📜 ⬆️ ⬇️

Unreal real estate developers, or why years of experience do not say anything

An experienced Toronto programmer, Matt Briggs, loves his job so much that he says: "I would write code, even if it were illegal." And when he published a post about juniors, midlachs and senior developers on his blog, he gathered more than a hundred delighted comments. We at Alconost also admired and translated this article for you.

We work in a strange industry. The need for developers here is much higher than the staff proposal. This problem has existed for many years, and over time it becomes more acute.

We have a serious shortage of talent, although the industry is quite young. Most software projects fail, and almost all exceed the budget. And the best idea that the strongest minds can offer comes down to “There are several standard ways to solve such problems, but our solutions often do not work. The only thing you can do is try and see the result. ”
')
The reality is that a “senior developer” means a person who sculpts a code for more than 3 years. He is put in a leadership position, and usually everything ends as expectedly pitiable.

In fact, an attempt to evaluate people by time intervals is too simplified for such delicate matters as knowledge and professional experience. But this is the way things are. And if we continue to classify specialists in this way, then it’s time for our industry to take time out. There is a difference between a person with 10 years of experience, and those who at the same time became more experienced 10 times.


Poster from the series "Computer scientists"

Developer growth stages


As programmers, we live in a world of complex systems and variables. In this world, even the simple execution of a well-set specific task can be difficult. Especially if there is no extensive experience with the available tools or code base.


A shot from the series "Computer scientists"

This is the life of a junior developer . Having completed the training, you seem to be all-knowing. But suddenly there comes an understanding that the school has poorly prepared you for the problems that you have to face. Reality is chaotic, not so pleasant and far from theory. We have to spin in an environment of compromise, without the ability to speculate about something.

Work with all this in mind will be your main lesson and focus. Younger developers need regular guidance, help and support. Otherwise, they can stagnate for a very, very long time (I recently ran into a comrade who had been making software for almost 10 years, but in fact remained the same novice developer). It can be said that this period is entirely devoted to the knowledge of tactical approaches to solving daily tasks.

The junior developer is fixated on code, not on the development process. And he does not particularly catch the difference. If the programmer says that “would happily code more if it were not for these users” - with a high probability, you communicate with a newcomer.

A good junior developer can be given a familiar task and expect it to be executed quickly.


A shot from the series "Computer scientists"

A mid-level developer is already beginning to see certain patterns in errors (usually in his own mistakes). He understands that writing a workable code that does not collapse at the first change requires much more than simply completing its part of the work. He also usually goes through that unique experience when you look at your past pride (one year old code) and you realize that this is utter trash.

Such a person studies the question of proper software development, and finds answers for himself in experiments, literature, and discussions with colleagues. At this level, everything is aimed at studying the theory of product development, rather than writing code (this is taught in school).

Written by "average" developers independently systems fail for completely different reasons than the creations of young professionals. Junior will simply write a mountain of semi-working algorithms. A good “medium” partly embodies the contents of the books “Design Patterns” and “Domain Driven Design”. Of course, these are excellent books for exploring the process of developing large systems. But simply following their postulates leads to the construction of unnecessarily complex systems that are flexible where it does not matter and are cumbersome in meaningful things.

The "average" programmer can be trusted to develop a system that will work much longer than the creation of a young colleague, but still lead to unpredictable consequences. Sad but true: the absolute majority of not only senior developers, but also tmlids, are ordinary "average" programmers. Many of them do not understand this and are guided only by good intentions, but they simply never worked with someone more qualified.

"Midly" well aware of their role in the organization and value for it. Good middle developers also understand that coding to solve a problem means working to its logical conclusion, and not just to the end of the task. And yet they are still too passionate about building ivory towers and the search for the “Right Path” in software development.

A good “average” developer requires less supervision. They can be trusted to search for problem areas of the project, and they play an important role in making key decisions. They are also the "workhorses" of the team, but they require more high-level mentoring.


A shot from the series "Computer scientists"

The senior developer is intimately familiar with his own failures. Such people created both unfinished and unnecessarily complex code - and saw dismal results in both cases. They are balanced approach to work, soberly and calmly assessing their own success and failure in the event of problems. The senior developer has already stopped loving the complexity that captures the minds of "average" colleagues, and is now obsessed with simplicity.

The senior developer does not classify colleagues by their level of knowledge, he understands that everyone has strengths and weaknesses. He knows about his advantages and disadvantages more than anyone else and seeks to use the advantages as much as possible.

Senior takes context into account when applying theory. He understands that there is no “Right Way”. The only way to build a good product is to adapt the theory to the requirements of the client, the code base, the team, the tools and the organization. Such a person understands that everything around us requires compromises, and will look for them for design patterns, libraries, frameworks and processes.

Senior developers think not only about themselves. They know perfectly well how their company and the organization of the customer work, what values ​​they have and what is important or not important for success. If the ball is thrown, the senior programmer will do everything possible to catch it. You will never hear from him the phrase "this is not my business" in such situations.

Senior developer understands that the job is to solve problems, not to write code. That is why he will always look at work from the standpoint of the ratio of its value to the organization for the effort expended.

While the “average” developer will get stuck in countless days of monotonous activity, the “senior” will first take an interest in the root causes of the situation. He will assess the cost of neutralizing the cause, and either fix it right away or direct the process in the right direction.

He also understands that you can not do everything yourself. His primary role is to help the team become better, often in the same ways that individual participants self-improve. After all, power is not in power, but in delegation. Not in management, but in support.

If you do not have any senior developer in leadership positions, then the project is doomed. A team of excellent "middling" can lead you quite far away, but the days of the product are still numbered. And in the final you will find either folding shops, or risky and costly rework. The only one who is able to choose the right technology and platform is the senior developer. Therefore, his absence in the project from the first days seriously hurt you.

This is just a giant simplification.


The reality is that no one fits the described framework exactly. I'm already tired of seeing how programmers are rated for "years of experience." Of course, they can tell you something, but this is practically useless information outside the rest of the context.

Moreover, in our industry, it is customary to appreciate daring smart young people after university. These guys are really valuable and necessary, but no more than their colleagues with 15-20 years of "field" experience. It's time to stop stereotypically hiring people and start thinking more about the team and the compatibility of talents. If everyone in the team thinks the same way - you will do a disservice to the project and the organization.


About the translator

The article is translated in Alconost.

Alconost is engaged in the localization of applications, games and websites in 60 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.

We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.

Read more: https://alconost.com

Source: https://habr.com/ru/post/262831/


All Articles