I've been meaning to write more about my experiences crewing on a Formula Ford team this past summer. I'm not a mechanical expert by any means. Given my interest as a kid, you might figure otherwise. I grew up memorizing the specifications for entire lines of automobiles. Mind you, the specifications never meant anything to me as I never really opened the hood and worked on any cars. As I got older, I even stopped memorizing the specifications of cars as my focus turned instead to computers. So when I started crewing, I was probably way in over my head and more of a nuisance to the rest of the crew than anything else.
The guys on the crew were fantastic though. They were passionate about their racing hobby, and the passion showed. It always does. They were also patient, often having to sit down and explain to me basic things like what a breaker bar was (turns out I'd used one and never learned the name). I eventually settled into a groove, being able to do basic maintenance on the cars between racing stints. I also gained an appreciation for the mechanical trade. I think many software developers can learn a lot from car mechanics.
First, mechanical nomenclature is a precise science. A wrench is not just a wrench. It is a box-end wrench, or an adjustable wrench, or a socket wrench. Moreover, I never heard a request for just a type of wrench. The precise size was always given in addition, and if one could not be established, an accurate estimate was given - "Paul, can you hand me a 5/8" box-end wrench?" Once I'd memorized the nomenclature, fetching tools for somebody became very efficient.
So, you might be asking how I can draw a parallel here. Well, to some extent good developers are exempt here. But many software developers have a poor grasp of programming nomenclature. The good developers reading this will scoff, but they may also empathize. I have encountered programmers that could not place the following labels on an appropriate location within an XML document: "attribute value", "leaf node", "data node". They aren't necessarily stupid programmers. Instinctually, they know what these things are. They just haven't bothered to learn the nomenclature. They don't think it is a very big deal. Yet these are often the same programmers that can't help themselves out of a bind. They can't find solutions to problems they encounter because they have no way of precisely articulating what they want to do. Go ahead and try finding the answer on Google to "how do I retrieve the attribute value from the current HTML node" without being able to say "attribute value" or "current node". It's difficult isn't it? Now, type that query into Google and see what pops up as the first result. So, lesson number one: nomenclature matters more than you think it does.
The team had a wealth of tools. There were tools that we had in duplicate: an expensive version we used in the paddock, and several cheaper versions we would haul up to the circuit and risk losing or handle harshly. There were tools that we might only use once in a blue moon, but that we always had rapid access to when required. There were tools that were extremely convenient to use, but were never used frequently, because they were never the best to use.
This lesson has been discussed exhaustively amongst software developers, and yet I still think most simply do not grasp it. Use the right tool for the job. I think most developers don't fully understand this tenet because they simply do not know how to use enough tools. Learn Perl. Learn Bash. Learn Microsoft PowerShell. Learn C++, C#, and Ruby. At least be familiar with what tools are available. How can you possibly use the right tool for the job if the only one you know is VB or Applescript? You don't have to be a wizard at every tool. I often saw mechanics tend toward the use of one particular sub-type of a tool because they subjectively preferred it. That's fine. You can still be passionate about your tools. Do you think Emacs vs vi is a heated debate? Try talking to a mechanic about welders. Which one is better, a TIG or a MIG? Though, I would be willing to bet you would not get an either-or answer as you would from the Emacs vs vi question asked of a programmer.
Finally, learn how to interpret what people are telling you. Don't listen for what you want to hear them say. After every run, the mechanics were always interested in drivers' feedback. Was the car feeling loose? Was there over-steer? Did they hit anything? In listening to the drivers, they often understood everything they needed to do. When this information was not sufficient, they would often turn to me. I was the data acquisition guy. I would run around with a laptop after each run and download data on the onboard computers, which recorded a number of sensory inputs like wheel speed, latitudinal and longitudinal acceleration, engine temperature, and engine speed. Not only were the drivers proponents of these systems, but the mechanics were too. It allowed them to objectively measure the results of their work "“ and find out when the drivers were lying about not over-revving the engine at turn 10! The numbers never lied, and we were usually able to deduce problematic phenomena such as excessive wheel spin, or sub-optimal gearing (there's a whole other discussion: what I learned about optimizing computer programs by racing cars).
This brings us to the last lesson for programmers. Don't just accept feedback from your users. In addition, actively engage them and seek out feedback. The good developers do this. They want to know what works and what doesn't. They know there is always a better version of their program out there, just like the mechanics always knew there were a few more tenths of a second in the car if only they could extract it. Finally, where human feedback is insufficient, resort to computer generated metrics. If your program is reported to be "slow", learn how to use a profiler. When allowed to observe the execution of your code, it generates graphs that are strikingly similar to the ones that racing data acquisition systems generate. You'll find the bottleneck, be it memory bus bandwidth, the CPU, or I/O, and be able to engineer around the bottleneck and/or optimize it.
It was surprising just how many parallels I could make between software development and car mechanics. The two professions aren't as different as I thought they were. Like I said, I gained a lot of respect and appreciation for their trade. All that grease on their hands and clothes hides meticulousness and precision that fellow logically minded folks can only marvel at. One thing I wondered is whether they would have a similar respect and appreciation for my work if given the chance to observe me in my natural habitat.