The Great Kolkhozian Doctrine is a quintessential element of programmers' wisdom. For decades, the Doctrine has been passed down orally, from generation to generation, among the members of the secret order of kolkhozian programmers. Unfortunately as time passed, the doctrine was overinterpreted and was overgrown with a lot of new elucidations and commentaries. We witnessed the emergence of [scholar-like heretics] (https://twitter.com/sum3rman), who knowingly [distorted] (http://devzen.ru/episode-0028/) the Doctrine in order to instill fear and doubt within our hearts. Thus, the order sees no other way to protect the truth than to reveal the doctrine with great publicity. Below, we present the most exact approximation of the original doctrine, which we were able to reconstitute from crumbs of knowledge, thanks to few initiated members.

1. The main goal of any programmer is to produce a working product and make users be happy. The users must never suffer (or at least, not more than the usual). If, for example, you rolled out a fix that causes hardship to the user, no matter what the cause is, roll it back and investigate the problem in a separate branch. The users know nothing of the bad people who used undocumented features of your marvellous API and the likes. A direct consequence of this rule is the fact that any alteration made to the product should not make it worse than it already was up to that point. If it turns out that the product did indeed turn out worse, roll it back to the previous version.

2. Remember that you are not the only one in command. Let's assume, you think the problem can be solved by just plugging in Paxos protocol. Apart from you, there are five more people in command, and it's highly doubtful that they would want to even know what your Paxos protocol is. And it is also quite unlikely that candidates who would pass by your office for job interviews everyday would have even heard that word. The fault lies not in your colleagues, but in yourself, and you are the only one who can support your architectural decision in the future. That does not suite to your team, so find another. Don't turn all categorical, but seek a compromise, find a way to solve conflicts that will suite to everybody. For example, leave the last word to the member of the team chosen by your team leader.

3. Only the (ситхи) make absolutism a principle. For example, only ever launch a single process in Docker, use only constant variables, or on the contrary, only and exclusively apply OOP principles, write everything using Vim, praise the MacBook as an ideal working tool that simply "just works", say that you should never use Java because its garbage collector sometimes does a "stop the world", or, for example, that Erlang has remsh and hot code upgrade and that all other languages are therefore utterly useless -- that is all just heresy. Another lesson here is that one should avoid categorical statements such as: "it is perfectly obvious that everything is the fault of our database (the language we are writing this in), so let's just migrate everything to MongoDB (Haskell)". Technological choices rarely turn out to be the cause of a problem, as a matter of fact it is almost always the people. Carefully examine each concrete situation independently, and pick an appropriate tool using stringent criteria, and not whichever fantasy of yours about what is right and what is wrong.

4. Fight perfectionism. Crappy code is normal. On any project, more than one programmer is going to work long and hard. Client demands, and therefore the code itself, are constantly changing. It would be strange not to find crappy code here and there. It works, don't touch it! Also, don't dig too deeply into other people's pull requests. It's possible that you would have named your variables slighlty better, found a better way to organize your indentation, or written a slightly faster code. But it s highly unlikely that all that energy would have changed anything to the user's happiness. And therefore you shouldn't spend time arguing vainly about such things.

5. Don't reinvent the wheel.

• Kolhoz was a collective farm in the USSR. Historically industrial production was paid much more attention by the state and agricultural production received much less (if at all) funds and support. Therefore people had to be creative in order to solve day to day problems with minimum resources available. Currently this word is used ironically to denote something clearly non hi-tech, hand made, using whatever materials and expertise were available, or just silly. In this article the author associate himself with a farmer to highlight that his doctrine is not based on high school theory but rather comes from pure down-to-earth practice.