Don’t scale (even if it hurts)

For better or worse, being an Erlang/OTP fanatic has made me see the world for all its wonderful concurrency.

But, this isn’t always so helpful, especially when one is a perennial tinkerer and always involved with upstarts.

Paul Graham said — and I believe this is true — that upstarts should, at all costs, avoid scaling in the beginning. ‘Don’t scale,’ and you’ll waste less, and learn faster.

The trouble with following the ‘don’t scale’ rule, is everything becomes imperative in nature — there’s nothing to juggle — so you can imagine, being blocked, doing things serially, is torture for anyone like me who sees the world ‘The Erlang Way.’

Fight the urge

I’m constantly forcing myself to accept the hum-drum pace of ‘not at scale’ as I know it’s not an upstart cargo-cult mantra, but rather, the only way to learn fast.

When you try to get ahead of yourself, over-engineer during the learning phase, then it’s just time and effort wasted.

Moreover, the opportunity cost isn’t zero, either, when you are building something out that may not be used. If you are knee-deep in the weeds geeking out on a branch of the system that may be used soon, you aren’t learning from the current feedback loop that is churning away.

Shelve concurrency

The good news is, when projects take off, there’s plenty of opportunity to employ the power of ‘The Erlang Way.’

So, leave juggling for later, listen to Paul Graham, don’t scale in the early days, and all the while, just tinker, learn, and grow in a direction that is new and exciting.