Thread by @JoshWComeau

Earlier in my career, I expected that once I had been doing this for a handful of years, I would consistently write clean, concise, "elegant" code.

The truth is that I've just learned to organize things better so that the mess doesn't matter as much.

In the project I'm working on now, a bunch of stuff is gross AF. But I'm mostly OK with that, since the inputs and output are clear. "This function takes A, B, and C, and reliably produces X". The params are context-relevant, there's no seemingly-unrelated stuff. No side-effects.

In a year, if I come back to this project, I'll be able to make sense of it pretty quickly, since there's a clear structure to the wiring. There's no weird dependencies, no confusing connections between components. There are magic numbers, but they're inside black boxes.

Of course when I actually want to change the hot-mess functions, I'll likely stumble over it a bit. But, critically, changes to this function don't affect any other parts of the system, so I'll be able to poke around with it and trust I won't break something unrelated.

The time I would have spent on refactoring the guts of a function to be more elegant is instead spent on adding unit tests, so that I have confidence in the conversion between inputs and output.

(I've also grown to understand that "concise and elegant" is far less desirable than "simple and dumb". Terse, clever code is fun for Advent of Code or Codewars, not so good for day-to-day projects. But that's a separate thread.)