Day in the Life of a Game Programmer/ Team Lead (in Crunch)

Well, the day still starts at 7:00 AM, but the timeline is a bit different in a crunch. See my original post for comparison: http://gameprogrammertechnicalartist.blogspot.com/2010/10/day-in-life-of-game-programmer-team.html

07:00-07:14 (00:14) Wake up to an alarm, keep hitting snooze.
07:14-07:32 (00:18) Shower, (skip breakfast) and leave.
07:32-07:51 (00:19) Leave apartment walk to bus stop.
07:51-08:30 (00:39) Get on bus, rest my eyes, but do not sleep.
08:30-08:33 (00:03) Walk to office, drop stuff off at my desk.
08:33-08:37 (00:04) Grab one of the many coffees of the day.
08:37-08:44 (00:07) Update code, check email, some admin stuff.
08:44-08:54 (00:10) Talk with one of the dev, answer questions.
08:54-09:15 (00:21) Update and print out bug list from QA.
09:15-09:30 (00:15) Stand up meeting for half the dev team.
09:30-09:45 (00:15) Stand up meeting for the other half of team.
09:45-10:00 (00:15) Meeting with server leads, about bug list.
10:00-10:06 (00:06) Grab another coffee, talk about a bug.
10:06-10:36 (00:30) Code.
10:36-10:42 (00:06) Clarify some code standard.
10:42-10:50 (00:08) Give current status.
10:50-10:54 (00:04) Answer some questions about specific feature.
10:54-11:38 (00:44) Code.
11:38-12:18 (00:40) Test and submit some bug fixes.
12:18-12:24 (00:06) Walk to get some lunch, call girlfriend.
12:24-12:36 (00:12) Buy some lunch (Subway), take it to my desk.
12:36-01:07 (00:31) Update repository, eat, and continue to code.
01:07-01:10 (00:03) Give status.
01:10-01:14 (00:04) Code.
01:14-01:21 (00:07) Answer important emails for clarification.
01:21-01:26 (00:05) Code.
01:26-01:29 (00:03) Help answer a developer question.
01:29-01:35 (00:06) Code.
01:35-01:43 (00:08) Grab another coffee, and coffee related break.
01:43-01:48 (00:05) Answer some questions in email.
01:48-01:51 (00:03) Code.
01:51-02:33 (00:42) Help developer debug an issue.
02:33-02:35 (00:02) Grab another coffee.
02:35-02:57 (00:22) Code.
02:57-03:01 (00:04) Answer email.
03:01-03:36 (00:35) Merge code and look over changes.
03:36-03:46 (00:10) Answer questions.
03:46-04:11 (00:25) Code.
04:11-04:20 (00:09) Give status.
04:20-04:24 (00:04) Code.
04:24-04:47 (00:23) Grab coffee with another dev.
04:47-05:59 (01:12) Code.
05:59-06:14 (00:15) Discuss implementation issue with other dev.
06:14-06:27 (00:13) Pizza arrives, grab a few slices and a pop.
06:27-07:17 (00:50) Code.
07:17-07:36 (00:19) Talk with developer, write email for tomorrow.
07:36-09:58 (02:22) Code.
09:58-10:09 (00:11) Add notes and tasks for tomorrow.
10:09-10:43 (00:34) Talk with other devs about tasks, status.
10:43-10:58 (00:15) Leave and walk/wait for bus.
10:58-11:36 (00:38) Rest on bus, phone and reading.
11:36-11:46 (00:10) Walk home.
11:46-12:02 (00:16) Talk with girlfriend, get ready for bed.
12:02-12:36 (00:34) Personal email, brief web surf.
12:36-07:00 (06:24) Sleep, so the whole thing can start again.


Breakdown:

Work:
Administration (email, delegating tasks, status): 2 hour 8 minutes.
Breaks (lunch, dinner, coffee): 1 hour and 14 minutes.
Coding: 8 hours and 33 minutes.
Helping Others: 1 hour and 30 minutes.
Meetings: 45 minutes.

Home:
Computing (web surfing, project coding): 34 minutes.
Exercise: 0 minutes.
Personal Maintenance (food, shower, etc.): 48 minutes.
Reading (including bus travel time): 38 minutes.
Sleep: 6 hours 24 minutes.
Travel (not including bus reading time): 1 hour 26 minutes.

Other Facts:
Read 48 emails.
Sent 13 emails.
No code review.

If you compare this with the previous day in the life entry there are a few substantial differences. Even though I am spending approximately 16 hours and 14 minutes away from home, the coding time still only amounts to half of my day. All the other aspects including meetings, admin and help have gone up, and nothing has gone down (on the work side).

