Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Get the latest Education e-news
 
  • Time Tracking In 2020

    [02.06.20]
    - Niklas Gray

  • I have three main things that I want to accomplish with time tracking.

    1. First, I want to know the total amount of hours I work each week. Since I'm working from home it's easy to work both too little and too much. Too little, because there's always other stuff that needs to be done around the house. Too much, because you can always pick up the laptop and do some more work.

      For me, I find the optimum to be about 30-40 hours of work per week. (Measured when I'm actually sitting down at my computer - hands on keyboard - so it doesn't include things like coffee breaks or chit-chat with coworkers that would be a part of a normal office workday.) If I work <30 hours I get restless and frustrated and feel like I'm not getting anything done. If I work >40 hours I tend to get "brain frazzle". I find it hard to relax, make poorer judgment calls when coding and can easily get distracted by social media, blog posts, etc.

      So I want to measure my total work hours to make sure that as far as possible I stay in this 30-40 hour sweet zone.

    2. Second, I want to know how much of that time I'm actually spending on the specific engine feature I'm primarily trying to implement. Sometimes I will counter-productively start to stress out about how I "didn't get anything done this week", only to realize that the main reason is that I've been occupied by other important tasks. Maybe I got derailed by a tricky bug that took two days to fix. Maybe I needed to spend a lot of time planning out the roadmap, answering questions on the forum or writing a blog post.

      In addition to not feeling too bad, I also want to track this to make sure I keep a healthy balance between feature work and all the other tasks that also need to be done. If this engine is to be a success, I can't spend all my time fixing bugs, taking meetings, updating the web site or answering forum questions. I'd like to be able to spend at least 50 % of my time on feature work, preferably more. If the time tracking shows me consistently dipping below that, I know that I need to reconsider how I'm spending my time.

    3. And finally, as I said in the beginning, I want to know how long a feature took to implement so that I can get better at estimating costs and planning. This information needs to be at a high level and not bogged down with minutia. For example, I want to know how many weeks it took to implement the physics system, not how many hours it took to add collision filtering to the character controller. I also want this information to be available at-a-glance all the time and not require batch processing of logs or something like that.

      Having the information always available means I can react to it in real-time: "Huh, seems like prettifying this part of the UI is taking a lot longer than I expected. Since this is not a crucial task, it does not make sense to spend a week or more on it. I should switch to doing something more important for our success."

      Side note: I use trunk-based development and avoid feature branches so that if I have to abort a task early I will still have delivered value (in this case - prettified some parts of the UI).

      Note that what I'm interested in is the real, wall-clock time it took to implement the feature. Not the time it would have taken in an ideal world where I could focus 100 % on feature work, was never interrupted, didn't have any vacation days or sick kids, etc. It's the time in the real world that matters, and there will always be things like this.

    Given these goals, here's the system I've come up with:

    • I'll use Toggl to keep track of the time spent on each individual task I'm working on (as before).

    • I'll assign each task to one of three categories (Toggl calls them Projects), so that Toggl can tell me, not only how many hours I've worked each week, but also how much time I've spent on each category:

      • Feature - Work on the primary feature I'm currently adding to the engine (physics, animation, etc).

      • Maintenance - Fixing bugs, regressions, addressing user feedback, etc. Basically, any coding work that is not a direct part of developing the feature.

      • Admin - Anything else I need to do for the company. Blogging, answering forum posts, working on the website, emailing, distributing new alpha versions, raising money, planning, etc.

    • Each week, I send a note to my coworkers showing what percentage of my time has been spent on each category, together with a short description of what I've done. Note that I only send percentage numbers to my coworkers, not the actual hours worked. I record the hours worked each week for my own sake and I want to avoid a culture where workers get shamed for low numbers or praised for high numbers since that just tends to lead to the numbers getting fudged. "I read all these blog posts vaguely related to work, so I'll just record that as 5 worked hours." I think things work better when everybody is assumed to be a responsible adult until proven otherwise. Also, I'd rather encourage people to be efficient - to get more done in less time - than to work long hours. There's enough of that in this industry.

    • I record these numbers in a spreadsheet, together with one line describing the main feature that I worked on that week. That way, it's simple to get an overview of how many weeks a feature took by looking at the spreadsheet. I don't really care about recording tasks with a more detailed granularity than that. If I need more detailed information, I can always look at the logs.

    Here's what the spreadsheet might look like:

    Week #FeatureMaintenanceAdminMain FeatureNotes
    13 18 12 10 Animation Blend states
    14 10 4 21 Animation Locomotion

    It's not always 100 % clear how to draw the line between Feature and Maintenance work. For example, while I'm working on a feature I often discover that another system needs to be refactored or has bugs. Typically I record that as Feature work. My reasoning behind this is that the refactoring and API changes that need to be made are an integral part of the work on that feature (without the feature, they wouldn't be needed - YAGNI). Also, discovering and fixing minor bugs is just a natural part of coding.

    The only exception is if I discover a particularly hairy bug in another system. Say a bug that takes more than 1-2 hours to fix. In that case, I will record it as Maintenance work instead.

    I aim to keep this time tracking system up for the rest of 2020 and see how it works.

Comments

comments powered by Disqus