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 didn't start.
The lesson I took is to break work into the smallest independent pieces I can.
If I'm building something new, that shapes it from the start: each step stands alone, and I can ask of every step, what happens when this fails and I need to run it again.
You won't often be building new, though.
Mostly you're looking at something that already works this way.
It is extremely unlikely you will be granted time to rewrite it. "Give me three weeks and at the end it'll work exactly as it does now, only more reliably" is not an argument many businesses say yes to, and they're not wrong to refuse.
So I stopped trying to win that argument and started doing the smallest useful thing instead.
Draw the process out on paper, find the seams.
Add logging at the boundaries so that when it breaks you can see it got to step three and no further.
None of that needs permission, and each small thing makes the next one easier to justify.
Pick the easiest fix that improves your own life first, not the biggest.
You're the one living with the system day to day, and anything you make better for yourself is better for whoever comes after you.
You can't predict the change, only leave room for it A system gets built around what's true today.
A rule that had held since day one stops holding, and suddenly the code is full of special cases for the one thing it was never shaped to do.
You can't fix this by predicting harder.
Try to build for every future you can imagine and you just widen the surface you'll get wrong, because the real requirement always turns up different to the one you guessed.
What you can do is notice where change actually tends to come from.
Reliably, it's two places: anywhere the requirements are still being argued over anywhere you depend on someone else's product or decision Those are the edges.
Keep them at arm's length from the core, so the thing the system fundamentally does doesn't know or care what's bolted to it this month.
Retrofitting that is, again, a matter