5 ms·
Sure they do. You just need to spell it out in business terms, not tech terms: "Reduced incidents by 80%", "Decreased costs by 40%", "Increased performance by
by codingdave 7mo ago
Sure they do. You just need to spell it out in business terms, not tech terms:
"Reduced incidents by 80%", "Decreased costs by 40%", "Increased performance by 33% while decreasing server footprint by 25%"
Simplicity for its own sake is not valued. The results of simplicity are highly valued.
- vjvjvjvjghv 7mo agoAnd mostly these numbers are made up BS. But management will eat them up.
- reactordev 7mo agoThis used to be true. Companies love efficiency. How does this stack up with modern AI? Seems those metrics would go in the opposite directions.
- candiddevmike 7mo agoThe "time to market" folks finally have everything they could hope for, let's see all of that business value they claim is being missed due to pesky things like security, quality, and scalability checks.
- nautilus12 7mo agoYou are citing negative metrics. The reality is that companies only care about positive metrics: increase marginal revenue by 30% That's regardless of the lip service they pay to cost cutting or risk reduction. It will only get worse, in the AI economy it's all about growth.
- deleted 7mo ago[deleted]
- wccrawford 7mo agoAbsolutely. And if you asked them if they're rather have it sooner, or keep it simpler, they'd pick "sooner" every time.
- withinboredom 7mo agoI once used the analogy of the PM coming to the shop with a car that had a barely running engine and broken windows, and he's only letting me fix the windows. His response: "I can sell a good looking car and then charge them for a better running engine"... https://www.youtube.com/watch?v=T4Upf_B9RLQ https://www.youtube.com/watch?v=T4Upf_B9RLQ hits a little too close to home.
- steveBK123 7mo ago> "Reduced incidents by 80%", "Decreased costs by 40%", "Increased performance by 33% while decreasing server footprint by 25%" My experience is no one really gets promoted/rewarded for these types of things or at least not beyond an initial one-off pat on the back. All anyone cares about is feature release velocity. If it's even possible to reduce incidents by 80% then either your org had a very high tolerance for basically daily issues which you've now reduced to weekly, or they were already infrequent enough that 80% less takes you from 4/year to 1/year.. which is imperceptible to management and users.
- ambicapter 7mo agoYou can reduce a single type of incident by 80%. The overall incident rate for this particular type wasn't high enough to kill your company, but it's still a big number on your promotion packet.
- tripledry 7mo ago> All anyone cares about is feature release velocity. And at the same time it's impossible to convince tech illiterate people that reducing complexity likely increases velocity. Seemingly we only get budget to add, never to remove. Also for silver bullets, if Big Tech promises a [thing] you can pay for that magically resolves all your issues, management seems enchanted and throws money at it.
- deleted 7mo ago[deleted]
- jamiemallers 7mo ago[dead]
- praptak 7mo agoYou can't measure the impact of not creating a steaming pile of complexity.
- theptip 7mo agoThe impact is that you get to go solve another problem. This absolutely does show up in a good performance review.
- nyeah 7mo agoReally you can. You look at the engineers who create steaming piles, and you look at the ones who don't. Over a year or two, the difference is easy to spot. For people who care to spot it. If there's no competent front-line technical management who can successfully make this simple comparison, then, sure, in that case the team may be fucked.
- bagacrap 7mo agoI think this is often true and it's the limiting factor that prevents complexity from spiraling out of control. But there's also a certain type of engineer who generates Rube Goldberg code that actually works, not robustly, but well enough. A mad genius high on intelligence and low on wisdom, let's say. This is who can spin complexity into self reward.
- praptak 7mo agoYes, I should have added "...this way" because I meant that to address GP's claim of the metric-based numerical measurement. In general, I agree that you can and should judge (not necessarily measure) thing like simplicity and good design. The problem is that business does want the "increased this by 80%, decreased that by 27%" stuff and simplicity does not yield itself to this approach.
- deleted 7mo ago[deleted]
- cloverich 7mo ago
- esprehn 7mo agoThose verbs (reduced, decreased, increased) all assume the situation was "bad" already. Avoiding that in the initial design is what's poorly rewarded. Building a system that's fast on day one will not usually be rewarded as well as building a slow system and making it 80% faster.
- bagacrap 7mo agoYes, and ironically there are promotion ladders that explicitly call out "staff engineers identify problems before they become an issue". But we all know that in reality no manager-leader is ever going to fix problems eagerly, if they even agree with someone's prediction that that thing is really going to become a problem.
- Oras 7mo agoNever seen these metrics in real life, especially in engineering.
- erelong 7mo ago"Code footprint is 80% more efficient / less" (when there is a simpler design over more complex "big ball of mud abomination" in contrast)
- causal 7mo agoThanks for the sane take. This article is engagement-porn for every engineer who ever looked at a system they didn't understand and declared they could do it much simpler. It's not because people love to promote complexity-makers, soothing as that thought might be.
- 1024core 7mo agoExcept when one of the criteria for promos is "demonstrates complexity". Then you results do matter, but you don't have the "complexity" box checked.
- hrmtst93837 7mo ago[flagged]