15 ms·

Nobody gets promoted for simplicity

• 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.
  • reactordev 7mo ago
    This 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 ago
      The "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 ago
    You 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 ago
    Absolutely. And if you asked them if they're rather have it sooner, or keep it simpler, they'd pick "sooner" every time.
    • withinboredom 7mo ago
      I 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 ago
      You 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 ago
    You can't measure the impact of not creating a steaming pile of complexity.
    • nyeah 7mo ago
      Really 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 ago
        I 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 ago
        Yes, 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
        It'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.
  • esprehn 7mo ago
    Those 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 ago
      Yes, 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 ago
    Never seen these metrics in real life, especially in engineering.
  • vjvjvjvjghv 7mo ago
    And mostly these numbers are made up BS. But management will eat them up.
  • 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 ago
    Thanks 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 ago
    Except 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]
• LAC-Tech 7mo ago
  I'm trying to sell simplicity to my target market, who I would call "semi-tech literate". Maybe it's stupid and I should sell whatever Forbes thinks is cool, but I just can't shake this feeling that I should be solving actual business problems.
  • mrweasel 7mo ago
    We failed a bid for a project because of simplicity. We were to migrate a service running on an on-prem Kubernetes installation and a three, or five, node Apache Cassandra cluster to Azure. The service saw maybe a few hundred transaction per day, total database size: 2 - 3GB. The systems would hold data about each transaction, until processed and then age it out over three months, making the database size fairly stable. Talking to a developer advocate for Azure we learned that CosmosDB would get a Cassandra API and we got access to the preview. The client was presented with a solution were the service would run as a single container in Azure Websites and using CosmosDB as the database backend. The whole thing could run within the free tier at that point. Massive saving, much easier to manage. We got rejected because the solution didn't feel serious and to simplistic for an organisation of their scale. On the other hand I also once replaced a BizzTalk server with 50 lines of C# and that was well received by the client, less so of my boss who now couldn't keep sending the bill for a "BizzTalk support contract" (which we honestly couldn't honour anyway).
    • LAC-Tech 7mo ago
      2-3gb... an organisation of their scale :D I sometimes feel like that's what it is. Simple solutions make some people feel unimportant.
• ekjhgkejhgk 7mo ago
  Bigger picture, when the thing you try to measure is subtle and difficult, you measure something obvious. That's what happening here.
• lccerina 7mo ago
  Dijkstra understood it 50 years ago, and again 26 years ago [1]. Nothing changes. Malpractice just propagate and there are zero incentives to build simple, small, and maintainable software. If the company you work for just push for unnecessary complexity, get out of there! Don't fold! [1]: https://www.cs.utexas.edu/~EWD/ewd13xx/EWD1305.PDF https://www.cs.utexas.edu/~EWD/ewd13xx/EWD1305.PDF
  • ivanjermakov 7mo ago
    > If the company you work for just push for unnecessary complexity, get out of there! If every company I know does this, how am I suppose to make money? There are reasons for "unnecessary" complexity. Mainly cost and time.
  • dgxyz 7mo ago
    Malpractice is exactly the word for this sort of shit.
  • sdevonoes 7mo ago
    > If the company you work for just push for unnecessary complexity, get out of there! Why? We learn all these cool patterns and techniques to address existing complexity. We get to fight TRexes… and so we get paid good money (compared to other jobs). No one is gonna pay me 120K in europe to build simple stuff that can work in a single sqlite db with a php fronted.
    • lccerina 7mo ago
      Except now we get websites that need to download 20-25MB of "latest cool framework" to show you a blurb of text because programmers before you created unnecessary complexity that needs to be maintained forever. The honest opinion no one wants to hear is that programmers do not deserve the money they are paid for because MOST of the time what it's really needed is a "single sqlite db with a php frontend".
      • sdevonoes 7mo ago
        Fair. I work on backend, and there we usually need db replication, sharding, event brokers, monitoring and alerting, autoscaling. I wish we wouldn’t need all of that, and could use a single server with sqlite… but that won’t cut it.
• moi2388 7mo ago
  This was already a post 6 hours ago which is now [dead]. What happened?
• blueboo 7mo ago
  Skill issue—in management. Good leaders perceive workhorse vs showhorse spectrum, critical toil vs needless flash (and vice versa). It’s hard. Most fail at hard things. The industry in the aggregate will fail at hard things So you get articles like this.
• hasbot 7mo ago
  I interviewed at a company that used a simple project to screen candidates. It was implementing a cash register checkout system. The task was soo simple that I couldn't figure out what they were looking for. So I implemented the simplest thing possible. I got the job partially because they were impressed by my utterly simple solution. I helped evaluate other candidates given the exact same problem and it's amazing how some people dialed up the complexity to 11. None of them passed the screening.
  • cottsak 7mo ago
    i think you can coach agents to build simple solutions in a simple way. I'm using amp rn so check back in 6 mo with me
• deleted 7mo ago
  [deleted]
• darkwater 7mo ago
  > Now, promotion time comes around. Engineer B’s work practically writes itself into a promotion packet: “Designed and implemented a scalable event-driven architecture, introduced a reusable abstraction layer adopted by multiple teams, and built a configuration framework enabling future extensibility.” That practically screams Staff+. > But for Engineer A’s work, there’s almost nothing to say. “Implemented feature X.” Three words. Her work was better. But it’s invisible because of how simple she made it look. You can’t write a compelling narrative about the thing you didn’t build. Nobody gets promoted for the complexity they avoided. Well, Engineer A's manager should help her writing a better version of her output. It's not easy, but it's their work. And if this simpler solution was actually better for the company, it should be highlighted how in terms that make sense for the business. I might be naive and too optimistic but good engineers with decent enough managers will stand out in the long run. That doesn't exclude that a few "bad" engineers can game their way up at the same time, even in functional organizations. though.
  • klabb3 7mo ago
    > And if this simpler solution was actually better for the company, it should be highlighted[…] Simpler than what? The reason this phenomenon is so pervasive in the first place is that people can’t know the alternatives. To a bystander (ie managers), a complex solution is proof of a complex problem. And a simple solution, well anyone could have done that! Right? If we want to reward simplicity we have to switch reference frame from output (the solution), to input (the problem).
    • darkwater 7mo ago
      I'm (also) an EM, I've been a pure EM in some roles in my career and I really struggle to understand these pain points that many people bring up. Isn't a manager job to know what their managees are focused on over a period of time? Shouldn't be they aware of the projects the team is working on? As EM and most probably previously engineers, shouldn't they know already why simple solutions are good?
  • fer 7mo ago
    > It's not easy, but it's their work. There's a significant asymmetry though, it's not just a bit more work. I'm a bit cynical here, but often it's easier to just overengineer and be safe than to defend a simple solution; obviously depending on the organization and its culture. When you have a complex solution and an alternative is stacked up against it, everything usually boils down to a few tradeoffs. The simple solution is generally the one with the most tradeoffs to explain: why no HA, why no queuing, why no horizontally scalable, why no persistence, why no redundancy, why no retry, etc. Obviously not all of them will apply, but also obviously the optics of the extensive questioning will hinder any promotion even if you successfully justify everything.
• ineedasername 7mo ago
  You need the tension between both, or else either approach at most levels of systems, whether its an app or a corporation, tends to lead to toxic failures modes. It could be something overbuilt, large organization structures. Brittle solutions that are highly performant until they break. Or products/offerings that don't grow for similar reasons, simpler-is-better, don't compete with yourself. Or those that grow the wrong way-- too many, much to manage, frailty through complexity, sku confusion. Alternatively, things that are allowed to grow with some leeway, some caution, and then pruned back. There's failure modes in any of these but the one I see most often is overreaching concern for any single one.
• mikeocool 7mo ago
  I’ve definitely consistently seen people who can take a wildly complex bug-ridden Rube Goldberg machine that was impossible to change and break it down into a simple understandable system get promoted. These people are generally the best engineers in the org and a get reputation for that.
  • cottsak 7mo ago
    where do you work!? lol
• domk 7mo ago
  One of our interviews is a technical design question that asks the candidate to design a web-based system for public libraries. It explicitly tests for how simple they can keep it, starting at "a single small town library" scale and then changing the requirements to "every library in the country". The top ever performance was someone who answered that by estimating that even at max theoretical scale, all you need a medium sized server and Postgres.
  • milkshakeyeah 7mo ago
    Wait, so you are telling me that not every company builds Spotify on design system interview? Impossible
    • uberduper 7mo ago
      AWS loop a long while back wanted me to design a playlist system so my dumbass brain snapped to m3u files or w/e people were using back then and designed a system to host/share playlist files. The teenager (ok probably in their 20s) interviewing me seemed more and more confused as we went on but he never tried to redirect me to what he really intended.
  • vrosas 7mo ago
    I have 100% failed interviews by giving that answer when their definition of scale was 10,000!!!! req/sec. Like sorry dude in 2026 that's not much different than 10 req/sec and my original design would work just fine... But that's what happens when your interviewer is a "senior" 24 year old just reading off the prompt.
    • silveraxe93 7mo ago
      10,000!!!! is such a huge number I don't think we could even represent with a computer. Being obviously pedantic here, I agree with what you meant.
    • IshKebab 7mo ago
      Well, it depends what those requests are doing surely? I always thought it was weird to treat "request" as a unit of measurement. Are you requesting a static help page, or a GraphQL search query?
• Niko901ch 7mo ago
  AI coding tools are making this problem worse in a subtle way. When an agent can generate a "scalable event-driven architecture" in 5 minutes, the build cost of complexity drops to near zero. But the maintenance cost doesn't. So now you get Engineer B's output even faster, with even more impressive-sounding abstractions, and the promotion packet writes itself in minutes too. Meanwhile the actual cost - debugging, onboarding, incident response at 3am - stays exactly the same or gets worse, because now nobody fully understands what was generated. The real test for simplicity has always been: can the next person who touches this code understand it without asking you? AI-generated complexity fails that test spectacularly.
  • dude250711 7mo ago
    It's a bad time to be an altruistic perfectionist, tell you what. Avoid hands-on tech/team lead positions like hell.
    • skydhash 7mo ago
      It’s not even about perfectionism. Code’s value is about processing data. Bad code do it wrongly and if you have strange code on top of that, you cannot correct the course. Happy path are usually the low hanging fruits. What makes developing software hard is thinking about all the failure and edge cases.
    • cottsak 7mo ago
      that second line is so underrated
    • whattheheckheck 7mo ago
      Thats the kind of thinking that got us into this mess... scab
  • brightball 7mo ago
    The flip side of this is that languages who have a major selling point of maintainability just had their value increase dramatically.
  • 7mo ago
• gmuslera 7mo ago
  Not just simplicity, we are wired towards additive solutions, not substractive ones, on a problem we try to add more elements instead of taking out existing ones. And are those additions what counts, what are seen, not the invisible, missing ones.
  • tumetab1 7mo ago
    True. By chance, recently in an architecture discussion document I added that one of aspects to consider is how easy is to remove (the whole thing) if it's not wanted anymore. It was an obvious case because it was an AI capability, which can be become deprecated/useless/too-risky very fast.
• wellpast 7mo ago
  Being able to solve problems with true simplicity is a master’s skill. The skill to recognize simplicity and its value is a skill as well. You can try to explain this OP’s concept to a stakeholder in a 1000 different sensible ways and you’ll get blinking deer-in-headlight eyes back at you. This skill is hard-earned and, so, rare. Therefore, many hierarchies are built on sufficient mediocrity top to bottom. Which works because bottom line doesn’t often matter in software dev anyway. And even when it does matter it’s multiplicatively rare to have a hierarchy or even the market that it tries to serve who can build, comprehend, handle high power::complexity systems, products, tools.
  • cottsak 7mo ago
    that's why talking about the merits of simplicity is more of an art than something of utility to other engineers https://hammerproject.com/2023/07/28/complexity.html https://hammerproject.com/2023/07/28/complexity.html it just isn't very appetising
• bell-cot 7mo ago
  If I was an engineering manager in an org which actually valued getting sh*t done - vs. bragging rights, head counts, and PHB politics - then I'd notice within a month that Engineer A (who the article has shipping in a couple days) got far more done then Engineer B (who needed 3 weeks). And long before performance review time, I'd have mentioned further up that A was looking like a 5X engineer - best if we keep her happy.
• mastermedo 7mo ago
  Related: https://news.ycombinator.com/item?id=47242765 https://news.ycombinator.com/item?id=47242765
  • e40 7mo ago
    That is dead, but I vouched for it.
• strickjb9 7mo ago
  This reminds me of this post from 2013 -- https://mikehadlow.blogspot.com/2013/12/are-your-programmers-working-hard-or.html https://mikehadlow.blogspot.com/2013/12/are-your-programmers... Essentially, there are two parallel teams, one is seen constantly huddling together, working late, fixing their (broken) service. The other team is quiet, leaves on time, their service never has serious issues. Which do you think looks better from the outside?
• dalmo3 7mo ago
  Long rant, but the author never defines what he means by "simple". He heavily hints at smaller changeset == simpler. Too often the smallest changeset is, yes, simple, but totally unaware of the surrounding context, breaks expectations and conventions, causes race conditions, etc. The good bit in tfa is near the end: > when someone asks “shouldn’t we future-proof this?”, don’t just cave and go add layers. Try: “Here’s what it would take to add that later if we need it, and here’s what it costs us to add it now. I think we wait.” You’re not pushing back, but showing you’ve done your homework. You considered the complexity and chose not to take it on.
  • cottsak 7mo ago
    this might help https://hammerproject.com/2023/07/28/complexity.html https://hammerproject.com/2023/07/28/complexity.html
  • skeeter2020 7mo ago
    I think Rich Hickey's talk about simple is great for defining these terms (literally). He describes how the roots of "simplex" mean single braid, which compares to the twisting & coupling with complexity; an apt visual for software development. He also differentiates simple/complex from easy/hard, which is important. https://www.youtube.com/watch?v=SxdOUGdseq4 https://www.youtube.com/watch?v=SxdOUGdseq4
  • vrosas 7mo ago
    > shouldn’t we future-proof this? The answer to this is almost always "NO" in my experience, because no one ever actually has good suggestions when it comes up. It's never "should we choose a scalable compute/database platform?" It's always "should we build a complex abstraction layer in case we want to use multiple blob storage systems that will only contain the lowest common denominator of features of both AND require constant maintenance AND have weird bugs and performance issues because I think I'm smarter than AWS/Google AND ALSO we have no plans to actually DO that?" /I'm not bitter...
  • tetha 7mo ago
    I agree. I generally don't ask "Do we need to future proof this?", I rather ask: "Do we paint ourself into a corner?" For example, if you implement a job framework of things calling a REST API to do stuff async, a sufficient first implementation is a simple monolith doing the stuff and some retries or periodic calls. Because, if it does not scale, we can start thinking about replacing that with something to put things into queues and scaling stuff-doers horizontally and such. But often enough, these simple things scale quite the distance. On the other hand, if you start introducing in-memory caches into a singular instance to taper around database performance... that's a huge issue. That always leads to pain. Additionally though, I"ve started to keep notes about people doing simple, efficient things without fanfare. This way, if my boss asks me what Bob did over the year, I can tell them that Bob made these problems disappear and how Bob is starting to handle this area of topics more and more. Suddenly Bob is growing responsible for this area, and if my boss asks Bob about these topics they did well in an annual review, Bob can shine. Hope they learn though.
• csmpltn 7mo ago
  People always overcomplicate this. Companies want to get the most out of their employees, for the least amount of money paid. Promotions are supposed to incentivise people to stay, rather than leave. If the company never promoted anyone, people would leave. So there needs to be a path for promoting people. But that process doesn’t have to be transparent, or consistent, or fair - in-fact it rarely is. You promote people who consistently overdeliver, on time, at or below cost, who are a pleasure to work with, who would benefit the company long term, who would be a pain to lose. A key precondition is that such people consistently get more done compared to other people with equal pay, otherwise, they don’t stand out and they are not promotion material. What counts as overdelivering will vary based on specific circumstances. It’s a subjective metric. Are you involved with a highly visible project, or are you working on some BS nobody would miss if it got axed? Are you part of a small team, or are you in a bloated, saturated org? Are you the go-to person when shit hits the fan, or are you a nobody people don’t talk to? Are you consistent, or are you vague and unpredictable? Does your work impact any relevant bottom lines, or are you just part of a cost centre? It really isn’t rocket science, for the most part.
  • arnvald 7mo ago
    It's really not that simple. Numerous times I've seen promotions going to people who were visible but didn't do the actual work. Those who share the achievements on Slack, those who talk a lot, get to meetings with directors, those who try to present the work.
    • csmpltn 7mo ago
      For the vast majority of people and cases, it really is that simple - but like I already said, "the process doesn’t have to be transparent, or consistent, or fair - in-fact it rarely is". There are exceptions to every rule, but for most people, it really does come down to some self reflection: 1. Do I consistently deliver more (in output, impact, or reliability) than peers at my pay level? 2. Is my work visible and tied to meaningful business outcomes, rather than low-impact tasks? 3. Am I known as dependable and easy to work with, especially under pressure? 4. Would the company feel a real loss-operationally or financially-if I left? 5. Have I made myself clearly more valuable to the organization than what I currently cost?
• randusername 7mo ago
  Whatever is going on with each 'f' in this font is breaking my brain. Feels like the drunk goggles equivalent of dyslexia. I don't think this phenomenon is unique to programming. My plumber was explaining how he put in a manifold and centralized whole-house off valve accessible indoors and I was like, okay, thanks? I can just turn it off at the street. Only established professionals have the status and self-confidence to show restraint. I think that explains interviews.
  • mauvehaus 7mo ago
    Your plumber is probably making a good choice. Valves that don’t get exercised regularly can be all but guaranteed to be a pain in the ass when you need them to work. We have a calendar reminder to exercise the valves in our house yearly, and the fact that they’re easy to get at helps make sure it’s a quick job, not a tedious one. Not a plumber, but have lived in enough old houses with iffy valves to have been bitten a few times.
• dzonga 7mo ago
  Charlie Munger once said >>> Show me the incentive, I will show you the outcome Problem is in big tech -- the incentives are all aligned towards complex stuff you wanna get promoted - do complex stuff that doesn't make sense. If you get promoted, then it also boosts the performance of your manager. the only way to escape this nonsense is to work at smaller companies right now you've people advocating for A.I coded solutions yet never realizing that A.I solutions result in a convoluted mess since A.I never possesses the ART of software engineering i.e knowing what to cut out
• sghaz 7mo ago
  In larger systems, what looks like “overengineering” can be deliberate risk management. In my experience, senior engineers do get promoted for simplicity but only when they can articulate the trade-offs and the future costs they are avoiding.
  • cottsak 7mo ago
    this is rare tho
• trjordan 7mo ago
  The push for simplicity can't be at the time of recognition. It has to be during the building, so that by the time the thing gets built, it's the simplest thing that met the need. Can you actually imagine a promo committee evaluating the technical choices? "Ok, this looks pretty complex. I feel like you could have just used a DB table, though? Denied." Absolutely not! That discussion happens in RFCs, in architecture reviews, in hallway meetings, and a dozen other places. If you want simplicity, you need to encourage mentorship, peer review, and meaningful participation in consensus-building. You need to reward team-first behavior and discourage lone-wolf brilliance. This is primarily a leadership job, but everybody contributes. But that's harder than complaining that everything seems complicated.
  • nyeah 7mo ago
    >Can you actually imagine a promo committee evaluating the technical choices? "Ok, this looks pretty complex. I feel like you could have just used a DB table, though? Denied." A committee with no skin in the game, who knows? But a manager who actually needs stuff done, absolutely.
• d--b 7mo ago
  Not my experience. I once hacked a spreadsheet in a week that was good enough to not embark on a multiple-months 3-devs project. In the same team, I tweaked a configuration file for distributed calculations that shaved 2 minutes of calculation on an action that the user would run thirty times a day. I got paid all right. People don't give a shit about complexity or simplicity. They care about two things: 1. Does it work 2. How soon can you ship There is a third thing that stakeholders really like: when you tell them what they should be building, or not building.
• bluGill 7mo ago
  Engineer B who can get that over complex solution working is the person you will turn to when complexity is required for the problem. They have experience in getting it to work, and such they really are worth more. The real question is how do you tell engineer A who can figure out how to make the complex problems simple from engineer C who can't handle complexity and so writes simple solutions when the complex one is needed.
  • zozbot234 7mo ago
    Not really, because even when complexity is required, the last thing you want is even more, unneeded complexity. There is no guarantee that the kind of complexity B brought to a problem is the exact same kind you're going to need somewhere else. It turns out that complexity is, shall we say, more complex than that.
• HarHarVeryFunny 7mo ago
  I forget who said it, but it seems that AI is basically an amplifier of the talents (or lack of them) of whoever is wielding the tool. In the hands of an experienced developer/designer, AI will help them achieve a good result faster. In the hands of someone inexperienced, out of their depth, AI will just help them create a mess faster, and without the skill to assess what's been generated they may not even know it.
  • winwang 7mo ago
    What about someone inexperienced but skeptical, using AI to learn + fix their own code before opening the PR?
    • HarHarVeryFunny 7mo ago
      That's an interesting question ... how should a less experienced developer use AI productively, and learn while developing? Certainly using it as a magic genie and vibe coding something you are in no position to evaluate is not the way to go, nor is that a good way for anyone to use AI if you care about the quality or specifics of the end result! There's always going to be some overlap, wanting to use a new skill/library in a production system, but maybe in general it's best to think of learning and writing/generating production code as two separate things. AI is great for learning and exploration, but you don't want to be submitting your experiments as PRs! A good rule of thumb might be can you explain any AI-generated design and code as well as if you had written it yourself? If you don't fully understand it, then you are not in a good position to own it and take responsibility for it (bugs, performance, edge case behavior, ease of debugging, flexibility for future enhancement, etc).
  • bagacrap 7mo ago
    I am the type of engineer who prefers simplicity and I have not found a way to make AI increase the simplicity of code I'm working on. If left to its own devices, Claude absolutely loves adding more member variables, wrapper functions, type conversions, rather than, say, analyzing and eliminating redundancies. So my experience is that AI is more closely aligned with the engineer type for whom the solution is always "add more code", rather than whatever its human manager would do.
• abcde666777 7mo ago
  Part of this from what I've seen is a large company problem, where developers exist underneath a thick layer of middle management. In smaller companies it's a lot easier to express the distinctions and values of simplicity to ears that might actually appreciate it (so long as you can translate it into what they value - simple example is pointing out that you produced the same result in much less time, and that you can get more done on overall feature/task level as a result).
• lxgr 7mo ago
  > In design reviews, when someone asks “shouldn’t we future-proof this?”, don’t just cave and go add layers. In fact, simplicity often is the best future-proofing. Complex designs come with maintenance costs, so simple designs are inherently more robust to reorgs, shifted priorities, and team downsizing.
• drdrek 7mo ago
  It's not just that it looks good, there is constant pressure from other Engineers that we should "Do it right" and "Plan for the future" even if the future is murky and every design choice we take for scalability is probably just constraints that will hinder us if the requirements change. as a manager its constant fighting the pressure to build "Great software" that is way above what the company needs instead building working software that addresses customer needs in a timely manner. My dude we are s startup with two servers and 20 customers, we do not need infinite scalability.
• portly 7mo ago
  Maybe I am naive but I still believe that simplicity leads to personal wins in the long run. Having simpler system designs lead to velocity and eventually you become known as the "team that can deliver".
  • Steve16384 7mo ago
    Or, the team that everyone takes for granted and/or the pointy-haired bosses assume their project must be pretty basic and anyone can do it.
    • portly 7mo ago
      But it frees up time to build more products, which could give you leverage for negotiating better pay.
• gip 7mo ago
  Assuming: simplicity === no unnecessary complexity. In my (limited) experience as an engineer and manager, leadership (e.g., a VP) didn’t like (or reward) simplicity. Simple solutions often meant smaller teams, which wasn’t something they were pushing for, especially pre-2024. I do think this is slowly evolving, and that the best leaders now focus on removing unnecessary complexity and improving velocity.
• bilsbie 7mo ago
  I had an interview question. What would you do if two different people were emailing a spreadsheet back and forth to track something? I said I’d move them to google sheets. There was about five minutes of awkwardness after that as I was interviewing for software developer. I was supposed to talk about what kind of tool I’d build. I found it kind of eye opening but I’m still not sure what the right lesson to learn was.
  • gwbas1c 7mo ago
    Probably that you didn't want the job? At least from the point of view of the interviewer, this was the point where they should give you a polite "hey, play along" nudge.
    • swiftcoder 7mo ago
      > At least from the point of view of the interviewer, this was the point where they should give you a polite "hey, play along" nudge. That may be the game, but we all know it's bullshit, and we shouldn't be playing along. If a member of my team actually proposed building a bespoke system for something that can be straightforwardly done in a spreadsheet, we'd be having some conversations about ongoing maintenance costs of software
      • gwbas1c 7mo ago
        > If a member of my team actually proposed building a bespoke system for something that can be straightforwardly done in a spreadsheet, we'd be having some conversations about ongoing maintenance costs of software All interviews are contrived / artificial situations: The point is to understand the candidate's thought processes. Furthermore, we're getting Bilsbie's (op) take on the situation, there may be context that the interviewer forgot to mention or otherwise Bilsbie didn't understand / remember. Specifically, if (the hypothetical situation) is a critical business process that they need an audit log of; or that they want to scale, this becomes an exercise in demonstrating that the candidate knows how to collect requirements and turn a manual process into a business application. The interviewer could also be trying to probe knowledge of event processing, ect, ect, and maybe came up with a bad question. We just don't know. Given that Bilsbie can't read their interviewer's mind, there's no way to know if that's what the interviewer wanted, or if the interviewer themselves was bad at interviewing candidates.
• Oras 7mo ago
  There are two other reasons: - CV-driven development. Adding {buzzword} with {in production} sounds better than saying I managed to make simple solutions faster. - Job security. Those who wish to stay longer make things complicated, unsupportable, and unmaintainable, so they become irreplaceable.
• nyeah 7mo ago
  Nyeah ... but people can get promoted for consistently shipping stuff that works, on time. And people can get sidelined for consistently taking 10x as much time to provide the same business value. That may not be the rule, and it may not always be obvious in the short term who is sidelined. But it can happen. It can even happen that the tag "very smart" gets attached to those sidelined engineers. That's not necessarily a compliment.
• anarticle 7mo ago
  Promotion Driven Development at its finest. There's no good way to fix this without better teams and less Lord of the Flies style management. Servant leadership helps here, but if your team is adversarial in nature there is no escape. A manager that needs an exciting story to get a feather in their hat will take the story every time over "+20 -8000" commit style developers. Your product will suffer accordingly. A lot of this boils down to promo system being so systematized. I've never heard of people in any other field min/max their promotions as hard along with all of the expert jargon in any other field I've worked in. Packets, peers, comp, other co comps, what your boss thinks of you, what your boss thinks of your peers (nee: competitors), and the inevitable crash out when they don't get the promotion. All part of the bigco experience! I feel like when we systematized comp into ranks Lx, Ly we gave up our leverage a little bit.
• stego-tech 7mo ago
  Spitting facts, here. I built a showback model at a prior org. Re-used shelfware for the POC, did the research on granular costs for storage, compute, real estate, electricity, HVAC maintenance, hardware amortization, the whole deal. Could tell you down to the penny how much a given estate cost on-prem. Simple. Elegant. $0 in spend to get running in production, modest spend to expand into public cloud (licensing, mainly). Went absolutely nowhere. Got RIFed. On the way out the door, I hear a whole-ass team did the same thing, using additional budget, with lower confidence results. The biggest difference of all? My model gave you the actual cost in local currency, theirs gave you an imagined score. The complexity (cost of a team, unnecessary scoring) was rewarded, not the simplicity.
• oidar 7mo ago
  Posted just yesterday: https://news.ycombinator.com/item?id=47242765 https://news.ycombinator.com/item?id=47242765
• psychoslave 7mo ago
  Any system that make rewarding path based on individual contributions as this defect. As opposed to one insuring that the overall result benefits is evenly distributed among all the engaged parties. The obvious outcome will be that the most skilled pretenders optimizing for their selfish profit narrow view, no matter what the consequences will be for the collectivity on large scale and at long terms.
• tylerrooney 7mo ago
  I worked at Amazon 2005-2008 as a Software Dev Engineer. To hammer home company culture, there were two awards which could be awarded at the Quarterly All-hands meeting * The "Just Do It" Award which recognized someone just fixing some obvious problem at was in front of them but not responsibility * The "Door Desk" Award for frugality, named in honour of the basic door-frame-four-leg desk everyone worked on. In many ways, the Door Desk award was for simplicity. I remember, one time, someone got an award for getting rid of some dumb operations room with some big unused LCD TVs. When you won these awards, you rarely got any kind of reward. It was just acknowledgement at the meeting. But that time, they literally gave the guy the TVs.
  • PaulDavisThe1st 7mo ago
    Except that of course, the "simple" Door Desk was actually more expensive than the equivalent from Ikea, had no real additional functionality and took more time to put together. Which somewhat muddies the metaphor ... (amzn 94-96)
    • taeric 7mo ago
      I confess I assumed that the spirit of that award was more in "using what you have" than it was in making a simpler solution? They definitely over indexed on how clever the door desks were, though. It is funny how much people assume quality from appearances, though. Same for costs.
      • PaulDavisThe1st 7mo ago
        There was/is a Home Depot and an Ikea equidistant from every Seattle amzn location. Bezos just though the door desk was "cool", and didn't both to cost compare with Ikea till after many of the door desks had been built. They were undoubtedly stronger than the Ikea equivalent, but that is unlikely to ever have been an issue.
        • taeric 7mo ago
          Agreed on the strength. I used to get annoyed with friends lambasting ikea furniture as not as strong as some custom built options. Nevermind they were strong enough for what they were designed for. Hilarious that cool factor won him over years ago. Not even a dig at him, really. Yet more evidence that we can all fall for that.
• bagacrap 7mo ago
  Actually I have seen successful promotion packets based on elimination of complexity. When maintenance of a complex system becomes such a burden that even a director is aware of it, "eliminating toil" is a staff level skill. More than once I have seen the same project yield two separate promotions, for creating it and deleting it. In particular this happens when the timescale of projects is longer than a single engineer's tenure on a given team. But yes, avoiding complexity is rarely rewarded. The only way in which it helps you get promoted is that each simple thing takes less time and breaks less often, so you actually get more done.
• barapa 7mo ago
  I promote people for simplicity
• ebisoka 7mo ago
  Shipping a button in 2026… <https://www.youtube.com/watch?v=xE9W9Ghe4Jk https://www.youtube.com/watch?v=xE9W9Ghe4Jk>
• phito 7mo ago
  I keep reading this online but never encounter it in real life. People I work with and for like simple solutions that don't add complexity. It saves them time and money. I really wonder how is it that some people seem to encounter this toxic mentality so much that they assume it is universal. Is it a FAANG/US culture thing where everyone acts based on corrupted incentives?
  • mrkeen 7mo ago
    It's the definition of simple that's the problem. For any definition of simplicity you might have, someone has an equal and opposite definition. Take these two alternatives: class UserService { PostgresDatabase db; } class UserService { IDatabase db; } There are some coworkers who will veto the first example for being too complex, because it brings Postgres (and its state and connections and exceptions and mappings) into the scope of what otherwise could have been a service concerning Users. There are some coworkers who will veto the second example for being too complex, because Postgres is all you use for now, and if you really need to use a second database, you can change the code then (YAGNI). Also the Interface gives you a pointless indirection that breaks IntelliSense so you can't just 'click-through' to follow the code flow.
    • tumetab1 7mo ago
      I agree with your comment, but I disagree a both the example opinions... complex is the discussion :D I heard something that helps better framing those discussions, use "familiar" instead of "simple". An highly abstract way to access a database table, with ORM for example, can be simple because everyone is expecting it and knows how to do all tasks (changing schema, troubleshooting, managing transactions, etc.). Doing userService.pgSql("select ....") in the same way can be simple.
  • __turbobrew__ 7mo ago
    I recently had a performance review at a FAANG. One engineer on my team has spent the past 3 years working on a complex infrastructure migration which involved about 20 engineers. The migration was completed last year and saved the company some opex costs. I on the other hand spent 3 weeks optimizing our core service and reduced 2x the opex costs of the large complex 3 year migration. In my yearly review my manager acknowledged my impact, but said I need to solve more complex problems to get to Staff Engineer. I protested saying that my 3 weeks of work had a larger impact than 20 engineers over 3 years, but he told me that is just how it works.
• PaulDavisThe1st 7mo ago
  Side note: > The interviewer is like: “What about scalability? What if you have ten million users?” This reminded me of how much more fun I find it to work on software that always only has one user, and where scaling problems are related solely to the data and GUI interaction design.
• xorgun 7mo ago
  [dead]
• BenoitEssiambre 7mo ago
  If you're at a place that rewards complexity, you might be able to pitch simplicity as something that to get right, requires deep understanding of complex information theoretic concepts and deep understanding of ontological knowledge about the domain (it helps that this is true https://benoitessiambre.com/simple.html https://benoitessiambre.com/simple.html ). You can talk about the Bayesian Occam's Razor ( https://benoitessiambre.com/abstract.html https://benoitessiambre.com/abstract.html ) and about minimizing the entropy of code ( https://benoitessiambre.com/entropy.html https://benoitessiambre.com/entropy.html ), of tests ( https://benoitessiambre.com/integration.html https://benoitessiambre.com/integration.html ) and even of infrastructure ( https://benoitessiambre.com/pgcentrism.html https://benoitessiambre.com/pgcentrism.html ).
• Lapsa 7mo ago
  what a pub/sub hater
• misja111 7mo ago
  This is not entirely true. In an environment driven by business stakeholders, the engineer who ships features quickly, and that break rarely in production, will be greatly appreciated. The engineer who takes weeks to over-engineer a simple feature, which then runs into unexpected side issues in production, much less so. The environment where the over-engineer tends to be promoted is one where the engineering department is (too) far separated from where the end users are. Think of very large organizations with walled departments, or organizations where there simply is not enough to do so engineers start to build stuff to fight non existing issues.
  • _vertigo 7mo ago
    This was my exact thought process reading this. The business side of my company does not care or want to wait for complex solutions that sound cool to engineers. If anything, we have the opposite problem: convincing business stakeholders when complexity is in fact warranted.
• tasuki 7mo ago
  "The Parable of the Two Programmers" by Neil W. Rickert is pretty much about this, from the year 1985...
• blueTiger33 7mo ago
  Steve Jobs
• pradn 7mo ago
  The problem can be complex, which sometimes means the solution needs to be complex. Often, you can solve a complex problem in simple ways. There’s many ways to do that: a) finding a new theoretical frame that simplifies the space or solutions, helps people think through it in a principled way b) finding ways to use existing abstractions, that others may not have been able to find c) using non-technical levers, like working at the org/business/UX level to cut scope, simplify requirements, The way you can make complexity work for your career, is to make it clear why the problem is complex, and then what you did to simplify the problem. If you just present a simple solution, no one will get it. It’s like “showing your work”. In some orgs, this is hopeless, as they really do reward complexity of implementation.
