Fake senior developers, or why years of experience don't say anything
- Transfer
We work in a weird industry. The need for developers is much higher than the staffing offer. This problem has existed for many years, and over time it becomes more acute.
We are experiencing a serious lack 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 that can be done is to try and look at the result. ”
The reality is that the "senior developer" means a person who sculpts the code for more than 3 years. He is put in a leading position, and usually it all ends with the expected disastrous.
In fact, trying to evaluate people at time intervals is an oversimplified way for such subtle matters as knowledge and professional experience. But this is the case. And if we continue to classify specialists in this way, then it's time for our industry to take a timeout. There is a difference between a person with 10 years of experience and someone who has become 10 times more experienced over the same time. Poster from the series "Computer Specialists"

Developer Stages
As programmers, we live in a world of complex systems and variables. In this world, even simply completing a well-defined specific task can be difficult. Especially if you don’t have a lot of experience with the available tools or code base.

Shot from the series "Computer"
This is the life of a junior developer . After graduating, you seem to be omniscient. But suddenly an understanding comes 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 go around in the midst of compromises, without the ability to build assumptions about anything.
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 (recently I ran into a friend who had been making software for almost 10 years, but actually remained the same novice developer). We can say that this period is entirely devoted to the knowledge of tactical approaches to solving daily problems.
The junior developer is fixated on the code, not on the development process. And he doesn’t particularly catch the difference. If a programmer says that “he’d love to code more if it weren’t for these users” - with a high probability, you are talking with a newcomer.
A good junior developer can be given a familiar task and expect it to be completed quickly

Shot from the series “Computer scientists”
A mid-level developer is already starting to see certain patterns in errors (usually in his own mistakes). He understands that writing a workable code that doesn’t fall apart on the first change requires much more than the simple completion of his work site. He usually also goes through that unique experience when you look at your past pride (a year-old code) and understand that this is complete rubbish.
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 at school).
Systems written by “average” developers fail on their own for completely different reasons than the creations of young specialists. Junior will just write a bunch of conditional algorithms. A good “medium” partially embodies the contents of the books “Design Patterns” and “Domain Driven Design”. Of course, these are great 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 is not important and clumsy in meaningful things.
The “average” programmer can be entrusted with the development of a system that will work much longer than the creation of a young colleague, but still lead to unpredictable consequences. Sadly, it is a fact: the vast majority of not only senior developers, but also team leaders, 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.
The "middle" is well aware of its role in the organization and its value. Good middle-aged 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 keen on building ivory towers and searching for the “Right Way” in software development.
A good “average” developer requires less supervision. They can be trusted with finding problem areas of the project, and they play an important role in making key decisions. They are also the “workhorses" of the team, but require a higher level of mentoring.

Shot from the series "Computer"
Senior developer is closely acquainted with their own failures. Such people created both unfinished and overly complex code - and saw disastrous results in both cases. They take a balanced approach to work, soberly and calmly assessing their own good luck and defeat in case 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 according to their level of knowledge; he understands that everyone has strengths and weaknesses. He knows more about his advantages and disadvantages than anyone else and strives to use precisely the advantages if 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, code base, team, tools and 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 are not only thinking about themselves. They know very well how their company and customer organization work, what their values are and what is important or not important for success. If the ball is thrown, the senior programmer will do everything possible to catch him. 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 a position of correlation of its value for the organization of the expended efforts.
While the “average” developer will wallow in countless days of monotonous activity, the “senior” will first take an interest in the root causes of the situation. He will estimate the costs of neutralizing the cause, and either immediately correct it, or direct the process in the right direction.
He also understands that you cannot do everything yourself. His primary role is to help the team become better, often in the same ways that individual participants cultivate. After all, power is not in power, but in delegation. Not in management, but in support.
If you do not have a single senior developer in leadership positions, then the project is doomed. A team of excellent “middlers” can take you pretty far, but the days of the product are still numbered. And in the finale you will find either folding up shops or risky and expensive alterations. The only one who can choose the right technology and platform is a senior developer. Therefore, its absence in the project from the first days will 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 watching programmers evaluated by “years of experience”. Of course, they can tell you something, but this is almost useless information out of the rest of the context.
Moreover, in our industry it is customary to value the daring smart young guys 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 hiring people stereotypically 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 both the project and the organization.
About the translator
Translation of the article was done in Alconost.
Alconost localizes applications, games and sitesinto 60 languages. Native-language translators, linguistic testing, cloud platform with API, continuous localization, project managers 24/7, any format of string resources.
We also make advertising and training videos - for sites that sell, image, advertising, training, teasers, expliner, trailers for Google Play and the App Store.
Read more: https://alconost.com