(Part 3) Top products from r/programming

i agree. books and tinkering are the very best way to get introduced to programming.

i read my first programming book the summer between my sophomore and junior years in high school. (i don't recall how old that made me at the time. 16? bah, i'm getting old.) anyway, that book was Herbert Schildt's The Complete Reference: C++. i found it really interesting, but knowing what i know now Python (The Quick Python Book and Learning Python are good) or Java (I learned on Thinking in Java, but Effective Java is supposed to be good, too) are probably better places to start.

hopefully your parents support your desire to learn programming. $30-$50 for a programming book and access to a computer are a small price to pay for starting a child on a hobby that could turn into a good career!

good luck, and keep us posted! :)

I've been pretty fortunate that I've been able to get interviews and job offers pretty easily within the game industry as a programmer.

I wouldn't consider myself a master programmer by any stretch and definitely don't spend as much time practicing on Code-Kata, etc as the poster. (The majority of my spare time is spent on unpaid overtime - if I can get that under control, then maybe I can apply some time to personal projects).

The 3 keys that I have found to make it easier to land the interview and the job is:

1. Networking - this is a MUST. If you know someone at the company that can vouch for you, sometimes the technical phone screen can be bypassed completely and it's a lot easier to position yourself above others when you have a good reputation before the interview. Call friends/colleagues that are still in the industry and ask if they are hiring or know anyone who's working somewhere where they are hiring. If there are conferences related to your specific industry (specialized types of programming), try to get to one of those and do what you can to get on a guest list for some of the company sponsored parties. Talking to people in a social setting goes a long way and is typically more effective that meeting a dedicated recruiting sessions.
   
   
2. Be energetic and friendly. Skills are only half the requirement, cultural fit and an easy going attitude go a long way to whether or not you'll get a job. How your potential colleagues feel about you is almost as important, if not more important, than if they think you are qualified (networking can help a lot to achieve this feeling amongst your potential colleagues).
   
   
3. Pick up this book and read it cover-to-cover: Programming Interviews Exposed. Most technical interviews ask questions from this book or variations of questions found in this book. Rarely do they really distinguish a good programmer from average/bad, but you're really competing with people that are good at interview questions and have seen them before vs people that are not or get a question they haven't seen. Every time I'm starting a new job search, I re-read this book, go over old programming tests that I saved and run through some of the problems from college programming tests on the ACM online judge website to get ready for obscure brain teasers.
   
   I can't really say whether the hiring process is broken or not, much of what they do does weed out people that really don't belong. But if you don't know the game or don't play the game, you may get swept to the side along with them.
   
   I hope this helps - good luck!

> I know basically nothing about x86 internals to make an accurate statement

If you're interested in learning about the internals, check out some real world technologies articles. For instance, Intel’s Haswell CPU Microarchitecture. On page 3, Haswell Out-of-Order Scheduling, it talks about the register renaming that goes on to support out-of-order execution.

It's more detail than most people really need to know, but it's interesting to understand what modern microprocessors are doing under the hood during program execution.

For anyone else reading, an even easier introduction to the topic is in the awesome Computer Systems: A Programmer's Perspective. It'll get you comfortable with the machine language representations of programs first, and then move on to basic architecture for sequential execution, and finally pipelined architecture. It's a solid base to move forward from to modern architecture articles like on real world technologies. There are more detailed treatments if you're really interested, e.g. Computer Architecture, A Quantitative Approach, but I have never read it so can't say much about it.

7-zip uses a mix of C, C++ and assembly. Unless you have experience with any of these languages, I would highly recommend starting with something much simpler.

I would say if you're trying to learn programming, you need to strip away all the extra 'stuff' that gets packaged up to make a production system. Don't worry about the GUI, and put WPF and C# to the side (for the time being). Start with something simple that will allow you to learn variables, functions, types, control flow, etc. A lot of people recommend Python, and that's a fine place to start. Any language where you can open a new file, write a few lines of code, and see a result would be ideal (Lua, Ruby, Javascript, etc).

More to the point of your question, GUI design is hard. There are all kinds of issues that have to be taken into account: event callbacks from the 'worker' code to let the interface know something changed, threading issues (does the interface lock up while the backend is working?), does the 7z file format even lend itself to parsing just a directory listing without decompressing the entire file?... There is a lot there, and it's not a good starting point. It's something that you can move toward as you learn the basics, though. And I always like looking through other codebases looking for good ideas.

