Joining Facebook in May of 2011 was quite a shock for me. I had come from 6 years at Microsoft, at a time a slow behemoth so big that it could probably ship software faster if it had less engineers. Facebook was not like that.
Every 2 weeks Facebook would pool its new hires into a Bootcamp class. Bootcamp was to last for 6 weeks, and it included everybody — new grads, veteran engineers and everyone in between. The program included a few talks, but primarily it was about tasks and team selection. Bootcampers were assigned random tasks from across the company so they could get a flavor of many teams and so that the company could get a flavor of them. Completing no tasks was not good.
I was given a laptop and told to sit at one of the many anonymous rows in an unfinished building. I happened to sit by some lively ex-interns — kids still. And while the kids were crushing it, completing several tasks a day, by the end of my first week I was still stuck on my first task, wondering if I’d be fired.
In comparison, my previous job had been easy. Projects were supposed to take long, with plenty of planning time. Now, my planning habits were looking very much out of place.
So I invented a trick that I still use when I need to start on a new project. Let’s call it ‘one wrong line of code’, or 1wloc for brevity.
I say ‘invented’ because I don’t remember anyone teaching me this. It’s entirely possible that it was mentioned to me and I forgot about it, and I’d bet that this idea arose independently several times; maybe it’s even a thing somewhere. But I don’t think I’ve heard of it before it occurred to me.
This is applicable when many things are still unknown. I don’t know how to structure the software (functions or classes or something else), I don’t know where to put it (file names, folder names, projects) and I don’t know where to start. Over time all these mysteries clear, but they can be paralyzing at the beginning.
1wloc goes like this: just open a code editor and type a single, wrong line of code. If it’s an existing project I’ll try to place it in a spot I know how to run, and if it’s a brand new one it will be in a new file that contains only main(). It doesn’t matter that the code doesn’t run, that it doesn’t compile and that it doesn’t even make a lot of sense. As soon as I have a single line of code in front of me, I can leave the abstract planning behind and start fixing it. Putting all the other concerns aside and focusing on just that, I’ll go on to type a second line, and a third, and slowly things will begin to take shape. When there’s enough lines they will move into a function, and then into a class, and then into a file, and we’ll be in business.
The key for this to work is detachment. There’s almost no chance that this first line survives. Very likely it will be entirely replaced by something better as the project starts to take shape. The point is not to produce an enduring work of art, but rather to get your thoughts flowing. What you need at this stage is not the final code; you need momentum to start exploring and figure out where to go next.
Hopefully it goes without saying that never having a plan also won’t work. If you turn 1wloc into nwloc you get nonsense. I find that this technique is a great way to break analysis paralysis, but it needs other companion behaviors (such as planning and iteration) to be successful.
As to Facebook’s bootcamp, I wasn’t fired. I adapted and eventually got the hang of it, going on to have a moderately successful stint at the company. The pressure during those years was formative, and I learned then much of what makes me a good software engineer now. I hope to share a few more of my learnings in future posts. I haven’t fully planned this series yet, but one has to start somewhere. Call it 1wloc for posts if you will.