I wouldn't say that you should read it, that depends on your priorities.

But the truth is that the benefit/effort ratio in that book is pleasantly high. It is very easy to read and it did gave me quite some "Oh! So that is how it works!"

I ordered The Mythical Man-Month a year or two ago. This is something of a blasphemous statement on Hacker News, but for me the book was a letdown. It felt like a rehash of ideas that I already knew from reading Paul Graham's essays, other technical blogs, and comments on Hacker News.

The reality, of course, is that the book was so spot-on and insightful that many of its ideas have simply been absorbed into the way we approach software development. It seems so common sense today that people don't even cite an idea stolen from TMMM.

Unfortunately, this meant that nothing in the book was new to me, and reading it was rather dull. Because of that, if you've spent much time following the tech community, my recommendation is to prioritize reading TMMM below many of your other suggestions.

What you're talking about are _much_ higher level books. They'll make you a better programmer for sure.

This book (probably) won't do that, but it will give you a more intuitive sense of how the machine actually _works_ at its core. This is not meant to be hands on stuff for someone who's programming at your level of abstraction.

Compared to those books you could clear this one out in a few days, and the benefit/effort ratio is probably actually better, although much less directly applicable.

It really depends on where you are. If you've done a CS undergrad program you probably already know everything in CODE. But for a bright high school student or self-taught programmer interested in CS the only book I'd rank higher would be SICP.

yeah, that seems to be accurate. that's the thing about these "best book ever for all software engineers" posts -- anyone reading even just a few industry books a year already knows this stuff.

If ONLY cs undergrads knew everything in code.

I'm still trying to teach some of them that a memory copy isn't instant.

Just trying to teach them that somewhere, down under all that runtime, there's a bunch of hardware which deals with the world 32 bits at a time, and that in the end all these magical "objects" really cook down to a bunch of memory addresses... yeow.

That's what I loved about being in computer engineering. You'll sit there and fill in charts of the cache, perform Tomasulo scheduling by hand, and by god at the end you'll have a pretty decent idea of how the machine does things. Not to say that CS students can't or don't learn the same thing, just that the ones I knew tended not to.

But you don't need all that stuff any more - you have garbage collection !

yeah, but the ones who actually care about CS probably do know most things covered in CODE.