If you're really serious about specifically working with 7-zip, the code is available at their website. You'll need to download the source code from 7-zip.org, then you'll need C Primer Plus and C++ Primer Plus. These are the best 'intro to...' books that I've found for C and C++. You're looking at a few months of reading and experimenting, and a lot of frustration. You're not only going to learn the languages, but also the Windows API that will allow you to interact with the folder views. These are somewhat stubbed out in the 7-zip source, but the specific view you're talking about would need to be written from scratch.

Regardless, it sounds like a fun project and if you put in the time I'm sure you'll get some benefit from it. Just be aware that this is trying to paddle against the current, and it is easier to take a step by step approach (in my opinion).

I think you need a bit of all of these.


If someone's asking you weird questions about esoteric details of Hibernate, they're probably not the kind of person you'd want to work for. OTOH.. if you get a question, like, "do you prefer Hibernate XML mappings or annotations? why?" and you can provide a reasonable defense for either position, I think this should be enough to vouch for your credibility as a competent developer. IMHO, it's not often about what you know, but how you make intelligent, thoughtful decisions. If you're not interviewing people who are proven to be intelligent, at least on paper, then there's probably something wrong with the screening/selection process.


Puzzlers in interviews can go either way, and I'd never discredit a candidate for not being able to solve eccentric riddles on the spot. If you can, however, figure out a new problem in a clever way then it can't hurt you. Reading this book or this book are good places to start to get your mind thinking in these directions.


In my opinion, you should probably also have a good prep for the garden-variety HR interview questions as well... if you can't 'describe a weakness' without using a stock answer, that's probably something to work on before the interview. These types of questions are usually pretty lame, but anyone who's done a few interviews should have answers for the most common ones.

This book has a pretty strong breakdown of how computers and processors work, and goes into more advanced things that modern day hacks are based off of, like address translation and virtualization with the recent Intel bugs:
https://www.amazon.com/Computer-Systems-Programmers-Perspective-2nd/dp/0136108040
The book can be found online for free. The author's website has practice challenges that you can download, one of them being a reverse engineer of a "binary bomb". I did a challenge similar to it, and it felt pretty awesome when I was able to get around safeguards by working with the binaries and causing buffer overflows.

> Not once have I thought to myself "Man, if only I'd wrapped this
> thing in an interface" during refactoring

Really? I say this to myself all the time, especially working with legacy code bases. Mostly in cases where business logic and persistence logic are deeply intertwined. The interface puts a hard firewall between the two, and protects the business logic from the persistence logic (and vice versa).

> Again, I've never actually seen this work.

I have seen this work all the time. For example, we started with a code base with no clear domain model at all, and by refactoring towards a domain model, the code became simpler, much easier to understand, and substantially easier to modify. Because the domain model speaks the language of the business, adding new business rules is a natural process, not an exercise in hacking in a new business rule into a mass of code in non-obvious ways.

The Domain Driven Design book demonstrates this transformation with several very good examples. This is a very good book in general to understand how to design effective domain models.

> I would agree some of the abstractions coming from FP are useful

That's not really the point... The point is that abstractions are everywhere. You can't escape them and thus abstraction certainly isn't a dirty word.

> the OOP cargo cult

OOP isn't a cargo cult, but there is cargo culting in OOP, just like any other methodology. It all boils down to understanding why things work, instead of blindly following "best practices".

It may be a big of a tough slog, but Sipser's Introduction to the Theory of Computation is great. The stuff on computability theory might be right up your alley, and even if you only make it through the chapter on deterministic finite automata you likely will be better at crafting a regular expression than many of my CS student peers.

Surprisingly enough, the book should be able to help you make sense out of that last sentence within 100 pages requiring only a bit of understanding of proofs. I think if you've got predicate logic under your belt you pretty much have all you need.

First of all you don't need to write a billion lines of code to create an OS. The first version of Minix was 6000 lines long. The creator of Minix, Andrew Tanenbaum, has a great book called Modern Operating Systems, in which he explains the inner workings of several famous operating systems.

Considering the emphasis on "from scratch", you should also have a very good understanding of the underlying hardware. A pretty good starter book for that is Computer Organization and Design by David A. Patterson and John L. Hennessy. I suggest reading this one first.

​

I hope this can get you started.

For iOS devices, you're going to want to start here, this will get you familiarized with the NeXtStep family of jive turkeys, followed up with a more formal introduction to Objective-C. I'll be honest, having some working knowledge of C will never hurt you, so after you're done with that, take a peek at K&R.

