I\u2019ve had a few programming jobs in my time and at least once in each of them I\u2019ve had a period where I\u2019ve 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\u2019m of the opinion that a happy coder is a hard working coder as I know when I\u2019m happy and enjoying my work I\u2019ll 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\u2019ve compiled a list of points that any good manager needs to take into account when dealing with their programmers.<\/p>\n
1. Tell us when we\u2019re right and wrong<\/p>\n
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\u2019d show my manager the new features; he\u2019d 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\u2019d come over and ask why I hadn\u2019t finished yet, I\u2019d explain and he\u2019d simply accept it and ask me to work a little harder. I was \u2018coding blind\u2019 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.<\/p>\n
There needs to be some way of telling your programmers when they\u2019re right and when they\u2019re 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\u2019t like. If someone is continually running over time on tasks then sit them down and let them know that you\u2019d like them to work a little faster if they could and see why it\u2019s taking longer than the scheduled time to complete their tasks.<\/p>\n
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\u2019ve 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\u2019s time to look whether there are problems within the team.<\/p>\n
2. Let us decide on the specific lengths of milestones<\/p>\n
In nearly every project I\u2019ve been on scheduling has been this secret activity that management and the leads carry out while we\u2019re 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\u2019ve been given and how long they\u2019ve got to do it. Grabbing arbitrary values out of the air and guessing how long a task will take isn\u2019t 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.<\/p>\n
3. Give us faster computers<\/p>\n
This is one of the most expensive of the ten points, but it\u2019s also one of the most beneficial ones. There\u2019s nothing more frustrating than sitting there waiting for my computer to do something simply because there isn\u2019t enough RAM in it. If you\u2019re 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\u2019ll 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.<\/p>\n
4. Don\u2019t get us to do QA<\/p>\n
Quality Assurance is an important part of any project and needs a lot of time spent on it; however programmers aren\u2019t 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\u2019t 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\u2019s 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.<\/p>\n
5. Don\u2019t make entering a bug more than a 1 minute job<\/p>\n
Leading on from point four, it\u2019s 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\u2019t see the bug. The simple fact is that unless it\u2019s 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\u2019t going to do it.<\/p>\n
6. Keep us isolated from the day to day business of the company, but not too isolated<\/p>\n
I was on a project where the boss would come in every single day, or multiple times a day, and ask if we\u2019d finished the project yet. He\u2019d tell us all about the latest publishers he\u2019d spoken to and what they\u2019d said about the product. Programmers don\u2019t need this information on a daily basis and it\u2019s not going to help productivity at all. We\u2019re 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\u2019ll realise that actually none of them are interested and that\u2019s why you have to talk to so many of them.<\/p>\n
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 \u2018almost\u2019 been signed. We like to know what the future is for the software we\u2019ve 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.<\/p>\n
7. Don\u2019t let us find out that you\u2019re charging us out at $100 and we\u2019re seeing $20 of it.<\/p>\n
At every job that I\u2019ve been outsourced to I\u2019ve 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\u2019t know the reasons are feeling. The other problem you have is when you have egocentric programmers that find out they\u2019re only being charged out at $70, they\u2019ll feel undervalued and think you don\u2019t understand just how much pure genius they have squeezed into their craniums.<\/p>\n
8. Talk to us<\/p>\n
This list isn\u2019t some form of divination, it\u2019s 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\u2019ll find a sensitive human being that has feelings and will probably tell you exactly why they\u2019re 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\u2019s anything they can help out with. At other companies I\u2019d be lucky if I spoke to my manager more than once per week. I\u2019d simply churn out the software and his name would be at the top of my pay slip. This doesn\u2019t really make us feel appreciated nor does it let you know how you can help to make your programming team more productive.<\/p>\n
9. But also leave us alone sometimes<\/p>\n
When it\u2019s coding time, it\u2019s coding time. If you need to just have a quick chat about something then come on over, but if it\u2019s the 4th<\/sup> time today, maybe you need to start scheduling daily meetings where you can meet and discuss everything in one go. This doesn\u2019t include scheduling a meeting for 30 minutes into the future and assuming that because you did it in a formal way it\u2019s 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\u2019s 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\u2019ll be lucky if they get back into the zone again that day.<\/p>\n 10. Stop using overtime excessively<\/p>\n Every programmer I\u2019ve 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\u2019s 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\u2019s day, they\u2019ll 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\u2019re 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\u2019d add in those two days. There\u2019s nothing worse for a programmer than looking at code they wrote and not having any memory of it nor any comprehension of what it\u2019s actually for, simply because they were too tired when writing it.<\/p>\n That\u2019s about all. If you have any comments either way on any of these points I\u2019d be glad to hear them. Some of them have been biased towards games programming, however there are a lot of parallel\u2019s between business and games when it comes to disgruntled programmers. Just remember, a happy coder is a productive coder.<\/p>\n","protected":false},"excerpt":{"rendered":" I\u2019ve had a few programming jobs in my time and at least once in each of them I\u2019ve had a period where I\u2019ve 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 Read More<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"enabled":false},"version":2}},"categories":[33],"tags":[],"class_list":["post-34","post","type-post","status-publish","format-standard","hentry","category-game-development"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/pgEc5-y","_links":{"self":[{"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/posts\/34","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/comments?post=34"}],"version-history":[{"count":0,"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/posts\/34\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/media?parent=34"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/categories?post=34"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/tags?post=34"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}