Software engineers care a lot about being smart and knowledgeable. Conversations about how to become a better software engineer often center around learning more facts: programming language syntax, design patterns, details of how particular technologies work, and so on. It’s also undeniable that having a strong working memory is really useful, if only so you can fit more of a codebase in your head. However, there’s a whole other dimension to being a strong software engineer that doesn’t get talked about as much: character. What do I mean by character? I mean the kind of person you are: the quality of your internal self. For want of a better word, your “virtue” or “moral fiber”. In my experience, people with good character are dramatically more effective software engineers. There are approximately one million books about learning software engineering skills and approximately zero books about software engineering character. It’s a bit unfashionable today to talk about character, for some…

How do projects fail at large tech companies? As I’ve said many times, failure means executives aren’t happy with how the project turned out. At healthy companies, that typically means that a sensible engineer wouldn’t be happy either, because the project didn’t work or users hated it. But what actually causes the projects to fail? I’ve seen a lot of projects go wrong - both up close and at a distance - in the last ten years. Here are the main reasons why. Doomed from the start Lots of projects fail because there’s no way they could possibly have succeeded. In American law, some cases get dismissed at “summary judgment”: even if the plaintiff succeeds in proving everything they aim to prove, it still wouldn’t add up to demonstrating enough illegal activity to win their case. At tech companies, some projects are like that: even if the plan goes off without a hitch, the project is still doomed to fail. Some doomed projects begin with over-ambitious plans. For instance, an executive…

What does it mean to get things done? In the abstract, you can complete a mathematical proof or a problem set, but the real world is much fuzzier. Suppose I plant a tree in my backyard. Once the sapling is in the ground, is that done? Not really. There’s always more work to do: clearing the ground around it, watering, keeping pests away, pruning, and so on. Programming large web applications is more like planting a tree than completing a mathematical proof. Once you write a service, you can keep working on it forever if you want to. In large tech companies, this fact is a trap for competent but unagentic engineers. They see an infinite queue of tasks that they’re capable of doing, and they start delivering a stream of marginal improvements to a particular subsystem. From their perspective, it feels like they’re crushing it. After all, they’re putting out work at their top speed: no downtime, no waiting on other teams. But they’re not doing their actual job, which is to deliver the most…

There’s a brand of tech influencer now that’s all about sharing the perfect prompt for any situation. The tweets in question typically read something like “this prompt will make you superhuman”, or “this prompt will be a 20k growth consultant in your pocket”. There’s a kernel of truth here - it’s surprising how much small alterations in a prompt can affect the quality of language model outputs - but overall it’s just a bit silly. Searching for the perfect prompt is just not how you should be engaging with language models. I’ve believed for a while that getting good at AI is not really about “prompt engineering”. Instead, it’s about getting a sense of what language models are good and bad at, of when it’s useful to continue a conversation with a LLM and when you should back out and start a brand-new conversation, of when to use reasoning models and when not to, of when you can broadly trust the model output and when you need to go over it with a fine-tooth comb, and so on. For instance…

I have delivered a lot of successful engineering projects. When I start on a project, I’m now very (perhaps unreasonably) confident that I will ship it successfully. Even so, in every single one of these projects there is a period - perhaps a day, or even a week - where it feels like everything has gone wrong and the project will be a disaster. I call this the valley of engineering despair. A huge part of becoming good at running projects is anticipating and enduring this period. The start of a project always feels good. I have a clear idea of what needs doing, and there’s plenty of time to do it. The very end of a project usually feels good too - by that point all the important pieces are ready, and it’s just a matter of getting the final tweaks and bugfixes in. The hard part is the middle of the project, when all these things are happening at the same time: You’re discovering that some of the things you thought would be easy are actually surprisingly hard New requirements have come…