I’ve had a few programming jobs in my time and at least once in each of them I’ve had a period where I’ve been unhappy. I wondered if this was simply because I get bored easily or that I complain too much, however after talking to my colleagues in all of my jobs I found most people around me felt the same way. Now, I’m of the opinion that a happy coder is a hard working coder as I know when I’m happy and enjoying my work I’ll be working at peak capacity and often will work an extra hour or two in the day. Obviously different projects have differing levels of interest to each of the programmers on the team, but I’ve compiled a list of points that any good manager needs to take into account when dealing with their programmers.

1. Tell us when we’re right and wrong

A few years ago I was working on a project where I was given tasks to perform that ranged from a week to a couple of months in length. At the end of each task I’d show my manager the new features; he’d look them over and then give me my next task to go on with. He never commented whether he liked or disliked what I had done. Occasionally if the feature was running over he’d come over and ask why I hadn’t finished yet, I’d explain and he’d simply accept it and ask me to work a little harder. I was ‘coding blind’ and had to just keep pumping out features as if we I was production line. Money goes in the front, I sit there working away, and software comes out the other end.

There needs to be some way of telling your programmers when they’re right and when they’re wrong. If someone does a particularly good job, tell them, even let the whole team know in a simple email that the latest feature is exactly what you were looking for. On the same token, if someone is slacking off and does a poor job with something let them, constructively, know that there were particular parts you didn’t like. If someone is continually running over time on tasks then sit them down and let them know that you’d like them to work a little faster if they could and see why it’s taking longer than the scheduled time to complete their tasks.

Some managers have a system such as this in place, however most of them will tend to concentrate on the negative feedback. Far too many managers will happily keep their programmers back late if they’ve made mistakes or are behind schedule, but will simply dish out new tasks if they finish early. Make sure the split between giving positive and negative feedback is as even as possible and if you find you’re always dishing out negative comments then maybe it’s time to look whether there are problems within the team.

2. Let us decide on the specific lengths of milestones

In nearly every project I’ve been on scheduling has been this secret activity that management and the leads carry out while we’re not around. All of a sudden this magical schedule is produced and each of the programmers warily open up project or excel to see what they’ve been given and how long they’ve got to do it. Grabbing arbitrary values out of the air and guessing how long a task will take isn’t helping anyone, and is a sure way to annoy your programmers. The best option is to figure out a ballpark figure, put it in the schedule then sit down with each of the programmers and talk to them about how long they think they will take on that particular task. Whatever your means of deciding, make sure that the programmer working on the task is the one who gets the final say in what value goes down in stone on the schedule. They will feel more responsibility for the task and it will be far more accurate estimation.

3. Give us faster computers

This is one of the most expensive of the ten points, but it’s also one of the most beneficial ones. There’s nothing more frustrating than sitting there waiting for my computer to do something simply because there isn’t enough RAM in it. If you’re working on a game then give your programmers the best video cards you can afford. It will not only show that your company is doing well, it’ll also make an early un-optimized debug version of the game playable so your programmers can start getting a feel for the game as early as possible. When it comes to CPU and RAM upgrades you also get the added advantage of build times being substantially faster which means your programmers spend more time coding and less waiting for it to build.

4. Don’t get us to do QA

Quality Assurance is an important part of any project and needs a lot of time spent on it; however programmers aren’t the best people to be doing the core of your QA work. Programmers have spent years refining their skills so they can make the computer do things the average user didn’t even know were possible. Being told to try alt-tabbing to and from the application for 6 straight hours is not the best use of these finely honed skills. It’s a waste of time, it becomes boring extremely quickly and it will make your programmers feel worthless. Hire a bunch of college students at a few dollars an hour to come and do the boring tasks, leave your programmers to pumping an extra 5 fps out of your latest game.

5. Don’t make entering a bug more than a 1 minute job

