Zipf's Law

When developing software, eighty percent of your work will be spent on trivial stuff and boring stuff instead of new features and things you (at first) consider core to whatever you are building. This is becoming very clear in the Blockrazor project as we start running into mountains of tiny issues.

This is a fact of life. You can’t change it. The best thing you can do is mitigate it by not trying to get things perfect, and only solving problems that are right in front of you.

Do the bare minimum, and then build on it if it still seems like a good idea and other people start using it. Don’t try and write perfect code, shitty code is not shitty code if it solves a problem. Perfect code is shitty code and a complete waste of life if it doesn’t end up getting used because it doesn’t solve a problem for enough people.

Don’t pretend you are so wise as to be able to foresee what’s coming in the next 6 months, let alone the next 10 years. Once you admit that you are hopeless at making predictions, you’ll start solving problems that are right in front of your face, problems that other people also have, and you’ll do it with “shitty” code because you know it might be replaced in a month anyway. The ironic thing is, if you take this attitude, your code will probably live longer than you because people will build on your shitty code that solves a problem for them instead of throwing it away.

Written on April 18, 2018