Paul Graham got a lot of flak recently for something he didn’t say about the ability of women to found startups.
We can’t make women look at the world through hacker eyes and start Facebook because they haven’t been hacking for the past 10 years.
As he explains, that didn’t sound like anything he’d say, and in fact is the opposite of what he thinks. The journalist neglected to put the quote in context and left our a crucial word. The actual quote was,
We can’t make these women look at the world through hacker eyes and start Facebook because they haven’t been hacking for the past 10 years.
And the question was about why his startup company couldn’t accept more women into their startup class and train them to be hackers. So he was answering a question about why it would be impossible in three months to turn someone who wasn’t a hacker into one. It had nothing to do with the skills of women hackers or really anything at all to do with women. It really had more to do with what makes a successful founder of a startup.
A lot of small software companies (some of which become large later) are founded by people who are “scratching their own itch”. They run across a problem in what they are doing and solve it. If they had the problem, odds are good that others did too, so they publicize their solution. There is a long history in the open software movement of doing just that. Many of the tools that programmers use every day are the result of sharing their solution with others. The web runs on Linux and the GNU tools and both were started by people who wanted to solve a problem that they had, and it turns out that others had the same problem and were interested in cooperating to solve it.
This hacker mindset is not something that can be taught in three months. I’ll give an example of what I’m talking about on a small scale. My server guy got a new job about a year ago. I know a little about server administration, but had to learn a lot more to keep them running. I got a bit of practice setting up a server when we moved ours from a dedicated server to a VPS. And then I set up one for my nephew. And started maintaining one for someone else. Now logging into a server isn’t hard, you use the command ssh loginid@servername and then type in your password at the prompt. And for my server it wasn’t hard since the commands were usually stored a few lines up in my history and so I just had to use a few up arrows to avoid typing. But with four servers to log into (two of which used numbers—not domain names) I had a harder time finding the lines in history and remembering the passwords for each site. And that’s where the hacker mindset comes in. The command line interface that I use is called bash and it lets you write login scripts and aliases. You can get really complicated with scripts, but I just wanted a shortcut to log in to my servers.
So I wrote an alias to get into my server, ¯server=’ssh loginid@192.168.194.220′, then all I had to do was type server and I could get into my server. And then I wrote an alias for each of the servers that I work on.
But if there is an update that needs to be applied on each server, I want to make sure I do it for each one, so I wrote a simple one that listed all of the servers and then I’d type in the number of the one I wanted to use. My command line prompt looked like this.
loginid@My-MacMini: ~ $ connect
1) server
2) dave
3) don
4) purple
5) Quit
Select a server.
Then I set up each of the servers to use secure authorization, so that I didn’t have to type a password, it used a public-key encryption method to verify that I was allowed in.
Now when you are working on lots of servers, you sometimes forget where you are. So I decided use a different color prompts for each server. One looked like this: loginid@server: ~ $
I copied the login script to each of the servers and tested it out. I decided to make some changes and so I had to copy it to each of the servers again. That’s not especially efficient, so I wrote a script that I run when I make changes and it automatically pushes the script to each of the servers.
Here’s the part non-hackers don’t get. In order to save myself 30 seconds of typing a few times a week, I read a 300 page book about bash. I spent probably three days in total working examples and rewriting my script. I’ll probably never save three days worth of time. But now I have a new tool in my toolbox, that I can use to automate some processes—in fact I’m going to automate the process of updating WordPress blogs when I finish this post. And that’s what can’t be taught in three months.