Why You Should Build Your Own Tools

Something has happened in the manufacturing world that is nearly irreparable.  As America moved production to China and downsized factories to realize the profit gains from low wage Chinese workers it also decimated an entire skill set from the national tool belt.

When a factory tools up a new line to produce a new iPhone, sneakers or toy it is the job of a skilled tool maker to decide what custom tools can be designed to make things efficiently.  These may be custom 1 of a kind drill bits, platforms, moulds, or machinery that someone with a creative and technical skill-set needs to design and create.

When America outsourced it’s factories it also lost these very valuable skills.  Now, as a result of that loss of knowledge spinning up a new factory in America is a very difficult task to accomplish.  That loss will take a long time to recover from.

In the world of software development, abstraction is often a panacea.  Abstraction has created a similar migration of technical skill sets over the last few decades.  We abstract out the complexities with layers upon layers of helpers, protocols, frameworks and libraries.  These extra abstractions can boost our productivity tremendously so long as we don’t encounter a use case that isn’t handled by our chosen abstraction technology.

The danger when you completely ignore how those abstractions work is that the skills and knowledge it took to create them die out as well.  Who are the tool makers?

I have found it incredibly useful when trying to understand a new tool to have a solid grasp of the underlying technology. Knowing how to build a HTTP service at the TCP level (and from time to time actually doing it) makes it easier to reason through issues and push the limits of a framework like Ruby on Rails.

Software developers everywhere should spend just a little more time writing the tools they need to do things quicker in the future.  It is investments in the tooling that has the chance to compound to make future work exponentially easier.

Create stand alone services that can be leveraged on multiple projects, write code generators, and libraries. Create your own frameworks.

The style of programming required for creating a great re-usable library is very different from that used when doing a business application.  Good, flexible code often relies more on using the dynamic capabilities of a language.  You’ll often find yourself needing to use meta classes, introspection and other fun constructs.  The people that know how to wield these tools are going to be better at debugging, see opportunities to improve code, and create their own tools.

My plea to software developers everywhere: create your own tools.  Know how to create the tools you use, and how to use the tools you create.