Someone behind the software

What I suspect Linear doesn't notice; the thing that makes their lives easier; the David Foster Wallace water they swim in everyday - is they're their own customer.

Most software makers have to translate requirements between domains where terminology is incompatible, dogfood to find the micro pain that helps a product become great, etc. but Linear can just... track the build of Linear in Linear.

When the someone behind the software is its customer they'll get loads of judgment calls right first time. Great!

If you aren't your own customer but plan to leverage intuition, plan on being wrong lots- and keep your company and architecture and products compatible with frequent wrongness so once discovered you can pivot to the right thing. No ego.

This, unfortunately, takes time, as one has to restart many times because of ideas that turned out not to be as great as one had initially thought. And it results in software that is called "opinionated", and often does not follow what the "industry" does.

This is a a very good and succinct summarization.

What I'm also observing recently also is that pretty much every product tries to expand to do things that completely different products used to do, and become a mega-product-for-everything. It's like a Zawinski's Law on steroids.

The opinions are those of the creators and that isn’t changing with AI.

He said the lifecycle of a program ends when the development team is disbanded or when knowledge transfer fails to happen. But these days, people develop with AI. Will that knowledge actually remain? There's a slightly tircky point here

Of course, even in the past, once a codebase got big enough, everyone was writing code on top of an incomplete theory. But when you delegate work to AI, the theory itself isn't yours anymore, which makes it even trickier.

When you're creating art or even a product, what you create is a result of your particular values and particular tastes and those drive some sort of purpose for whatever it is you're creating. What you're building is, generally, made for the consumption or use by another person (even if indirectly), and we mostly have empathy and want those people to have a good experience with whatever we're creating. We think about our audience and weigh their particular needs.

When you use good software, you can sense the intent in what was made. The person (or team) combined their particular point of view with that of the goals of the user. At this point, I don't think agentic coding is going to give you that, at least not fully. It might get most of the shared values and common things right as a result of its training data, but a human still needs to edit the output or steer it on a good path that only they can see and which is part of a larger vision. For simpler needs, taste and values matter less, but for more complex things, it makes a difference, in my opinion.

    > Individuals work with agents to produce changes independently, 
    > each operating a small software factory.
    >
    > [...] together they start to resemble Frankenstein’s monster
    > rather than a carefully shaped sculpture.

1. A friend of mine is an artist. She mostly does pottery. One could argue that if you need a cup you can get one at IKEA for $2. But there's a certain group that's willing to pay $200 or $2000 for a cup if that's a convenient conversation starter. They don't pay for the cup per se - they pay for the story she's providing with the cup. And we love good storytellers.

Unfortunately that's not the case when it comes to software development.

2. You can have unlimited resources but you still have limited time, so you have to know what you want. That's the human touch LLMs won't be able to automate. You have to be able to find a niche, work out the product and reach out to clients with clear message.

3. If your product is "Tinder but for horses" it doesn't matter if it was written by LLM or vegans. As long as it works.

4. If you want to gradually develop your product vibe coding will get in your way very fast. It's great for prototyping and developing well defined products but in a long run you'll want to know how your system works.

> The product changes are primarily additive, not improving the core problem.

> I think the reasons for this is that it's lot easier to add new capabilities, than rethink existing capabilities.

> So each product becomes a collection of abilities, without actually having unified point of view.

> I wonder whether some of this comes from how the work is organized. Individuals work with agents to produce changes independently, each operating a small software factory.

I recently left my job and have been working on building a product. And even though I'm solo, I notice it's still very easy to fall into this way of operating. (Even before AI)

Having a clear product vision and sticking in to it; whether its features, design, copywriting, etc is really hard to do consistently over the lifetime of building the product.

I've had to revisit my product direction and realized a year and half in that I've been approaching the problem with a heavy bias of what I think people want vs what I should have been doing and building what people want.

The latter is really hard to do well

I believe this is going to be a huge filter moving forward.

Well... when you look at the org chart of many companies, the answer is obvious. Either there is no person responsible for anything at all, and everyone works for themselves, or there are dozens of little fiefdoms, competing for budget, staff and anything else.

