4 ms·

The problem with any book list like this is the scope. Software is turning into a very diverse culture, a very heterogeneous ecosystem. Subjects that are very i

The problem with any book list like this is the scope. Software is turning into a very diverse culture, a very heterogeneous ecosystem. Subjects that are very important to one area might not be as important to other areas. Design patterns are essential for enterprise development, not so much for AI and low level systems programming. Algorithms are essential for the latest but not for the former. Given this, there are some books you might add or remove depending on the area you are interested (e.g.: Knuth's "Art of Computer Programming", Martin Fowler's "Patterns of Enterprise Application Architecture", ...) To finish, 2 books people recommend a lot for beginning programmers: "The Pragmatic Programmer"- Hunt, Thomas: a very good book, with sound advice and very easy to read. The only bad side is that it became so influential that its ideas became vulgarized in thousands of blogs. "Code Complete" - Steve McConnel : A very dangerous book. It does give have a lot of sound advice. But, IMO, it has some big problems. First is that it gives the false impression that there is a lot of empirical evidence on what works on software engineering. Second, it perpetuates some myths that don't have such evidence: the "orders of magnitude programmer's productivity" and "the cone of uncertainty" (see: https://leanpub.com/leprechauns https://leanpub.com/leprechauns).

tellarin 14y ago
I overall agree with you on "Code Complete", but where did you find data that disproves 'orders of magnitude programmer's productivity'? I can't reach the linked website. I'd be genuinely interested to check that. While still anecdotal, my experience from working in big and small companies in 4 countries is that there certainly is a absurdly wide gap in productivity between programmers.
- tjpick 14y ago
  Original source FOR the "orders of magnitude" claim seem to usually point back to Fred Brooks Mythical Man Month (5-10x) or Robert Glass (Facts and Fallacies of Software Engineering) 28x. I don't think either of these multipliers are accurately expressed as "orders of magnitude", regardless of them being supported by evidence. There is some discussion of the topic in "Making Software: What Really Works, and Why We Believe It."
  - tellarin 14y ago
    Hmmm. I agree that 'orders' is not an appropriate choice of words. But I usually don't interpret this kind of claims literally, so I took the GP remark as saying that in practice (IRL) there was no such 'wide gap in productivity', which is opposite to claims/data I saw before (as you mention, 5-20x) and to my own experience.
bcjordan 14y ago
Very good point about specializing the reading list for the areas developers are interested in. You're right, trying to come up with a one-size-fits-all reading list is foolhardy. Re: The Pragmatic Programmer and Code Complete, I learned a ton from those books and I'd heartily recommend them to programmers starting their first job or internship, but likely not to someone with a few months before their first round of programming interviews. What do you think? Maybe I will put together another list more tuned for general programming improvement versus interview-specific prep. As an aside, Patterns of Enterprise Application Architecture looks very useful, thank you for the pointer.

tellarin 14y ago

I overall agree with you on "Code Complete", but where did you find data that disproves 'orders of magnitude programmer's productivity'? I can't reach the linked website. I'd be genuinely interested to check that. While still anecdotal, my experience from working in big and small companies in 4 countries is that there certainly is a absurdly wide gap in productivity between programmers.

tjpick 14y ago
Original source FOR the "orders of magnitude" claim seem to usually point back to Fred Brooks Mythical Man Month (5-10x) or Robert Glass (Facts and Fallacies of Software Engineering) 28x. I don't think either of these multipliers are accurately expressed as "orders of magnitude", regardless of them being supported by evidence. There is some discussion of the topic in "Making Software: What Really Works, and Why We Believe It."
- tellarin 14y ago
  Hmmm. I agree that 'orders' is not an appropriate choice of words. But I usually don't interpret this kind of claims literally, so I took the GP remark as saying that in practice (IRL) there was no such 'wide gap in productivity', which is opposite to claims/data I saw before (as you mention, 5-20x) and to my own experience.

bcjordan 14y ago

Very good point about specializing the reading list for the areas developers are interested in. You're right, trying to come up with a one-size-fits-all reading list is foolhardy. Re: The Pragmatic Programmer and Code Complete, I learned a ton from those books and I'd heartily recommend them to programmers starting their first job or internship, but likely not to someone with a few months before their first round of programming interviews. What do you think? Maybe I will put together another list more tuned for general programming improvement versus interview-specific prep. As an aside, Patterns of Enterprise Application Architecture looks very useful, thank you for the pointer.