The One Piece of Advice I'd Give Juniors

I'm coming up on my ten-year anniversary as a software engineer, so I've been looking back at my path so far. If I could give a junior only one piece of advice, it would be this:

There are a million ways to create quality software. Find one you enjoy and keep getting better at it.

That doesn't mean you should ignore your team's standards or skip the boring parts. It means treating advice about how to work as something to continuously test, rather than a set of rules you have to adopt.

Best Practices Are Mostly Other People's Opinions

Over the years I've tried plenty of supposed best practices: test-, spec- and domain-driven development, pair programming, mob programming, scrum ceremonies, and more. I've taken something useful from most of them. I've rarely wanted the whole package. The useful part is often a set of small ideas you can apply without adopting the surrounding process, or paying for a certification.

What I Kept

This is my list, and yours should look different, that's the point.

• Spec-driven: I like discussing the design of bigger features with peers up front. It rules out the completely wrong decisions early and spreads the knowledge across the team.
• Domain-driven: Ubiquitous language is genuinely useful. I'm less convinced by the layers of tactical patterns that can grow around it. I've seen teams spend a lot of effort preparing for a future database change while making everyday changes harder. If that migration ever comes (and in enterprise, that is a very, very big if), the mapping layers may be the least difficult part to adjust.
• Test-driven: I adore end-to-end tests with Testcontainers, but I've never been a fan of strict TDD. I have also never seen a single engineer take it to the gospel extreme of test first, red, green, refactor.
• Pair and mob programming: I always hated it. I'm up for discussing the direction throughout a feature, but when I'm on my keyboard, I want to listen to music and be in the zone. And I certainly don't want to watch someone navigate their idea with a mouse.
• Scrum ceremonies: Where do I start? Having full-time employees work as scrum masters was an embarrassment, and putting someone between developers and users is a sham. A weekly check-in and prioritization, Kanban style, is all a somewhat experienced team needs. As a junior at a consultancy, I was told it would be good for me to do a scrum certification to progress to the next level. Looking back, that seems incredibly laughable. Why should an engineer do this? How did we end up in a place where this became a thing?

Agents Are Changing the Trade-offs

Best practices have always been trade-offs that depend on context, and agents are changing that context fast.

Take DRY. Avoiding duplication makes sense when two places must always change together. But extracting every similar-looking block into a shared abstraction can make code harder to understand and change. Repeated implementations can also give an agent useful examples: it can see the pattern, follow it in a new place, and help update existing copies when the pattern changes. That makes some duplication more valuable, and less costly, than the rule of thumb suggests.

The same goes for reviews. A lot of review time used to go into nitpicks an agent now fixes before anyone looks, and that time can go into the decisions that matter. That doesn't mean review and tests stopped mattering. As I wrote in a recent post, verification matters more than ever.

Enjoyment Is the Best Predictor

The biggest indicator of a successful engineer I've seen is how much they enjoy the process of creating software and the time they spend in the chair. If you enjoy it, you spend more time on it, and over the years that adds up.

The engineers I've learned the most from enjoy making things. They show up with an experiment, a tool, or a better way to explain a problem. Process discussions have their place, but they shouldn't become a substitute for trying something and seeing whether it works.

As a junior, you won't always get the most exciting work or much say in the team's direction. Ask for more responsibility anyway. Bring a small prototype, a clearer explanation of a problem, or an improvement you can show someone. Expect pushback from seniors and listen to it: every line of code creates work for someone later. You'll learn that trade-off faster by making things and discussing them than by waiting for permission to become experienced.

Comfortable, but Volatile

Software engineering is comfortable work in many ways, but it changes constantly. You'll spend parts of your career learning things that later become less useful. Enjoying the process of learning makes that easier to sustain.

Scary, but Liberating

I know the current state is scary when you're just starting out. Everyone seems to have an opinion on whether there will still be jobs for juniors in a few years, and none of them sound reassuring.

But it can also be liberating. Most of the knowledge I spent years collecting just became obsolete, which means you're not as far behind as you think. Some fundamentals stay true, but the way we develop software will completely change, and nobody has figured it out yet.

And there will be an incredible amount of work to do. Just look at PHP2Shell, two critical PHP flaws that leaked this week before the patch was out. This will keep happening, faster and more often, and every one of them needs people who understand the system well enough to build the countermeasures.

Own Your Process

Try the practices people recommend. Keep the parts that make your work better, and let go of the rest without feeling guilty. In a team, honor what you've agreed to do together. Outside those agreements, you still get to choose what to explore, how to learn, and which tools make you want to sit down and build.

Learn in the most chaotic way possible that you can sustain.