Zee Spencer

Getting Past Junior

Junior developers make complex solutions for simple problems.

Average developers make simple solutions for simple problems and complex solutions for complex problems.

Senior developers make simple solutions for complex problems.


I was pairing with a friend of mine who is working as a junior developer. We were reviewing and rewriting some of the code, and he asked "I can see this is better, but how did you know to do it?"


That's a hard question. I mumbled something about "When you've been doing this as long as I have..."

And that's a bullshit answer.

Much of my judgement comes from seeing what has worked and what didn't; yet that's only part of the story. I take several deliberate actions to hone my judgement:

  1. I Write throw-away code
  2. I Surround myself with expertise
  3. I Read. Constantly.
  4. I Turn the knob to 11

Write Throw-Away Code

Whether I'm working on a kata or a breakable toy or even production software; I throw away most of the code I write. Why? Because my first attempt is a poor attempt. I use my first pass as a "spike", a kind of hands-on learning opportunity.

This gives me the freedom to experiment and explore without worrying about adding unnecessary technical debt. This lets me go off the beaten path a bit and try things I never would have if I knew it had to go into production. Sure, some of these experiments are dead ends; but they invariably provide me with more information about how to solve the kind of problem I'm working in.

Safety to experiment is crucial for building judgement.

Surround Yourself With Expertise

While I may think I'm pretty hot shit when it comes to software development, the fact of the matter is that there are thousands of developers with more experience, better judgement, and deeper understanding than I. Add in the sheer breadth of specialities in software and it's pretty overwhelming. And humbling!

I've spent the past 6 years building a network of people across a wide range of specialities. From software testers to interaction designers to operations engineers to machine learning scientists. When I have a problem, I can send off an email or aks a question in IRC or Twitter.

By investing in friendships across disciplines I "outsource" my judgement. This helps me build judgement in a new territory quickly and effectively.

Read. Constantly.

And not just books. Read code. Find small code bases that do specific things and read and annotate them. Find large code bases and skim them. I regularly practice diving into an unfamiliar project and figuring out what's going on.

This builds judgement by letting me see how people I've never even met solve problems. It also builds my ability to understand unfamiliar code.

Not to undervalue books at all. I easily spend $500+ a year in technology books; mostly when I'm learning a framework, language or tool.

Turn The Knob To 11

Turning the knob to 11 is when you take a very specific concept; and over-apply it. Over-applying a technique or technology is the easiest way to find its shortcomings. Want to learn to TDD? TDD everything for a year. At the end you'll have a solid understanding of when to and when not to TDD.

I love turning the knob to 11; but since it is directly intended to discover where something breaks down it isn't always a good practice to apply to production code.

Judgement Makes Perfect

Practice makes permanent, feedback and judgement makes perfect. Reflect on your work. Intentionally seek the edges of your skills. This is how you move beyond junior.

Browse posts about:

Want to get notified when I publish new articles or update old ones? Subscribe to my newsletter. It's a weekly-ish set of interesting links with a short essay on programming, design, technical leadership, or anything else that strikes my fancy.

Not sure? Read the archive.