I wouldn't do this exactly the same way with fully trained Sr engineers, but a whole team of 1-3 year engineers I would certainly do this.
How else will they learn? I don't mean this in a snarky way, but what other options are there? Code review is _terrible_ for training. It happens at the worst possible time, when the only options left are rework. Micro reviews like this give them a chance to explain what they are doing and thinking, usually they figure out issues on their own this way. It's a chance to point out edge cases they haven't considered. Lots of times it's a chance for me to notice a gap in their training, like maybe they forgot that SQL migrations need to put into a file and committed, not just run locally in their database. Or maybe they are trying to edit an autogenerated file. Maybe they are building something that already exists because they didn't read through existing libraries. The list goes on and on.
The only other ways they can be trained is just by doing and making a huge mess, which is extremely inefficient. Plenty of Jr engineers will never become a Sr engineer without feedback and mentorship, they will just make messes, never improve, get frustrated, and leave the industry. Notice the recent SO survey showing how few devs we have with more than 7 years. I think total lack of training is a big part of this.
I don't want them to waste days building a feature totally wrong, then me spend hours writing up a "now do it this way", just to have them rewrite it all.
This isn't creative writing, this is engineering.
Better to make small nudges along the way, finding gaps in their knowledge, pointing out resources, articles, videos, and tools to get them up to speed. Then over time they get the satisfaction of needing less and less guidance, and being able to provide that guidance to others on the team.
Definitely it's possible for this to be oppressive. It's possible for this to be micromanaging. I think the same is true for the style of go away for a week, come back and I'll point out a week's worth of mistakes all at once now that you think you're done. Having done both styles, I think this is far less wasteful and is much more humane.
The way I look at it is this, if I'm the code/architecture quality gatekeeper, I want to give feedback as early and often as possible. Imagine you could only run unit tests after you've written all the code. That would be infuriating. I want to run them all the time, knowing very clearly what still needs to be done to finish a project. This is me providing that feedback about quality and architecture as early and often as possible.
All that said, I'm probably a lot more aggressive with the size and scope of a project I'll let a Jr dev take on. I've got one now doing a month long series of features that all build to one coherent epic. He's gaining more and more momentum and confidence, needing less and less guidance each day. There's not a change he'd get to build something this huge on a normal team, they'd reserve it for a Sr dev, but because he's able to figure out each day what needs to be done, he's able to build out something really quite impressive. He's written 100% of the code, made a majority of big decisions himself, and still I'm 100% happy with everything that is committed. The second he is done he'll merge into main.
Also consider that while Gen-X developers grew up at a time where they can deep dive into tech on their own, with little support (what internet?), Gen-Z developers expect a much different experience (where _isn't_ the internet?). Helping them grow is how software will be relevant for the next generation.
One thing I have been noticing about the Gen-Zers coming in is that they seek out mentorship and are very open to it. Why not lean into it?
Exactly! I find many (not all) younger developers respond extremely well to this more present mentorship.
Also let's be real, the average project now is 10x the complexity of the projects when I was getting started in the late 90s. I remember my mentorship was little more than being given the pocket guide to Perl and told to read it. Also told to use emacs.
But we had no code review, version control, docker, container orchestration, no React, TS compiler, no HTML+CSS+Tailwind, no build pipeline yml, no ORM, no OOP, no unit tests. We "deployed to prod" with ftp. We ran jobs with cron.
We had a maybe 1000 lines of Perl scripts and a production database.
So it's not like there was a lot to learn. Of course a year in I still barely knew what a function was. After a year I learned PHP and made a basic website that talked to a MySQL database I on our one server.
The expectations were extremely low, there was plenty of time to putter and rework over and over.
So I try to be empathetic that this is a job that needs an extreme amount of on the job training.
> But we had no code review, version control, docker, container orchestration, no React, TS compiler, no HTML+CSS+Tailwind, no build pipeline yml, no ORM, no OOP, no unit tests. We "deployed to prod" with ftp. We ran jobs with cron.
My neck hurts from alternatively nodding in approval, to shaking my head vigorously side to side, as I go over the commas.
Haha fair enough, maybe you're not using all these things. I suspect though if you aren't doing a webstack then there is complexity elsewhere, like external API calls, message queues, enterprise service buses, s3 buckets, ML pipelines, k8s, monad transformers, SSO integration, security, distributed tracing, etc.
Many systems are vastly more complex than 20 years ago. Even just system integration is a complex web.
It's our duty to train our employees. I disagree with the philosophy that hires someone with <5 years in the field just to throw tickets at them like they are fully trained. I've seen so many talented engineers wither away and quit from this lack of mentorship. It's disrespectful to them.
If you are a tech lead, it is your duty to spend the majority of your time training.
If there are high level tasks that need to be done that only you can do, have a Jr team member to it. They obviously cannot, and will need to research the subject, learn the area, and then you can use daily review and pairing to ensure they complete it successfully. I'd prefer to have a Jr dev take a 3x to accomplish a Sr level task like SSO integration while learning the area deeply than they fiddle with some CSS while I do the SSO integration.
This builds resiliency in the team. Now two people deeply understand the SSO integration. At the same time another Jr dev maybe was adding our first message queue for job processing. Again this is far too difficult for a Jr dev, but they are getting little bits of feedback throughout the process, I'm getting the message queue we need, and the team now has two people who deeply understand it, instead of one.
If I'm on vacation, my entire team should be able to handle any issues, because they built it all.
> Haha fair enough, maybe you're not using all these things.
Oh, I am - just not very happily :)
Not to get too into the weeds here, but I could live a long and happy life if I never had to read or write yaml that controls our build or CI pipelines, or troubleshoot layers of Helm and Kubernetes to figure out why our database migrations fail but only when running `alter` statements, or if I never had to manually search for `<FooBar` to figure out where some parameter is being passed from through twelve layers of React components down to FooBar itself.
But I also remember working in a world where Junior Engineer me FTP'ed code directly to production, hoping that `index_new2.php` was the latest, correct file on the shared network drive, and that nobody erased `index_old.bak` over the weekend because I still had to port some functionality over on Monday. (Joke was on me, by Monday the numbers had already come in, and it turns out that using Javascript to do financial calculations was a Very Bad Idea, and the functionality was no longer relevant. Plus, by then, I'd forgotten whether it was in `index_old.bak` or `index2.php.bak`.)
How else will they learn? I don't mean this in a snarky way, but what other options are there? Code review is _terrible_ for training. It happens at the worst possible time, when the only options left are rework. Micro reviews like this give them a chance to explain what they are doing and thinking, usually they figure out issues on their own this way. It's a chance to point out edge cases they haven't considered. Lots of times it's a chance for me to notice a gap in their training, like maybe they forgot that SQL migrations need to put into a file and committed, not just run locally in their database. Or maybe they are trying to edit an autogenerated file. Maybe they are building something that already exists because they didn't read through existing libraries. The list goes on and on.
The only other ways they can be trained is just by doing and making a huge mess, which is extremely inefficient. Plenty of Jr engineers will never become a Sr engineer without feedback and mentorship, they will just make messes, never improve, get frustrated, and leave the industry. Notice the recent SO survey showing how few devs we have with more than 7 years. I think total lack of training is a big part of this.
I don't want them to waste days building a feature totally wrong, then me spend hours writing up a "now do it this way", just to have them rewrite it all.
This isn't creative writing, this is engineering.
Better to make small nudges along the way, finding gaps in their knowledge, pointing out resources, articles, videos, and tools to get them up to speed. Then over time they get the satisfaction of needing less and less guidance, and being able to provide that guidance to others on the team.
Definitely it's possible for this to be oppressive. It's possible for this to be micromanaging. I think the same is true for the style of go away for a week, come back and I'll point out a week's worth of mistakes all at once now that you think you're done. Having done both styles, I think this is far less wasteful and is much more humane.
The way I look at it is this, if I'm the code/architecture quality gatekeeper, I want to give feedback as early and often as possible. Imagine you could only run unit tests after you've written all the code. That would be infuriating. I want to run them all the time, knowing very clearly what still needs to be done to finish a project. This is me providing that feedback about quality and architecture as early and often as possible.
All that said, I'm probably a lot more aggressive with the size and scope of a project I'll let a Jr dev take on. I've got one now doing a month long series of features that all build to one coherent epic. He's gaining more and more momentum and confidence, needing less and less guidance each day. There's not a change he'd get to build something this huge on a normal team, they'd reserve it for a Sr dev, but because he's able to figure out each day what needs to be done, he's able to build out something really quite impressive. He's written 100% of the code, made a majority of big decisions himself, and still I'm 100% happy with everything that is committed. The second he is done he'll merge into main.