4 ms·
You can't measure the impact of not creating a steaming pile of complexity.
by praptak 8mo ago
You can't measure the impact of not creating a steaming pile of complexity.
- nyeah 8mo 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 8mo 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 8mo 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 8mo agoIt's easy to gloss over this assessment but ultimately this needs to be a key decision point for where you choose to work. No matter how well you manage complexity as an IC or a lower tier leader, if your upper tier of leaders don't value it, it won't last. Simplicity IME is not a "tail that wags the dog" concept. It's too easy to stomp out if nobody in power cares.
- quaunaut 8mo agoExcept it's not something you can really accurately assess before you start working somewhere.
- williamdclt 8mo agoMeasure no, but only engineers care about that (and I'm not even saying that they're right, engineers care a whole lot too much about hard data). You can show alternative solutions, estimate, make assumptions, even make up numbers and boom, you have "data" to show you improved things. You don't even have to lie: you can be very open that these are assumptions and made-up numbers, that it's just a story, what's important is that people come out with confidence that thanks to you, things are better by a bit/a lot/enormously.
- e-topy 8mo agoYou can. GitHub is about to hit zero nines of uptime[0]. But feedback like that is far too late to be useful. Maybe (principal or senior) engineers should be the ones to judge, and be trusted by management that their foresight is worth pushing the deadline? [0]: https://mrshu.github.io/github-statuses/ https://mrshu.github.io/github-statuses/
- strix_varius 8mo agoYou can't. You can hypothesize about the counterfactual in which you shipped a "steaming pile of complexity," but you definitionally cannot measure something that does not exist.
- jpollock 8mo agoWon't that show up in roi numbers?
- praptak 8mo agoThere is no base to compare against.
- sam_bristow 8mo agoOne of my the papers I share around a lot is "Nobody ever gets credit for fixing problems that never happened (2002)"[1]. I like it because it's not purely about software so the examples resonate better with some exec level people in other teams I work with. [1]https://ieeexplore.ieee.org/document/1167285 https://ieeexplore.ieee.org/document/1167285
- cdavid 8mo agoYes, this is the real cause, and the OP explanation is just a symptom of that.
- theptip 8mo agoThe impact is that you get to go solve another problem. This absolutely does show up in a good performance review.