The most popular unwritten rules developers stick to.
You are surrounded by unwritten rules. “Let people get off an elevator or train before you get on”, “Do not swipe left or right if someone shows you a photo on their phone”, or “Don’t ask for something if the person only has one left — gum, piece of cake, etc”. Most of the time, you follow them (hopefully) in your daily routine without realizing it.
I wanted to see how this set of rules looks like in the programming world. Here are the 5 most popular ones I found. After you check them out, let me know what’s your take on them. And, if you have other suggestions, don’t keep them just for yourself — share them here. Let’s go!
There’s a debate going on whether this rule is beneficial or not, as some say it promotes having a risk-averse kind of mindset. The thing is that pushing to master on Fridays gives you only half a workday to fix whatever it is that went wrong. It’s also the day when we’re more prone to push things off, especially as the end of the workday approaches. Don’t lie and say you’re immune to the powers of Fridays. Nobody is.
For example, Apple only ships software on Tuesdays. This way, they leave enough time on both ends of the critical development event: Mondays are for practicing and solving last-minute bugs, and from Wednesday to Friday people focus on patching up any urgent changes before the deployment. Other reasons to avoid deploying on Fridays are related to people not being available to answer any urgent questions you might have or to catch and fix new bugs.
2. Backup. Backup. Backup!
I hope you’re already aware of how important backups are. And that you maintain them regularly. As It’s hard to overstate the importance of backups, I’m going to say it again: Backup! Yes, do keep your repository up to date with every line of code you write, that’s helpful. But you should also ensure you have a backup for your: database, configuration files, cryptographic keys, VM images, images/videos. Actually, you should have a backup for e.v.e.r.y.t.h.i.n.g. When you run out of storage, go get an external hard drive.
Even if 95% of backups are useless in the short and long run, you will be grateful for them in that 5% of the time. What if someone accidentally removed your VM image tomorrow? Or you want to roll back to better analyze a bug? You can always count on your best friend, the backup. So, even if it might be time-consuming, make sure backups are among your priorities. If I repeat the word backup 12 times in only two paragraphs, take my word for it — they’re important.
3. Avoid Bikeshedding in team discussions
Also known as the law of triviality, it refers to when a dev team spends too much time focusing on something easy/trivial rather than on the bigger/harder issue at hand. Have you ever been in an important meeting where someone derails the topic completely by asking a simple question such as: “What color should we use?”. That’s how the law of triviality, also known as bikeshedding, was born. When you notice the meeting is no longer productive, as the discussion goes towards trivial details, say something.
Why is this called bikeshedding, tho? A quick summary of the story behind the metaphor: a committee has the task to design the new Nuclear Power Plant; Even though the meeting is going well, one of the participants manages to derail it completely by asking “Can we get a bike shed?”; The question causes everyone involved to argue about the trivial details, as everybody wants to share their opinion on how the bikeshed should look like. Urban Dictionary also sums up the idea very well.
4. Know what your code should do before writing it
It might seem obvious, but there are times when programmers found themselves stealing a march. Due to not getting enough specifications before starting, you risk having to rewrite parts of your code. What you can do is to ask as many questions as possible.
Don’t fret if it happens, as it’s not always up to you. Clients might change their minds or they might be unsure of what they want in the first place. Meetings might generate new ideas that twist the desired result. But it’s important to beware of this and, if you can, wait for all the details before starting to work on a project.
5. Test your code before shipping it
It saves you and your Testing Engineer a lot of time. If you send your build to be tested right after you finished working on it, without trying it out yourself, you’re making things more complicated than they should be. It’s like being in an unnecessary tennis match with your Testing Engineer, where both of you are very skilled and where your build is the ball.
To avoid this, take a few minutes to run your code through some test scenarios. If everything looks fine, send it to your Testing Engineer. The point is not for you to catch all the bugs, but to see if there are obvious mistakes that you can correct before the actual testing process begins. This practice speeds up the whole process and both you and your Testing Engineer will be more than grateful for this working style.
Among these 5 rules, I’d like to point out a few more that almost made it to the top and deserve honorable mentions:
- It’s okay to not know everything — asking for help is more efficient and productive than trying to learn everything or doing everything all by yourself;
- The best practices always depend on context — it’s better to know more practices and how to adapt them depending on the context;
- Always strive to simplify — the most elegant solutions are more often than not the simple ones.
Through new experiences, new rules will appear. So, what unwritten rules could you develop based on your experiences? Or what are the ones you live by while wearing your programmer shoes?