If you're aiming for Android, you have a bit of a different education outlook, I'd recommend brushing up with Head First Java. When I started poking around with Android, I read Hello, Android most of it should be still pretty relevant. I'm not entirely sure if it has been updated as of late, I outgrew it rather quickly, and if you do too; pretty much anything and everything by Mark Murphy is relevant. Best of luck!

Ok, let's see. A few quick points:

Rooted in in standard, everyday mathematical notation? public static final volatile interface abstract class transient inner class inner anonymous class objects values boxed values..... etc...

Java Generics has drawn heavily from the functional programming camp which is based on lambda calculus. See google tech talk: Faith, Evolution, and Programming Languages

Extremely easy to read and understand? Go read Java Puzzlers and Effective Java to see how many easy mistakes you can make.

Static types enables blablabla...? Not possible without static typing...? Does he realize that tools like Eclipse grew out of a smalltalk project and that smalltalk pioneered automatic refactoring ages ago? Smalltalk is one of the most dynamic language around, and it's more than 30 years old.

Most bugs are found at development time with java? That's not my experience :-)

Simple puzzle: for which values for someInt does this code fail?
int myPositiveInt = Math.abs(someInt);
assert myPositiveInt >= 0;

This is in my opinion by far the best book on introductory computability and one of the best books on any kind of computing that I have ever read. It ranks right up there with Knuth for me.

It is clear and elegant and explains what's going on in a really well thought out fashion. Highly recommended.

Your job is not to make them like you. It is to accurately deliver something, and make them hire you. "I don't know, but we can figure it out..." is as close as you can get without being dishonest.

At my company we have 3 solutions to "I don't know" when asked "How Long is this going to take":

We offer to do an estimate of the software at our expense for people doing hourly. It will be rough, a range, and by no means guaranteed, especially if there are any scope or other changes pushed over to us.

If they want a detailed, super through estimate (using a lot of the techniques in this book), we offer to do one, at our normal hourly rate. As many projects where customers care this much would take as much time to estimate as it would to do 40% of the project, then you likely don't REALLY want to spend that amount of time doing it.

If they want a fixed price (and this is the real deal for most of them), or a fixed deadline, then we offer them a price that we develop off of working through a moderately through estimate, timelines of availability, and how much we want any IP we may get out of this agreement. Additionally we tack on a "Changes cost extra, and will be billed hourly, unless prior fixed fee amounts are asked for and agreed upon"

Seems to work out fine.

Before teaching myself C++, I was terrified of the language too. Everyone said it's such a big language with many dark corners, and for the most part they're right. Then I /had/ to learn it for some coursework. I found the book C++ Primer to be very good. I abused all sorts of features of the language at the start, wrote tens of thousands of lines of code, and now I actually enjoy using the language for some tasks.

By analogy, cars and driving are scary too, but a healthy respect for the rules and best practices will usually get you to your destination safely.

> That's exactly a multi-agent simulation.

Well yeah, that was kind of my point. At least in biology, this isn't unusual.

> For most processes this is a too low level representation to be
> useful.

I find very useful, and I've modeled pretty much all business processes that I've implemented this way. Eric Evan's excellent book Domain Driven Design describes some very useful ways to reason about business processes, in effect, as multi-agent simulations (if you call an agent an entity in DDD terms).

I've read about this practice in Rapid Development, used as a motivator. I have no firsthand experience with the practice as it's described in RD but it I expect that it's not as awful as all that.

As described in RD, the manager offers the project to the engineers from the standpoint of a challenge: "here's this thing we want to build, it has [x] requirements, we need it done, who is in?" The manager then must leave it up to the engineers as to whether or not they wish to participate. It stands to reason that this procedure can't be used in all contexts, for example, successful implementation usually results in a loss of management control and progress visibility. The takeaway is offering people a chance to be a part of something interesting is a powerful motivator.

Note: I just reviewed the chapter in RD and it uses The Soul of a New Machine as a reference.

First of all, for any software development questions you may have, I suggest you post your questions on Stackoverflow because the people there will surely provide you with answers.

Now, for a list of books I recommend:

JavaScript

JavaScript: The Definitive Guide; if you're new to JS, start with this one.

JavaScript: The Good Parts; not a beginner's book, but a must-read if you are going to use JS

If you are going to be using JS, you will most probably be developing using a framework, and for that I seriously recommend mastering jQuery because as they say, you will write less and do more!

CSS

CSS Mastery: Advanced Web Standards Solutions

Web Usability

Don't Make Me Think: A Common Sense Approach to Web Usability; the book that shows the users' perspective when viewing a website

Performance