• random3 7mo ago
  This has been a thought theme throughout my career and have a good set of scenarios I never ended up publishing. It's not just the most "elaborate system". The same thing happens in so many other ways. For example a good/simple solution is one and done. Whereas a complex one will be an interminable cause of indirect issued down the road. With the second engineer being the one fixing them. Then there's another pattern of the 10x (not the case with all 10x-ers) seeding or asked to "fix" other projects, then moving on to the next, leaving all the debt to the team. It's really an amazing dynamic that can be studied from a game theoretical perspective. It's perhaps one of the adjacent behaviors that support the Gervais principle. It's also likely going to be over soon, now that AI is normalizing a lot of this work.
• jona777than 7mo ago
  Is it just me or could this apply to commentary as well? Sometimes, I set out to comment with all my thoughts and their intricacies related to the subject, but sometimes the simplest one contributes far more to the conversation. In my experience, simplicity enables others to more freely participate and contribute.
• arealaccount 7mo ago
  I'm not sure I agree wit this, if I have work that needs to be done, and have a vague idea how long it should take The engineer that consistently quotes 3x my expectation (and ends up taking 4x with bugs) is going to look way worse than the engineer that ships things quickly with no drama.
  • Steve16384 7mo ago
    It's rare to have two engineers working separately but on exactly the same problem so their results can be directly compared.
