Sunday afternoon I saved the day. You may not have read about it in the Seattle Times; it was kind of a subtle thing, but I think it made the world a little brighter.
I was in town helping to run a weekend workshop and at the end of the event, the teacher wanted to play a musical selection through the P.A. system. The sound team couldn’t get it to work, so I swooped in, fixed three separate problems, and averted. . . well, honestly, probably not disaster, but at least, mild disappointment.
The interesting piece for me was reflecting on the parallels between what happened that day, and what we do here at Art & Logic. Maybe some specifics would be useful:
- The first problem we encountered was that the iPhone being used for playback simply made no sound. This was easy to fix. The phone was plugged into a mixer – a device that combines multiple audio sources and then sends the result out to a speaker or a recording device. Mixers can be kind of complicated; in this case, there were a few different volume controls involved, and one was simply turned down.
- After bringing up the volume we noticed that the audio was being obscured by a pulsing digital noise. This one was a bit trickier to solve. I had a hunch that there could be interference caused by the phone’s cellular system interacting with the amplifier – possibly unshielded wiring somewhere. I quickly switched the iPhone into airplane mode and the sound cleared up.
- We still weren’t out of the woods. Now the audio was playing, but slightly distorted. Assuming that the iPhone had an amplifier of its own that was driving the headphone output, and thinking that this could be causing the output to be too loud for the input of the mixer to handle, I turned down the phone’s volume and increased the mixer volume by a similar amount.
All of this happened over the course of about 30 seconds, so we were quickly able to proceed, and the weekend closed out to the lovely strains of Elgar’s Cello Concerto.
So why does this matter? I like audio, I understand its basic principles, and I used that understanding to solve a problem. So what? I would suggest that there are important elements to understand here that can spell the difference between success and failure on a complex software project, too. Here are some that I identified:
- The audio team that day was new, and not deeply trained. They knew which wires to connect, and which knobs to turn to achieve different results. If the teacher’s mic is too quiet, turn this knob up. At the end of the day, flip this switch to off. That sort of thing. When a workshop (or software project) is sailing along smoothly that can be enough. When it comes up against the rocky shoals of an unexpected problem, however, it’s important to know what those knobs represent. One needs to grasp the underlying functional principles and understand the architecture and the purpose of the system. This level of intimacy with the problem domain provides a mental model that allows one to extrapolate, predict, and adapt.
Teams at Art & Logic are comprised of people who have taken a deep dive into the software development pool. People who really know the back alleys of at least some languages, frameworks, and toolchains, and who know when they need to augment their knowledge of a newer technology, whether through further study or by consulting with a colleague.
- When they looked to me for support that day, I knew I was going to do whatever it took to fix whatever problems arose. Playback needed to work and I was the last resort. That commitment is something we talk a lot about here at Art & Logic. We say that we never stop pursuing a successful outcome for our clients, or more colloquially, “work sticks to us.” Just having the confidence that you can get something done, and making a commitment to see it through, is a powerful thing. I’ve seen that quite frequently at Art & Logic, and developers with that self-assurance are more likely to instill confidence in team members and clients, through a sort of resonance process. Obviously, that confidence needs to be well-founded, but developers generally don’t make it in the door here when that basic competence is lacking.
- I was willing to take a chance on a hunch, but also to place that hunch in a theoretical framework, not just to wiggle wires and knobs about randomly. “If this is cellular interference, it should disappear when I disable the cellular function of the phone.” Having a hypothesis in mind before taking a chance is an important way to focus attention and effort, and, on a software project, it’s a critical ingredient of efficient and fiscally responsible debugging. It’s easy to get caught up in making changes to code to fix something, without asking the question, “what specific thing will this particular adjustment tell me about why things aren’t working?” Sometimes you need a Hail Mary pass to shake things up, but the result should always be to try to add to your understanding of the problem’s details, not just to grab the ball and throw another one.
I have a variety of skills and talents that allow me to perform my job well. I really enjoy seeing these show up in other areas of my life, too. After 25 years, Art & Logic has learned that great developers don’t just know how to write code; rather, they have a temperament and inclination that helps them guide projects to successful conclusions. We’ve managed to bring this lesson to Recruiting, asking ourselves questions like, “does this developer approach other aspects of her life with the clarity, organization, and adaptability we’d hope she could bring to our projects? How does she learn new things, keep track of personal projects, communicate with us?” The result has been a long run of successful projects, and project teams who make it look easy.
