Don’t not hire junior devs, either
Apologies for the double-negative ;) But there’s a missing piece to yesterday’s article on hiring devs. The lesson of that piece was that you can’t get around requiring some level of senior technical capability when you’re starting anything technical, whether that’s a new business or an internal improvement initiative. The lesson was not that you shouldn’t have any junior developers on your team, which is the other extreme of bad advice: “Now that AI is basically like a very eager junior, you can just fire all your junior devs, and hire an additional AI-augmented senior dev.”
Such advice is equally wrong. A healthy team has a healthy mix of all sorts of backgrounds, both in technical and lived experience. I could try to write a long and eloquent piece about this, but others have already articulated much better than I could hope to.
One is Charity Majors, Cofounder and CTO of the observability platform honeycomb.io and great writer with a fun style. Check out her piece from 2024 about it: https://charity.wtf/tag/junior-engineers/
Alex Jukes, Fractional CTO and fellow daily email writer, has a whole series of posts on it: https://engineeringharmony.substack.com/p/where-will-the-engineers-of-tomorrow
It seems to me that both ends of the spectrum come from a miscalculation:
“I’ll save the money from a senior engineer and just hire a bunch of juniors; who needs seniors with their complicated architecture anyway?”
“I’ll save the money from a bunch of juniors and just let AI + a senior loose; who needs juniors when you have Claude?”
There is a way to save money, and that’s by not wasting it thrashing around with an approach that leads nowhere.
