To quote a friend of mine, a very experienced IT consultant, Carl Nestingen, "Whether I am designing a new data schema or remodeling my basement on weekends, I gotta tell you something: It's all the same thing!"
How true. Just about every seasoned developer I know maintains a creative outlet beyond code. Some are do-it-yourself home remodelers, some are expert chefs, others are gifted musicians. One developer I know builds radio-controlled jet airplanes. Me? I build guitars. And to paraphrase my friend's quote, whether I am designing a cloud-based, service-oriented architecture or building a new guitar, I gotta tell you something: It's all the same thing!
I take coding very seriously. I take guitar building very seriously. At this point in my life, I spend about equal amounts of time on each discipline. And, in these surprisingly parallel pursuits, I have come to understand a few rules that are always in play, as much for software as for any craft. These rules are:
- It takes a lot of time to get good.
- If you have never done a task before, most likely you are going to mess up. Accept it.
- There is little to be saved by cutting corners.
- Be ready to commit yourself when you commit yourself.
- If you don't pay attention, you will hurt yourself.
- There is no substitute for working with the end user.
Now that you have the rules, let me fill you in on the details.
It Takes a Lot of Time to Get Good
Malcolm Gladwell asserts in his book, Outliers, that it takes about 10,000 hours to get good at something. 10,000 hours is the equivalent five years working at a full-time job. Yes, five years is a long time. But, knowing it's going to take your five years to become competent is a liberating understanding. You can give yourself the leeway to become a willing student rather than a demanding professional. You can say to yourself, "I am not very good at this yet. I am going to make a lot of mistakes. I am going to learn from my mistakes. I am going to ask for help. I am going to surround myself with people who are good at this and learn from them. People in the know will respect me because I am a willing student. I will give myself the freedom to improve continuously."
Figure 1: Whether it's making a guitar or writing code, it takes five years to get good at something.
The most important thing is the pursuit of excellence. It's going to take a long time to get good. Sometimes we get lucky. A company might hire you to build up your coding skills on the job because you are a dedicated, conscientious worker. A player might buy one of your early guitars because, despite your inexperience, you made a decent instrument. But, don't expect recognition right away for anything other than your dedication to excellence and complete willingness to learn. All good things take time!
If You Have Never Done a Task Before, Most Likely You Are Going to Mess Up. Accept it.
Few people get it right from the gitgo. When I first started out making guitars, every one of the hundreds of steps required to complete an instrument was new to me. And, to my chagrin, the expectation that I had of myself was that, if I could not do a step right the first time, I was incompetent. Well, it turns out I was incompetent, not due to lack of desire, but rather to lack of experience. Nonetheless, I beat myself up. It took me a good while to accept the fact that that the odds for getting something right on the first attempt are not in my favor. So, I let myself off the hook and did the mature thing. I planned for my failure. I accepted that I was going to get it wrong the first time.
When doing something new, such as cutting truss rod channels, I practice many times on a piece of cheap pine before attempting the cut on an expensive slab of exotic wood. I want to achieve mastery in the safest, most inexpensive way possible, Once I get achieve success working in pine, I practice again on a scrap piece of exotic wood. Then, I make the cut on the piece I plan to use for the instrument. I call this the committed cut. If I blow the committed cut, well, it's a significant impact. The odds of success are much better when I accepted that I was going to blow it on the first attempt.
Figure 2: Plan to mess up. Making a mistake on a throwaway piece of pine (left) is a lot cheaper than making a mistake on expensive woods (right).
The same can be said of software. The first time I write code for a project, it sucks. I just don't know enough. I need to do it over again, more than once, to get the product right. Agile embraced from inception the notion of continuous improvement using iteration. Most companies in the know understand that the first release will not be that good. That's why we have Alpha code. It's not meant to be production quality. But, we have go through Alpha code to get to Beta and finally onto a version that can handle the stress of a production release. The slogan "It take three shots to get it right" is accurate.
Accept you're going to mess up the first time out. Your life will be easier.
There Is Little to be Saved by Cutting Corners
A while ago, I needed to do some rework putting position markers on a guitar's fretboard. My process requires that I take all the frets off of the fretboard, drill shallow holes for the markers in the fretboard, insert the position markers on the fretboard, sand the markers level to the fretboard, refret the instrument, and then apply finishing. It's a delicate process. If the markers are too high, they will be sanded away and the white dots go dark; too low and the neck gets sanded down too much. If the frets are not level, the instrument is unplayable.
I put in the position markers and did the sanding. When it came time to refret the instrument, I figure, why not save some money and use the frets I removed instead of incurring the expense of using new fret wire, a $20 savings. Also, the old frets were already cut to size and fit the existing neck, no need to incur the labor of cutting the fretwire to size. It seemed like an easy savings.
I used the old fret wire and resanded the existing frets to level. Using the old frets was a mistake. The frets were level, but the fret height of each was not uniform. The top frets were much lower to the neck then the frets at the end of the fretboard. I needed to start all over using new fretwire. So much for my savings. It took more work to not use new fretwire.
Figure 3: Fretboard work is delicate and detail oriented, just like programming. Cutting corners rarely works.
Then I had deja vu. In my early days of software development, I was more than willing to try to rework legacy systems on the cheap, attempting to save money by getting legacy code of questionable value to work within a modern architecture. Sometimes the attempts to adapt old code worked, but mostly not. Not only was money not saved, but most times the cost of shoehorning in the legacy code was greater that the anticipated savings.
Lesson learned? There is little to be saved cutting corners. I should have used new fretwire. I should have let the old system go.
Be Ready to Commit Yourself When You Commit Yourself.
When I am in the process of making a guitar, or software for that matter, I am in one of two phases: I am messing around or I am committed. The difference between the two is that once I am committed, I am going to see the product through to shipping. There is no turning back, no walking away. If I make a mistake, it must be remedied and most times the remedy is going to cost me big time. The product has got to ship. The trick is to make most of my mistakes when I am messing around and very few mistakes when committed. If I have not messed around, I am not ready to commit.
Messing around is a vital part of the development process. The purpose of messing around isn't to ship product, but to develop the skills and sensibilities necessary to ship product. I am continuously challenged to give myself enough messing around time. I like to ship product. Sometimes my overwhelming desire to get the strings on the guitar and hear the sound of the instrument makes me act in haste. When I cut short my messing around time, I find myself spending hours engaged in correcting mistakes that could have been avoided.
Committing myself to the instrument or to the code is a conscious act. It's taken me a long time to understand that commitment means doing the right thing all the time. Saying to myself that I will "clean it up later on" is akin to saying "cleaning this up later is going to take a good deal of time and money."
Messing around stuff is necessary and it is transient. The work is throwaway. The product to which I commit myself will be with me for a long time.
There is a lot of software out there that is messing around code pretending to be committed code. It was never intended to go all the way. It just sorta happened.
If You Don't Pay Attention, You Will Hurt Yourself.
A table router is a power tool that you use to trim and shape wood. It's a tabletop that has a bit that protrudes upwards. The bit spins very fast, cutting away the wood that is brought to it. If your finger accidentally touches the bit, you will lose part or all of it.
Figure 4: Using a table router requires complete attention. Writing good code requires complete attention.
I use a table router all the time. When I do, it's an act of total concentration. There is nothing else in the world but the router bit, the wood, and my hands; nothing else. I know that if I lose attention, if my mind wanders, even for a millisecond, I can hurt myself very badly.
Just about every bug I have made in code is the result of one of two things: not knowing enough and not paying attention. Not knowing enough can be overcome through the iteration process. Not paying attention is mine to own. The best place for me to be when coding is similar to my mindset when working with the table router: It's just the code, the goal and me, nothing else. Otherwise, I will hurt myself. Nobody wants a coder who who has a reputation for writing bad, buggy code.
There Is no Substitute for Working with the Player.
So, I spend a hundred hours making a guitar. I spend days building a great piece of code. I've finished. Now, what do? Put the guitar on the wall and look at it? Check the code into Github and forget about it? Not likely. In both cases, I want someone to use what I've made. In fact, unless somebody is using my creation, it's worthless. It takes the end user to have my product fulfill its intended purpose.
There is nothing in the Rule Book of Creative Construction that says the end user needs to be the last stop of the Road to Fruition. In fact, those in the know work with the end user as an integral partner in the creative process. An educated, experienced, end user has a lot of information that will help you make a really good piece, be it guitar or code.
I talk to my end users continuously. I am always showing them my stuff. I want the criticism and support. It makes me better. It makes the product better.
Of course, many end users get intimidated when faced with the complexity that goes with the work. But, when you as a builder/developer break through that complexity and present the player with informed choices, the level of involvement goes up for all parties. End users want me to make a good product and I want to make a product that is pleasing to the end user, whether that product is a musical instrument or a piece of software.
Putting It All Together
Let's face it, coding is not guitar making, or cooking, or sitting down and tickling the keyboard through a few of the Chopin Etudes. It's a distinct discipline requiring a special set of skills and experiences. Also, coding is not a manual activity. Other than slamming away at a keyboard, all the work is done in your head. On the other hand, lutherie is essentially about working with one's hands. So, how do we connect the two? As I mentioned at the beginning of this piece, I can't help but notice that those who a really good at programming, are really good at crafts, too. Their heads and hands are wired together into a complete whole. Each experience contributes to that whole. Coding is not a separate thing in life, but a facet of a unified life. Luthiers are craftsman. They are determined to become better at making beautiful things that matter. And, as those of us who have been coding for a while understand; making beautiful things that matter is what it's all about.
About the Author
Bob Reselman is an enterprise software developer and aspiring luthier. Bob is Director of Architecture at Casting Networks International. CNI's software is the market leader that connects agents and directors to actors, actresses, and models worldwide. You can contact Bob about code or lutherie at email@example.com.