• NoSalt 7mo ago
  I feel this. I once worked for this manager, and whenever we finished a sprint, the first question he ALWAYS asked was "What tool(s) did you use/implement?" Many times, the answer was "No tools, I just banged out a bit of code to do the job.", only to get looked at for several seconds before he looked disappointed, and moved on. It was infuriating!
• youknownothing 7mo ago
  This resonates so hard with me. I was self-employed for over eight years, since I was the one who had to deal with all messes I always made sure that things were as simple as sensible (but not simpler). I made a good career out of it. Then I went back to being employed by a company, and I was completely befuddled but the over-complication of designs. Engineers aren't trying to help the business or solve a problem, they're trying to prove how good they are. It's just the completely wrong set of incentives. If you only get promoted by solving complex cases and there are no complex cases to solve, then you'll make them up.
• theodorethomas 7mo ago
  There are two ways of constructing software: one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. — C. A. R. Hoare
  • argee 7mo ago
    That's cute, but pure fantasy, imo. There's no non-trivial code that's actually used and maintained that's going to be immune to obvious deficiencies that get overlooked. Look at this [0], for example. Simple as can be, obvious defect in a critical area, left out in open source for ages, a type of bug an LLM would be liable to generate in a heartbeat and a reviewer could easily miss. We are human after all. [1] [0] https://www.theguardian.com/technology/2014/feb/25/apples-ssl-iphone-vulnerability-how-did-it-happen-and-what-next#what-was-the-bug https://www.theguardian.com/technology/2014/feb/25/apples-ss... [1] https://pmc.ncbi.nlm.nih.gov/articles/PMC9436839/ https://pmc.ncbi.nlm.nih.gov/articles/PMC9436839/
