Introduction
I’m working as a programmer for a few years. I have experience in small teams as well as companies with over a hundred of employees. I’ve been working not only in gamedev but no matter of the company’s profile or team size, I’ve noticed a specific type of behaviours over the years. Those behaviours in many cases were negatively affecting my work and my coworkers.
I’d like to highlight something from the start: those remarks might seem really trivial. However, I think that everybody was or might be at a certain point in career, where a given mistake have been made or it might happen in the future. Errors which I’ll point out here, won’t be only connected with programming but also with so-called soft skills or certain work attitude. Those mistakes will be my personal ones but I’ve also noticed them among my colleagues. My opinion about them might be highly arguable, of course. What is more, if you haven’t made those mistakes in your career – that’s great. And if no one pointed them out to you, that’s even better.
Teamwork
Quality Assurance / testers are my worst enemies.
The biggest nonsense I’ve heard in my life! The worst thing about it is that many teachers, books, and your surrounding will repeat it and put it into your head. QA verifies your work and points out mistakes. Of course, having to revert and fix your code again because a tester has found something will annoy you. It will annoy you even more, when they’ll rub it in your face. But then – let it be a motivation for you to not give them satisfaction next time. Analyze again different use cases, double or triple check your code. Try to break it! If you’ll work properly with QA people, your code will become much better with every patch.
I’d like to mention a book that’s really worth to read, written by Nassim Nicholas Taleb titled: “Antifragile: Things That Gain From Disorder.”
Taleb is a statistician and risk assessment specialist. His books revolve around mathematics, philosophy, sociology and reveal surprising relations between things around us. In the book mentioned above, the author introduces a new term: “antifragile”, which describes a state of an object, which meets random external factors. Due to those factors given object builds up immunity with every new challenge. Obviously, it’s a strong simplification of the matter, and I do recommend the lecture. In our field, I’d like to stretch that term to the code. An iterative and creative process which is bouncing back between code programming and testing hardens the code – just like a piece of glass. It becomes more and more antifragile, which benefits the entire project. Appreciate it, accept it, and work on it.
I’m surrounded by idiots, so I’ll do it my own way.
You have to be quite impertinent and self-confident to say that out loud. Even if your superior might not be qualified enough, you cannot just not follow established specification. If you think that proposed solution is wrong or impossible to achieve in given time, state your arguments and try to come to some agreement. The boss is not technically savvy but leaned into marketing area? Show the errors in a spec from his side. Not strong enough to fight it through alone? Talk to colleagues, who can help. Believe me, you don’t want to make your boss unhappy on purpose.
You can always say: “Everybody has the right to be wrong.” But it works both ways. Nobody is infallible. If you think that your solution is better, prove it. However, take other side’s opinion into consideration. Having 5 years more of work experience doesn’t make the younger colleagues idea automatically wrong. If somebody has a better solution, which won’t cost a lot to carry out – accept it, admit it, say thank you. It’s not a hard thing to do and may profit in the future.
You can read more about it here:
https://www.monster.ca/career-advice/article/my-boss-is-an-idiot
Why should I get along with others? I won’t waste my time for dealing with people…
In relation to the previous paragraph – basic life motto: “Don’t be a dick.” If you’re not a communicative person – you don’t have to be! Nobody expects you to be the heart and soul of the community. Just try not to be rude to your colleagues and don’t gaze at your own navel. You don’t know the moment you’ll be in trouble and need. If you’re going to annoy everybody around, don’t expect a helping hand from anyone. Sometimes it’s worth to spend half an hour of your precious YouTube time on helping somebody.
You can read more about it here:
https://www.theblot.com/dont-dick-work-practical-guide-7719621
Work organization
Why do I need the specification? I have it all in my head!
If you really think that way, to be honest, your specification is in completely different place. Along with your code. You have an idea? Some design? Plan? WRITE IT DOWN.
Analyze pros and cons of given solution, describe expected input and output. Believe me, most of the errors can be eliminated before implementing anything.
Of course it shouldn’t be art for art’s sake, and simple issues don’t need an epos of additional description. But those few lines of comment before writing any code might come in handy, especially when the spec will change over time.
Moreover, always demand specification detailed enough for you to know what to do from the beginning to the end. Something is wrong or unclear? Ask, ask and ask again.
You can read more about it in those articles:
https://www.toptal.com/freelance/why-design-documents-matter
https://www.joelonsoftware.com/2000/10/02/painless-functional-specifications-part-1-why-bother/
Programmers shouldn’t test their own code.
The most popular approach, which, sadly admitting, sometimes I still have, and then bitterly regret. You’ve written a code with a given spec? Great. If you didn’t have one, you have wasted another moment of your life. Specification should always describe what you can expect from code and what are the limitations.Knowing that – try to break it for starters. Go with some edge cases or some “impossible” or “too obvious” input. Don’t waste the time of QA team. You should know already they’re not your enemies.
You can read about it in those articles:
My code is a snowflake, and my functionalities are like my children.
Every programmer thinks, that his code is perfect. At least in the beginning. That’s the perfect application of Dunning-Kruger effect. In a nutshell: “The less you know, the more confident you are about what you say or do.”
In time, you’ll notice much more initial problems during coding, anticipate possible loopholes. To have better perspective about it, find your own year-old code. Or even older, if you can. I do it myself sometimes. Then I think: “Jesus, they should’ve got me fired for that piece of crap!” but in a different perspective I see how much I’ve got better from that time.
The sooner you’ll realise, your code isn’t the National Treasure and even after weeks of hard work, your dear precious will land in dumpster, the better. This is your blood and sweat, may be even your Magnum Opus but in most cases you don’t decide whether anybody would ever see it. Be prepared for that.
Why would I ever need a code review?
Yes… Legendary code review. A thing that should be mandatory everywhere but in practice even the biggest corporations think it’s redundant. If you don’t know what is it exactly, let me explain. After you finish writing a piece of code, before going to QA, another programmer (in most cases more qualified colleague or programming lead), goes through your code changes assessing them in terms of style and functionality. If some standards are not met, the reviewer writes down suggestions and sends the changes to the original author.
You cannot even imagine how easily you can eliminate bugs that way, even before first QA testing session. Of course if it’s done properly. Even if your company does not conduct it officially, ask your colleagues to have a glimpse on your code before sending it further. It might even be after some time but have a second opinion somewhere. Alternatively – try to acquire a habit of checking your old changes, from a week before for example. Spend just a little while to double check and verification. Maybe QA haven’t found something? It might also pay off some of the technical debt.
You can read more about it here:
https://www.mobify.com/insights/why-code-reviews-are-integral-to-software-development/
Time underestimation will show I’m a professional. I’ll work some overtime, and everything will be alright.
Firstly: no, it won’t. If you’ve declared 2 weeks for a task and after a half of that time your code doesn’t work on expected input, you’re screwed. Why? Code review, tests, patches, code merging… You’re really screwed.
Secondly? There’s no second point to it! Run to your superior on the double and ask for additional time. Otherwise, you will look something like that:
And with every additional hour at work you’ll be hating more and more your project, your work and yourself as a bonus. Pareto principle has application here as well. Twenty percent of work results (everything mentioned above) will take eighty percent of total work time.
Respect it, respect your work and yourself. Believe me, burning out your health won’t improve quality of the final product and the only person that will be in loss, is you.
Summary, part 1/2
This part described basic problems of working with other people and organizing yourself. Next part will continue that subject and finish up with some more technical elements.
Footnote
Graphics used in this article are properties of their respective owners:
https://images-na.ssl-images-amazon.com/images/I/41yKG1SbjsL._SX323_BO1,204,203,200_.jpg
https://cdn-images-1.medium.com/max/550/1*RxmPeSybIUtxea4Vh98y2g.jpeg
http://www.hanselman.com/blog/content/binary/Windows-Live-Writer/197e1bef071c_122CC/There-is-an-I-in-TEAM_73688c54-07a7-41de-be61-0576cd5d83fb.png
https://i.pinimg.com/736x/17/d2/91/17d291b13c3210495c98ee7142d41355–o-reilly-software-development.jpg
https://i.pinimg.com/736x/d1/07/17/d107178c10a908b3ec8aae3082f6dd58.jpg
https://understandinginnovation.files.wordpress.com/2015/06/dunning-kruger-0011.jpg
https://cdn-images-1.medium.com/max/800/1*INwRDJ_vspfJKkyFpv5jww.png
https://pbs.twimg.com/media/CiQ0haFWgAARgpx.jpg
http://ryanengelfit.com/wp-content/uploads/2016/09/15diagram-1024×507.jpg