The Great Doctrine or 10 simple rules that any developer should follow

The Great Doctrine is a quintessence of the programmer’s wisdom. For decades, the doctrine was passed by members of the secret order of programmers by word of mouth, from generation to generation. Unfortunately, the teaching began to be thought out and contaminated with different interpretations. We see the emergence of new heretics, which are intentionally distorting the doctrine, to instill doubts and horror in our hearts. The Order had no other way to save the truth except for making the doctrine public. Below is the most accurate version of the original doctrine, which was recovered bit by bit by a small group of initiates.

1. The main goal of any programmer is a working product and happy users

Users should never suffer (at least, not more than usual). For example, if you roll out a fix that leads to user suffering, no matter the reason, roll back your fix and deal with the issue in a separate branch. Silly users know nothing about bad people who have used undocumented features of your excellent API and so on. The direct consequence of this statement is that any change in the product should not make it worse than it was before. If it turns out that the product has become worse, roll it back to the previous version.

2. Remember that you are not alone on the team

Let’s say you think that the problem can be solved simply by introducing Paxos. However, besides you, there are five more people on the team and they hardly even want to know what Paxos is. Moreover, it is unlikely that people who come to you every day for an interview have even heard this word. The problem is not with your colleagues. The problem is with you, your decision can only be supported by you. If the solution is not suitable for your team, find another one. Do not be categorical, look for compromises, and find a way to resolve conflicts that will satisfy everyone. For example, the last word of the team lead.

3. Only a Sith deals in absolutes

For example, run only one process per container in Docker, use only immutable variables, follow the OOP approach only, write everything only in Vim, position the MacBooks as ideal devices that “just work”, say that Java cannot be used because of the garbage collector, which sometimes does stop-the-world, or say, for example, that Erlang has remsh and hot code loading, and therefore all other languages are useless. All of these are heretical teachings. Another interpretation is that one should avoid categorical statements such as “Obviously, it’s all database’s (programming language’s) fault, let’s all migrate to MongoDB (rewrite it in Haskell)”. Technologies are rarely the real cause of problems. In fact, people are usually to blame. Carefully analyze each particular situation separately and choose the right tool, using strict criteria and not your fantasies about what is right.

4. Fight with perfectionism

Crappy code is okay. Far more than one programmer was working on the project for a long time. The requirements, and therefore, the code were constantly changing. It would be strange not to have crappy code in some places. If it works, do not touch it! Also do not carp too much about the pull requests of others. Perhaps you would name the variables a little differently, you’d have placed the indents better, and you’d have written slightly faster code. However, all of these things will not significantly affect user happiness, so do not waste time arguing about such things.

5. Do not reinvent the wheel

It’s unlikely that you have faced something so unique that no one has ever tried to solve it before and open-sourced it, or does not provide it at a low cost in the form of SaaS. If you don’t know how to solve the problem, do not be afraid to ask more experienced colleagues. Most likely there is already a known solution somewhere. You should not rush to write your own ORM or distributed database. Use an existing solution or try to understand why no one does that.

6. Check everything by yourself

Do not be fooled by marketing bullshit. Call into question the opinions of “experts”. Ignore rumors such as “My friend used DynamoDB and lost all his data” and microbenchmarks that are one year old, that applied small amounts of data or that can not be repeated. If they use Erlang in WhatsApp, it does not mean that you would automatically build a cool distributed and fault-tolerant system with it. Riak, first of all, is a key-value database. If Basho promises you MapReduce, full-text search, and who knows what else, it’s not a fact that they will work very well in Riak. Load your amount of data into PostgreSQL on your hardware and check how many transactions per second it really processes after tuning the settings that you were able to grasp. Set up your Cassandra cluster and check how it behaves when the nodes fail and with netsplits, see whether data is lost and so on.

7. Use the simplest and most time-tested solutions

You most likely do not need all those fancy things such as pure FP, category theory, dependent types, proof of program correctness, and so on. Because, guess what, users don’t care how many monads you’ve used in the project and how many theorems you’ve proven in the process. Take the time to write additional integration and load tests that are straightforward and time-tested. If almost all highly, and not very, loaded web projects are successfully built on top of RDBMS like MySQL or PostgreSQL with their all their kludges, then maybe there is no need to use MongoDB in the project. Most likely, you will only collect a bunch of problems.

8. Stay conservative, but do not be afraid to learn new approaches and tools

Perhaps Git is really much better than Subversion, and programming in Scala instead of Java will make you more productive. Moreover, there is something good about those microservices and DevOps. The main thing is to understand what specific problem you want to solve with the help of this novelty and move carefully.

9. Writing code is not everything

Many problems can be solved in a non-technical way. For example, if an application hits a memory limit, you can just purchase more RAM, rather than engage in long and expensive optimization. Usually, businesses don’t need nine nines, and it’s easier to convey this to management then rush into implementation of nine nines. Another interpretation is that programmers need to rest and avoid overtime. Of course, unless users don’t suffer (see the first statement of the Doctrine). If bosses suddenly ask for overtime because “Hey, we are a team and the company is counting on you”, that means you are being stupidly deceived, or someone in the company doesn’t know how to plan. Anyway, a tired programmer is of little use, and overtime only creates an illusion of more rapid development.

10. This Great Doctrine is beautiful and eternal

This is the only correct doctrine and all teams sooner or later come to it as a result of natural selection. Therefore, there is no special reason for imposing it on someone. However, sometimes, very ardent heretics come to the team and, of course, they should be removed from programming at that company as soon as possible.

The main thing to remember is that this doctrine is not about how to make something hastily and in a slipshod way, it’s about how to make it simple and understandable. So that the workability of the solution is obvious without any cunning evidence. So that any good programmer is able to understand what and how it works after, at worst, five minutes of explanation. It is also about objectivity, not about random acts, trends, or your fantasies about an ideal world. Most importantly, it is about pragmatism and the creation of working applications for solving specific problems in a reasonable timeframe and at a reasonable price. Elegant solutions are useless if they do not work in the real world.

Whose side are you — the Order or the heretics?

This is a translation of Aleksander Alekseev’s post “Колхозная доктрина”.