High Performance Web Sites: Essential Knowledge for Front-End Engineers and Even Faster Web Sites: Performance Best Practices for Web Developers;if you want to get serious about performance for your websites

I can't recommend anything offhand, but I'm there's bound to be books aimed at someone in your position: coders who have to produce decent web/web application interfaces.

Robin Williams' (no, not the actor) books like her Non-Designer's Design Book are good introductions to basic principles of layout.

Jakob Nielsen's Designing Web Usability and Krug's Don't Make Me Think cover principles of good interface design. This looks promising too: Designing The Obvious.

In college, I probably wouldn't have cared and had it end up as a fluff class (if it got offered at all, academia is notoriously different than the industry). There was far too many other things to learn. As it was I took intro, mips assembly, digital logic, data structures, compilers, operating systems, theory of programming languages (imperative and functional), theory (the regex to Turing machine), AI, and numerical methods - and that filled up all of my CS degree requirements.

In the mean time, I've found a few books that do capture some of this philosophy. Probably the best is Programming Pearls, though there's some in The Mythical Man Month too. (And yes, this time it is something I wrote...) my list of Five books every programmer should read captures some of that.

The post Ruby’s Principle of Too Much Power is a good read about what happens with too much power.

I do suspect much of this comes from our generation and the code philosophy we (or at least I) was brought into back in college. From that W3 link:

> Computer Science in the 1960s to 80s spent a lot of effort making languages which were as powerful as possible.

More powerful languages to hide the complexity more. C++ and Java came into the world with the idea of encapsulation and private variables - OO coming into vogue. Everything was "more power" (and I have Tool Time flashbacks here). It took two or three decades to come to terms with "too much power is not a good thing."

... and yes, this is finding its way to a blog post of my own.

Interesting that I was never required to read any of these books while in college. Luckily, I have read 5 of the 12 on my own time and they have definitely helped me in my professional development - Refactoring, Clean Code and Design Patterns in particular. I also highly recommend Peopleware and reading other people's code on Github or elsewhere, particularly if you are learning a new language.

And that is exactly why I recommend reading these books to people. Information online can often be misleading, wrong, old, or all of the above, at least in a book which is praised by so many people, you know that the info which you are getting is top value. I know that learing C++ can be a bit difficult, but remember that you do not need to know all of it at once (heck - nobody knows all of C++, and even Template Metaprogramming was kind of discovered by accident ). I hear that Accelerated C++ is a good book to start from if you already know some programming in another language. C++ Primer Plus is huge, but also good.

Huh. After reading this thread, I'm pretty happy that Stack Overflow did not exist when I started programming in the early 2000s. All I found were sketchy pay-for-answers sites, which I did not trust (I was also a broke 13 year old), so I was forced to go buy a giant book on C++ and read it all the way through. this one

That gave me a great base of patterns to work with and I was able to not pay any attention in college because I already learned most of the material.

I do love Stack Overflow for shit like "How do I fix this obscure OpenGL error?" though, it has become an irreplaceable tool in my toolset.

Friedman & Felleisen Little Schemer seems noteworthy. Unorthodox, but nicely done.

And while I think that Meyer's technical writing isn't exactly the best, Object-Oriented Software Construction has a nice visual layout and is one of the few computer books that uses color effectively.

> I don't know what the fuck you're actually advocating.

Try to get some more experience, kid. Especially with things like Dependency Inversion and Domain Driven Design. Then maybe you'll understand.

> Put adaptors on all the things so you don't depend on them, but
> you're not passing interfaces to everything.

You don't create such fine grained interfaces that wrap around a single library in particular. That would make the adapter nothing more than a call translator. You would end up with a bunch of interfaces around every little library you need, and that would be dumb.

The whole point is that your code represents some business functionality, and the architecture should be dependent on the rules of the business. At some point you'll need help with some aspect of the business or another. You write an interface to describe that need. The adapter simply fulfills that need.

The adapter will probably have functionality of its own, and depending on the system, perhaps not trivial. But that functionality is isolated from the rest of the system. It can be replaced at some cost that is isolated.

J2EE application servers do a lot of work, and the EJBs leveraged that capability (like clustering, distributed transactions, etc.). We had to find replacements for those capabilities. The replacement wasn't trivial. But the application itself could care less about most of that. So the risk to the application was substantially reduced.
Which allowed us to focus on specific, isolated areas and didn't risk the entire application.

> Then you talk about the one time that architecture saved you
> time and not the five hundred times it didn't.

Prove it.

