No, it’s not. Identifying which problems are worth solving (regardless of their complexity), and solving those is worth promotion.
Lots of engineers have a fascination with solving complex problems purely for the sake of solving them. When you make that your criteria for promotion you end up have to do many rounds of layoffs in harder times because you’re staffed to the gills with people solving complex problems that deliver little to no actual value.
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.
This very rarely corresponds with the ability to deliver good software in medium to large enterprises and entirely with your ability to market yourself. Which is easier if you're able to show them a super complex problem you've solved, because it sounds impressive to a mba...
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.
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.
the practice among those with power or influence of favouring relatives, friends, or associates, especially by giving them jobs.
how is that related to someone finding a complicated but irrelevant problem to solve to show how competent they're to the mba thats in the position to greenlight the promotion...?
Well, an MBA that wants to promote their relative might need that "complicated but irrelevant problem" solved as a kind of "cover your ass" paper trail.
> 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.
> 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.
Similarly I sped up a python script by 3 orders of magnitude by running a linter on it; the script intended to cache a value for reuse, but neglected to actually reuse the value, resulting in an unused-variable warning in the linter.
> 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.
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.
Do engineers at FAANG choose what problems they want to solve? At places I worked, it was more of management task to choose problems to solve. Developers just worked on tasks they were given.
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 agree with you up until the cliche "code is the easy part".
People say this at the same time that they complain that people with 10 years of experience can't even solve FizzBuzz.
The amount of badly architectured, buggy code I've seen in a couple of decades working with software tells me that "code is the easy part" is an absolute lie.
Writing good code that's well tested and mostly just works, while being efficient, is such an extremely difficult task that I am not sure many developers in the world can do it. So, no, code is not the easy part, it's only the part where you can probably escape accountability (as no one will be able to tell) unless you have good devs in your team that can properly code review (which is also very rare).
I mean, code is both the hard and the easy part. I can write the code to get good code, or I can spend more effort on finding the right problems to solve and let others write shitty code.
It hurts to let people do that, but ultimately shitty code still works, while having solved the wrong problem means that all the work goes down the drain.
¿Por qué no los dos? - find the right problems to solve and write good code (or insist on good code being written) to fix them? Because bad code (unless it's throwaway code) will quickly become a problem all of itself...
Lots of engineers have a fascination with solving complex problems purely for the sake of solving them. When you make that your criteria for promotion you end up have to do many rounds of layoffs in harder times because you’re staffed to the gills with people solving complex problems that deliver little to no actual value.