This is part 3 in my series of how the Mac reminded me why I fell in love with software development, and why it still matters.
While reading Andy Hertzfeld’s anecdotes (and those of his colleagues) of designing the original Macintosh computer, I was inspired, inspired to take account of my own passions, the passions that these stories reminded me of. Today, I continue that list:
“The Team Pair-programming”
Photo © 2005 Michael Caroe Andersen CC BY-NC 2.0
-
I love to create new patterns. I love solving problems through discovery, inventing that which has never existed before. (From part 1.)
-
I love applying principles in new ways. I love working with abstractions, and turning them into concrete expression. I love challenging the status quo, breaking through the limits of what everyone else says is “possible.” (From part 2.)
-
I love achieving status through collaboration, which is compassionate conflict. I am not a baboon. I do not achieve a sense of status by beating up (literally or figuratively) on my colleagues and friends. But I do expect to be recognized for the ideas I bring to the table, and I want to be taken seriously.
The early Mac development oozed this sort of idea culture. It had to: it was originally a research project. And so you had a bunch of smart, creative people getting together to accomplish the formerly inconceivable. For example, when Andy displayed the very first image on the very first Mac display:
Even though it was starting to get late, I was dying to see if my routine was working properly, and it would be very cool to surprise Burrell when he came in the next day with a detailed image on the prototype display. But when I went to try it, I noticed that Burrell’s Apple didn’t have a disk controller card, so there was no way to load my program…
The only other person in the lab that evening was Cliff Huston, who saw the trouble I was having… Cliff told me that he could insert a disk controller card into Burrell’s Apple II with the power still on, without glitching it out, a feat that I thought was miraculous…
By the time I came in the next morning, an excited Burrell had already showed the image to everyone he could find…
Truthfully, this is sometimes a tough one for me, because I tend to believe my ideas are the best. And when you work with other people, you need to give credence to their ideas, too. And often their ideas aren’t nearly as good as mine!
Seriously, though, some of the most enjoyable professional experiences I’ve ever had have been working with others. My mind goes back to one particular meeting at YCRDI (the makers of Kurzweil® Music Systems electronic musical instruments). We were developing a next-generation synth, some years ago, before the company got bought out and the project was canceled and then the governing authorities nixed the merger but not in time to save our jobs—which is all a long story for another time. But back before all of that, I remember one day sitting at a conference table with one of the other engineers, and we were going through how the user experience would work on this product. And we were both throwing in ideas, and we were both arguing our ideas, and we were both making a difference, helping to make this product the best it could be.
What I bring to the table: I think in abstractions, so I can understand the problem and solution as a single big picture. I see the forest for the trees. I also attend to detail, sometimes obsessively, every semicolon and period in the right place. Once I know what needs doing, I tend toward perfectionism.
What others bring to the table: The ability to see the concrete differences between instances of an abstraction, to see the trees for the forest. And often, the foresight to identify all the ducks that need to be lined up to make a shooting gallery. Rather than “Ready, Aim, Fire,” I tend to “Ready, Fire— Hey, where’s the duck?!” And then I’ll sit around with my gun at the ready, in case a duck happens to waddle by. (Unfortunately, the duck was only an abstraction.)
That’s one reason, I believe why I often work so well with Tom Metro, one of my long-time friends and colleagues. We met at IEC (the centrifuge manufacturer from part 1), while we were still in college, and we’ve worked on and off together, on various projects, ever since. When we get together, he’s the one who asks all the challenging questions that need to be answered in order for the project to be a success. He’s the one who insists on segmenting the project into bite-sized stories and planning out iterations—sometimes with so much dedication that I feel like I ought to gouge out my own eyes just so I don’t have to look at it anymore. But I usually see his point, and he definitely appreciates the elegance good abstractions bring to a design. And beyond that, we share many of the same values and desires when it comes to development: quality, good documentation, efficient and effective processes, interesting problems.
(Continued with part 4.)