Nearly all of the teams I've joined had problems they didn't know how to solve and often had no previously established solution. My last gig involved exploring some niche research problems in LLM space and leveraging the results to get our first round of funding closed, this involved learning new code bases, understanding the research papers, and communicating the findings publicly in an engaging way (all to typical startup style deadlines).

I agree with your remarks around "greenfield" if it just involves setting up a CRUD webapp, but there is a wide space of genuinely tricky problems to solve out there. I recall a maintainer style coworker of mine, who describe himself similar to what you are describing, telling me he was terrified of the type of work I had to do because when you started you didn't even know if there was a solution.

I have equal respect for people such as myself and for people that you describe, but I wouldn't say it is more challenging, just a different kind of challenge. And I do find the claim "you don't learn the actually valuable lessons" to be wildly against my experience. I would say most of my deep mathematical knowledge comes from having to really learn it to solve these problems, and more often than not I've had to pick up on an adjacent, but entirely different field to get things done.

"when you started you didn't even know if there was a solution."

Regardless what the problem is - as long as I know _nobody knows if there is a solution_ it's an instant sugar rush.

You are free to bang your head against a stone wall for months trying to crack the damn thing.

OFC you need to deliver in the end. And this requires then ruthless "worse is better" mentality - ship something - anything. Preferably a the smallest package that can act as mvp that you know you can extend _if this is the thing_ what people want.

Because that's the other side of the coin - if the solution is not known - people are also not aware if the solution has true value or if it is a guess.

So in any case you have to rush to the mvp.

Such joy!

Of course the mvp must land, and must be extensible.

But these type of MVP:s are not a slam dunk.

The combined requirement of a) must ship within limited time b) nobody knows what _does_ require a certain mindset.

I've found new hires to be more successful when they join, get some easy wins, and then find their own problems to solve. But maybe it's just an artifact of working at large companies where most of the day-to-day stuff is figured out.

Definetly it's a trap. If you are a purist it's nigh impossible. But if you ruthlessly 80/20 it most stakeholders will be pleasantly surprised.

I have no clue why I end up in these situations but I sure do like them.

I do realize this would sound more of a perpetual "not invented here syndrome" but technical implementation of modeling aspects for 3D and computational geometry is such a scarce talent you actually get to do novel stuff for your business.

The last time this happened I designed & implemented the core modeling architecture and led the implementation effort for our new map feature[0]

[0] See section "Stunning new building facades add practical value" in https://www.mapbox.com/blog/detailed-architecture-and-new-de...

(d) although the initial statement seems credible, the problem is actually ill defined and under specified and therefore not solvable as originally stated.

Example: our start-up plans to "fix health care"

It's kind of like when the FAA does crash investigation -- a stunning amount of engineering and process insights have been generated by such work to the benefit of all of us.

“Technologist flavor of NTSB investigator.”

One of the guys had a very strong opinion that the ideal architecture was something as abstracted and object oriented as possible with single function classes, etc. I let him run with that. The other guy got frustrated with his sub-team's inability to write code to spec in a language they'd never used before and where they were trying to build some new features they didn't clearly understand. He developed a strong feeling that TDD was the most efficient path forward: he owns the PRD and design, so he just created test stubs and told the remote team to "just write code that passes the test" even if they didn't understand the function of the block.

So, after a few months where did we end up:

1. The "abstract everything" architect's team had an extremely fragile and impossible to maintain codebase because it was impossible for any outsider to tell what was going on.

2. The "just pass the damn tests" guy had a team that had quickly ramped on a new language and they had a codebase that was incomplete (because they were building it like a Lego project) but that everyone could understand because the code blocks generally stood on their own.

What was the next step: to shut down the guy who abstracted everything and force him to drive a quick & dirty rewrite that would be more maintainable, and to also start a major refactoring of the "Lego" team's code because it was so fragmented that it also was fragile and unsuited for production.

I saw this as a terrific learning experience for all involved and I was able to get away with it because the stakes were pretty low and we had time to experiment (part of the ultimate objective was upskilling the team), but the more important lessons were these:

1. Docs matter. Take the time to write clear & detailed specs first because you'll be forced to think of edge cases and functionality that you didn't originally, and it provides a basis for system design, too.

2. Architecture & design matter. Adhering too close to any single paradigm is probably a mistake, but it takes experience on the team to understand where the compromises are and make the best decision for that system.

That second point will not stop being true with the advent of agentic assisted software development. Like others have said, my expectation in the job market is that pay will continue to be depressed for junior hires as employers reset expectations and generally just want folks who can instruct fleets of agents to do the actual coding. Senior staff will become increasingly critical and their jobs will be painful and difficult, because it'll be assumed they can (and will be willing to) do design & code reviews of artifacts originated by agents.

What I am going to be most interested in is what happens in the SRE/Sysadmin world over the next few years as more AI-generated code hits prod in organizations that don't have adequate review & oversight functions.

You kindof answered the question yourself. Humans write the tests and then go tell the AI to write the solution which passes the test.

Takeoff systems aren't analogous to prototype development. I don't know you'd build a prototype plane that's feasible to take to market, without having deep knowledge about how planes are built.

Early design decisions matter. And you don't get to that realisation without dealing with legacy systems where some upstart made terrible decisions that you're now responsible for.

Trust me, you get plenty of experience in this as a founding engineer in a startup.

