Junior and rational thinking methods

Much that seems completely obvious to an experienced developer is not obvious to a beginner. I'm not talking about writing code, knowledge of patterns, and so on. This concerns the way of thinking in general: how to solve a problem, how to ask how not to arouse the anger of the mentors of their elders . Today we will try to talk about it.

Methods of rational thinking (here) - these are questions that should be asked at each stage of thinking about the problem. With their help, you can quickly come to the right decision and more effectively build your work.

Question 1. What is the reason?

According to the law of meanness, when you first start the application, something will definitely not work. To get started is to try to determine the cause of the error. The easiest way is to look at the console. Perhaps the error text will be enough to figure out how to fix it.

Question 2. Did I do everything I could?

Even if the text of the error did not help, you should not rush to people with a question. First you need to make sure that everything possible was done. You can check about this list:

1. I checked the application documentation for a solution to this problem.
2. I googled and found nothing
3. I googled in English and found nothing
4. None of the tips found helped me

If everywhere the answer is positive, then go to the next item.

Question 3. I seem to be puzzled. Why?

There is nothing wrong with asking your mentor / mentor / boss / friend about solving a problem. Perhaps you just forgot to talk about it. However, the question should not consist only of the words “something does not work”; all available input data should be enclosed in it. Properly constructed question saves your tutor's time and helps you work more efficiently. Try to check the question for "completeness":

1. Error text specified
2. The case is indicated in which you encountered an error (up to the launch commands)
3. Indicated tried solutions

Profit! In the shortest possible time, you will receive a solution to the problem and deep respect from your colleagues. So, forward to the development of tasks.

Question 4. Does my solution completely solve the problem?

Now let's talk about how to complete the execution of any task. Hint: the right question to yourself.

If this is a bug, then it is worth checking: is the problem fixed or masked? For example, there is a function that should return a number, but it (suddenly) returns a string. By converting the result at the place where the function is called, you can mask the problem. But, perhaps, it is worth making the transformation within it and thereby fix the problem completely.

Feature or bug, do not be lazy at the end to check all possible cases. As practice shows, the phrase “should work” causes terrible bugs and even more terrible discontent from the receiving side.

Question 5. Why am I sure about this?

Immediately consider an example: it is time to integrate different parts of a large application. The backend associated with the junior task was developed long ago. He runs the feature on his side and ... everything hangs! Pretty quickly, it determines that the backend is frozen. One could immediately say: “The problem is not on my side”, throw off the task and go about your business. But Rational Junior will think: “If the backend task is marked as completed, it was probably tested. Why am I sure the problem is in the backend? ” It doesn't matter which side the problem will be. It is important that he does not come to another developer without checking the behavior on his side.

Question 6. Why was this done?

It should be taken for granted that rational people are working around and they will not write nonsense (at least on purpose). When it seems that someone writing a line in the code is superfluous, it is worth thinking ten times before deleting it. Even if it completely solves the problem. The most likely ways to not miss anything:

1. View the last commit message with a change to this line.
2. View the task bound to the commit (often specified in the commit message)
3. See who did commit and ask him, after telling about his task

In conclusion, I want to add one thing: it is not necessary to follow all the precepts from this article, but be sure to think constantly and think for yourself .