“What is the reason?” — I would advise you to ask such a first question before solving each error and task.

“I see the investigation” – At the beginning of his journey, the developer often tries to fix the error as it is, and not to understand in depth what caused it.

A simple real-life example from a project I’m currently working on.

The title of the page is written in capital letters “PRODUCTS” instead of “Products“.

Investigation: visible immediately – quickly fix and forget about this bug Minimal effort.

There can be several reasons:

• There is no agreement with the designers, in which the headings should be in a uniform style. The solution is to discuss with the designers and standardize the work with headers.

• The global theme was incorrectly overridden for Typography: someone did this a long time ago. The solution is to study the topics and bring them to a unified view.

• Previous developer or designer (legacy) thought headings should always be capital letters and made them so on all his pages. The solution is to look at other pages and fix them too.

The transition from a mindless harvester from correcting consequences to finding causes and their corrections characterizes one of the main qualitative growths of a developer from Junior to Middle-Senior.

Importantly! – Sometimes it is better to solve the error immediately and quickly, and then start the task of correcting the cause as a whole.

If you have examples, write in the comments. I think this experience will be useful for new developers.

The film “Chorists” and Action-Reaction

For a deeper understanding of this topic, I suggest you watch the brilliant comedy drama “Choirs” from 2004 and think about the question: “Am I currently working through Action or Reaction?”, where teachers are frameworks and libraries, and students are our mistakes and tasks.

Trailer at https://www.kinopoisk.ru/film/51481/ – and you know where you can watch the film for free 🙂

What is the reason for the appearance of frameworks?

At the global level, frameworks try to minimize the number of such reasons. True, the architectural solutions of the framework are not always successful and they give rise to new types of reasons with which we work every day.

Frameworks and libraries declare the problems they solve on their home page.

Some positive examples:

• $mol – relevance due to no versioning, default reactivity, localization and out-of-the-box testing, boilerplate reduction of layout templates.

• React – simplification of layout templates, huge ecosystem, popularity thanks to Facebook.

• Vue – nice and clear documentation, convenient templates, good optimization and assembler on VIte with HMR.

• This list can be continued indefinitely.

The framework is selected once per project, and tasks and bugs in the project appear daily.

The main idea of ​​this article

Ask yourself a question about a current (future) mistake or task “What is the reason?» – This will help improve the quality of your work and open up new options for solving it. It can be difficult.

Try to automate this issue for better quality of your work.