Juniors should optimize for growth, not just productivity

A junior who optimizes only for productivity may get very good at being a junior.

That sounds harsher than I mean it, because productivity absolutely matters. I have always valued being productive, and I do not think junior developers should use learning as an excuse for low output. The point is that, early in a career, output is only part of the job.

You are also learning how to recognize problems, where to look for context, who to ask for help, and how experienced people reason about decisions that are not yet yours to make. Those things are harder to measure than tickets closed or pull requests merged, which also makes them much easier to optimize away.

Productivity is real, but incomplete

Imagine an intern or junior developer saying they are more productive working from home. They may be completely right: there is no commute, there are fewer interruptions, they can focus for longer stretches, and they may well finish their assigned work faster.

If productivity means “how efficiently can I complete the task in front of me?”, working alone may win. The problem is that this is an incomplete definition of progress when you are early in your career.

The more important question is not only how efficiently you can do the work you already understand, but how quickly you are expanding the set of problems you can recognize, understand, and eventually own. Those two things often reinforce each other, but not always, and sometimes the most useful hour of your day does not produce a commit.

You do not know what you do not know

One of the biggest differences I see between junior and senior engineers is not that seniors always know the answer, but that they are better at noticing when they are missing context.

An experienced engineer may look at a problem and think that another team probably owns part of it, that there is likely some history behind the current design, or that they should ask before changing a particular boundary. They may not know the answer yet, but they recognize the shape of the gap and often know where to knock next.

A junior may not.

That is why “ask when you need help” is not enough as a development strategy, because it assumes you already know when you need help. Sometimes the value of being around more experienced people is not that they answer the question you were about to ask, but that you hear a conversation, see a reaction, or get challenged on an assumption that makes you realize there was a question in the first place.

Be a sponge

If you are early in your career, I think one of the best things you can do is be a sponge: talk to people, ask questions, ask for help before taking long strides alone, try to understand what adjacent teams are working on even when their problems do not affect your current ticket yet, and join discussions where you are not expected to make the final decision.

None of this means staying dependent on other people. The point is to accumulate enough context that, over time, your independence becomes more useful.

A senior engineer is not valuable because they can spend longer periods without talking to anyone. They are valuable because they have a larger mental map of the technical and organizational landscape, and because they know when that map is incomplete.

One way I think about seniority is the handoff point. With a junior, you may hand over a well-defined task and still need to stay fairly close, clarifying assumptions, pointing out missing context, and helping them notice when they are heading in the wrong direction. As experience grows, that handoff point moves earlier: instead of handing over a task, you can hand over a problem, and later perhaps only an outcome.

The more senior someone becomes, the less of the surrounding context you need to pre-package for them, because they are better at discovering the missing pieces themselves. That is why exposure matters so much early on: the goal is not simply to make someone faster at executing tasks, but to help them become the person you can hand a messier problem to.

You build that map through exposure.

Some of the useful stuff is accidental

This is one place where remote work can change the equation. I do not want to turn this into an argument about remote work in general; I am very much an office-first person, but that is a different article. The narrower point is that some learning opportunities are incidental, and they can become easier to miss when they are not deliberately recreated.

You have lunch with someone from another team and learn what they have been struggling with, then months later your systems collide and you already know who to talk to. You overhear a discussion about a problem you did not know existed, or someone sitting nearby notices what you are doing and asks a question that makes you rethink your approach. Sometimes there is a five-minute conversation after a meeting that would never have seemed important enough to justify scheduling a call.

These interactions are difficult to put on a roadmap and may have no measurable output that day, but they build context and relationships that make you more effective later.

When most of your interaction happens through Slack and pull requests, those moments become much easier to miss. Even a tiny barrier such as “can I call you?” changes how often a question gets asked, and the bigger issue is not only the questions you decide not to ask, but the questions that never occur to you.

I was invited into rooms before I belonged there

When I was a junior, I was brought into design meetings to listen, but I was also allowed to discuss and even challenge decisions. I obviously did not have the experience of the people around the table, and that was exactly why being there mattered.

I got to see how experienced engineers thought about alternatives, constraints, uncertainty and trade-offs. The useful part was not only learning what architecture we chose, but seeing how we got there.

A pull request can show you the decision; a design discussion can show you the judgment behind it.

Someone more senior had to decide that it was worth having me in that room before I was ready to own the decisions being made there, and I think that is part of developing junior engineers too.

Managers need to steer

This is where I think managers have a role. A junior who optimizes for visible productivity is not doing anything irrational, because those are the signals they can see: tasks get completed, pull requests get approved, and velocity looks good.

A manager should have a wider perspective and notice whether someone is becoming very effective at a narrow set of junior tasks or whether they are also expanding their context and judgment. That does not require turning office attendance into a performance metric, nor does it mean forcing juniors into every meeting in the name of development.

It can be as simple as inviting a junior into a design discussion, introducing them to people in another team, giving them work that requires understanding a slightly wider part of the system, or encouraging them to ask questions before disappearing for two days in the wrong direction. Just as importantly, managers can make it clear that spending time learning the surrounding system is not wasted time.

A junior may optimize for today, while a manager should have tomorrow in mind as well.

Becoming senior is part of the work

The responsibility is shared. A junior should be curious, seek context, ask for help and deliberately expose themselves to things outside the exact task they were given, while a manager should recognize that someone early in their career may not yet know which opportunities matter and help create them.

None of this means output stops mattering, and the goal is not to produce less work. The goal is to avoid becoming exceptionally efficient at the level you are supposed to be growing out of.

A good junior should be trying to become a senior, and a good manager should be helping them do it.

This article was produced using an AI-assisted editorial process and was reviewed with AI assistance. Read about my editorial process.

Support this blog

If you liked this article, consider supporting this blog by buying me a pizza!