I care about performance and the joy of programming an awful lot. I get a lot, and I mean a lot of pushback on the kinds of code this leads me to write.

It’s Premature

I hear this a lot. The exchange usually goes:

<I write some trivial function by hand>
"Why do it that way?"
"Because its probably faster, and it took me no time to write"
"Oh that's premature optimization"

I would argue the opposite - that reaching for an off-the-shelf solution as your first pass is premature. Generic solutions are necessarily more complex. You just made things worse (possibly MUCH worse) for speculative value.

Performance Doesn’t Matter

Uh. that’s factually not true. Some of the biggest technology revolutions came down to performance. See the iPhone beating Windows CE because of framerate despite having fewer features. I’d also argue that Figma’s valuation (something in the multi-billions) was due to them decreasing the framerate of remote digital collaboration to zero - something that posed a serious threat to Adobe.

Or they’ll say “Oh you’re a games guy. We’re under different constraints. We don’t worry about performance, we worry about X”. I’ll point you to Mike Acton’s Data Oriented Design talk as a rebuttal.

It’s not industry standard

This one’s valid - you need to be able to hire people to work on your code, so you need to write code that the available workforce understands.

First, I’ll point you to Jon Blow’s talk on technology decline.

But the funny thing about this one is that while it’s used to prevent better solutions early on, it reappears to justify insane amounts of complexity in the name of libraries.

The logic goes like this:

1. Custom code is too complex, do the standard thing.
2. Go find the library everyone uses.
3. The library we choose is over 4000 lines long, when the proposed solution would have been visible on one screen.

It’s simpler if you don’t write it yourself

I hinted at this earlier but this is also factually incorrect. If you’re reaching for a library, it necessary handles cases you dont have because it wasn’t written with your application in mind. Even well written, well encapsulated libraries (see the stb-libs) handle more cases than any single application will.

To quote Mike Acton, (approximate) “Solving problems you don’t have creates new problems you definitely do.”

You are in a very privileged position - you have more context than anyone else in the world about the problem you are trying to solve. You have the opportunity to solve this exact problem better than anyone else. How cool is that?

Here’s a Handmade Con Clip on over generalizing

Conclusion

1. Programming a computer is like programming a computer. You might need different words depending on the computer. But at the end of the day, the concerns do not fundamentally change.
2. At the very least, do not assume that the industry standard is always right. I’ve worked in games, embedded systems, and on the web. They all have different standards. The likelihood that your industry has the right idea is slim (mostly because there isn’t likely a single right idea, see point #3)
3. Certainly do not assume the industry standard is right for you in this context, right now. The industry standard was developed by companies working at scales and under constraints you do not have. Use that to your advantage.
4. When you do reach for something off-the-shelf, read the code, not the github/npm stars. Find the thing that best fits the exact problem you have, not the thing that the most people like.
5. Practice non-pessimization based programming - do the thing that could become better later. A thing you wrote can only be so complex, and is easy to improve. A library will require you to go understand the large parts to begin to make improvements.

I’m aware that I tend to overindex on writing everything yourself - I enjoy knowing how everything works. But it’s become a defense mechanism because so much code out in the world wasn’t written with these ideas in mind.

At the end of the day, my goal with all this is to write high quality software. To do that, we have to be able to understand the software we write. And I’ve found that writing software in a way you understand is a deeply empowering, exciting experience. I want more people to have that!