Programmer's own ability expansion model

[[142043]]

I heard someone say a word called “Comfirtable Zone”, which means “comfort zone” in Chinese.

This word instantly reminded me of the problem of programmers’ ability boundaries, so I drew a model diagram of ability expansion. It is as follows:

I think this capability expansion model is applicable to all aspects of a person, but this time I intend to talk only about programmers.

Capability Development Model

The left side of the picture is our current situation. The innermost archetype is the area where we feel comfortable, which I call the "comfort zone."

Take programmers as an example. When a programmer's technical ability and problem-solving ability reach a certain level, he or she can easily handle certain development tasks, solve specific practical problems, and bring convenience to users in some aspects. His or her ability matches the problems he or she encounters, and the programmer is in a comfort zone. The size of this comfort zone is defined and limited by his or her problem-solving ability.

When a problem exceeds the programmer's skills and experience, he can see and understand it, but cannot solve it. These problems are the challenge areas that the programmer may face at any time, which are the yellow circles in the figure.

The large red area in the picture is an unknown area for programmers. The unknown means confusion and pain. This area is often invisible to programmers. It is an unknown and mysterious area in the Bermuda Triangle. If you jump in rashly, you may fail.

If a programmer is willing to step out of his comfort zone, enter the challenge zone, and accept a certain degree of discomfort, then he will have the opportunity to expand his abilities and expand his comfort zone. His ability model will become the right part of the above picture, with a larger comfort zone, a larger challenge zone, and a larger pain zone. This is also in line with the laws of human cognition: the more you know, the more you don't know.

If a programmer is unwilling to accept even the slightest discomfort, he will gradually become complacent, fall behind others, fall behind the times, and gradually be abandoned by this ever-changing era, becoming an old guy who is useless in the eyes of others.

Expand your comfort zone during development

A programmer's ability can be continuously strengthened through exercise. Just like human muscles, if you overload the exercise intensity for a period of time, the muscles will adapt and become stronger than before, and then overload it a little more. Through this spiral progression, the muscles will become stronger and stronger. The same is true for programmers. Your learning ability, coding ability, design ability, communication ability, management ability, etc. can all be strengthened through exercise (we have to consider what a person is suitable for. If he does not have a certain talent, although he can be strengthened through exercise, things that go against nature usually have twice the result with half the effort).

In the software development process, a programmer knows what languages ​​he can use and what frameworks he knows. The project manager also thinks he knows what he knows based on his performance. So when there is a new project to be done, the usual practice is to assign the programmer who is familiar with the technology related to implementing the Tx task to do the Tx task. This is usually based on considerations such as delivery time, productivity, and cost.

In this case, everyone does what they are familiar with, which is naturally the most economical for the entire project. But for the programmers themselves, it is not economical. Because you cannot accept new challenges, the expansion of your ability boundaries will be very slow. Therefore, it is reasonable that when dividing tasks, the project manager should be responsible for the programmers, giving them tasks that can be completed easily and tasks that require some effort to complete, and training the programmer through challenging tasks to make him grow better and faster. However, the management cost of doing so is too high, so in reality, few project managers in companies will take the initiative to do so (they will do so passively when there is no suitable person to take a task).

In view of this reality, as a programmer, if you want to grow faster, you must be brave, take the initiative to go to the challenge area, and grab challenging tasks. (If you are embarrassed to take the initiative, you can also accept challenging tasks when they fall on your head.) Once you get a challenging task for you, you will make money. Yes, I said this on purpose, you have made money. Although you will work hard for it, although you may work overtime for it, although you may pay for it in places that others cannot see, but you have opportunities and more possibilities. If you complete it successfully, your comfort zone will expand, and your chances of encountering new challenges will also increase. You will enter a virtuous circle and you will become stronger and stronger. You will eventually embark on the transformation path of Goku in Dragon Ball, becoming a Saiyan, a Super Saiyan, a Super Saiyan 2, a Super Saiyan 3,... until you become a Super Saiyan God.

Just think about it, what a wonderful thing this is!

So, you haven't worked on a certain technology? Not a problem. You haven't learned a certain language? Not a problem. The software structure is too complex and you can't control it for the time being? Not a problem. You are not familiar with the business? Not a problem. If you think these are problems, OK, please sit back and watch the clouds rise, wait for time to take away everything and leave you where you are.

In the eyes of programmers who are eager to achieve self-realization, problems are opportunities. Only by seizing opportunities can our ability to solve problems grow like a snowball in the painful experience.