Reading
These are the books I actually return to, and the courses I have worked through rather than bookmarked. When I mentor someone I hand them a subset of this, in roughly this order.
The ones I recommend first
The Pragmatic Programmer, Hunt and Thomas. The one I give people earliest. Very little of it is about code, which is the point: it is about the habits that decide whether the code you write survives contact with a team.
Code Complete, second edition, McConnell. Long, and worth it. It is the book that answers “why is this function hard to read” with something better than taste.
Clean Code, Martin. Worth reading and worth arguing with, which is most of its value. Some of it I follow to the letter and some of it I have watched teams apply as dogma until the code got worse.
Refactoring, Fowler. The one that gives the moves names, so a code review stops being an argument about preference and becomes two people agreeing which transformation applies.
Design Patterns, Gamma, Helm, Johnson and Vlissides. The Gang of Four book. Dated in its examples and still the shared vocabulary: when I argued for the builder pattern over a procedural mess, this is the argument I was making.
Structure and Interpretation of Computer Programs, Abelson and Sussman. Genuinely hard, and anyone who tells you otherwise has skimmed it. It is not hard because the syntax is unfamiliar, it is hard because it keeps asking you to build the thing you have been taking for granted, and then asks what that means. The only book on this list that changed how I think rather than what I know, and I still do not understand half of it. Anyone claiming otherwise is either lying or teaching it.
Courses
Learn Python the Hard Way, Shaw. The title is the method: type it out, break it, fix it. Unfashionable now and it is still how I pick up a language I have no commercial reason to know yet.
The Ruby on Rails Tutorial, Michael Hartl. I took this while at an agency that was passing database files around by hand. I came back on the Monday and introduced migrations, which is the most direct line I can draw from a course to something I changed at work.
Stephen Grider’s courses. I have worked through most of his catalogue over the years. Good at the thing that is hardest to teach: building the whole thing rather than the interesting part of it.
Laracasts. Years of it. The best explanation of Laravel and of PHP as it is actually written now rather than as its reputation suggests, and the reason the PHP on my CV is not stuck in 2013.
Frontend Masters. Where I go when I want the depth rather than the tutorial: the courses are taught by the people who build the things.
Teach Yourself CS. A curriculum rather than a course, and I am still working through it. It exists because a lot of us came into this by building things first and filled in the fundamentals afterwards. That is my route exactly.
Why this page exists
Most of my career has been spent arriving at somewhere that already has a problem. What travels between those engagements is not a framework, it is the set of ideas above. A CV lists what I have used. This is closer to how I decide.