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.