A few things I have learnt (Feb 2015 version)

In just about 4 months, it will officially be my 2nd year working in the games industry. I have been meaning to write about what I have learnt in my 1st year but since I was not doing any real development, I withheld such a post. Now that I was given a chance to handle bigger problems, I would like to think that it is nice to write something up here. So far I have had a hand in porting a game to a platform, created features for an existing game, had a hand in creating an app from ground up, among others tasks like maintaining servers.

There's a few things I have learnt and hopefully other developers will read this to get a rough gauge of what they can expect in a big game company, especially if you are working on maintaining social games. I'm going to leave the very technical stuff aside, like attempting to do unit testing or write safe code. These are more of things you do not really learn in school.

So here are 3 that I can think off the top of my head..

1) Follow existing conventions as much as possible.

This applies to everything. Code, excel documents, documentation, SQL scripts, etc. Usually, there isn't much of a written document on conventions; it is up to you to read what was done, understand why it was done this way, and follow. If there is a flaw or if you feel some way of doing things should be changed, complete your task first and bring it up to higher ups. ALWAYS discuss with the affected people if you are making changes, even if you are the lead. 

When the deadline is tight, there will not be time to do a full code review, so in a sense, everyone is responsible for their code. There WILL be legacy stuff that do not follow the conventions. These are basically stuff that went unchecked for whatever reason. Do not follow them, cut your future junior programmers some slack. When future programmers pick up your code and they start going 'is there a reason why this guy isn't follow convention?', it's going to eat up their time, and time is money here.

2) Readable code vs Optimized code

It is ultimately in the heart of every aspiring programmer to push for as much optimization as possible. But the amount of time it could take to develop it, plus the pain it might cost the next programmer to take over your code can be a high price to pay. General rule of thumb is, if the code has an acceptable speed, there isn't a need to optimize it. 

I cannot stress how important readable code is.  If you have to eat slightly more CPU or RAM just to make your code look nicer, I'd say go for it 100%. I have seen some optimized code that was a pain in the neck to decipher and could completely be avoided at no cost whatsoever. For example, I give you 4 variables to store your values in the database, but somehow you want to make use of only 1 variable to store 3 variables by using bit shifting/masking. Sure it looks damn cool if you are creating something for a school project, but the next programmer is going to take like 30 mins to figure out what you are doing AND why are you even doing it like that. 

The most frustrating conclusion any programmer want to make is "because the previous programmer wants to be cool shit". That's not cool at all.

Another good rule of thumb my colleague pointed out to me is to be able to write code such that it is understandable without comments. Comment ONLY when you are doing weird shit. Also, comment only WHY, not WHAT or HOW. WHAT or HOW should be inferred from your code. If you need to explain WHAT or HOW, time to refactor.  

3) Power must be controlled

Programmers are super powerful. I mean, they are the ones who knows (supposedly) the inner workings of every part of the project. It will come to the point where a workaholic programmer, for the sake of saving time, wants to do everything by himself so that his task is completed faster.  Really, to us programmers, adding an extra text to a properties folder is extremely trivial. Clicking on buttons to, say, generate assets, is also trivial.  

But when communication is difficult, like say your teammates don't work next to you, this can get out of hand. Even when we work next to each other, we had our own share of such problems. Committing text files is fine and all thanks to merging tools, but what about more complicated things like images, or even folder structures? What if the folder you are working on disappeared, or suddenly had files attempting to override your files because they have same name? It gets messy. At the worst scenario, you would have to delete your repository (because you cannot figure out the problem or because it is FUBAR) and re-setup your workspace, taking tons of time because of one innocent commit.

For such unstable pipelines, I think it is inevitable but to assign a go-to personnel in charge of it until a clean solution presents itself. Like no matter how inefficient it sounds, stability of the project is more important. You would rather 1 guy screw up, than a possibly 10 other guys screw up.