• ChrisArchitect 7mo ago
  Earlier discussion: https://news.ycombinator.com/item?id=47242765 https://news.ycombinator.com/item?id=47242765
• fennecfoxy 7mo ago
  Yep people get promoted for bullshit throwaway projects that are built in the fastest & dirtiest way possible so that management can dance & clap about how brilliant everyone is about every 2-4 weeks.
• checkmatez 7mo ago
  "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Antoine de Saint-Exupéry. It's hard to keep things simple. Management should be mindful of that and encourage engineers to follow YAGNI, to do refactorings that remove more code than they add, etc.
• TimMeade 7mo ago
  Complexity is the enemy of success - Tony Robbins.
• quantum_state 7mo ago
  The implication and manifestation of Dijkstra's observation are routine happening in IT ... God bless info tech.
• austin-cheney 7mo ago
  The name of the game is framing. You don't talk about simplicity, because most people don't really understand what simplicity is. They falsely equate it to easy. Instead you talk about how you complete all your tasks and have so much bandwidth remaining compared to all your peers, the beneficial results of simplicity. Being severely under used while demonstrating the ability to do 2x-10x more work than everybody else is what gets you promoted. In this vein simplicity is like hard work. Nobody gives a shit about hard work either. Actually, if all you have to show is how hard you work you are a liability. Instead its all about how little you work provided and that you accomplish the same, or more, than everybody else.
  • pretzellogician 7mo ago
    Except you spend extra time making your code simple, rather than slapping together something that requires extra maintenance from the eventual owners. Ideally we need metrics saying, "my projects require 30% less support or 50% less brainpower than comparable projects". Things like "average cyclomatic complexity", etc.
    • austin-cheney 7mo ago
      Simplicity is like any form of automation in that there is always an expensive upfront cost. The automation pays for itself by reducing time per interval, so its only a matter of when break even occurs as derived by the savings per interval multiplied by intervals in a given frequency.
  • Cthulhu_ 7mo ago
    Exactly, simplicity is a subjective term; some think of it as in Clean Code where codebases end up as oneliner functions or overly formal lasagna code with many clean-feeling layers, but they can't see the resulting complexity in the overarching architeture.