> If you're putting all libraries in an adaptor then you're interfacing
> all the things and your constructors will be huge or nested.

The number of interfaces depends on how fine grained your abstractions are. You don't want your abstractions to be too fine grained, or you'll have a ton of dependencies. If you end up creating 15 interfaces in your constructor, that means you have way too many dependencies. That's a definite code smell and a definite sign you need to rethink your abstractions.

> If you're transforming your data

And what data would that be? For the most part, we are talking about parameters.

> you've got application logic in your adaptor which means
> replacing it is not low risk.

Not application logic, which is another domain. But logic related to the domain of the library. Because that logic is isolated, and independent of the business rules of the application, it is a lot easier to replace.

> If you're encapsulating your errors you've broken your stack
> trace.

Nope. The error is simply being recast into the application's domain. That is if it needs to be recast into the applications domain at all. The adapter can do much of the error handling itself, if that error handling falls into its domain.

> Separating your business logic from your presentation layer has
> nothing to do with being dependent on libraries.

It has everything to do with it. The separation of presentation layer from business logic is small potatoes compared to what I'm talking about. The Domain Driven Design book has a great section about the Anti-Corruption Layer, which describes how to protect an applications architecture from the architecture of other libraries and systems.

Libraries that represent an entire domain separate from the business domain shouldn't affect its architecture. If the library is substantial enough that it could effect the architecture of the application and more importantly is a risk to the application, it belongs to a different domain and the domains should be separated to reduce risk. We're not talking apache-commons-lang which just does string manipulation.

C++ Primer is excellent.

(NOT C++ PRIMER PLUS OH DEAR GOD STAY AWAY)

Thank you all for your responses! I have compiled a list of books mentioned by at least three different people below. Since some books have abbreviations (SICP) or colloquial names (Dragon Book), not to mention the occasional omission of a starting "a" or "the" this was done by hand and as a result it may contain errors.

edit: This list is now books mentioned by at least three people (was two) and contains posts up to icepack's.

edit: Updated with links to Amazon.com. These are not affiliate - Amazon was picked because they provide the most uniform way to compare books.

edit: Updated up to redline6561

• 14 The C Programming Language
  
• 11 Structure and Interpretation of Computer Programs
  
• 8 Introduction to Algorithms
  
• 7 Compilers: Principles, Techniques and Tools
  
• 6 Programming Erlang
  
• 5 The Mythical Man-Month
  
• 5 The Pragmatic Programmer
  
• 5 Applied Cryptography
  
• 4 Beautiful Code
  
• 4 The Little Schemer
  
• 4 Programming Perl
  
• 3 Types and Programming Languages
  
• 3 Gödel, Escher, Bach
  
• 3 OpenGL Programming Guide
  
• 3 Code Complete
  
• 3 Artificial Intelligence: A Modern Approach
  
• 3 Programming Pearls
  
• 3 ANSI Common Lisp
  
• 3 A Brief History of Time
  
• 3 Agile Web Development with Rails
  
• 3 Concrete Mathematics: A Foundation for Computer Science
  
• 3 Modern Operating Systems
  
• 3 Paradigms of Artificial Intelligence Programming
  
• 3 Operating System Design and Implementation
  
  

he lost me when he said this about GEB
> If you only read one book on this list, it should be this one.

seriously? it's not that i don't appreciate the sentiment, but things douglas hofstadter thinks are neat is no substitute for any single book on the rest of the list unless you

• have no other way to explain at cocktail parties what you studied at school
  
• try to sound smart at cocktail parties by talking about things in GEB without actually referencing the book.
  
  for my part, i'd add sipser's computation book and why not throw in some ken thompson in there as an amuse bouche?

Have a look at Effective Java by Joshua Bloch - Each chapter in the book consists of several “items” presented in the form of a short, standalone essay that provides specific advice, insight into Java platform subtleties, and outstanding code examples. The comprehensive descriptions and explanations for each item illuminate what to do, what not to do, and why.

::edit:: wrote Essential instead of Effective

I highly recommend "The Code Book" to any novices interested in this sort of thing, it's readable and entertaining without being insulting or excessively complex.

For an excellent, easily accessible description of some of these codes and the work done to break them, I recommend The Code Book by Simon Singh. Amazon link

> but as far as I know the repository pattern only really achieved popularity after the blue book came out and that's the one DDD technical pattern that really seems to have been widely accepted.

Are you talking about Smalltalk-80 the Language and it's Implementation? Or this book on Domain Driven Design?

