Having read it a few times since I think it falls into the same group of books as Mythical Man Month, Peopleware, and the Pragmatic Programmer where the earlier in your career you read it, the more you'll get from it.

Reading these books after 20 years of programming I found that I really struggled to find anything useful to take away from them.

It's not that these books are bad, or out of date. It's more that they exposed some new ideas at the time that, to the books credit, have been picked up and made mainstream or basic/required knowledge for the working programmer

What books do you recommend though to get novice (or not so novice) programmers up to speed? IMO there is a lack of modern literature and general introductory material to the kind of wisdom you otherwise only get after decade(s) of software development (if at all, for quite a number of people).

A recent one I liked is “A Philosophy of Software Design”, but it only covers so much ground, and some of its advice requires further qualification.

I believe this is the highest compliment a book can receive. When reading it the first time makes a big difference and the second time doesn't, it means it was so well written that you internalized it completely.

I wonder what Steve would think of it. I didnt even know about "More Effective Agile", maybe it'll tell me.

You forgot 'SQL' (or broad 'data management and access'), as well as security and performance stuff in your list above.

I don't want to be a 'stick in the mud' but.. I also resist some of the newer/shinier things, precisely because they don't always stick around (and I've been burned). But also, I don't really have time/bandwidth to be an expert. Doing server mgt, security, etc half-assed, by just following a couple of readmes... that can lead to lots of trouble.

It is not overly opinionated, it is direct, it tries to support the statements it makes.

It does not tell you a great story or tries to play you. It is what it is. And still it's a great reference.

It's the anti-Uncle Bob, which tries to manipulate you and convince you of his way being the best way.

http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html

That insight helped me calm down quite a bit. Because noobs are being produced faster than best practices can percolate. Per Mark Twain's quip about lies racing half-way around the world before truth can get its pants on, every generation thinking they invented sex, and how people are generally emotionally attached to their first notions (no matter how wrong).

(So if your introduction to computing is thru Python, PHP, JavaScript or whatever, it's super hard to see their flaws, or to appreciate what their precedents were trying to achieve.)

Instead, if I start with an opinion, I'm able to make immediate progress even if I end up refactoring down the road for some reason or another.

Of course there's no single write way to organize projects and write software. But one mediocre way that makes sense to me right now is often preferable to 10 better ways that I don't yet understand.

Clean Code has a narrative and is opinionated. It explains the experiences that formed those opinions. It is a better read.

Code Complete is dry, academic, and comprehensive for its scope. It references many studies and is well documented. It has opinions too of a sort. It is a better reference.

Thinking of function length - Clean Code says short functions are good. Code Complete references studies that say it is not long functions that are bad, it is functions using too many objects/variables that are bad. This of course has an indirect effect on function length. So I keep this in mind, and both books are helpful.

I read a bunch of Uncle Bob's books and usually don't mind him being opinionated, although I did think the opinions in Clean Coder got to be too much. Although not all of it. Recently I have been mulling the idea from that book that there should be zero regressions. I think there is something to that, if you start to accept there can be 2-3 regressions per sprint, then why not 5-7? Why not 10? I agree with him that acceptance of regressions is a problem.

Totally. I appreciated that he actually cited actual studies of commercial software projects, such comparisons of defects found in code reviews vs tests or defects vs function length.

This seems a fairly common refrain in the comments. Am I the only one who forgets things? I have to reread things to keep the ideas crisp in my head.

Oh well!

I've got to remember to revisit it soon.

I've never been under the impression that he figured it all out on their own, or that they captured the end-all, be-all of how to make software. Some of the things he wrote about have evolved tremendously over the years. But I still get incredible value of revisiting those books and reinforcing better engineering practices and habits he evangelizes.

For some reason, I've been noticing this mistake more and more lately.

If you say you "couldn't care less" then you don't care at all, and that's what you are trying to point out (This is the correct version of the phrase, for how it is used in every case I can think of).

Saying you "could care less", means you do care, at least a little (as Weird Al points out in the "Word Crimes" song). Again, in the places where I hear people use one of these phrases, they always mean they don't care at all, and are trying to emphasize that.

Only "I couldn't care less" makes sense for that meaning.

When the phrase you are using quite literally (hehe) means the opposite of what you mean, that's just abuse of the language. Unless, of course, you are trying to be sarcastic (which is never the case with saying "I could care less").

I feel the same way about literally/figuratively, and at least figuratively (hehe-2) roll my eyes on that one regularly.

Mostly, Code Complete is a model for how to think about thinking, a self examination, how to do introspection.

A current superior example of this strategy is Dan Luu. IMHO.

Does anyone have any books they recommend for senior engineers (approx 10 years experience)?

Perhaps it's harder to recommend one book because by that time generalized knowledge should already have been absorbed.

Someone who writes a book with pragmatic advice, based on real life research, focused on delivering projects quickly, on time, and with few defects?

Instead it feels like almost all the writing in software is evangelizing.

I'd suggest anything and everything written by Gerald Weinberg, starting with what looks most appealing to you now.

'Making Software', edited by Wilson and Oram is chock-full of the latest research of its day (10 years ago.) It's dry, but it presents work of some top SE researchers. Following that group on twitter/Google scholar would bring you to the edge of what is studied in SE research.

Yes. Old but gold. Brian Kernighan. Jon Bentley. Google them and their books.

*I have no association with him whatsoever.