From translator

The other day a mini- site minifesto.org appeared on the network with a sound, in my opinion, abstract presentation of the experience of approaching start-ups (and of development as a whole). The manifesto of the text softens from the beginning to the end, but this does not make it worse.

Again I apologize for the lack of translation of the phrase “computer science”.

Briefly

• Fight for Pareto's law , make sure that 20% of your work gives you 80% of the result;
• Set priorities , because minimalism is needed in order to do what is needed, and not to be sprayed over trifles;
• The best is the enemy of the good : first, just do it, then do it right, then do it better;
• Kill in the bud , do not be afraid to start all over again. The faster you make a mistake, the faster you learn;
• Increase your value . Constantly think about how you can help the team - and develop in this direction;
• First the basics . Think consistently, focusing on the best practices of the world Computer Science;
• Look from different sides . The simple is harder than the complex, so turn on the imagination;
• Syntax - the basis of interaction. We write code for people, not machines;
• Do not tangle . Try to design layers, as far as possible independent of each other;
• Clean out the left-to-be . Minimalism fights with distractions from the core.

Fight for Pareto's Law

Pareto's law says that eighty percent of the result is achieved by twenty percent of the realized capabilities of your application . Keep this in mind when planning your next sprint / goal cycle.
The best engineers are those who can estimate the costs of implementing the exhibited requirements so as to save 80% of the effort for the future.

Crush them for yourself. This is not an army, in our industry you are paid for what you think and take on responsibility. Always voice your position if it seems to you that the requirements are superfluous.
')
The worst code you can ever write is code that is not used. For this, there is an abbreviation YAGNI (You Are Not Gonna Use It) [literally - "you will not use it"; here is given literally in accordance with the original text, approx. translator] .

The best code you write is code you won't write. Just because it can not be wrong.

Prioritize

There is a way to correct the mistakes, which I call “precipitation” . This is when the error is corrected by the accumulation of other errors. There is another way that I call "erosion . " This is when the customer changed his mind. The very examples in which prioritization and endurance will protect you from unnecessary work.
After all, minimalism is not the way to do work. Minimalism is a way to focus on the important .

Best the enemy of the good

Look for perfection, but not right now. Iteration is your friend who gives you the right advice at the right time.
First, just do it , then do it right, then do it better.

Engineers often think that the world can be modeled, but the world every time shows that it is not. It is impossible to design any rather complicated system without a hitch. Design is always evolutionary .

Treat everything as an intermediate stage of your work. Do not strain when something is not working as it should - remember the law of Mosher , which says: "If everything works as it should, you are left without work."

Kill in the bud

Destroy . The faster the better. Do not be afraid to throw in the trash what you have been working on for several months.
When you start from scratch, something new appears by itself. It comes from your experience.

Constantly evaluate what you are doing. This is what is written in the book Lean Startup . Develop your MVP (Minimum Viable Prototype, Little Live Prototype). Check it out. Not suitable? Throw away, you already got the experience.
The faster you make a mistake, the faster you learn.

Increase your value

No one can know everything.

Ask yourself the question - how can you help the team? What does she need most? Which of you is an expert in scalability? Who knows your programming language thoroughly? Who cares most for the product? Who coordinates the effort?

All teams are different, so you have to adapt and choose, look for the strengths and weaknesses of you and your team.
Learn to love one thing and go for it . Try to feed yourself correctly. After all, you yourself like what helps you solve your problems, and not something that somehow does your work.

Of course, it is easier to work with those with whom you can share the task - but the real strength of the team is in complementary people. Remember, at least, Team A.

First basics

At some point in our lives, we will understand the importance of the basics. For some reason, it is assumed that a return to basics is a topic for older people. Try not to be silly and do not wait. Put on the basics right now.

In the annals of Computer Science there are time-tested excellent solutions that you can apply in any new project . We must try to think consistently, starting from these decisions.

Paraphrasing the famous proverb: there are three critical aspects of software development — architecture , architecture, and architecture, in that order.

Examples of such fundamentals are the division of responsibility , the general theory of systems , the design patterns of the Gang of Four , the general patterns of assignment of responsibilities , the principles of SOLID , pure code , the principles of Agile , algorithms , data structures , HTTP specifications , etc.
Of course, you can plunge into some framework tests of unit tests like Jasmine, JUnit, Mocha - but, of course, it will be more useful to learn how to write code that can be covered with tests (for example, isolating the code from the state and reducing the connectivity of components).

Look from different sides

The simple is obtained with much greater effort than a complicated one. Minimalism requires creativity in order to find a way to do more with less effort.

Technical skills are responsible for complexity, creativity is responsible for simplicity. Creativity is like a “research fun”. Enjoy the opportunity.

Do not try to work more, try to work less, but more intellectually. Think! Think about what you are working on. Disable autopilot. Leave the comfort zone . Take control of your hands.

Do not be afraid to lose the status quo. Remember that the world around is built by people who were not smarter than you, they just believed that such a world is possible.

Of course, people may start thinking about you as an odd person - simply because you will do strange things, but you cannot become a leader until you can do something strange and innovative. Something that no one else before you did.
For an example: I am sure that each of you thought that a lot of time in the company is wasted on all sorts of meetings and meetings. Well, on those who talk about everything and nothing. That is what prompted Jeffrey Bezos (founder and CEO of “Amazon”) to approach the holding of meetings in his company slightly out of the box . When all participants in the meeting meet in the meeting room, they have 30 minutes to read the meeting theses in complete silence. And only after that you can proceed to the discussion.

Syntax

We write code for people , not for machines, syntax is the basis of their interaction.

A good example in Pasteur’s quotation: “If I had more time, I would have written a shorter letter.”

Try to give methods shorter names, and classes - as little as possible responsibility. Reduce the number of parameters, avoid obvious comments ... Your work is finished, when nothing can be thrown out of the code.

Do not tangle

Any software development problem can be solved by adding another layer of abstraction. Anyone except redundant abstraction . Unfortunately, this limits us in the complexity of the architecture and makes us look for a certain balance between simplicity and redundancy.

Abstraction is great. It allows you to create a new semantic layer in which you can accurately express your thoughts. But it also for some aspects of the activity (for example, for refactoring) complicates the understanding of the huge and over-detailed scheme of the system.

That is why it is necessary to look for natural points at which we can make a dissection and try to consider some compromise solutions .

As an example: the “root / leaf” paradigm of the domain model, the “Controller / tools” paradigm, the principle of “ high density - low connectivity ”, inter-level RESTful interaction interfaces .

Clean out the left-in-case

There is such a thing - “abandoned, just in case” [in the original - “kippel”, approx. translator] . This is what we leave just in case, but never use it again. In your home such a bulk, however, as, certainly, in your code. Any inherited methods that we are afraid to remove due to the fact that some part of the project may break; the instantly needed libraries that we will never need again; outdated comments ...

In human nature itself lies the fact that we have to create complexity in order to heroically simplify it later. It is necessary to periodically go over the project, find the “abandoned, just in case” and destroy it.

Minimalism fights with distractions from the core.