Code brevity

We all want to write simple, short, effective code.

My biggest desire when i was just starting up as a developer was to write short code. Even today, when I look at a piece of code, my initial reaction is to look for ways to simplify . The problem? I might not know enough about the problem I’m solving or the code I am working with to make that change… yet.

This could come from a bunch of reasons.

Maybe it’s because I work so much in the JavaScript performance realm so my first concern is bundle size.

Or, maybe it’s just my profound dislike of duplication and copy-paste solutions. God knows I’ve had my fill!

Regardless, reaching for brevity in the initial phases prevents learning. Believe it or not, when implementation starts we are still learning about the problem.

So compacting those conditionals into a nested ternary or extracting each piece of functionality into its own method/function, is actually hiding useful complexity. It blurs the big picture and you end up with a skewed version of reality.

We end up creating brittle code, that’s hard to change both structurally as well as philosophically. We’re less willing to change what we think is the right implementation.

We are left with the impression that we have good, decoupled code, but making that decision too early might leave us with an inflexible, fragile architecture.

If the system is resistant to change from the start, when pieces are still missing, we will resist changing it or miss possible solutions altogether later on.

The wrong implementation done right is worse than the right implementation done badly. Premature optimization leads to inflexible solutions, but if you apply a TDD mindset (red-green-refactor) and optimize later you’ll reap the benefits.