Read your product code. Whole

Based on all of my many years of developer and technician experience, I can confidently name one specific thing that most dramatically increases the productivity of a programmer’s work: it is reading absolutely all the code of a product developed by a team. This is a “simple” action (although it will take some time, and will also require attention to understand the reading), but it is surprising how few people in teams do it. But the developers who have never read the entire code will always depend on those who did it.


Understanding the general architectural principles and interrelationships of components is a step in the right direction, but what I advise you to do is a step further. Implementation details often determine the behavior of the system to no less than the high-level architecture. Routine low-level operations will in fact sooner or later develop in your mind into a puzzle on which high-level connections of components and subsystems will appear in bright lines. You will never get into a situation “and I thought it was done in that subsystem ...” or “I performed this operation here, because I did not know that it should be performed earlier \ later”. You will find yourself at that level of “enlightenment”, which will allow you to discuss with any of your colleague or manager the details of the interaction of subsystems or potential ways of implementing the future functionality.

After you read the entire code of your system, you will notice how your view of the tasks for developing new functions will change:
')

• You will quickly understand exactly which parts of the system will be affected by the new functionality. You can better appreciate the complexity and time to develop a new feature. A general view of the system will even allow you to make recommendations to the developers of its individual components on how it would be better to join them.
  
  
• Since you understand the operation of the entire system, you can foresee problems in some situations that were not noticed by the developers of individual subsystems.
  
  
• Your manager will be able to rely on you in terms of assessing the complexity of problems and choose those among them, the solution of which at the given moment can bring the greatest result with the least labor costs. In principle, the manager could apply for similar assessments to the developers of specific subsystems, but this works well only for very small teams (up to five people). But you need to try to keep a balance: do not let your colleagues feel forgotten. Your in-depth knowledge and understanding of the system will not be beneficial if the rest of the team members eschew you.
  
  
• Your colleagues responsible for the individual subsystems will begin to ask for advice from you (and appreciate it) themselves. When you are asked to help with advice, this is either a sign that you are starting to work on the micromanagement of someone else’s work (not a good thing), or that you are going through a phase of situational leadership in this team / project (not yet the official leader of the team, but already one of the opinion leaders).

Outside the context of developing new features, you may also notice a few more things:

• You will be officially appointed a technical project leader, which will open up new challenges for you.
• You will have to look through more and more pull requests. Their high-quality processing will take a long time.
• You will be invited to more strategic meetings.
• You will be more often attracted to the design of architecture.
• You will have your own vision of where the whole system should go in order to achieve long-term goals.
• You will have to advise external clients.
• Your contacts with the manager will become more frequent, your judgment will be relied more and more.
• You will rarely manage to find time to write the code yourself.
• You will come to express your ideas and ask for their assessment.
• Your salary will grow
• The word “senior” will appear in the title of your post.
• People will start to see you as their leader.
• Your colleagues will be impressed by your ability to anticipate problems and bottlenecks. Although they, in general, are also at the same distance of an outstretched hand to such insight (you just need to take and read the entire code of your product)
• Each new feature will be considered by you as a move in a chess game (so many positions, threats, opportunities).
• You realize that all the work done has given you only a single-step snapshot of knowledge about the state of the system at some point. Your ideas about the code will become obsolete with each pull request, and you will have to fight with the obsolescence of your knowledge day after day. Well, you know, "run as fast just to stay in place."

So, you know ... Better you do not read all this code. Life is much easier without it :)