Things instrument repairmen do better than software developers

As most of my readers know, I started my career as a software developer as a career change from repairing band instruments. I generally liked fixing instruments, but I eventually decided that it wasn't for me. But because I didn't start my career writing software, much of my outlook on software development is rooted in the way I approached repairing instruments. There are some noticeable differences between the development and instrument repair mindsets, so I thought it would be interesting to come up with a list of things that the average repair person does better than the average software developer. I came up with five, in no particular order:

Right tool for the right job

As a repairman, I learned early on that not all tools work equally well in all situations. Methods for removing dents in a tuba would pretty much destroy a trumpet. Methods for padding a saxophone wouldn't work at all on an oboe. I had one type of glue for saxophones, another for clarinets, and still another for oboes. There are numerous types of hammers to take dents out of trumpets. We did this not only because the right tool saves time and money, but also because the wrong tool could literally do more harm than good.

On the other hand, many developers don't seem to have many "tools" in their toolbelt. They become experts in a particular technology, and then use that technology to solve all their problems. They'll bend that technology to do things it was never meant to do just in the name of staying within one platform. Languages and platforms try to cater to everyone, rather than try to focus on a particular type of problem. Instead, more technology professionals should focus on the types of problems they want to solve, rather than the types of technology they want to use.

Know when to stop

Most instrument repair personnel are very keenly aware of the budget of their customer. In most cases, repairs are done on instruments done by musicians/schools with small budgets or on instruments for young students. In neither case does the customer want to pay a lot of money for the repair person to get it right. What the repairman must decide, then, is what repairs are most important to give the player a functional instrument without breaking the bank.

On the other hand, many developers try to create the best solution possible, regardless of need orcost. While I understand this point of view, we as technologists need to start keeping costs appropriate to the problem at hand. There are times when making sure that the application never fails, moves almost instantaneously, and is built to withstand thousands of concurrent users is appropriate. There are times where one or more of those is not.

Interviewing

When I was first getting into the repair business, my wife (then fiancée) was applying to several graduate schools, so I had no idea which part of the country I'd end up in. So I took as many interviews in each of our possible landing spots as I could. I noticed a remarkable difference in quality of the interviews – some were clearly thought out, while others were clearly unplanned. What they all had in common, though, was that I repaired something for each of them. There was never a question of whether they would check to see if I could repair something before hiring me; the only question was which repairs were most indicative of my general skill level.

On the other hand, I find it shocking how few technologists think of asking potential candidates to write some code during a job interview. With laptops and networks readily available, it would be easy for any company to administer a quick one hour programming exercise to any candidate. Yet most interviews I've been on involved talking about programming, maybe even a whiteboard exercise or two, but very little actual programming work. This makes it much harder to determine if a potential programming candidate is up to the job.

Know the customer

In order to find what repairs are appropriate for a customer's goals and budget, a repair person needs an understanding of what those goals and budget are. In order to do that, most reasonably good repair people will spend several minutes with a customer, asking what their problems are and looking at their instrument, before going over options with that customer.  Having several of these interactions a day allow repair people to become very good at eliciting the short- and long-term needs from their customer.

Software developers, on the other hand, tend more to writing code based on what they, not the customer, think is right or appropriate for a given situation. This isn't entirely the developer's fault; I've certainly had clients who were not interested in having a detailed discussion of different approaches in the development process, so I was forced to guess. I do think that experiences like these cause software development teams to focus on delivering what they think is best unless the customer explicitly says they want to be involved. Instead we should be involving the customer whenever we can until we're told not to.

Find creative solutions to problems

Until recently, there were very few vendors out there who provided a wide variety of tools appropriate for repairing band instruments. Even now, individual repairs quite frequently defy the tools that can be bought. Repairs still need to be done, though, even if there isn't a tool out there perfect for the job. Repair professionals, therefore, must be good at creating their own tools. I mean that literally. It's not uncommon for repair shops to have raw steel, brass, and lathes available for the primary purpose of making tools when an appropriate one isn't available to purchase.

Developers, on the other hand, are much less likely to make their own "tools". Instead of trying to determine how best to fix the problem, and then building software to do that, developers more often than not hand-code the solution. Tools can easily be made to simplify development tasks. I've personally built a JavaScript generator that would create copies of script that could easily be debugged locally, but could be loaded quickly in production. I've used code generators that built abstraction layers over databases simplifying data access and architecture. We need more of this ingenuity in software development, especially in the Microsoft community.

Edit: this is getting better. Since originally writing this post, some developers are much more willing to create their own "tools" to solve particular problems. I would still like to see more, though.

A few final notes

By reading this blog, you may think that I'm trying to say that band instrument repairmen are better at their jobs than software developers are at theirs. Keep in mind that my goal here is not to compare individuals or approaches in the two careers, but instead is to tell software development teams of approaches to work and customer interaction that works well in other industries. There are certainly things that the average developer does more naturally that the average band instrument repair professional, but that's out-of-scope for today's blog. And no, I don't regret the career change; I find solving business problems using technology a very rewarding career in more ways than one.