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.