Things You Should Never Do, Revisited

When you’re first starting in your career - in whatever field that may be - it’s important to find reliable sources for information and advice on how to do your job well. This can come in many different forms: mentors, books, podcasts, videos, and articles. One of those sources that I learned from was Joel Spolsky,¹ who wrote publicly on the internet in an era when that was still a fairly novel thing to do. Now if you don’t know who Joel is, you most definitely know what he has created - amongst other things, he was the co-creator and CEO of Stack Overflow. The coding question and answer platform helped millions of software engineers over the years and likely lives on in the training data of the current LLM models. Today (and periodically in the future) I wanted to take a look back at one of the important articles that he wrote that helped guide my understanding of the world of software development. How much still holds up today? Are there lessons that those just starting their career can learn from?

The OG #

Stack Overflow may be the most impactful thing Joel has built, but I first found out about him and his writing through my use of Trello - project management SaaS that was quite revolutionary at the time, both for its influence on process (Kanban inspired) and the web-based interface you interacted with. At the time I started reading his blog, I didn’t realize he was connected to Stack Overflow. Once I discovered his writing, I was hooked. He had a way of discussing topics in a matter of fact manner that didn’t gloss over the details, but was easy to follow at the same time.

What Joel said in 2000 #

Let’s walk through his article titled “Things You Should Never Do, Part I”² and discuss some of the salient points he makes. The occasion was Netscape 6 going into its first public beta, almost three years after version 4.0, with no 5.0 in between:³

They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.

In what would go on to be probably his most famous article, he laid out the case for why (despite the engineer’s inherent inclination to do so) it’s a bad idea to rewrite software from scratch.

We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.

Whenever a new generation of developers comes in, they often feel like there is a new, better way of doing things that should be adopted. They aren’t always wrong, but an iterative migration is almost always better than starting from nothing (as appealing as that might sound at first).

It’s harder to read code than to write it.

Even 26 years ago, this was axiomatic. Writing assembly had been close to writing in a foreign language, but by 2000 the mainstream languages read almost like plain English. The difficulty came in following the logic and state as you walked through the code, not writing the statements themselves.

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive.

This is the thing that stuck with me the most. There is a reason that all those weird conditionals exist with branches for special cases. It’s because those represent real world scenarios where something went wrong and someone went in and fixed it. It may be ugly or inelegant, but it’s the reason that things keep working.

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.

Time was anchored as an important factor in decision making. I really appreciated this as well - sometimes tending towards being a perfectionist, it was important to hear that you don’t have all the time in the world. Software is only valuable when users are using it. Shipping is key to success.

It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”.

This is something that I’ve learned myself and now innately trust - oftentimes coming up in the context of looking at old code that I have written. For personal projects, there can sometimes be a many year gap between when I work directly in the code, and when I go back I will occasionally encounter something that is unintuitive. Usually I’ve left myself a comment explaining the unintuitive part and why it’s like that, but even if I haven’t I try to trust myself and give my past self the benefit of the doubt that “you did this for a reason”.

The scorecard #

What agents change #

I think the thing that has fundamentally changed here is that you no longer have to read ugly code - the agent can (and does at lightning speed). One of the primary motivating factors (outside of reliability) that folks wanted to start fresh in the past was code “elegance”. It’s harder to follow and read bad code. Well - what about when you don’t actually have to read it? It doesn’t matter as much.

The other factor - and probably the much larger change - is that refactoring and writing code has become incredibly inexpensive. Knowing “what” you want to change and how to approach/design it is much more important than the syntax or language. Look at the Bun rewrite from Zig to Rust. Claude was able to complete this in 11 days - 535,496 lines of Zig, with up to 64 agents running at once - at a cost of around $165,000 in API pricing.⁴ That’s quite remarkable for something that would have taken many months and multiple engineers before.

What it means today #

Despite the fact that the landscape has changed dramatically, I still think these old articles should be mandatory reading for any new CS grads entering the workforce - but it’s also important to read them with a modern lens. Agentic engineering changes how we develop software and the capabilities (and limitations) of the past may no longer be true. It’s important to challenge the status quo on why we did things to evolve towards the future. That said - Joel still has great advice. Ask the model about him and it will likely agree.