Founders at Work.pdf

Philip Greenspun 325
Airplane mechanics have a direct interaction with the customer. A lot of the
jobs require two to three people, so it’s kind of social, and I noticed that they’re
just really happy. Programmers are isolated. They sit in their cubicle; they don’t
think about the larger picture. To my mind, a programmer is not an engineer,
because an engineer is somebody who starts with a social problem that an
organization or a society has and says, “OK, here’s this problem that we have—
how can we solve it?” The engineer comes up with a clever, cost-effective solution
to address that problem, builds it, tests it to make sure it solves the
problem. That’s engineering. If you look at civil engineers, architects, they’re all
dealing directly with the customer and going through the whole process.
Livingston: Programmers were off in the corner programming?
Greenspun: The programmers were in the corner doing what they were told.
That’s one reason they were so easy to outsource. If a programmer really never
talks to the customer, never thinks, just solves little puzzles, well, that’s a perfect
candidate for something to offshore. So I said, “I don’t want my students to end
up like this. I want them to be able to sit at the table with decision-makers and
be real engineers—to be able to sit with the publisher of an online community
or an e-commerce site and say, ‘OK, I’ve looked at your business and your goals;
here are some ideas that we can bring in from these 10 other sites that I built,
these 100 other sites that I’ve used.’ And be an equal partner in the design, not
just a coder.”
I wanted to grow people into being able to do that, and I thought, “Let’s try
to make these people true professionals in the sense that lawyers and doctors
and real engineers like civil engineers are professionals.”
Livingston: What would that mean?
Greenspun: They would have to develop the skill of starting from the problem.
They would invest some time in writing up their results. I was very careful
about trying to encourage these people to have an independent professional
reputation, so there’s code that had their name on it and that they took responsibility
for, documentation that explained what problem they were trying to
solve, what alternatives they considered, what the strengths and limitations of
this particular implementation that they were releasing were, maybe a white
paper on what lessons they learned from a project. I tried to get the programmers
to write, which they didn’t want to do.
People don’t like to write. It’s hard. The people who were really good software
engineers were usually great writers; they had tremendous ability to
organize their thoughts and communicate. The people who were sort of
average-quality programmers and had trouble thinking about the larger picture
were the ones who couldn’t write.
Livingston: You had a different atmosphere, such as encouraging your people
to be part of the process. Didn’t you also have educational sessions?
Greenspun: Yeah, and we had very strict code reviews. Basically the whole idea
was to grow the company by having apprentices. We would bring in some
people, and then the handful of people who were already there would work