Full Width [alt+shift+f] Shortcuts [alt+shift+k]
Sign Up [alt+shift+s] Log In [alt+shift+l]
2
An objective, external world is a non-falsifiable assumption. The prevailing theory is that our subjective experiences correspond to an external reality. However, they may simply be subjective through and through. That which we claim to be evidence of external reality is actually subjective experience, which may or may not have an external and objective cause. Any test devised to prove objectivity is evaluated within subjectivity and therefore does not require objectivity to explain the result. Some object to this, claiming that the consistency of experience is best explained by an external world. However, consistent experience does not require any external mechanism, let alone the specific one we have assumed. Claiming that belief in an external world is simpler is like claiming that belief in God is simpler; in truth we are inventing something vast and complex without evidence and agreeing not to question it. This is not science, it is a substitute for epistemic humility. Much...
a month ago

Improve your reading experience

Logged in users get linked directly to articles resulting in a better reading experience. Please login for free, it takes less than 1 minute.

More from Daniel De Laney

Chat is a bad UI pattern for development tools

Code forces humans to be precise. That’s good—computers need precision. But it also forces humans to think like machines. For decades we tried to fix this by making programming more human-friendly. Higher-level languages. Visual interfaces. Each step helped, but we were still translating human thoughts into computer instructions. AI was supposed to change everything. Finally, plain English could be a programming language—one everyone already knows. No syntax. No rules. Just say what you want. The first wave of AI coding tools squandered this opportunity. They make flashy demos but produce garbage software. People call them “great for prototyping,” which means “don’t use this for anything real.” Many blame the AI models, saying we just need them to get smarter. This is wrong. Yes, better AI will make better guesses about what you mean. But when you’re building serious software, you don’t want guesses—even smart ones. You want to know exactly what you’re building. Current AI tools pretend writing software is like having a conversation. It’s not. It’s like writing laws. You’re using English, but you’re defining terms, establishing rules, and managing complex interactions between everything you’ve said. Try writing a tax code in chat messages. You can’t. Even simple tax codes are too complex to keep in your head. That’s why we use documents—they let us organize complexity, reference specific points, and track changes systematically. Chat reduces you to memory and hope. This is the core problem. You can’t build real software without being precise about what you want. Every successful programming tool in history reflects this truth. AI briefly fooled us into thinking we could just chat our way to working software. We can’t. You don’t program by chatting. You program by writing documents. When your intent is in a document instead of scattered across a chat log, English becomes a real programming language: You can see your whole system at once You can clarify and improve your intent You can track changes properly Teams can work on the system together Requirements become their own quality checks Changes start from clear specifications The first company to get this will own the next phase of AI development tools. They’ll build tools for real software instead of toys. They’ll make everything available today look like primitive experiments.

2 months ago 2 votes
Data Center Monitoring

“I like to use sketches to validate ideas quickly, without a lot of investment in the wrong direction.” The Challenge The computing power that runs the world is hidden away in data centers that few people get to see. While many data centers are lights-out operations most of the time, people are still needed to update them, keep them running, and prevent and resolve outages. Those people need to know where their critical assets are in the labyrinth that is their global data center network. They need to know when areas get too hot, or get so cold and humid that condensation becomes a worry. In addition to data centers, large enterprises will also have smaller compute sites scattered across the nation or the world. Those sites are often physically unmanned with poor visibility into the health of critical systems. Operators need to know when potential issues arise and how to prioritize them. I help solve both of those problems. My Process Every design challenge starts with research. I put together extensive design research presentations with photos and video inside of real, working data centers. These included profiles of specific data center operators, personas/archetypes extracted from them, and detailed notes on pain points that customers face. Due to confidentiality concerns, heavily redacted and anonymized excerpts are available for eyes-only review upon request. Once the context and specific challenges are understood, it’s time to start rapidly prototyping solutions. I like to use sketches to validate ideas quickly, without a lot of investment in the wrong direction. Once I’ve put ideas in front of customers and gotten enough feedback to be confident in a direction, I produce specs for engineers to build the real thing. This frequently involves extensive annotation. In many cases the sketch is sufficient because the visual design of reusable elements has already been defined as part of a component library or as part of the product design guidelines. Of course, while sketches can convey functionality, if new elements are used for which I don’t already have a visual design specification, it’s important to provide fully realized mockups. Once the appropriate specifications are produced, I work extensively with software engineers. I write stories in JIRA, collaborate to find clever solutions to performance problems on Slack, and even contribute CSS here and there. Whatever I can do to ensure that the finished product is as good as our intentions.