• dfilppi 7mo ago
  [dead]
• narvidas 7mo ago
  In full-time employment this is sad but true. There is a way out of this toxic loop however. As a consultant/contractor I always evangelise simplification and modelling problems from first principles. I jump between companies every 6-12 months, cleaning up after years of complexity-driven development, or outright designing robust systems that anybody (not just the author) can maintain and extend. This level of honesty helps you build a reputation. I am never short for work. I also bill more than I could ever as a full-time engineer based in Europe.
• pacifi30 7mo ago
  Totally tangent, a startup get promoted to getting funded if the business model is simple. May be opt for a startup.
• newzino 7mo ago
  [flagged]
• mrkeen 7mo ago
  One more opinion piece uselessly recommending "simplicity" with no code samples or concrete takeaways. > It also shows up in design reviews. An engineer proposes a clean, simple approach and gets hit with “shouldn’t we future-proof this?” So they go back and add layers they don’t need yet, abstractions for problems that might never materialize, flexibility for requirements nobody has asked for. Not because the problem demanded it, but because the room expected it. $100 says the "clean, simple" approach is the one which directly couples the frontend to the backend to the database. Dependencies follow the control flow exactly, so that if you want to test the frontend, you must have the backend running. If you want to test the backend, you must have the database running. The "abstractions for problems that might never materialize" are your harnesses for running real business logic under unit-test conditions, that is, instantly and deterministically. If you do the "simple" thing now, and push away pesky "future-proofing" like architecting for testing, then "I will test this" becomes "I will test this later" becomes "You can't test this" becomes "You shouldn't test this."
• surrTurr 7mo ago
  Well you do get promoted for simplicity if you outperform others, who do things too complicated. For example, person A implements the simple solution, gets the project done faster while person B over engineers, has seemingly impressive stuff to talk about but at the end of the day doesn't ship.
• mathgladiator 7mo ago
  There is a balancing point. At core, complexity is derived from discovery of demand within those pesky complex humans. Simplicity is the mechanism of finding common pathways within the mess of complexity of a product. the tragedy is that simplicity is very expensive and beyond most organizations ability to support (especially since it can slow down demand discovery), and this is one of the allures of big tech for me. I was greatly rewarded and promoted for achieving simplicity within infrastructure.
• dcchambers 7mo ago
  We all know this, but no one is willing to fix it. Be the change you want to see in the world. If you are in management, promote those that see the value in simplicity.
• wanderr 7mo ago
  This is the norm at large tech companies and, IMO, a huge problem and major detriment to productivity within organizations as the cost of that added complexity is paid by everyone. BUT, at least very occasionally I have seen people get promoted for simplicity, I've even successfully made the case myself. With a problem that was itself so complex that it was causing fires on a regular basis, and staff & principal engineers didn't want to touch it with a ten foot pole. When a senior eng spent a couple of weeks thinking about the problem and eventually figured out a way to reframe it and simplify the solution, melting away months of work, making the promo case was actually quite easy. The problem is, the opportunities to burn down complexity like that don't present themselves nearly as often as the opportunities to overcomplicate a thing, which are pretty much unbounded.
• game_the0ry 7mo ago
  Quite the opposite -- you get promoted for complexity and inefficiency, and pretending like you are the only SME who can handle it, thus creating a dependency between you and your manager. A good technical manager can see this coming a mile away. Bad ones don't but it costs the company. The sad thing is that it is common to get fired when you make things better bc then your work is perceived as "done" and your skills are no longer necessary. There are countless IT job stories where someone delivers a technical solution that saves a company a ton of money or generates revenue, then they get fired bc the solution has been delivered and an off shore team has been hired to maintain the work. Big corps suck. Edit -- reading some the responses here on this topic and they are...eye-opening and depressing.
• SurvivorForge 7mo ago
  The incentive misalignment gets worse when you factor in hiring pipelines. A team that keeps their stack simple has fewer "impressive" bullet points for resumes, which makes it harder to hire senior engineers who want to work with "interesting" technology. So there's pressure from both ends — management rewards complexity, and talent acquisition inadvertently selects for it. The orgs that consistently reward simplicity seem to be those where senior engineers have enough credibility to push back and say "we already solved this with three lines of SQL."
• jcmontx 7mo ago
  Sad but true. I'm very strict with my developers and extremely cautious of introducing new "moving parts" to existing systems. I try to keep a single deployment-unit if possible. I like monoliths.
  • kolja005 7mo ago
    I just refactored a bunch of our microservices into a monolith. Fortunately the business justification was pretty straightforward because it was clear to all of us that the service architecture was weighing us down. Since one of microservice's benefits is solving a coordination problem, now that teams are getting smaller due to AI, I wonder if we will see monoliths make a resurgence in some cases.
• ngow25 7mo ago
  You can though. You can build a simple system that's easy to operate, and just sail it in.
• dismalaf 7mo ago
  All this is game theory top to bottom. The only way to really quantify productivity is to look at "how much" of a thing has been created. In this case, lines of code, features, files, etc... So of course people who want to maximize their own income through promotions will also be incentivized to maximize the only quantifiable thing that they're judged on.
