# ETOOBUSY ðŸš€ minimal blogging for the impatient

# Coding discipline: resist premature generalization

**TL;DR**

Another epiphany about coding discipline: get to something that actually works before generalizing it.

Iâ€™ve always been a fan of refactoring, to the point that Iâ€™m often inclined
to *factor* instead of *re-factor*.

What I mean is that I think about doing something â€“letâ€™s say the sum of two
and threeâ€“ and my brain immediately starts with generalization challenges,
like *what about summing any two integers*? *Why not numbers in general*?
*Hey, what about complex numbers, or any possible field*? *Why are we
considering sum only, and not any possible binary operation*? You get the
idea.

Result: Iâ€™m down a rabbit hole when I only needed to sum two and three, and
I definitely hear *five* laughing somewhere out there.

So, in addition to premature optimization is the root of all evil,
Iâ€™ll add *premature generalization is pretty bad too*. To some extent, a
generalization can be seen as an optimization, so itâ€™s nothing new right?

As a discipline, Iâ€™ll try to reach *something working* as soon as possible,
and then *consider* if generalizing it makes sense or not. At least I will
have something, shut the vicious *five* up and feel less frustrated!

Cheers!

*Comments? Octodon, , GitHub, Reddit, or drop me a line!*