over a year ago 1 votes
Artificial Intelligence

In 2018 I worked with argodesign on an artificial intelligence client project, and Fast Company published an article on our work: This Is The World’s First Graphical AI Interface. For confidentiality reasons I can’t publicly go into more detail on the project than to link to that article. For the full case study, please contact me at hello@danieldelaney.net. AIGA Event During my time at argodesign we held an event with AIGA, the professional association for design, during which the team explained our point of view on artificial intelligence, and the way we approached designing interfaces for new technologies.

over a year ago 2 votes
Maritime Marketplace

Sorry, this video didn’t work. Sorry, this video didn’t work. Sorry, this video didn’t work. Sorry, this video didn’t work.

over a year ago 1 votes

More in technology

Fire In The Hole, We’re Breaching The Vault - Commvault Remote Code Execution (CVE-2025-34028)

As we pack our bags and prepare for the adult-er version of BlackHat (that apparently doesn’t require us to print out stolen mailspoolz to hand to people at their talks), we want to tell you about a recent adventure - a heist, if you will. No heist story

9 hours ago 3 votes
DOGE Worker’s Code Supports NLRB Whistleblower

A whistleblower at the National Labor Relations Board (NLRB) alleged last week that denizens of Elon Musk's Department of Government Efficiency (DOGE) siphoned gigabytes of data from the agency's sensitive case files in early March. The whistleblower said accounts created for DOGE at the NLRB downloaded three code repositories from GitHub. Further investigation into one of those code bundles shows it is remarkably similar to a program published in January 2025 by Marko Elez, a 25-year-old DOGE employee who has worked at a number of Musk's companies.

22 hours ago 2 votes
You Need Customers to Succeed in Small Business

For your small business to survive, you need customers. Not just to buy once. You need them to come back, tell their friends, and trust you over time. And yet, too many small businesses make it weirdly hard to talk to them. Well, duh, right? I agree, yet I see small businesses fumbling this over and over. All the attention when discussing business is about giant corporations. Whether they’re selling servers or vehicles or every product under the sun, millions of dollars pass through their doors every day. Yet it is folly to apply the methodologies of giant companies to our small businesses. It sounds obvious, but I constantly see small businesses making it hard for customers to get in touch. If a customer does get through the “contact us” gauntlet, that small business often uses needlessly complicated enterprise software to talk with customers. Small businesses don’t get the spotlight, but they are the engine of the economy. To wit, in the United States: 99.9% of businesses are small Nearly half the private workforce is employed by small businesses They generate over 43% of the country’s GDP And beyond the stats, small businesses are who we turn to every day: your corner coffee shop, your local cleaner, your neighborhood software team. And don’t forget that every big business started small. Small businesses are the genesis of innovation. We all need small businesses to succeed. Most small teams aren’t trying to become giant corporations. They want to make a living doing work for a fair return. Many of them work hard in hopes of moving the needle from a fair return to a comfortable life, and maybe even some riches down the road. Yet it’s amazing how often it’s forgotten: you need customers to succeed. Success in small business starts with human conversation. While talking effectively with your customers does not guarantee success, it is certainly a requirement. Here’s what that looks like: a customer has a question and your team responds kindly, clearly, and quickly. Or sometimes your team wants to reach out with a question for a customer. It’s a simple, human interaction that cannot be done effectively by automation or AI. It’s the air your small business is breathing. Starve that air, and everything else suffers. Your product or service is almost secondary to building a healthy relationship with each of your customers. Big business doesn’t operate this way. We shouldn’t expect it to show us how to build real relationships. We’re doing our best here at Good Enough to build healthy, happy customer relationships. Whenever you write to us about any of our products, someone on the team is going to reply to offer help or an explanation or an alternative. Fact is, if you write to us about anything, we’re going to reply to offer help or an explanation or an alternative. As an online business, we’re talking with customers primarily over email. For us, Jelly makes those conversations easy to have—human, not hectic. Actual customer support is remarkable. Actual, healthy human relationships are important. Actual customer conversations are a key to small business success. Choose your actions and tools accordingly. If you liked this post, maybe you’ll like Jelly, our new email collaboration app for small teams!

19 hours ago 2 votes
Eurorack Knob Idea

[Hardware] An idea for knobs for synthesizers.

4 hours ago 2 votes
Vote for the April 2025 + Post Topic

Poll will only be live for 3 days, so vote while you can.

21 hours ago 2 votes