To be a Senior Engineer, You Have to be a Productive Junior Engineer First

Product teams rely on software engineers in individual contributor (IC) roles to consistently produce high-quality code. As part of a team—in the real sense of the word, not just an arbitrary group of people assigned to the same project—IC engineers are expected to play their part by performing at a high level.

On a product team, non-engineers often manage significant ambiguity, negotiations, and complexity, partly so engineers can focus on the implementation of what is clear. Arguably, much of the agile process is designed to set up ICs for success. For example, it clarifies and spoon-feeds tasks, maximizes "maker time," strives to unblock people, etc. As a result, when ICs are producing, it's easier for other team members to focus on their contributions to shipping features and completing sprints—leading to a well-oiled machine for uncovering and meeting user needs.

In this post, I will describe strategies a junior engineer in an IC role can apply to be more productive, leading to a faster rate of personal advancement.

As an IC, particularly when working on a hybrid or fully remote team, it's natural to question the agile process or experience burnout occasionally. IC work can be routine, with some stories presenting challenges or novelty, but many similar to past work.

Engineers may sometimes attempt to make their IC work more interesting, but doing so can harm the team and product delivery. Examples include introducing new approaches to an older code base based on personal preference or complicating the architecture of a product without a clear benefit.

Rather than trying to make the code more interesting, a better approach is to take an interest in improving individual work styles. For instance, if a 1 pull request (PR) per day approach has been adopted, each day, the focus can be on how to complete a user story or a mergeable unit of it. By setting the goal of getting a PR merged, one can work backward to consider what tactical decisions can be made to increase the likelihood of reaching that daily objective.

Outside of the benefit to the team, users, and stakeholders, being an IC has unique benefits for the engineer that appeal to many people (including myself). However, it is also a stepping stone to other related roles, such as tech lead, architect, engineer manager, and even product manager, which focus less on direct code output.

I see the key benefits of IC work as follows:

• lucrative pay
• being a part of a team where people challenge and support each other
• growing as a team member in non-technical areas such as communication, problem-solving, and time management
• creating work that you can be proud of
• using repetition as a strategy to gain higher fluency and mastery
• gaining subject matter expertise in the area of the product
• being a practitioner in a setting where people care about results

Re: being a practitioner, this point can't be emphasized enough. In life, personal growth happens in situations that are hard; nobody ever improves by being comfortable. In this context, working as an IC will often be challenging for an engineer at an early stage in their career who wants to ship features and hates being the cause of an unfinished sprint. This will drive them to find ways to block out distractions, plan better, and write one more line when they feel like giving up. Over time, compound interest in these small personal improvements can lead to significant progress and even potential that a person didn’t realize they had.

In my experience, five core tenets lead to thriving as an IC on a product team; they are:

• No uncertainty
• Smallest possible units
• My plan
• One task
• PR per day

No uncertainty means you must understand precisely what is expected before starting work.

• This sometimes means re-reading the description multiple times until it sinks in.
• If there is an unfamiliar term, look it up.
• Exploring the product as a user when a story comes up about a product area you haven’t used.
• Exploring the code of an unfamiliar area to the best of your ability before asking another engineer
• If the item's creator needs to include sufficient details, you ask them to do so.
• Sometimes it feels embarrassing not to understand what might appear to be a simple user story, but it's way better to ask early than to build the wrong thing due to guessing.

The topic of the smallest possible units is about moving quickly through the software development lifecycle.

• The harm of misunderstanding a user story is reduced when the implementation is minimal.
• PRs are easier to complete when their scope is small: less code, fewer tests, and faster reviews.
• If a user story should be multiple stories, ask to split it. By critically thinking about what the user story describes, you might notice that it implies work that could be split at the conceptual level. For example, a user story might cover authentication, forgotten passwords, and logout. The could easily be three separate user stories.
• Create separate targeted engineering tasks if a user story implies multiple high-level elements. If the concept can be split, but the work is easily split, replacing the user story with multiple engineering tasks is possible.
• If you are thinking about adding something to your PR or doing some refactoring—don't—just create an engineering task and move on.
• Create a PR that makes the least changes while satisfying the requirements.

My plan describes a detailed personal checklist (not shared with the team) of the steps required to complete a user story, engineering task, or individual PR.

• The list and its items are not shared or estimated, it is more granular than an item in a project management tool.
• It shows if there is uncertainty, as when there is, it's hard to create a plan.
• Combats procrastination/anxiety because while a user story may seem daunting, the current step is not. When you make incremental progress by focusing energy on the current step, getting the entire PR done takes care of itself.

One task in this context means picking up other work only if you finish your currently assigned tasks or are blocked.

• Picking up a new task when the current task gets complicated or tedious may be a dysfunctional avoidance. It is usually best to face the difficult task head-on.
• Only pick up something new if you are externally blocked. In that case, pick up something new; it doesn't help your team to be doing nothing.
• Pretending to work on multiple tasks simultaneously (you can only work on one at a time) gives the illusion of progress, while in reality, very little gets completed. This is one of those "you are only fooling yourself" situations, as an agile board is transparent, and it is easy to see when a person has three items “in progress” and nothing “done”

PR per day is a device to get you to think about your work differently, so you are more likely to apply the tenets above collectively to produce PRs at a high rate. That said, this is a personal goal and strategy and not something that is always possible to achieve daily.

If a person is trying to lose weight, they might drink a glass of water before each meal to feel full sooner. This is a similar “trick” for someone trying to be more productive in a sprint.

A few considerations:

• The workday starts with a new task and ends with completing that task. This doesn't mean pulling an all-nighter but using tactics to achieve a PR in a day in the available work time when possible.
• A single user story or engineering task can be referenced by multiple PRs; it doesn't have to be a 1:1 ratio.
• Consider the smallest unit of work that is “merge-able,” i.e., a part of a user story that will not cause any harm if it gets deployed ahead of the remaining work of the user story. You don’t want to break your application or provide a bad user experience by shipping incomplete work. That being said, it is often possible to ship many parts of a user story that are unnoticeable to users.
• Work backward from the goal of completing a PR and consider what tactics you could employ to make this goal more achievable.

The tenets described above make IC work more sustainable for me despite the inherent struggles of succeeding in the challenging setting of working on a product team. While I haven’t always applied all strategies, when I have, I achieved better results and was surprised at what the team could achieve.