The carrying cost almost never gets charged to the builder. Team pays it later in surface area, failure modes, and onboarding time. The only fix I've seen work: write down the two options you didn't take and a concrete trigger for revisiting ("if latency hits X" / "if we add a second consumer"). Suddenly "simple choice" is a legible decision with an upgrade path, not just a gut call.
Nobody gets promoted for simplicity
91–95 of 95 posts
Re: Nobody gets promoted for simplicity
#92I launched a technical feature on Amazon's retail platform that is responsible for 9 figures worth of revenue. When I launched it, it had no infrastructure. It was a collection of small changes across every core platform (Detail Page, Cart, Checkout, etc). At first people were like "Well, you didn't do much" but when they saw the value things changed drastically. It's a bit of marketing you have to do to help bring p…
How do you ascribe a revenue number like that based on one collection of changes in a huge system? Presumably there were a bunch of other features being released around the same time as it. Was there a lot of A/B testing around it?
Amazon uses a complicated process called "attributed OPS". Meaning you may not be directly responsible for but you contributed in some way.
Re: Nobody gets promoted for simplicity
#93Earlier quoted context omitted.
How do you ascribe a revenue number like that based on one collection of changes in a huge system? Presumably there were a bunch of other features being released around the same time as it. Was there a lot of A/B testing around it?
Doesn’t matter, @ChadMoran is already on the fast track whilst you are on a pip.
Hah, well I've done something right. They've let me stay here almost 15 years.
Re: Nobody gets promoted for simplicity
#94on code duplication… I prefer the Ian Fleming approach:
- once is happenstance
- twice is coincidence
- three times is a patternRe: Nobody gets promoted for simplicity
#95I think there are several reasons for this. Firstly, simple design places higher demands on developers than complex design. You need sufficient experience and a deep understanding of the business to create a design that is just right. Otherwise, after several iterations, your code is likely to become bloated—for example, a single file exceeding 2,000 lines or a function stretching over 500 lines. Secondly, I strongly…
> You need sufficient experience and a deep understanding of the business to create a design that is just right. Otherwise, after several iterations, your code is likely to become bloated—for example, a single file exceeding 2,000 lines or a function stretching over 500 lines.
You don't need some fancy overarching design to avoid that. Just don't do it - break up functions as you're writing them, following standard bottom-up design practices. That doesn't require "deep understanding of the business". It doesn't even require experience, just a minimal amount of education, following advice such as "functions should do one thing" and the single responsibility principle. A couple of random blog posts about this:
https://medium.com/codex/should-functions-be-small-e76b45aa9...
https://blogs.oregonstate.edu/devindaniels/2025/01/16/functi...