Career-Changing Programming Books

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 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.

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.

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.

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".

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.

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.

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?

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.

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.

Effective Java (!) may be a contender, as it teaches about avoiding mutable state, composition over inheritance, etc