Naturally, people were incentivized to find complex problems so they could solve them. Not only that, I think a lot of tech stacks at other companies evolved by copying this company's ideas, so even smaller companies with even less need for complex solutions ended up having them as well.
(add smiley as appropriate)
- Using Kubernetes to host an application when Docker Compose would do (specialist application with <10 concurrent users).
- Using DynamoDB to store a few kB of temporary data in a processing pipeline, despite having several existing PostgreSQL instances already and no DynamoDB ones.
And left Mongo on the default settings for the time (speed of return over reliability of saving data), so they ended up with a reporting replica which was MySQL.
Don't think I've seen anything before or since which was architected so exactly backwards.
- "Using Kubernetes to host an application when NodeJS would do..."
I am not very knowledgeable about Kubernetes or Docker, but often times NodeJS+PM2 worked just fine for me for a small user base.
We swapped the learned model for a perfect a oracle and realized the actual problem was elsewhere in the system and was easily fixed. None of those model enhancements were needed.
While those are interesting problems they have nothing to do with their current perception challenges (that have to be solved for a successful deployment), steal resources from the team and make life harder for a few remaining people actually working to solve current challenges, as they now need to switch to a more complex messaging and rewrite some of their existing utilities.
I worked at a place where they finally ditched their Hadoop project after a couple of years and who knows how much money. Only to implement a big Kubernetes cluster instead, where they four years later have burned through three different commercial Kubernetes distributions.
Kubernetes, (micro-)services, queues, nosql, lambda and other aws service are examples that I've seen in the wild. These can absolutely be valuable and cost-effective, if the problem needs that complexity.
I love engineers that focus on the user, problem and business. They are soo valuable, especially for startups and smaller companies. Engineers that love solving complex problems without thinking much about the user are still awesome, if they can operate in an organisation where that critical thinking is done by others (product people or other engineers)
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.
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...
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...?
The whole system seems destined to be replaced by something more useful.
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.
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.
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).
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.
This is such a huge factor in how software is built in today's world.
I wonder what % of developers simply espouse that mantra to downplay their technical shortcomings to the team.
I think you are completely wrong. Wouldn't the easy problems have been solved as they are by definition, easy?
If there is economic incentive to solve a problem, and it's easy problem to solve then everyone can do it. That is not true of complex problems.
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.
So...a complex problem then?
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.
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.
Software isn't an art project; it's a practical tool to solve practical problems.
Some of my more impactful changes haven't been all that complex; it was just a matter of knowing where and when to spend my time, based on working with our customer team, sales team, and directly talking to some customers.
One of my more praised changes was adding a link to our support backend that saved our customer team minutes of manual work every time. This was literally just adding a permalink: 3 minutes of work. Simple and low-complexity? Yes. But also impactful and moved the needle, and no one else had done it in the previous years.
Yet me and my colleagues have seen code that resembles abstract art far too often - it's interesting to look at, but mind-bogglingly complex. Getting rid of that is a delicate balance act, as you risk stepping on the shoes of the people who wrote the code.
I picture my colleagues or young engineers 20 years from now combing through my programs, learning the problem domain, learning the tradeoffs we made at the time and why it made sense.
I used to support a ton of random apps written as domino databases, and often would make someone's day by doing small changes like that. Things like adding one new column that saved them tons of time in cross referencing data. It was super fulfilling to have someone mention that they spend literal weeks of the year doing some task and I'd be able to totally eliminate the need for that task altogether.
(Am partially sentient collection of coral, YMMV)