Developer personal time management
I find that most developers want to help out. They like to get involved. They enjoy rolling up their sleeves to put out fires. They relish being seen as the person that can do magic to solve the unsolvable problems for their business counterparts.
And because we enjoy these things we tend to allow people to interrupt us at their convenience. We horribly under estimate how long things will take to get done because we feel bad admitting that some problems are hard to solve. And we mis-manage our time over and over again as we attempt to catch up on all the things we need to get done because none of us want to appear like we aren’t that magical after all.
In this post I am going to discuss things that have all already been discussed around time management somewhere else (and they likely did a better job). But these seem to be new concepts to many younger developers. Please ignore this post if you already manage your time well and estimate your work expertly!
And if you are interested in these concepts please do a little more research to understand the importance of each and how they will help your day be more efficient.
Developer Office Hours
Developer “office hours” means that you have a time slot scheduled on your calendar for when you are available for unplanned one on one walk ups. Most developers like to get work done as soon as they get into the office (as they were likely thinking about a hard problem all night and now have a solution for it). So scheduling work time (not office hours) first thing in the morning makes since. Having their first office hour(s) scheduled at 10 or 11 works better as they have solved their burning issue and are ready to have some face time with their peers. But if you prefer to have all your interruptions unplanned work out of the way first thing, earlier office hours might make more sense for you.
I would be careful calling those walk ups or unplanned work “interruptions” (even though you may see some interactions that way). Since you have scheduled time for one on one interactions with your juniors, business partners, etc. these conversations should specifically not be seen as interruptions but instead conversations that are needed by your team to be successful. The more senior you are, or the more managerial you are, the more likely your team needs your input. You may need more office hour time than “personal sprint” time.
Once you have this time for unplanned conversation on your calendar you will be ready to defend all of your other time as your time. But, now instead of saying “Please go away, I am busy” – you can instead say “Please come back during my scheduled office hours from 10am-11am or 1pm-2pm. I am available for this discussion then.” And as you train the folks you work with most they will come during your office hours more and more thereby allowing your personal time to be that much more productive.
In order for office hours to be effective for those walk ups, use the time between meetings for business related tasks that don’t require a lot of thought or are heavily fragmented. Don’t try to squeeze in important tasks that require deep thought as a way to sneak more real work into your system. You will only end up pissed that people are stopping your flow. Instead stick with other busy work items that are generally more fragmented in nature.
Some things that fall into this category:
- checking email
- getting caught up on your group chat
- other forms of communication
- managing your calendar
- returning phone calls
- etc.
Now let’s optimize your focus during your non-office hours.
There is a great answer on StackExchange about office hours
What most people fail to understand: Every time our concentration is broken, we create at least one bug and/or delay the deadline for another half-hour. Private offices is not a “nice to have” for developers but a must. This is not about status, this is about brain physics.
And in a world where open floor plans (and noise and interruptions) are the norm, scheduled office hours is as close as you can get to a dedicated office space.
Personal Sprints
A lot of development teams these days have heard of Agile and likely “sprint” with their teams. So for most people this concept should be well known. How do we apply this to our personal work time?
Easy! Plan it. Start at a certain time with specific work in mind. And just work on that specific task. A personal sprint might be the time between your office hours. Or it might be in 45 minute blocks several times leading up to the next meeting or break in your day. But schedule your day to work on specific tasks during specific times and then commit to that activity and minimize allowed interruptions in your sprint.
Communicate to your team that you are in the midst of a “personal sprint” so that people learn not to interrupt you while you are trying to achieve a state of flow.
Mihaly Csikszentmihalyi: Flow, the secret to happiness
If you have your own office, guarding your time is a bit easier as there is a physical barrier to interruptions and you can hang a sign on that barrier “I am busy in the midst of a personal sprint! Please check my calendar for my next available office hours.”
If you are in an open floor plan (as is soo very popular these days) it is a little bit more difficult to guard your time and attention. SO – Fly a flag. Put up a lamp with a red bulb. Do something crazy that shows you are busy…and teach frequent interrupters that there is a cost associated with being interrupted. Sadly – wearing your head phones no longer seems to work. …tap tap tap…I am standing here please answer me!
What is that cost of being interrupted? I found a great post that covers this topic well. Here is a snippet.
Based on a analysis of 10,000 programming sessions recorded from 86 programmers using Eclipse and Visual Studio and a survey of 414 programmers (Parnin:10), we found:
- A programmer takes between 10-15 minutes to start editing code after resuming work from an interruption.
- When interrupted during an edit of a method, only 10% of times did a programmer resume work in less than a minute.
- A programmer is likely to get just one uninterrupted 2-hour session in a day
We also looked at some of the ways programmers coped with interruption:
- Most sessions programmers navigated to several locations to rebuild context before resuming an edit.
- Programmers insert intentional compile errors to force a “roadblock” reminder.
- A source diff is seen as a last resort way to recover state but can be cumbersome to review
Pomodoro Technique
Once you have office hours and you have started working with the concept of personal sprints, you might want to optimize even further. Matt Hinze introduced me to the concept of the Pomodoro Technique for helping you with this. This is a very simple way to improve your time management.
- Use a timer for planned activities
- Plan your tasks around Pomodoro time increments
- Review your time estimates to get better at estimating
- Ignore interruptions during your Pomodoro sessions
- Record your progress across timings and across activities to improve your process
Devin Rose turned me on to a Trello like board for doing the Pomodoro Technique and work item management called KanbanFlow. This allows you to plan your sessions, keep a timer going, and track your sessions over time to see how long certain types of activity generally take you.
Doing Pomodoro before you have trained your peers to speak with you during office hours will be very painful and will likely lead you to not like Pomodoro. Office hours. Then personal sprints working on deep thought items. And then Pomodoro to track your progress.
Have a better way?
I am sure there are many other great ways to be productive with your time. I can think of some off the top of my head that I use every day: Inbox Zero, getting things done. Scott Hanselman has been doing a productivity talk that summarizes some of his concepts: “Don’t worry, just drop the ball”, “Scale yourself”, “Look for danger signs”, and many more.
There is a lot of room for improvement out there to be had by most developers. Please share your ideas below. Let’s discuss it!