Reduce the Pressure on Young and Inexperienced Developers
You can tell the contradiction: We can have close to no expectations of junior or, generally speaking, young and inexperienced developers.
Any expectations we do set change the profile we’re hiring for. To stick with the popular example, if we’re looking for someone with five years of experience, we’re looking for a medior. Not a junior. If we keep these expectations up insisting on hiring a junior, a working student, or even an intern, it gets ridiculous (and exploitative).
Consequences of Unrealistic Expectations
While we know of our thirst for experienced developers and see that thirst trickle down to entry roles, we may not consider what unrealistic expectations mean for young and inexperienced developers.
We show disrespect. Asking someone to meet a standard they cannot meet is not showing appreciation for who they are, what they bring to the table, or what else they have accomplished.
We evade our responsibility to mentor and coach. By suggesting a candidate knows everything, it may be argued that we’re playing a trick, acting like we don’t need to train them anymore. The candidate may see through that, but we may fool ourselves in a way that hurts us more than we think, because evading that responsibility also evades the respective growth.
We put undue pressure on candidates. Unrealistic expectations make for pressure. A young or inexperienced developer already has enough of that—after all, they’re just trying to get a foot in the door, to start their (new) career. This is hard. Add unachievable requirements and it gets worse.
We set candidates up for failure. When—unintentionally or not—we’re not up to our own responsibility and instead put pressure on young and inexperienced developers, we set them up for failure. We make it harder for them to enter the field, and we make it harder for them to acclimate and thrive in the field.
What we can do instead is to lower the expectations on young and inexperienced developers—and to raise the expectations on the mentoring and coaching of young and inexperienced developers.
There can be several reasons for hiring someone young or inexperienced, but we must be far past doing so in order to take advantage of them. This is a low, a terrible reason, and those motivated by it are fit for neither hiring nor leading.
The best reasons include that you want to give to the candidate and the community, and that you hire because you deem it part of your mission to train and nurture new talent.
I’m still tweaking my own management and leadership philosophy. But here’s my thinking around young and inexperienced developers:
In general, there’s a hybrid goal for each engineering team to complete work, do good work, and drive work forward; and to do so in (and contribute to) a healthy and diverse work environment and culture.
Young and inexperienced developers cannot immediately contribute to the first part of the goal, but are already one key for a healthy environment and culture. They may be so important for that, that in some team constellations, a junior developer could make the team more effective than a senior developer, just because that may avoid some sort of “seniority mono-culture.”
When hiring young and inexperienced developers, one fair condition is that they have some early link to the field—like, they’ve been studying computer science, or they went through a development bootcamp, or they’re running some technical projects.
More important, then, are soft skills: Is the person awake, are they motivated, are they a good culture fit?
The rest, then, is the manager’s and the team’s responsibility: They are now responsible for mentoring, training, and guiding the new team member so that they can be successful (to the extent that the new member accepts their own responsibility).
❧ Hiring juniors, hiring young as well as inexperienced developers is important and beautiful. But the challenge is training and mentoring them, and that responsibility should stay with us, and not be loaded off on new talent by setting unrealistic expectations. Let’s put the pressure on us, the experienced developers and managers, and reduce the pressure on new peers. That’s much better for everyone.
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma. I love trying things, not only in web development, but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
Maybe of interest to you, too:
- Next: On the Peculiarities of Counting the Number of HTML Elements
- Previous: 2021
- More under Web Development and Engineering Management, or from 2022
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try WebGlossary.info—and The Web Development Glossary 3K (2023). With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.