Leading on from point four, it’s important to make sure your programmers do enter bugs if they find them in their day to day programming. A while back I was on a project where the list of steps required to enter a bug was astronomical. It took about 5 minutes to follow all of the steps. Not only is it wasting your programmers time, but your programmers are going to do as I (and every other programmer on the project) did and simply pretend like they didn’t see the bug. The simple fact is that unless it’s a simple task of entering the bug into the system or emailing the QA department with simple instructions on how to reproduce the bug your programmers aren’t going to do it.

6. Keep us isolated from the day to day business of the company, but not too isolated

I was on a project where the boss would come in every single day, or multiple times a day, and ask if we’d finished the project yet. He’d tell us all about the latest publishers he’d spoken to and what they’d said about the product. Programmers don’t need this information on a daily basis and it’s not going to help productivity at all. We’re smart people so if you come in every day and tell us that another publisher is interested in the product then after a while we’ll realise that actually none of them are interested and that’s why you have to talk to so many of them.

The other end of the spectrum is not letting your programmers know anything about the project. This is almost as bad as being interrupted daily to find out that the deal has ‘almost’ been signed. We like to know what the future is for the software we’ve put our love and sweat into and being left in the dark is not a good feeling, especially in the games industry where so many studios are closing down recently.

7. Don’t let us find out that you’re charging us out at $100 and we’re seeing $20 of it.

At every job that I’ve been outsourced to I’ve known, through some means, exactly how much my employer has been making off my time. I know the reasons behind these mark ups and it still annoys me; imagine how the programmers that don’t know the reasons are feeling. The other problem you have is when you have egocentric programmers that find out they’re only being charged out at $70, they’ll feel undervalued and think you don’t understand just how much pure genius they have squeezed into their craniums.

8. Talk to us

This list isn’t some form of divination, it’s just how I as a programmer, feel about my job. If you actually make your way through the caffeine rich atmosphere and excuse the lack of social skills attached to your average programmer you’ll find a sensitive human being that has feelings and will probably tell you exactly why they’re not happy. Some managers have been quite good in this regard and have talked to me regularly about how my work is going and if there’s anything they can help out with. At other companies I’d be lucky if I spoke to my manager more than once per week. I’d simply churn out the software and his name would be at the top of my pay slip. This doesn’t really make us feel appreciated nor does it let you know how you can help to make your programming team more productive.

9. But also leave us alone sometimes

When it’s coding time, it’s coding time. If you need to just have a quick chat about something then come on over, but if it’s the 4^th time today, maybe you need to start scheduling daily meetings where you can meet and discuss everything in one go. This doesn’t include scheduling a meeting for 30 minutes into the future and assuming that because you did it in a formal way it’s going to be any less distracting. Every time someone interrupts me it takes me between 5 and 30 minutes to get back on track. This is the simple truth of programming, there’s a lot going on upstairs and stopping for human interaction usually clears out most of this data. I also pity the manager that interrupts a programmer when they’re in the zone. Not only will the programmer be angry, but you’ll be lucky if they get back into the zone again that day.

10. Stop using overtime excessively

Every programmer I’ve ever worked with has achieved less work per day the further they get into overtime. For the first few days productivity goes up substantially, but after about the third day programmers start getting tired, and unhappy about working so much. There is a time and place for overtime and in the game industry it’s a necessary evil of the current developer-publisher relationship, however it needs to be kept down to no more than one work week. For every hour that you add to a programmer’s day, they’ll usually spend fifteen minutes of it complaining, thirty minutes surfing the web in protest, and fifteen minutes drinking coffee to stay awake. Factor in that time spent programming becomes less productive in crunch time, and you can quickly see that you’re actually hurting the schedule. The best example of this was when a few of us had to keep coding for two straight days before E3. We certainly got all the work done, however we spent the 3 weeks after we returned from E3 fixing the bugs we’d add in those two days. There’s nothing worse for a programmer than looking at code they wrote and not having any memory of it nor any comprehension of what it’s actually for, simply because they were too tired when writing it.

That’s about all. If you have any comments either way on any of these points I’d be glad to hear them. Some of them have been biased towards games programming, however there are a lot of parallel’s between business and games when it comes to disgruntled programmers. Just remember, a happy coder is a productive coder.