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.
Talking to the users, allowing them to show you what they are trying to do with your software, almost feels like cheating, because of how easy things suddenly appear to be when uncertainty fades away.
Obviously, the number of uniquely different users has an influence, and users most often do not truly know what they need, but that's our job to tease appart.
Turns out the users most often benefits from small changes that reduces friction toward achieving their goal. Any time saving will be appreciated, but only if it can be trusted to work. Nothing worse than the dread of knowing an action might or might not work randomly.
I use most software today with a constant sense of fear that the next action will break something and waste my time. Undo probably doesn't work properly anyways
"What problem are we trying to solve?" is a question I have to ask constantly in corporate development environments, and rarely does anyone presenting the task to be done actually know the answer!
It can be the case that people don't want to accidentally mis-state the problem, or get into a debate about the problem because they know people will chime in about nonessentials. I would recommend "Have we written down the problem we are trying to solve? I'd like to understand more." And get it written down if it isn't already.
Trying to position the conversation as "we're on the same team, trying to figure the problem out together" also helps a lot of the intensity of these conversations melt away.
Sometimes it sucks, but often it's awesome. I love seeing people use what I built for them. It was also very enlightening doing prototyping and watching the customers use it. Often they would ask for something that they didn't realize they didn't actually want until they used it. Working directly with them saved potentially months of building out features that would never be used.
Absolutely. I think that over-reliance on analytics has had a similar effect; compared to relying primarily on proper usability research and in-person user studies, doing that creates a detachment and distance that further removes the project from reality.
How great the impact is depends on how management uses the data. If they use it add resolution to broad strokes from studies and the like, there may be no negative impact at all, but in my experience it's much, much more common for management to read analytics like tea leaves and interpret it in whatever way best fits the individual's/team's biases/agendas.
>> I think that over-reliance on analytics has had a similar effect
I lost track of how many times the directors would tell us, "Since the analytics say A, we should do B." then the research person says, "Sure Jim, great idea, lets get a few rounds of useability research and confirm it first."
Then the always predictable thing happens: Users never align with your analytics. Seeing data and seeing someone struggling to do something basic with your interface is totally different. When directors see these videos, it really makes them see how important research is and not just relying on data to make decisions. Right now, anything the research team wants, they usually get - its had that profound of an impact on our leadership team.
Simple example: feature X is rarely used (thus we should get rid of it)
Hold on, why is it rarely used?
Is it hard to use? Is it hard to find? Was it poorly named? Does it work right? Does it get me 80% of the way there? Does it get me 20% of the way there? Do I rarely need it but when I do need it it's a huge time saver? Am I hesitant to depend on it because I fear it will be taken away in a future update?
> Simple example: feature X is rarely used (thus we should get rid of it)
Oh man, I remember a very specific example of this: many years ago now, Google Chrome pushed an update that got rid of the option on the menu bar for "Close Tabs to the Right". I remember looking into the Google issue tracker where people were complaining, and some PM provided a "data-driven" justification: when people opened the context menu, they only clicked on the "Close Tabs to the Right" option 1-2% of the time.
It's a great example of why data without context can give you the wrong answer. Of course the option is used relatively very rarely; you only need to clear out your tabs every once in a while, compared to creating new ones or managing tab groups! But it's still an essential task. It's like saying filing your taxes isn't important because you only need to do it 0.2% days of the year.
Conversely: Feature X is often used... Because to drive adoption someone made it mandatory for a certain workflow and it nags everyone else so they "engage" with it just enough to make it go away. (Looking at you, "AI" buttons...)
And following this, I'm sure we've all seen the pattern of manufacturing the data required to justify the removal of features. Bury feature → usage numbers tank → oh hey look nobody uses this any more, guess we can safely cut it!
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;)
"What if I made X?" is basically Product Development Antipattern #1. Most feedback you get here is incredibly low signal. The stakeholder you're talking to isn't a technical person in all likelihood, so they probably aren't visualizing what you're describing in the same way you are. There is a high probability that they are telling you it sounds great as social lubricant or because they don't really understand what you are talking about and don't want to look dumb. Not to mention that positive response is the path of least resistance for most people -- the hard work of thinking critically about an idea so that you can locate potential flaws requires caring in the first place, and most people assume positive feedback is what you want to hear anyway.
The problem is it's often the devs themselves who request the siloing. I used to assume otherwise, as I think the way you do. And then I had a lot of my devs rebelling because I was keeping them from their "real work" by having them deal with users.
> The problem is it's often the devs themselves who request the siloing
I used to be this developer.
The more the development team complains, the more valuable the system is. If there is never any friction between the developers and customers, it's likely that everyone is on the same page and the meeting is largely redundant.
I just call them not great developers. The users pay your fat salary and you yourself are a user for everything else in the world and at all other times. It's not some icky burden to talk to them or let them talk to you, it's the job. If you don't like the job, then you don't like the job, and should not be doing the job.
I don't have a lot of patience or sympathy for this attitude even though it's practically universal. There might be a few legitimate cases where someone basically has a handicap where they are clinically incapable, but then that's a handicap like a broken leg. A defect. Maybe it's ok to make allowances for them in the name of equality but it's absolutely making allowances, and should not be a norm and should not be something just everyone gets to claim for their mere comfort and convenience. IMO anyway if I were king and all that.
Maybe, but check if there's another level to it: is it because their performance review is based on metrics for which meeting with customers is a hindrance?
If I'm graded on getting tickets done or getting some feature out, then meeting with users may be beneficial and the right thing to do but incentives turn it into swimming upstream...
Agreed. I find it really fun to work with customers. It keeps you focused on real problems. And there are so many problems in 'boring' industries that need solving. Just a ridiculous number. There's so much bad software out there, or things being done manually, still now so many decades into the industry.
But you have to be willing to break out of the bubble, including getting on a plane, and I see very few people being willing to do that.
More actual interaction between end-users and programmers makes the end-users better at reporting bugs and describing what they want (and at having an idea how complex a certain request actually is).
Because the multiple translations from customer wish to project manager language to backlog items are all lossy.
Software that is not about the user and more about the developers or the providers struggles with alignment and optimizing for the outcomes of the user instead of their own.
> 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.
But... but what would Project Managers do, then?
Anyway the key thing for any software developer AND Project Managers to do is regularly work first level helpdesk.
What would Project Managers do? Manage backlog. Set priorities. See that the one customer gripe from someone's eccentric old Uncle George does not re-architect the entire UI, no matter how fervently Uncle George believes in it. Do the same as the previous sentence, when "Uncle George" is in upper management.
I disagree - it’s best never to talk to users because they have no idea what good quality is and will constantly push you to implement stupid features that only they uniquely need because of their fucked up business practices.
Or weaken your security so it works with their fucked up legacy firewall that cant ever be changed and so on.
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.
Or, it's greasing the wheels of free-association until people skid out of control.
And since the 'world' of the chat is mostly epistemologically closed (except for Web search), there's no absolute tether point. Everything's subjective, and self-confirming.
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?
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."
Reminds me of this 2014 post "Programming Sucks" [0], which has some similarities in that both posit a disconnect from reality.
> 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.
> Not in the "wash your hands every thirty minutes like Howard Hughes" kind of way,
Hold on, this isn't that crazy in today's day and age. I used to wash my hands basically only when using the restroom or before eating. Since the pandemic though, I started upping that a lot (not every 30 minutes, but pretty frequently) and since then almost never get sick.
The Cochrane review of "physical interventions to interrupt or reduce the spread of respiratory viruses" that infamously does not find a significant effect for masking does find significant effects for hand washing.
> We are uncertain whether wearing masks or N95/P2 respirators helps to slow the spread of respiratory viruses based on the studies we assessed.
> Hand hygiene programmes may help to slow the spread of respiratory viruses.
> There is uncertainty about the effects of face masks. The low to moderate certainty of evidence means our confidence in the effect estimate is limited, and that the true effect may be different from the observed estimate of the effect.
> Hand hygiene is likely to modestly reduce the burden of respiratory illness, and although this effect was also present when ILI [influenza-like illnesses] and laboratory‐confirmed influenza were analysed separately, it was not found to be a significant difference for the latter two outcomes.
> Our confidence in these results is generally low to moderate for the subjective outcomes related to respiratory illness, but moderate for the more precisely defined laboratory‐confirmed respiratory virus infection, related to masks and N95/P2 respirators.
> Relatively low numbers of people followed the guidance about wearing masks or about hand hygiene, which may have affected the results of the studies.
Anecdote: During the pandemic I added washing my hands every time I get back to my office building (and specifically after interacting with surfaces the public interacts with) to my usual hand washing (after bathrooms and before eating, just like you). I keep a towel in my hand for any door handles between the restroom and my office door. Since doing this I feel like I've noticed fewer illnesses, too.
This is exactly why I think this article is wrong: it starts with a false premise that devs are sane to begin with (not because you're right or wrong re hand washing but because this is an insane thing to focus on from the article).
I wanted the author to see how this relates elsewhere and identify the forces at work.
The solution is not just "do only what's needed by the customer".
There are emerging environments where the conditions don't force previously-rational decisions, and where assumptions no longer apply. New tools in the battlefields of yore, new beliefs and practices in cultures...
The stunning march of compute hardware in the last 50 years has changed many such conditions.
Those who work with new freedom - liberated from the strictures of old gods, able to harm enemies without putting themselves at risk, with the time freed from foraging to build - have to identify the new constraints and conditions at work.
And sometimes to make the conditions that make for sanity: Solon got ancient Greece out of a stagnating pickle by getting the wealthy to release the poor from debtors' jails but sign them up for the military that could defend lands and trade routes, if they subjected themselves to land-owner self-government and the annual ostracism of one person who went too far.
Capitalism used competitive markets to liberate but discipline business, but right now the scaling power of compute leads to winner-take-all, and the openness of the West is seeding closed systems (military or foreign) with the power to destroy the liberal governance that sustains it. In software we're stuck between Scylla and Charybdis: an Anthropic+OpenAI duopoly or Chinese control over the lifeblood of enterprise.
If there were someone who in the large had structured the freedom of software to make its practitioners and stakeholders sane, they'd be a good candidate to steer us through this situation, so this freedom wouldn't drive us insane.
ya, almost every app is over-opinionated on design and only getting worse not better in most case, iOS 26 is perhaps the most egregious mass-market example
thinking to this day afaik still can't change width of first column on Monday.com even tho they claim to replace spreadsheets and only js console will fix
or Trello going the opposite direction of former CTO when any page specifically had sub-second load target. now many seconds, that insane auto markdown editor showing up on almost all input boxes except HN that can't disable no chatgpt i dont want automated bullets i wanted plaintext so can c/p etc.
Beautifully written post and true on many levels. The art of software stopped being an art once large amounts of capital started creeping in. There are no signs that we're returning to sanity any time soon.
As a founder of a few software startups, I agree with this. If I can give advice to other founders, remember than software is usually a means to an end, and for most users, they just want the bare bone essentials to work and work well. Everything else is nice-to-have-fluff that won't drive 99% of sales.
The apps I pay for are simple and focus on a super basic interface. BookFusion and Libro.fm are great examples.
It’s interesting because my experience is inverse (b2b software) - the bloated shiny solution what actually doesnt work at all performs better in the market than the sober, unsexy solution that just works.
Companies like Oracle or Microsoft are so massive not because they sell simple and focused products that work well; quite the opposite
Might be different when you’re selling to endusers
Oracle (and SAP and IBM) are not in the business of building software, they are in the business of never complete software, instead stretch the project as far as you can and bill to death.
The insanity the author is describing sounds like normal corporate BS to me. Everybody wants to "raise concerns," everybody is looking for an idea to take credit for, everybody has a reason your idea won't succeed. I'm pretty sure this is the same whether you're making software or advertising campaigns or plastic cups.
I once tried to explain a pointless debate over the definitions of "acceptance testing" versus "regression testing" to a non-tech person, and they said that was the most relatable thing I'd ever told them about my job.
I’ve always thought that this principle explains all sorts of cultural phenomena, from the tech industry having a poorer work-balance compared to others (the pace of development is only limited by how many hours you must sleep!) and programmers seemingly having worse engineer’s disease than in other disciplines (if software can do anything and know everything, how could we, the lever-makers, be any less than our creations?).
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.
Talking to the users, allowing them to show you what they are trying to do with your software, almost feels like cheating, because of how easy things suddenly appear to be when uncertainty fades away.
Obviously, the number of uniquely different users has an influence, and users most often do not truly know what they need, but that's our job to tease appart.
Turns out the users most often benefits from small changes that reduces friction toward achieving their goal. Any time saving will be appreciated, but only if it can be trusted to work. Nothing worse than the dread of knowing an action might or might not work randomly.
I use most software today with a constant sense of fear that the next action will break something and waste my time. Undo probably doesn't work properly anyways
"What problem are we trying to solve?" is a question I have to ask constantly in corporate development environments, and rarely does anyone presenting the task to be done actually know the answer!
It's very frustrating.
It can be the case that people don't want to accidentally mis-state the problem, or get into a debate about the problem because they know people will chime in about nonessentials. I would recommend "Have we written down the problem we are trying to solve? I'd like to understand more." And get it written down if it isn't already.
Trying to position the conversation as "we're on the same team, trying to figure the problem out together" also helps a lot of the intensity of these conversations melt away.
> Working with the customer sometimes sucks.
Sometimes it sucks, but often it's awesome. I love seeing people use what I built for them. It was also very enlightening doing prototyping and watching the customers use it. Often they would ask for something that they didn't realize they didn't actually want until they used it. Working directly with them saved potentially months of building out features that would never be used.
Absolutely. I think that over-reliance on analytics has had a similar effect; compared to relying primarily on proper usability research and in-person user studies, doing that creates a detachment and distance that further removes the project from reality.
How great the impact is depends on how management uses the data. If they use it add resolution to broad strokes from studies and the like, there may be no negative impact at all, but in my experience it's much, much more common for management to read analytics like tea leaves and interpret it in whatever way best fits the individual's/team's biases/agendas.
>> I think that over-reliance on analytics has had a similar effect
I lost track of how many times the directors would tell us, "Since the analytics say A, we should do B." then the research person says, "Sure Jim, great idea, lets get a few rounds of useability research and confirm it first."
Then the always predictable thing happens: Users never align with your analytics. Seeing data and seeing someone struggling to do something basic with your interface is totally different. When directors see these videos, it really makes them see how important research is and not just relying on data to make decisions. Right now, anything the research team wants, they usually get - its had that profound of an impact on our leadership team.
> Users never align with your analytics.
Any good theories for how this happens (i.e. why the data fails to capture the struggle)?
Simple example: feature X is rarely used (thus we should get rid of it)
Hold on, why is it rarely used?
Is it hard to use? Is it hard to find? Was it poorly named? Does it work right? Does it get me 80% of the way there? Does it get me 20% of the way there? Do I rarely need it but when I do need it it's a huge time saver? Am I hesitant to depend on it because I fear it will be taken away in a future update?
> Simple example: feature X is rarely used (thus we should get rid of it)
Oh man, I remember a very specific example of this: many years ago now, Google Chrome pushed an update that got rid of the option on the menu bar for "Close Tabs to the Right". I remember looking into the Google issue tracker where people were complaining, and some PM provided a "data-driven" justification: when people opened the context menu, they only clicked on the "Close Tabs to the Right" option 1-2% of the time.
It's a great example of why data without context can give you the wrong answer. Of course the option is used relatively very rarely; you only need to clear out your tabs every once in a while, compared to creating new ones or managing tab groups! But it's still an essential task. It's like saying filing your taxes isn't important because you only need to do it 0.2% days of the year.
For what it's worth, I definitely don't organize my tabs in a way where "close to the right" would be helpful in cleaning them up.
Conversely: Feature X is often used... Because to drive adoption someone made it mandatory for a certain workflow and it nags everyone else so they "engage" with it just enough to make it go away. (Looking at you, "AI" buttons...)
And following this, I'm sure we've all seen the pattern of manufacturing the data required to justify the removal of features. Bury feature → usage numbers tank → oh hey look nobody uses this any more, guess we can safely cut it!
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;)
"What if I made X?" is basically Product Development Antipattern #1. Most feedback you get here is incredibly low signal. The stakeholder you're talking to isn't a technical person in all likelihood, so they probably aren't visualizing what you're describing in the same way you are. There is a high probability that they are telling you it sounds great as social lubricant or because they don't really understand what you are talking about and don't want to look dumb. Not to mention that positive response is the path of least resistance for most people -- the hard work of thinking critically about an idea so that you can locate potential flaws requires caring in the first place, and most people assume positive feedback is what you want to hear anyway.
The problem is it's often the devs themselves who request the siloing. I used to assume otherwise, as I think the way you do. And then I had a lot of my devs rebelling because I was keeping them from their "real work" by having them deal with users.
> The problem is it's often the devs themselves who request the siloing
I used to be this developer.
The more the development team complains, the more valuable the system is. If there is never any friction between the developers and customers, it's likely that everyone is on the same page and the meeting is largely redundant.
I just call them not great developers. The users pay your fat salary and you yourself are a user for everything else in the world and at all other times. It's not some icky burden to talk to them or let them talk to you, it's the job. If you don't like the job, then you don't like the job, and should not be doing the job.
I don't have a lot of patience or sympathy for this attitude even though it's practically universal. There might be a few legitimate cases where someone basically has a handicap where they are clinically incapable, but then that's a handicap like a broken leg. A defect. Maybe it's ok to make allowances for them in the name of equality but it's absolutely making allowances, and should not be a norm and should not be something just everyone gets to claim for their mere comfort and convenience. IMO anyway if I were king and all that.
Maybe, but check if there's another level to it: is it because their performance review is based on metrics for which meeting with customers is a hindrance?
If I'm graded on getting tickets done or getting some feature out, then meeting with users may be beneficial and the right thing to do but incentives turn it into swimming upstream...
Agreed. I find it really fun to work with customers. It keeps you focused on real problems. And there are so many problems in 'boring' industries that need solving. Just a ridiculous number. There's so much bad software out there, or things being done manually, still now so many decades into the industry.
But you have to be willing to break out of the bubble, including getting on a plane, and I see very few people being willing to do that.
I think this goes both ways.
More actual interaction between end-users and programmers makes the end-users better at reporting bugs and describing what they want (and at having an idea how complex a certain request actually is).
Because the multiple translations from customer wish to project manager language to backlog items are all lossy.
Beautifully articulated.
Software that is not about the user and more about the developers or the providers struggles with alignment and optimizing for the outcomes of the user instead of their own.
> 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.
But... but what would Project Managers do, then?
Anyway the key thing for any software developer AND Project Managers to do is regularly work first level helpdesk.
What would Project Managers do? Manage backlog. Set priorities. See that the one customer gripe from someone's eccentric old Uncle George does not re-architect the entire UI, no matter how fervently Uncle George believes in it. Do the same as the previous sentence, when "Uncle George" is in upper management.
I disagree - it’s best never to talk to users because they have no idea what good quality is and will constantly push you to implement stupid features that only they uniquely need because of their fucked up business practices.
Or weaken your security so it works with their fucked up legacy firewall that cant ever be changed and so on.
Talking to users -> not even once.
Might be only this bad in B2B software
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.
Or, it's greasing the wheels of free-association until people skid out of control.
And since the 'world' of the chat is mostly epistemologically closed (except for Web search), there's no absolute tether point. Everything's subjective, and self-confirming.
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?
+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."
[delayed]
Reminds me of this 2014 post "Programming Sucks" [0], which has some similarities in that both posit a disconnect from reality.
> 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
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.
> Leaving things alone is an underrated engineering skill.
Truer words have never been spoken.
It’s an underrated life skill and was discovered by Lao Tsé probably around 2500 years ago
"It is often easier to not do something stupid than it is to do something smart."
> Not in the "wash your hands every thirty minutes like Howard Hughes" kind of way,
Hold on, this isn't that crazy in today's day and age. I used to wash my hands basically only when using the restroom or before eating. Since the pandemic though, I started upping that a lot (not every 30 minutes, but pretty frequently) and since then almost never get sick.
The Cochrane review of "physical interventions to interrupt or reduce the spread of respiratory viruses" that infamously does not find a significant effect for masking does find significant effects for hand washing.
It's worth noting that Cochrane reviews are normally the minimal effect sizes you'll see, as they pull in every study and hate self reported measures.
Don't get me wrong, they're my first port of call (mostly for the funnel plots), but they're one source, with their own biases.
Even that is overselling it:
https://www.cochranelibrary.com/cdsr/doi/10.1002/14651858.CD...
> Key messages
> We are uncertain whether wearing masks or N95/P2 respirators helps to slow the spread of respiratory viruses based on the studies we assessed.
> Hand hygiene programmes may help to slow the spread of respiratory viruses.
> There is uncertainty about the effects of face masks. The low to moderate certainty of evidence means our confidence in the effect estimate is limited, and that the true effect may be different from the observed estimate of the effect.
> Hand hygiene is likely to modestly reduce the burden of respiratory illness, and although this effect was also present when ILI [influenza-like illnesses] and laboratory‐confirmed influenza were analysed separately, it was not found to be a significant difference for the latter two outcomes.
> Our confidence in these results is generally low to moderate for the subjective outcomes related to respiratory illness, but moderate for the more precisely defined laboratory‐confirmed respiratory virus infection, related to masks and N95/P2 respirators.
> Relatively low numbers of people followed the guidance about wearing masks or about hand hygiene, which may have affected the results of the studies.
https://news.ycombinator.com/item?id=49608023
Not arguing one way or the other just brining up the last Hacker News conversation where it was established that dirty hands are good for you.
Anecdote: During the pandemic I added washing my hands every time I get back to my office building (and specifically after interacting with surfaces the public interacts with) to my usual hand washing (after bathrooms and before eating, just like you). I keep a towel in my hand for any door handles between the restroom and my office door. Since doing this I feel like I've noticed fewer illnesses, too.
> in today's day and age
The human world today is freer of pathogens than at any point in all history.
This is exactly why I think this article is wrong: it starts with a false premise that devs are sane to begin with (not because you're right or wrong re hand washing but because this is an insane thing to focus on from the article).
I wanted the author to see how this relates elsewhere and identify the forces at work.
The solution is not just "do only what's needed by the customer".
There are emerging environments where the conditions don't force previously-rational decisions, and where assumptions no longer apply. New tools in the battlefields of yore, new beliefs and practices in cultures...
The stunning march of compute hardware in the last 50 years has changed many such conditions.
Those who work with new freedom - liberated from the strictures of old gods, able to harm enemies without putting themselves at risk, with the time freed from foraging to build - have to identify the new constraints and conditions at work.
And sometimes to make the conditions that make for sanity: Solon got ancient Greece out of a stagnating pickle by getting the wealthy to release the poor from debtors' jails but sign them up for the military that could defend lands and trade routes, if they subjected themselves to land-owner self-government and the annual ostracism of one person who went too far.
Capitalism used competitive markets to liberate but discipline business, but right now the scaling power of compute leads to winner-take-all, and the openness of the West is seeding closed systems (military or foreign) with the power to destroy the liberal governance that sustains it. In software we're stuck between Scylla and Charybdis: an Anthropic+OpenAI duopoly or Chinese control over the lifeblood of enterprise.
If there were someone who in the large had structured the freedom of software to make its practitioners and stakeholders sane, they'd be a good candidate to steer us through this situation, so this freedom wouldn't drive us insane.
Oh, Nice reading :)
> Everything becomes urgent because everything can move quickly
I finally understand why I quit my previous job.
ya, almost every app is over-opinionated on design and only getting worse not better in most case, iOS 26 is perhaps the most egregious mass-market example
thinking to this day afaik still can't change width of first column on Monday.com even tho they claim to replace spreadsheets and only js console will fix
or Trello going the opposite direction of former CTO when any page specifically had sub-second load target. now many seconds, that insane auto markdown editor showing up on almost all input boxes except HN that can't disable no chatgpt i dont want automated bullets i wanted plaintext so can c/p etc.
Beautifully written post and true on many levels. The art of software stopped being an art once large amounts of capital started creeping in. There are no signs that we're returning to sanity any time soon.
As a founder of a few software startups, I agree with this. If I can give advice to other founders, remember than software is usually a means to an end, and for most users, they just want the bare bone essentials to work and work well. Everything else is nice-to-have-fluff that won't drive 99% of sales.
The apps I pay for are simple and focus on a super basic interface. BookFusion and Libro.fm are great examples.
It’s interesting because my experience is inverse (b2b software) - the bloated shiny solution what actually doesnt work at all performs better in the market than the sober, unsexy solution that just works.
Companies like Oracle or Microsoft are so massive not because they sell simple and focused products that work well; quite the opposite
Might be different when you’re selling to endusers
Oracle (and SAP and IBM) are not in the business of building software, they are in the business of never complete software, instead stretch the project as far as you can and bill to death.
The insanity the author is describing sounds like normal corporate BS to me. Everybody wants to "raise concerns," everybody is looking for an idea to take credit for, everybody has a reason your idea won't succeed. I'm pretty sure this is the same whether you're making software or advertising campaigns or plastic cups.
I once tried to explain a pointless debate over the definitions of "acceptance testing" versus "regression testing" to a non-tech person, and they said that was the most relatable thing I'd ever told them about my job.
I’ve always thought that this principle explains all sorts of cultural phenomena, from the tech industry having a poorer work-balance compared to others (the pace of development is only limited by how many hours you must sleep!) and programmers seemingly having worse engineer’s disease than in other disciplines (if software can do anything and know everything, how could we, the lever-makers, be any less than our creations?).
windows adbloat and 15 corporate software policies and scanners drive people insane