 |
|
|
| |
Opinion: Game Development And Remote Workers
by Tony Albrecht [PC, Console/PC, Career, Columns, Exclusive]
|
|
| |
|
May 15, 2009
|
| |
[Veteran game programmer Tony Albrecht gives an in-depth look on the positives -- and challenges -- of being a remote worker in game development, and offers advice for successful teamwork from home.]
As the game development industry is getting older, so are its employees. These employees have families that are becoming increasingly important -- and these same families are putting extra demands on the time and even the location of these maturing developers.
One increasingly appealing option is to work remotely –- you get to spend more time with your family and spend more time at work too, so you get your cake and eat it too. But trust me, its not all that simple -– sometimes there is a little too much cake.
I’ve spent the last 2 and a bit years working remotely for a couple of companies with half a dozen teams in almost as many time zones and it would have been a damn sight easier to have been working with them in the same building.
"But…" you say, "but you get to code with no pants on…"
"No!" I interject. "Well, yes, but No! Shut up. Listen to me first, here’s why its more difficult."
Communication is much, much harder. You can’t just turn around and abuse the dickhead behind you who thought that thread safe programming merely meant adding volatile to variable declarations.
You can’t bump into the office graphics guru and strike up a conversation that leads to a new, more optimal way of performing motion blur.
Emails will be misunderstood and misinterpreted – there is no substitute for face to face communication. You can’t underestimate the power and clarity provided by body language. Communication via instant messaging is a pain in the arse for anything of any detail.
You will get overlooked for meetings and announcements –- you are out of sight and out of mind. And the larger the team, the more likely it is that you will be forgotten. Large meetings are awful over the phone –- you pick up a lot of ambient noise, and different speakers in different positions mean that you hardly ever hear what is going on.
Plus, it is an order of magnitude more boring not being there. I mean, its often hard enough to stay awake in some team meetings when you are there, let alone sitting in your room alone, eyes closed as you concentrate on the current speaker, leaning back on your comfy chair, thinking about the code you’re working on, or what you’ll be doing after work, or the last episode of True Blood you’ve just watched… well, you get the idea.
Testing your code becomes far more laborious -– and it is also far more important that your code is robust. The first person to get blamed for code not working is the person that’s recently checked something in who isn’t there. Which, when you are working remotely, is always you.
Here’s the typical cycle for submitting some code while you are working remotely:
You spend a week writing your code. You’ve been very cautious and carefully verify that it works flawlessly with your data. So you go ahead and check out the latest version of the code in the main branch (which has been automatically tested, so you assume that it works) and merge it with your own.
You attempt to test it against your own data, but realize that you need the latest data. So, you do a grab of the latest data in the art repository, hoping that there aren’t too many extra assets to download. When that finally finishes you munge the new assets -- only to discover that you need the latest version of the editor to munge all of your data as there have been some fundamental changes.
Without the benefit of an office full of machines that can be utilised for a distributed munge, you know that you’re going to be waiting for 4 or more hours before you can test again (BTW, the munge process is sometimes called cooking because the ambient temperature of your office rises by 10C while the machines you do have churn through gigabytes of data).
Finally, you test your code against the newly munged data -- only to learn that it doesn’t work. QA assures you (over the phone or IM) that the latest build is working, so you spend a couple of hours trying to debug your code, fruitlessly.
You stagger to bed, say hi to the wife, and sleep the restless sleep of a coder without functioning code. The next morning you spend some more time on your code, then chat with various people about your problem only to find out that the version of the editor that you grabbed didn’t work with the version of the code you had and that it was fixed not long after you checked it out (or that you have to roll it back to an earlier version).
At that point, you check out the working version of the editor, check out the latest version of the code, merge, check out the latest data, compile, fire off a munge, kick the cat, put your pants on and head down the pub.
Yes, it can be that painful -– I’ve spent days trying to check in working code. Even with continuous integration and a good QA team, the lag between your code and data and the main branch can be troublesome to say the least.
Another issue with coding is that you are pretty much on your own. If you are having problems with a programming problem it is very hard to get someone to help you remotely. Applications like UltraVNC are excellent and I recommend that you do peer reviewed code checkins using something like this, but it is (at least initially) a large intrusion on a co-workers time to get them to remote into your machine and help you with your code. It becomes less of an issue as they become more used it but it is still a hurdle to cross.
Sure, you have more privacy and less distractions – actually, no. You have more distractions -– family, a fridge with (theoretically) more food, alcohol, TV, games (not in the fridge), the internet with no-one looking over your shoulder, it’s just started raining and you’ve noticed that guttering is leaking so you get up on the roof to fix it ‘cos you can’t see where it’s leaking when its not raining… and did I mention games?
The temptation to work your own hours "when you feel like it" is quite high – I mean, you’re not impacting on anyone else's schedule, are you, and anyway, you work better at 3am, right? That is, until you pull an all nighter, sleep most of the next day and then can’t be arsed to work the night away again and before you know it you’ve lost a day of work.
Time zones complicate things somewhat also. It’s not too bad if you are only an hour or so out, but when working from Australia with the US or UK, you have a very large discrepancy in work hours. My current employer is in the UK and our regular office hours do not overlap at all -– in order to communicate directly, I need to spend part of my evening working. Sure, that means that I manage to avoid watching some crap TV with The Wife(TM), but part of the reason to work from home was to spend time with the family, wasn’t it?
One of the hardest things I’ve found is the lack of human interaction. I miss the idle banter you get in an office, the pointless chats while making coffee, the new friends you make while arguing over lunch, the things you learn when asking a co-worker to help you with a coding problem.
So you can see that there is some bad thrown in with the benefits of working remote and pantless. There is a lot of good though -– when you hit the zone there is nothing to break you out of it. The flow keeps on going and going. You can modify your working hours (a little) without affecting your routine too much -– an hour here or there to take the kids to the doctor or swimming –- and you can easily put in more hours when the need arises. The 5-second commute is awesome.
There are a few things that you can do to help you deal with working remotely.
You must know the team you are working with. Programmers are notorious for not trusting other people’s code. If you’ve not worked locally with a team before I would advise that you meet with them and spend at least a week or two working on site, learning the ropes, appreciating your workmate’s strengths and personalities and, importantly, socialising with them.
It is important that everyone understands each other’s sense of humor (or lack thereof) -– it helps with textual communication. I would advise that the remote worker and local team have at least one video conference a week: cover what you have worked on, what you will be working on, any problems you’ve been having as well as sprinkling the meeting with idle banter. You need to maintain a social connection with the team -– if people like you, then they are more likely to respond to your emails earlier and help you more.
Be disciplined with your working hours. Start at the same time, lunch at the same time, try and finish at the same time. Regular work hours will help you to maintain a sense of work life and home life -– you need to maintain a sense of separation, otherwise you’ll either end up working all the time or alternatively, watching Oprah and Dr. Phil instead of working.
Take short breaks like you would in a workplace -– culture some rituals. For instance, make a coffee (not instant mouth rot coffee, make something a little more involved. I use a stove top percolator to make beautiful coffee from beans bought at the local market). This will give you the type of break that you would get naturally at work, and give your brain a little time to work on in the background. Be careful that these rituals don’t become a form of procrastination though.
If you have a significant timezone difference, try to schedule some regular hours where you overlap with the team you are working with. Take those hours out of your regular work day, but be consistent. If your workmates expect you to be working within their work hours on a regular basis then they are more likely to instigate communication during those regular “cross over” hours. Make sure that your workmates are aware that you are working –- running a instant messaging client will ensure that your coworkers know when you are online.
With the problems involved with the latency in checking in and building or cooking your data, the best solution I’ve found is to get the local team’s QA to check in and label munged data and binaries when they test a specific code set. This means that you won’t have to worry about building the data yourself and you remove a level of complexity and another source of potential errors.
Also, with the size of modern game’s data sets its often quicker to download 5GB of data than it is to munge it (assuming of course that you have a decent internet connection. If you don’t then I suggest you relocate until you do). Of course this doesn’t work when you are changing the munging yourself.
Be proactive with communication. Answer all of your emails promptly (if you work in a dramatically different timezone then you have the benefit of getting a full day's emails when you log in in the morning). Regularly email team members with questions and even simple communication –- you need to cultivate your relationship.
Maintain an online presence via instant messaging. Don’t let yourself be forgotten. If you are being forgotten for meetings, ring the meeting room yourself. Make sure that management realizes how important it is that you are included.
I’ll mention it again as its so important; video conference at least once a week. The best remote relationship I had with a team was one where we had a video conference every morning. It was just a short scrum type stand up meeting, but invaluable as far as building a relationship with the team and understanding what everyone was doing and, even more importantly, letting your team mates know what you are working on.
So, if you have read this far, congratulations. This is a big topic, one that I deal with daily and one that I think is becoming more and more relevant to the modern programmer. I recommend you read The Pond for an excellent article on working remotely from the point of view of a manager.
I’ve managed a remote worker before and the best thing I can recommend is to call regularly for updates, to catch issues early and to just maintain a base level of interaction, letting the remote worker know that you know they are there and working and that they are appreciated.
It is also imperative that the manager sets realistic milestones for the remote worker and gets regular status updates - it is all too easy for a remote worker to drift off into a little corner of the codebase which is incredibly interesting, yet ultimately irrelevant.
Working remotely is hard. It is more work for manager and worker alike, but it can be very successful and rewarding as long as both parties are willing to address problems as soon as they arise. I'm privileged to have been able to work from home for these last few years - my children know nothing different. Daddy has always been there, and if things work out, Daddy will always be there.
[Tony Albrecht is a console engine programmer who works from home, and contrary to all reports, does actually wear pants whilst working. He sporadically blogs at Seven Degrees of Freedom.]
|
| |
|
|
If I honestly wanted to work without my pants on I'd just ask my co-workers and manager if it would bother them if I took my pants off. I think most developers (from what i hear) are fairly lax in the dress-code, so how could not wearing clothes violate a dress-code? It's not like you're naked or anything (unless you go commando). Its already a fairly male dominated industry anyway, and if it helps you work, who has a problem?
It probably wouldn't hurt to ask, the worst they can say is 'no' (and your going to embarrass yourself in one way or another eventually so stop trying to pretend like you can prevent it). You know what they say, 'there are no stupid questions'.
One option of course is a constant video stream. But you'd have to have your own little area and people would have to come to you.
There's also the option of RC cameras you can drive around the office. Though if someone got mad at you, they could drop you in the toilet...