“No Deployments on Friday” and three more unspoken development rules

Original author: Tobias Merkle
  • Transfer
Everything old one day becomes new again. There comes a time when even experienced programmers step on the same rake. It is impossible to list all the “unwritten rules" of any discipline, in part because many of them are not even rules . This is often a way to rephrase abstract and eternal truths.

Marie Kondo made a career by applying the universal principles of efficiency, cleanliness and beauty to the household task of housekeeping. It turns out that many people just need a translator between eternal wisdom and their daily lives in order to really “understand” the meaning of what is happening around (see also “Zen and the art of motorcycle maintenance” ). We sincerely hope that you enjoy our attempt to do the same for programming.

1. No Friday Deposits

Even if you have a continuous deployment system. Friday is the most inappropriate day to start the master, for the obvious reason: there is only half a day left to fix possible jambs. Usually, after updates, surges in technical support tickets are observed, especially after the release of new functions and, inevitably, new errors. People on Fridays are sleepy, inattentive, tend to put off everything until later ... you know how it happens.

No one is immune from otherworldly forces who always choose Friday for bugs! Therefore, observe the best practices, and if you are not sure, pay attention to industry leaders. For example, Apple supposedly releases on Tuesdays.leaving enough time on both sides of such a critical event as the deployment: Monday to test and catch the latest errors, and from Wednesday to Friday to make any urgent changes. And with Apple's earnings, you realize that their deployment model is washed in blood and sweat.

2. Regular backups

It is hard to overestimate the importance of regular backups. Our entire industry is built on an abstract progressive backup system. Of course I'm talking about Git, but this is not enough. Your database, cryptographic keys, configuration files, VM images, images / videos ... even imported packages should be stored securely where they will always be available in case of emergency. If you do not have an automated system, then let at least a couple of employees regularly archive the working folder and copy it to an external drive. Yes, just a couple - redundancy is not superfluous.

Probably you will never need 9 out of 10 backups. But one day, as I am today, you will want to return to the past and find out exactly when we made this inconspicuous but completely deadly mistake that no one has ever noticed ?! Then you will be glad that you took the time to backup. Or, you know, when a new employee accidentally deletes 100,000 lines of code. It happens. We do not hold grudges against people, but learn from mistakes. Make backups, even if it's hard!

3. Get the full specification before starting development

I often suffer from the "start too soon" syndrome. More than once I had to rewrite large fragments of code, because I did not ask enough questions at the first meetings with the customer, where he outlined the contours of the task. Our brain is really tiny, and it hates accuracy, especially when accuracy is complex and expensive (read: needed by the client). He finds similarities where he is not even close. This is especially true in program design - in a fairly complex application, ten similar buttons perform a dozen completely different tasks. Before you start coding, you should catch these subtleties if you want to get the most out of your time and the time of your clients. Do not be like me or my brain. Draw everything on paper, make sure everything is clear,

No one will ever achieve perfection in this process. I still rely too much on guesswork. But since I realized the problem, unfounded assumptions have become less. It should be thought like a computer: unequivocally and thoughtlessly in its logic. In the concept of system design, study border situations, be a “tester’s advocate” - and you will probably find a design that immediately eliminates whole classes of errors that are allowed in a less thoughtful design.

4. If you see unimportant nonsense, say so

Try to gently stop or prevent unproductive discussions before they get out of hand. Our time in the office is almost as valuable as the 3-8 hours we spend unconscious every night - that is, it is very important! From a business point of view, the more people there are, the more effective the meeting should be, because the hourly wage is multiplied by 20-500 developers in one room / conference room / etc. This is crazy money, especially in sunny California with her salaries. Time is money! And we work out this money by inventing intellectual tricks around monsters with tentacles that are hidden behind each code base and just wait to break innocent expectations with cruel bugs and crashes.

But we do not always wander through forgotten code catacombs with a trembling torch and a sweaty forehead. Sometimes we sit at meetings or discuss something tense outside formal meetings. Slack is famous for increasing team cohesion, but at what cost (other than a monthly fee)? In my experience, Slack dramatically increases the “meaningless time” of your brain — the time taken to filter out another constant stream of (often inappropriate) sound alerts when you try to do what the company pays you for; that is, develop and repair useful code. And people quite easily fall into unnecessary disputes.

It's okay to ask to end the discussion if it takes too much time. Nowadays, children like to say that “the present sees the present”: people who really do real work, help customers, users and the world — they will be grateful for asking you to end the discussion about whether the new refrigerator should be black or chrome plated. "Yes, you throw a coin, what's the difference ... we have more serious problems." And many of the people who pay attention to you will be from leadership.

Thank you for joining me on this journey. May you see the same wisdom as those who first wrote these tips before us. And please, if in your experience you have learned some other unspoken rules, write them and let us know!

Also popular now: