Improving your team’s productivity by being a Lazy Programmer!

Originally published on my personal medium for #notGDC.

Programmers have a lot of pride, at least most of the ones I know have. We like to build our own libraries, make our own algorithms and some even create their own programming languages! But man, that’s a lot of work! You need to chill sometimes, life is not just work. There’s no reason to be ashamed of being lazy and wanting to skip work sometimes because that can help you and your team! Let me show you how:

1) Don’t do what someone else may already have done for you

New programmers specially have this problem. I know I had.

Last time I checked, at least 1 million games had been released in the world since 1980, so unless you’re making something completely new, there are good chances that someone already solved that problem you’re having. Give it a search, talk to other programmers, ask at StackOverflow or in a more specific forum. Maybe you can’t find exactly what you’re looking for but you may find something that can put into the right path.

2) Don’t get stuck for too long

Sometimes it could be worthy to pay for a library or software that solves your problem. Talk to your boss if you think that will save up time. Just be sure that it fits all your needs before spending the money.

3) Give up!

Every time you heard that little voice inside you saying “give up”… give up. It feels so good (Ultimo Programa do Mundo)

Oh well, that’s life. Sometimes you have to learn when to give up. That problem you thought would take only 2 hours has already taken 3 days and now you realize it will take 3 more days. Are you really sure you wanna do that? It could be time to give up.

Talk to the designer, maybe there’s some easier way to accomplish what you want. Maybe that complex mechanic you want to use is not really that worthy. Isn’t it better to cut it out and spend more time polishing other more important mechanics instead! Have a chat with the designers and you may think about something cooler and simpler to program.

In some cases it could also be solved with art! Talk to your artist, tell him that procedural animation system won’t happen and she’ll have to do it all by hand. And it’s very possible that you won’t be saving time just now, but also in the future when the procedural animation start to glitch and the animators don’t like the result, having to do it by hand anyway. I’ve worked with Flash programming for many years and you have no idea of how many things I solved by using a fixed animation instead of programming it.

4) Good enough is good

It’s great that you’re aware of your code being bad, but making it look good is not a priority. If the performance is really getting in the way of the rest of the game and you have time to fix it, then go for it… later. Worry about making something that work first and something that runs nicely later.

PS: If there’s more people working in the same code, at least make some clear variable names and put some comments in the hardest parts. You don’t have make the prettiest code ever but don’t be a dick.

5) Build tools for your team!

YOU GET A TOOL! AND YOU GET A TOOL! EVERYBODY GETS A TOOL!

It’s not as selfish and dickish as it sounds, let me explain.

Let’s suppose you ended up making that procedural animation system for your game! But the animators weren’t satisfied with the result and keep asking you for changes. Instead of changing it, build a nice tool to allow them to tweak the system themselves! They’ll be happy to be able to make it closer to what they want and won’t bother you and giving you time to fix bugs (and play Overwatch).

So build tools for your sound guys so they can change the music and effects without your help. Allow the designers to tweak the levels and balance the game without needing to ask you, give writers a way to change the dialogue in the game themselves. You don’t need to make some complex stuff with some fancy interface, just something that they can use. Maybe you don’t even need to really program a tool, a simple script that can parse a text file into the game could be enough. The important thing is to find a way to let the team work on what they want without you needing to do it!

6) Go to sleep already!

“At least I’ve fixed the bug”

You have a lot of work and so you stayed up until 5AM coding and now the work is done! Great, but also it’s not really done, it’s full of bugs because programming requires a lot of your brain and lack of sleep can be really harmful for it.

I know, some times you can’t escape working until late. But looking at the code in the morning and thinking “Why the hell I did this? This is so stupid!” doesn’t help either, pushing yourself to the limit can do more bad than good for your code, your team and your health. And a healthy programmer is an efficient programmer!

If you REALLY have to do it, try to spend that time with some task that don’t require much of your brain, don’t implement a new pathfinding algorithm after 28 hours without sleeping.

In conclusion

I still haven’t found a way to improve productivity by sleeping in the bathroom so being that lazy might not help. Also, those things aren’t really laziness but more like taking care of yourself. Don’t be ashamed or feel like you’re a bad programmer for not dedicating 100% of your time for the game and not being able to implement everything you want. You’ve probably heard of incredible programmers that spent 5 days straight coding and created their own algorithm to end world hunger or something but you don’t need to be that. Everyone has their own rhythm, be the best you can be right now and you’ll eventually get there.

As a programmer you’re the one putting together design, art and sound. You’re the one making stuff on the screen move and if you get stuck, the whole game gets stuck. So value your time because it’s important and you’re gonna need it later when the QA kicks in and the bugs start coming back at you!