I enjoy woodworking as a hobby. I enjoy working on software projects and products as an occupation. Believe it or not, there are plenty of similarities between the two vocations.
Let's see if I can make you a believer. Here are seven rules that will serve you well in both wood-working and software development.
1. Plan first and adjust when needed
I want to build a table (it’s a product!). A real table — not a data table — with legs and a drawer or two. I can draw up plans (or get them from the interwebs), figure out what wood I’d like to use and go buy it. But first I need to know just how much lumber to buy. I get to the hardwood supplier and they have the wood I want, but it’s not quite in the dimensions I need, so I plan a way to cut and dimension so I get the best use of the material. I figure out the grain patterns and adjust what type of wood is used on what part. And I need to deal with how wood moves with seasonal changes.
Sure, I could just jump right in and start cutting wood, but a little planning goes a long way. And I also know I will likely make adjustments along the way. Especially when the honey-do list gets re-prioritized for me.
2. Processes and procedures matter
With both software development and woodworking, the way you build something matters. Here’s a picture of a checkerboard pattern cutting board I made. The first time I saw one of these, I thought “sheesh, cutting all those cubes and gluing them together would be a pain, plus, no way would I get them to line up perfectly.”
This is true. That would be the painfully wrong way to make that cutting board.
The correct process is to cut the strips of light and dark wood the same width, glue them together, then, cross-cut that assembly into identical width strips (like this). The resulting squares are perfectly sized and will line up to give you that pleasingly aligned checkerboard.
Order of operation makes a big difference and reduces complexity and increases quality.
3. Don’t waste time with unneeded precision
There are two camps in the woodworking hobby — people who want incredibly accurate tools and people who kinda/sorta don’t (sure, there are people somewhere in between but they’re just starting out grin).
Here’s a mitre gauge that is accurate to fractions of degrees:
It is expensive. It does reduce the amount of time to set up. It also requires that my table saw is equally set up to be dead on accurate, which, of course, is ideal. But, hey, tools get used and lose their accuracy. There are other ways I can make a mitre cut faster and just as accurate, like fine-tuning the two pieces by hand.
Similarly, I could get my velocity accurate do the second decimal place, but to what end? Do I need that accuracy? Is it useful? Nah. Many times, close enough is good enough.
4. Measure twice, cut once
“Measure twice, cut once” is an old woodworking adage that still rings true. Sometimes, you measure to cut a leg or some other piece….exactly 16 11/16 inches long. Then you cut it exactly that length and when you fit that piece you find you’re short by a 1/16 of an inch. Ugh. Now I need to cut another piece. Time lost. Lesson learned (again). Should have measured that twice. But, hey, I’ve got a scrap piece I can use to test with.
With software development, the practice of measuring twice is usually exhibited by getting a second set of eyes on the issue. Confirm your assumptions by checking them with others. Then check again before you proceed.
5. Invest in repeatable automation
If I want the four legs on the table to look like each other, a jig or template will help make sure they are all the same. While making the template, I’m not spending time making the piece, but I’m investing time on the quality. And I get to re-use that template for a future project.
The same thing happens when in software development — we use and re-use patterns and code, especially if they’re built well.
6. Experts don’t build everything by hand
A professional woodworker once told me, “If I pick up a hand tool, I’m losing money.” Time is money for that guy. Hand-planing a tabletop, while enjoyable to some, is time (and labor!) intensive. Nope, that pro uses power planer. Devs usually don’t handwrite code for similar reasons.
7. Learn your tools to reduce your risk
I have noticed one significant difference between software development and woodworking. When developers go to a software conference, an overwhelming number of their cohorts still have all their fingers. Seriously….I’ve been to a couple woodworking shows and I couldn’t swing a bat without hitting a guy missing a digit. That’s a reality check.
But that leads us to another similarity: learning to work with your tools and knowing how to use them properly helps you stay safe and reduce risk. For software developers, the impact of not knowing your tools will probably be less corporal. But following good practices can help you avoid many internal headaches and client woes down the line.
Software developers and woodworkers are more alike than we are different. Makers tend to do the same things despite the medium. We tend to do some planning, get to the work quickly, and iterate to refine the piece as we go. We meet challenges and solve problems as they arise. And we always like looking at those nice new tools that might improve our craft. But its experience that impacts what we do and how we do it.
