Build Your Tools
In a previous life I worked as a carpenter. I built timber-frame houses in the woods of Vermont. It was a sublime combination of hard work and numbing repetition, punctuated by brief moments of terror when your chisel slipped or your saw jumped. While physical strength and stubborn perseverance are core components of succeeding as a carpenter, a passion for the craft and a deep understanding of how things fit together are equally so.
Though it has been several years since I put my mallet and chisels down, I find that I still feel them in my hands sometimes. I still see the stacks of beams and tracings of engineers drawings in problems laid out before me, even though these problems lack that immediate physicality. Sometimes it helps me to imagine building a programming project metaphorically, as a building composed of beams. First lay them out, then cut them, then put them together. I never amounted to much as a carpenter, but I picked up a few things along the way that have served as helpful guideposts.
Firstly, I always try to remember that preparation and layout are the work. They are at least as important as the actual assembly of the building. It’s no use throwing everything together if none of the pieces fit! It’s no use writing an application that doesn’t solve your users’ problems. There’s a good reason that everyone has heard the old line: ‘measure twice, cut once!’ I have learned this lesson repeatedly, through wasted lumber and wasted hours chasing poorly thought out plans. If only it would stick with me!
Since I began my journey as a programmer I have often heard that it is a good practice to start small. Plan out a minimal set of features and try to build them simply, without getting caught up in prematurely optimizing or attempting to do everything at once. Software, unlike a beam, is easy to iterate. I usually find that I need to work my way through something to really understand the best way to approach it. If I try to make everything work all at once, I end up chasing my tail and cursing my foolish ambitions. So take your time, keep it simple, and refactor until it’s beautiful. Easy, right?
In this day and age, there are software solutions for so many problems. You can take your pick of toolkits, frameworks, and libraries. We have even apparently reached the end of code! For those of us who are learning how to put these pieces together, It can be immensely satisfying to see how quickly you can build something with impressive functionality. In order to progress, however, we need to pull back the curtains and find out how the puppets dance. After all, some day we want to be masters, building tools that are useful for and appreciated by our peers.
The most powerful way that I have found to understand a complicated software problem is to find a project that you think solves it well, and try to replicate it. It can be really intimidating to look at something that appears to be so capable and think that you could make something that even approaches it. For example, I used to be really overwhelmed by jQuery’s voluminous API. When I was given the assignment of building a subset of it’s functionality, I thought that it was impossible. While I can’t claim that my code is beautiful, and it certainly only does a fraction of what jQuery is capable of, the act of building jQuery forced me to look deeply both into that scary API and that of the the DOM itself, leaving me with a much greater appreciation for both. This week I tackled a similar project: the Express Router. It took a lot of refactoring to get to code that I could feel comfortable with, but I have come around to being happy with the results.
In thinking about this process of building your tools I remembered the very first thing my timber framing mentor had me build: my mallet. It is a simple and unassuming tool, but it is one of the most important in your toolbox. You can make yours very plain or you can embellish it with fine touches. Inevitably, as you cut beam after beam, it starts to become a part of you. It no longer feels like a separate entity, but simply an extension of your will that allows you to shape the small pieces that compose the solution to the large problem laid out in front of you. I hope that these small projects will help me to learn a similar mastery and allow me to feel these new tools as extensions of myself that I can wield skillfully.