> If the author truly cares about advancing software engineering, I'd ask what he's doing to advance software engineering (apart, of course, from proposing laws and writing about it on his blog)?

Bertrand Meyer has done a fair bit to do that, Eiffel and Object-oriented Software Construction sticks out.

It's one of the best OO languages, with one of the best books to go along with it OOSC. But it was never mainstream. And a purely OO language is becoming a thing of the past.

All the current new languages are more or less hybrids between OO and FP, for example: Scala and F#. Even C# which is touted as an OO language has a lot of FP features that were not available in Eiffel.

It is probably not a bad language for teaching OO, probably better than Java and C++ especially when used with the book mentioned above. But it's not my favorite language. Haskell is, but it's not OO so I'm not sure if it counts. (Not a big fan of OO either anymore) .

I quite enjoyed The Code Book by Simon Singh. It's a book on cryptography for the layman. Not really about computer science, per se, but it's fascinating and explains a lot about thinking algorithmically.

I'm assuming he/she will have to read them first and get back to you, but set gets some great reviews on amazon

Run and get a copy of Computer Systems: A Programmer's Perspective. It covers everything from assembly to semi-modern computer architecture, operating system abstractions, and concurrent/parallel programming.

It's pricey, but worth it. A used copy of the first edition would be plenty good enough if price is an issue.

Programming Interviews Exposed is an extremely good resource, Steve Yegge also has a good post on areas a programmer should be proficient in.

Nothing is really a substitute for being knowledgeable and enthusiastic.

Basic:

C++ Primer

Effective C++

Effective STL





Advanced:

More Effective C++

C++ Coding Standards: 101 Rules

C++ Templates The Complete Guide

Large Scale C++ Design

This is a nightmare. After reading Peopleware (http://www.amazon.de/Peopleware-Productive-Projects-Tom-DeMarco/dp/0321934113/ref=sr_1_1?ie=UTF8&qid=1421350607&sr=8-1&keywords=peopleware) you'd expect major players like Facebook and the likes have learned by now. But nooooo, let's continue to pretend a software company is a huge fabric where people sit in front of monitors instead of working the assembly line. What else could be different?

\ It is entirely possible that they just do this to show off to stakeholders, because those aren't impressed by a row of closed doors.

Excellent book!

You can't forget Tanenbaum: http://www.amazon.com/Modern-Operating-Systems-Andrew-Tanenbaum/dp/0136006639/ref=sr_1_1?s=books&ie=UTF8&qid=1302667905&sr=1-1

Or the design of the BSD operating system: http://www.amazon.com/Design-Implementation-FreeBSD-Operating-System/dp/0201702452/ref=sr_1_2?s=books&ie=UTF8&qid=1302667950&sr=1-2

Two Must-haves for any *nix // C guys out there!

Yep, Prata's C++ Primer Plus [5th ed.] and Lippman's C++ Primer [4th ed] are very very good. The 2 books are completely unrelated, by the way, in spite of the similarities in version numbers and names.

I've never been a huge fan of Stroustrup's tome, sure it's complete, but it's slow going. The 2 books above are good for someone jumping in, esp. if you've got a C background (not required however.)

• practical object oriented design in ruby
  
• smalltalk best practice patterns
  
• refactoring to patterns
  
• object oriented software construction

> creating a strong cryptography algorithm is primarily trial and error

I don't think it's trial and error, more like a series of steps in which each is designed to befuddle a particular class of attack that may have been successful on previous iterations. This sort of goes back to the Cold War and even WWII—a code like Enigma was the scramblers and the plugboard, where the plugboard was specifically added to foil a type of dictionary attack.

Anyhow, not that I really know too much about it, but this is a fantastic book on the topic.

Best work I've seen on subject:
http://www.amazon.com/dp/0735605351

Peopleware has an entire chapter on this, as I recall. Great book.

C Programming: A Modern Approach by K N King is a great book and is recommended in the C FAQ.

When I first started programming, I started with C++. C++ Primer Plus was my primary learning tool, and worked out great. I'm not a full time developer (mentioned as proof that it worked and I didn't wash out of programming)

It's a search algorithm which divides up the solution space using binary search.

See Programming Pearls by Jon Bentley for an interesting investigation of the ubiquity of binary search.

A good complimentary book is "Anti Patterns": http://www.amazon.com/AntiPatterns-Refactoring-Software-Architectures-Projects/dp/0471197130

I realised that UX design could be fun only after reading http://www.amazon.co.uk/Dont-Make-Me-Think-Usability/dp/0321344758

Thanks for the recommendation!

