Probably the idea that adding more developers to a project slows it down.
We've all heard the quote about how nine women can't make a baby in one month, but it can be hard to understand why it's applicable to developers too.
This has to be tempered with how many you are adding. If you have a small team, say 3-5 programmers, adding another programmer should definitely speed up development.
If this is not true, then it's a reflection of your code, processed, and organization. If you are in this, then try bringing somebody on with the key purpose of fixing this state. It'll bring rewards quite quickly.
Certainly it's not an absolute.
If you have a project with clean code, good test coverage and continuous integration, then bringing someone else on board can be pretty painless.
Under other circumstances, it can be downright excruciating. I'm working on a Zend 1 legacy code base with some downright awful code that I inherited, as well as horrible jQuery spaghetti code, and bringing someone else on in the project to do some of the front end work did mean I had to take some time out to bring them up to speed on various aspects of how it worked, which in turn slowed me down.
I think that would probably trigger my problematic code consideration. I'm not saying it won't slow you down on some projects, only that clean projects should benefit.
Though, even here, how long did it slow you down for. Do you think the junior won't contribute more overall than the time you invested?
In this case, it wasn't too bad because:
In this case, most of the loss of velocity came from things like the adjustment to React and explaining the downright awful application structure. It was definitely worth bringing in someone else - it'd take me a lot more time and hassle to do a much crappier job of the front end.
However, if it had been a case of bringing in another back-end developer to work on similar tasks to me, I'd have had to spend a lot of time explaining what I could, going through the awful parts of the code base, and avoiding stepping on each other's toes.
Pretty obvious actually. The number of communications scales quadratically so then you need to put them into teams to stop them talking to each other at which point you've got multiple projects so then you need to manage the interface which means people have to talk to each other...
I'll compound it with: hiring a junior will never speed up development. Hire juniors when you have the time and breathing room to train them.
I think juniors are often better off working on their own projects if possible, rather than integrating into a larger project. Ideally these should be small and comparatively simple, and they can work their way up to larger projects. Code reviews would allow regular feedback on code quality and allow for potentially problematic code to be identified and refactored away.
I'd only feel comfortable bringing a junior onto a large existing project in cases where I already had good test coverage and continuous integration.
I disagree with this. Unless your hiring practice is broken, or your code is in awful shape, hiring juniors should add immediate benefit to a team. They may not be as productive as existing team members, but they should definitely improve total output.
You don't need to devote lots of time to mentor newcomers. I've never really had it interfere with my own work.
We’re a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.