The other day I attended a tech talk hosted by Facebook. Their internal platform team was talking about how they manage the Facebook framework and code base.

The presentation was titled “Code Is Written To Be Read”.

Immediately my gag reflex kicked in. Code is written to be read??? Really??? I literally can’t remember the last time I sat there and thought “hmmm, how readable is this code, I wonder if so and so will be able to understand this”. Having said that, I think I was the only person from a startup in attendance, most were from Google, Zynga, and other larger tech firms. So perhaps I was the wrong audience for this topic.

Whatever their problem is, it is not mine. In my world I have one reason to write code – TO SHIP.

“Code is Written for Users to Use It” (i.e. just ship or shipping is a feature) – that is the startup equivalent mission statement.

And this is where all the “maintainability” coding trolls come in and leave comments like “yeah, but it’ll be huge advantage if we can iterate quickly and get a v2 out and so on and so forth, thus we need code thats easy to maintain”.

No.

Here’s the reality – your product is likely going to fail, so if you wasted time and money making fancy abstractions, doing code golf, and focusing on elite coding craftsmanship… you blew it. You failed. You should have finished it 2-4 weeks earlier instead.

You have to EARN maintenance as a problem. You have to EARN v2. You have to EARN the right to practice expert craftsmanship. If you get there, if you really get to the point where maintaining your code base is a problem for you where many other developers are reading your code… congrats! You’ve succeeded. Go nuts, rewrite everything. You deserve it!! Forget every word I am writing, and go attend the Facebook tech talk and take diligent notes.

But for most of us, we are not going to earn that right. We are going to fail or pivot or leave or get acqui-hired or whatever. That code is going to get thrown in the trash never to be touched again. So how’s that clever FactoryOfTaskFactories abstraction feel now?

And that’s why you probably don’t want to hire Facebook or Google engineers for your startup. And more so, if you are a new grad engineer who aspires to be a startup founder one day, that’s why you don’t want to join Facebook or Google.

Look, it’s not that there is something wrong with those developers. I’m sure working at Facebook or Google is fantastic. It is the closest thing to a tenured prof position you can get in this field. The problem is that they operate under significantly different operating conditions than you do (unlimited money, unlimited time, lots of technical resources, working across massive teams, etc + MASSIVE scale problems, huge performance requirements,petabytes of data, etc). They learn a very different craft than you do.

Your craft, the startup developer craft, is simple – “get things done”. The other parts of the craft, you have to earn.

(caveat – if you are building a startup focused on platform or tools being used by other developers, your craftsmanship should be excellent)
(disclaimer – I have nothing against facebook or google, they are full of friends of mine and other wonderful and smart ppl)