Maybe because we’ve all been burned at one time or another by a boss or client who didn’t spec out the software we ended up trying to build. Or maybe it’s because we live in a world where everything that matters is true or false, none of this messy in-between stuff that’s impossible to code. Developers crave specificity, exactitude, precision.
We are far better at dealing with 3.14159265358979323846264338327950288 than “a little more than 3” so we don’t look for good enough, we want the best. The One True Answer.
For example,

There’s absolutely nothing wrong with looking for the best solutions when you build your startup – an absolutely zero chance you will find those answers outside of your codebase.
Best? By what standard? For who? In what context? In a world where there are programmers still at each other’s throats over whether VIm or Emacs “rules” setting your standard for what you’re going to attempt to an impossible degree of certainty is just another way of dodging the bullet you fire when you try to build something new, exciting and daring.
Defining the “best” process is a worthy and profitable way of making car seats by the million when the few less than best, the more money you make. But you’re building one software business, with probably one application and definitely one chance to get more business answers right than wrong. You can’t afford best – what you need is what will work for you, get that item off your multi-thousand entry To Do List and will let you move on.
Save the precision for your code, where it can do some good.

Write A Comment