Not Invented Here
Summary: Tools and process is important but sometimes it's better to use what you have instead of reinventing the wheel. I contemplate the Not Invented Here phenomenon and try to curb my own proclivities.
Like many writers, I’ve raised procrastination to an art form. Instead of knuckling down and finishing the damned book I’ve spent countless hours in ancillary or, worse, completely different tasks.
I should note that there is some value in this; that’s why I said ‘spent’ not ‘wasted’ countless hours. The skills I’ve learnt over the years have served me very well in my day job. However, the end goal of the writer is to finish the work and anything that compromises this goal must face scrutiny.
I recognise that one of my biggest pitfalls is suffering from Not Invented Here Syndrome.
Not invented here (NIH) is a stance adopted by social, corporate, or institutional cultures that avoid using or buying already existing products, research, standards, or knowledge because of their external origins and costs. Wikipedia
Basically it means instead of making do with what you can get off the shelf, you spend valuable time making your own stuff (and sometimes even putting up your own shelving). For an individual, it’s one of the most destructive forms of productivity masturbation.
For me NIH typically revolves around reinventing my tools and processes. I’m a born tinkerer; I love pulling things apart and seeing how they work and I love the intellectual challenge of making new things.
Sometimes this is born of necessity. Using Linux for example meant I had to overcome a lot of things that are missing from the system that I took for granted on macOS. Sometimes it’s born of a desire to automate tasks, the way I do in my day job, even though technical writing and fiction writing are very different animals. Often, I find myself creating elaborate, time-consuming solutions for problems that are either trivial or don’t exist.
Letting go of this desire is really, really hard…
…but it’s something I have to do, otherwise I’ll just keep following the rabbit down into the metaphorical warren. That’s fine when you’re seventeen and time rich; it’s not when you’re thirty-seven and time poor.
So, from now on I’ll endeavour to write more and tinker less.
Here’s some rules I’ve set for myself:
- Evaluate the tools I already have: someone has likely solved my problem.
- Don’t make apps: a shell script or Automator/Editorial/Workflow action will suffice.
- If a simple template can solve my problem, use it!
The big points for me are the first two rules. I already own a lot of great quality software I’ve bought over the years. There’s unlocked potential in many of them that I know about, but have not fully embraced. What I have should realistically cover me for 95% of my needs.
This leads into point 2. If most of my needs are met by what I already have then I’ve reached the point of diminishing returns. Creating an app (even a web app) takes more time than it’s worth. By contrast, creating a shell script or an Automator action is much more efficient and faster at solving a particular problem.
Finally, point 3 means that often a problem needs nothing more than a little forethought and a good template. Templates (I’ll include checklists here too) are easy to create and provide consistency and clarity. If I give thought to how I structure and persist my data, it will save me pain later on. On the subject of data, I need to accept that it’s okay to abuse spread sheets; not every problem needs a relational database.
Enveloping all these points is the big, unspoken rule that goes to the heart of the matter: don’t do anything that compromises my goal. This takes discipline, focus and the recognition of what’s actually important to me: writing.
So there you have it. As the cliché goes, recognising you have a problem is the first step to overcoming it. This is my first step.