Unwritten rules are everywhere around you. “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 even realizing it.
We wanted to see what this set of rules looks like in the programming world. Here are the 5 most popular unwritten programming rules we found. Check them out and let us know if you agree with them or not. And, if you have other suggestions, don’t keep them just for yourself – share them with us too.
Unwritten Programming Rule 1: #NoDeployFriday
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 prior to 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.
Unwritten Programming Rule 2: Backup. Backup. Backup!!
We 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, we’re 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, and 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 irrelevant in the short and long run, you will be more than grateful for them in that 5%. What if someone accidentally removed your VM image tomorrow? Or do 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 we repeat the word backup 12 times in only two paragraphs, take our word for it – they’re important.
Unwritten Programming Rule 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.
Unwritten Programming Rule 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 ask as many questions as possible to make sure you 100% understand what the wanted result looks like.
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 which might lead to a change in 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.
Unwritten Programming Rule 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, we’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; “best practices always depend on context” – it’s better to know how to adapt to the context than to try adapting one practice that is labeled as “the best” to every situation; “always strive to simplify” – because 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? Share them with us!
