Artificial intelligence will not create a cool development team for you, or How we underestimate hiring juniors
Writing code is not difficult, writing good code is difficult.
When I was 19 years old, I dropped out of college and moved to San Francisco. There I had to go to work as a Unix system administrator at Taos Consulting. But I didn’t have time to start – I was immediately lured away by a startup, where I began working as a developer of mail subsystems.
I always knew that I could find a job. There were many offers, and more importantly, the employers’ demands were not too high. If you knew how to sling HTML or work with the command line, sooner or later there were people willing to pay you a salary.
Was I a genius born with a computer keyboard? Of course not. I lived on the outskirts of Idaho and was homeschooled. I first touched a computer at the age of sixteen, when I went to college. I got to the university thanks to a scholarship in the classical piano program, a little later exchanging it for a string of humanities subjects: classical Greek and Latin, music theory, philosophy. Everything I learned about computers, I learned on the job, as a system administrator in the computer science department at the university.
Remembering all this now, I understand that I got into IT at a very good moment. I shudder to think what would have happened if I had started a few years later. All the IT career ladders that my friends and I climbed have long since fallen apart.
IT is growing up
To some extent, any professional industry matures as it develops. At the very beginning, any field of activity is like the Wild West – low stakes, no laws, and rudimentary standards. Even if we take the history of the birth of non-IT industries – medicine, cinema or radio – the similarity in development will be striking.
Every young technology has that magical moment where the lines between roles blur and anyone who is motivated, curious enough, and willing to work hard enough can seize control of that technology.
But this is a very fleeting moment. That's how it should be. The amount of prior knowledge and work experience required by newcomers to the industry is growing by leaps and bounds. The stakes are raised, the goals become more ambitious, and the cost of error increases sharply. Certificates, training courses, standards, and legal norms appear. We begin to argue fiercely whether developers can be considered engineers.
Software development is an ongoing apprenticeship industry
Today, few people want to entrust the rotation schedule of on-duty employees to some teenager without a diploma. The prior knowledge required to get started in the industry has increased, the pace has quickened, and there is much more at stake. Nowadays you can no longer learn literally everything on the job, as I once did.
But even at university you can’t learn everything in advance. A specialized diploma will help prepare you for research in the IT field rather than for the everyday work of a developer.
Perhaps a more practical path into IT is a good programming bootcamp, honing practical problem-solving skills and working with modern tools. In any case, you're not so much learning “how to do a specific job” as you are “learning the basics so you can understand and use the tools you need to use to learn the job.”
Creating programs requires constant practice. You can't become a developer just by reading textbooks. You can only learn through practice. You need to do, do and do again. No matter what education you receive, you will still gain most of your knowledge on the job. And you will study all the time. You need to study and teach all your life. In an industry that is changing so quickly, it could not be otherwise.
It takes seven years or even more to become a competent developer. Most often, a specialist of this level is called a “lead developer”, in other words, a “senior”. To do this, you need to write, review and deploy code every day for many years, in a team with much more experienced developers. This is approximately how many years it takes to become a professional.
What does it mean to be a senior
I often hear indignant objections about deadlines, for example:
“Seven years?!” Yes, two years was enough for me!”
“And I became a senior in just four and a half years!”
I'm glad for you. No, it’s not that seven years is some kind of magic number. But it takes time and experience to grow into a mature developer who will become an anchor for his team. Moreover, this requires practice.
We began to call developers who can prepare code and gain profit in terms of productivity as seniors. In my opinion, this is a huge mistake. It seems like it turns out that other developers are less productive, but this is not the case. We are missing the true nature of software development, in which writing code is only a small part.
For me, the concept of senior is not primarily tied to the ability to write code. What is more important for a senior is the ability to understand, support, explain and manage a large body of software in production over a long period of time, as well as the ability to transform business needs into technical solutions. Much of the work revolves around building and maintaining large, complex sociotechnical systems, and code is just one representation of those systems.
So what is it like to be a senior? This means that, first of all, you have learned to learn and teach; keep these models in your head and talk about them, and you can work with these systems for a long time, you know how to maintain and expand them. This means you are a sound thinker and can trust your instincts.
And this brings us smoothly to the question of AI.
Stop ruining your own future
It's really, really hard to get a first-time job as a developer. I didn't realize how difficult it was until my little sister started looking for work. It took a recent graduate, an excellent student, with little practical experience, hardworking and friendly, two (!) years to secure a job in her field. This was several years ago. Paradoxically, since then, getting a job has become even more difficult.
Last year, I came across articles from time to time that entry-level jobs in various industries is gradually being replaced by artificial intelligence. In some cases, this endeavor has its advantages. If the work involves routine actions: for example, you need to convert the format of a document, read and take notes on a lot of texts, or replace one set of icons with another, such tasks can really go to AI. I don’t perceive this as a revolution – it’s just a continuation of the trend of automation, which now copes with both text materials and mathematical problems.
But recently, it seems that some tech executives and so-called thought leaders have sincerely believed that generative AI (GenAI) is about to take over the jobs that the Junes are currently doing. I have read countless articles about how the work of junior developers has been completely automated or that the need for juniors is approaching zero. It just drives me crazy.
All this indicates a deep misunderstanding of what developers actually do.
By not hiring and training juniors, we are destroying our own future.
This needs to be stopped.
Writing code is the easiest thing
People seem to think that writing code is the hardest part of software development. But no. This was not and will not be the most difficult part of the job. On the contrary, these are the simplest tasks in a developer's job, and they will become easier and easier.
The hardest part is what you do with the code: how you handle it, how much you understand it, extend it, and how you manage it throughout its lifecycle.
To begin with, June learns to write lines, functions and code snippets, and debug them. He accumulates experience and gradually rises to the rank of senior. At this time, he learns to compose entire systems from programs and manage them through stages of change and transformation.
Sociotechnical systems are made up of software, tools, and people. To understand them, you need to understand the interaction between software, users, production and continuous change. These are fantastically complex systems, characterized by chaos, non-determinism and unpredictable behavior. If someone claims to have a good understanding of the system they are designing and working with, then either it is a very small system, or (more likely) they lack the knowledge to understand what exactly they don't know. Code is simple, but systems are complex.
The current wave of generative AI tools has opened up the ability for us to write a lot of code, very quickly. Simple tasks become even easier with amazing speed. But these tools in no way help you understand and work with the code. Moreover, they make difficult tasks even more difficult.
Writing code is not difficult, writing good code is difficult
Perhaps, if you read various analytical articles, in your imagination, developers cheerfully compose prompts for ChatGPT or generate tons of code in Copilot, and then carefree commit this stuff to GitHub and go home. But the reality looks different.
It would be more appropriate to think of tools like Copilot as a cool autocompletion or copy-paste feature, or as the offspring of a vicious passion for Stack Overflow search results and Google's “I'm feeling lucky!” Every time you go all-in.
These tools are most useful when there is already a parallel in the file and you just want to copy something with minor changes. Or when you write testsand you have a giant block of repeating YAML files, and it repeats the schema with the necessary column and file names inserted, like an automatic template.
But the generated code cannot be trusted. I never tire of repeating this over and over again.
AI-generated code looks reasonable, but even when it seems to work, it rarely matches what you need it to do.
AI vigorously generates code that cannot be parsed or compiled normally. It creates variables, method names, function calls; he hallucinates and invents non-existent fields. The generated code does not follow your programming practices or standards. Artificial intelligence is not going to do the refactoring or pick up intelligent abstractions for you. The more important, complex, or meaningful that piece of code is, the less likely you are to get a usable artifact from the AI.
You may be able to save time by not creating the code from scratch. But you will have to check the result line by line and only then commit it or send it to production. In many cases, this takes as much time as writing the code itself – especially these days, when we have such advanced autocompletion capabilities at our disposal. Bringing AI-generated code into line with the rest of the code base sometimes requires a LOT of work. Frankly speaking, the game is often not worth the candle.
It's not that hard to create code that can compile, run, and test successfully. It's much harder to build a code base that will be usable for many years to come for individuals, entire teams, and future generations of teams to work with, change, and talk about.
How developers are actually using generative AI
This is a fact of life: you can generate a lot of code very quickly, but you cannot trust such a result. Categorically. But there are still use cases where generative AI consistently shines.
For example, you can ask ChatGPT to generate sample code using unfamiliar APIs. It's easier than reading the API documentation – after all, the corpus was trained on repositories that used the APIs for real workloads.
It is convenient to use generative AI to create highly specialized or understandable code that is unpleasant or tedious to write. The more predictable the scenario, the better these tools will do at writing the code.
Generative AI will get the job done if you need to efficiently copy and paste data into a template – just as if you were generating the required code using sed/awk or a vi macro every time.
It's also great when you need to write small functions that do things in languages or scripts you're not familiar with. If you have a snippet of code in Python, and you need to get the same thing in Java, which you don’t work with, AI will cover you.
Again, don't forget, there's a 50/50 chance that the result could turn out to be completely out of whack. Before checking the results manually, you should always start with the assumption that the AI made mistakes. And yet, these tools, one way or another, help speed up the work.
Generative AI is somewhat reminiscent of June
My colleague Kent Quirk says, “AI is a fast-paced developer with a very fast typing speed.” A very bright image that hits the spot.
Generative AI is, in a sense, truly June, because its code cannot be taken and immediately rolled out into production. You are responsible for it – legally, ethically and practically. You still need to spend time understanding and testing what he did, stylistically and thematically refining the results so that they fit into your code base, and colleagues can understand and support this code further.
In fact, this is a completely valid comparison, but only if your code is standalone, one-time use, that is, if you do not plan to embed it into a larger project and if other developers will not have to read and modify it.
Yes, there are also such areas in the industry: one-time technological code that no one will read is suitable for them. There are agencies that every year churn out dozens of one-off applications created for a specific marketing event. After this, no one needs this code. But this approach does not apply to most programs.
A one-time code is rare; code that should last for many years is the norm.
Even when we plan to use the code once, it often turns out that we were wrong.
But generative AI is not part of your team
The code that GenAI generates cannot be relied upon; in this regard, it is really like June. But this is the only point in which this comparison is true. Because hiring a person who writes code to your team is completely different from creating code automatically. Such code can be obtained from anywhere: from Stack Overflow, Copilot, you never know where else. And it doesn't even matter. In this case, you have no feedback loops, there is no person on the other end of the line who is gradually learning and working on himself, there is no influence on the vibe and culture of your team.
Let me state the most obvious thing: giving a junior feedback on the tested code is completely different from editing the generated code.
Your efforts pay off when you invest them in another person's professional growth. This is an opportunity to pass on to someone else the lessons you yourself have learned over the years. The very need to formulate feedback in order to convey your thought to another person forces you to think more deeply about the problem. In a way, it helps you understand the material better.
When you have a new junior, the team dynamic immediately changes. An atmosphere emerges in which asking questions is normal and even necessary, and learning is an ongoing process. We're talking more about team dynamics in the moment.
The time you spend to bring up a junior sometimes pays off unexpectedly quickly. Time flies ☺️ When we hire employees, we often overestimate seniors as much as we underestimate juniors. Stereotypes are of little use.
We underestimate the cost of hiring seniors and overestimate the cost of hiring juniors
People think that a senior can be thrown into a team and he will immediately work productively, but a newly hired junior will endlessly drag the team to the bottom. Both are not true. In fact, most of the work that most teams face isn't all that difficult if you break it down into its component parts. She always provides novice developers with space for professional growth.
Here's a simplified look at things for your accountant: “Why pay $100k to a junior and slow down the overall speed of work when you can pay $200k to a senior to make things go faster?” This is nonsense!
But I, you, and every concerned developer know: development works differently. This is a hands-on industry, where productivity is determined by the results and throughput of each team, not the individual.
A person can influence the speed of a team in different ways. However, there are also different ways to drain energy from the team and create interference for the work and for everyone around. This is not always related to a person’s personality (at least not in the way that is commonly believed), and writing code is only one of the criteria that affects the speed of work.
Every developer you hire needs time and help with onboarding before their work begins to make a tangible contribution to the overall goal. Hiring and training developers is expensive, regardless of their level. Any senior needs time to form a mental picture of the system, become familiar with the tools and technologies, and get up to speed. How much time? This depends on whether the senior has experience working with your tools and technologies, on how well and clearly organized your code base is, how well the onboarding process is established, and on other factors. In general, this adaptation lasts for 6–9 months. It is possible that the senior will reach his full power only in about a year.
Yes, June will take longer to gain momentum. And yes, the team will have to put more effort into him. But this is not forever. The Junes will become profitable in about the same time: from six months to a year. But they develop much faster than their more experienced colleagues. Don't forget that a junior's contribution to the work can be much more than just the code they write.
You don't have to be a senior to create value.
According to my observations, mid-level developers are more productive than others when it comes to writing code and creating various functions. They are not yet bogged down in meetings, curation, mentoring, advertising and architecture. Their working time is not yet interrupted by switching to other tasks, so they can calmly engage in programming. Arriving at the office, the first thing they do is put on headphones, write code all day, and go home in the evening, having done a lot of work.
Middles are in this pleasant temporary state where they have already gotten their hands on programming and can be very productive, but are still learning how to create and maintain systems. The only thing they do is create tons of code.
And they do it with great enthusiasm. They get a kick out of it! They are not bored with writing a web form or page for user authorization for the thousandth time. Everything is new for them, everything is interesting. Typically, this means they will perform better, especially under the gentle guidance of a more experienced colleague.
Middles on the team are amazing. But the only way to get them is to hire juniors.
A team that has middles and juniors develops excellent immunity against excessive and premature complication of decisions. They have not yet gone deep enough into the problem to accurately represent all the edge cases that they need to provide for. Everything is simple for them, but simplicity is very difficult to achieve.
Arguments for hiring juniors in the long term
If you ask, almost everyone will sincerely agree that hiring juniors is a good thing… But someone else should do it. This is because in the long term, the arguments in favor of Junes sound convincing and understandable:
We need more seniors in the industry.
And someone has to raise them.
The work of juniors is cheaper.
They can bring some much-needed variety.
Junes are often very loyal to companies that have agreed to spend time and effort on training them, and sit in one place for years.
Did we mention that someone needs to take charge of this?
But long-term thinking is not the strong point of companies in particular and capitalism in general. If you put the question this way, it turns out that hiring a junior on your part is an act of charity, and it will cost you a lot. And companies want someone else to take on these costs. This brings us to the point where we are now.
Arguments for hiring juniors in the short term
But even in the short term, there are arguments in favor of hiring juniors – selfish and purely practical arguments why it is beneficial for the team and the company. We just need to shift the focus a little from individuals to entire teams.
Let's start with this: Hiring a developer is not about “picking the best person to do the job”. Hiring developers is about building teams. The smallest unit of ownership of a software product is not an individual, but a team. Only teams can own, build and maintain the core of the software. In essence, this is a joint, cooperative activity.
If hiring developers meant only choosing the “best”, it would be worth hiring the most advanced and most experienced people you can get for the money you have – here by “senior” and “experienced developer” we mean the “most productive” employee . Doubtful, but ok. But the productivity of an individual employee is not what we need to optimize. What's really important to optimize is team productivity.
The best teams are those that combine different strengths, perspectives, and levels of expertise. Monoculture can be incredibly successful in the short term—sometimes it even outperforms team diversity. But monoculture does not scale well and is not able to flexibly adapt to new challenges. The longer you give up diversity, the harder it will be to catch up.
You need to hire juniors to work, and not just once, but constantly. It is necessary to staff the funnel with personnel from the lower level. Juniors remain juniors for only a couple of years, and middles turn into seniors.
Superseniors are not the most suitable candidates for mentoring juniors; Employees who are one step higher and still remember well what it’s like to be a newbie usually cope best with this.
A healthy, high-performing team has people at different levels
A healthy team is an ecosystem. You don’t make up a product development team of six database specialists and one mobile developer. You should also not form a team of six seniors and one junior. A good team includes specialists with different skills and grades.
Have you ever worked on a team made up entirely of lead or principal software engineers? Not that it was fun. This is an ineffective team. The amount of work involved in creating and planning a high-level architecture is limited, as are the number of big decisions that need to be made. Leading engineers spend most of their time doing boring, routine work, so they tend to overcomplicate solutions, oversimplify things, or sometimes both. They compete with each other for fun and come up with reasons for technical clashes. They always don't document things and don't invest enough in what makes systems simple and manageable.
Teams that employ only middle players, or only newcomers, or only seniors, will suffer from different pathologies and will always have similar problems with competition and blind spots. The work itself has a wide range of challenges – from simple, highly specialized tasks to important and risky architectural decisions. It makes sense that the people doing the job would have different levels of competence.
In the best teams, no one gets bored because each employee works on a task that interests him, thereby pushing his own boundaries of what is possible. The only way to achieve this is when the team consists of people with different skill levels.
The company's bottleneck is hiring, not training, employees
The bottleneck we are facing now is not training new juniors and developing the necessary skills in them. The problem isn't that the juniors aren't trying hard enough; I've come across a lot of good, sensible advice on this topic. But this will not solve the problem.
The problem is that juniors are not hired. It's all about companies that treat June as a cost that they want to shift to someone else, and not as an investment in the future of their company.
After the first job, it is usually not difficult for a developer to find a job. But finding your first job is murder. It's almost impossible. Unless you graduated from one of the best universities in the country and got an internship at Big Tech, then this is a pure lottery, a matter of luck or personal connections. It was hard even before the “artificial intelligence can replace Junes” chimera emerged from the swamp. And now… It’s actually terrible.
Where would you be if you had not gotten into IT at one time?
I know where I would be and that's for sure not here.
On the Internet they like to make fun of boomers – a generation who, by inertia, graduated from university, bought real estate and retired, and then slightly pulled down the ladder they themselves climbed, and now teases young people with “sissies.” The “OK Boomer” meme may be here to stay. But maybe we can at least try to prevent “OK, lead engineer” from becoming the norm?
Nobody thinks we need fewer seniors
Many people think that we don’t need juniors. But no one believes that we need fewer seniors or that we will need fewer seniors in the foreseeable future.
I think it's safe to assume that everything that can be deterministic and automated will eventually be automated. Software development is no exception: we are point zero. Of course, we are always looking for ways to automate and increase the efficiency of anything – in fact, this is what we should be doing.
But large software systems are nondeterministic, difficult to predict, and suffer from unpredictable behavior. The very fact of having users brings chaos to the system. Components can be automated, but complexity can only be adjusted.
Even if we were able to fully automate systems and hand over their control to artificial intelligence, the fact that we do not understand how AI makes decisions is a huge, perhaps insurmountable problem.
Building a business on a system that people can neither understand nor debug is such an existential risk that no legal, financial or security team would ever sign up to it.
Maybe someday something similar will come, but from today such a future cannot yet be discerned. If I were asked to argue about this, I would not bet my career or company on the line.
In the meantime, we need more seniors. But the only way to get them is to correct the career funnel from which they then grow.
Should every company hire juniors?
No. The company must be able to provide the Junes with success.
Signs that indicate your company does NOT need to hire juniors:
You've been around for less than two years.
Your team is always on the go, or there is never a lull in your system.
You don't have experienced leaders, or you have bad leaders, or you don't have any bosses at all.
The company does not have a product development schedule.
No one on your team wants to be responsible for the juniors and be their mentor.
The only thing worse than refusing to hire juniors is the first job, where the junior has nothing to learn. Finding a second job is so much easier than getting a first one that I think most Junes would prefer a frankly lousy first job than none at all.
Working completely remotely is not exactly a stumbling block that cannot be bypassed at all, but it significantly complicates the situation. I would advise juniors to start looking for an office job. When you soak up everyday conversations and technical chatter in the smoking room, you learn much faster. Remotely you are deprived of this. If you do work from home, do not forget that you will have to work harder to compensate for the lack of such communication. I advise you to seek advice from those who have succeeded (yes, there are such people too).
I recommend that companies do not start by hiring just one junior. If you are planning to hire a junior, hire two or three people at once. Let each of them feel that he is not alone, then the situation will be less stressful for him.
No one will come and solve our problems for us
I came to the conclusion that the only way to change the situation once and for all was to take matters into my own hands. The developers and their bosses must continue to fight and make this battle personal.
As far as I know, most companies that have a program for recruiting and training newcomers only have it because the developers decided to fight for it. It was the developers, or less often their bosses, who proved why this program was needed, found resources for it, developed the program itself, conducted interviews and hired juniors, and then provided them with mentors. This is not some exotic project. This program is within the capabilities of most motivated, experienced developers. And, by the way, this is also good for their career.
The finance department will not lobby for such a program. The company management will not intervene. The more a position involves treating developers as fungible resources, the less likely they are to understand the importance of this approach.
AI will not come and solve all our problems for us, and will not write all the code for us. And even if I did, it wouldn’t matter. Writing code is only a small part of the job of professional developers, and perhaps the easiest part.
We are the only ones in the context who have the authority needed to drive change. And only we know that these changes are the cornerstone for creating great teams and professional growth.
Great developers grow on great teams. Nobody knows this better than developers and their managers. It's time to take matters into your own hands.
To grow, you need to get out of your usual zone and take a step towards change. You can learn new things by starting with free classes and guides:
Or open up prospects and get promoted from vocational training and retraining:
