Chris Baus

Talkers and Doers

I was fortunate enough to make some stupid decisions when I was young -- when I didn't have much to lose. Number one stupid decision: when I graduated in 1997, I turned down a developer job at Adobe, to work at a start-up called ObjectSpace (yes there was a woman involved, but that was only part of the equation).

Talkers and Doers

Back then I considered myself to be a hot shot OOD guy. I was an arrogant SOB. I jumped on the C++ bandwagon early, and fought my way to a scholarship, and a few jobs based on what was, in retrospect, limited knowledge. I naively believed that with the right methodology I could solve any problem.

ObjectSpace appealed to me because they were all about the new cool methodologies. They drew pretty diagrams, drove Lotus's, and described how to correctly model the employee/roll relationship, while providing elaborate explanations of how it saved their customers millions of dollars. They gave seminars and wrote books. They talked a lot. They were the smart guys. But something was missing, and I knew what it was: working applications.

One day I went to a brown bag lunch, and a lead architect proudly proclaimed that he had used every GoF Design Pattern in a project. What he failed to mention was that the software didn't live up to the customer's expectations. It didn't work. After the meeting, I immediately called the hiring manager at Adobe and begged for the developer position, but it was too late. The bridge had been burned. In normal times this could have torpedoed my career. Fortunately 1997 was not normal times.

Software isn't about methodologies, languages, or even operating systems. It is about working applications. At Adobe I would have learned the art of building massive applications that generate millions of dollars in revenue. Sure, PostScript wasn't the sexiest application, and it was written in old school C, but it performed a significant and useful task that thousands (if not millions) of people relied on to do their job. There could hardly be a better place to learn the skills of building commercial applications, no matter the tools that were employed at the time. I did learn an important lesson at ObjectSpace. A UML diagram can't push 5000 pages per minute through a RIP.

There are two types of people in this industry. Talkers and Doers. ObjectSpace was a company of talkers. Adobe is a company of doers. Adobe took in $430 million in revenue last quarter. ObjectSpace is long bankrupt.

The pencil or the building

When hiring an architect it is common to assess the architect's previous projects: the beach house in the Hampton's, the office remodel in San Francisco, or the tear down in Tahoe. You might ask about the vertical space, the southern exposure, or the placement of the fireplace. You probably wouldn't ask what type of pencil and T square was used to draw the blueprints, or if the architect is left or right handed. Yet we software developers are obsessed with our tools. Our tools define us. We classify ourselves as C++ Developer or J2EE expert. But isn't software really about the stuff you execute, and not the tool used to create it?

When was the last time you asked a candidate to bring in a portfolio of their work, so you could run it -- actually use the developers work, just to see where they put the fireplace? That almost never happens. Instead most interviews focus on the tools. "Can you explain partial specialization of C++ templates?" "At what angle do you hold your pencil?"

I think the first question of any developer interview should be, "what have you shipped?" It is very telling question. You might know everything about strong exception safety, but if you haven't actually shipped anything, what good is it?

Toolsmiths and developers

Certainly there are those that have made careers creating tools: language designers, compiler writers, IDE developers, and even library implementors. But shouldn't the toolsmiths be vastly outnumbered by the tool users? A hammer is only valuable when it is applied with skill to wood and nails. C++ is only valuable when it is used to build applications. What is more important, your knowledge of your tools, or how you apply that knowledge? Language is a means to an end. It is not the end in and of itself. As an application developer, when you evaluate a new tool or technique, you should always ask yourself, "How can this make my application better, or help me develop it more quickly?" If you can't quantify the advantages of a tool, your time is probably better spent actually building software.

When I consider my heros from the industry, I find they are consistently those who understood their tools well enough to build something useful. They include (but are not limited to) David Cutler of VMS and Windows NT fame, Donald Knuth who developed TeX so he could write the seminal work on computer algorithms, and Ev Williams who started a blogging revolution in his bedroom. They are the doers. Missing from the list are the technology experts that litter the covers of trade journals who earn their living giving $1000/week seminars on software development methodologies. They are the talkers.

That's not to say that the talkers don't provide an important service in this industry. They do. They are the teachers, the disseminates of information, and they add to the greater understanding of our craft. I simply hold in high regard those who are able to cut through all the white noise and focus on the end game and not the process. In the end only one thing matters: working software.

Disclaimer: Ok, ok, I know. Just writing this article makes me a talker. Maybe that is part of the irony. ; )

This entry includes a personal account of my time at ObjectSpace, which has been stylized to make a point. There were many smart people at ObjectSpace (which is probably why so many remember the environment more positively), and many have gone onto far greater success than myself. I was unfortunate to start at a difficult time for the company, and it influenced how I viewed the corporate culture. I had high hopes for my career and it was difficult to be in an environment which I felt squandered my skills.

I went from a posh corporate office with Aeron chairs and adjustable desks, to a room filled with developers seated side by side waiting for work. It was a learning experience that I sincerely needed, and I don't regret it in the least. Enough time has passed that it is possible to look back and consider what went right and what went wrong. One thing is certain, it takes more than smart people to be successful in this industry. I can only hope that someday I will understand what the "more" is.