Ramping up at Pivotal
When I was on the hunt for a job, I would explain what I was looking for by way of an analogy to a friend of mine, a budding chef. After he had graduated culinary school and worked a few “stages” (STAH-zjes) in Paris, Chicago, and San Francisco, he insisted on coming to New York, and to one restaurant in particular: the venerated Per Se, one of only seven American restaurants to earn three Michelin stars.
Why Per Se? Because it was reputed to have the best-run kitchen in the country. They were said to operate with the urgent discipline of a surgical team. They loved food for food’s sake; they treated their ingredients with a respect you wouldn’t find anywhere else. They gave a damn about the small things.
When I would tell people that I wanted to work for the software equivalent of Per Se, Pivotal Labs invariably entered the conversation. They said that Pivotal was where programmers went to become better programmers. Pivots weren’t so much hackers as craftsmen. They aggressively refactored; they scoffed at untested code. They worked in an unusual way, in constantly shuffled pairs, a method said to emulate a string of micro peer apprenticeships.
The Pivotal approach had a lot of appeal, if only because I had spent the last few years doing something like its opposite, working the quick and dirty way, not among a gang of more capable peers, but in one- to two-man teams that were too busy surviving to worry in any serious way about technical debt or elegant object design or avoiding bad habits, because bad habits kept the lights on.
Of course that mode of learning shouldn’t be sneezed at. I bet the best guys in the business are the ones who built something soup to nuts — guys like Woz, who knew every bit going in and out of the Apple ][. God bless ’em. But for whatever reason when I hit that fork in the trail of my nascent “career” I had the urge to choose, not the gnarly backside, but a way that had been mastered many times before.
When Pivotal made an offer, I took it.
What kind of day has it been
My first few days on the job were not fun. Actually they were full of moments of terror. Most of the time I felt small and stupid.
Everything was new. I had never written a test before. How does one use RSpec, Cucumber, and Jasmine? What’s a factory? A fixture? I knew nothing of my project’s vast conceptual domain, its Kafkaesque ontology. I didn’t know anyone on my team; there were twenty-five or so new personalities to parse, some less scrutable than others. I had edited server config files in Vim but never tamed it for everyday work. I had never used Sass or HAML. I had never asked Rails to do so much.
I carried around a note card on which I desperately jotted commands, snippets, terms, and names, all fragments of a foreign tongue. My overall impression was that I wasn’t supposed to be there. I didn’t think I could catch up. There were too many pieces. Here is a note I wrote to myself the night after day two: “I get the feeling from time to time, with all these layers, that I just want to see the goddamn bottom. The abstractions bewilder me. I thought I knew how to make websites do things. Why do I have to step through fourteen different files to find out how a button works?”
Wasn’t this what the NAVY SEALs did, too? Scare, crush, de-program you? Make a man out of the splinters of your broken soul?
Ironically, I would have been the first person to advocate for this kind of immersion. That’s how I learned to code in the first place: from the bottom up, fighting problems. On many occasions I’ve proudly quoted the Texas mathematician Robert Lee Moore: “That student is taught the best who is told the least.”
Moore’s lovely theory seemed to be breaking down. The presumption that you could just plop a new guy into pairs and watch while the team’s collective knowledge osmosed, well, now that seemed pretty stupid. In fact pairing itself seemed to be getting in the way. If I was lost while pairing, I couldn’t do what I most wanted to do — what I would have done at any other job — which was to peel off and dig in for a few hours. Instead I had to fumble around in front of another coder, asking a few questions here and there, obliquely piecing together a picture of how the thing might work. The further out of my depth we would go, the more I would feel like I wasn’t doing anything. My workday seemed to consist of watching other people write code and floundering when they gave me the controls. I “contributed” by pointing out typos.
The problem seemed to be that the other guy was always too far ahead, enough that I couldn’t get a foothold. I would try to follow along but I’d quickly drop the thread, and with no purchase on the problem I would disengage. I’d get bored and tired, and nervous because I was bored and tired. I had the uneasy suspicion that I was fucking up.
The pleasure of finding things out
What a regretful miscalculation! That discontent of mine, what Feynman might have described as “the terrible, uncomfortable feeling called ‘confusion,'” was nothing but evidence that I was learning, like the soreness after a good workout. In this case it wasn’t my muscles that were growing but my stock of analogies, concepts, images, words, and ideas, the working capital of my mental life. To let that stuff atrophy for fear of strain would have been a special kind of tragedy.
And of course, just six or seven days after starting at Pivotal I began to see things for the second time, now with a little bit of context, a little more of the basic picture filled in. Each person I paired with, and each story we chewed off, sliced through the application in a new way, each slice overlapping, naturally, with the other slices, especially near the semantic “center” of the thing, so that the important parts were reinforced many times over, the rest coming in happy little whiffs.
Since by definition my partner was working on exactly the same thing as me, his mental workspace, so to speak, was filled with all the same elements. Modulo our shared context, what stood out were differences in technique — how we moved among files, used our debugger, referenced documentation, broke problems into pieces, tested, talked, and thought about code. In that way our long sessions together became unusual opportunities to study how the other operated on a micro level, and that, I’d argue, is what makes the whole business of pairing effective. It’s not so much that it spreads units of declarative knowledge — which is after all easy enough to do in a book or e-mail — but rather that it throws into relief the subtle cognitive algorithms and perceptual tics that generally stay private as people struggle individually, in parallel, with the puzzles of the day.
I’ll admit that for a moment there I didn’t think I’d get above water, but less than a month later I’m thrilled to have fought through the anxiety and dread that accompanied — that was supposed to accompany — such a massive transfer of new information, and thrilled, especially, to have done it in the company of Pivots.
About the Author
