Rocket Scientists’ 10 Commandments for a High-Quality Coding Future
We jotted down ten commandments that, if followed carefully, are guaranteed to leave you with some cracking code, help your software projects reach their goal and make competent individuals better professionals and people regardless of their job descriptions.
Okay, to be fair, no curse will befall you if you choose not to follow these commandments. Let’s change the word to tips. Think of the following ten points as things you should do and things you should avoid to ensure the creation of beautiful code. Even though these commandm... tips have been written with developers in mind, all those regularly involved in software projects can benefit from reading this through. With ten years of experience under our belt and a swarm of HC consultants in our corner, we can confidently state that this is something we know a little bit about.
Thou shalt read further (now that was a proper commandment)!
1. Have respect for your colleagues
Quality emerges from a mix of friendliness and the ability to see past your toes and into the horizon. Code is written for colleagues, who, more often than not, are people themselves. In other words, don’t write for machines. A computer does what it’s told, but it doesn’t care whether the methods used are illustrative and easy to read.
It’s true that developers can’t always remember the circumstances in which a code came into being a month ago or why the solutions are the way they are. But here’s a word for the wise: it’s always possible to send your future you some fan mail through, say, Javadoc, for example.
2. Be patient
Coding requires some patience from both the code author and the client. When you work on something complicated and create something new, you need to do a lot of thinking, experimenting, testing, negotiating and reworking. In other words, things that don’t necessarily seem to be going anywhere. If you try to rush or cut corners at this point, the quality’s going to be second-class at best.
A person who’s just starting out in the field can spend some time learning to turn the crank, as long as they’re not going to be forced into becoming the designated crank turner with an exploitative employment contract. A person who’s not being exploited is naturally curious and willing to learn new things.
Doing your stint in the daily grind of programming can also be a good experience for some. An intensive course in crank turning may open up the world of coding for someone for the first time and serve as a good foundation for further learning, whether it be through self-tutoring or through some advanced courses.
Remember that learning to code at the age of three on your daddy’s Commodore 64 is not a prerequisite for becoming an expert at a later stage.
3. Be detailed enough in your documentation
To refer to the first commandment: you never write a code for yourself but for the person who’s going to read the documentation and code next. And if worse comes to worst, it will be the original coder themself!
“The code is the documentation,” some may say. However, this is yet to be true for anything more complex than “Hello World”. Someone with programming skills can (usually) figure out what a command does by reading the code, but this isn’t enough to shed light on why things are done the way they are or what the code is trying to accomplish. But once this much is clear, even a weird-looking, foreign code can provide the rest of the documentation.
4. Write code that’s to the point
A good code focuses on solving a task or problem in a way that’s as succinct and dummy-proof as possible. Usually, when you try to make everything as short as possible, it tends to end up pretty effective as well. Chop everything into little chunks but never chop the same thing twice.
If an algorithm happens to look unnecessarily complicated later on, show some mercy to the reader by leaving a comment: “Don’t bother trying to understand this. Even I can’t figure out why this works. BR, Author.”
5. Only fool around in your spare time
Or prepare yourself for the full FUBAR. Only resort to using the idiosyncrasies of different programming languages when they actually bring some benefits to your work. Leave all kinds of gimmicks and poindexterisms to your own projects. It’s preferable to write a snippet of sure-fire code that’s a couple of lines longer than to produce an ultra-short but completely opaque piece of tomfoolery that you yourself are unable to decipher the next week.
This can understandably be difficult, remembering how we used to give our computer class teacher an ego boost by telling them “I am sorry if my program seems too complex, but my brain refused to sink to the desired level of unsophisticatedness.”
6. Don’t take risks when quality’s at stake
Projects that have been forced through the pipeline are bound to cave in sooner or later. Typically, this will happen as soon as there’s a need to take on a competitor that has entered the same arena better prepared or when you need to implement a project that’s been scraped together using investment money.
It’s the company image that will be hit the hardest, so save yourself the frustration of realising that you managed to make a save somewhere where it wasn’t wise.
7. Pay attention to different user groups
In the future of our dreams, accessibility is guaranteed by various technological solutions. Sooner or later, cyber and nanotechnologies will begin to replace damaged senses and fix things like physical disabilities. Before we get to that point, however, it may be a good idea to have a dedicated person who’s responsible for this part of the QA.
The most important characteristics of UX designers resemble those of a good developer, since these areas overlap to a great extent.
8. Trust those around you
Being in a hurry and under pressure may make you reluctant to listen to an expert as well as overconfident and too stubborn to be able admit any shortcomings in your expertise. Possible side effects may also include cheapskatism and reluctance to figure out how much things actually cost.
Don’t give into the dark side. Take a breather, think about what you’re doing and have a feel-good smoothie. The world will seem a bit brighter once you do.
9. Don’t underestimate the significance of your work environment
If your working conditions are subpar (due to noise, lack of room and the office being restless, for example) or if your tools are not up-to-date (for example, if your user rights are limited, your work computer sucketh or the developers’ IT infrastructure is designed for regular office workers), it’s no wonder if you feel like you’re about to have a litter of kittens.
All of these things affect quality, so double check that they are really in order. Getting some insight into user experience isn’t a bad idea here either.
10. Be a softie
A developer isn’t an extension of a machine, and therefore shouldn’t be treated like a piece of equipment. If the workplace environment resembles an internment camp, it doesn’t bode well for the future.
It should be remembered that all employees have feelings, and that feeling good and nice leads to good results. In a toxic work environment where people are worn out, aiming for high quality is absurd. A soft and people-oriented environment, on the other hand, will promote quality, good vibes and innovation.
This year, Rakettitiede celebrates its 10th anniversary while keeping a keen eye on the future. We want to keep boosting our clients’ demanding software development projects in the decades to come, so we teamed up with the Finnish Central Association for Mental Health to see what we could do to improve well-being in the industry. We decided to start a countdown to a more mental health positive tomorrow and embarked on a journey to find ways to develop organisational cultures and promote employee well-being.
Selling a recently serviced and inspected consultant in mint condition. Buy yours today!
Read the other parts of the series:
Rakettitiede claims: The Primary Programming Language of the Future is the Mind
A Five-Star Mind Menu for Developers - A Diablog
Hot or Not? Timelapsing through the World of Programming Languages