Can a New Starter Release Code on Their First Day? Ours Did.

On their first day working with us, one of our subcontractors released code to a live client system.

The change went through exactly the same process as every other change we make: the same tests, the same automated checks, the same review. Then it went live.

It's the standard we hold our systems to. It was still nice to see it happen.

The standard

A new developer should be able to make a meaningful change to a system and release it on their first day.

We don't chase that for its own sake. Nobody is handing out prizes for the fastest first release. It matters because of what it proves.

Why day one is the test that matters

Think about what a newcomer has to do to get a change live on day one.

They have to get the system running on their machine. They have to find their way around code they've never seen, and understand it well enough to change it. They have to be confident their change hasn't broken something somewhere else. And they have to get it reviewed and released without anyone holding their hand.

Each of those steps depends on something:

• Getting set up quickly needs a development environment that's scripted.
• Understanding the code needs code that's readable and consistent.
• Being confident nothing else broke needs tests you can trust, and automated checks that catch mistakes.
• Releasing safely needs a release process that's automated and boring.
• Knowing the unwritten rules needs someone to have written them down, or better, turned them into checks.

If any one of those is broken, the newcomer can't do it. If day one works, almost everything else is working.

What it takes

Setting up in minutes

Everything needed to run the system is scripted. Set up your access keys, run one command, and a few minutes later you have a working copy of the whole system on your machine.

There's no setup week, and no wiki page that was last accurate in 2019.

Code that reads the same everywhere

Formatting and style are handled by tools, automatically, to one standard. Every file reads as if the same person wrote it, so a newcomer only has to learn one way of doing things.

It also means code review is about decisions, not about where the brackets go.

Tests you can trust

A newcomer can't know every corner of the system. They don't need to. If their change breaks something three modules away, a test fails within minutes, on their own machine.

That only works if the tests are trusted. We don't chase a coverage percentage. We aim for a test suite where a green run means it works and a red run means something is actually wrong.

The rules nobody tells you

Every codebase has unwritten rules. "Don't call the payment provider from there." "Always get the current date through this class." Long-serving developers know them. New ones find out by breaking them.

So we turn them into static analysis rules. If a change breaks one, the check fails and says why. The rule teaches the newcomer at exactly the moment they need it, and nobody has to remember to mention it.

A second pair of eyes

Every change is reviewed before it goes in, including a newcomer's first one. Review catches mistakes, but on day one it does something more useful. It's a conversation about real code with someone who knows the system, and that's how new people learn fastest.

Releasing is boring

Every change runs through the full set of tests and checks automatically before it's released. If they pass, it goes out.

Releases are small and frequent, so a newcomer's first change isn't bundled up with thirty others. If something did go wrong, it would be obvious what, and quick to undo.

Decisions written down

Code tells you what the system does. It rarely tells you why.

When we make a decision that matters, we write down the reason and what else we considered. So when a newcomer finds something odd, "why is it like this?" has an answer that isn't "ask Dave".

What it's like without it

You've probably seen the alternative.

A new developer spends their first week or two getting set up: installing things, chasing settings, working out which of the three config files is the real one. Every question pulls your one experienced person off their own work. It's a month before the new person is trusted to change anything important.

For a while, adding someone makes the whole team slower.

Why it matters if you're not a developer

If your business runs on software, this is one of the most useful questions you can ask about it.

A system a newcomer can release on day one isn't dependent on one person, and extra help actually helps. It's also a good sign the system is being built for the people who'll be working on it in three years, as well as the people working on it today.

So, if someone new started on your system tomorrow, could they release a change by the end of the day? And if not, what would stop them?