The super smart robots over at Thoughtbot recently asked me to do a video on the main idea from my Pycon 2010 keynote that everyone in a small startup should learn to code. Given that this is the the one year anniversary of the talk, and that loads of people have email/talked/tweeted me about it, I figured I’d recap how the idea has worn over the last 365 days.
(PyCon for those that don’t know is the annual developer conference for the Python programming language)
Originally the talk started as a thought experiment around removing unnecessary inefficiency from startups trying to act too much like “real” businesses by functionalizing too early. To that end, I took a pretty liberal definition of what “coding” was. The gist though— to get everyone involved in the mechanics of how the product/service is built— has graduated to almost conventional wisdom at least among the most capital efficient consumer Internet/SaaS businesses that I’ve seen over the last year. It’s funny to me one year after mentioning Y Combinator as an interesting “experiment” that its become a legitimate source of some really high quality startups with relatively low inefficiencies in the maker loop between users and product. You could see this even back a year ago— but 2010 really proved to be YC’s coming out year.
The following are the notes from the PyCon 2010 keynote that I gave on February 21, 2010. Because I hate those slide sharing widgets, I’ve tried to put the relevant slides inline with the text of the talk. You can also just watch the video here.
When the organisers for the conference asked me to do this talk, it was in the spirit of getting an entrepreneur who has gotten a small group of people to believe that they could get out there, beat the odds, and make something that didn’t exist before. The bonus of getting me was that at every startup I’ve been a part of— either as engineer, manager, or CEO, I’ve always found a way to use Python as a strategic weapon, a tremendous source of leverage, to make that small group of people much more productive than the big companies that can— through the force of sheer mass— crush you like a bug.
However that is not what I am here to talk about today. What I am going to talk to you about is a crazy proposition, one which will make anyone here who has ever worked at a startup suck in their breath in disapproval and wonder why they let the crazy on stage. Even if you are working for a medium sized company, or one giant tech companies, you’re going to find what I am going to say to be controversial.
Are you ready?
I think every employee in a web startup— or in fact any company which depends on software in any meaningful way— should learn how to code. From the slickest sales guy to the most obstinate operations guy, from the laziest intern to the most professorial manager, if they don’t have their hands in the code, your startup is much more likely to fail.
So I’m going to talk about that to try convince of your jobs as Morlocks in the companies you’re working for, have started, or are thinking about starting. Then we’ll fly over why Python is the best language I’ve seen to date in my career to implement this new regime— something I don’t think will be controversial— so that we can get to the meat this, which is thinking about what we can do better as a community to enable this future state.
Oh yeah, and if you stick with me, I promise that along the way I’m going to tell you about just what these AIs that are coming to rule all will think of this, and why it matters.
So that I don’t forget to do that, I’m going to put up some evidence that I’ll get back to at the end of the talk.
See that? That’s a message the AIs sent to me— every day for a year beyond when it was even relevant. So you can tell that these AIs will be ruthlessly intelligent. But we’ll come back to that in a bit…
First, let’s talk about everyone in your startup hacking. And specifically, what I mean here.
For starters, I mean that everyone should be able to run the dev stack (because everyone should be able to run the full dev stack and in the era of VMware, there is absolutely no excuse), every person in your company should be able to check out the source, make a change— and now for the craziest of all of the ideas, everyone should have commit bits… and even be able to push to production.
Let me give you some anti-patterns in the form of the kinds of things you might hear from people that should make you look to change things around:
Not: I was a CS major but now I am a VP from central casting in charge of synergy. Not: I could work on the code, but I focus on architecture. And certainly not: I’ve got an Excel spreadsheet of the changes I’d like to see to the signup page.
Or my personal favourite: “I’ve built a new way for users to edit their projects” (pointing at a Photoshop document).
I mean real, bona fide, hacking on some part of the source tree. By every single person in your startup.
Let’s face it: most startups have between 10-20 people in them. Even the mega funded ones get to about 100 people. In fact if you look at the data, here in the US, 98% of businesses are fewer than 10 people. Are you telling me that you can’t find people who either know how to program, or learn to program?
Whenever I bring this up with engineers, or with technical founders, this is the point where I get the polite nod and the smile which means “yeah right, not on your life,” or even better: “maybe for your trivial little service, but what we do here is HARD.”
Well guess what? While parts of what you do may be hard, a healthy startup is like an organism: you’ve got complex parts like the brain or heart, and dead simple parts like the big toe. And anyone you would ever hire in a startup should be able to work on the big toe if they need to. And trust me, there are a lot of toes in your typical web service.
Let me give you some quick examples.
First, any healthy web services lives and dies on analytics, which is usually the first place where business people cross engineers. “Yeah, can you run this report again excluding holidays?”
Then there are the basic tweaks to the presentation tier— usually simple HTML changes that almost anyone can do. Or changes to any of the other types of templates that generate the stuff that goes to your customers. In my mind, this is the gateway drug to turning the least technically minded person into a hacker. Get a decent marketing person hooked on making a change and directly seeing the effect in production and they will most likely be hooked. I bet you’ve never thought of Django’s template library as the marijuana to scripting’s cocaine.
But what I am going to argue here goes much further than that. I want you guys to write your systems so that core parts of the functionality can be exposed to this new class of casual programmers. You want for instance to be able to make it so that your typical PM can move flows around for the sake of experimentation. It may never make it to your production service, heck it may never make it to staging— but just being able to mould the clay will pay huge dividends, especially with the folks who need to figure out really tricky user facing things.
I’ve got a personal agenda here which is born out of something I’ve seen at places where I’ve worked before that is unhealthy— especially for small companies. Traditionally, there has been this separation between “business” things and “technology” things, with people that do one or the other.
This is a false dichotomy. It probably has always been. In fact, the company that bought my last startup, HP, is widely credited with giving birth to Silicon Valley. And it was started by these two engineers from Stanford, Hewlett and Packard who built measurement and testing instruments out of a garage. But they also sold them, kept the books, did the hiring, and even swept the floors and cooked the lunches. They did it all. For something like 3 decades. Because it was healthy.
And however true this was back in the day— it is an order of magnitude more true now that we live in the Internet age for two basic reasons: first, unless you are scaling to bazillions of users, the technical concepts are much more graspable by the non Morlocks. And second, because the Internet presents a new channel to get customers, everyone can take an interest in selling.
By the way, this is Pycon and I’ve got a room full of hackers which is why I’m encouraging you to build your startups out of people that can either program, or want to learn how. If I got invited to talk at the Dunder Mifflin sales conference, I’d be telling those EloiEloi that they need to teach you guys to sell, sell, sell.
But let’s take this from another angle: let’s talk for a minute about some of the “best practices” we’re seeing in the world of startups out there today.
There is a guy named Eric Ries who is on the talk circuit as a sort of Tony Robbins for startups. Eric’s core argument is that many more startups fail than should, mostly because they aren’t quick enough to validate their assumptions about how their customers will or will not take to what they are building. A startup that does this correctly— a “Lean Startup” in Eric’s terms— does it by tightening the loop of implementing, deploying, testing, measuring, and fixing product features. He preaches about all sorts of good stuff that in my experience the best startups do already without knowing what to call it: continuous integration, one-button deploys, automated smoke testing, etc.
In my experience, the Lean Startup model is so right for the web that soon enough, it will be jacks to enter for everyone building services (as I said, all of the best folks are doing it already). So we need to take it to the next level.
Let’s call it the Emaciated Startup.
At the Emaciated Startup what you need to do is to get everyone to the point where they are capable of making the kinds of changes that help to accelerate tighten the feedback loop. This is going to seem scary. And uncomfortable.
A marketing droid with commit bits?
People will tend to get territorial about things. But if you do it right, it will tighten the loop and give you massive competitive advantage.
Trust me, there is a reason why the most productive periods in any startup’s life are when you’ve got just the hackers in the garage. It’s what is right about the Y Combinator model, and what is so utterly broken about the way that software gets written in big companies.
If you truly adopt this way of doing things, you’re going to break some eggs. At Tabblo, I took one too many red eyes from Silicon Valley to Boston thinking that I was some sort of crazy ninja who could rewrite some big part of the system that hadn’t come out correctly while sick and hopped up on Nyquil and worrying about some investor presentation that I hadn’t done or some other equally scary first time CEO thing.
But if you’ve got a good team of Morlocks, if they’ve got good hygiene around testing and automated build and deploy, you’ll absorb bumps like this and be much better off for it. And the stories I could tell you on the benefits could easily take up the rest of my time here today.
However this last example gets me to something I want to mention about everybody coding: if you do this, you’ll be able to enforce commit reviews in a way that is healthy for the entire organisation. I’ve heard that at Google every commit is reviewed and I think that is a good thing— in fact it is such a good thing that it probably ought to be part of the culture anywhere from day one. Use Trac and make the timeline a clear and very public part of everyone’s daily routine. Tell people to stop wasting time checking Twitter 20x a day and instead check the timeline!
So let’s get on to why Python— and this ought to be really quick.
As far as I know, Python is the only language that gives you enough dynamic range to be able to pursue the kind strategy I’m talking about— you might even call it the “High Dynamic Range” programming language. For those that don’t know the term, it’s from a technique from digital photography where you get incredible pictures by being able to span a much great range of exposure within one photo. Similarly, the throw-away script that wraps a few of the objects in your system can be written it it while at the same time allowing those objects themselves to be also written in it.
This is a big deal, and something that is not to be taken lightly. Maybe Ruby could do this (though it has some landmines that Python doesn’t), but I don’t know of other languages that could span the gap well— no matter how many frameworks I see in PHP, Java, or Perl, they all end up looking like… what is that phrase about the bacon maker and cosmetics again?
A side note to all of the people pushing Erlang, Clojure, Scala, F#, Haskell the Rascal or any of what I like to call the Ewok languages (Ewoks are cute and cuddly and all have tremendously adorable names— so much so that you want to hug them. But spend a few days in Ewok village and you will quickly discover that they are as disposable as hamsters).
Get Real People.
The science fair attitude around all of these is great right up until you have to a) hire people b) use external libraries or b) be able to read and understand the code that was written by folks coming up to speed on whatever the new paradigm your fringe language was trying to introduce when they first learned in 12 months ago.
I don’t have to tell this crowd this, so I won’t belabor the point, but Python is modular enough, object oriented enough, non crufty enough, performant enough, and batteries included enough to fulfil 95% of the tasks that your typical web startup will need to do. And for the other 5% there is always C and C++ — the languages where, as someone said here last year— “when you crash, you crash in the real world.”
So, if you are with me thus far you’ve heard me argue that I think in the future startups that succeed will be have an unfair advantage if they can make everyone who works there into some sort of a hacker who can work on the organism that is the company’s product. I’ve just flown through why I think that Python makes the most sense if this is the approach you want to take. To bring it on home, I want to spend a little time giving you a few thoughts on what I think the Python community, and you guys as Python developers can do to make this future state more likely to happen.
But before I do that, let me go back and ask a very self-serving question: Why? Even if you are with me thus far and buy the notion that a startup where everyone is a programmer is more likely to win, why should you care that they pick Python over say, Ruby?
Two reasons: first, startups that “win” tend to take part in a positive feedback loop for the improvement of any given language. Look at Python and Google for instance, with the contributions around Unladden Swallow we just heard about. Python gets to thrive much the way that a remora thrives by developing a symbiotic relationship with a big fish. And the more startups that use it, the more lottery tickets you get that one of them will turn out to be a big fish. Or, as is probably more common, eaten by a big fish.
But enough about that, let’s talk about what today’s community can do to get the new startup employee coding. There are basically three types of activities I see are very relevant with this goal in mind:
1. Continue knocking down the FUD 2. Add more batteries to the standard library
3. Fix packaging (of everything)
The first, removing more FUD, is not one that I am particularly worried about. When you spend close to two years of your life fighting an internal IT bureaucrat about why Python is a toy language that is not fit for production, you hear all of the FUD. And then for bonus, they hire consultants to come up with more. But let me tell you, with one exception, I am not worried at all about the FUD.
The one place where I think the community ought to spend a little more time taking the FUD on directly is in the 2-to-3 transition. Backwards incompatibility is scary, for real. As is the fact that, as a relative outsider would, when you spend a little time with Google diving into the question of where the centre of mass is on this moving to 3 question, you don’t get that warm fuzzy feeling of a community that has whole heartedly made the decision to move on any kind of a consistent timeline.
I am not arguing that it is necessary for people to move to 3 as soon as possible. Not at all. But I do think that there needs to be more thought put into sending newbies and curious souls the right message about what the “official” thinking is on where to start, and how to think about the move.
It’s curious thing though that when I came to Python, the bulk of the community was in a state of transition from 1.5.2 to 2.0 and I don’t remember feeling like this was an issue at all, so perhaps I am wrong.
And finally on this one— and just to show you how much communication matters, early on at HP, I ran into someone who said to me: “So I hear Python is going to move from 2.6 to 3000! Can you tell me why you’d use something that has evved 2997 times?”
Moving on to the second suggestion, let’s talk about adding more batteries. I suspect that this is going to be a controversial one to tackle mostly because this fight must go on all the time with what to put in and what to take out given the limits of testing, bugfixing, etc., but I wanted to touch on it here because I think the overall philosophy of including more and not less has helped Python be as successful as its been.
My own take is that Python needs more web stuff in the standard library. realise of course that my whole perspective here is around how good of a language Python is for building web startups.
I know that it is really hard to put stuff in the standard library, mostly because the pace of development needs to slow down which means innovation slows down. Which is why I wouldn’t argue that that shoving an entire web framework is an awesome idea. But how much innovation are we really seeing with libraries like httplib2 and BeautifulSoup? Or PIL? Or for that matter, all of the database drivers?
I have great faith in the core team and in the greater Python community as a whole. The other day at the language summit I saw a blend of ambition, thoughtfulness, and pragmatism that made me think that this is a group that will sort this out well.
The only point I am trying to make here is that we should redraw the line of what gets considered further out— especially around web stuff. More is better when it comes to thinking about making new programmers effective. And as Tim O’Reilly first argued, the WebOS is the new OS that matters. And no matter how many companies like Apple are trying to silo us in their proprietary “App Worlds” (for those not from America, let me give you a hint: anything that ends in “World” is just a cheap thrill that is going to given you food poisoning and drain your wallet— Disney World, Sea World, etc.), or Facebooks that are trying to get us into a modern-day version on AOL to feed us pokes, ads, and Farmville animals and have us crap out cash, we need to remember that this WebOS— open and available to everyone, iterative, and belonging to no one vendor or beholden to any proprietary technology— is probably the most important technical legacy we’ll leave to our kids.
More batteries, more batteries, more batteries!
The third thing I’m going to mention seems to have become a bit of a whipping boy as of late: packaging. And when I say that I really mean Capital P Packaging which includes both the distribution of software, and the way Python itself is presented on Python.org.
Let’s start with the first one: as someone who has now been using Python for about a decade, across as I said a number of companies both big and small, I find it remarkable that I still have so much trouble wrapping my brain around how to install new versions of anything on a given system.
So first there was depending on the OS distribution mechanisms, be it .debs, .RPMs, or something else. I liked this way but we then got distutils as the “official” mechanism which looked pretty great because it would free us all from the tyranny of OS distributions that weren’t staying up to date. Except of course that wasn’t goo enough so we then got setuptools and easy_install which brought us eggs which are awesomely self contained except when they break or clutter up your PYTHONPATH in which case you can always just go to PyPi and get another one to mix with your virtualenv configuration so that your package gets installed correctly on top of the stuff that you’ve already installed in the 3 other forms for the version of Python you think you’re running before smoke starts coming out your ears and you decide that maybe the life of the Morlocks is not for you!
Anyone ever run into this particular kind of doom loop before?
Now one of the reasons I gave up Java was because I discovered that CLASSPATH was dangerous to my health. Spend one all-nighter debugging some Java web application only to discover that someone has jimmied in a custom class loader to load the EJB mumbo jumbo persistence beans that happen to leak memory AND clobber your namespace and you’ll realise why.
I’m afraid we’re heading in the same direction, which is bad enough for full time dedicated coders and completely anathema to the everyone hacks movement.
I don’t know what the answer is, but I know what it needs to look like: one solution to rule them all. And I know this is a super tall order for an open source community with intelligent and passionate geeks involved, but please please help avoid the packaging train wreck.
The good news is that at the language summit, Tarek provided a blueprint for this. And get this— it comes with a poster (see anyone of the folks with the HP badges for your very own FREE version of this printed).
Now it is your job to get out there and push this. Push it hard. Packaging is one of those non sexy things that just needs to work, and yet, left without direction, we will almost all do the wrong thing.
In fact, I’d go further: giving a geek a half finished packaging solution is like giving a child a Sawzall to build a treehouse— sure, something will get done— but not before a few fingers end up on the ground.
Before I close on this one, let me just highlight something about the big “P” Packaging which is the Python website itself. Now, it has come a ways since it’s 1985 Compuserve L&F days, but I think that as class, the language websites for the open source languages could still benefit from some basic user-centric redesigns. They are prime real estate and seem to me to be drastically under-utilized. Think of this way— some of you may know the location on 5th Avenue right under Central Park where Steve Jobs has built a giant glass mausoleum to Apple. This is some of the best real estate in NYC and for that reason it moves a lot of people to give Apple cash.
If that location is python.org, it feels to me like what’s there today is something between a food truck and a government office building. There is tons of information there, and quite a few tasty morsels to be had, but you’re not going to linger.
There are loads of great designers out there, many of which we should be able to get to take this on purely for their portfolio. And what is more, there are great product management people that would be thrilled to help bring us from 1992 to at least the outbreak era of Web 2.0.
Here, let me show you what I came up with by enlisting an hour of time from my own favourite designer (someone I’ve worked with for a while now and who I think rocks this type of thing). It’s not there yet— but it is a good start towards 1. getting the clear messages across, 2. being Designed by one person with taste and experience (remember Shuttlerworth’s comments yesterday), and 3. moving a lot of stuff to other pages.
Let’s not forget big P packaging.
Ok, let me wrap this up with some Cliff Notes:
The ideal startup today is one where everyone hacks. It is your job to be the Morlocks who both set up your infrastructure to do this, and teach your Morlocks how it’s done. Python is ideally suited for this.
But, it’d be good to work on a few warts.
Oh yeah, I almost forgot— the AI thing. Do you guys want to hear about the AI thing really quickly or do I let you get to the coffee break?
Ok so there are loads of people who are totally disillusioned by the prospects for general purpose sentient AIs— a whole load of burned out computer science professor/LISP hacker types that Google has been hoovering up (which is why some think that the AI has already arrived and just happens to live at Google).
But a few years ago, a really creative and inventive self-published writer named Daniel Suarez wrote an absolutely killer book called Daemon which detailed a more insidious AI-driven future— one where sorts of narrow AI programs come to cause a series of events that literally unhinge the entire world. I’m not going to go into plot spoilers here— but suffice it to say, that it’s a sort of cron meets Terminator dystopian story and if you like that, you should definitely check it out.
Well as it happens a few jobs ago, I put together a distributed job scheduler/manager thing in Python that I then set about to teach all of the non-technical people at my company how to use. My very non technical CEO didn’t get far to learn how to actually make any changes in the codebase, or do any of the things I’ve argued for today, but he did love the idea of cron-like tasks and set about making one of the junior admins write a series of cron jobs that would make my email inbox phone light up like a Christmas tree with colourful messages that he would craft every time something went wrong. And then— gateway drug style— he decided to start adding his own special messages.
This one was the most popular with me (referring to another system), mostly because it kept chatting with me for close to a year— after I had already left.
It was the closest I’ve ever come to thinking that we Morlocks might want to keep this stuff to ourselves.
And still, I think we shouldn’t avoid it. And hopefully, in the decades to come, when all of these Morlock inspired cron jobs recombine in a crazy way to deliver this particular vision of the future, we— who started the whole mess by teaching everyone to program— will get some of that Cylon-like love the humans get in Battlestar Galactica. Or at the very least, a confused ambivalence about our continued significance as the progenitors of this better world.