Hacker News Reader

Maybe instead of promoting, which is a stand in for $ and peer respect, you give those things, and/or provide a track which values being a domain expert+maintenance e.g. professor emeritus.

Building half working shiny things is bad for the company, and erodes user trust.

You wouldn't promote them. But if they picked up a new system and started maintaining that one too, then they could get a promotion for expanding their scope and for getting more efficient at maintaining the old system.

Or, if they are both adding new features and maintaining them, then that could merit a promotion too. They are still doing innovative work, and they are maintaining it and fixing it.

>You're asking for title inflation

You're asking for feature bloat. If the only way of winning is getting new stuff done, new stuff will be done regardless of the benefit or cost to the company.

That does sound like Google alright, though.

Yes, it is in fact the case that getting new stuff done is the only way to benefit the company. But new stuff != feature bloat. There's lots of new stuff that can be totally invisible to end users, and is deeply valuable.

Treading water should not get you promoted. That doesn't make sense.

>it is in fact the case that getting new stuff done is the only way to benefit the company

I spent a few weeks just refactoring 6k lines of code into +- 300 lines on my current job.

If my company was run by you, the best course for me woould have been leaving that mess around. Which would have led to either the same refactoring under far more stressful time constraints, or even more shit code by applying a band-aid into the old code (this code makes us some serious money, and an unexpected third party change would have broken it in such a way that would be seriously hard to fix with the old code).

Also, there are loads of features that were far easier to implement after the refactoring.

Maintenance job isn't coasting around. It has a multiplicative effect on anyone who works in the system. It needs to be done, if you want the org to not slow down to a snail pace - and when someone leaves a mess, it isn't even neccessarily easier than pumping new features since you have to figure out all observable behaviours from messy stuff.

If there's no incentive to getting your hands dirty, no one will want to get their hands dirty. People will fight to not do neccessary jobs if the only way of advancing their career is avoiding those jobs.

> Also, there are loads of features that were far easier to implement after the refactoring.

Congratulations, you have demonstrated the value and made it easier to do something. As someone who has gotten promoted 2 times (and soon to be 3) primarily off of tech debt reduction and infrastructural improvements that don't themselves do anything, but drive future productivity, of course I think this is valuable. This kind of thing is literally the only work I do.

Now yes, there's a point beyond which only doing that work won't get you promoted, but that point is L5 where you're making 350K/year, and you can continue to do some of that work and get promoted further, you just likely have to

1. Get other people to also do that work 2. Do other work that acts at a larger scale

If you're actively adding new features to a service, you aren't doing maintenance. You're launching new things, and people get promoted by launching new things all the time. And people get promoted for making it easier to launch to features all the time.

>it is in fact the case that getting new stuff done is the only way to benefit the company

>[work that will] drive future productivity, of course I think this is valuable

These 2 aren't compatible. Seems like you've walked back on the former from this last reply.

No, they're perfectly compatible, you're just choosing to take an extreme interpretation of the first.

Like there is always groundwork that has to be done as part of the new thing, and doing that work is part of getting new stuff done. If getting new stuff done is the end goal, "getting new stuff done 5% faster" will obviously get new stuff done (and benefit the company).

If a person is locked up in one feature/one product and unwilling to learn new things for the years then I do not think that person should be promoted. You can certainly give merit increases to keep up with inflation but that's about that. Ultimately, we all responding to market value of a person. That value remains unchanged for someone not learning anything new for years after the earned experience saturates. In many professions like doctors or pilots, experience never saturates and continues to increase person's market value however in other like cashier or barista that's not the case. So this opinion is job-dependent.

But the person might have the knowledge to build on whatever the system is, without having the mandate to do so. He'd still be the best person to modify the system, but for whatever reason the business doesn't need the edits. Should you keep him happy just in case or let him find another job and take the option to upgrade with him?

> So what happens when you promote someone for maintaining the same system for years? When do you stop promoting them? There's a person on my team who is happy to maintain what he works on. He has worked on fundamentally the same project for over a decade. He's a senior level engineer, and as far as I know doesn't have aspirations beyond that, which is perfectly fine. Assuming he keeps doing that work, and no more, does he get promoted again?

I know a few of these people who have been on the same product at Google for a decade and they generally cap out at L6, which is staff engineer.

L7 engineers are typically careerist and have larger a scope, focusing on higher level cross team collaborations. Some L6s are like this but there are plenty of them that are just chilling

At some companies, this is broadly what "SRE" vs "SWE" is meant to capture. But the issue is that roles aren't very fluid, plenty of times SWE ends up transitioning to a role more resembling an SRE after building a system and reorienting towards maintaining it.

God I hope not, SRE isn't a maintenance engineering role!

Improving the reliability of a system (SRE's ultimate responsibility) is deeply technically challenging work of its own, and one can encounter deeply challenging problems.

The problem is that people think "maintenance" is a bad word. A company like Google is seeing growth from external customers, churn from their internal systems as internal best practices change, and changing threat landscapes on the internet.

"Maintenance" often is actual hard feature work. But when your org or company has a culture of thinking of maintenance as some low-level job, you get a culture like Google's.

I don't disagree. I don't think maintenance is a bad word. But I do think that there is a point beyond which "maintenance" cannot grow. If you're maintaining a system there is a breadth of experience you cannot get. Being a senior engineer at Google is not easy. But my point is that sre is still fully capable of supporting L7 and L8 ic swes, while "maintenance" isn't.