[half0wl]

How are you "training" them? It's important to drill down into what they're struggling with before you throw resources at them.

I've found that code reviews are the best way to mentor and transfer knowledge. And it goes both ways: you review their code, they review your code. When I'm explicitly training someone, I get them to review my code and I occasionally throw in some minor curveballs that I expect them to pick up on in the first few rounds (e.g. obviously incorrect conditionals, some convoluted loop, leaky interfaces, etc.) If they stamp the PR without picking up on those items, I highlight it using a "do you think this is correct/is there a better way for us to do this" line of questioning. 5-10 or so PRs later, they become the first to spot those issues :-)

[productized]

Thanks for sharing how you code reviews with your juniors! You're definitely more patient than me in that respect. I'll try that out.

Our training program mostly revolves around teaching them the fundamentals, where I give them some specs & resources, and once they code that, I give a code review: - They learned how to build some CLIs programs, where they make small clones of cat, find, grep, and cut. - They learned how to build some basic data structures such as linked lists and some sorting algorithms. - They learned some OOP by creating a CLI employee management system - Also some Network Programming by replicating the core features of the rack gem, and building their own web framework from scratch - They then take their hand-rolled frameworks, and they build the web version of the employee management system and ship it to heroku - Other projects also include some common tasks in the company, such as creating their own authentication system. - Lastly, they build their own design system using BEM CSS (a designer hands them a figma file, and they follow our internal CSS template / variables)

All of the above projects include code reviews, and the hope is that they learn how to become independent programmers & be able to contribute to any code, whether internal or open source. The goal is mastery of fundamentals.

I am not sure if I am too demanding -- our sprint is about 1.5 months long (0.5 months are for QA), but the expectation of that sprint is to ship one or a few features (e.g. a share button for a CRM for example).

[brycelarkin]

Lol. Aren’t you afraid you’re going to forget about those bugs and merge them in?

[Two4]

You'd probably branch off a previous feature branch, introduce the bugs then do a mock PR that doesn't get merged, maybe even against a copy of the dev branch in case of accidents.