• SoftTalker 7mo ago
  The example in the story seems, if I may, "too simple." Rarely have I seen an actually straightforward, simple feature that can be done in a day used as the basis to spin up a 3-week mini-project with a complicated new architecure. What happens is a complicated-sounding feature is requested, and some devs will just take it literally and implement it, maybe along with some amount of "future-proofing" that logically follows because the spec is poorly scoped. Other devs will spend some time thinking about it, realize that there is a really a simple requirement at the core of the request, and it only sounds complex because it was vaguely specified (or maybe these days an LLM was used to write the spec, and its vomit was copy-pasted verbatim). They just implement the simple thing that is the actual need. This is one place where the agile/scrum practice of planning poker can help. You get a few smart people in a room, and discuss the story and its requirements. Hopefully someone will throw out a low number of points and say "isn't this simply asking for..." Over my career, most of the complicated code I have written is no longer running. What is still running after 10 years? Postgres (or more broadly, a relational database). Fad frameworks or architectures come and go pretty quickly, they don't end up working as advertised, and it's on to the next thing. I no longer want to spend time in this hamster wheel churning out complicated code that will only end up as next year's tech debt.
• jsiepkes 7mo ago
  I have a story about this; People had an HSM (in USB key form) which needed to be shared. The question came to create some elaborate piece of software for lending to prevent people from accidentally leaving it in their pockets and accidentally going home with it (which had happened a couple of times). Instead I went to the hardware store across the street and bought the biggest (and cheapest) screwdriver I could find and attached it with some cord to the HSM. They never lost it afterwards.
• SurvivorForge 7mo ago
  There's a related dynamic that I don't see discussed enough: simplicity is also harder to defend in design reviews because it looks like you didn't consider the edge cases. When someone proposes a three-table schema, the immediate question is "but what about X?" and the simple answer — "we handle X when X actually happens" — sounds like hand-waving compared to someone showing an elaborate diagram that accounts for every hypothetical scenario. The irony is that the elaborate design usually handles those hypotheticals incorrectly anyway, because you can't predict real requirements from imagination. The simple version gets modified when real feedback arrives, and the modifications are cheaper because there's less architecture to work around.
• erelong 7mo ago
  Relatedly, I'm periodically thinking about the issue of people who prevent problems not being rewarded as much as those who become "heroes" for resolving avoidable situations I guess it may be important to underscore the value that simplicity provides over needless complexity or to sell people on the value of problems prevented rather than preventable catastrophes that were dealt with Maybe we could encourage a culture of patting people on the back for maintaining reliable "boring" systems Some people also crave "drama" so there might be a way to frame "boring reliability" as some kind of "epic daily maintenance struggle that was successfully navigated"
  • pm90 7mo ago
    You’re thinking along similar lines as I am. The article talks about “visibility” in the end. This might be a document that is written. Or it could be a demo thats shared. Or a simple shout out in slack. As engineers, we tend to keep away from the limelight and quietly get shit done and be happy with it. But professional growth and recognition requires visibility somehow. We need to be creative on how to achieve that.
  • stahorn 7mo ago
    The difference between the fire fighter and the fire safety inspector. The former puts out fires and saves lives and is of course a hero. The latter complains about things that never happen, wastes everybody's time and money and is generally annoying.
    • strix_varius 7mo ago
      It seems like the safety inspector might be closer to a SOX compliance auditor or something... in this metaphor, the engineer who doesn't build something that "catches fire" is just the one who uses sensible materials, includes smoke alarms in the design, and chooses to use passive insulation in the walls instead of electric space heaters on a high-pile rug.
    • morning-coffee 7mo ago
      In my engineering job of over 30 years, I've noticed that the heroes that get rewarded for fixing the problems are usually the same ones who created the problems in the first place. I've only been a paid-on-call firefighter for 10 years, but I have yet to work with any who are also arsonists. ;)
• tracker1 7mo ago
  I'd add one point to this, as someone who voraciously fights against complexity at every turn, more and more as I get older. I've experienced times where leadership/management will assume that you're fighting against the complex solution simply because you don't grasp or understand it. It's irritating at best. The longest lived projects and solutions I've worked on have always been the simplest, easiest to replace solutions. Often derived from simple tests scenarios or solutions that just work and get shifted over without much re-work. What's somewhat funny, with this is that AI code assistants have actually helped a lot with continuing this approach for me... I can create a stand alone solution to work on a library or component, work through the problems, then copy the component/library into the actual work project it was for. I'm in a really locked down internalized environment, so using AI for component dev is on my own hardware... but the resulting work is a piece that can be brought in as-is. No exposure of internal data/resources. I don't think I'll have a level of trust to "one-shot" or vibe code solutions from AI, but leveraging the ability to spin up a project as a sample to test a component/library is pretty great to say the least.
  • strix_varius 7mo ago
    To add to this, sometimes leadership will assume (or even imply) that there's some laziness involved in not wanting to jump immediately on-board with the complex proposal. I often end up saying, "I can build this, and I will build this if product insists on it, but first let me suggest an alternative ordering of deliverables that starts with a simple implementation and moves towards this one." In almost every case, that simple implementation is still what's in production years later.
    • taeric 7mo ago
      Lead time for "how long until we can start using it" is one that is hard for a lot of folks to really take into consideration. There are terms for this, "earned value" and such. I have rarely seen them used in such a way that the planning actually worked out, long term.
  • alansaber 7mo ago
    The only way to learn this lesson is the hard way
• callamdelaney 7mo ago
  Sqlite, the one trick interviewers hate!
• JDye 7mo ago
  We've had an interesting experience on the interviewing side of this. Asking a system design question and getting answers involving multiple layers of caching, pub/sub, event-driven whatever/etc.. when the real answer is to just use postgres. It handles the scale we're asking about. We know it, as that's what we use internally. I've only worked at my startup so I can't comment on scale elsewhere, but if our simple architecture can handle 30k requests per second, I think it can handle most other companies scale too.
  • voxl 7mo ago
    If your interview questions answer is a particular technology then you're asking a really bad question.
    • JDye 7mo ago
      It's more "just put it in A database". If someone said MongoDB I'd be just as happy.
• kittikitti 7mo ago
  When I'm on a team and there are multiple engineers and data scientists, many of them come from Big Tech: Google, Microsoft, Apple, etc. I don't get any points with them for implementing a one-liner that does whatever Google implemented but they get very excited if I did. I get a "Oh wow, I know someone who worked on that at Google, I am really glad it's useful!" This extends to suggesting huge licenses like from Salesforce. The Marketing and HR teams are ecstatic that they can purchase another license of their favorite software, they can go shopping! If I had implemented a free and more efficient CRM, there would be no networking effect. This all builds systems that are vastly more expensive (to the tune of hundreds of thousands of dollars), slower, and much harder to fix. YCombinator financially benefits from this and it's all very corrupt. Most of the time, I have to really gain the "soft skills" to activate the networking (nepotism) effects. It's not about what you know, it's about who you know.
• deleted 7mo ago
  [deleted]
• andoando 7mo ago
  I just dont agree with this and it hasnt been my experience. Your job is to deliver value. If you can get stuff done quicker and without it breaking, you did great. Some one who spent more time doing the same thing except took longer and has a more brittle solution they have to keep going back and fixing doesn't look good. And simple solutions are easier to explain and convince people.
• nopurpose 7mo ago
  Adjacent to it are PR reviews. Suggesting simpler approach in PR almost always causes friction: work is done and tested, why redo? It also doesn't make a good promotion material: keeping landscape clear of overengineered solutions is not something management recognises as a positive contribution.
  • Cthulhu_ 7mo ago
    Depends on the management and whether they're involved in coding. Any engineering manager, architect, senior / lead developer etc should appreciate lower complexity. Of course, if it's the person in charge introducing said overengineering there is a problem.
    • nopurpose 7mo ago
      they can recognise on the informal level, but you can't put it into end of the year review document. What it will be? "Kept N PRs from introducing cruft into our systems?". Fixing or building things is much more visible, than just maintaining high standards. Worse, to suggest a simpler approach checking existing products/APIs or even preparing toy prototype is required to be confident in own advice. This hidden work is left entirely unnoticed even by well meaning managers/engineers: they simply don't know if you knew or had to discover simpler solution.
• mparnisari 7mo ago
  If they could read, this would upset managers at Amazon.
• spelunker 7mo ago
  This is definitely a "known problem". At my company we call it "promotion-driven development". The promotion guidelines call out that knowing when _not_ to build something is important, but how do you put that in a body of work? "Decided not to build A". Nobody cares.
• oceanplexian 7mo ago
  Ironically, this article is "over simplifying" the problem. In the FAANGs I've worked at, engineers who come from scrappy companies and implement hacks (Like the example of emailing spreadsheets around) undermine the business and will cost the productivity of thousands of people. However, at the startups I've worked at, the folks from big companies that try to implement a super complex thing (e.g. exotic databases, overly ambitious infrastructure) The results are equally catastrophic for a company attempting to bootstrap when the complexity is so far removed from their core business. What makes an experienced engineer is recognizing both states, understanding what works where and making the right trade-offs, usually from experience you can't fake your way through. I've seen a lot of projects that took 10-20 engineers 18 months to so we could sell something that landed a $100M contract with a customer. You see that enough times and you won't bias as hard against complexity. But of course it's situation dependent, like anything.
  • jpollock 7mo ago
    There are definite discontinuities in there. What works for a team of 5 is different to 50 is different to 500. Even just taking fault incidence rates, assuming constant injection per dev hour...
  • alansaber 7mo ago
    Being able to project manage yourself is indeed a very difficult skill
  • kermatt 7mo ago
    The right answers are usually something in the middle. Don't email spreadsheets (i.e. make copies that drift), don't use K8S unless it is a technical requirement. For some reason, this middle ground gets the smallest population.
