Are the junas good?
This article is an analysis of another article: If you do not hire June, you do not deserve seniors
It should immediately make a reservation that I have no idea what is there and how in Netflix. It was just a shame for the common sense and logic, which the author so obscenely mocks throughout the article.
If possible, I left the original design, and noted my comments separately.
Well, the yellow title also left, slightly modifying.
Let's go .
Let me tell you a story about a very successful company that made a big, stupid mistake:
We do not hire junior programmers and interns ... If you don’t start a puppy, you don’t have to clean up the puddles.
Comment . The title is yellow and the introduction says that the essence of the error and the rapid fall of this company will be revealed further. Not really.
I was completely amazed how some kind of corporate thing had managed to present puppies in a negative light, and even this convinced someone. Puppies - the purest creatures on Earth, live fluffy joy! Rays of light in a lonely world. But let's get to the point.
Comment . Puppies can not keep themselves clean and eat on their own.
Many companies have followed this strategy of "hiring only seniors". They justify it like this:
- We do not have the time and resources to hire junior programmers; we are developing too fast.
- Our company can afford seniors, so there is no need for the junas.
- At the current stage, we can not afford to make mistakes. The stakes are too high.
- Our process provides employees with greater autonomy. We are not ready to hold the juns by the hand, as they need it.
- We want to lay the foundation for the product before we start hiring inexperienced employees.
The message is that junior programmers represent a risk, a step towards which a company takes either a sense of public debt, or a lack of budget.
Comment . It was always interesting, from which finger is sucked what was not in the original phrase. Where was the debt and the budget? It is about distraction of senior developers: instead of creating a product, they will train (review, explain, direct, fix, etc.) younger developers. Those. stupidly saving the time of senior developers.
It turns out that other companies must be able to afford corporate charity and second-rate results, but certainly not us.
Comment . Not the fact that others can afford too. They just think they can. After all, no one conducted experiments, at least I have not heard of such.
By the way, in the USA there are more than 100,000 IT companies, and I haven’t heard anything, that at least one CEO said “think about mistakes!” Or “need to get an extra budget somewhere”. So, attention, organizations, where the “junam entrance is prohibited”! No matter how you see your benefits, no matter how you substantiate your life hack, the reality is that you invented it all. There is no competitive advantage in getting rid of the junas. And you just showed your problem management to the world.
Comment . There is no evidence yet that these 100,000 IT companies represent an effective development environment, more efficient than Netflix. All this - juggling speculation and emotions.
This is a toxic company culture.
- April Wensel (@aprilwensel) August 1, 2017
Hostility to younger programmers is a clear sign of a toxic corporate culture.
Comment . Where is the hostility? No one says that juniors are enemies. They simply do not hire. And do not hire, for example, locksmiths and artists. Also show hostility? This is called "substitution of concepts."
The way you hire and handle younger programmers is an important indirect indicator of the health of your organization, your product line, and your internal culture. Seniors pay attention to this. And if this alone does not sound convincing enough, then hiring a weighted number of junior programmers also provides financial advantages.
Comment . Let's apply this logic to librarians who are not hired, and understand the absurdity of logical conjectures.
If you refuse junior programmers because they "create problems", then you also automatically send an important message to employees about the corporate culture: mistakes are unacceptable. You create an image of a company that fires someone whenever a server falls. No matter how much you pay, nobody wants to work in an environment that does not give confidence in the future. And attempts to intimidate programmers so that they do not make mistakes increases the culture of fear and threats, which catastrophically affects psychological health and productivity.
Comment . Another logical nonsense. Everyone is mistaken. Only an idiot can argue otherwise. The only question is who makes them more and who is able to correct them as soon as possible. And then also prevent them in the future. Therefore, the questions about the "messages" leave on the conscience of inventors. From the fact that someone is not hired, it does not follow at all, which is why people are being fired. Well, the passages about intimidation, psychological health, and the other just cause confusion.
You might argue that this attitude encourages programmers to be careful and create error-proofing processes: for example, automated testing, QA, failover, access protection, and reversible code edits. But this theory puts the cart before the horse. If the company's policy encourages the creation of such safety nets and the company itself provides programmers with enough time and resources for this, then the culture of the inadmissibility of errors is unnecessary and useless; Most problems will be caught well before production. And every programmer, whether he is a junior or a senior, prefers an environment where reliable processes protect against catastrophic errors.
Comment . On the basis of erroneous parcels, you can get any, however terrible consequences.
And what about the mistakes that pierce all the established safety net? Think of them as valuable opportunities to strengthen your protection. Younger programmers, it must be admitted, usually open up such opportunities faster than seniors. So the question is: would you prefer to debug your processes sooner or later? "Never" is no good, as any experienced programmer will confirm. If something can go wrong, sooner or later it will go. No amount of experience can prevent human error.
Comment . Yes, let's bring a monkey to a nuclear reactor and see how reliable the safety systems are. Well, to quickly open the defense. I'm already starting to worry about the mental abilities of the author.
Needless to say, you will need several senior programmers and ops leads to lay the foundation and create precedents for a fail-safe development cycle. Nobody offers to hire only junior programmers. But if your office is really serious about errors - in other words, errors are caught early and often - then younger programmers will be useful. And all levels of programmers will be more satisfied with their work, since fault tolerance frees them to create good software (instead of constantly putting out fires) and protects their evenings and weekends.
Comment . Speech is not about the fear of mistakes, it is about efficiency and productivity. The author repeats this false construction from time to time, proving that everything is bad. Everything is bad, yes, but only with the original premises.
According to Indeed, the average Junior Software Engineer receives $ 55,394 per year, while the Senior Software Engineer receives $ 117,374 per year. Seniors are more than twice as expensive as junas.
These costs are often justified. Older programmers are expected to be more productive than younger ones.
Comment . It is known that the difference in productivity between different programmers can reach up to 25 times. Therefore, 2 times just about anything.
But this picture is not exhausted, and you will get a pretty penny thoughtless and lazy justification of increased costs as the costs of doing business.
Comment . Even if you hire janitors for programming, including minor developers, this is always true, regardless of.
Not all application code requires many years of experience for its writing or even for a quality job. In each program there is a “software glue” that connects the various inputs and outputs in quite an ordinary way. In essence, it doesn't matter who writes it. You can pay $ 28 an hour to write this code — or you can pay $ 59 an hour to write the same code. One way or another, the result will differ little. If you hire only seniors, then you pay at exorbitant prices for a substantial amount of simple work.
Comment . If a significant amount of work in a company is rather trivial, then yes. But it is unlikely then the company can be considered high-tech. The complexity of the infrastructure is set by a serious initial barrier that a junior developer can not cope with (or cope with).
In addition, the code base varies considerably between applications, and familiarity with it is a key factor in productivity. In most cases, a junior programmer who has worked in a team for six months will be more efficient in coping with tasks than a newly hired senior programmer - simply because of his degree of familiarity with the logic of the project.
Comment . Depends on the complexity of the project. It happens that it is easier to fire and hire a good specialist than to wait for the “junior” to dull into the project.
The previously mentioned software glue and domain-specific code constitute at least half of the entire development. The rest is the code that really needs the attention of a senior specialist with benefit to the result. But even with this code, a junior programmer can do impressive work with sufficient access to educational resources and advice from an experienced mentor.
Comment . It happens that mushrooms grow on the moon. Arguments in the style of "and maybe so," it may, of course, take place, but I do not see any reason for this.
Because of this, a pair of junior and senior programmers usually work with the efficiency of two senior programmers and in less than 75% of the cost. If your goal is maximum productivity with minimum costs, then such a pair of jun + senor should become the fundamental molecule of your organization.
Comment . Or maybe not.
It is worth noting another, immeasurable factor: the trend of senior programmers to constant disputes on topics that are ultimately insignificant - about algorithms, micro-optimizations and code style. If a company hires only seniors and does not have a hard decision making process, then hundreds of working hours can go into such disputes. Younger developers usually do not have this problem.
Comment . Older programmers will not push the water in the mortar, and will be engaged in business. That's why they are older. Otherwise, I have bad news for you: your senior programmers pretend that they are older, you better hire more juniors to pay them less wages, because there will be no difference between them.
If you don’t hire junior programmers, then send another message to the staff - that you don’t know how the career development works.
I’m trying to make sure that they’re not hiring.
- Kate Heddleston (@ heddle317) September 13, 2018.
Sometimes when companies say they don’t hire junior programmers, I want to grab them by their breasts and scream: where do you think older programmers come from ?!
Comment . If there are no minor developers in the company, how can they send a signal? Send a signal in this case can only be outside. The author has numerous problems with receiving and interpreting the signal. For some reason, I receive a signal like this: "cool specialists will work next to you, you will be able to learn a lot, and you will not need to explain the obvious."
Again, this is not about the performance of corporate civic debt and not about the "participation in the development" of the IT community. It's about turning your company into a decent workplace, where programmers will want to settle down and stay long enough to make a tangible contribution.
Comment . Without a bazaar. Totally agree!
I happened to hear from programmers: “I was tired of changing job titles. I just want to remain forever a senior programmer. ”However, no one has told me yet:“ I hope I’ll never get a pay raise, I don’t learn anything new and will not be recognized for my services. ” And, oddly enough, the resources needed to support both ambitious careerists and diligent, but enthusiastic senior programmers are about the same. Methods are needed to change and recognize well-done work, a sufficient amount of educational resources and a variety of projects of different ages in the development pipeline. You need to create a sense of development, even for those who are not interested in promotion.
Comment . A senior programmer is the beginning of a long way. And between them, too, there are gradations. In any complex project, a senior programmer will develop. In modern development, there is practically no ceiling in development.
But do not lock on these guys. Their minority. Most IT workers are not going to be senior programmers for 40 years. They dream of becoming software architects, team leaders, technical directors and studio founders. A company that boasts of its indifference to career growth will find itself at the bottom of the list of prospective employers.
Comment . "Finding yourself at the bottom of the list" - is it about Netflix? Netflix topped a new list of "50 to the Places the Work the Best for the New Dads," with the Silicon Valley OTHER Several tech firms Lithuania landing on the lineup of Offering and stiff competition to woo working fathers .
I only recruit senior devs.
The trick is, I recruit some of them earlier in their career.
- Reginald Braithwaite (@raganwald) September 17, 2018.
I only hire senior programmers.
The trick is that I hire some of them at the beginning of my career.
Comment . This is the most awesome trick. And I'm all for it. These people really decide and can do a lot for the company. However, there is a little problem: how to find them? It’s pretty clear how to see the “older” in a programmer: the amount of knowledge he has in stock. In a promising novice programmer, you should look into a crystal ball and see the future. I did not see such an approach scaling well and working within a large company. It is always a risk and you can easily get into the milk.
One of the most impressive phrases that a programmer can hear at the interview is “Hello, I’m a team leader, I worked here for eight years, starting with an intern.” Very impressive and very rare. Such a person is extremely important for the company - he knows everything about the product line, he saw the code of all projects within a hundred meters radius, and he worked with all the employees of the company. He is able to offer innovations within the company like no other. And the company earns uncountable dividends from the labor of this person, because she was able to understand how to keep his interest for eight years - about 1/10 of the average life expectancy. This is evidence of corporate culture success. This is a sign of an office in which there is a fighting spirit, in which recognition finds all well-done work, and interesting projects await at every turn.
Comment . One of the most impressive phrases is “we pay an awesome salary, you build the project yourself from scratch, invite the right people and use any tools you want.” Wow, that's cool. But this is from the realm of fantasy. Like what the author wrote.
To declare "we are not hiring the jun" is, on the contrary, openly acknowledging that the company is not ready to play a role in anybody’s career. This is actually a demonstration of stagnation: the company wants to attract experienced and talented programmers who will make their contribution for the sake of only one salary. Some will agree to such conditions, but you will not see their best work.
Comment . To declare "To declare" we do not hire the June "is, on the contrary, open recognition that the company is not ready to play a role in anyone's career." - this is an open admission that the author has problems with logical chains and interconnections.
However, if your company is really serious about career growth, then an artificial restriction on junior programmers only reduces the payline of hiring and shortens the time of employees in your company.
Comment . I wonder why Google and Facebook have a high bar? Probably, they "narrow down the pipeline (?) Of hiring and shorten the time of employees in the company."
Writing great software
Junior programmers have a number of unique features that their more experienced colleagues usually lost. One of them is uncomplicated optimism. Another is the willingness to follow the leader. But perhaps the most important feature that junior programmers offer is the lack of baggage. Older programmers saw the sunrise and sunset of technology, project failures, teams torn by internal conflicts, and the rest of the IT industry. They have amassed strong beliefs and often draw too far-reaching conclusions, suggesting that one success scenario (or failure) will unfold in the same way for another project or team. What can lead to unwillingness to understand the nuances of the new field of problems.
Comment . Whether business "junior". It can commit a ton of broken bazhny code with uncluttered optimism and lack of baggage without far-reaching conclusions. Just a dream!
He doesn’t want to take it.
- DHH (dhh) July 31, 2017.
Companies eager to hire only senior professionals often lose sight of the fact that forgetting too much is often more difficult than learning the right things.
Comment . Maybe often (although this is debatable), but not always. And I would not draw conclusions from here at all, since there is a very dubious basis.
Sometimes the task of the project manager is to say "I know that it did not work there, but maybe it will work for us." A junior programmer is usually the best candidate to test such a theory: he can collect a sample of an idea or a prototype without drawing into it the prejudices accumulated by a senior programmer over the years. As a junior programmer, I often performed such work, testing new tools and technologies, rewriting code snippets in an alternative way, testing ideas that other employees hurriedly shoals. I often discovered improvements in architecture, and the company's software became tangibly better. In some cases, it was possible to speed up the page loading by an order of magnitude; or combine several pages into one, avoiding weeks of support in the future; or get rid of inefficient technologies that would lead to loss of time.
Comment . Depends on many circumstances. The author just got lucky with himself. From experience I can say that it often does not work.
Many companies can afford such wastefulness as solving a problem or writing code by locking a few senior programmers in the conversation to get something. But if you add a few junes there - that is, developers, whose time it is permissible to spend on one-time experiments and unusual ideas - then you can see what improvements this will give your products.
Comment . You can also see how easily a great product turns into a rubbish bin. Suffice it to recall Borland.
As for the quality of software, junior programmers usually perform important work that few people notice: they are holding back the abstruse, over-wise code that their older colleagues tend to write.
Comment . So I see how govnokod dilutes overly smart code. Probably, I will make a discovery for the author: a cool developer will never write overly smart code, since he knows that people will read him. He will responsibly approach this case. Apparently, we have different ideas about what a senior programmer is.
It can be easily read, modify, and extend.
- Jamon Holmgren (@jamonholmgren) September 17, 2018.
One of the undervalued skills of a programmer is the ability to write code that a medium or mediocre programmer can easily read, modify and extend.
Comment . In truth!
If you change "medium or mediocre" to "junior", then you will immediately see the system. The code base is the abstract imprint of the critical thinking of its authors. A sensible combination of junior and senior programmers creates an opportunity to simplify the code, which speeds up the writing of features over time.
Comment . A typical example of how easy it is to transform a logical chain into a wrong result from a basic basic premise with a simple stroke of a pen. Those. in order to write simply, you need to have people who would not understand the complex? For some reason I have always believed that simple is better than complex, regardless of. For me to understand simple code is easier than complex, I apologize for the tautology. Those. it is always profitable, regardless of the degree of procarminess.
To summarize: the “only seniors” principle widely used in IT underestimates junior programmers. This is bad for everyone, especially when the organization believes that without novice specialists, everything will be easier. Although some of these companies are financially successful, one can imagine the enormous amounts spent that they have to demolish their budget because of this approach.
Comment . To summarize: the incoherent jumble of weak arguments proves that the author does not own the basic logical primitives, and is trying to pull an owl on the globe.
If your company overtakes competitors on this issue - that is, it knows how to hire, train, and retain junior programmers - then you yourself already feel all the advantages that I only superficially described in this article. You have lower turnover, higher diversity of specialists and less overhead than those of competitors. In your software less bugs and more joy. There are, of course, other factors. But a positive approach to junior programmers is an important sign of the quality of the office at all levels.
Comment . If the company is still developing and systematically adheres to a certain approach, then this is an important sign of the company's quality at all levels.
The essence of any company is making money. If the company has been successfully engaged in this for several years, then this behavior is viable. Moreover, as a rule, ambitious startups do not have the opportunity to hire novice programmers, since it is necessary to create a product in the shortest possible time of a certain quality, there is no opportunity for acceleration and a set of experience.
Criticizing a company for not accepting someone and blaming it for it is an extremely strange step. The company owes nothing to anyone. Even if she goes broke - that is her right.
I am not against the June. Itself was once so. Juny awesome. Sometimes you look at a novice programmer and realize that you will have nothing to do here after he grows up. In the meantime, work a little.
From my point of view, different projects require different people with different qualifications and specialization. Unable to make a universal recipe. However, I believe that Netflix has made a very interesting precedent, and this approach deserves at least attention.
PS Noticed a big and stupid mistake, which the author said at the beginning of the article?