Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Would like to emphasize: Software is intangible. It fails to meet most standards of "what is real", because it exists entirely in the realm of symbols. You're at the edge of reality. To human instincts it seems like an unreal world without rules, so it unconsciously triggers all sorts of weird things, including a good bit of amoral behavior. Nasty things locked away in one's psyche come out to play.
  • I love this framing. I have a lot of ideas about why this is true, but the best (IMO) pat explanation I've been able to come up with is:

    1. Much of constructing software is math of a sort. In math, you write proofs that say why X is true. In software, you write code that guarantees X will be true (e.g. "the backend assumed a user ID was always available, but now that we have service accounts, we need to change the access control code so that a sensible view is still returned")

    2. Math is hard, and most of the work is invisible thinking. If you asked a mathematician for an estimate on when the Reimann hypothesis will be proved, they would laugh at you. Our problems are generally easier, but they can still be hard. And as in math, they're sometimes much harder than you expect (e.g. Fermat's Last Theorem. "Why was it so hard? Did you talk to Fermat? He left? But he said it would be easy!")

  • It is not the software, it is the internet. Something Awful already had it figured out: The internet makes you stupid.
  • And they even figured that out before Cambridge Analytica happened.
  • It makes a lot of people dumber -- they doom scroll, gossip, play childrens games, and on the high end post cat memes.

    But it's a tool like any other and the results depend on the user.

    For those with eyes to see and ears to hear it is (was) the Library of Alexandria. The knowledge of the world unfiltered without gate keeper trolls deciding what you can see and learn.

    Getting on the internet in 1993 completely changed my life. Linux changed my life and without the internet there is no Linux. Before Linux you could not get a UNIX distro for less than $1000 USD which was a lot of money for me back then.

    Before Linux and Internet all that was available to consumers outside of big institutions was Windoze and Apple was already on life support. The internet and Linux opened an entire world to me and I never looked back. Everyone at the time said I was wasting my time and should be doing an MCSE LOL but those are people in the 90%... they will NEVER get it.

    Fast forward 4 years later I'm working in startups and leading dev teams and that was almost 30 years ago.

    I can imagine what my life would have been without the internet and I prefer how things worked out.

    So it did not make me dumber... but the filtered nannied corporate approved internet of 2026 -- that probably just makes anyone dumber.

  • Is it software having this effect or management over software products? I don't see many academic or hobby software projects constantly changing what's important to them on a whim. It can be seen all the time in the software industry though.
  • It's not software; it's the fact that most managers/administrators are not software developers (although they may have some programming ability). so they stand in teh same relationto their development team as cusomers complaining to a manufacturer about the features on a physical product, and saying 'it should do this or that, it's an easy change to make' (because it's easy to imagine having it if you skip over the tedium of having to implement it).

    Of course sometimes the ask is justified and addresses some failing of the original spec, either through lack of ambition or excess ambition that harnessed a cargo container to a lawnmower engine. But most of the conflict the article describe stems from a combination of imagining the benefits of change with the unspoken assumption that implementation is just a matter of pushing a few more buttons.

  • > Leaving things alone is an underrated engineering skill.

    Truer words have never been spoken.

  • "It is often easier to not do something stupid than it is to do something smart."
  • It’s an underrated life skill and was discovered by Lao Tsé probably around 2500 years ago
  • When I read the title, my mind immediately jumped to something else: negativity.

    I've noticed that my own mind always searches for corner cases, error conditions and failure modes. This can be super helpful when planning new features (or explaining to stakeholders that certain conditions must be met first, when they want some new features), but when it extends to other things besides software, it can be psychologically unhealthy.

  • Reminds me of this 2014 post "Programming Sucks" [0], which touches on some similar issues of getting disconnected from reality in a microcosm that always "ought" to be better than it is.

    > All programming teams are constructed by and of crazy people [...]

    > The destructive impact on the brain is demonstrated by the programming languages people write. [...]

    > All programmers are forcing their brains to do things brains were never meant to do in a situation they can never make better, ten to fifteen hours a day, five to seven days a week, and every one of them is slowly going mad.

    [0] https://www.stilldrinking.org/programming-sucks

  • After doing this a few decades, one of the things I've discovered that, working 15 hours a day is insanely overrated. A shocking number of 'impossible' problems become quite easy if you just think about them lightly overnight.
  • OP has practically observed the effect of the Ego via software, but hasn't quite arrived at the ability to quantify it.

    Read back through and apply every example given through that lens.

    It is possible that we're in an industry that inordinately expresses this part of human nature, but I'm pretty sure it shows up everywhere though different anecdota. Apply a reductionist Zen Buddhist view to your professional creativity and all of this goes away.

    Bob wants to refactor a subsystem because it will make him a hero, and if he positions it correctly to management, the technical merit and actual realized level of success will be irrelevant. Alice chooses to surface some obvious concerns and then sit back and watch the show. Jane chooses to throw her hands up in stand-up and try to emotionally convince everyone the sky will fall. Be like Alice and preserve your sanity.

  • Or maybe he thought it was more effective to talk specifically about something he had actual experience rather than saying "it shows up everywhere" with no way to actually support the claim?
  • Being like Alice preserves your sanity on that level, but opens you up to significant issues in your future career and financial state. There's a reason why people who make a bundle relatively early in this world often pack it in and move to a farm or a job where they can enjoy the produce of their labor. They have a good choice to make without sacrificing more than they can afford, but that's not true of everyone at all times.
  • My observation is simply that tech leaders misinterpret rewards from the market in conquering some abstract representation of a facet of a domain with conquering the domain itself. Then they become egomaniacal.

    Did you conquer commercial real-estate ushering in the future of work and society, or did you build a handy scheduling app?

    Did you have a neat idea for an online community or did you revolutionize human connection?

  • We are the "...whatever gets us $2m seed..." layer for the AI of the future of finance.
  • +1 .

    I think it takes a certain type of mental or emotional deficit to forfeit all of your free time and the majority stake in your company for funding for a tiny shot at hitting a grand-lam.

    "Not everything needs to be a platform". I remember a 10 person company that did translation dispatch for medical needs in California. And the CEO was insisting we needed to someday "become a platform."

  • I was about to post this thought on the latest "We're moving from tech/architecture X to Y" post on the HN front page today, but now I feel it belongs here.

    I was recently chatting with a friend about how we used to do so much more with so few developers: 20 years ago, we developed mission critical, real time software (trading systems) in C++ with team of a couple of dozen developers. The core trading kernel team was four people. An in-house distributed process orchestration tool (both front end and back end written in C++) were two guys. I myself once managed to produce an entire post-trade risk management system for futures contracts in a couple of months, working alone. Today, I see teams of 60-80 working on web and mobile applications where the vast majority of operations are CRUD, with some transaction/queue complexity at the extremities.

    I think the difference is tech churn. Back then, what few dependencies we had in terms of either runtime libraries or development time tools, were stable: the standard library, compiler, unix commands and bash scripts, and some internal libraries. Much of our time and focus went into figuring out the right algorithms and data structures, with coding coming in second. Very little time was spent on selecting, configuring, updating, rearchitecting or replacing tech stacks and tools.

  • yes but also people-churn/attrition was likely lower too. it can really hurt your career to stay in most organizations more than 2 years because very few places devote any meaningful resources to growing from within. if you want better opportunities and more comp it often requires moving companies.
  • Yes the modern toolchain is super-massive. There is no pushback. Remember when deployment was trivial?

    My expectation is that the toolchain will expand by another order of magnitude because LLM's, not just because of what they can produce, but because we are lowering the ceiling with LLM assistance when it comes to just understanding the toolchain. That creates a vacuum that people can fill up with more stuff.

    The "insanity" that makes people do this is hard to explain. It's certainly irrational and seemingly unconscious.

  • the average developer back then was much better. 50% of engineers in the average IT department produce zero or negative value. I worked at one of the largest financial institutions in the world and had coworkers that literally committed zero code for months.
  • Man I wish I was born 20 years earlier so I could be working in the golden age of developers like this (and also buy a home at a decent price)
  • Joel Spolsky's "Fire And Motion" blog post (2002) describes the challenge of tech churn well: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

    > Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.

  • If you've not read Fred Brooks MMM, give it a shot.

    It seems like you're implying that teams of 60-80 developers should be expected to outperform teams of 12. This is simply not true. The most important feature of source code as a language is that it allows precise mindshare among close knit teams. It doesn't guarantee it, but it makes it possible for people to talk about the product at a level that is otherwise very difficult.

    A convenient side-effect of the source code is that it instructs the machine what to do. But instructing the machine was never the bottleneck, the essential difficulty of software development is in understanding what are the correct instructions to achieve some objective, not typing them out.

    The problem is that communication doesn't scale at all. Having just 3 developers with good alignment about mental models, best practices, and design direction is hard enough, and if you found the right three people at the right time with the right ideas, you could generate billions of dollars of value.

    Large monolithic teams on the order of 80 are a product of people in control not understanding how software development works, and how to make it work well.

  • Software development untethered from the practical realities of the customer / user is what drives people insane.

    When developers are required to interact with the customer on a regular basis, the freewheeling effects described in this article are damped massively.

    The potential for insanity goes off the charts when the development team is siloed away in solitary confinement and the only interactions with the client occur via some prison guard known as "project manager" sliding notes under the door.

    Working with the customer sometimes sucks. Just like exercise and eating vegetables sometimes suck. It's a temporary unhappiness that keeps us grounded in reality.

  • A similar disease comes out of an industry being overly concentrated in a single geography. For instance Firefox could keep failing and losing market share for decades because Google knows politicians will be stupid enough to believe that Firefox with a 0.01% market share will mean Chrome is not a monopoly. The one thing that could possible reverse that market share decline would be having some empathy for people outside the Bay Area but that won't happen... but it doesn't matter.
  • Sometimes I would ask stakeholders about some idea or nifty feature we were considering implementing. The answer was usually positive and enthusiastic. I'd then ask if they would use it and how it would help them. Silence....

    Being untethered from reality is the natural state of humans;)