• notepad0x90 7mo ago
  You can sell simple solutions as complex by focusing on what they solve. No one has to know your solution is simple unless they're looking under the hood. And complexity doesn't always sell better. A lot of times it might look like the whole thing is messy, or too hard to maintain, tech burden nightmare. Things that are simple might look complex and vice versa too, I think anyone who had to implement requirements from people who don't understand the implementation complexities will know this very well.
• ImaneIdrissi 7mo ago
  It's great to choose simple solutions to avoid over-engineering, but at the same time you need to be able to talk about them in a way that proves making that choice was much more complex than picking the complex path directly. Listing both the complex solution and the simple one shows others that you reasoned about both and deliberately chose simplicity. It's all about framing the story behind the decision.
• flashybaby 7mo ago
  [flagged]
  • easton 7mo ago
    What's going on here? There's a AI generated song in a youtube video, but it was posted yesterday and this bot is here today. Did someone have future sight of what today's HN post was going to be?
• DrewADesign 7mo ago
  I’ve known some pretty simple managers that got promoted pretty quickly.
• upofadown 7mo ago
  I actually got a job for deleting code. I was fixing a problem on a contract and noticed that I could fix the problem by getting rid of the section that contained the problem. The functionality could be provided in a much simpler way. Later the company created a position and I was given first refusal before they interviewed anyone. It was a 8 bit embedded application in something like 10k of code. When I left I generated a short and clear explanation of why what I had done was awesome in terms of their future business ... because that is what you have to do if you work contracts. Which is the real message of the article. You have to write things up.
  • strix_varius 7mo ago
    That sounds like good work & a good outcome. I think there may be one ingredient left though to this: > You have to write things up. ...and someone has to read it who understands the value you brought by deleting complexity.
• doall 7mo ago
  The irony of simplicity is that people often talk about it, yet the concept is so complicated that they fail to define it.
• blobbers 7mo ago
  Haha. This title: Nobody Gets Promoted for Simplicity This was the model at my last job. The "director" of software had strong opinions about the most random topics and talked about them like they would be revolutionary. His team was so far from the product teams they would just build random crap that was unhelpful but technically demo'ed well. Never put into practice. Promoted for 4 years, then fired.
• 1024core 7mo ago
  FAANGs are notorious for promoting complexity, and the results are there for all to see. One thing engineers can do to fight this, and I think it's mentioned in the article, is to write extensive documentation. Bosses in these companies are too lazy to dig into solutions and figure out for themselves; so they resort to proxies like the number of lines of code, number of pages in the design doc, etc. Unfortunately, some of us who aim for simplicity are also averse to writing long docs; but with the advent of LLMs, there is some relief in sight. My career has suffered a lot in terms of promos, etc. because I hate complexity.
• EchoReflection 7mo ago
  I imagine Steve Jobs would not have agreed with the statement "Nobody gets promoted for simplicity".
• zackmorris 7mo ago
  Just about every project I've ever worked on eventually needed everything. So the way we write software piecemeal today is fundamentally broken. Rather than starting with frameworks and adding individual packages, we should be starting with everything and let the compiler do tree shaking/dead code elimination. Of course nobody does it that way, so we don't know what we're missing out on. But I can tell you that early in my programming journey, I started with stuff like HyperCard that gave you everything, and I was never more productive than that down the road. Also early C/C++ projects in the 80s and 90s often used a globals.h header that gave you everything so you rarely had to write glue code. Contrast that with today, where nearly everything is just glue code (a REST API is basically a collection of headers). A good middle ground is to write all necessary scaffolding up front, waterfall style, which is just exactly what the article argues against doing. Because it's 10 times harder to add it to an existing codebase. And 100 times harder to add it once customers start asking for use cases that should have been found during discovery and planning. This is the 1-10-100 rule of the cost of bugs, applied to conceptual flaws in a program's design. I do miss seeing articles with clarity like this on HN though, even if I slightly disagree with this one's conclusions after working in the field for quite some time.
• bluemario 7mo ago
  The structural problem is that simplicity accrues value slowly and diffusely, while complexity delivers visible credit immediately to whoever built it. The person who adds the abstraction layer gets the PR merged and the ticket closed. The person who deletes it six months later gets... a smaller diff and a shrug. I've noticed the incentive breaks down even further when you consider that simplicity often means saying no upfront, which requires correctly predicting future maintenance costs that nobody has experienced yet. Complexity requires no such foresight. You just build the thing someone asked for. The orgs where I've seen this actually work had explicit "deleted lines" culture, where removing code was celebrated as loudly as shipping features. Not many places do that. Most treat a 2000-line deletion PR with the same energy as taking out the trash.
• andresquez 7mo ago
  I think it's simpler than that, you get noticed and then maybe promoted based on what you deliver. The ability of delivering what you were asked to, on time, or even before that. Adding extra things can always help, specially like in the UI side of things, since higher ups will probably just notice that part.
• jppope 7mo ago
  The article's point is sound, but its missing a key component. People who build simpler systems are capable of getting more done - the build takes less, the maintenance takes less, etc. So when the engineer choosing simplicity is looking to get promoted they might have 3 or 4 bullet points to their name instead of 1. Of course, over-simplification is the wrong decision some times, the same as abstraction and complexity is the wrong decision some times... Your shortcut for promotion is generally building value for the company, but people need to remember that promotions support the business and they aren't free to the company.
  • saulpw 7mo ago
    Unfortunately, no, simpler systems often take longer to create. It's always easiest to just add some janky widget hanging off the side, than to rejigger the whole system to be simpler. It's like the Pascal quote: "I have made this longer than usual because I have not had time to make it shorter." They take less to review and maintain etc, but the credit for those positives aren't assigned to the original engineer. Which is the point of the article.
• astrobe_ 7mo ago
  The problem simplicity is facing is mentioned in TFA with the keyword "future-proof", which is the typical instance of FUD in software. It is extremely difficult to fight against it, as, just like fake news, it would take 10 times more effort to debunk it than to make it. Yes, you spell out the cost of the additional layer, but it is invariably answered with "that's not so expensive", and risk aversion does the rest.
• pojzon 7mo ago
  What in case engineer picks a simple solution that is hard to understand, cant be tested and next person that comes looks at it and says “wth is that?” In case you ask “how can simple solutions be hard to understand and test?” Lets just say you use single line bash scripts with multiple pipes, loops and very niche cmds. It will work, it will look like nightmare, it will be simple -> one line.
• boricj 7mo ago
  That article made me chuckle. I'm currently building a full-blown OpenAPI toolchain at work, where the OpenAPI document itself is the AST. It contains passes for reference inlining, document merging, JSON Schema validation, C++ code generation and has further plans for data model bindings, HTML5 UI... Why? Because I'm working on a new embedded system which has a data model so complex, it blew past 10k lines of OpenAPI specifications with no end in sight. I said "ain't no way we're implementing this by hand" and embarked on the mother of all yak shavings. I want all of the boilerplate/glue code derived from a single source of truth: base C++ data classes, data model bindings, configuration management, change notifications, REST API, state replication for device twins and more. That way we can focus on the domain logic instead, which is already plenty complex on its own. I'm not designing all of this to be simple to develop. I'm designing it so that it's simple for the developers. Even with the incomplete prototype I have currently, the team is already sold ("you mean I just write the REST API specification and it generates all of the C++ classes for me to inherit?"). The roadmap of features for that toolchain is defined, clear and purposeful: to delete mountains of menial, bug-prone source code before it is ever written by hand. Sometimes, it takes complexity to deliver simplicity. The trick is to nail the abstractions in-between.
• dirk94018 7mo ago
  Simplicity is hard. Mark Twain's 'I would have written less had I had more time' at the end of a letter comes to mind. Software dev's tendency to build castles is great for technical managers who want to own complex systems to gain organizational leverage. Worse is better in this context. Even when it makes people who understand cringe. You would think that things not breaking should be career-positive for SysAdmins, SREs, and DevOps engineers in a way it cannot be for software devs. But even there simplicity is hard and not really rewarded. Unix philosophy got this right 50 years ago — small tools, composability, do one thing well. Unix reimagined for AI is my attempt to change that.
• e40 7mo ago
  I hate clickbait titles like this. Of course, some organizations appreciate and reward simplicity. Mine does.
• aljgz 7mo ago
  In my team, I've been working to help everyone do a task that's necessary, but because it was too difficult, people bypassed it. Over time, I made it simpler, others are joining to make it even simpler, but in the process, I'm not doing as many "feature tasks" as I could. I joke that people are mad at me every day, but grateful every week and month. I had to stop trying to prove myself to the company. I have already done that when y'all interviewed me. Now I do what's best for everyone, and I want the company to prove to me that it deserves people who do the right thing despite the processes not valuing it. If it does not, I have enough resources to spend some time on the projects I cared about most. This mentality gave me peace of mind and helped many people in partner teams go faster and with higher quality. Management still does not openly appreciate it, but it shows in how they interact with me. Like when you learn to talk to your parents as equals. It's unexpected for them, but they quickly embrace the new interaction and they love it much more than the one before.
  • deleted 7mo ago
    [deleted]