Many of these comments make me wonder how many people here have actually worked at an early stage startup in a lead role. You learn a lot about what's maintainable and scalable, what breaks and what doesn't, in the process rapidly iterating on a product to find your market.

(For readers, I don't think there's anything wrong with that but it just means that certain perspectives are overrepresented here that may not be more reflective of the broader industry.)

The idea that this is means "you don’t learn the actually valuable lessons" is completely baffling to me.

Most people I've know with founding engineer experience or similar leave not because it's not challenging, but because it's exhausting.

Increasingly I've realized that the HN community and I are not even speaking the same language.

Even in areas where startups aren't literally creating new product categories like the foundational model providers, the edge of a startup over a more established business is the speed at which they can provide value. What's the point of buying CoolCo when you can go with L&M Inc. that has thousands of headcount working on your feature. The value prop of CoolCo is that CoolCo can roll out a feature in the time it takes L&M to make a detailed specification and a quarterly planning doc breaking down the roadmap and the order of feature implementation.

Now be part of the team of folks that keeps that application running for 10, 20, 30 years. Now be part of the transition team to the new app with the old data. Those tasks will also teach you a lot about system stability, longevity, and portability... lessons that can only be learned with more time than a startup has.

The technical challenges are _very_ different between these environments. In a small company you have to deal with technical breakages all the time, but you don't really have systems-level problems.

Then customers and market changed so you also most likely have different customers.

I had to undo a lot of over-engineering to fix performance issues that was implemented in good faith by people who ultimately left the company and they thought they did a good job future proofing our product.

I am with company from start and now it is 11 years. I knew why they built it like it was so I was able confidently what to fix. But it still took almost a year to undo stuff that was making our current customers miserable.

Obviously very few, because these roles are impossible to get into. What else did you expect?

The original punchline ("you don’t learn the actually valuable lessons.") was just a bit too sharp, so you even edited in a psuedo-clarification which actually just repeats that punchline but in a softer way, masterful!

Almost invariably after submitting, I see how I could clarify and/or expand on my thoughts, so I often do end up editing.

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.

Staff or principals that have a tenure of majority greenfield development are extremely dangerous to companies IMO. Especially if they get hired in a nontraditional tech company, like utilities, banking, or insurance.

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.

When working at larger orgs on legacy projects (which I have also done) you think "what sort of idiot did this?"

Then when you're the one tasked with getting a project shipped in two weeks that most reasonable engineers would argue needs two months, you start have to make strategic decisions at 2am about what maintainability issues will block the growth of the product on the way to funding and what ones can be fixed before 5pm by someone that will think you're an idiot in 3 years.

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'll figure out what you should have built after it's been used in prod for a while. Possibly years.

> 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.

How times have changed

Maybe you're just a really really good engineer and product thinking hybrid!

When you are going from “1” to stable, there is some breathing room because you have a 1 that works, mostly. Sort of. Dealing with it may be a slow slog of sordid substitutions, but the pressure is different.

Going from 0 to 1 may involve working 80+ hour weeks with little sleep and enormous stress. It may mean meeting deadlines that make or break the product in a mad rush to fulfill a contract that saves or dooms the company. It may mean taking minutes to decide designs when days or months of consideration would have been more appropriate. And it may mean getting a lot of things wrong, but hopefully not so wrong that a version 2 is impossible.

As a final note: often v1 has substantial problems, that’s true. But sometimes it’s actually not that bad, and v2 fails because it was trying to shove the tech de jure (k8s cough cough) where it wasn’t needed so someone could get that shiny architect promotion.

You learn a ton of valuable lessons going from 0 to v1. And a ton of value is created. I guess I'm unclear how you're defining "actually valuable" here.

This is evident in my personal experience by the fact that I am often the one that sees scaling and maintenance issues long before they happen. But of course parent would claim this is impossible.

Edit: a legacy vibe coder

If v1 is successful and attracts a lot of users, it will have to have features added and maintained.

Doing that in ways that does not produce "legacy code" that will have to be thrown away and rewritten in a few years is a very different skill than getting v1 up and running, and can easily be what decides if you have a successful business or not.

Maintaining and expanding is optimizing for throughput or reducing headroom so you can pack more compute.

Developing a greenfield solution requires innovation beyond a simple scaling issue. Often times, once a project like this is done, it lives in maintenance mode for the rest of its life and my skills would be better applied elsewhere.

Don’t get it twisted, I’ve scaled 0-1 to 10M and maintaining and expanding is a different skill set than innovating and invention.

Greenfield is easy because nothing matters yet.

No legacy data. No backwards compatibility. No users depending on uptime. If the architecture is wrong you just rewrite it, rename a few services, and move on.

Maintaining and expanding a real system means every change has consequences. You’re migrating live data, preserving behavior people rely on, and evolving the architecture while the plane is already in the air.

0→1 lets you be bold because you can break things. 1→10M is harder because you can’t.

(I'm just kidding, your dismissal just needed a dismissal to make things balanced again)

But yes, as everything in life, YMMV and all jobs are a double edged sword. Some greenfield is shit because shitty decisions were made. Some enterprise is shit because some shitty decisions were made. In either case, whether it’s a new project or fixing an old one, take your time and not make shitty decisions.

(Spider-Man Point Meme)

(I don’t make products, I create legacies, in C++)