The home side is where all the time goes. Sleep takes a hit (about half and hour less), exercise is non-existent, and coupled with fast food for lunch and dinner is going to make me gain weight and have less energy overall. This plays into attempting to sleep on the bus, but really turns into wasted time, since I want to sleep in the morning (and am too tired to read), but can't really get to sleep on the bus with all the noise and crowded seats in the morning. I also tend to miss making breakfast, but will try and grab something like a banana, apple or bagel on my way out the door to eat on the way to the bus.

There are still a lot of interruptions, a lot more status updates and emails. Organizing the crunch is tricky since there are always "fires" that have to be put out, and as things move faster, more coordination is needed to make everything work smoothly.

With so much time at work, there is very little personal time for any time with loved ones, projects, additional reading, or relaxation. I try and phone when I have free time (lunch and on the bus), but this is not the same as being around. If you are at this pace (or worse) for a prolonged period of time, that means you are on a death march. If this lasts longer than a few weeks (longer than three weeks maximum) it will start to take a toll. This is not the worse pace I have been on (I slept under my desk multiple consecutive nights earlier in my career), but it is a difficult one to maintain.

With so many tired devs, so much extra coordination, many interruptions, minimal code reviews, extra status updates, it becomes a tricky situation to balance. Throw in low energy, running on coffee and a lot of other tired developers and co-workers, it can quickly turn ugly if spirits are not high. Everyone wants to see the project out, but there is still a lot of work to do. I should probably take my vitamins.

Wish me luck,
Michael Hubbard
http://michaelhubbard.ca

One day at a time

How do projects succeed or fail? One day at a time. What is your focus during the day, do you always work on the most important aspects first, or do you get swept up in the tiny details each time. Too often it is these tiny details that become death by a thousand cuts. Sure it is great to have all those little features done and edge cases for functionality, but it so often comes at the expense of major features.

What is your time for iterations, how many iterations do you usually require?

This is often a major issue in larger teams, especially across departments. Tightening up iterations is essential and the decision making needs to be given to the people actually doing the work. Whenever there is someone who says that they could handle all aspects of a project in a day, or week or month, they are often talking about single person efforts where they created the art, game play mechanics and everything else without outside influence. If art or creative requires some feature to be "just so", then the individual who has the final say should be working side-by-side with whoever is developing it until it is complete. If the need for a server call or API to work a certain way, the server dev should be the one writing and using the test cases from the client code. Everytime you introduce a task that requires two people and there exists a separation between those two people, the results will be extremely slow. Instead, having the participants nearly sequestered until the result comes through is essential.

What is better in most cases is to have people that can handle both roles, so there is not a need for two people on those crucial elements. It is also important to understand how much iterations cost. If there are ever more than three iterations on a single element it needs to get hammered out and finalized immediately. Iterations often come from too many individuals involved in the decision making, and the people doing and monitoring the work not being involved enough in the process. If it is not right by the third iteration of a completed work of functionality and can not have the details finalized, it should be put on the bottom of the work pile as a "nice to have". Granted this usually becomes a highly visible topic that makes it difficult to ignore, but it is essential not to waste time on something that can not be decided. When asked for status, ask instead for requirements and also ask for confirmation that these are the final requirements. If there are still issues, ask the people involved to all sit down and get it to work as intended. If those people do not have the time, then it is very likely trivial anyway, and the numerous iterations a product of their ego, and thus good enough as is.

Another big problem is the lack of tools development. Consider tools as the scaffolding to build your project. If you don't spend a little time building tools that improve workflow and minimize time for iterations you will waste a lot of time getting these things done manually. There does need to be a balance though as too much time on tools is also not put into the final product. In most cases tools are somethings you wish you had time to develop for, but don't have time to do for "this" project, having a few people working on tools throughout the project will help minimize this issue when in a crunch.

What it all comes down to is how much closer do you get to your final goal each day? So often time is spent on trivial things that in the end don't really matter to the end result. With every day of effort you should ask yourself, did I focus on implementing the feature that would make the game the most fun, stable or maintainable? If the answer is no, what were you working on, and why were you working on it instead? Often the answer to this is A: it was an iteration on an existing requirement, B: it was a new feature or request, C: it will only take a day to implement, so why not just get it done and over with now.

Every day matters, especially in a crunch.

There is a saying that I always liked, since games are notorious for feature creep and changes in requirements: You will have a good idea today, a better idea tomorrow, but the best idea... never! This is because the best idea today, is not the best idea for tomorrow. Hardware, software, opinions and markets all change, so sometimes you just have to go with a good idea.

Best of luck,
Michael Hubbard
http://michaelhubbard.ca