Comment by BoorishBears
14 hours ago
This is unironically my favorite kind of HN comment: to say something incredibly rude and/or condescending but wrap it in the right kind of thoughtful language to qualify as HN nice
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!
It's correct tho. If your entire career is nothing but greenfield development, you'll never know the result of your decisions or the impact of tech chosen.
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.
Your list is places that treat development as a cost center, but greenfield-only devs don't want to touch that work with a 10-foot pole.
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.
This is an excellent point.
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.
My intention was actually to inspire others to maybe also start preferring long-term/maintenance work, because I feel there’s a lack of enthusiasm for that.
Almost invariably after submitting, I see how I could clarify and/or expand on my thoughts, so I often do end up editing.
This seems wrong? Like if you look at a collection of open SWENG positions, most of them are maintenance roles at large companies. Greenfield software doesn't have the revenue needed to justify much headcount.
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!
I wasn’t talking about segregating roles, but about personal preference. People do tend to prefer building new stuff over maintaining projects long-term, and I’d like the scale to tip a bit on that. Linus is indeed a good counterexample: He didn’t leave Linux after 1.0 to build the next new thing. But the latter is what developers in practice often prefer doing.
1 reply →
> Almost invariably after submitting, I see how I could clarify and/or expand on my thoughts, so I often do end up editing.
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.
Ahh that finally explains the [delayed] posts. For ages I've wondered what that is about and assumed it's some automated rate limiting.
Business bros will not pay high salaries to maintain software. Software maintenance will always end in India with developers making $20/hr. Or less.
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.
The soft sensitive people today have no idea how hard a condesending asshole has to work to live up to his own standards. When they do, one should still find something to troll them with. If you cant find it you complaint about the excessive border radius creating a child friendly fisherprice kind of environment. If that is the worse you can find they should agree and confess they have a fear of sharp edges.
How times have changed
Passive aggressiveness isn't the opposite of kindness, and worse than directness, but you'll get away with it here because this is just reddit but more pretentious and all the same biases are intact, just more walls of text instead of getting to the point.
And yet it is correct. The most valuable engineers today are those who have maintained and expanded the 0..v1 crap from others, and are now driven and ambitious enough to go build the next generation of 0..v1. Armed with that experience, the crap is minimal and value maximized.
Oof ima be the one to say it depends. This is personality based and the truth is a successful product has both. Even late on u want that person willing to break convention to find a new way of doing something. Early u need some seasoning in there too.
They're 100% correct, though.
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.
2 replies →