There are at least two ways to make building software about yourself:
- Believing that being the smartest person entitles you to win, and
- Believing that making your team suffer entitles your company to win.
Two recent pieces of drama online—because I am unfortunately chronically online—showed both of them in action.
Bun vs Zig
The first was the Bun / Zig drama. For those who haven’t followed it, the tl;dr is that Bun was acquired by Anthropic and while originally being written in Zig, it was rewritten in Rust with a lot of tokens and help from Anthropic models like Fable 5. While Jarred’s article about the rewrite did talk about some of the challenges they had with Zig, I feel like he went out of his way to not blame the language, saying things like:
Zig made Bun possible. I would never have been able to build this much in 1 year if it wasn’t for Zig.
and
I don’t blame Zig for that - other users of Zig don’t have the bugs we had…We wouldn’t have gotten this far if not for Zig, and I’ll always be grateful.
All in all, I would say it’s a balanced look at the situation, where Bun came from and where they wanted to go with the project. Used Zig, now uses Rust…big obvious advertisement for Fable 5 and we can all move on with our lives.
But then Andrew Kelley, the creator of Zig, decided to chime in and write about his “thoughts on the Bun Rust rewrite”. By contrast, this article takes a number of personal shots at Jarred, his intelligence, and the Bun team’s overall competence…only to then follow it up towards the end by saying:
Two, I actually don’t have any personal criticisms of Jarred.
That has since been edited out and replaced by what I think is probably true - that Andrew was attempting to make points about their business relationship and not Jarred personally and that he had unprocessed emotions at the time of writing. But the fact remains that the blog still contains the phrase
Jarred was already writing slop well before he had access to LLMs.
So it’s safe to say that it remains pretty personal, and pretty clear that Andrew does not think highly of Jarred. Now I don’t know Jarred as an engineer at all, but I do know that Bun is a fantastic piece of software and just for that reason, Jarred probably deserves a lot of respect for building it and making it valuable enough for Anthropic to acquire it.
Don’t Smile
Then a second controversy exposed the other half of the same mistake.
One of the cofounders of Mintlify - which is a great product and tool for documentation - posted an article on X bragging about an all-hands slide he presented that said only “Remember not to smile”.
The idea was you shouldn’t smile because “if a strategic win came easy, you left something on the table.” So smiling is in this case seen as a sign that you didn’t work hard enough. You didn’t maximize time in the office, pull enough all-nighters or do whatever else it takes to be seen by the world as a hard worker.
This post was then derided online by dozens of people, in YouTube videos, quote tweets, and subtweets left and right. Perhaps my favorite take in and among the memes was this from @paularambles:
We see here the old Protestant trick in its Silicon Valley form: success alone is vulgar, almost pornographic. My god, you cannot simply succeed. It must first be purified through unnecessary suffering. So you get this obscene reversal where pain stops being a cost of the product, and instead becomes the product itself.
It’s not about you
So what do these two things have to do with each other? I think the answer is actually incredibly simple. When you’re building software, perhaps most especially when it is a tool for other software developers, it is not about you.
This lesson, simple as it may seem, is one that I think is at the heart of almost any failed or successful developer tool or project you can think of. Just look at “open source” as a concept: whatever motivates someone to begin an open source project, it can only become a community when other people find value in it. Why in the world would anyone do “work” for free like so many many open source maintainers and contributors do?
The mere fact that we have seen an open source community exist even once, much less over and over for decades, is a testament to how critical this point is. Projects are far more likely to grow and succeed if as they embrace that (and build something people actually want, sure). And they often fail miserably when they turn inwards and try to make it about themselves.
A programming language like Zig is almost the perfect example of this. If you’re writing a programming language, by definition the only people it could be for is other programmers. The trouble begins when a language’s creator treats a user’s departure as a personal rejection, or the user’s success as something that should rightfully belong to the creator. You’re going to have a really rough time if that is the way you think about it.
And even worse, if for some reason you think that having a bad time is a requirement for success, you’re going to have an even more uphill battle to fight. If you’re not able to actually enjoy the process of building, you’re not going to be able to succeed by just “trying harder.” The marathon athlete who is part of the analogy in the post might not be smiling simply because they are focused on their breathing, but they are often enjoying it. Why? Well because people rarely sustain that level of effort through misery alone. The best athletes may not enjoy every mile, but they find something in the process worth returning to.
And they certainly don’t do it to just “ship one more feature” or “increase shipping velocity” or “increase shareholder value.”
Technically Correct is not the best kind of correct
I’m not sure how many times we are going to have to say this, because no matter how many times we say it it seems like there are always engineers who choose to completely ignore it.
The best technical solution is not always the winner.
Just because you have the best technical idea, or you know how to program better than anyone else, or you are the smartest person in the room, does not in any way shape or form guarantee your success. History is filled with “better” products that failed miserably. That’s because it isn’t about just being technically correct.
If you’re writing a developer tool, your success is not guaranteed by having the best API or the most features or even the fastest code. Your success is directly tied to the success of the people who use your tool.
Andrew Kelley could be correct about every technical deficiency he identifies in Bun and still misunderstand what Bun’s success means. A tool isn’t evaluated in isolation; it exists inside someone else’s work. Its real quality includes whether people can understand it, trust it, adopt it, get support, hire for it, and accomplish something valuable with it. Performance, language design, and API elegance all matter, but only as means to that end.
Even if moving away from Zig were technically mistaken, or Bun never “used Zig correctly” - Bun is allowed to optimize for Bun. A programming language exists to serve its users. They don’t owe the creator validation or continued adoption.
The most successful people aren’t the biggest sufferers
Just like technical correctness doesn’t determine winners and losers, neither does suffering. Just because you worked harder or even worse suffered more than the next guy, does not mean you are going to win. And certainly doesn’t mean you’re going to have a better life.
In fact, the opposite is sometimes true. In a 1989 study of competitive swimmers called “The Mundanity of Excellence,” researchers found that the most successful people in sports were not the ones who suffered the most. In fact, in some ways the opposite was true:
At the higher levels of competitive swimming, something like an inversion of attitude takes place. The very features of the sport which the “C” swimmer find unpleasant, the top-level swimmer enjoys. What others see as boring—swimming back and forth over a black line for two hours, say—they find peaceful, even meditative…they enjoy hard practices…
It is incorrect to believe that top athletes suffer great sacrifices to achieve their goals. Often, they don’t see what they do as sacrificial at all. They like it.
I’ve experienced this directly in my career: I am not the best, most creative, most productive developer relations person when I work harder. Instead, I work harder when I am being my best most creative self.
When I really believe in something, am truly excited about it, that is when my passion shines through and I do my best work. Not when I’m trying to force myself to just ‘work harder.’ Forcing that kind of thing produces subpar work, burnout, and an unsustainable set of results.
The work has to serve someone
The world doesn’t owe us success for an elegant solution, and it owes us even less for a painful one. Those are facts about our experience as builders. A developer tool is ultimately judged by what happens on the other side: whether someone else can do something better because it exists.
That doesn’t mean craftsmanship is irrelevant, or that worthwhile work is always easy. It means craftsmanship and effort are in service of something. The code isn’t there to prove we’re clever, and the work isn’t there to prove we can suffer. Both exist to serve the person using the tool.
Thanks
I want to thank these folks for helping inspire me to write this post: