Developers Happiness
Development Noise
Features & updates
Developers happiness
Development noise

What time management looks like for today’s developers?

Oct 25, 2021
 min read
Like it, share it!

Company Calls, Daily Scrum Meeting, Retrospectives, or just a casual weekly check-in? Depending on the structure of your organization, you might be doing some of these or all of them. So, more power to you! The more time you spend on meetings, the better you have to manage the time left to get the most out of your workday.

In this blog post, I'll show you all the techniques I'm using to manage my time as a Software Developer.

The more time you spend on meetings, the better you have to manage the time left to get the most out of your workday.

Clear Communication

But before I dive into those specific time management techniques, I would like to talk a bit about the importance of communicating clearly, when it comes to time management.

Let's say you have a task at hand that requires the opinion of another engineer from another department who worked on the same code a year ago.

There are infinite ways to approach such a conversation. Some of those will take a lot of time for both of you, while others lead to a solution much faster.

Here's one of those lengthy conversations between Jane and Ben:

Ben: Hey

Jane: Hi 👋

Ben: You worked on PaymentProcessor a year ago, and I have some questions.

Jane: Which PaymentProcess is the California Tax or the regular one?

Ben: The regular one.

Jane: Okay! What's your question?

Ben: I'm wondering why there's rounding in "processPayment"?

Jane: 😟

Why the above, doesn't look like a meaningful conversation to us?

Well, first of all, don't forget, Jane looked at this code exactly a year ago.A lot has happened since then. She moved into a different team and now owns a completely different code.She has to open the project and files mentioned in her editor and find the function "processPayment".

Let's be honest, it just takes a whole lot of time for Jane to answer something you couldn't figure out for yourself.We could communicate our queryJane so she has everything right at hand and can focus on helping us, rather than getting to the correct files and scrolling back Slack 10 times to remind herself of the original question.

Value others' time

The most annoying message I get on Slack is probably: ”Hi 👋”.

This thing hurts, imagine how disappointing is to have your thought process interrupted by the annoying sound of slack - or worse an on-screen Alert - just to read: ”Hi 👋”. It's ok to say Hi, but please if you interrupt someone just be meaningful and include some other details in your message. So if the person already took the time to look at Slack, actually gets something out of it. This is also true for questions like ”May I ask a question?” - because you just did.

Be precise

Chances are, your set of knowledge and the other person's set of knowledge is different. Be precise with your messages, use permalinks if you're on GitHub to help your peers get to the files or specific lines of code faster. You can highlight multiple or single lines and send that to a fellow engineer.

Ask a meaningful question

I've seen this too many times in my career, a clear explanation of the problem, links, everything, but... what's your question?

It often happens that when you spend quite some time working on something the problem becomes obvious to you - but it might not be for others. This is why it's really important to make sure you close your message with a question.


Now that we're aware of how to not waste others' time it's time to optimize how we spend ours.

I'll be describing some techniques I tried and didn't work out and what I ended up with.

Pomodoro Technique

At heart, it is a super simple practice to follow: 25 minutes of work followed by 5 minutes of break. Repeat this 4 times then take a longer 15-30 minute break.Tried it for a couple of months, but I'm not following this one anymore. My main problem is that sometimes it would take me another 5, 10, 15 minutes to get to the bottom of a problem, so I continue and break the whole Pomodoro cycle. This is why I do take breaks when I feel I need a break.

Now I would say if you're just getting started and this is your first developer position, don't rely entirely on your feelings because they might trick you. You won't even notice that the quality of the decisions you make just dropped a bit, that writing easy stuff just becomes a bit harder. Take a break at regular intervals and don't fear using a timing technique such as Pomodoro.

As I said, recently I'm taking a break when I need it and it's usually after I completed a task or a block of tasks.

This leads me to the technique I'm currently using:

Time Blocking

I usually divide my day into big blocks that don't change.

My morning - late noon hours are reserved for work.

Evening hours are reserved for contracting or social media work.

I don't track these big blocks, this is just how I'm used to it.

What I do track however are the smaller blocks inside these two. At the beginning of the day, I try to fit some tasks into both of these boxes.

Benjamin Franklin's Daily Schedule
Benjamin Franklin's Daily Schedule

I'm using additional criteria to pick the right tasks:

Is this thing blocking?

It's always a top priority for me to unblock other work. Never underestimate being a blocker, you can block a single feature or an entire release. Your team members should communicate to you if you're in such a position and you should prioritize accordingly. Being a bottleneck in a process is a bad thing, and there are several other ways to avoid becoming one but those tips are for a completely different article.

Eisenhower Prioritization Matrix

This technique helps you prioritize your tasks based on their importance and urgency.Once I create a list of tasks for each of the main blocks I start working on them.
There are four types of tasks in this matrix:

Eisenhower Prioritization Matrix


Respect others' time and they'll respect yours. Don't shoot into the dark with half-baked questions. Do your homework and prepare a well-formatted question that can be answered with ease. Provide as much context as you can but leave out the details that don't help to make the question more clear.

Resist the urge to jump from task to task. You're the only one who knows what your priorities are.

Like it, share it!
Ákos Kőműves
Lead engineer, Csongrád, Hungary

When I was 15, I sold my first piece of software. I started making simple websites about 20 years ago. Since 2011, I have been a professional software developer; I have worked in different fields such as FinTech, E-Commerce, Acoustics, and Workflow Automation.

See all other articles
Stay updated!
Zigi’s blog is the place to read and hear from developers like you about happiness, noise, productivity and everything that is new at Zigi in one place.
*Enter a valid email
Thanks for subscribing!
Oops! Something went wrong while submitting the form.
No charge. Unsubscribe anytime.
Join our mission
to eliminate wasted time & burnout for developers
Join us! Be a part of our beta group and help us shape Zigi — a tool for developers, by developers.
Spread the word about Zigi, and win a prize
Get rewarded for you’re referrals and score the full Zigi sticker pack.
Get your referral code
Join our mission
to eliminate wasted time & burnout for developers
Join us! Be a part of our beta group and help us shape Zigi — a tool for developers, by developers.
Join Us