[luckydude]

This article works in theory, not so much in practice. The theory is fine, it's the reality of working in the real world where it is less fine. I think the author needs to rethink his approach in the context of a limited budget.

If your goal is to grow your junior engineers at any cost, great article. If your goal is to balance the benefit to the company/project with growing a junior engineer, less great.

And perl? For production code? I love me some perl, I really do, and I've written production code in perl (but it took 2 complete rewrites before I figured out how to do maintainable code in perl). I would not let a junior engineer anywhere near perl for production code.

[tboyd47]

It takes creativity to carve junior-level tasks out of a real backlog. But it can be done. You just need to have buy-in from your manager. They hired the junior not expecting them to be productive right away. What they usually don't realize is that they need the seniors to spend time mentoring them in order for them to ever be productive. If they can't allow time for that then it's just not a good place for juniors.

[avleenvig]

Indeed. As your business grows (it is growing, right - that's why you hired more engineers?) you need to scale yourself. If you don't, eventually you'll become the bottleneck.

Following this process has a definite cost up front. You have to give up doing some work in order to help someone else grow and learn the system. But once they do, your business now has an extra version of you. Not as experienced, but hopefully still pretty good. Let that person handle more work, trust them, and hire another person. Rinse and repeat.

The truth is that when you get more senior, you almost have to stop focusing solely on knocking out code or fixing problems yourself, and commit to helping others learn how to do it.

If you become the bottleneck, the business will start to work around you and then you will become irrelevant.