Press "Enter" to skip to content

Managing Your Tasks

Many programmers haven’t learned how to manage their work tasks. This is especially common for programmers who are at their first professional job.

However, managing your work tasks is vital to your success. This is true not only for beginners, but also for senior developers. I use these practices in my work.


Take notes in meetings

If our memories are RAM, then a notebook is a hard drive. Over the decades, I’ve been in countless meetings where people argue about what we agreed to in previous meetings.

So, when I start a new job or contract, I buy a new notebook to record what we decide in meetings. I like hardcover A5 notebooks.

Whenever I’m in a meeting, if we agree to do something, I make a note of it. If I have a task, I write it in the notebook with a little square to the left – so I can add a checkmark when I complete the task.

Every day I start work, I look through the notebook and see if there are incomplete tasks I need to work on today.

You’ll probably be using an online project management tool like Trello or Jira. But there are many other tasks that need to be done. You probably won’t create user stories for things like contacting the DBA to make sure they’re available for a deployment. However, that’s an important task that you can’t forget to do.

By writing all these tasks down, and reviewing them every morning, you’re going to prevent a lot of problems. And management is more likely to recognize you as someone who is worth promoting.


Let someone know when you’re stuck

A common situation with new programmers is getting stuck on a problem for many days and not letting anyone know.

It’s difficult to come up with a single rule about when to ask for help. Each company, team, and co-worker will have different standards for how much effort you should put in before asking for help.

When you’re stuck, definitely search for solutions online. This is especially true for when you get an error message. Searching for a specific error message will almost-always get you to some potential solutions to try.

If you’re still stuck after searching for a solution, and you want to ask a co-worker for help, make sure you’ve put in effort to solve the problem yourself.

If a junior developer is stuck on a problem, asks for help, but hasn’t done any of their own research, that’s probably not going to lead to a positive response from the person they ask. However, if you ask, “I’m having this problem, I tried these things (which didn’t work), and I’m out of things to try. Can you point me in a direction to find a solution?”, you’re probably going to get a much more positive response.

As a rough guideline, if you’ve only spent an hour or two trying to find a solution, that’s probably too early to ask for help. Remember, you’re interrupting your co-worker’s work. But, if you’ve spent more than a day or two, it’s almost certainly time to ask for help.

By the way, if you end up at a job where the senior developers don’t help you, that’s probably a good sign you need to find a different job – or a different team at the company.


Realize that estimates are only estimates

Always remember that estimates are just that – a guess of how long it will take to do a task. Many of those guesses are going to be wrong. This is especially true for your first few jobs. A new programmer just doesn’t have the experience completing tasks and dealing with the many unknown problems that may come up.

If your team does “poker planning” to estimate tasks, listen to what the senior developers say when they have a different number from what you estimate. They will often be considering things you weren’t aware of but need to consider for your future estimates.


You might be in a situation where other people on the team try to hold you to those estimates as if they were 100% accurate numbers.

This can be a sign of a bad work environment. However, it can also be a sign that there are new skills or knowledge you need to acquire. If you always take longer than expected to complete tasks that require working with the database (for example), it’s a good idea to take time to learn how to work with databases.


But also keep in mind, if your estimates are only accurate 10% of the time, that’s a sign you need to work on making better estimates. Think about the things that caused your estimate to be wrong. When you make your next estimates, take these things into account and make sure your next estimates allow for them.

Estimates aren’t random numbers that you randomly hit or miss. But if you never apply what you learned from your previous experiences, your estimates will never become more accurate.


Ask for prioritization

At some point, you will probably have multiple tasks to work on. Bugs come up in production systems and need to be fixed quickly. Management needs a special report. And you still have assigned tasks for the project you’re supposed to be working on.

In this situation, I’ve seen several new programmers get stuck and not know what they should be working on.

If this happens to you, and you don’t know which task to work on, just ask your manager. That’s their job – to manage the work.

If you have multiple people trying to make their work your top priority, talk with the manager who is actually in charge of your work – the one who determines if you get promotions or raises. The project manager manages the project. Your line manager manages your career.

Unfortunately, it’s not unusual for managers, project managers, and product owners to tell you multiple tasks are a priority. If managers repeatedly say multiple things are all the “top priority”, I consider that a sign of a bad team, and an indicator I may want to work somewhere else.



Most of the things I mentioned are things you can do to better manage your work. However, I also mentioned that some of them are indicators you may be on a bad team, and it may be a good idea to look for a different place to work.

My personal opinion is that there are many things you can do to improve your work. However, in my experience, it’s difficult to “fix” other people – so I’ve stopped trying. Maybe you’ll want to try, and maybe you’ll have more success than I’ve had. But I’d rather devote my time and energy finding an existing place where I’d be happy, instead of trying to change a place where I’m unhappy.


Return to “Life as a programmer outside Silicon Valley” index

    Leave a Reply

    Your email address will not be published. Required fields are marked *