[FinnLobsien]

I think this dynamic is not specific to SWE and as old as time. As organizations grow, so does the aspect of work that's more "seeing and being seen", and rightfully so.

There's definitely a ton of cruft that accumulates, and a lot of "work" being done that accomplishes little, just to satisfy a corporate bureaucracy.

But there is a reality where "good performance" is not just about the work you do, but also about your ability to get things done practically, e.g. not just your ability to write a specific microservice, but to make a compelling case for that architecture over another, and to get it reviewed and merged.

That's not to excuse wasting everyone's time on sycophantic vanity projects that don't help the business.

But I do think there's a tendency (especially on HN and Developer Twitter) to only respect complicated engineering work (e.g. optimizing Kubernetes deployments). To be fair, I'd love to almost never deal with company politics and performative work and am lucky to be at a company where effectively zero of that exists.

But as orgs grow, so does the share of work that's more political.

[osigurdson]

It doesn't help shareholders or customers in any way however so we should not celebrate it or even simply accept that this is "the way things are". It is an error to be corrected.

[FinnLobsien]

Yes, agreed. But it's not a binary. It's not like you can either wrestle with hard engineering problems until an eventual breakthrough or exclusively pretend to be working.

Sure, on one extreme is the purely value-extractive person whose only work product is calling recurring meetings to talk about how great things are going (while having contributed little). In that case, it's an error to be corrected.

But there are different types of useful work. Let's use engineering as an example.

You could build a set of new filter options on in-product analytics that customers have been asking for. Assuming this doesn't require net-new data sources or whatnot, this is usually not a complex engineering challenge, but will be loved by customers.

Then you have types who refactor an obscure caching function to reduce its memory use 15% when performance wasn't an issue, but it was a fun engineering puzzle that made the code more elegant.

Clearly both create value, but one will be more useful to customers, although it's not as fun to solve.

My point isn't that we should treat corporate bureaucracy, performative work, and freeloading as "the way things are" (they're toxic to any work culture). I'm saying that "deeper engineering challenge" doesn't equal "more important work".

Also, I don't necessarily like this! Deep problem-solving and focused work on tricky challenges are the most fulfilling things to me and to most people I know. But this is the dynamic we're in.

(and yes you can argue that having the most efficient code possible prevents future performance issues and whatnot and is thus long-term more valuable than analytics options, but at least in the startup world, limited resources mean you tend to solve things when they become problems, not because they could one day become problems)