What do you think about his books on Rapid Development and Software Estimation?

Do you mean "C Interfaces and Implementations: Techniques for Creating Reusable Software by David R. Hanson"?

Or perhaps "C Programming: A Modern Approach, 2nd Edition by K. N. King"?

This book was my jam in college. Somewhat dry, but clear and concise.

I see he just published a second edition in 2005; I used the first, and I bet you could get it on the cheap.

UPDATE: I think the reviews on Amazon are very accurate with the exception of the one dude who Just Didn't Get It.

I was in a very similar situation, and read many of the books poeir wrote up. However, the one I found the most helpful was Steve McConnell's Rapid Development.

At least make sure you borrow it from your library and read the part about classic mistakes.

there is an excellent book called peopleware that goes into lots of management fads, check it out, you might just like it.

I also recommend the book Peopleware

If you are looking to go a little deeper, I can recommend this book as well:

"Computer Systems: A Programmer's Perspective"

http://www.amazon.com/Computer-Systems-Programmers-Perspective-2nd/dp/0136108040/ref=sr_1_1?ie=UTF8&qid=1292882697&sr=8-1

This book has a similar thread, but is much more in-depth and covers modern Intel and AMD processors, modern Operating Systems and more.

I learned all about linkers, compiler optimization, the crazy memory management structure of x86...

K.N. King's C programming
covers upto C99, I don't know if there's anything significant in C11.

This should be at the top of the comments list with 150 points. This book helped me immensely.

This article is a ripoff of a couple of chapters from Steve McConnell's 1996 book, Rapid Development.

He could have at least given credit to that book for all of the point mentioned. Its not quite word for word, but there are too many similarities to be co-incidental.

I have to say that I don't know. I know that some people like KNK, but as I haven't read it, I cannot vouch for it.

Yep. It's been a while, but I think the process you're talking about is all documented in Rapid Development from when McConnell was at Microsoft. I think it was called "Spiral"?

RELEVANT TOO

The Art of Computer Programming by Donald Knuth

Donald Knuth:

http://www.amazon.com/Art-Computer-Programming-Volumes-Boxed/dp/0201485419/

The goto theory book by Sipser.
Excellent for C programming.
Programming in general.
My favourite.
You can probably find all of these at a library.

It is an academic paper and written as such. For a more practical approach to the topic, try some of these:

Programming Pearls

Performance Bugs

Performance Engineering of Software System

Programming Pearls by Jon Bentley

Start with Don't Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition

Then read GUI Bloopers 2.0, Second Edition: Common User Interface Design Don'ts and Dos

Then possibly The Design of Everyday Things

And follow up with The Non-Designer's Design Book

Effective Java

Effective Java is necessary if you work with Java.

Only two months left

The Hillegass book is kinda the Cocoa bible. Clicky.

There's also a relatively cheap book on programming interview questions.

This is it:
http://www.amazon.com/AntiPatterns-Refactoring-Software-Architectures-Projects/dp/0471197130/ref=sr_1_1?ie=UTF8&qid=1450850251&sr=8-1&keywords=antipatterns

Ah...Sipser.

Have you read Software Estimation: Demystifying the Black Art?

Management shouldn't be making the estimates in the first place.

Have you looked into studies on programmer productivity? There's plenty of literature. They used benchmarked tasks.

Nah, http://www.amazon.com/Modern-Operating-Systems-3rd-Edition/dp/0136006639.

The Code Book for a primer on the basics up through some simple explanations of modern computer cryptography and the Handbook of Applied Cryptography for serious math proofs of a lot of the modern crypto standards in use today.

I distrust this website. Don't buy from them.

I once bought their anti-patterns book, but I quickly discovered that it was a ripoff of the original anti-patterns book, the text and even the graphics were literally copied from that book.

I get it. I should give the article the benefit of the doubt, like you gave my comment.

The first sentence was an exaggeration, maybe intended to provoke and make you read the rest. I don't blame you for writing off my comment -- there are too many bogus opinions and malformed arguments and conclusions, that not using past experience as a filter would be quite the test of patience, not to mention, a waste of time.

For what it's worth, I did skim ahead and read parts of it, and it seemed to try to convey "common sense" concepts, using conjecture and complicated constructs. It hurts my brain when I try to understand what is meant by "to use up cognitive resources". The more convoluted an explanation is, the less I feel it has been understood by the person explaining it. I have a strong distaste for psychology terms that add depth, but not clarity, as if trying to validate and give authority to the field or explanation.

A bit ironic for an article trying to explain the concept of "minimizing drainage of the cognitive tank" (to paraphrase).

