The first cut is the deepest.

When you have something new, you baby it. Preserving its state of “newness perfection” as long as possible. You polish it, park it far away, or have some expensive case for it.

And then it happens. A dent, scratch, blemish, whatever.

Your treasured possession is ruined in its purest sense. It works & looks fine, but the pristine quality is lost.

You care a little less. The next scratch, dent etc. doesn’t feel as bad. At this point its inevitable. More dents and scratches will come, and you’re no longer worried about it. You’ll get a new thing some day & replace what you have now, so who cares…

Framed over any dev project, there are glaring similarities. #

You’re building an amazing product. You fucking love this thing. You’re working hard to ship things and make it even better, then it happens.

A poorly styled link, unformatted email, ugly error page, or some poorly written code, a relative nothing in your mind. And you say, I’ll get to this later - its not important as the feature I’m working on - lets just ship it for now.

And that’s it.

You have now shipped a shitty product. Thanks for playing.

Those “little things” that don’t matter are something that is constantly in the user’s face. Our brains are WIRED to notice differences, and they will see it.

Simply put, you’ve told the user you don’t give a shit. #

Even worse, you’ve set the precedent to allow more of it. Other people on your team see it and think, “its ok - XYZ is just like it.” Or, “no big deal, I’ll just add it to my list of things to fix, like XYZ.”

This grows to a backlog of problems you never fix, with a terrible product, that shipped some things too early.

Fear the first cut, it can kill your product. #


Now read this

Products, not frameworks.

Almost everything I read about javascript right now seems to be framework related. Angular this, react that (I know - not a framework) , ember is the worst, meteor is the worst, and on and on. Lots of frameworks are good and bad. But... Continue →