So I’ve talked about time tracking before, however that was much more a “keep yourself on track / how to know what to bill per hour as a freelancer/contractor” post. Today I’d like to share some thoughts on bigger companies and my feelings toward management and time tracking there.
I’ll preface all this with ”these are my opinions, I’m not saying I’m entirely correct here, this is just how I personally feel“.
As a programmer I love my craft, I spend hours playing around with new technologies, learning new languages and wrapping my head around computer science concepts. I’ve always known programming would be my career from a young age, finding it amazing that people would pay me to do what I love to do anyway.
What I never realised back then is how much of a programming role involves no programming at all. Meetings can be a daily occurrence, eating into your time, understandable though as things do need to be decided on or signed off. Managers need updates so they can communicate clearly with the people they report to. Clients want you to explain why you can’t add five new features by next week. Customers want you to explain how to use things (and occasionally need you to fix things). Priorities must be juggled.
All of the above I don’t really have an issue with. They are mildly annoying, but to be fair, they are often necessary parts of the job.
What I do have an issue with however is time tracking on top of this in large organisations, especially when it becomes very detailed. A certain amount of visibility can be useful, and I understand why teams want to know where time is going, but it can easily drift into a process that interrupts the programmers workflow more than it helps. Before long you can end up in JIRA logging hours on tickets and trying to account for your day in a way that feels more administrative than useful.
What I find difficult about that as a developer is that it can create the impression that you are being measured too closely rather than supported. Even if that is not the intention, it can make people feel less trusted and add friction to work that already requires long stretches of focus. If the main outcome is a detailed report that doesn’t meaningfully improve planning or team health, then it feels like the cost to morale and concentration may not be worth it.
If you haven’t read Programmer Interrupted, I recommend that you do, but I’ll just include the results of their study here:
- A programmer takes 10-15 minutes to start editing code after resuming work from an interruption.
- When interrupted during an edit of a method, a programmer resumed work in less than a minute only 10 percent of the time.
- A programmer is likely to get just one uninterrupted two-hour session in a day.
These are the kinds of problems I think management should be trying to solve, rather than adding more interruptions by requiring developers to log each hour they’ve spent on every feature.
Another great article that discusses how programmers see time different to managers is the Makers Schedule.
Where I currently work (Kobas) actually deals with all of these things I’m complaining about very well. For a start there is no time tracking (which makes me very happy), and we have a daily Slack stand-up (I guess it’s more sit down?) where we give a few sentences on what we worked on yesterday and what we plan to do today. It’s very helpful for knowing what other people are up to without wasting time doing an actual stand-up.
Interruption-wise, at any point I feel I need to have an uninterrupted session I can pop in my headphones and, unless something explodes, I never get interrupted. Meetings for me are rare, but when they occur they have an actual purpose. Developers != support, which leads to fewer interruptions. Of course I still have to fix problems that come up from support, but I’m not personally being interrupted by support requests.
So it’s certainly possible for companies to function well in these ways. I imagine there are plenty of reasons larger organisations end up with more process around this, but I still think many of them could reduce that overhead and create a better environment for focused work.