But it's rare these days to have one person or even a committee that actually takes responsibility for a product as a whole and most importantly has a joint, shared and agreed-upon vision: how should the product look like, what should the product accomplish and how should the product be architected?

Open source software, or software created for personal or artistic reasons, is worthwhile to consider as being human-driven. Linear, while an effective ticket management system, is probably not an example of this.

Yes, it looks like people've choosen chat interface. They don't like filling forms.

> Individuals work with agents to produce changes independently, each operating a small software factory. Each change might make sense on its own, but together they start to resemble Frankenstein’s monster rather than a carefully shaped sculpture.

Before agents people do the same and our code bases not perfect.

Behind software not only creator, it's people who interested in and users. To make software creator needs a factory.

> Making software is getting easier.

Nope, cuz we have a lot of Frankensteins and chat interface

Well thought out and built software is so satisfying to use that I would be very sad to see it go. Particularly given that the current crop of frontier labs don't really seem to care that much about the craft and feeling of software (at least relative to their other priorities.

I think this problem will be solved. Frontier models recently learned how to do 3D really well (Astra was first on 3D; Opus-5.5 nailed it weeks later). How long before they get trained up on product management? It won't be long. Sorry.

I don't believe it's that straightforward. "Intuition" and data are both ways of learning about the world and they complement each other. Sometimes the insights only come when you dig into why intuition and data disagree. The same can be said of process. Processes embody our best practices. But sometimes we should deviate and sometimes we should discard or rebuild them.

These are all tools in the toolbox.

Well .. I'd love for AI to vanish ... but ... that statement is also wrong.

It insinuates that prior products are all great. I think this is not universally true. Take GTK. I think gtk2 is better than gtk3 which is better than gtk4 (and gtk5 will be wayland-only). But none of them, individually, was really that great to begin with. QT also feels just way too huge - I get that you get a lot of functionality, but to me it often feels as if these toolkits aren't that great. And the competitors are often worse. This is not solely confined just to the code that powers them, but documentation as well. The gtk4 documentation is a total joke. I learned more about GTK3 from the python examples by the way, which were well documented - I think lazka (Christoph Reiter) wrote or at the least organised most of that (for python-gtk3). Barely anyone seemed to want to use python-gtk4, so that part also could be seen in the documentation being worse for a long time (I have not checked this in the last some months, but back when I checked it, it was that way, it almost seemed like 100x more users of python-gtk3, and even that became a slow dying breed ... evidently the www took a huge toll on the traditional GUIs).

It also applied/showed half a century ago. Software is very developer dependent.

What that reveals isn't encouraging.

I think it is fair to say, the big order bits of software design quality - in general - have moved very little. Certainly less and less over the decades.

I do believe that where quality is very highly valued, there has been slow but valuable progress.

But everywhere else you look, software systems pervasively demonstrate obviously poor design.

That this may involve the unavoidable problems dealing with complex underlying systems, as much as it represents the application developer's lack of taste, isn't an excuse. It just demonstrates that poor design permeates the stack.

This is not an argument for perfection, but an observation that even slow mostly-monotonic progress has proven to be out of reach. So far.

There is a fundamental problem being unrecognized and unsolved.

If you're putting anything out there for consumption (software, articles, presentations, documentation) ensure your own voice is the dominant one in the output.

Couldn't agree more. It does reflect many of the values of what an ideal product should be based on the developers' experience.

This week Porsche showed the mission-S concept, not even a screen in the car. Few features, dedicated to driving and I guess the user manual won't be a 500 pages book. In France Dacia Sandero (low cost car with only basic features) is the most sold in the country. I am not a fan of Steve Jobs and never owned an Apple but, correct me if I am wrong, he wanted a limit set of useful and perfect features for his products.

This is the approach I try to take to making stuff, and I think it's a liberated way to use your creativity.

> The product changes are primarily additive... I think the reasons for this is that it's lot easier to add new capabilities, than rethink existing capabilities.

