Founders at Work.pdf

Joel Spolsky 359
For example, Ruby on Rails is a framework that you can use with the Ruby
programming language to access databases. It is the first framework that you
can use from any programming language for accessing databases to realize that
it’s OK to require that the names of the columns in the database have a specific
format. Everybody else thought, “You need to be allowed to use whatever name
you want in the database and whatever name you want in the application.”
Therefore you have to create all this code to map between the name in the
database and the name in the application. Ruby on Rails finally said, “It’s no big
deal if you’re just forced to use the same name in both places. You know, it
doesn’t really matter.” And suddenly it becomes much simpler and much
cleaner. To me, that is an elegant hack—saying, “This particular distinction that
we used to fret over, just throw it away.”
I don’t know if that’s what makes a good hacker. I guess that would be
answering a slightly different question to what’s a brilliant hack. I guess a brilliant
hacker is someone who comes up with a brilliant hack.
But it’s also a programmer who gets into flow—sort of what Paul Graham
describes as an animal. I see it specifically as a programmer who sits down to do
something and they get into a mental state where they’re just cramming away.
They’re just generating stuff and the time is passing and they’re not aware of it.
They’re just typing, typing, typing, typing, and great things are happening
because they’re in that particular mental state.
I think probably there are a lot of workaday programmers working on
upgrades to Enterprise Java (now I’ve insulted all the Java programmers) who
never achieve flow. To them, it’s just kind of engineering step by step; it’s never
the magic of creation.
Livingston: Is that what makes a good software company?
Spolsky: To me, building a software company—and this is kind of hand-wavy—
is creating the factory that was going to be equipped for, when I have an idea or
when somebody has an idea, we can throw it into the factory and get the working
code at the back.
The first time we ever did this was last summer with Copilot, where we took
four summer interns (three programming interns and one marketing intern),
and we had this idea for a particular way of doing remote desktop assistance. It
was a pretty obvious idea, and we looked out in the marketplace and there were
not any compelling alternatives. We realized that, lo and behold, we could do
this with four summer interns in one summer, because it was not that big of a
programming problem. There was a neat hack where we could reuse somebody
else’s code. We could accomplish this with a small amount of effort and it was a
business opportunity, so for the first time ever, Fog Creek was actually able to
take an idea and, within a few months, churn out the solution to that idea on a
fairly small scale.
My goal is to build a company where I can take much more significant
ideas—where I can say, “Golly, backup software is really, really terrible. It’s
awful for all kinds of reasons. Let’s make good backup software.” That’s a big
project. I want to have the organization that I don’t have yet where, when we