Understand the purpose of your work

One mistake I’ve seen junior software engineers repeat again and again is their lack of understanding of why they work on tasks they work on. This confusion can be somewhat justified by the relatively small scope junior engineers typically have but it’s a slippery slope. Doing something only “because my manager (or a senior engineer) asked me to do it” has a few drawbacks:

Inability to execute independently: making even the smallest decision without involving your manager or the tech lead will be hard if you don’t understand the bigger picture. You will get stuck if you can’t get hold of them. It will also be difficult for you to demonstrate you know how to solve problems at your level and are ready for bigger challenges.
Communication gap: your manager or senior engineer may unintentionally give you incomplete or incorrect information. If you don’t have enough context, you may not notice this. You may struggle to complete the task, but once you finally do, it may turn out that what you built is not what they hoped for and needs redone.
Hindered innovation: unawareness of where your work fits limits your ability to propose solutions beyond what you’re asked to do. Sometimes, the approach you’re instructed to follow may not be the best solution to the problem, but exploring alternatives is impossible if you don’t understand the broader context.
Incorrect prioritization: working on a task without knowing its purpose may lead to neglecting this task and unknowingly delaying work that depends on it.

How to understand the bigger picture?

The easiest way to understand where your work fits is to ask your manager or the tech lead. They are responsible for what the team needs to deliver, so they should be able to explain this instantly.

Your question may even come to them as a surprise. They probably assume everyone on the team already understands the purpose of their work. In my experience, this is not always the case. The bigger and more complex the project, the harder it is to connect the dots.

You can start small, but it is important to go deep. Start asking about your task. You may hear that it contributes to a project the team is working on. An answer like this is not very helpful but could be a great starting point. It allows you to drive the discussion further and ask more interesting questions like:

Why are we working on this project? Why is it important?
What metrics is this work expected to move, and how?
How does it support the company’s goals and priorities?
What projects did we decide not to pursue to fund this work (a.k.a. opportunity cost)?

A different way to understand where your work fits might be by talking to your product manager or people from the UX (User Experience) or marketing team. Because of their different perspective, they can teach you things you would never learn from fellow engineers. The challenge with this approach is that you need to be able to explain your role in the project to them.

Want your productivity to skyrocket? Avoid this trap!

As a junior engineer, I felt the urge to jump on each new project that showed on the horizon. I never checked what I already had on my plate. Inevitably, I ended up with too many projects to work on simultaneously. Whenever my manager or a customer mentioned one of my projects, I immediately switched to it to show I was making progress. It took me years to realize that while this approach pleased the customer or the manager (and saved my junior dev butt) for the moment, it quietly hurt everyone.

The three-line execution graph

Executing multiple projects of the same priority at the same time looks like this:

Initially, there are two projects: Project A and Project B. You start working on Project A, but after a while, you receive a call from the customer inquiring about the progress of Project B. To make this customer happy, you switch to project B. In the meantime, a new interesting project, C, pops up. It is cool and seems small, so you pick it up. Your manager realizes that project A is dragging and asks about it. You somehow manage to finish your toy project C and move to A, which is well past the deadline. Then you pick B again.

If you didn’t jump from project to project, the execution could look like this:

If you compare these graphs, three things stand out in the second scenario:

Overall, the execution took less time. Resuming a paused project requires time to remember where the project was left off and get in the groove, i.e., to switch the context, which , which is time-consuming.
Projects A and B finished much quicker than in the first case. While you didn’t make customer B feel good by saying you were working on their project, ultimately, the project was completed sooner. In fact, both projects, A and B, were finished much sooner than they would have if you bounced between them.
Project C came in late, so it should wait unless it is a much higher priority than other projects. Otherwise, it disrupts the execution of these projects.

I know that life is not that simple. Completely avoiding context switching is rarely possible. But if you can limit it, your productivity will dramatically increase.

Does it mean you should only work on one thing at a time?

