Own the mess you didn't make

There's no shortage of advice on landing your first software engineering role. Portfolios, interviews, which languages to learn. What I found far less of, when I was starting out, was anything on what to do once you're actually in the building. So when The Tech Academy asked me to give a talk at the end of July, mostly to students and people lining up their first role, that's what I talked about. You're joining a system somebody else built, that's live, and that you now have to keep running. None of what follows comes up while you're learning to code. It only shows up once you're standing in front of the real thing. Give the last engineer the benefit of the doubt You will join somewhere and find things that look wrong. You've just spent months learning how it's meant to be done, and the real thing won't match. When that happens it's tempting to say so, loudly, and to wonder aloud what the last person was thinking. Try not to. Every system I've worked on was built by people making the best call they could with the information, the tools and the deadline they had at the time. I've not yet found a bad decision that was made carelessly, and I've made plenty of my own that looked fine on the day and worse a year later. There's a practical edge to it as well. The business doesn't watch individual engineers make individual decisions, it sees engineering as one thing, so when you run down the engineer before you, the credibility you spend is partly your own. The attitude that serves you better is that you're going to inherit systems you didn't build, and owning their flaws is the job. Small failures beat big ones The clearest foundational mistake I've seen up close was a process that had to succeed all at once. It did a large piece of work in a single pass, and any failure anywhere failed the whole thing. At small volumes nobody notices. As the numbers grow the odds of falling over climb with them, and a system that half-finished its work leaves a worse mess than one that d