Things I Had to Unlearn

Every year-end list in tech is about what to learn next. New frameworks, new patterns, new tools. But the changes that actually made me better were mostly about letting go of things I thought were true.

Here are some of them.

"More abstraction is always better"

Early in my career, I treated abstraction like a virtue in itself. If I could make something generic, I should. Every function needed to handle edge cases it would never see. Every component needed props for configurations nobody asked for.

It took shipping real products to understand that premature abstraction is just premature optimization wearing a different hat. Three similar lines of code are better than one clever function that nobody can read. The abstraction should come after you see the pattern three times, not before you see it once.

"Clean code means short code"

I used to golf my code. Ternaries nested in ternaries, clever destructuring, one-liners that saved lines but cost minutes every time someone (including future me) had to read them.

Now I write boring code on purpose. An extra variable with a clear name. An if/else instead of a ternary. A few more lines that read like prose. My PRs got easier to review, my bugs got easier to find, and nobody ever complained that a function was too readable.

"You need to have opinions about everything"

There was a phase where I thought being a good engineer meant having a take on every tool, every pattern, every conference talk. Tabs vs spaces. REST vs GraphQL. Vim vs everything.

The engineers I admire most say "I don't know" more than anyone else. They have deep opinions about the things they've actually used in production, and comfortable indifference about the rest. That ratio — strong opinions about things you've earned the right to have opinions about, and silence about the rest — is underrated.

"The best code needs no comments"

Self-documenting code is real, but it only covers the what and the how. It can't tell you why you made a weird choice, or what you tried before that didn't work, or that the API you're calling has an undocumented quirk.

I've started leaving comments that read like notes to a friend: "this looks wrong but it handles a Safari bug from 2022" or "we tried X but it caused Y, see incident #1234." Comments aren't a failure of naming. They're a gift to your future team.

"Shipping fast means cutting corners"

This one's subtle. Speed and quality aren't opposites — they're both downstream of clarity. The fastest engineers I've worked with aren't hacking things together. They're making fewer decisions because they've thought through the problem before they open their editor.

Shipping fast means knowing what to skip, not skipping the thinking.

"Senior means knowing more"

The jump from mid to senior wasn't about learning more technologies. It was about learning to care about different things: how the team communicates, whether the architecture makes the next six months easier or harder, which technical debt to accept and which to refuse.

The hardest part of growing as an engineer is accepting that your job is increasingly about people, not code. And then learning to like that.

The Meta-Lesson

Every one of these unlearnings came from the same place: real experience contradicting theoretical knowledge. Reading about best practices is useful. Watching them fail in production is educational. Knowing which ones to break and when — that's the actual skill.

I expect to unlearn a few more things next year. That's probably the most important thing I've learned so far.