Career-Changing Programming Books(nomachetejuggling.com)
nomachetejuggling.com
Career-Changing Programming Books
http://www.nomachetejuggling.com/2014/02/05/top-10-career-changing-programming-books/
49 comments
You were inspired.
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.
:)
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.
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.
> 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.
Yes -- a beginner's book for someone starting now, but essential for everybody in the industry nonetheless.
Pragmatic Programmer has influenced enough people that it has changed the industry for better. These ideas and practices may sound common sense now, but were not until popularized -- I suspect -- by Pragmatic Programmer. If you found good practices already entrenched in the ecosystem when you joined the industry, the roots can be traced back to a few good books such as Pragmatic Programmer. Even though these ideas may not have been ground breaking, nobody now needs to spend time convincing their peers about these practices from first principles. Time and energy saved for everyone.
My point is, I have seen enough [senior] programmers to whom clean code etc. does not come naturally, and they always benefit from reading this book. Not that they aren't smart, just that someone needs to present a good case which this book does very well.
Yes -- a beginner's book for someone starting now, but essential for everybody in the industry nonetheless.
Pragmatic Programmer has influenced enough people that it has changed the industry for better. These ideas and practices may sound common sense now, but were not until popularized -- I suspect -- by Pragmatic Programmer. If you found good practices already entrenched in the ecosystem when you joined the industry, the roots can be traced back to a few good books such as Pragmatic Programmer. Even though these ideas may not have been ground breaking, nobody now needs to spend time convincing their peers about these practices from first principles. Time and energy saved for everyone.
My point is, I have seen enough [senior] programmers to whom clean code etc. does not come naturally, and they always benefit from reading this book. Not that they aren't smart, just that someone needs to present a good case which this book does very well.
Its ideas have 'leaked out into the culture'. I doubt it was all so obvious when it first came out.
> I read the Pragmatic Programmer last year, and it was .. very boring. Most of the tips were like "doh, of course".
Context: it was published in 1999.
Context: it was published in 1999.
A few of my top non-programming books that have had a major impact on my career:
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.
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.
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.
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.
Maybe! Thanks for the rec, might be a nice companion to the ideas presented in how to solve it.
+1 for The Trachtenberg Speed System of Basic Mathematics. I remember learning that system decades ago, and have always kicked myself for lending my copy of the book. I never got it back, and have stopped lending any books I value no matter who.
Funnily, after applying the Trachtenberg system for many years, I came to realize the traditional methods were pretty good too.
Funnily, after applying the Trachtenberg system for many years, I came to realize the traditional methods were pretty good too.
'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.
One of the non-technical books that changed -my- career was The No Asshole Rule.
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.
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.
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.
SICP is amazing. The only bad thing I can say about it is that since it was my first CS textbook in college, it naturally became my measuring stick for "good CS book", which has nearly ruined most of the CS books I read.
I can't say enough good things about SICP. I'm currently working my way through it, and it's such a joy. Watching Prof. Abelson and Sussman's recorded lectures from the 80's is equally enjoyable because they're such good lecturers; thought-provoking and engaging.
Having recently revisited SICP, I am not nearly as impressed anymore as I used to be when I worked through it as a teenager. It aged badly (or perhaps, I outgrew it).
[deleted]
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.
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".
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".
This is a misguided ramble. TAOCP is a comprehensive reference of computer science, and archive documentation. It isn't meant as a textbook to read through. Nearly no one has read more than a few pages.
At the time it was a revelation. And I did too read all. I guess I'm no-one then, by your standards. I'd warrant you never read a dictionary in your childhood either.
No-one. Well then. Creds are perhaps in order.
So, now - 50 years experience, still working, very senior level tech equivalent to management, hardware and software designer from transistor days through graphical programming platforms. I started at the bit level and grew from there alongside the technology, all the way. Still surfing it.
At this age I think that stands for something. If I were no longer working or able to cut it you might have a point, but I've never got a job by sending in a resume - always by reference. I am still a valuable player today. My paycheck tells me that. Stuff in the field tells me that. Everyone I've ever worked with tells me that - and back it up with investment and salary. Two industries know my name (Datacomms and Music). To my surprise I built up a solid rep and no longer need to keep quiet abut stuff.
Consequential emergent philosophy of the Art.
I also think there's a difference between a ramble and an attempt at linearizing a parallel multi-dimensional thought. English is not good for this. Nor does ADHD help.
Knuth's works are also a multi-dimensional parallel linearization. Similar to though differently presented than Minsky's Society of Mind. Though they are both far better than I at doing that. The value comes after internalizing them, where your mind rebuilds the multi-dimensional structure and the interconnections become useful.
This might come as a surprise, but programming is also a multi-dimensional, parallel, multi-threaded mental activity. Internal knowledge organization of similar form is essential. It is fractal too, no depths too detailed or un-needed, no heights irrelevant, all present at the same time.
If you disagree about the need to know the fundamentals, well, good on yer, but you limit yourself. Tell me how it went when you are 67.
No-one. Well then. Creds are perhaps in order.
So, now - 50 years experience, still working, very senior level tech equivalent to management, hardware and software designer from transistor days through graphical programming platforms. I started at the bit level and grew from there alongside the technology, all the way. Still surfing it.
At this age I think that stands for something. If I were no longer working or able to cut it you might have a point, but I've never got a job by sending in a resume - always by reference. I am still a valuable player today. My paycheck tells me that. Stuff in the field tells me that. Everyone I've ever worked with tells me that - and back it up with investment and salary. Two industries know my name (Datacomms and Music). To my surprise I built up a solid rep and no longer need to keep quiet abut stuff.
Consequential emergent philosophy of the Art.
I also think there's a difference between a ramble and an attempt at linearizing a parallel multi-dimensional thought. English is not good for this. Nor does ADHD help.
Knuth's works are also a multi-dimensional parallel linearization. Similar to though differently presented than Minsky's Society of Mind. Though they are both far better than I at doing that. The value comes after internalizing them, where your mind rebuilds the multi-dimensional structure and the interconnections become useful.
This might come as a surprise, but programming is also a multi-dimensional, parallel, multi-threaded mental activity. Internal knowledge organization of similar form is essential. It is fractal too, no depths too detailed or un-needed, no heights irrelevant, all present at the same time.
If you disagree about the need to know the fundamentals, well, good on yer, but you limit yourself. Tell me how it went when you are 67.
As a recent graduate, I cannot recommend Pragmatic Programmer and Code Complete highly enough.
Pragmatic Programmer fills in the gaps you need to succeed as a professional programmer.
Code Complete is a field guide to managing software complexity.
Pragmatic Programmer fills in the gaps you need to succeed as a professional programmer.
Code Complete is a field guide to managing software complexity.
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.
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.
Yeah, it seems to me most Uncle Bob fans throw all common sense out of the window and start following him blindly in all his extremist opinions
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
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
GoF came to symbolize everything which went awry with OOP for me
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?
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?
A fellow developer told me he worked the presented project along with the book and it greatly helped him to understand the content. I plan to do this myself one day.
I'm not afraid of object soup because first, the alternative is implementation soup, with methods that span several tens or hundreds of lines. There is little abstraction of high level concepts. Also it depends on the organization. I keep everything cohesive and organized in packages (or namespaces). With Maven, Gradle or most other build tools, you can even divide your application in Modules that don't know each other. If they need to communicate, they may use a common Message Bus, that is a separate module. Another advantage of this is that this makes it easier for you application to run distributed if desired.
I'm not afraid of object soup because first, the alternative is implementation soup, with methods that span several tens or hundreds of lines. There is little abstraction of high level concepts. Also it depends on the organization. I keep everything cohesive and organized in packages (or namespaces). With Maven, Gradle or most other build tools, you can even divide your application in Modules that don't know each other. If they need to communicate, they may use a common Message Bus, that is a separate module. Another advantage of this is that this makes it easier for you application to run distributed if desired.
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.
Functional Programming in Scala would be my suggestion:
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.
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.
How To Design Programs http://htdp.org
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.
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.
Pragmatism and Functional programming are not bedfellows.
Effective Java (!) may be a contender, as it teaches about avoiding mutable state, composition over inheritance, etc
Effective Java (!) may be a contender, as it teaches about avoiding mutable state, composition over inheritance, etc
Cannot agree at all with this list.
For me it was:
* SICP
* Antipatterns
* Bentley Programming Pearls
* Sedgewick Algorithms
* Stevens Advanced Programming in the UNIX Environment
* Knuth TAOCP
* Tanenbaum Computer NetworksNo mention of Code Complete? That book is baller.
+1. This book is a goldmine of good coding practices.
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)
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.
For me, I think the biggest one was Refactoring by Martin Fowler, which you can find here: http://refactoring.com/
This post almost seems to be turning out to be an AskHN, with everyone chiming in on their 'career-changing' programming books.
This post almost seems to be turning out to be an AskHN, with everyone chiming in on their 'career-changing' programming books.
+1 for Clean Code. I just recently read and reviewed it: http://henrikwarne.com/2015/01/03/book-review-clean-code/
Would love to add CSAPP into the list.
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"
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"
'CSAPP' = ?
I think the OP means "Computer Systems: A Programmer's Perspective" http://csapp.cs.cmu.edu/
Yup, most likely it's the one. It's very deep and well-written book, though too focused on x86 and Linux. Though, to be fair, trying to cover widespread alternatives with the same depth would require seveal thousand pages.
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.
"No list like this would be complete without a book about design patterns."
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.
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.
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.