You’re assuming what results in a promotion is the same as what’s worth a promotion. Nepotism makes it really easy to convince someone to promote you, but it doesn’t mean someone else doing the same thing would get a promotion.

It is very difficult for management to over time not change the rules on promotion enough that it tends towards a random walk where your level is approximately proportional to your length of service. Also,in at least the places I have worked, the enormous emphasis on individual performance both detracts from looking at group performance, i.e. actual productivity, and sucks up so much time. Copying from what execs have heard about Google they have promo boards, overly defined level descriptions, endless work of writing and rewriting promo packets, tactical discussions on which VPs need to be impressed independently of the merits or scope of a change, etc. There is a clear incentive to help people in a sister org over helping your team accomplish its goals.

The whole system seems destined to be replaced by something more useful.

> Reality disagrees with your worldview. There is only one thing that's "worth a promotion" and that's convincing the person able to greenlight it that you deserve it.

It seems pretty clear to me that the person you’re replying to was talking in the sense of how things should be, not describing the way things are. Also, “worth promotion” is not their wording. You’re nitpicking the wrong thing.

If all you do as a developer is just work on tasks given to you then you aren't going to rise very high in the ranks in any tech-forward company, FAANG or not. Sure you can make a decent career out churning tickets given to you by someone else, but you'll run into a glass ceiling pretty quickly. The tasks don't just appear out of thin air.

A key part of being a senior+ engineer anywhere is the initiative and autonomy to identify problems, quantify costs and benefits, and work with management and stakeholders to come up with solutions that balance cost, complexity, schedule, and quality.

Much of my work as a staff engineer is working with engineering, product, and business leaders to collectively identify what our biggest challenges are and how we should go about attacking them from the engineering side given all our resources and constraints. And then spearhead the implementation to get projects going the right direction and overseeing more junior team members.

The actual coding is the "easy" part that comes after first defining the problems and specifying solutions and wrangling the competing needs of the business. Engineering should have a seat at that table since we're on the hook to build (and maintain) it, after all.

I slightly disagree.

There are lot of problems that are not identified as “easy” before someone tries to solve them.

Hence, “identifying” step is often required to find the low hanging fruits.

One catefory for these types of issues is “Complex root cause analysis, easy fix”

So there might be a “medium severity” issue - something that is not business-lethal - and that appears hairy enough that everybody just avoids it. Then someone spends some time digging into it and finds it’s some arbitrarily small change that fixes it.

These things happen more often than not.

The trick here is to look at the problem long and hard enough and realize a small change will fix it - instead of doing something completely tangential and complex to circumvent the problem.

These problems fall into the class of “anyone could have fixed it” but only the person who fixed it actually did the hard work of figuring out the root cause.

> Wouldn't the easy problems have been solved as they are by definition, easy?

Only in an efficient market. And real world markets often have vast inefficiencies. The reasons they're inefficient don't always generalize, either. Companies can behave in certain ways because of personalities (2024 Twitter vs 2018 Twitter), embedded institutional norms (2024 Boeing vs 2020 Boeing vs 1980 Boeing), changing conditions (any 2024 startup vs any 2019 startup's finances), or a million others that don't necessarily spell doom for trying a different approach.

One that's relevant a lot in the real world is market share. Large organizations very frequently get away without doing easy good things for long periods of time, which they can do because network effects and platform lock-in are powerful defenses against disruption. A lot of startups get founded on the idea "large incumbents are not doing this easy good thing, so let's do that and beat them". The fact that this ever works is a sign that incumbents must be leaving a _lot_ on the table, or their lock-in would never be overcome. The very existence of the startup scene is proof of the frequent inefficiency of markets in the short-to-medium-term (or at least of investors' belief in such).

Even in cases where the incentives _are_ aligned and the market _is_ efficient, the world is often in non-equilibrium states. I like to think of incentive gradients as something akin to a (very complex) differential equation, and consider what _simple_ DEs can teach us about them. Consider, say, Newton's law of cooling: dT/dt = -k(T-T_e). Some calc 101 will tell you that solutions to this equation trend (exponentially! so not even slowly!) to a constant stable equilibrium T = T_e. But if you try to use that analysis on a fresh batch of french fries, you're going to get burned, because it turns out T(0) is very relevant to predicting T(1 minute) for realistic values of k.

> Wouldn't the easy problems have been solved as they are by definition, easy?

No, not at all. “Easy” does not mean “obvious”. I once replaced a call to scp with a call to rsync in a script I didn’t originally write. The result was that an operation which used to take more than an hour and was thus run occasionally now took seconds and was executed every time. Both speed and reliability were increased with one simple and easy line change.

While the bottleneck had been recognised earlier, the original authors had learned to live with it. They weren’t aware of how it could have been improved so drastically with so little effort. That’s another thing: easy is relative.

Either way, you’re conflating easy (the opposite of difficult) with simple (the opposite of complex, which is the word used by the person you’re replying to). They are not the same thing. Easy mathematical formulas can make complex fractal shapes and complex programs can do simple things.

Yes it's a problem; that's why I've started to use the "this isn't an art project" line, because some people really do seem to treat it as such.