How is the signor different from the junior?

In addition to the knowledge of 100,500 technologies and approaches, which, of course, are also important, there is one more point that is directly necessary, and for some reason they rarely talk about.



This is the ability to build in your head a model of what is happening in the software being created. And remember her for a long time, at least in general terms.

You may not care about the benefits of business (hello, fillpackart), or, on the contrary, you live only by work. You may or may not know the details of the gc implementation in jvm and twirl the red-black trees.







It doesn't matter if you can't train your gray neural network so that you can more or less keep the system as a whole in your head. Something that belongs to the part of the software for which you are responsible, and a little more nearby.







You can transform the customer's meaningless muttering into a clear model yourself, or you can set a business analyst or email on it, who will give out the documentation.







But all the same, until it "clicks" in your head, the understanding of what is happening in general does not settle down, you will make the dumbest mistakes and flaws. Silently finish the obvious nonsense from the TZ, because you will not understand that this is nonsense. It will be wrong to highlight entities and abstractions in the code, because the code is the model of business processes written in a weird computer language.







Various approaches like DDD help, but only in part, because without understanding the system, without asking timely questions, bounded contexts and entities will also be mistakenly distinguished. Then it will have to be redone, and at the same time there will be a lot of unnecessary dependencies and strange names in the system.







Cool chess players can keep in mind a dozen games in a simultaneous game session.







Cool senior programmers will cut off a crazy feature even at the preliminary discussion stage, asking a couple of correct questions.







Those who are able to hold the model in their head are often made team leaders, even if they perform worse in lines of code per second.







PS It would also be nice to be able to explain what is happening to others: when explaining, you remember and crystallize the essence better.







This post is a censored version of a post from the Cross Join telegram channel








All Articles