So, what is this article really about? This.

Let me change my reactionary first sentence from "What a stupid article", to "What a waste of time -- anecdotal, conjectural, and even the bogus psychological experiments she references are completely misrepresented".

Thanks.

I disagree with the suggestions of podcasts, videos, and developer documentation. You really need to start here:
Cocoa(R) Programming for Mac(R) OS X

The problem is in using expert judgement in the first place. Thats the last place you look if you have no other data available, or you're estimating something on the scale of < 3 weeks.

There has been a whole lot of work done on analytical approaches to SW estimation, and they generally work really well. Use company historical data, use team historical data. Find something close to what you're planning, and base your estimate off that. As the linked article states, people are just generally bad as estimation, so rely on data instead.

This book is a pretty decent primer. http://www.amazon.com/Software-Estimation-Demystifying-Developer-Practices/dp/0735605351#

No, but looking into it I wish we had.

We used Modern Operating Systems 3rd Edition also by Tanenbaum.

I think what we can conclude from this is that the man really knows his shit, both about teaching and about operating systems.

• Object Oriented Construction and Design
  
• GOF Design Patterns
  
  These books will bring your design skills up a notch and give you some material to back up your arguments in design disputes.

While you're at it, also read Antipatterns, which gives a very good explanation of what goes wrong when patterns are ignored, and how to remedy those problems.

http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr

I hate tech tests.

I worked at a company were we needed a C++ developer to work on some legacy C++ code we had. We had no C++ developers but my manager still had to scramble around for a tech test for a C++ developer.

I don't understand why there is no certification for developers. Everyone thinks their tech test is unique but they are not. I've been to many tech tests and they all cover the same crap that is not relevant to any job I've ever had. If tech test were unique books like this would not exist http://www.amazon.com/Programming-Interviews-Exposed-Secrets-Programmer/dp/047012167X/

And if I need an accountant I don't put them through a tech tests to see if they are qualified.

Carpal tunnel syndrome is a specific injury. If you're having physical discomfort and pain from using a computer it is more likely RSI (Repetitive strain injury).

First of all you must fix your workstation. An adjustable chair and a keyboard tray are the most important items. Learn to be an ambi-mouser and use keyboard shortcuts more often.

Secondly your body is not meant to type on a computer all day. You need to exercise, stretch, take breaks, etc.

Thirdly buy this book for professional advice - It's Not Carpal Tunnel Syndrome! RSI Theory & Therapy for Computer Professionals

• Are you sure you have carpal tunnel syndrome? This book helped me.
  
  
• No matter what the exact diagnosis is, it's not curable. The best you can do is to lower the stress and lower the strain in order to (significantly!) reduce the pain.

IMPORTANT REPLY!!1one: I've been dealing with this for YEARS. I finally figured it out. I feel like the acne kid in the frontpage here.

Actually the only/best solution is activity and enough sleep. Your brain needs at least ~8 hours of sleep to restore your muscles. Your body needs physical activity to move blood and keep the wiring clean.

Hand pain:
It is weird, but your knuckles are part of one big nerve and although it seems like only they are fucked up, a lot of it is really your shoulders are fucked and your chest isn't open, so your knuckles don't get lubricated enough to deal with typing all day. (I know that sounds weird :-) )

Sleep: Give your body space to relax and sleep after work/homework/WoW and you will see immediate results because your muscles will reset properly. If you are about to tell me you can't relax or sleep easy, this is a good indicator that you need to slowly train your body to relax! Physical activity is part of that training. It will ease your brain from this tenseness, you will be able to sleep better, which will let you relax more.

Activity:
Yoga is cheap physical therapy and attacks exactly the part of the body computer scientists fuck up. My Yoga class has more men than women so don't be socially shy about it. Look for forrest yoga, it is actually designed for working professionals who wear themselves down and isn't too hard but will still give you rad muscles. Wake your body up in the morning with a rubber band shoulder exercises.

Further tips:
If your doctor is a dick and says your life is over, says stop typing so much (when it is your job), or jumps immediately to getting you median nerve surgery for carpal tunnel syndrome then his education is outdated. That is what people believed 15 years ago. Don't let it get bad enough to be nerve damage. It's probably just musculoskeletal problems and you can fix those!. Read the book "It's not carpal tunnel syndrome!" if you need further guidance.

You can tell this guy wasn't getting sleep, he was a perfectionist. We are really shitty priority queues by definition. I am a perfectionist who dealt with this and I know what I am talking about here.