I read "The Pragmatic Programmer" about two years back and back then I felt inspired and excited about all the wonderful ideas shown in the book. Fast forward to today, it seems that stuff was kinda obvious - automate things, read, take responsibility, care for the craft, be patient and the other forty tips.
I kind of believe that, have I not read the book, I would have stumbled upon the ideas later anyhow, by reading blogs, tinkering, and making mistakes. Albeit, it is wrong to expect any magical words that can shift your direction completely, but still I am not sure how much value do printed ideas provide vs learning them by experience. I am not implying that books like it are futile but I don't buy that they are "career-changing".
Same goes for reading about Design Patterns. I believe it is better to learn "Design Patterns" by building and reading code and finding a certain code organization better for your use-case, rather than enforcing a kung-fu-singleton-ninja pattern where it might be simply an over-engineering.
Therein is the career-changing aspect. Yes they seem obvious now, but you had a roadmap for your learning. That is why it, and many of the other books, are career-changing.
I agree. I have been programming for many years, working in the industry for four years, and have always been interested in improving with clean code, testing and whatnot.
I read the Pragmatic Programmer last year, and it was .. very boring. Most of the tips were like "doh, of course". It's a beginner's book, not for someone who have been trying to improve their code (and processes around it) already for some years.
Greg, was it you who recommended Ready Player One to me? Looks like I already bought it on my Kindle on $MYSTERYPERSON's recommendation, so now I'd better read it!
Here's an odd one of mine:
The Trachtenberg Speed System of Basic Mathematics
I checked this out from the Scottsdale library when I was 11. I'd learned all the usual algorithms to multiply and divide and do basic arithmetic, but like most kids, I assumed that those were the only ways to do those things - that the steps we learned were truly fundamental and the one and only way to get the result.
Then I read Trachtenberg and learned that there were other procedures you could use to get the very same results. The techniques we'd learned were not the only ones!
Oh, there were tradeoffs - you might have to remember more stuff and more special cases - but once you had those down you could zip right through a calculation that would have taken a long time otherwise.
So that's how I learned that there was more than one way to do it.
'How to Solve It' looks to be just the book I've been looking for. I would say I'm fairly good at problem solving, but I've always felt that I do a lot more stumbling around than I should on my way to solving most problems, and I really should be methodical about it.
You are young and so forgiven to have not included as #1 the seminal works of Donald Knuth, "The Art of Computer Programming", still as relevant today as it was in the late 60's and 70's. What he described is to this day true of the underpinnings of all we do, everything since is really decoration and elaboration. And I say this as a still active systems developer, familiar with and working with current SOC systems from DSP coprocessors on up, not as an old fogey left by the wayside and complaining about the youngsters today. Although they really don't know what it took to get here.
In the preamble the post discusses wanting to learn how to write enterprise-type code, but if we are going just good ol' CS books in general, no one can touch SICP. The definition of abstraction in there blew my mind.
For algorithms, I like Skiena's Algorithm Design Manual. That's a practical-oriented book, where theoretical learning is mixed with anecdotes about real life problems solved.
The same cannot be said for TAOCP, but it certainly looks very good on a shelf. Practical usage? Limited. You don't need Knuth to learn basics of time complexity.
To my down-voter: TAOCP is essential foundation to understand the whys and wherefores of writing good code at any higher level; one must understand the mechanics and limitations of the systems one is using.
Hoping for Moore's Law to save your performance is not the way to do things.
Knowing about what goes into an ISA, about how operations map onto the hardware, about cacheing, memory virtualization and architectures, about in-order and out-order execution, multi-processor scheduling and synchronization, communications basics (on top of which all other protocols are built), distributed processing gotchas, etc etc, all play their part in writing efficient and effective code wherever.
Languages are tools, all are Turing Complete and can do no more than any other; which to choose for any function is a matter of convention and convenience. And what coding style to use is convention, and how to integrate with other programmers, how to manage projects, "Best Practices" and Patterns, all are conventions, and the degree to which they make the difference is a function of the quality of the involved programmers abilities, not a function of the style chosen. Hence my characterization of all the above as "Elaborations and Decorations". Most of the earlier hardware list also fit into that characterization, but the idiosyncrasies of each ISA and core architecture can have enormous impact on the final products' performance and need proper attention.
It is sad that after 50 years in the business I still know how these things work, and how to make them sing. It should not be so. But the technology has only gotten smaller and faster and has more immediate storage available and faster I/O and more elaborations and accelerations. No fundamental changes. Not that it doesn't blow my mind every so often, that what was a mere pipe-dream in the 60's is today mundane, or even so ubiquitous its underpinning have faded into the background. But it was pretty much already all down on paper in the 60's, just waiting on the capacity of technology SOA to catch up.
The list presented contained very little if any fundamentals. And without the fundamentals, the knowledge garnered is rote, founded upon shifting sands. Thus, I posit the books from which one learned those fundamentals should occupy top place in any such list. The knowledge garnered shapes every future thought on the subject, shapes every problem solving approach, shapes how you think about computers and computing at an internalized level.
In 50 years of commercial (if not commerce per se) experience (and continuing), every hire I've had the pleasure to work with has them, and every hire that frustrated and produced bad, unreadable, buggy, and inefficient code, did not.
That we have today billions of transistors in the space once occupied by one, and clock cycles thousands of times higher, and communication rates trillions of times higher (potentially anyway), is no excuse for not understanding how it all fits together. Today we need to do more with what we have, and so resources are always limited. Possibly a derivative of Parkinson's Law at work. Instead all too often I see bloat and the hope that tomorrows' machines will fix things. Tomorrow never comes, it seems.
As IIRC Piccasso (Dali?) is reputed to have told one young hopeful: "Come back to me when you can show me you can draw a straight line. Then I might believe those squiggles mean something".
come to say this. code complete is basically a free ticket to obtain 10 years of working experience in one go. I read it after 3 years of career, and still found the content insightful
I'd also add the mythical man month. being a programmer is good, but overspecializing as the technical guy cause a certain degree of blindness to other software requirements (cost, time, quality). some part of that books can't really work in today work environment because external constraint, like the surgical team, but every word of it is gold.
Funny, SICP isnt on the list. It's always mentioned in these list, and it's probably one of those books that everyone recommends, but no one has ever read.
Yeah, I think they recommend it for the "lispier than though" attitude, it's good if you want to learn Scheme/Lambda Calculus, but it's nothing a "wow" book (maybe if you're programming for the 1st time it is?)
Since a majority of programming today is still done object oriented, I'd pack "Growing Object Oriented Software Guided By Tests" on the list, simply because it teaches you what object orientation actually is and how to apply it. I feel that most of the hate against OOP would vanish if the knowledge in this book was shared and applied.
I got through this book and found myself nodding in agreement with many of it's observations and recommendations, but I'm not sure it completely sunk in (despite the examples) the such that I would be able to synthesize the same results myself. I'm considering a second reading which might be more fruitful now that I know what's going to be said, and could concentrate harder generalizing the details.
Maybe it was in fact the such extended example that threw me off.
Also, slightly worried that this style could lead to an object soup?
Any suggestions for a pragmatism-oriented functional programming book? It seems like a lot of inspirational/philosophical books on software development processes and patterns can't shake the object-oriented examples, even when they try to be as general as possible.
While the preamble said something along the line of "these books are valuable for 'enterprise' dev situation', I find that a lot of ideas from those books are fully applicable to startups/hot-tech-companies.
Release It! => applicable
Continuous Delivery => applicable
Effective Java => absolutely IF you use Java (see other 'effective' series such as Effective C#, Effective C++ [_the_ grandfather], Effective JavaScript)
Patterns of Enterprise Application Architecture => Guess where Rails come from? (hint: DHH name is also mentioned somewhere in the book)
I would like to recommend the clean coder books on the list.
They really saved my butt when I was fresh graduate.
I wasn't sure how the whole business software cycle works or how to communicate effectively with other people in the company, like my team, and the business analysts and CTO.
Those books saved my butt, I don't know where I'd be in my career with out them.
This is a pretty good list. Domain-Driven Design is definitely deserving of the list. It probably impacted me more than any other (I work on complex business applications).
Surprised that Coders at Work hasn't been mentioned yet. Reminds me of Gigs a bit if anyone remembers that one - just long form interviews without the filler.
The thesis is that if good software, projects and teams are noted for using good patterns, then bad versions of any of the above will be marked by bad patterns, and one won't have the other. This can also be a lot more useful in practice, since we seldom get complete greenfields to play in, and therefore antipatterns with prescriptions to fix them more often match what we find in the real world.
I note there are a number of other antipatterns books; this was the original, and now seems to be back in print without needing any changes are updating.
[+] [-] shubhamjain|11 years ago|reply
I kind of believe that, have I not read the book, I would have stumbled upon the ideas later anyhow, by reading blogs, tinkering, and making mistakes. Albeit, it is wrong to expect any magical words that can shift your direction completely, but still I am not sure how much value do printed ideas provide vs learning them by experience. I am not implying that books like it are futile but I don't buy that they are "career-changing".
Same goes for reading about Design Patterns. I believe it is better to learn "Design Patterns" by building and reading code and finding a certain code organization better for your use-case, rather than enforcing a kung-fu-singleton-ninja pattern where it might be simply an over-engineering.
[+] [-] bphogan|11 years ago|reply
Therein is the career-changing aspect. Yes they seem obvious now, but you had a roadmap for your learning. That is why it, and many of the other books, are career-changing.
:)
[+] [-] gravlaks|11 years ago|reply
I read the Pragmatic Programmer last year, and it was .. very boring. Most of the tips were like "doh, of course". It's a beginner's book, not for someone who have been trying to improve their code (and processes around it) already for some years.
[+] [-] gfodor|11 years ago|reply
The Art of Doing Science and Engineering
How to Solve It
Anything by Tufte
The Millionaire Fastlane (terrible title, brilliant book)
and since I'm in VR, I have to mention Ready Player One.
[+] [-] Stratoscope|11 years ago|reply
Here's an odd one of mine:
The Trachtenberg Speed System of Basic Mathematics
I checked this out from the Scottsdale library when I was 11. I'd learned all the usual algorithms to multiply and divide and do basic arithmetic, but like most kids, I assumed that those were the only ways to do those things - that the steps we learned were truly fundamental and the one and only way to get the result.
Then I read Trachtenberg and learned that there were other procedures you could use to get the very same results. The techniques we'd learned were not the only ones!
Oh, there were tradeoffs - you might have to remember more stuff and more special cases - but once you had those down you could zip right through a calculation that would have taken a long time otherwise.
So that's how I learned that there was more than one way to do it.
[+] [-] nemesisrobot|11 years ago|reply
[+] [-] geoelectric|11 years ago|reply
First, I became less of an asshole.
Second, I learned to not work for assholes.
Third, I learned that if I do choose to work for an asshole as a trade-off, I own that choice. I'm never trapped.
My job satisfaction has gone way up for those three improvements.
[+] [-] dwarman|11 years ago|reply
[+] [-] santaclaus|11 years ago|reply
[+] [-] Erwin|11 years ago|reply
The same cannot be said for TAOCP, but it certainly looks very good on a shelf. Practical usage? Limited. You don't need Knuth to learn basics of time complexity.
[+] [-] dwarman|11 years ago|reply
Hoping for Moore's Law to save your performance is not the way to do things.
Knowing about what goes into an ISA, about how operations map onto the hardware, about cacheing, memory virtualization and architectures, about in-order and out-order execution, multi-processor scheduling and synchronization, communications basics (on top of which all other protocols are built), distributed processing gotchas, etc etc, all play their part in writing efficient and effective code wherever.
Languages are tools, all are Turing Complete and can do no more than any other; which to choose for any function is a matter of convention and convenience. And what coding style to use is convention, and how to integrate with other programmers, how to manage projects, "Best Practices" and Patterns, all are conventions, and the degree to which they make the difference is a function of the quality of the involved programmers abilities, not a function of the style chosen. Hence my characterization of all the above as "Elaborations and Decorations". Most of the earlier hardware list also fit into that characterization, but the idiosyncrasies of each ISA and core architecture can have enormous impact on the final products' performance and need proper attention.
It is sad that after 50 years in the business I still know how these things work, and how to make them sing. It should not be so. But the technology has only gotten smaller and faster and has more immediate storage available and faster I/O and more elaborations and accelerations. No fundamental changes. Not that it doesn't blow my mind every so often, that what was a mere pipe-dream in the 60's is today mundane, or even so ubiquitous its underpinning have faded into the background. But it was pretty much already all down on paper in the 60's, just waiting on the capacity of technology SOA to catch up.
The list presented contained very little if any fundamentals. And without the fundamentals, the knowledge garnered is rote, founded upon shifting sands. Thus, I posit the books from which one learned those fundamentals should occupy top place in any such list. The knowledge garnered shapes every future thought on the subject, shapes every problem solving approach, shapes how you think about computers and computing at an internalized level.
In 50 years of commercial (if not commerce per se) experience (and continuing), every hire I've had the pleasure to work with has them, and every hire that frustrated and produced bad, unreadable, buggy, and inefficient code, did not.
That we have today billions of transistors in the space once occupied by one, and clock cycles thousands of times higher, and communication rates trillions of times higher (potentially anyway), is no excuse for not understanding how it all fits together. Today we need to do more with what we have, and so resources are always limited. Possibly a derivative of Parkinson's Law at work. Instead all too often I see bloat and the hope that tomorrows' machines will fix things. Tomorrow never comes, it seems.
As IIRC Piccasso (Dali?) is reputed to have told one young hopeful: "Come back to me when you can show me you can draw a straight line. Then I might believe those squiggles mean something".
[+] [-] zgm|11 years ago|reply
Pragmatic Programmer fills in the gaps you need to succeed as a professional programmer.
Code Complete is a field guide to managing software complexity.
[+] [-] LoSboccacc|11 years ago|reply
I'd also add the mythical man month. being a programmer is good, but overspecializing as the technical guy cause a certain degree of blindness to other software requirements (cost, time, quality). some part of that books can't really work in today work environment because external constraint, like the surgical team, but every word of it is gold.
[+] [-] raverbashing|11 years ago|reply
This is a very good reason I'm not inclined to read his books (and if they're like his tweets, really not worth it, for me)
Code Complete OTOH is a nice book, that if it has a fault is that of "not taking sides" and maybe being too generic, but with good advice.
Design Patterns? Yawn
[+] [-] jghn|11 years ago|reply
[+] [-] Avalaxy|11 years ago|reply
[+] [-] raverbashing|11 years ago|reply
[+] [-] emsy|11 years ago|reply
[+] [-] platz|11 years ago|reply
Maybe it was in fact the such extended example that threw me off.
Also, slightly worried that this style could lead to an object soup?
[+] [-] saosebastiao|11 years ago|reply
[+] [-] efuquen|11 years ago|reply
http://www.amazon.com/Functional-Programming-Scala-Paul-Chiu...
I would consider it an updated and more practically minded version of SICP, which is of course amazing as well but not the sort of book you asked for.
[+] [-] smikhanov|11 years ago|reply
Many people consider it essential reading similar on its importance to SICP.
Re the original poster's list: most of those books are terrible, in my opinion.
[+] [-] sukilot|11 years ago|reply
Effective Java (!) may be a contender, as it teaches about avoiding mutable state, composition over inheritance, etc
[+] [-] rurban|11 years ago|reply
[+] [-] santaclaus|11 years ago|reply
[+] [-] zgm|11 years ago|reply
[+] [-] edwinnathaniel|11 years ago|reply
Release It! => applicable
Continuous Delivery => applicable
Effective Java => absolutely IF you use Java (see other 'effective' series such as Effective C#, Effective C++ [_the_ grandfather], Effective JavaScript)
Patterns of Enterprise Application Architecture => Guess where Rails come from? (hint: DHH name is also mentioned somewhere in the book)
[+] [-] MollyR|11 years ago|reply
[+] [-] zo1|11 years ago|reply
This post almost seems to be turning out to be an AskHN, with everyone chiming in on their 'career-changing' programming books.
[+] [-] henrik_w|11 years ago|reply
[+] [-] mimighost|11 years ago|reply
My then college director's comment on this book is very insightful and might be some of the highest you can ever endorse a tech book.
"Worth a second read"
[+] [-] blake_himself|11 years ago|reply
[+] [-] slantedview|11 years ago|reply
[+] [-] johnsmth|11 years ago|reply
[+] [-] hga|11 years ago|reply
If this is true, then no such list is complete without the Antipatterns book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (http://www.amazon.com/AntiPatterns-Refactoring-Software-Arch...).
The thesis is that if good software, projects and teams are noted for using good patterns, then bad versions of any of the above will be marked by bad patterns, and one won't have the other. This can also be a lot more useful in practice, since we seldom get complete greenfields to play in, and therefore antipatterns with prescriptions to fix them more often match what we find in the real world.
I note there are a number of other antipatterns books; this was the original, and now seems to be back in print without needing any changes are updating.