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 tubas 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. Instead,
the repair person is responsible for determining which repairs are worth the
money to do.
On the other hand, many developers try to create the best
solution possible, regardless of need.
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; but
the reverse should be true.
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.
A few final notes
By reading this blog, you may think that I’m trying to put
band instrument repair on a pedestal.
Keep in mind that my goal here is not to compare 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.
No comments:
Post a Comment