A software engineer’s time is highly valuable. We are the ones that can fix bugs, improve UI, and bring new features to fruition. While this is definitely a positive for the role, it does require a high degree of time management. Effective time management helps to ensure that the most important work is being completed in an efficient manner. Let’s go over a few tips on how to do this.
PLAN & REVIEW DAILY TASKS
It is a fascinating exercise to write down how you think you spend your time, track how you actually spend your time, and then compare the two. I don’t say this to imply that anyone isn’t actually working hard, but to suggest that we don’t truly know how much time we spend on pull requests vs meetings vs writing code.
In order to better understand how time is being spent and where it can be optimized, start every day by looking at your tasks for that day and planning them out, hour by hour. This prompts us to think through how much time each task will actually take, what is realistic to accomplish in a work day, and utilize smaller chunks of time in between meetings or other work. Throughout the day, track how you are actually spending your time, including additional asks that were made as the day progressed. At the end of the day, compare the two. Ask yourelf, how accurate was I in my estimations? Do I feel like I used my time today efficiently or not? Was I able to effectively manage the daily asks that came through, or did those throw off my otherwise scheduled day?
Knowledge is power, and this applies equally to time management. We can’t manage what we don’t understand. In doing this exercise each day, we improve our ability to plan, allocate resources, and efficiently handle our responsibilities.
PRIORITIZE & REPRIORITIZE CONSTANTLY
We talked about daily asks in the previous section. New tasks, large and small, are always being asked of us. Whether it’s fixing a typo that was found, supporting a new oAuth option, or building a new feature, the “To Do” list is never ending and forever being added to.
It is imperative to our own time management that we understand the priorities of new asks as they come up, and thoughtfully prioritize them among existing work. Context switching, which is basically stopping work on one task to switch to working on a totally unrelated task, is something that itself takes up our time. The mental and physical switch from one space to another, the time it takes to re-familiarize yourself with the nuances of the new task, and then the time it takes to do these again when switching back to the initial task, adds up and is not insignificant.
By understanding priorities and effectively managing them, we can minimize this time-suck. If the typo is buried somewhere that isn’t very noticeable, maybe it can be grouped with the work that we’re already doing later in the week on that same page. If it’s a new feature that is needed soon but will take a week to build, it might make sense to spend the day and a half needed to tie up current work before diving into it.
USE TIMEBOXING
Timeboxing is the idea of allocating a finite period of time to a task. In approaching a piece of work, the default tends to be to work on it until completion. This often will make sense, but can have its perils in development. For tasks with many unknowns, an unclear level of urgency, or vague requirements, forging ahead without time parameters can lead to unintentional allocation of many hours of precious software engineering time. Issues are addressed as they arise without giving much thought as to whether the growing task is still something that should be prioritized, given the resources it is costing.
We can (mostly) avoid this by using timeboxing. Rather than starting on a task and reassessing after completion, we would say, “I will spend X hours on this and see if I can get it done. If I can’t in that time, we can circle back on what I found, what resources would be needed to reach completion, and decide if we want to continue with it.” Sometimes we might even just say “I will spend X hours on this and see if I can get it done. If I can’t get it done in that time, we’ll put it on the back burner until we have more time to look at it.”
Even with the best planning, unknowns are always a part of the software development process. With timeboxing we can mitigate and manage their intrusions.
TAKE A STEP BACK WHEN NEEDED
Personally, I can get very stubborn when working on something that just won’t do what I need it to do. If I let myself, I can spend hours being “almost finished” with it.
Not only is this incredibly frustrating, it’s also a waste of time. Granted there will be times when something is particularly tricky and this might not apply, but almost every time that I am in this position, all I really need to do to get it over the finish line is to take a step back. This could be going for a short walk outside, switching modes to work on something a bit less complex, or reading for 20 minutes. When I do this, I come back to the problem and almost immediately see the solution. I just couldn’t see it before because I didn’t have any space from it.
We can save ourselves hours by knowing when to take a step back. “Shower Thoughts” are a thing for a reason — ideas come to us when we aren’t looking for them, and taking a step back allows us to leverage this. When we hit that point of feeling like we are “so close” (or sometimes maybe even not close at all) but just can’t quite get there, we have to take a step back from hammering on it. When we come back to it, we’ll hopefully bring some clarity, and if we don’t, we’ll know it’s time to get other eyes on it.