In the past I thought a good solution for junior engineers to combat context switching was to ask them to work on just one project at a time. But this idea has a serious drawback – projects often get stuck due to factors outside our control. If this happens and there is no backup, idling until the issue gets resolved is a waste of time.

Having two projects with different priorities works best. You execute on the higher-priority project whenever you can. If you can’t, you turn to the other project until the main project gets unblocked.

What I like about this approach is that it is always clear what to work on: the higher priority project wins unless working on it is impossible.

Falling back to the lower priority project means there might be some context switching. While it is not ideal, it is better than idly waiting until the issues blocking the main project are resolved.

But my TL (Tech Lead) always works on five projects!

Indeed, experienced senior and staff engineers often work on a few projects at the same time. In my experience, however, it is a different kind of work. It might be preparing a high-level design, working on an alignment with a partner team, breaking projects into smaller tasks, and tracking the progress.

The secret is that most of these activities don’t require as much focus as coding. Handling a few of them at the same time is much more manageable because the cost of switching contexts is much lower.

The Biggest Enemy of Focus and Flow: Interruptions

Bill Gates once said: “Most people overestimate what they can do in one year and underestimate what they can do in ten years.”

I like to paraphrase it as “Most developers overestimate what they can do in 10 minutes and underestimate what they can do in 1 hour”.

Interruptions are a productivity killer. You can do barely anything in 6 blocks of 10 minutes but do a lot during an uninterrupted 1-hour focus session.

Even minor interruptions can be costly. For instance, when debugging intricate bugs, you need to build and hold a complex state in your head. A simple question from a colleague can destroy it and force you to restart your debugging session from scratch.

Here are the most common sources of interruptions with ideas on how to deal with them

Notifications

Nowadays, every application wants to grab our attention. Just the basics, like email, text messages, or work chat, send many notifications per hour. It’s impossible to stay focused and respond to these notifications. The truth is that most, if not all, of them can wait.

Turn off most notifications on your phone and laptop if you can. For the remaining ones, disable the sound entirely, or at least for the duration of your focus session. Consider leaving your phone in a different room and putting your laptop in the focus mode.

Check your email or work chat between focus sessions. Attend to messages that need to be answered and decide what to do with the remaining ones – likely, almost none will require action.

Teammates

If you work in the office, your teammates are a blessing but also a curse. While spontaneous brainstorming sessions, ad hoc design discussions, and the ease of receiving help to solve on-call issues are gold, they are also a source of constant distraction.

My first strategy to avoid these distractions is to… hide. I found a nice area in my building a few floors away from my team, which I can use to prevent interruptions. I often go there if I need to finish something important urgently. Occasionally, I work from home to get work done, which I view as an ultimate form of hiding.

Another option is to use noise-cancelling headphones. I don’t even play the music – I use the headphones to isolate myself and signal to other team members that I don’t want to be interrupted. It is not as effective as hiding, but it works fine most of the time.

Internet

It is hard to tell what is more difficult: coding with or without the Internet. On the one hand, a significant part of coding is searching the Internet for solutions to more or less trivial problems. On the other hand, it is so easy to fall into the downward spiral of checking “just one more thing.”

My way to combat these temptations is to use a dedicated virtual desktop for my coding session. The only programs open on this desktop are my developer tools, such as IDE, terminal, or a simulator, and a dedicated browser window, where I am not allowed to open any website unrelated to what I am working on. (I gave up on a multi-monitor setup long ago when I realized I used the other monitor(s) for things whose only purpose was to distract me, like email). Some people also use programs like Cold Turkey to block the Internet and avoid distractions.

Ultra focus mode

Long plane trips can trigger the ultra-focus. They definitely do it for me. Because the environment is restricted, there are few chances for interruptions. Ever since I experienced it for the first time, I have been trying to recreate it on the ground. If you have yet to discover it, take the opportunity on your next long flight.