• EmilySmith23 7mo ago
  This is true, but since the article mentions interviews. They're a game in itself.
• jameson 7mo ago
  "less is more"
• aristofun 7mo ago
  That is very true. For whatever reasons - the bigger the company, the more unjustified complexity it cripples itself with without being aware about it. Also survivorship bias is a very real thing (problem prevented is ignored, while problem solved is appreciated regardless of who and why caused it).
• t43562 7mo ago
  Simplicity can be a powerful defence against complexity. When there are many ways something can go wrong. Rather than trying to anticipate all the different failure modes one tries at first just to handle fact of failure itself, assuming there's no remediation. If there's a way to make sure the worst case isn't terrible in some simple way then you do that first - like making a backup file or tr4ying to keep APIs idempotent so you can recover from issues and so on.
• aarestad 7mo ago
  The example he gave where each dev gets a single feature done seems to skip over the opportunity that Dev A has - after she spends only "a couple days" on that feature to ship a simple solution, she now has the rest of that week to do another feature, and another... in fact, she could probably get 6 features done in the time that Mr. Complexity took to do his one feature (3 weeks in the straw-man example). Then the promo packet looks much better for Dev A - while it says "implemented feature X", it also says "implemented feature A, feature B, feature C...". Doesn't that seem more attractive? Slightly related: I've noticed that there are lots of "ideas guys" (yes, guys) in our field who love to bloviate, and maybe even accomplish some stuff that looks really good. I have made a career out of just putting my head down and getting shit done. I may not have grand design ideas, and in fact have had to unlearn the "fact" that you need to come up with, and implement, Big Ideas. In my experience, people who "get shit done" may not get fancy awards, but their work is recognized and rewarded.
  • anal_reactor 7mo ago
    > in fact, she could probably get 6 features done in the time that Mr. Complexity took to do his one feature Not if management is moving at the speed of the more complex solution. > yes, guys I thought that blatant sexism wasn't a part of this website. > In my experience, people who "get shit done" may not get fancy awards, but their work is recognized and rewarded. top kek
  • throwaway292939 7mo ago
    I think sometimes flip side is that the engineer looks like they just shipped a bunch of "small features" A, B, C... because the solutions were so simple
• mattbillenstein 7mo ago
  Extends to the extreme levels of SaaS-ification of fairly basic app functionality as well. It's often simpler to build something you know than to integrate a 3rd party service, but it's highly frowned upon by a lot of devs and management. Auth and analytics are things I'm thinking of - we have good tools to build these in-house. Also just running a database - never seen so many people afraid of installing postgres and a cronjob to back it up.
• w10-1 7mo ago
  Maybe not promoted, but certainly hired, as a consultant. Most of my engagements consisted of replacing politics-driven complications with simple solutions. The bigger problem was first quietly showing all the affected people other interesting things that needed doing so they would let go. And TBH, the simple stuff lasted the longest because it harder to misunderstand or misrepresent.
• einpoklum 7mo ago
  Article seems to suggest that simplicity vs complexity is a sort of a binary, or at least a spectrum. In fact, it's very often the case that: * You can have a bunch of simple code for a latent or implicit concept that is complex; and that making the code more complex might make the reflect principle simpler. * You have trade-offs: If one aspect is simple, other aspects must become more complex to accommodate. * There is no consensus over what constitutes complex vs simple code.
• eikenberry 7mo ago
  Sounds like an inverse Peter Principle... the people who are best at their jobs will stay in that job while people who care enough about promotions to sabotage their work will get promoted out of a position to do damage.
• Jtsummers 7mo ago
  > Picture two engineers on the same team. Engineer A gets assigned a feature. She looks at the problem, considers a few options, and picks the simplest. A straightforward implementation, maybe 50 lines of code. Easy to read, easy to test, easy for the next person to pick up. It works. She ships it in a couple of days and moves on. > Engineer B gets a similar feature. He also looks at the problem, but he sees an opportunity to build something more “robust.” He introduces a new abstraction layer, creates a pub/sub system for communication between components, adds a configuration framework so the feature is “extensible” for future use cases. It takes three weeks. There are multiple PRs. Lots of excited emojis when he shares the document explaining all of this. So in this scenario two solutions are produced: Fast to develop but probably brittle (it is not described as robust, but it is described as easy to change), slow to develop but not brittle (but perhaps too complex and likely hard to change). Both fucked up. Engineer A stopped too soon, and Engineer B built too much up before any value was realized. You want Engineer C: Makes the fast solution that gives you feedback (is the feature worth pushing further? do users want/need it?), and continues to produce a more robust solution that won't crap the bed. Engineer A is a potential chaos agent, tossing out and abandoning work too soon. Engineer B is a bottleneck who will waste weeks or months producing invalid solutions. Go for the middle path.
• thallavajhula 7mo ago
  >I think there’s something quietly screwing up a lot of engineering teams. In interviews, in promotion packets, in design reviews: the engineer who overbuilds gets a compelling narrative, but the one who ships the simplest thing that works gets… nothing. I got emotional reading this. This is way too real.
• bhk 7mo ago
  Ah, but it's worse than this. The truly ambitious ladder climber creates not just unnecessarily complicated abstractions, but organizations. Processes for people to follow. Infrastructure for people to maintain. Committees to vet changes. Standing meetings.
• godelski 7mo ago
  This is so weird to read given the quote at the top. The kind of simplicity Dijkstra is talking about is a form of abstraction. He's talking about elegance. While the author is talking about a different type of abstraction, more like the image or a Jackson Pollock painting. Look at how Dijkstra talks here [0]. When a scientist says "simplicity" they mean "elegance". This is very different from "easy to understand". There's a reason that quote says simplicity is difficult to achieve. This doesn't seem in line with the author's examples. But it's easy to see what Dijkstra was talking about. Have you ever derived an equation in math or physics? You start one place, do a whole lot of work, and then you get out this "simple" thing. You could write pages of math to come up with an equation that uses only a few symbols. E=mc^2 is simple but getting there was very hard and took a lot of time, thinking, and abstraction. The author conflates simplicity with speed, not with what the end result is and how well it solves the problem. Why are CS people against abstraction? All we do is abstraction? We act like all abstraction is the same, and it's evil. We have to be more nuanced. I could see the entire blog post written in the exact other way where engineer A gets promoted because they complete more tickets and engineer B doesn't because they take too long. But the reality is that from such a high level we can't determine which solution is right. Sometimes A's method is the best and sometimes B's is the best. But we don't know the impact. B's solution could create more problems, like the author suggests, but also it could solve many problems that don't end up appearing. Same for A's solution! I don't like this over simplification and the author's conclusion is naïve. If we make everything understandable to everybody then it's a race to the bottom Who does it need to be understandable to? The senior? An experienced developer? A junior? A manager? Don't get me wrong, there's tons of unnecessary complexity out there and that's bad too. But for that I'll reference Knuth's famous and misunderstood quote where he says "get a fucking profiler before optimizing things". He too is talking about elegance, but a balance of how we should prioritize things. [0] Concern for Correctness as a Guiding Principle for Program Composition https://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD288.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD288...
• ChrisMarshallNY 7mo ago
  Yup. As a manager, I preferred engineers that delivered simpler code, but I also ran a team of experienced, high-functioning coders. I suspect teams with many less-experienced people get The Parable of The Toaster[0]. [0] https://www.danielsen.com/jokes/objecttoaster.txt https://www.danielsen.com/jokes/objecttoaster.txt
• narmiouh 7mo ago
  I feel like the article is conflating simplicity with minimalism. Just doing the minimum of whats asked isn’t in itself enough to differentiate great vs ok. Simplicity is worth recognizing only when the person started with a complex problem and ended up with a relatively simpler solution. For a straightforward ask you will have people who will just build a hut and another will build a campus, who is right really depends on many factors and time.
• WalterBright 7mo ago
  People get promoted for making their boss look good. P.S. I know this sounds obvious, but I was a slow learner.
  • WalterBright 7mo ago
    A corollary is the boss should be enabling the workers to make him look good.
• jackfranklyn 7mo ago
  [flagged]
• torvald 7mo ago
  https://www.youtube.com/watch?v=SxdOUGdseq4 https://www.youtube.com/watch?v=SxdOUGdseq4 this one comes to mind. A talk by Rich Hickey explaining that “simple” and “easy” are different concepts in software design, and that systems become better when we aim for simplicity (few intertwined parts) rather than ease (things that feel convenient at the moment).
• amai 7mo ago
  Reminds me of the classic: "Premature flexibilization is the root of all evil that is left": https://product.hubspot.com/blog/bid/7271/premature-flexibilization-is-the-root-of-whatever-evil-is-left https://product.hubspot.com/blog/bid/7271/premature-flexibil...
• deleted 7mo ago
  [deleted]
• DavidPiper 7mo ago
  If we accept the short and sweet "Programming as Theory Building (1985)", by Peter Naur, you land on Einstein's (alleged) maxim: “Everything should be made as simple as possible, but not simpler.” Or, more fully [1]: “It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.” [1] https://www.makingthemuseum.com/newsletter/the-einstein-rule-redux https://www.makingthemuseum.com/newsletter/the-einstein-rule...