They're incorrect, and my reply to a sibling covers why in detail.
But to reword it: if you think the reason 0 to 1 work is typically a duct-taped mess is because of a lack of experience or understanding from greenfield devs, you'll probably fail at 0 to 1 work yourself.
Not that a noob developer great at selling has never landed 0 to 1 work, crapped out a half working mess and left with a newly padded resume... but maintenance work is missing out on by far the most volatile and unpredictable stage of a software project, with its own hard lessons.
The duct-taped nature of 0 to 1 work is usually a result of the intersection of fickle humans and software engineering, not a lack of knowledge.
-
People in maintenance can do things like write new tests against the production system to ensure behavior stays the same... what happens when 1 quarter into a 2 quarter project it turns out some "stakeholder" wasn't informed and wants to make changes to the core business logic that break half the invariants you designed the system around. And then after that it turns out you can't do that, legal pushed back. And then a few weeks later they came to an agreement so now we want a bit of A and B?
Or you're in consumer and there's a new "must have" feature for the space? Maybe you'd like to dismiss as "trend chasing", but that'll just doom your project in the market because it turns out following trends is a requirement for people to look at everything else you've built
Or worst of all, you know that quality engineering of the system will take 8 weeks, and there's a hard deadline on someone else's budget of 4 weeks, and you can of course decline to ship it, but then you'll need a new job. (and I know, you'll say "Gladly, I take pride in my engineering!", but again, you're probably going to end up maintaining a project that only survived by doing exactly what you quit over)
tl;dr it's Yin and Yang: you can't have one without the other, and you need to have a bit of the other side in you whenever you're working in the capacity of either to be a good technical leader.
You must be “that person” who joins a team, creates IMPACT!!!, reaps the review-time award, and fucks off to some other new team to do it all again before any of the difficult maintenance issues arise. I've spent far too much time cleaning up after people like that to ever tolerate it again.
See I thought how nuanced my argument was towards both sides, and calling out worst cases like:
> Not that a noob developer great at selling has never landed 0 to 1 work, crapped out a half working mess and left with a newly padded resume...
Would be enough to smooth over the minor complex that some career maintainers pick up: "I'm doing the cleanup to make their crap piles work and they're the ones getting treated like they make the industry go round?!"
But I guess for some that feeling goes really deep, and at that point you're just chomping at a chance to pattern match... so the fact my career spans from app agencies boringly maintaining top app store listings to safety critical HMI work for AVs wouldn't sway you that I've been on both sides: since I am now working on a startup! :D
There's your side and there's the other side, and no one who doesn't unilaterally deride the other must be against yours. Tough way to live to be honest.
They're incorrect, and my reply to a sibling covers why in detail.
But to reword it: if you think the reason 0 to 1 work is typically a duct-taped mess is because of a lack of experience or understanding from greenfield devs, you'll probably fail at 0 to 1 work yourself.
Not that a noob developer great at selling has never landed 0 to 1 work, crapped out a half working mess and left with a newly padded resume... but maintenance work is missing out on by far the most volatile and unpredictable stage of a software project, with its own hard lessons.
The duct-taped nature of 0 to 1 work is usually a result of the intersection of fickle humans and software engineering, not a lack of knowledge.
-
People in maintenance can do things like write new tests against the production system to ensure behavior stays the same... what happens when 1 quarter into a 2 quarter project it turns out some "stakeholder" wasn't informed and wants to make changes to the core business logic that break half the invariants you designed the system around. And then after that it turns out you can't do that, legal pushed back. And then a few weeks later they came to an agreement so now we want a bit of A and B?
Or you're in consumer and there's a new "must have" feature for the space? Maybe you'd like to dismiss as "trend chasing", but that'll just doom your project in the market because it turns out following trends is a requirement for people to look at everything else you've built
Or worst of all, you know that quality engineering of the system will take 8 weeks, and there's a hard deadline on someone else's budget of 4 weeks, and you can of course decline to ship it, but then you'll need a new job. (and I know, you'll say "Gladly, I take pride in my engineering!", but again, you're probably going to end up maintaining a project that only survived by doing exactly what you quit over)
tl;dr it's Yin and Yang: you can't have one without the other, and you need to have a bit of the other side in you whenever you're working in the capacity of either to be a good technical leader.
You must be “that person” who joins a team, creates IMPACT!!!, reaps the review-time award, and fucks off to some other new team to do it all again before any of the difficult maintenance issues arise. I've spent far too much time cleaning up after people like that to ever tolerate it again.
"Build one to throw away" comes to mind.
You'll figure out what you should have built after it's been used in prod for a while. Possibly years.
See I thought how nuanced my argument was towards both sides, and calling out worst cases like:
> Not that a noob developer great at selling has never landed 0 to 1 work, crapped out a half working mess and left with a newly padded resume...
Would be enough to smooth over the minor complex that some career maintainers pick up: "I'm doing the cleanup to make their crap piles work and they're the ones getting treated like they make the industry go round?!"
But I guess for some that feeling goes really deep, and at that point you're just chomping at a chance to pattern match... so the fact my career spans from app agencies boringly maintaining top app store listings to safety critical HMI work for AVs wouldn't sway you that I've been on both sides: since I am now working on a startup! :D
There's your side and there's the other side, and no one who doesn't unilaterally deride the other must be against yours. Tough way to live to be honest.