161–170 of 206 posts
* 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.
Earlier quoted context omitted.
"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.
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.
Earlier quoted context omitted.
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.
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 g…
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.
Earlier quoted context omitted.
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 g…
> 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…
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.
Earlier quoted context omitted.
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…
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…
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."
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 creativ…
Earlier quoted context omitted.
>> 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 t…
> Users never align with your analytics. Any good theories for how this happens (i.e. why the data fails to capture the struggle)?
> 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…
It depends on the context, software that controls an airplane has very different requirements from an todo-app.
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.