Code Health Starts With Categorization
When starting any new project, one of the first things I do is sort the existing code into three buckets: Boring Code, Salt Mine Code, and Radioactive Code. The approach applies across languages and frameworks, whether it's HTML, CSS, or a React component. It helps clarify what deserves attention, what to refactor, and what to leave untouched.
Boring Code
Boring code reads as if it makes perfect sense. There's no urge to refactor it, and it does its job cleanly. It's not flashy or clever — it just works. You can rely on it without writing hacks or extra layers on top. The functions are straightforward, the prop names are clear, and the components behave as expected. No nested loops, no mental acrobatics.
Boring code is deceptively hard to produce. When we start a problem, our understanding is often incomplete, which makes it easy to write code that's less clear than it could be. Getting to boring code requires diligence, repeated refactoring, and genuine engagement with the codebase. But the effort pays off: boring code is kind code.
Salt Mine Code
Salt Mine Code is the opposite of boring. It's bewildering, hard to read, and seems to make no sense at all. The difference is that it's buried deep enough that it rarely surfaces. It doesn't leak into other parts of the codebase, so you can mostly ignore it. It may be ugly, and you'd rather never look at it, but it isn't causing active damage.
This is the code you forget about — dangerous if opened and tinkered with, but harmless as long as it stays sealed. The trouble is deep underground, out of sight.
Radioactive Code
Radioactive code is the true problem every engineering team faces. If the codebase is a nuclear reactor, this is the material that has breached its container and is now contaminating everything around it. It's not just bad code — it's code that makes the whole system worse over time.
At Gusto, our form components in the design system are a prime example. They can't be used as-is; every integration requires a hack on top to get the desired behavior. That means each use adds more code, reinforcing the bad pattern and teaching the team to follow suit. The component API itself is inconsistent: a class name for the wrapping div requires formFieldClass in one component and wrapperClass in another. There's a propType called isDefaultLayout that everyone sets to false, then writes custom CSS to compensate.
The compounding effect is worse than the initial confusion. Files that depend on radioactive code become harder to understand because they carry invisible dependencies on multiple broken pieces. The codebase loses its trustworthiness. Teams feel the strain too — radioactive code fosters bad habits, churns Slack threads with frustration, and creates friction between team members. The technologies themselves aren't the problem; radioactive code can be written in any language, by anyone, when attention slips, when someone tries to be too clever, or when they're trying to impress others.
The fix requires discipline: draw a boundary around the compromised code to contain the spill, then systematically work to make it boring. It's not glamorous, but it's the only path forward.
