It's called comparative advantage. Have junior engineers work on easy things that are a waste of time for senior engineers to do. Personally, I'd rather not have my $200,000 a year senior engineer working on debugging cross browser javascript or writing documentation.

Hopefully he's not wasting a bunch of time debugging cross-browser javascript because A) He already knows how to fix it, or B) It didn't break to begin with. JavaScript is hardly difficult material.

As for documentation, I'm not sure quite what to say. The best person to document code is the person that's writing it. The best person to document things that aren't code is a technical writer, not an engineer.

Those were just example of simple tasks that a junior developer can do. And a junior develop in my company is someone of any age who has less experience. What kind of industry would we have if we only hired senior developers? If we said junior developers have no value? I guess we'd be a bit like the fashion industry where anyone new is just supposed to work for free.

Ah, I love when "I can't think of a way to do it" turns into "it's simply impossible".

Not only can I not think of a way to do it, I have never, in 15 years, seen an organization that successfully managed junior engineers in a way that resulted in the production of code on par with what senior engineers would produce.

Getting good work out of junior engineers requires a management investment greater than the cost of simply hiring experienced engineers to begin with, and they still will not produce code to the same level of robustness and quality.

I can see from your company that you don't operate this way. I assume this choice expands the apparent pool of available applicants, but it also ensures that your company is likely completely uninteresting to senior, experienced, genuinely expert engineers.

In my experience, there are two kinds of engineering managers. The first is the kind that has figured out (or thinks they've figured out) how to get decent enough code out of inexperienced or just plain bad engineers. The second is the kind that realizes that they don't have to work nearly so hard or jump through so many procedural hoops if they just hire people that know what they're doing to begin with.

What's more, those experienced people tend to have extensive contacts and make it easy to hire their friends.

That said, I'm happy to let you spend the time, money, and energy training and managing junior engineers, while dealing with their subpar work output.

This thread has grown somewhat stale but I never replied initially and I think I can probably address some of the differences in our experience. I don't run a company, so I almost certainly have a different viewpoint, but senior engineers are often great at displacing blame/CYA, so it may not always be apparent to management what is really going on in an organization. I've never worked at a place that had particularly well-engineered software to begin with, and there were those who were either capable (and willing) to do a little bit of ad-hoc coding with an eye towards refactoring on a larger scale, or those who weren't. I've had really bad experiences with 'senior engineers' being left to build something semi-autonomously, thinking they know the best solutions a priori, etc., and seeing nothing functional at the end of months of effort. I've seen it happen way more than with junior engineers who are at least a little unsure of themselves. I'd probably take a good senior engineer over a good junior one for many of the hand-holding reasons you point out, but I really have worked with several young folks who did not have the problems you've encountered.

Fascinating! Please tell me more about how I run my company, and all the things I apparently believe. Plus more about what kind of manager I am.

You certainly have an active imagination, so I'm sure the next things you make up would be just as interesting.

Sorry, apparently somebody downvoter prefers dry prose to sarcasm. A more temperate reply:

Flatline3, you're wrong in pretty much every particular about how I work and how my company works.

It's certainly possible to mentor younger developers well and at low organizational cost. It depends a lot on your process. In particular, I think pair programming, frequent commits, good unit tests, and collective code ownership together make it entirely safe to hire somebody younger, and you get substantial benefits.

I also think it's shortsighted to say, "Hey, let the shitty shops train junior developers." Great senior developers have to come from somewhere, and I think they'll never get great working at places that don't have their acts at least somewhat together. I benefited a lot from people taking a chance on me when I was younger, and I think I have a professional obligation to return the favor.