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!
I try to remember to say something like this: "This is an interesting solution, but I'm not confident we have a shared understanding of the problem we're solving. I have a few guesses, but I don't want to bias the discussion, so please restate the problem without suggesting a solution. If it's too difficult to explain, I can suggest what problems I think you might be running into." I wish I always remembered to say that. :-)
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.
This is likely the start to a useful approach. I suspect the crux of the challenge is that engineers who need to write code get very pedantic in their questions and picking the answers apart (because we need to be! code leaves no room for ambiguity or intuition). And you can imagine how that feels from the other side. I imagine a lot of people feel like an engineer asking about the actual problem feels like getting goaded into some sort of pedantic debate. A natural response will be to try to dictate what to build (often micromanaging) and avoid the discussion about why at all costs. Writing offers a bit of a neutralizing buffer, at least.
> I imagine a lot of people feel like an engineer asking about the actual problem feels like getting goaded into some sort of pedantic debate.
Wow, that's describing it really well. I work for a guy who basically started a company by trying to vibe code his ideas into existence (late 2023 LLMs) and realized he would need actual developers to get anywhere.
It was excruciating trying to make him answer questions to get proper domain modelling going since LLM use had made him think of software as being wished into existence in a "declarative" way.
Not to mention the heavy contrast my persistent questioning had to a background of sycophantic yes-man claudespeak.
I was really wondering what these replies were talking about until this one - when I remembered a guy I used to work for that was just like this.
I think I have been pretty lucky the last 5-6 years of my career at least, where someone asking those questions is treated as trying to drive the team to a better result, rather than a pedant.
You are correct. You ask that if you want to get promoted to a better job, because you understood the problem and likely saved the company money, time, effort or all three, rather than just pushing the buttons like a good code monkey.
I don’t know what job you think I have, but my job is to identify and implement solutions to problems, not figure what problems exist from someone else’s contrived answer to the problem.
That’s the job we all want to have, but it doesn’t exist. It’d be nice to say you are the lone outlier here but unless the previous comment was completely made up we know that’s not the case.
You can't always change your circumstances, but if you work to make little changes to improve your environment, the people that work with you probably will too.
My current team is like that - we all see the roadblocks that make our job harder, and we know we can't solve them all, but we talk about and work on making our own solutions to get around those things - like making a habit of asking those questions to better understand what's really desired by the stakeholder.
I has only been approximately 11 hours since your job was expressed to be quite different. I am glad that you recognized the source of your frustration and managed to turn your situation around — and so quickly at that! — but be aware that it is still early days. Temporary aberrations are common in the workplace.
I don't know what kind of things you are inferring from my comments, but they are quite clear and do not contradict eachother. I'll ask you to stick to the literal text of my words rather than guessing new meanings for them if you want to discuss them with me further!
No need to guess new meanings. The message was loud and clear:
'"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.'
We talked about that for a bit, and then, only hours later, we got:
"Your job doesn't have to be that way."
So, again, I am glad you realized you have the power to change your world and did so. But, again, know that there were only hours between your job being a complete frustrating mess and it ostensibly becoming a well functioning system so there is not yet any evidence of it being a long-lived change. People can modify their behaviour momentarily but old habits die hard.
I am not sure what is confusing you here, but just to be clear: I have been working as a developer for about 15 years. I have not worked for the same company that entire time.
The confusion is in the story changing each time. At one point you earlier asked us to take the literal text of the words, but in that text there is no literal mention of one company. It also literally asserts that you are currently frustrated ("It [is] very frustrating", not "It was very frustrating").
Now this seems to imply, to the best of my interpretation, that you only experienced that job at a single company some time in the past. Okay. But where did you think that was found in the earlier text? As far as I can see this is new information. And why are you still (at time of writing that comment, at least) frustrated by something that you are now suggesting, as best I can tell, was already no longer a part of your life and, given you finding significance in noting that you've done this for 15 years, likely hasn't been for a long time?
I’m not sure why you’ve taken so much offense and made so many aggressive replies to being told that you misunderstood something, but again - none of my comments are contradictory.
You have repeatedly confused yourself by assigning your own meanings to my words instead of asking for clarity where you didn’t understand.
I think that most people who read my comments understood that I am speaking broadly about my career, and that while I’ve encountered this problem at my current job, my team and I have worked to make it better.
Your primary issue comes from the fact that you asserted that my frustrations with corporate development are in fact the real job, and your seeming offense at being told that no, your negativity and hostility are not a universally shared experience.
I hope things get better for you in your career, but please stop harassing others for not succumbing to cynicism.
> You have repeatedly confused yourself by assigning your own meanings to my words
As instructed, the words were taken literally. Now that you are telling us that we actually needed to read between the lines to understand what you really meant is informative, but curiously late to make that known, especially in light of earlier instructions.
> and your seeming offense at being told that no, your negativity and hostility are not a universally shared experience.
Uh, what? That doesn't make any sense. If I were offended or felt negativity or hostility I would have turned off the computer and went outside. This is a completely voluntary time use. It had better be good. The fact that I am still here proves that there is no negative emotion felt whatsoever because the instant there is anything else I'm gone. Presumably the same holds for you because there is no rational explanation, assuming you are of sound mind, why you wouldn't have equally found something better to do if there was anything unpleasant experienced on your end.
I guess this is supposed to be another case where we cannot take what you have written literally?
i consider a sign of maturity in myself that i always defer to adapting my software to fit how the user is trying to interact with it. the sign of immaturity is that my deference masks internally screaming, "why would you want that!? why would ANYONE want that!?"
my "customers always right" approach has produced much more successful and useful software compared to my perfect little hobby projects which will never be complete and noone would ever use anyway
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.
My problem is I can skip all those steps and 8 separate meetings by applying a little common sense to software design.
Unfortunately, orgs often treat devs like this as indulgent or wasting time. They need it to be done the inefficient way because that's the only way they have visibility and control.
Yes. And in most of those meetings where the researcher invalidated the leaders, the leaders have left the meeting saying (and thinking? I’m not sure) they were validated. So because of the leaders we have we should skip the meetings and research in both cases.
Analytics don’t capture the “why” of what they measure, on the user side. Indicators may move in the seemingly right direction for the wrong reasons. Analytics typically can’t tell you what the user wanted to achieve. Knowing the “why” gives a better basis to decide on what changes to try, or to realize what’s actually wrong with the user-facing side of things. Another reason is that they tend to measure an average where in reality there is no average user.
I think the answer to this is roughly ... the content of an applied statistics degree, or a research methodology practicum. There are so, so many ways that quantitative measurement of human phenomena can mislead, from measurement error to conflation between trends/sample sizes/effect sizes, to p-hacking, to good old bias (in interpretation or in deciding what tools to use to smooth or normalize data), and thousands more.
Eg, if you have a bunch of airplanes returning from a war, you might be tempted to armor the areas where they were hit. But you want to armor planes where the holes arent because those are the critical areas.
If you can read literal bullet holes backwards, hundred dimensional preference vectors say something, but we generally have no clue.
I think it's because a lot of analytics are data points oriented instead of being workflow oriented. So you can see that feature A is not being used a lot, but it's very important in a particular flow. Feature B may be used a lot, but it can be only important for a particular class of users while very detrimental mentally for another class.
People use software for a needs, but rarely I've seen a need being highlighted when interpreting analytics data.
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.
I do all the time because the feature exists. I would treat it like a sliding line in my tabs bar. When I'm done with a tab for now it goes to the right, and eventually everything to the right gets closed once I haven't used it in a while
I do. I open a search page, middle click a bunch of links, then want to close all of the ones to the right because I found one that told me what I needed and don't need the rest of them.
It's useful when starting a thread of research of research as new tabs will be opened to the right (Ctrl+Clicking a link). So after it's done, close to the right can be quite useful.
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!
> I think that over-reliance on analytics has had a similar effect;
The over reliance on analytics combine with a lack of metrics and proper accounting.
If you are renting all your infrastructure knowing how people use your app, and what the COSTS of that are is kind of a big deal. If your high dollar client is your lowest margin one, thats a problem that is technical and financial as well as a product insight.
And that infrastructure your renting, it stopped making sense for a lot of orgs to do that almost a decade ago, but here we are where everything is in the cloud because capacity planning is a lost art and was a great throttle on the insanity that the post is describing.
For 2 larger projects I'm on, I'm both the developer and a user: on a regular basis I use the software myself. And not just for one-off tests. I really use it the way other users use it.
This has provided rather deep and interesting insights in software development for these particular products and in general. Or in OP's lingo: not a lot of potential for insanity at all. Because any new idea immediately gets regarded on 2 fronts: what does it take to implement and what does it really do for the user.
I find that if people don't dogfood their software the software just ends up being shit.
As engineers we need to be a little grumpy. Frustrating with our software provide directions to improve it. If we're not grumpy, we don't know what to fix.
But some of this also comes from top down. Engineers also need the freedom to fix things. They're the experts. Management Also shouldn't interpret that frustration in quality as the engineer being a thorn in their side. It means the engineer cares and is willing to remove the thorns in their side. But I think there's a strong natural tendency in any organization to surround yourself with yes men. They're sneaky, telling you no when you ask them to. Maybe a reason management loves LLMs so much
At very large $companyIUsedToWorkFor, the accessibility features got a lot better once we hired a blind developer. Once it went from "we have to pass this test" as our only feedback to "Bob did this because it confused his text-to-speech program when he was looking for another bug" we got such a great success flywheel going. Very quick feedback cycles really is required for successful software development.
At my friend's org, they like it to suck bc that reminds them they are doing the very sophisticated work of dogfooding. No one told them they're allowed/supposed to feel good making/using the sw...
"We want to feel the same pain the customer feels" is shortened to "we want to feel pain." Instead of "neither we nor the customer feel pain."
In my experience, this is the only kind of software that ends up not sucking. If development is not driven by users in a very intimate way -- like being one and the same person -- then you routinely end up with necessary features only half working or splitting essential information across multiple screens or dialogs. Eating your own dog food is essential to rising above that, because only that reality will overwhelm the developers sense of the "proper" way to do things.
I believe it's the major reason that industry specific information systems are universally shitty. The user can't articulate what they need to accomplish and the developer doesn't really understand the purpose or importance of the work. Result is bad functioning or bad interface.
It's why only software like text editors and web browsers gets to be really good. Huge user base. Lots of developers involved.
Git kinda proves that it's not infallible, though.
> It's why only software like text editors and web browsers gets to be really good. Huge user base. Lots of developers involved.
There's lots of great software out there that you interact with every day that was written by a small number of developers to clear requirements. Your car ABS brakes. Your coffee maker. Your brushless drill. Your TV remote. Think of the fact that majority of the microprocessors and microcontrollers that you interact with every day have software that you never think about, because it just works and gets out of the way. (And think of the cases -- maybe your dishwasher, your smoke detector, whatever -- where that's not the case! It really drives home how incredibly pleasant just-works-without-thought really is.) It's only these big, large team, overly complex systems where the expectations are so low that even the crap that is a current web browser is considered acceptable, let along "not sucking."
You're mistaking shitty software for software that doesn't work. Shitty software is 100% functional. You just hate it.
By intentionally picking the software that eliminates the UI, when the whole benefit of computers as a tool is that the UI is infinitely flexible, you're picking shitty software that doesn't appear that shitty. But it still is.
I mean, I hate the way my TV remote works and have wanted to change it. But I can't. It has buttons that open NetFlix or Apple TV that I can't change, and I don't have any ability to reprogram them because the companies paid for it to be a permanent advertisement I can't get rid of. That sucks.
But also, I think we only have to look far for what shitty appliance software looks like. VCRs and microwaves are notorious for having shitty software. As soon as we introduce a network, suddenly the software sucking is an immediate problem: witness the nightmare stories of Jeep updates, Tesla lockouts, and paywall feature locks when the hardware is present. Or we can look at the spying done by LG that you can't turn off. Or the forced advertising that Samsung showed they can do to your fridge.
Or how automobiles need an OBD reader even thought they ship with a built-in tablet. Or how the OBD codes are something you have to pay for. Or how you might not be able to disable the stupid "shut the car off" feature when you stop at a red light.
Shitty software on microcontrollers is some of the most tyrannical shitty software there is.
> when the whole benefit of computers as a tool is that the UI is infinitely flexible
I think this statement is insane. The benefit of computers is that they allow complex behaviors to be defined and implemented. The benefit of software is that it’s the lowest-NRE way of defining those complex behaviors. UI doesn’t come into it, except in a few edge cases like desktop computers, phones, appliances, etc. A climate model’s “benefit” comes from its output, not the form in which it generates output or takes input.
Okay, I don't really feel like your going for a good faith interpretation of the points I'm trying to make. You're taking things hyper literally and out of context. I don't feel like you're really trying to understand what I'm saying at all.
> It's why only software like [...] web browsers gets to be really good.
Huh? Web browsers are still laughably bad even after all these years. They are engineering marvels, certainly, but using them leaves a lot to be desired. I cannot imagine anyone would voluntarily use them if the ultimate function was equally available another way.
You mean installing the Reddit, X and Instagram apps on my phone? I use them in the browser because the browser is so terrible they don't spy on me as much.
That's absolutely splendid. In the user role, I get very irritated when programs do stupid things or interface elements don't do what they're supposed to do. Muttering to myself I'm asking a question: have the developers ever actually used this program? I'm convinced had they used it for real, there would be far less idiocy users have to deal with.
Your approach to developing software goes a long way to producing software that users appreciate. OTOH users may have no opinion about software sufficiently intuitive to use that it fails to bring attention to itself. Such transparency is an outcome developers should be proud to achieve.
Dogfooding is useful certainly but it can also be a trap, as someone who is technical and knows how the software works both sides you can fall into the trap of avoiding triggering the exact kind of issues a regular user can walk into.
Your conceptual model of how things work is going to be different to that persons and it is a very hard trap not to fall into.
Indeed. Some of the worst software interfaces I've ever dealt with were fully "dogfooded" and that was the cause; the people writing the software did use it every day but (a) in a very idiosyncratic way and (b) in a specific, very constrained environment.
The devs did use the software, but used it in such a different way from everyone else that when the devs optimized for their own case, it made the software actively worse for everyone else.
Indeed, it's a lesson I learnt the hard way and is much like proofreading something you wrote, you don't see the errors as easily as someone else you asked to proofread it usually does (well until you hit Send then you usually see all of them instantly).
This is something I've asked repeatedly at my job. Current team builds services for other developers to use, okay, do we also use it so we can go th ough all the same pain points as them? Why not?!
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.
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...
I live in Finland, where in "product companies" developers don't always speak great English. Or they might not speak Finnish if they're immigrants. So the employer wants to pick and choose product managers that they think are "presentable" enough in terms of linguistic or social competence to put directly in front of a customer. They seem to value this high enough that they are willing to take the productivity hit from the indirection.
Product manager skills do not overlap much with dev skills.
If I put some devs in front of a customer I'd be very much afraid of them doing what they ask rather than what they want, for instance, or overindexing on one particular customer's problem.
If the devs understand and can empathise with the users and there aren't a lot of them, sure, maybe but on most projects it's more effective to have the distilled and filtered customer feedback from a PM who is good at being a PM.
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.
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.
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.
Oh boy, I do mostly agree with you but this applies well if you’re making software for the fellow SWEs. While a lot of them can be an annoying bunch, once you’re making something for general consumption, like let’s say running an e-commerce platform, interacting with your end users could be probably better compared to a front desk/service industry job. It’s very hard to keep that positive attitude then.
The stakeholders should be held accountable to this. C level and PMs. Otherwise they just push what they believe will be better, no matter what developers say.
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.
When the user is understood as yet another human who doesn’t know what they want, the insanity returns! Because an average customer usually doesn’t have practically grounded wants.
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.
Not sure on this, a lot of time I know better but the customer insists we do it their way and it's usually because they are lazy to improve on their end.
I've had more than one half-serious conversation with SVPs here that every staff/architect level engineer should have to spend at least 6 months working on the engineering team that directly interacts with the largest customers.
I flat out guarantee they'll come away with a wildly different perspective of the things that need done, and the ways their service operates.
Ideally I'd want them to do a rotation in customer support so they get the small customer perspective too, and at least learn what kind of paper cuts they're inflicting on customers.
> 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.
Sure. Now, how to deal with the entirely plausible situation where there needs not be any separation between the developer and the customer at all, thanks to AI.
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.
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.
> 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.
I feel for you. We didn't know how good we had it. Wooed by multiple companies right out of university, good salary, comfortable, fulfilling work (some nights though), fast path to car and home ownership and long term financial security. Few rules/restrictions more perks compared to other professions. We were spoiled. Perhaps this is why the current crop of tech leaders are behaving like spoiled brats.
I resemble that remark. The trouble is that I'm now too old and if I ever lose my job, I'll never find another one. No one hiring in tech wants the greybeards.
Getting the kids to insist they be paid what their contributions are worth would raise the boat for all developers. Of course that would take some sort of big bad union, which the oligarch vc asshats really don't like.
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.
> coworkers that literally committed zero code for months
That's awesome
I would much prefer to have coworkers that literally commit zero code than the monkeys I sometimes work with who commit way too much code, or just plain commit the wrong code
I don't think it's because of the 'average developer', but because system's like OP's were designed by experienced engineers, while the modern toolchain is written by "senior developers" with 3 years of experience. They have a lot of energy to pull all-nighters reinventing yet another wheel, and not the wisdom to avoid doing that, or to do it in a sensible way.
In fact, the entire tech sector, favouring fresh grads out of college over greybeards, is built this way. My pet very controversial theory is that this phenomenon is massively fueled by everybody and their dog using ADHD stimulant medication to get through their day; fresh grads + amphetamines is the preceding step to Kubernetes and the entire React ecosystem.
tl;dr: modern software is built by 'work hard, not smart' kinda types.
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.
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.
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."
Similar to "needs to be a platform" [0], another variant is "be a data company" where somehow the underpants gnomes will transform your moat of stored information into profit.
[0] Read: "Needs to be pitch-able to investors as a magical 1000x growth unicorn."
Google already had the machine, this was just feeding the machine. 99% of companies do not have this machinery in place and probably wouldn't know where to start.
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.
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.
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.
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.
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.
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.
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.
The peak of human civilization, for me, was downloading Shrike and actually having it work "out of the box". If an absolute moron like me could get that to boot up with next to no involvement or fudging through the user manual, I knew then that the tide had turned.
The Internet doesn't make people dumber any more than video games, rock music, picaresque novels, the printing press, or writing did. These kinds of arguments come around with every new technology and have always been fatuous.
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!")
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.
> But, harsh as it may be: most software is still just a glorified spreadsheet.
Think the author means most back-end software is a glorified spreadsheet (CRUD app with a few sorting algorithms).
The last 10-20 years in software has been more about new device interfaces, improving UI/UX, and networking technologies. I think of things like streaming, 3D games, live chat, video content, mobile apps, and LLMs.
Anyone who thinks about software like that would not instill confidence in me that they make very good software.
> You can watch sensible people argue for an hour over a button because, somewhere deep inside the conversation, the button has become connected to a future pile of money.
> It means understanding that not every problem is existential, not every idea belongs on the roadmap, and not every abstraction deserves to exist.
> waste away in Margaritaville tinkering with shit that doesn't need tinkering with.
I don't really understand what each paragraph has to do with each other, or why this message is being shared with me today.
I don't even mind that style of writing, but it should be more specific and interesting if it's going to be stream of consciousness style like that (IMO). To do all that, and deliver just vague half-points and boring assertions, felt like I was just waiting for some kind of punchline or point to be made that I could nod my head at but no thought was stuck with long enough.
The conclusion was like they tried to come up with anything just to turn the essay in on time.
This was written at a really easy level. It was not at all hard to understand. Disagreeing with something and not understand it are very different but often the latter is feigned to make the writing seem written by an inferior. It's kinda like an ad hominem attack. (≧▽≦)
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'm starting to believe computer work and screens make me lose touch with reality and dissociate. I remember starting an apprenticeship as a dev in 2015 and I saw a guy like me, but 2 years in, with deep eye bags and he just smiled, didnt say anything and he looked extremely exhausted. Well 11 years later and here we are, we are all tethered to this mess
My career in software development happened back in the days of MS-DOS, before Windows really took hold. I developed a system that recorded the inspection of Fire Safety equipment like Fire Extinguishers, Hoses, etc. My initial estimate for the time required to build the system was 2 months, it actually took 3. Then the client looked at it, and it met all the requirements, but was unusable in practice. I then worked onsite for a year, and learned so much about software usability by seeing it in use. After that year, we deployed it to 10 other sites.
Other than having a summer intern once, it was a solo effort. The code was written in Turbo Pascal, with some code on the hand-held computers written in a language called PL/N. (A variant of PL/1 for the Norand corporation handhelds)
I wrote all my own text editing/forms handling libraries, and everything else I needed. Version control was using pkZip to archive the source code onto 3.5" floppy disks.
Tying it back to the article in question, I can't imagine what it's been like with the push for "sprints" and all the rest in software development over the past few decades. I can see how it would drive you to burnout. I'm very thankful I missed it.
Sprint is a terrible misnomer, it should be iteration. It's about seeing work as a series of opportunities to gather feedback and apply the learnings to the way future work is done.
> 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).
The article had me at "[...] every new feature is the one that's going to be the one (but certainly not that one that was supposed to be the one during the previous sprint)".
I have fought way too many times the new "the one" feature. Just ship it, it's already good enough, everything else just adds cost, especially psychological cost to the team.
The part that the cost of changing software is unknown, ignored and fixed is not true anymore.
This is a thing I realized recently.
A company cannot get free (o low cost) software changes anymore. Someone invented llms and they charge by work produced (useful or not)
So a PM cannot "save" costs by pushing. The employees will resort to their agents and there will be cost. If there is no agent, another company will beat them.
So now a change has a measurable cost and even you can calculate in what was spent (agent logs)
Since software is less constrained by physical resources and has low perceived friction for change, it's easy to adopt a development strategy based on the common ideas that "more is better" and that continuous change is inherently good.
But things don't have to be this way. Buttons moving around after every update isn't inevitable. AI-assistants in text editors aren't inevitable either. I use and love xfce, for example
I don't usually dig these little tirade blog posts but I genuinely laughed, related, and enjoyed this one.
I particularly liked this quote:
>You can watch sensible people argue for an hour over a button because, somewhere deep inside the conversation, the button has become connected to a future pile of money.
I have worked in a number of different types of jobs; from restaurants, to nursing homes, to roofing, to physics research. And finally for about 15 years I've been developing software at various companies of various sizes (Giant corporations to tiny startups). Part of what he describes is what attracted me to this industry. The feeling of being able to create something that people can actually use and might actually make money (maybe A LOT of money) was/is stimulating. Having witnessed the craziness that can come from that seed, well I just think he did a great job of explaining it. I appreciate that he tries to balance showing the insanity with the fact that there are times when the underlying driver is real. That's probably true of most insanities though. :)
Anyway, I'm not leaving the industry but I think it's really difficult for the AI agents to tell what is crazy and what isn't, so they are picking up this insane culture. (^▽^)
Seems like your actual argument is that competitive profiteering makes people insane. That is the motive here. Software is just the conduit.
As well as the people who work on software not being the ones making decisions about that work. A gap between the deciders and the laborers. Which is a result of the structure of the current micro political economy within organizations. It is not separate from it.
There is a symmetrical presumption in the minds of people that the software representation in their screens is both accurate and capable of altering reality when changed. This is very often violated, obviously, and people find it jarring.
Another related problem is people will often take software at face value. When you have an inkling of what sort of dysfunction might be behind a certain buggy behavior it is much easier to cope both by finding workarounds, deciding to wait it out (my parents had an issue with some government database and I thought it suspiciously like some change propagation issue, told them to try again next week because I assumed some reconciliation on the weekend would solve it and it did) etc.
But a lay person will see error messages and take it to mean some catastrophic bureaucratic issue with their data when it's most likely just poor quality software...
I think the expectation that software is correct, accurate, and trustworthy, drives people up the wall when they are confronted with the reality of buggy and poorly implemented systems that they are required to use to function in society.
Is it fair to say the same applies to writing? It feels like so often when I'm reading something (really anything--blog posts, essays, the news) the words I'm reading are there for their own sake, not because they need to be there.
Maybe it's because I'm reading work with a deadline, or from a half-hearted writer, or maybe it's because a lot of people have never been taught how to write well. Whatever it is, so much of writing is bad because the author hasn't done their due diligence with their purpose for writing.
Except unlike software, this fault is so prevalent and eternal that it has become the status quo.
I've been "joking" about this with my friends for a couple months now, and every day it becomes less and less of a joke--there are some very...interesting...things happening on the Twitter timeline these days.
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.
Ok, I get how you might like the ideas there, but "beautifully written"?!? Really?
The goal of writing is to communicate. That means saying what you mean to say ... and not filling paragraph after paragraph with pointless and redundant things you don't need to say.
There is not an English teacher in this world who would argue that was even a well-written essay, let alone a beautifully-written one.
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?).
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.
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.
> Moving the kitchen in software might look like a "simple fix."
Why, of course! We leave the kitchen deployment where it is, and just install a proxy kitchen facade on the other side of the house, which does everything via the original kitchen through remote procedure calls.
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.
When you know something can be changed relatively easily, say compared to a building or a car, the tendency is to do it. Especially when there is no tight feedback loop telling you what is a right and wrong move. The churn is the result of the psychology of uncertainty combined with the ability to act on that anxiety.
Shipping MVPs or minimal features quickly and seeing if they stick is a solution. Quick and dirty until you know something is worth further effort. Yes, user feedback is good but often people don’t know what they want, or think they want things they won’t actually use, and you won’t find out until it’s sitting in front of them.
And someone is always yelling that everything is taking too long, usually the same person who told their boss that something would be done by x date without asking anyone else.
Depends on what you're doing. If you're at a keyboard and there's no reason to wash them, then yes. If you're in a kitchen with ingredients sticking to your fingers, that's not enough.
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 think there's some truth to this. All those decisions and interactions at your fingertips cause dopamine release, which in excess can cause things like psychosis, paranoia, or delusions.
I feel like this post could've been either shorter or better structured.
It explores a bunch of interesting ideas, but the way they're mushed together makes it taste a bit bland.
I still don't really understand what exactly it was that this text wanted to tell me. A bunch of things? But also nothing.
I can deduce what it I think was supposed to tell me (based on extrapolating patterns and most likely talking points), but it didn't necessarily do that. _Telling_ me I mean.
Maybe leaning less into the relateable-ness would've helped there?
Or just containing it better.
__
I suppose there is a place for just stream of consciousness rambling (like this comment), but the post kinda came with the optics of "here's a statement", but then there's no real statement.
So maybe that could also have been fixed with a "Here are some not necessarily fully coherent thoughts you might find interesting" disclaimer.
Perhaps my mind is just not wired in the same way as the ones of the target audience, but if that is the case, then I am a bit offended by the blog naming itself "Graybeard".
A bit too vibey feely "that is so me omg" for that.
(The LLM I've consulted telling me that I'm just missing the point here kinda validates that hypothesis for me. Good for you then. May you all bond over this with your weird "emotional resonance" stuff. It seems to tickle the RLHF stuff just right.)
the level of observability swe's have into how their changes affect UX, revenue, costs, etc. definitely have something to do with it. that feedback loop isn't as quick in other industries.
This rings so true to me. I've had about a dozen jobs in software and exposure to another dozen through consulting, and I've generally found that the more mundane the application, the more the company's leadership and many employees had deluded themselves into thinking they were truly changing the world (a sales productivity tool in the most extreme case). Like the bigger the elephant in the room that the project was actually pretty boring, the more overcompensation there had to be.
"Drives people insane" is the interpretation of those with an external locus of control. For those with an internal locus of control it translates to "reveals character".
Here's my alternate title: people are insane, software reveals it.
Insane feels too strong, though. I believe people make sense. We just have this crazy ability to fool ourselves by spinning stories. And many of the stories we continue to spin were handed to us without our awareness.
A lot of it has to do with communications. The times I (as a programmer myself) have witnessed how companies we asked to write software tackled it was eye opening in a negative sense.
As a freelancer my process involves a lot of observation, asking questions and planning. Usually when I go into the details more questions emerge and whom to ask better than the people who do exactly this daily? Sure sometimes their process is a bad abstraction, they chose because they did not knew better and thus not worth putting into software. But before you decide that you gotta ask whether there are reasons why it was done that way. I see my task as a programmer to make peoples lives easier, by finding elegant abstractions for their problems, that are at the same time, reliable, adjustable, encourage correctness, avoid problems and so on.
Now most software companies I interacted with from the other side did none of the things. They rushed to gather the specs, asked some questions in the beginning and were out of the door to start way too fast, with some things they just assumed without confirming. Then crickets and then something half broken comes around that you need to beat into shape in an exhausting back and forth, where again you have to be the person with the questions.
If it is exhausting for a person with software development experience to be your customer, how bad will it be for people who have no such experience.
Now there are of course exceptions also in such companies, but in my experience that is mich rarer than it should be.
This resonates with me. And I think I know why software is like this. It isn't software that drives people insane, it's money that drives people insane. Specifically the promise of money breaks people's brains. They see the unicorn companies turning junior engineers into overnight millionaires, and they start salivating. They start looking for The Way. The closest thing they find to The Way is a bunch of unicorns and FAANG companies that have gone before. They start looking for talismans and ceremonies that will bring them closer to The Way. Scrum, Agile, Kanban, scalability, "web scale", 12 Factor Methodology, microservices, etc. may be good ideas but they take on real power when they're a perceived path to fortune.
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.
I try to remember to say something like this: "This is an interesting solution, but I'm not confident we have a shared understanding of the problem we're solving. I have a few guesses, but I don't want to bias the discussion, so please restate the problem without suggesting a solution. If it's too difficult to explain, I can suggest what problems I think you might be running into." I wish I always remembered to say that. :-)
Until you run into that most stubborn, "my problem is the absence of this solution" type of stakeholder...
Upper management material right there.
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.
This is likely the start to a useful approach. I suspect the crux of the challenge is that engineers who need to write code get very pedantic in their questions and picking the answers apart (because we need to be! code leaves no room for ambiguity or intuition). And you can imagine how that feels from the other side. I imagine a lot of people feel like an engineer asking about the actual problem feels like getting goaded into some sort of pedantic debate. A natural response will be to try to dictate what to build (often micromanaging) and avoid the discussion about why at all costs. Writing offers a bit of a neutralizing buffer, at least.
> I imagine a lot of people feel like an engineer asking about the actual problem feels like getting goaded into some sort of pedantic debate.
Wow, that's describing it really well. I work for a guy who basically started a company by trying to vibe code his ideas into existence (late 2023 LLMs) and realized he would need actual developers to get anywhere.
It was excruciating trying to make him answer questions to get proper domain modelling going since LLM use had made him think of software as being wished into existence in a "declarative" way.
Not to mention the heavy contrast my persistent questioning had to a background of sycophantic yes-man claudespeak.
I was really wondering what these replies were talking about until this one - when I remembered a guy I used to work for that was just like this.
I think I have been pretty lucky the last 5-6 years of my career at least, where someone asking those questions is treated as trying to drive the team to a better result, rather than a pedant.
I wouldn’t ask that if you want to keep your job.
Really?
I’ve asked that question all the time throughout my career. Lots of promotions. No firings or layoffs.
Why would you lose your job?
I wouldn’t ask that if you want to keep your job.
You are correct. You ask that if you want to get promoted to a better job, because you understood the problem and likely saved the company money, time, effort or all three, rather than just pushing the buttons like a good code monkey.
That’s a very silly statement. I’ve been asking that question for over a decade and it’s the question that makes me a better developer.
Reverse engineering the problem from someone's solution is the job. If you find it to be frustrating, you might be in the wrong profession.
I don’t know what job you think I have, but my job is to identify and implement solutions to problems, not figure what problems exist from someone else’s contrived answer to the problem.
That’s the job we all want to have, but it doesn’t exist. It’d be nice to say you are the lone outlier here but unless the previous comment was completely made up we know that’s not the case.
Your job doesn't have to be that way.
You can't always change your circumstances, but if you work to make little changes to improve your environment, the people that work with you probably will too.
My current team is like that - we all see the roadblocks that make our job harder, and we know we can't solve them all, but we talk about and work on making our own solutions to get around those things - like making a habit of asking those questions to better understand what's really desired by the stakeholder.
I has only been approximately 11 hours since your job was expressed to be quite different. I am glad that you recognized the source of your frustration and managed to turn your situation around — and so quickly at that! — but be aware that it is still early days. Temporary aberrations are common in the workplace.
I don't know what kind of things you are inferring from my comments, but they are quite clear and do not contradict eachother. I'll ask you to stick to the literal text of my words rather than guessing new meanings for them if you want to discuss them with me further!
No need to guess new meanings. The message was loud and clear:
'"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.'
We talked about that for a bit, and then, only hours later, we got:
"Your job doesn't have to be that way."
So, again, I am glad you realized you have the power to change your world and did so. But, again, know that there were only hours between your job being a complete frustrating mess and it ostensibly becoming a well functioning system so there is not yet any evidence of it being a long-lived change. People can modify their behaviour momentarily but old habits die hard.
I am not sure what is confusing you here, but just to be clear: I have been working as a developer for about 15 years. I have not worked for the same company that entire time.
The confusion is in the story changing each time. At one point you earlier asked us to take the literal text of the words, but in that text there is no literal mention of one company. It also literally asserts that you are currently frustrated ("It [is] very frustrating", not "It was very frustrating").
Now this seems to imply, to the best of my interpretation, that you only experienced that job at a single company some time in the past. Okay. But where did you think that was found in the earlier text? As far as I can see this is new information. And why are you still (at time of writing that comment, at least) frustrated by something that you are now suggesting, as best I can tell, was already no longer a part of your life and, given you finding significance in noting that you've done this for 15 years, likely hasn't been for a long time?
I’m not sure why you’ve taken so much offense and made so many aggressive replies to being told that you misunderstood something, but again - none of my comments are contradictory.
You have repeatedly confused yourself by assigning your own meanings to my words instead of asking for clarity where you didn’t understand.
I think that most people who read my comments understood that I am speaking broadly about my career, and that while I’ve encountered this problem at my current job, my team and I have worked to make it better.
Your primary issue comes from the fact that you asserted that my frustrations with corporate development are in fact the real job, and your seeming offense at being told that no, your negativity and hostility are not a universally shared experience.
I hope things get better for you in your career, but please stop harassing others for not succumbing to cynicism.
> You have repeatedly confused yourself by assigning your own meanings to my words
As instructed, the words were taken literally. Now that you are telling us that we actually needed to read between the lines to understand what you really meant is informative, but curiously late to make that known, especially in light of earlier instructions.
> and your seeming offense at being told that no, your negativity and hostility are not a universally shared experience.
Uh, what? That doesn't make any sense. If I were offended or felt negativity or hostility I would have turned off the computer and went outside. This is a completely voluntary time use. It had better be good. The fact that I am still here proves that there is no negative emotion felt whatsoever because the instant there is anything else I'm gone. Presumably the same holds for you because there is no rational explanation, assuming you are of sound mind, why you wouldn't have equally found something better to do if there was anything unpleasant experienced on your end.
I guess this is supposed to be another case where we cannot take what you have written literally?
i consider a sign of maturity in myself that i always defer to adapting my software to fit how the user is trying to interact with it. the sign of immaturity is that my deference masks internally screaming, "why would you want that!? why would ANYONE want that!?"
my "customers always right" approach has produced much more successful and useful software compared to my perfect little hobby projects which will never be complete and noone would ever use anyway
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.
My problem is I can skip all those steps and 8 separate meetings by applying a little common sense to software design.
Unfortunately, orgs often treat devs like this as indulgent or wasting time. They need it to be done the inefficient way because that's the only way they have visibility and control.
Yes. And in most of those meetings where the researcher invalidated the leaders, the leaders have left the meeting saying (and thinking? I’m not sure) they were validated. So because of the leaders we have we should skip the meetings and research in both cases.
> Users never align with your analytics.
Any good theories for how this happens (i.e. why the data fails to capture the struggle)?
Analytics don’t capture the “why” of what they measure, on the user side. Indicators may move in the seemingly right direction for the wrong reasons. Analytics typically can’t tell you what the user wanted to achieve. Knowing the “why” gives a better basis to decide on what changes to try, or to realize what’s actually wrong with the user-facing side of things. Another reason is that they tend to measure an average where in reality there is no average user.
I think the answer to this is roughly ... the content of an applied statistics degree, or a research methodology practicum. There are so, so many ways that quantitative measurement of human phenomena can mislead, from measurement error to conflation between trends/sample sizes/effect sizes, to p-hacking, to good old bias (in interpretation or in deciding what tools to use to smooth or normalize data), and thousands more.
Interpreting data is hard.
Eg, if you have a bunch of airplanes returning from a war, you might be tempted to armor the areas where they were hit. But you want to armor planes where the holes arent because those are the critical areas.
If you can read literal bullet holes backwards, hundred dimensional preference vectors say something, but we generally have no clue.
Not GP, but I can humbly share mine.
I think it's because a lot of analytics are data points oriented instead of being workflow oriented. So you can see that feature A is not being used a lot, but it's very important in a particular flow. Feature B may be used a lot, but it can be only important for a particular class of users while very detrimental mentally for another class.
People use software for a needs, but rarely I've seen a need being highlighted when interpreting analytics data.
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.
I don't like that they have that data in the first place. But then again I don't use Chrome.
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.
I do all the time because the feature exists. I would treat it like a sliding line in my tabs bar. When I'm done with a tab for now it goes to the right, and eventually everything to the right gets closed once I haven't used it in a while
I do. I open a search page, middle click a bunch of links, then want to close all of the ones to the right because I found one that told me what I needed and don't need the rest of them.
Probably a perfect example of why it's so useful for developers to talk to users
Not only to understand the usage of features, but also use cases perhaps to design even better features
It's useful when starting a thread of research of research as new tabs will be opened to the right (Ctrl+Clicking a link). So after it's done, close to the right can be quite useful.
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!
> I think that over-reliance on analytics has had a similar effect;
The over reliance on analytics combine with a lack of metrics and proper accounting.
If you are renting all your infrastructure knowing how people use your app, and what the COSTS of that are is kind of a big deal. If your high dollar client is your lowest margin one, thats a problem that is technical and financial as well as a product insight.
And that infrastructure your renting, it stopped making sense for a lot of orgs to do that almost a decade ago, but here we are where everything is in the cloud because capacity planning is a lost art and was a great throttle on the insanity that the post is describing.
For 2 larger projects I'm on, I'm both the developer and a user: on a regular basis I use the software myself. And not just for one-off tests. I really use it the way other users use it.
This has provided rather deep and interesting insights in software development for these particular products and in general. Or in OP's lingo: not a lot of potential for insanity at all. Because any new idea immediately gets regarded on 2 fronts: what does it take to implement and what does it really do for the user.
I find that if people don't dogfood their software the software just ends up being shit.
As engineers we need to be a little grumpy. Frustrating with our software provide directions to improve it. If we're not grumpy, we don't know what to fix.
But some of this also comes from top down. Engineers also need the freedom to fix things. They're the experts. Management Also shouldn't interpret that frustration in quality as the engineer being a thorn in their side. It means the engineer cares and is willing to remove the thorns in their side. But I think there's a strong natural tendency in any organization to surround yourself with yes men. They're sneaky, telling you no when you ask them to. Maybe a reason management loves LLMs so much
At very large $companyIUsedToWorkFor, the accessibility features got a lot better once we hired a blind developer. Once it went from "we have to pass this test" as our only feedback to "Bob did this because it confused his text-to-speech program when he was looking for another bug" we got such a great success flywheel going. Very quick feedback cycles really is required for successful software development.
Heh it can stil suck even when dogfooding.
At my friend's org, they like it to suck bc that reminds them they are doing the very sophisticated work of dogfooding. No one told them they're allowed/supposed to feel good making/using the sw...
"We want to feel the same pain the customer feels" is shortened to "we want to feel pain." Instead of "neither we nor the customer feel pain."
In my experience, this is the only kind of software that ends up not sucking. If development is not driven by users in a very intimate way -- like being one and the same person -- then you routinely end up with necessary features only half working or splitting essential information across multiple screens or dialogs. Eating your own dog food is essential to rising above that, because only that reality will overwhelm the developers sense of the "proper" way to do things.
I believe it's the major reason that industry specific information systems are universally shitty. The user can't articulate what they need to accomplish and the developer doesn't really understand the purpose or importance of the work. Result is bad functioning or bad interface.
It's why only software like text editors and web browsers gets to be really good. Huge user base. Lots of developers involved.
Git kinda proves that it's not infallible, though.
> It's why only software like text editors and web browsers gets to be really good. Huge user base. Lots of developers involved.
There's lots of great software out there that you interact with every day that was written by a small number of developers to clear requirements. Your car ABS brakes. Your coffee maker. Your brushless drill. Your TV remote. Think of the fact that majority of the microprocessors and microcontrollers that you interact with every day have software that you never think about, because it just works and gets out of the way. (And think of the cases -- maybe your dishwasher, your smoke detector, whatever -- where that's not the case! It really drives home how incredibly pleasant just-works-without-thought really is.) It's only these big, large team, overly complex systems where the expectations are so low that even the crap that is a current web browser is considered acceptable, let along "not sucking."
You're mistaking shitty software for software that doesn't work. Shitty software is 100% functional. You just hate it.
By intentionally picking the software that eliminates the UI, when the whole benefit of computers as a tool is that the UI is infinitely flexible, you're picking shitty software that doesn't appear that shitty. But it still is.
I mean, I hate the way my TV remote works and have wanted to change it. But I can't. It has buttons that open NetFlix or Apple TV that I can't change, and I don't have any ability to reprogram them because the companies paid for it to be a permanent advertisement I can't get rid of. That sucks.
But also, I think we only have to look far for what shitty appliance software looks like. VCRs and microwaves are notorious for having shitty software. As soon as we introduce a network, suddenly the software sucking is an immediate problem: witness the nightmare stories of Jeep updates, Tesla lockouts, and paywall feature locks when the hardware is present. Or we can look at the spying done by LG that you can't turn off. Or the forced advertising that Samsung showed they can do to your fridge.
Or how automobiles need an OBD reader even thought they ship with a built-in tablet. Or how the OBD codes are something you have to pay for. Or how you might not be able to disable the stupid "shut the car off" feature when you stop at a red light.
Shitty software on microcontrollers is some of the most tyrannical shitty software there is.
> when the whole benefit of computers as a tool is that the UI is infinitely flexible
I think this statement is insane. The benefit of computers is that they allow complex behaviors to be defined and implemented. The benefit of software is that it’s the lowest-NRE way of defining those complex behaviors. UI doesn’t come into it, except in a few edge cases like desktop computers, phones, appliances, etc. A climate model’s “benefit” comes from its output, not the form in which it generates output or takes input.
Okay, I don't really feel like your going for a good faith interpretation of the points I'm trying to make. You're taking things hyper literally and out of context. I don't feel like you're really trying to understand what I'm saying at all.
> It's why only software like [...] web browsers gets to be really good.
Huh? Web browsers are still laughably bad even after all these years. They are engineering marvels, certainly, but using them leaves a lot to be desired. I cannot imagine anyone would voluntarily use them if the ultimate function was equally available another way.
You mean installing the Reddit, X and Instagram apps on my phone? I use them in the browser because the browser is so terrible they don't spy on me as much.
That's absolutely splendid. In the user role, I get very irritated when programs do stupid things or interface elements don't do what they're supposed to do. Muttering to myself I'm asking a question: have the developers ever actually used this program? I'm convinced had they used it for real, there would be far less idiocy users have to deal with.
Your approach to developing software goes a long way to producing software that users appreciate. OTOH users may have no opinion about software sufficiently intuitive to use that it fails to bring attention to itself. Such transparency is an outcome developers should be proud to achieve.
This approach is really worth pointing out and recommending. Not everyone is allowed / encouraged to realize how powerful it is.
Dogfooding is useful certainly but it can also be a trap, as someone who is technical and knows how the software works both sides you can fall into the trap of avoiding triggering the exact kind of issues a regular user can walk into.
Your conceptual model of how things work is going to be different to that persons and it is a very hard trap not to fall into.
Indeed. Some of the worst software interfaces I've ever dealt with were fully "dogfooded" and that was the cause; the people writing the software did use it every day but (a) in a very idiosyncratic way and (b) in a specific, very constrained environment.
The devs did use the software, but used it in such a different way from everyone else that when the devs optimized for their own case, it made the software actively worse for everyone else.
Indeed, it's a lesson I learnt the hard way and is much like proofreading something you wrote, you don't see the errors as easily as someone else you asked to proofread it usually does (well until you hit Send then you usually see all of them instantly).
This is something I've asked repeatedly at my job. Current team builds services for other developers to use, okay, do we also use it so we can go th ough all the same pain points as them? Why not?!
> 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.
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...
I live in Finland, where in "product companies" developers don't always speak great English. Or they might not speak Finnish if they're immigrants. So the employer wants to pick and choose product managers that they think are "presentable" enough in terms of linguistic or social competence to put directly in front of a customer. They seem to value this high enough that they are willing to take the productivity hit from the indirection.
> The users pay your fat salary
In an idealized world, maybe, but enterprise software isn't paid for by its actual users, but by their company's executives/management.
Product manager skills do not overlap much with dev skills.
If I put some devs in front of a customer I'd be very much afraid of them doing what they ask rather than what they want, for instance, or overindexing on one particular customer's problem.
If the devs understand and can empathise with the users and there aren't a lot of them, sure, maybe but on most projects it's more effective to have the distilled and filtered customer feedback from a PM who is good at being a PM.
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.
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.
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.
> Firefox
Nobody asked Mozilla for a redesign.
Oh boy, I do mostly agree with you but this applies well if you’re making software for the fellow SWEs. While a lot of them can be an annoying bunch, once you’re making something for general consumption, like let’s say running an e-commerce platform, interacting with your end users could be probably better compared to a front desk/service industry job. It’s very hard to keep that positive attitude then.
https://www.productftw.com/cdn-cgi/image/format=auto%2Cwidth...
The stakeholders should be held accountable to this. C level and PMs. Otherwise they just push what they believe will be better, no matter what developers say.
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.
When the user is understood as yet another human who doesn’t know what they want, the insanity returns! Because an average customer usually doesn’t have practically grounded wants.
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.
Not sure on this, a lot of time I know better but the customer insists we do it their way and it's usually because they are lazy to improve on their end.
I've had more than one half-serious conversation with SVPs here that every staff/architect level engineer should have to spend at least 6 months working on the engineering team that directly interacts with the largest customers.
I flat out guarantee they'll come away with a wildly different perspective of the things that need done, and the ways their service operates.
Ideally I'd want them to do a rotation in customer support so they get the small customer perspective too, and at least learn what kind of paper cuts they're inflicting on customers.
> 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.
Sure. Now, how to deal with the entirely plausible situation where there needs not be any separation between the developer and the customer at all, thanks to AI.
[dead]
[dead]
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
> it’s best never to talk to users because they have no idea what good quality is
You should use some Microsoft, Google, Adobe and Apple products to have an idea what good quality _isn't_.
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.
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.
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.
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)
I feel for you. We didn't know how good we had it. Wooed by multiple companies right out of university, good salary, comfortable, fulfilling work (some nights though), fast path to car and home ownership and long term financial security. Few rules/restrictions more perks compared to other professions. We were spoiled. Perhaps this is why the current crop of tech leaders are behaving like spoiled brats.
I resemble that remark. The trouble is that I'm now too old and if I ever lose my job, I'll never find another one. No one hiring in tech wants the greybeards.
Getting the kids to insist they be paid what their contributions are worth would raise the boat for all developers. Of course that would take some sort of big bad union, which the oligarch vc asshats really don't like.
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.
> coworkers that literally committed zero code for months
That's awesome
I would much prefer to have coworkers that literally commit zero code than the monkeys I sometimes work with who commit way too much code, or just plain commit the wrong code
> than the monkeys I sometimes work with who commit way too much code, or just plain commit the wrong code
We've managed to emulate this behaviour in silicon now.
I don't think it's because of the 'average developer', but because system's like OP's were designed by experienced engineers, while the modern toolchain is written by "senior developers" with 3 years of experience. They have a lot of energy to pull all-nighters reinventing yet another wheel, and not the wisdom to avoid doing that, or to do it in a sensible way.
In fact, the entire tech sector, favouring fresh grads out of college over greybeards, is built this way. My pet very controversial theory is that this phenomenon is massively fueled by everybody and their dog using ADHD stimulant medication to get through their day; fresh grads + amphetamines is the preceding step to Kubernetes and the entire React ecosystem.
tl;dr: modern software is built by 'work hard, not smart' kinda types.
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.
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.
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."
Similar to "needs to be a platform" [0], another variant is "be a data company" where somehow the underpants gnomes will transform your moat of stored information into profit.
[0] Read: "Needs to be pitch-able to investors as a magical 1000x growth unicorn."
it's no longer a theory. google paid millions for spirit airlines' emails and internal messages to be used as training data for their AIs.
Google already had the machine, this was just feeding the machine. 99% of companies do not have this machinery in place and probably wouldn't know where to start.
Yeah: Spirit Airlines didn't become ultra-awesome with the power of all its "data", it went bankrupt.
I'm not sure on how much of the flight/sales/maintenance data is being used, versus simply a big archive of emails and support calls.
Probably by emailing google, meta, OpenAI, and Anthropocene, saying you have a dataset and asking if they'd be interested.
After they went bankrupt... right?
Related: https://en.wikipedia.org/wiki/Map%E2%80%93territory_relation
We are the "...whatever gets us $2m seed..." layer for the AI of the future of finance.
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.
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.
> 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."
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.
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.
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.
It is not the software, it is the internet. Something Awful already had it figured out: The internet makes you stupid.
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.
The peak of human civilization, for me, was downloading Shrike and actually having it work "out of the box". If an absolute moron like me could get that to boot up with next to no involvement or fudging through the user manual, I knew then that the tide had turned.
The Internet doesn't make people dumber any more than video games, rock music, picaresque novels, the printing press, or writing did. These kinds of arguments come around with every new technology and have always been fatuous.
All of them were true to some extent, except probably the printing press.
And they even figured that out before Cambridge Analytica happened.
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!")
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.
> But, harsh as it may be: most software is still just a glorified spreadsheet.
Think the author means most back-end software is a glorified spreadsheet (CRUD app with a few sorting algorithms).
The last 10-20 years in software has been more about new device interfaces, improving UI/UX, and networking technologies. I think of things like streaming, 3D games, live chat, video content, mobile apps, and LLMs.
Anyone who thinks about software like that would not instill confidence in me that they make very good software.
> You can watch sensible people argue for an hour over a button because, somewhere deep inside the conversation, the button has become connected to a future pile of money.
> It means understanding that not every problem is existential, not every idea belongs on the roadmap, and not every abstraction deserves to exist.
> waste away in Margaritaville tinkering with shit that doesn't need tinkering with.
I don't really understand what each paragraph has to do with each other, or why this message is being shared with me today.
I don't even mind that style of writing, but it should be more specific and interesting if it's going to be stream of consciousness style like that (IMO). To do all that, and deliver just vague half-points and boring assertions, felt like I was just waiting for some kind of punchline or point to be made that I could nod my head at but no thought was stuck with long enough.
The conclusion was like they tried to come up with anything just to turn the essay in on time.
This was written at a really easy level. It was not at all hard to understand. Disagreeing with something and not understand it are very different but often the latter is feigned to make the writing seem written by an inferior. It's kinda like an ad hominem attack. (≧▽≦)
You don’t know what “ad hominem” means.
But you are right that it’s beginner level writing.
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'm starting to believe computer work and screens make me lose touch with reality and dissociate. I remember starting an apprenticeship as a dev in 2015 and I saw a guy like me, but 2 years in, with deep eye bags and he just smiled, didnt say anything and he looked extremely exhausted. Well 11 years later and here we are, we are all tethered to this mess
This is why I hope to retire on a farm
My career in software development happened back in the days of MS-DOS, before Windows really took hold. I developed a system that recorded the inspection of Fire Safety equipment like Fire Extinguishers, Hoses, etc. My initial estimate for the time required to build the system was 2 months, it actually took 3. Then the client looked at it, and it met all the requirements, but was unusable in practice. I then worked onsite for a year, and learned so much about software usability by seeing it in use. After that year, we deployed it to 10 other sites.
Other than having a summer intern once, it was a solo effort. The code was written in Turbo Pascal, with some code on the hand-held computers written in a language called PL/N. (A variant of PL/1 for the Norand corporation handhelds)
I wrote all my own text editing/forms handling libraries, and everything else I needed. Version control was using pkZip to archive the source code onto 3.5" floppy disks.
Tying it back to the article in question, I can't imagine what it's been like with the push for "sprints" and all the rest in software development over the past few decades. I can see how it would drive you to burnout. I'm very thankful I missed it.
Y'all have my sympathy.
Sprint is a terrible misnomer, it should be iteration. It's about seeing work as a series of opportunities to gather feedback and apply the learnings to the way future work is done.
> 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.
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.
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.
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.
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).
> in today's day and age
The human world today is freer of pathogens than at any point in all history.
The article had me at "[...] every new feature is the one that's going to be the one (but certainly not that one that was supposed to be the one during the previous sprint)".
I have fought way too many times the new "the one" feature. Just ship it, it's already good enough, everything else just adds cost, especially psychological cost to the team.
The part that the cost of changing software is unknown, ignored and fixed is not true anymore. This is a thing I realized recently.
A company cannot get free (o low cost) software changes anymore. Someone invented llms and they charge by work produced (useful or not)
So a PM cannot "save" costs by pushing. The employees will resort to their agents and there will be cost. If there is no agent, another company will beat them. So now a change has a measurable cost and even you can calculate in what was spent (agent logs)
Since software is less constrained by physical resources and has low perceived friction for change, it's easy to adopt a development strategy based on the common ideas that "more is better" and that continuous change is inherently good.
But things don't have to be this way. Buttons moving around after every update isn't inevitable. AI-assistants in text editors aren't inevitable either. I use and love xfce, for example
Hacker News itself is a great example too
I don't usually dig these little tirade blog posts but I genuinely laughed, related, and enjoyed this one.
I particularly liked this quote:
>You can watch sensible people argue for an hour over a button because, somewhere deep inside the conversation, the button has become connected to a future pile of money.
I have worked in a number of different types of jobs; from restaurants, to nursing homes, to roofing, to physics research. And finally for about 15 years I've been developing software at various companies of various sizes (Giant corporations to tiny startups). Part of what he describes is what attracted me to this industry. The feeling of being able to create something that people can actually use and might actually make money (maybe A LOT of money) was/is stimulating. Having witnessed the craziness that can come from that seed, well I just think he did a great job of explaining it. I appreciate that he tries to balance showing the insanity with the fact that there are times when the underlying driver is real. That's probably true of most insanities though. :)
Anyway, I'm not leaving the industry but I think it's really difficult for the AI agents to tell what is crazy and what isn't, so they are picking up this insane culture. (^▽^)
Seems like your actual argument is that competitive profiteering makes people insane. That is the motive here. Software is just the conduit.
As well as the people who work on software not being the ones making decisions about that work. A gap between the deciders and the laborers. Which is a result of the structure of the current micro political economy within organizations. It is not separate from it.
There is a symmetrical presumption in the minds of people that the software representation in their screens is both accurate and capable of altering reality when changed. This is very often violated, obviously, and people find it jarring.
Another related problem is people will often take software at face value. When you have an inkling of what sort of dysfunction might be behind a certain buggy behavior it is much easier to cope both by finding workarounds, deciding to wait it out (my parents had an issue with some government database and I thought it suspiciously like some change propagation issue, told them to try again next week because I assumed some reconciliation on the weekend would solve it and it did) etc.
But a lay person will see error messages and take it to mean some catastrophic bureaucratic issue with their data when it's most likely just poor quality software...
I think the expectation that software is correct, accurate, and trustworthy, drives people up the wall when they are confronted with the reality of buggy and poorly implemented systems that they are required to use to function in society.
Is it fair to say the same applies to writing? It feels like so often when I'm reading something (really anything--blog posts, essays, the news) the words I'm reading are there for their own sake, not because they need to be there.
Maybe it's because I'm reading work with a deadline, or from a half-hearted writer, or maybe it's because a lot of people have never been taught how to write well. Whatever it is, so much of writing is bad because the author hasn't done their due diligence with their purpose for writing.
Except unlike software, this fault is so prevalent and eternal that it has become the status quo.
I've been "joking" about this with my friends for a couple months now, and every day it becomes less and less of a joke--there are some very...interesting...things happening on the Twitter timeline these days.
> A boring application that stores records in a database and lets people edit
> them doesn't sound especially impressive, while a distributed event-driven
> platform with a service mesh and realtime synchronization layer sounds like
> you're building NORAD.
Very well put
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.
Ok, I get how you might like the ideas there, but "beautifully written"?!? Really?
The goal of writing is to communicate. That means saying what you mean to say ... and not filling paragraph after paragraph with pointless and redundant things you don't need to say.
There is not an English teacher in this world who would argue that was even a well-written essay, let alone a beautifully-written one.
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?).
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.
Tech has the following issues to greater and lesser extents:
* It gets in the way: confirmations, notifications, features that don't exist and can't be added, even when they're asked for repeatedly.
* It stops listening: freezes, overly-strict interaction requirements.
* It's not 100% safe, and thus not truly reliable.
Not all tech is like that. Or has to be.
My long running message of the day: "eventually all programmers turn into mumblers."
It depends on the context, software that controls an airplane has very different requirements from an todo-app.
Which he talks about in the article of course.
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.
Oracle and Microsoft are in the contracting business, and software is just an excuse for them to get contracts.
> Moving the kitchen in software might look like a "simple fix."
Why, of course! We leave the kitchen deployment where it is, and just install a proxy kitchen facade on the other side of the house, which does everything via the original kitchen through remote procedure calls.
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.
> Everything becomes urgent because everything can move quickly
I finally understand why I quit my previous job.
> But, harsh as it may be: most software is still just a glorified spreadsheet.
I've always liked representing it this way, the software we use rarely breaks out of the CRUD mold.
When you know something can be changed relatively easily, say compared to a building or a car, the tendency is to do it. Especially when there is no tight feedback loop telling you what is a right and wrong move. The churn is the result of the psychology of uncertainty combined with the ability to act on that anxiety.
Shipping MVPs or minimal features quickly and seeing if they stick is a solution. Quick and dirty until you know something is worth further effort. Yes, user feedback is good but often people don’t know what they want, or think they want things they won’t actually use, and you won’t find out until it’s sitting in front of them.
And someone is always yelling that everything is taking too long, usually the same person who told their boss that something would be done by x date without asking anyone else.
I know this is slightly off-topic, but is washing your hands twice per hour really considered a Hughesian level of compulsiveness?
I know no mentally healthy people who wash hands ~32 times daily (16hours awake) - except if you work in a kitchen or as a doctor etc.
For office work, it sounds excessive to me.
I think most people only wash their hands after toilet visits and perhaps before eating (many don’t).
Twice an hour is not even Hughesian level of compulsiveness IIRC.
Depends on what you're doing. If you're at a keyboard and there's no reason to wash them, then yes. If you're in a kitchen with ingredients sticking to your fingers, that's not enough.
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 think there's some truth to this. All those decisions and interactions at your fingertips cause dopamine release, which in excess can cause things like psychosis, paranoia, or delusions.
[dead]
I feel like this post could've been either shorter or better structured.
It explores a bunch of interesting ideas, but the way they're mushed together makes it taste a bit bland.
I still don't really understand what exactly it was that this text wanted to tell me. A bunch of things? But also nothing. I can deduce what it I think was supposed to tell me (based on extrapolating patterns and most likely talking points), but it didn't necessarily do that. _Telling_ me I mean.
Maybe leaning less into the relateable-ness would've helped there? Or just containing it better.
__
I suppose there is a place for just stream of consciousness rambling (like this comment), but the post kinda came with the optics of "here's a statement", but then there's no real statement.
So maybe that could also have been fixed with a "Here are some not necessarily fully coherent thoughts you might find interesting" disclaimer.
Perhaps my mind is just not wired in the same way as the ones of the target audience, but if that is the case, then I am a bit offended by the blog naming itself "Graybeard".
A bit too vibey feely "that is so me omg" for that.
(The LLM I've consulted telling me that I'm just missing the point here kinda validates that hypothesis for me. Good for you then. May you all bond over this with your weird "emotional resonance" stuff. It seems to tickle the RLHF stuff just right.)
Pretty decent output, mind sharing the prompt and model used? I struggle getting text i enjoy reading
https://www.pangram.com/history/5a4b90c6-0123-4f97-b50e-9c90...
the level of observability swe's have into how their changes affect UX, revenue, costs, etc. definitely have something to do with it. that feedback loop isn't as quick in other industries.
I don’t know… People says that I eat ice cream using the forehead
this effect feels only tangentially related to software
This rings so true to me. I've had about a dozen jobs in software and exposure to another dozen through consulting, and I've generally found that the more mundane the application, the more the company's leadership and many employees had deluded themselves into thinking they were truly changing the world (a sales productivity tool in the most extreme case). Like the bigger the elephant in the room that the project was actually pretty boring, the more overcompensation there had to be.
Wow that was way, way, way too long. The author could have summed that whole entire "essay" up in maybe five paragraphs!
"Drives people insane" is the interpretation of those with an external locus of control. For those with an internal locus of control it translates to "reveals character".
pulling levers is the new equivalent to pulling requests
I really liked the article. Thanks for sharing!
Here's my alternate title: people are insane, software reveals it.
Insane feels too strong, though. I believe people make sense. We just have this crazy ability to fool ourselves by spinning stories. And many of the stories we continue to spin were handed to us without our awareness.
Well done and the author is just scratching the surface ...
A lot of it has to do with communications. The times I (as a programmer myself) have witnessed how companies we asked to write software tackled it was eye opening in a negative sense.
As a freelancer my process involves a lot of observation, asking questions and planning. Usually when I go into the details more questions emerge and whom to ask better than the people who do exactly this daily? Sure sometimes their process is a bad abstraction, they chose because they did not knew better and thus not worth putting into software. But before you decide that you gotta ask whether there are reasons why it was done that way. I see my task as a programmer to make peoples lives easier, by finding elegant abstractions for their problems, that are at the same time, reliable, adjustable, encourage correctness, avoid problems and so on.
Now most software companies I interacted with from the other side did none of the things. They rushed to gather the specs, asked some questions in the beginning and were out of the door to start way too fast, with some things they just assumed without confirming. Then crickets and then something half broken comes around that you need to beat into shape in an exhausting back and forth, where again you have to be the person with the questions.
If it is exhausting for a person with software development experience to be your customer, how bad will it be for people who have no such experience.
Now there are of course exceptions also in such companies, but in my experience that is mich rarer than it should be.
Oh, Nice reading :)
This resonates with me. And I think I know why software is like this. It isn't software that drives people insane, it's money that drives people insane. Specifically the promise of money breaks people's brains. They see the unicorn companies turning junior engineers into overnight millionaires, and they start salivating. They start looking for The Way. The closest thing they find to The Way is a bunch of unicorns and FAANG companies that have gone before. They start looking for talismans and ceremonies that will bring them closer to The Way. Scrum, Agile, Kanban, scalability, "web scale", 12 Factor Methodology, microservices, etc. may be good ideas but they take on real power when they're a perceived path to fortune.
> Most software, when you strip away the branding and architecture diagrams, is remarkably boring.
Lost me right there.
[flagged]
[dead]
windows adbloat and 15 corporate software policies and scanners drive people insane