I’ve been called a workaholic by other workaholics who don’t consider themselves workaholics which is probably not a good sign. I consider myself a programmer and track my hours spent working and employ various metrics because I like measuring things.
From 2010 to 2015 I averaged about 15.4 hours of work a day (that’s 5,621 hours of work a year). Around September 2015 I “owed” myself over 365 days (over a year!) of weekends – Saturdays and Sundays where I worked the whole day.
I’ve been trying to work a lot less these days. The wake up call was when my father, previously a workaholic, told me I was working too hard. When the hardest working person in your life tells you that you might be taking the thing you know them for to an extreme you tend to take notice.
I took a vacation from September 2015 to January 2016 where I only averaged about 3.8 hours of work a day; I bought a work laptop specifically for the trip so clearly I’m not doing this cold turkey. It was fun. I spent a lot of time with my nephew, who is a little hellion, and ate way too much food. My nephew also kept begging for way too much food.
It’s late January now and I’m still catching up on work my contractors did for my game while I was off playing uncle, but it cleared up some issues I had floating around in my skull.
It’s always better to think about work in terms of tasks rather than time. You can’t divorce the time aspect of tasks, but it’s just better to say “I got tiny task X done today” rather than “I worked eight hours today.” For one thing it’s just more meaningful – I doubt your commit logs say, “Worked for eight hours on [System Y].” For another when you’re talking about day to day REAL WORK TM getting done, the time scheduling doesn’t even really matter. No, really.
I mean I knew this years ago. I think most people (apart from managers) understand this intuitively. But my four month vacation also made something a little more clear to me: don’t jump the gun if you have the time.
I don’t mean if you find yourself with a windfall of two hours and you can hammer something out on your todo list to not take advantage of it. I mean just don’t do this consistently. I’m not talking about burnout which is a separate and very real thing. I’m talking about clarity of purpose and avoiding redundant work.
Maybe this is different for other programmers, but I frequently find myself implementing a system, tying it in with relevant systems, then doing a bunch of filler work to get everything working smoothly. Unnecessary things. Things that may change. This isn’t about pre-mature optimization, this is about not knowing at a given point in time what is actually needed. It’s more like, “Hey, this thing knows about [some value] now. This should tie into the GUI, right? And it needs code-specific handling when interacting with…”
It’s subtle and annoying when you realize you’ve wasted your time, like when you made an entire inventory system before realizing inventory is a real crappy system for your game and you could have figured that out just by hard-coding a healing potion and a sandwich.
This also means your task list really needs to not be things like “Make [Massive System X].” It needs to be broken down into very small, bite-sized tasks you can accomplish in a relatively short amount of time. Personally I think that if you can’t do it in 15-30 minutes you haven’t thought it through or broken it down enough yet.
Aside 1: As the exception that proves the rule, if you’ve done something frequently enough and you know for sure you can slam it out really fast without thinking too much, you can put giant-looking items on your todo list. For example coding up a simple grid-based level generator for a roguelike game is pretty straightforward for me these days. I don’t need to break that down into room/corridor/placement/digger/whatever components anymore on paper or in my head. A benefit of experience you can apply to the things you know a lot about.
Aside 2: If you’re coding a bunch of systems that you don’t really like but are too attached to to throw away, this is also a Very Bad Thing TM.
Maybe I’m just really concrete sequential and this all sounds ghastly to you. Sure, and I guess it depends a bunch on what kind of game (or non-software project) you’re trying to make as well. I don’t work well in chaos, but maybe you do.
Right. So my four month vacation had me using a laptop which, though quite nice for development, was not up to my main dev machine standards. So this limited what things I could work on. I ended up spending a lot of time cleaning up old code and scripting for side mechanics because even my old Mac Classic let me type text reliably.
But four hours feels a lot less than sixteen hours a day, and when January rolled around I felt like I had a lot of catching up to do. Turns out not that much catching up to do.
It’s not that I got so much done, it’s just that working in a lower capacity actually made me focus on what things mattered and what didn’t. You know how if you have a set budget you start buying random crap? Well it’s kind of like that except you’re budgeting with time. Hey, I’ve got sixteen hours of work to do today; Let’s do a buncha crap.
I consider myself fairly disciplined, particularly regarding issues of prioritization, but apparently I’m not. A review of my current project since inception revealed that I wasn’t actually doing much better at doing real work that stuck around. I had previously reviewed my last game and discovered that I spent [EMBARRASSINGLY REDACTED] percentage of my time on systems that just never made it into the final game.
Turns out the percentage from my last game had aligned almost exactly with the development of my current game. Awkward. But the work I had done recently while on vacation? All in the game, at least currently.
I know, more current work is more likely to still be in the game. Obvious, right? Except I went back to a one week period I took a working vacation on my first game and reviewed what I had done during that period. Turns out all of that stuff, written about nine months before the game fully released, made it into the final game.
Well shit. That seems like a pattern.
I Hate People Who Waste My Time And I Really Hate Myself Right Now
Without exact numbers on how much work makes it through to final release it’s hard to determine how much to restrict your own work time. I mean yeah, maybe if I work 25% fewer hours 100% of that work gets through, but how does that work exactly? If four hours a day means 100% (haha yeah right but argument’s sake okay) of work is effective, does eight hours mean the first four hours is 100% and the last four is like 50% or what?
It’s probably some weird graph curve but that’s actually not that important. It’s not important because I know three things:
- I can’t get the bare minimum I need done for my game if I only work four hours a day (28 hour work week). Not if I want to release in a reasonable time frame.
- I prefer to finish sooner rather than later.
- Any amount of work between 4 and 16 hours a day is better than 4 or 16, assuming I estimated the time of tasks reasonably accurately.
I think this means that I should be trying to schedule tasks per day that I think will take me four (or a little more) hours a day, every day for the length of the project, and more or less stick to it. Inevitably some work will expand into available time, because I suck at estimating and because some things crop up that you didn’t plan for, and if not that leaves me time to expand on non-bare minimum tasks.
It’s a weird way to approach a creative project, perhaps, but I also have the benefit of making turn-based tactics games, and so spending more time on the core stuff has a lot more value than if I was making a game that really depended on loads of new content (e.g. a fully-fledged RPG.)
- Populate your todo list with the bare minimum, core things your game needs to be the game you want it to be.
- Make a schedule of the tasks you need to get done every day until release (and maybe post-release!)
- Stick to it and use extra time to work on extraneous stuff.
P.S. I’m down to about 60 hours a week on average for Steam Marines 2. Progress.
Thanks for reading,