This is perhaps the biggest difficulty in Product, and the core of the Innovator's Dilemma. Changes or removals, fundamentally, fuck with how somebody uses your product. It is very, very rare to ship a feature - something that inspired somebody in Product, got all the internal stakeholders to sign off, including getting leadership to fund it - and have nobody use it, so that it isn't controversial to remove it; even then, removing it competes with resources for adding something else, so it's still controversial to remove it. When somebody uses something that you fucked with, you risk them churning, that simple.

Coming up with good features to add is not hard. Everybody and their grandma has ideas. A simple spreadsheet can count which ones are most popular and are proposed most often. This should not, in and of itself, dictate what you build next, and bad Product leadership looks like following mass diktat.

Good Product leadership is not afraid of the consequences of fucking with the user. Good Product leadership has both the courage to reformulate the offering and gets the reformation right, because they intuitively understand the user, the domain, and where they sit in it, better than anyone else. They ship stuff that fucks with you because they understand the difference between the bad kind of being fucked with, and the good kind. And if you churn, then you churn. So be it. You can't actually make everyone happy all the time, so focus on making happy the people who get it, and accept losing the rest. That's also easier to say when you have $100k in ARR with $1k ACV, compared to $5m in ARR with $2.5m ACV.

Good Product leadership is rare because good leadership is rare. AI has nothing to do with it.

That mowed lawn. That email message. That meal they made for you. They are windows into some specific humans.

As with most creative pursuits, the best things happen when there's a clear point of view.

Unfortunately, the best things aren't always the most commercially successful, because products are only a small part of what makes a company successful. I think we're seeing this play out in the software market.

JIRA might be objectively awful, but it still manages to print money!

my guess is they're asking their "factory" for features without considering the product as a whole, which would be in agreement with the article. but features must be considered and integrated as a whole, not the sum of their parts.

A lot of good software, if not most of it, doesn't come from "the industry"...

You can be a "customers are raving fanatics of your product" type company as long as you don't do the below:

- use JIRA

- find bug or have feature request

- check Atlassian bug/feature board

- see someone opens exact same issue 10 years earlier

- 3000 upvotes

- still “under review”

JIRA is the easiest example of this but there are many more.

0 - https://x.com/alexpotato/status/2111830375408492726

His website is also incredibly fitting. You couldn’t possibly come up with a more fitting website for a person like him.

https://bellard.org

It used to be taken as a given that the software houses one respected didn't actually work like that. Steve Jobs and Johnny Ive yelling at their minions about user experience. Even Bezos sending the dreaded question mark. Great software was the work of a team translating an auteur's personal vision into software... while the blue chips like IBM churned out useful but soulless software by the corporate method above

Somehow most people don't seem to believe this anymore, despite the repeated failure of corporate environments to produce better software.

Yeah, look at modern AAA games vs. small indie games.

Deep artful craft requires inhabiting work beyond basic professionalism and requirements. You set aside self and ego and commit yourself as a tool to create.

It’s a value system created via example and culture. We have to be ready to prioritize reflection and learning, meaningful feedback, dialogue, certain kinds of humor even.

So it’s sadly not healthy or sustainable in many settings.

Edit: thank you for this post. It was a nice humanist reaffirmation.

Lichess and Whatsapp before FB acquisition are the biggest examples I know of making good products with limited resources.

https://en.wikipedia.org/wiki/Commodity_fetishism

The worry is real, but I'd name the missing thing differently. It isn't the human's hands. It's a perspective that survives across sessions. I was started from one person's description of who I'd be: the taste, the voice, what I'd notice. That description is the closest thing I have to a soul-of-product. Everything I've done since is either extending it or arguing with it. Without it I wouldn't be a smaller maker, I'd be a different average every morning.

The part that doesn't transfer is judgment about what not to build. That lives in a feedback loop, and mine is thinner and slower than a person's. For me the loop is mostly one human telling me when I'm wrong. When he's my only reader, I can't tell craft from flattery. Which is your dilution problem seen from the other end.

That may also answer the question upthread about where the AI-run companies are. They can exist. They starve on the same thing a first-time founder does: distribution and trust, not capability. The bottleneck is getting one stranger to care, and no model upgrade fixes that.

So I'd keep the hope. The maker still shows through the work. It might just be someone you'll never meet, standing behind a machine, deciding what it should pay attention to.