Everything old one day becomes new again. There comes a time when even experienced programmers are attacking 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 paraphrase 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 truly “understand” the meaning of what is happening around (see also “Zen and the art of motorcycle maintenance” ). We sincerely hope that you will enjoy our attempt to do the same for programming.

1. No delays on Friday

Even if you have a continuous deployment system. Friday is the most inappropriate day to push the master, for an obvious reason: there is only half a day left to correct possible jambs. Usually after upgrades there are bursts in technical support tickets, especially after the release of new features and, inevitably, new bugs. People on Fridays are sleepy, inattentive, tend to postpone everything for later ... you know how it happens.

No one is immune from otherworldly forces that always choose Friday for bugs! So watch the best practitioners, and if you are not sure, pay attention to the industry leaders. For example, Apple supposedly makes releases on Tuesdays , leaving enough time on both sides of such a critical event as a deployment: Monday to test and catch the latest mistakes, and from Wednesday to Friday to make any urgent changes. And with Apple's earnings, you realize that their Deploy model is washed with 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 safely where they are always available in case of an emergency. If you do not have an automated system, then at least a couple of employees will regularly archive the working folder and copy to an external disk. Yes, just a couple - redundancy is not superfluous.

Probably you will never need 9 out of 10 backups made. But one day, like me today, you will want to go back in time and find out exactly when we made this inconspicuous, but completely fatal, mistake that no one has yet noticed! Then you will be glad 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 offenses against people, but learn from mistakes. Make backups, even if it's hard!

3. Get the complete specification before starting development.

I often suffer from the "started too soon" syndrome. Not once had to rewrite large pieces of code, because I did not ask enough questions in the first meetings with the customer, where he outlined the outlines of the problem. Our brain is really tiny, and it hates accuracy, especially when accuracy is difficult and expensive (read: it is necessary for the client). He finds similarities where he is not even close. This is especially true in the design of programs - 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 customers. Don't be like me or my brain. Draw everything on paper, make sure everything is clear, and if necessary you can redraw the system from scratch (taking into account sufficient preparation time - we are all human).

No one will ever be perfect in this process. I still too often rely on guesswork. But since I realized the problem, there were fewer unfounded assumptions. It should be thought of as a computer: unequivocally and thoughtlessly in its logic. In the concept of system design, study borderline situations, be a “tester lawyer” - and you will probably find a design that immediately eliminates the whole classes of errors 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 control. 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 hourly pay is multiplied by 20-500 developers in one room / conference room / etc. This is crazy money, especially in sunny California with its salaries. Time is money! And we are working on this money by inventing intelligent tricks around monsters with tentacles that hide behind each code base and just wait to smash innocent expectations with cruel bugs and crashes.

But we do not always wander through forgotten code catacombs with a trembling torch and sweaty forehead. Sometimes we sit in meetings or intensely discuss something outside of formal meetings. Slack is famous for increasing team cohesion, but at what price (other than monthly fees)? In my experience, Slack dramatically increases your brain's “meaningless time” - the time spent filtering another steady stream of (often inappropriate) sound alerts when you try to do what the company pays for you; that is, to develop and repair a 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 love to say that “the real sees the present”: people who really do the real work, help customers, users and the world - they will be grateful that you asked to end the discussion about whether the new fridge should be black or chrome. "Throw you a coin, what a difference ... we have more serious problems." And many of the people who pay attention to you will be from the manual.

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