From translator

The other day, the minifesto.org minisite appeared on the network with a sound, in my opinion, abstract thesis on the experience of approach to startups (and development in general). The manifesto of the text is softened from beginning to end, but this does not make it worse.

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

Briefly

• Fight for the Pareto 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 get sprayed on trifles;
• The best is the enemy of the good : first just do it, then do it right, then do 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 basics . Think sequentially, guided by the best practices of the world of Computer Science;
• Look from different angles . The simple is harder than the complex, so turn on the imagination;
• Syntax  is the basis of interaction. We write code for people, not for cars;
• Do not confuse . Try to design in layers as far as possible independent of each other;
• Clean out what is left just in case . Minimalism fights distractions from the core.

Fight for Pareto Law

Pareto’s Law states that eighty percent of the result is achieved by twenty percent of the realized features 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 set requirements in such a way as to leave 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 responsibility. Always voice your position if it seems to you that the requirements are redundant.

The worst code you can ever write is code that is not used. For this, there is the abbreviation YAGNI (You Are Not Gonna Use It) [literally - “you will not use it”; here is verbatim in accordance with the original text, approx. translator] .

The best code you write is code that you won't write. Just because it cannot be wrong.

Prioritize

There is a way to correct errors, 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 exposure will protect you from unnecessary work.
After all, minimalism is not a way to do the job. Minimalism is a way to focus on the important .

Best the enemy of the good

Seek perfection, but not right now. An 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 this is not so. You can’t design any rather complex system in a snap. Design is always evolutionary .

Treat everything as an intermediate stage of your work. Do not strain when something is still not working as it should - remember Mosher’s law , 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 is born 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, Barely Live Prototype). Check it out. Not suitable? Throw away, you have already gained experience.
The faster you make a mistake, the faster you learn.

Increase your value

No one can know everything.

Ask yourself  - how can you help the team? What does she most need? How many of you are scalability experts? Who thoroughly knows your programming language? Who is most rooting for the product? Who is coordinating the efforts?

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 grasp it . Try to give yourself right. After all, you yourself like what helps to solve your problems, and not what somehow does your job.

Of course, it’s easier to work with someone with whom you can share the task - but the real strength of the team is in complementing each otherpeople. 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 understood that a return to basics is a topic for older people. Try not to be silly and don't wait. Bet on the basics right now.

The annals of Computer Science have time-tested excellent solutions that you can apply to any new project . You need to try to think consistently, starting from these decisions.

To paraphrase the famous saying: there are three crucial aspects of software development — architecture , architecture, and architecture, in that order.

Examples of such foundations:  separation of responsibilities , general systems theory ,Four Gang design patterns , general assignment patterns , SOLID principles , clean code , Agile principles , algorithms , data structures , HTTP specifications , etc.
Of course, you can plunge into some unit test frameworks such as 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 the components). 

Look from different angles

The simple is obtained with much greater effort than the complex. Minimalism requires creativity to find a way to do more with less effort.

Technical skills are responsible for complexity, creativity is responsible for simplicity. Creativity is a kind of "study tipsy." 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 in your own hands.

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

Of course, people can begin to think of you as a person with oddities - 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 has done before you. 
For example: I am sure that each of you has thought that a lot of time is wasted in the company at all kinds of meetings and meetings. Well, those who talk about everything and about nothing. This is what prompted Jeffrey Basos (the founder and CEO of Amazon) to approach meetings in his company a little unconventionally . When all meeting participants gather in the meeting room, they have 30 minutes to read the abstract of the meeting in complete silence. And only after that we can proceed to the discussion.

Syntax

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

A good example is in Pasteur’s quote: “If I had more time, I would write a shorter letter .”

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

Do not confuse

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

The abstraction is wonderful. 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 we must look for natural points at which we can conduct 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 .

Scrub Leftovers

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

In the very nature of man lies the fact that we must create complexity in order to then simplify it heroically . It is necessary to periodically go over the project, find the “abandoned-just-in-case” and destroy it.

Minimalism fights distractions from the core.