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.
I'm a professional PHP, Python and Javascript developer from the UK. I've worked with Django, Laravel, and React, among others. I also maintain a legacy Zend 1 application.
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?
I'm a professional PHP, Python and Javascript developer from the UK. I've worked with Django, Laravel, and React, among others. I also maintain a legacy Zend 1 application.
The new functionality was a new home page, so I'd built it in React as opposed to the PHP and spaghetti jQuery of the rest of the site
The developer brought onto the project is experienced. She hadn't used React, but had used Vue, and could easily draw parallels between the two
The division of labour. My CSS skills have never been that robust and I'm happy to stick to writing server-side code and Javascript, so I just put together some basic React components for the front end and left it to her to style them.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.