Max is a life enhancer for tech & entrepreneurship. Which seeks to blend both to build innovative products or services for the world that solves hard problems.
That's a good rule and that's provided that they know they are getting into a legacy system. As Simon and you had mentioned unless they know what they are doing and prepared for it they will fall badly. So it makes total sense to have a new developer working on maintenance before working on new features.
I understand that new systems will become legacy systems eventually. Therefore there's a need to understand and learn ways to tackle legacy systems regardless your own focus or type of work you want to do.
What I am saying is that if I were to do the same thing, say bring a developer who had worked only on legacy systems into greenfield projects like those in startups. It will be quite challenging for them to tackle greenfield project like those in a startup. Since the focus is towards speed, adaptability, resourcefulness and product market fit that you are building for.
Agreed, there are challenges joining a greenfield from brownfield but having done that myself I think the challenges are lesser - if only because most devs have started new codebases themselves for learning and side projects. It's hard to grow a side project to 3,000 SQL tables and 6 interconnected APIs and a fragmented front end.
Max is a life enhancer for tech & entrepreneurship. Which seeks to blend both to build innovative products or services for the world that solves hard problems.
Yup I got to agree on they might have a easier time to transit. I won't say that might be easy including things that brownfield projects does not contain.
Like design, business value/case for the solution your building, resources availability, prototyping and time to adapt to rapid changes 2 weeks from now or less.
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.
That's a good rule and that's provided that they know they are getting into a legacy system. As Simon and you had mentioned unless they know what they are doing and prepared for it they will fall badly. So it makes total sense to have a new developer working on maintenance before working on new features.
I understand that new systems will become legacy systems eventually. Therefore there's a need to understand and learn ways to tackle legacy systems regardless your own focus or type of work you want to do.
What I am saying is that if I were to do the same thing, say bring a developer who had worked only on legacy systems into greenfield projects like those in startups. It will be quite challenging for them to tackle greenfield project like those in a startup. Since the focus is towards speed, adaptability, resourcefulness and product market fit that you are building for.
Agreed, there are challenges joining a greenfield from brownfield but having done that myself I think the challenges are lesser - if only because most devs have started new codebases themselves for learning and side projects. It's hard to grow a side project to 3,000 SQL tables and 6 interconnected APIs and a fragmented front end.
Yup I got to agree on they might have a easier time to transit. I won't say that might be easy including things that brownfield projects does not contain.
Like design, business value/case for the solution your building, resources availability, prototyping and time to adapt to rapid changes 2 weeks from now or less.