In my experience separating the roles out is silly if you're an engineer yourself. We do this a lot and that leads to silly mentalities. Greenfield developer vs maintenance engineer, MVP engineer vs Big Tech dev, FOSS hacker vs FOSS maintainer. Each of those dichotomies speaks to cultural differences that we humans amplify for no reason.

In truth the profession needs both and an engineer that can do both is the most effective. The sharpest engineers I've worked with over the years can hack new, greenfield stuff and then go on to maintaining huge projects. Hell Linus Torvalds started out by creating Linux from scratch and now he's a steward of the kernel rather than an author!

One of the tricks of HN is the 'delay' setting. https://news.ycombinator.com/item?id=231024

> There's a new field in your profile called delay. It's the time delay in minutes between when you create a comment and when it becomes visible to other people. I added this so that when there are rss feeds for comments, users can, if they want, have some time to edit them before they go out in the feed. Many users edit comments after posting them, so it would be bad if the first draft always got shipped.

I've got mine set to 2. It gives me a little bit of time for the "oh no, I need to fix things" or "I didn't mean to say that" and when everyone else can see it.

AI makes it look like these developers can do the same job the Americans did building the product to begin with. Even if things fall apart in the end, it won’t stop the attempt to order of magnitude reduce the cost for maintenance.

And if your entire career is nothing maintenance and sustaining projects, you'll never know what decisions it takes to build a greenfield application that lives long enough to become a graybeard.

You'll think you do because you see all the mistakes they made, but you'll only have cynical reasons for why those mistakes get made like "they don't care, they just make a mess and move on to the next job" or "they don't bother learning the tools/craft deeply enough moving, it's all speed for them".

-

To indulge myself in the niceness a bit: I don't think you write comments like the one above if you've done both, yet having done both feels like an obvious requirement to be a well-rounded Staff/Principal.

Most maintenance work suffers because of decisions made at the 0 to 1 stage. And most greenfield work fails entirely, never maturing to the maintenance stage.

So both sides have to do something right in the face of challenges unique to their side. And having familiarity with both is extremely valuable for technical leadership.

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.