How I Prioritize My Work as a Software Engineer

Somewhere in the middle of my career, my coding skills started to grow rapidly.

I surrounded myself with the best engineers. I got the best mentorship.

Every pull request was an invaluable lesson.

However, being a great developer is much more than writing amazing code. We are team players, and we must act like it.

Soft skills, if you focus on them, can improve your career more than your technical skills.

Just a few engineers who work closely with you will be aware of your code quality. However, if you’re a great team player, everyone will know it.

Let me share a few things I changed at my work that completely transformed my career.

What I Was Doing Wrong

At the time, I was obsessed with deep work and the flow state. I put my noise-canceling headphones on, started coding, avoided all distractions, and let the code fill my mind.

Sometimes, I succeeded in retaining that state for hours. It was amazing. I was learning so much and it felt so good.

Today, I have nothing against the flow state. Hey, I’m currently in it while writing this article. I have no distractions. My phone is on silent mode and I know I won't speak to anyone before I finish.

But there’s a huge difference. When writing, I’m all alone.

When coding for a company, I’m a team player.

I can’t snooze all my notifications. I can’t be unresponsive. My team needs me in the same way I need them.

And that’s exactly what I was doing. Sometimes, it took me an hour or even longer to respond to a simple Slack message.

When people asked me to do something that would take five minutes, I ignored that task for days.

I was constantly pursuing that magical flow state. I didn’t want to let any distractions come to my mind.

In my head, I had a right to do that. I was writing the best code possible and focusing just on that. What’s the problem?

What My Colleagues Thought About Me

If we take a different perspective and look at it from the eyes of my colleagues, we will see that my behavior wasn’t justified.

They needed to do something for work, so they asked me for help. However, those requests always landed at the bottom of my priority list.

I gave them solutions hours or even days later.

Sometimes, the solution wasn’t so great. I didn’t want to spend too much time on those small tasks.

“Let me keep my flow state!”

Why I Changed

Every once in a while, we have anonymous team reviews. Basically, you write about the people you work with. After the sessions, the team leaders tell you what others are saying about you.

I received many positive comments about my engineering skills.

However, some comments were quite negative, and they were all connected to my prioritization and communication techniques.

People were saying that I was unresponsive or gave them solutions that hadn’t been fully tested.

How could I test them properly when I had to return to the flow state as soon as possible?

I took that opportunity to self-reflect and change.

What I did was incredibly simple. However, it completely transformed my career.

The Simple Changes

When somebody asked me for help, I immediately responded. Their request was now my top priority.

Most of the time, it’s not a time-consuming task. It’s a question about where something is located in the app, what the expected behavior is, what that code means, etc.

I can handle those tasks in 1-2 minutes. Occasionally, it takes me 5-10 minutes if they are a bit more complex.

Besides just responding to my direct messages, I also became an instant responder in our groups. Suddenly, I became a person others rely on when they need quick information or changes.

Astonishing Effects

From being an unresponsive person who coded in the corner with his noise-canceling headphones, I became one of the most valuable people in the company.

Everyone has that feeling of trust: When they ask me something, they know the solution will be there in the shortest time possible.

People don’t expect that, so they love it even more! I often receive compliments about how great my work is and how fast I deliver it.

My colleagues have problems they need to solve. If I help them in two minutes, they will be amazed.

However, if I help them in three-plus hours, they won’t be impressed. They may even be annoyed if it’s something really simple.

The Real Benefits

For the sake of simplicity, imagine that I’m working on a task that needs six hours to be finished. I started my work at 9 a.m. If I do nothing but code, I will finish it at 3 p.m.

However, I’m not the only one who’s working. Everybody else is, and they need my help. In the period from 9 to 11 a.m., three people ask for my help.

The tasks are pretty simple. Each one will take around five minutes to complete.

We have two possible scenarios about handling this work:

1. In the first one, I’m the old, unresponsive team member. It takes me about one hour to respond to somebody’s message, and it goes at the bottom of my priorities list. I will do it after I finish my task. That means that I’m done with my feature at 3 p.m. However, that also means those three people waited 4-6 hours for my solutions. They are grumpy because they wanted to do something by noon. However, they were blocked by me.

2. In the second scenario, I respond and do the job immediately. I receive comments like “Amazing, that was so fast 🚀” or “Wow, I can do this before lunch now, thanks Dom 🏎.” Besides all that, I finish my feature at 3:15 p.m.

Can you see the difference?

Nobody cares about me finishing the feature 15 minutes later because they didn’t know when I was expected to finish it anyway.

However, they certainly care about me providing them with a solution in five minutes rather than five hours.

Again, just a few people can see your code skills. However, most of them will see your communication skills.

How Did This Influence My Coding Skills?

We, as engineers, need to solve extremely complex problems that require a lot of focus. Sometimes, context switching can destroy those solutions in our minds.

However, a context switch can also be the break you need. When you return, you’ll be able to take a step back and look at the problem from a different perspective.

If you had stayed there for a few more hours, you would have just drilled in the wrong direction.

Suddenly, you return after a break and fix the issue in a few minutes.

So those breaks actually improve my coding skills. I ship the code even faster now.

Sometimes, the best solution is to let go. A fix will quickly come after we stop being obsessed with it.

Conclusion

This is not just for your benefit — everybody’s included.

These skills will make you a great team player. A person others can rely on. You will radiate confidence and solve people’s problems in no time.

Nobody’s pipeline will be blocked because of you. Everything just flows. You make others feel happy and inspired.
You’re not alone, so stop acting like that.

You can be an incredible engineer, but if you manage to be an incredible team player as well, you’ll easily become part of the top 1%.