Previous to joining Pivotal Labs, I didn’t do a whole lot of pair programming.
Hoo boy.
It’s been a little over two months since I started, and the number of hours I’ve spent solo programming since then would all fit in one workday. I’ve had some surprising realizations – about myself, my style, and my abilities – and more than a few DUH moments. This post is more a collection of anecdotes than a coherent essay, but if you’ve wondered what full-time pairing is like, I hope it gives you a few insights.
It does contain some profanity. I blame my co-workers for that.
On Constraints
Pivotal works a strict 8-hour day, in keeping with the agile principle of sustainable pace. But because all projects are paired (you cannot buy the services of a single Pivot – we only come in pairs) everyone has to be in the office at the same times every day. So everyone arrives at 9, everyone takes lunch from 12:30-1:30, and by 6:15 the office is a ghost town.
I knew I’d love the work – and I do – but I thought I’d be fighting the schedule. Nine to six would have been fantastic 10 years ago, but now that I have a husband and two kids…not so much. There isn’t a daycare in the city that stays open past 6, and it’s much harder for me to go to doctor appointments, school events, and all the other kidly activities that are, without fail, held between 9 and 6.
The Punchline
Now that I’m doing it, I love the fixed schedule. At other jobs, around 4pm every day, I’d start wondering about when I needed to leave. I’d try to remember who I was picking up, and when, and then I’d look it up on my calendar, and then I’d text Peter and ask whether there was anything I needed to ask or tell the daycare folks, and then I’d stress about getting enough work done before I had to take off.
There’s none of that anymore. I know exactly when I’m leaving, and since my pair is leaving at the same time there’s no pressure to stay longer to finish something off. When I’m working, I can be completely present. When I’m done, I don’t have to drag a laptop home and check email or fix the build once I get there. I don’t even know how to get into Pivotal’s VPN from home. I walk out of the building at 6:05 with a clear mind and a clear schedule for the rest of the night.
It’s fucking exhilarating.
On Getting Shit Done
Fundamentally, what I love about software development is writing code that people actually use. I love to finish things. So anything that makes me feel like I’m really GSD makes me incredibly happy.
When people talk about pairing, you hear a lot about how it “amplifies” their productivity. I am going to go on record with the truth, however. Pairing does not amplify my productivity. Instead, it erases all the bad habits I have that keep me from being a superstar on my own.
When I’m pairing, I can really get shit done.
By myself, I have a lot of roadblocks:
Rabbit Holes. When trying to figure out some thorny bug by myself, I often follow the wrong line of inquiry too far. I follow it sometimes for the sake of completeness – of knowing with 100% certainty that some factor is not what’s causing the problem – when 90% or even 50% certainty would do. Something in my brain craves completeness, occasionally to the detriment of productivity, and particularly when I am tired (hello, parenthood). I usually don’t notice it when it’s happening. However, if I have to explain to someone else what I am doing, the ridiculousness of it all suddenly becomes obvious and I’m able to break out.
Distractions. If I’m working by myself, I’m on email, I’m on IM, I’m on twitter, oh my tests are running so I’ll check hacker news…and on and on. That time adds up over the day. And of course once I look at my email I’ve switched contexts so going back to my code is another context switch, and even though it may only take a few minutes, that also adds up. It feels amazing to work solidly for four hours at a time on a problem. But somehow when it’s just me, I can’t always keep that focus. I think it’s the addition of the social input and output that lets my frontal cortex actually attend to the problem at hand, without going ooh-shiny all the time.
That, and the guilt trip from my pair when I do wander.
Cheats. If someone’s watching, I don’t take shortcuts. I write the tests first. I refactor code that needs it. I focus on doing the simplest thing that could possibly work, without being sloppy. I make sure I understand what I’m doing before I do it. I’d like to say that I always do these things when on my own…I really would. But the truth is that sometimes I put logic in my view code, because christ, if I move that then I need to put it in a helper and make a new file and add a new spec, and I said I’d be done by the end of the day and it’s 4:30 and no one’s reviewing my code so…I just do it.
But if someone else is watching what I’m doing…I just don’t. That feels incredible.
Too-Clever Syndrome. On the other side, I get excited by knotty technical complexity. I love to dive in and start changing things to see what happens in situations where it would really be better to write some tests first. And, I like pushing the boundaries of the language, but I don’t work on experimental or research code – someone has to read and maintain it – so all the clever metaprogramming is really not suitable.
But it’s so much fun! And I get to revel in how smart I am! It sounds stupid to say that out loud, though. So I don’t even go there.
The Nine-to-Fiver
I often hear programmers – mostly young, mostly single – talk disparagingly about “commodity programmers.” They usually mean people who program at work but spend their free time on other stuff, and aren’t really interested in tech.
Since I became a parent, I’ve turned into that person – the one who needs to leave at a fixed time and can’t work weekends. So for a lot of my peers, that means I’m not “passionate” enough, and that I can’t really be a good engineer. I got that reaction enough times that I started to believe it. Well, fuck that. I know I am amazing at what I do, and I love it. But it’s not my whole life.
Working at a company that really respects the boundaries of my time AND enables me to kick ass and get shit done all day has seriously been a revelation.
Socialitis
On the spectrum of social awkwardness, I fall somewhere between the engineers and the marketing guys. Like many engineers, I miss social cues, don’t make enough eye contact, forget people’s names, and have a hard time making small talk. However, I can fake these skills decently well when necessary, and I’ve noticed that it’s a muscle that I can exercise – the more I do it, the better I get, and the less I have to think about it.
About a month after I started at Pivotal, I went to a UCSD engineering alumni event. At these events, where I am usually the only person not working in Enterprise with a capital E, the social interaction part of the evening is a lot of guys staring at each other’s shoes. In the past I’ve tried to get conversation out of these people, but between their awkwardness and mine it was like pulling teeth. But this time, for some non-obvious reason…it was easy. The people and the shoes were about the same.
It’s me who had changed.
Such a great post. So happy you landed such a rad gig! Looking forward to meeting up once I’m on the west coast this summer.
Great essay! The rabbit holes, agh. Totally understand. Not sure about the UCSD situation, though. Don’t become the shoes! There’s an interesting correlation here between writing for fun, and writing for work. If you have a really good editor, you can do this kind of writing that’s really excellent. But usually, being a “commodity writer” ends up sapping your energy for writing fun stuff. Writing for fun, though, is no boundaries, but also is rarely published/used, etc. Hm.
[…] This post was mentioned on Twitter by sarahmei, Anna Billstrom. Anna Billstrom said: one of my sometimes-prog. partners writes a great post on pair @sarahmei I have drunk the Pivotal flavr-aid. http://bit.ly/dquYE0 […]
I spent a month pair programming at Pivotal. Your observations largely match mine, and are spot on. The heightened productivitity and the 8-hour day were definitely quite satisfying. As far as “cheating,” however, I had the opposite experience: things that I felt were important (like MVC, TDD, and database normalization) were often overruled in favor of just GSD. So although my pairs were all exceptional programmers, it could be that yours were more compatible with your development standards. At any rate, I just couldn’t handle pairing for 8 hours a day and continually losing these battles, so I left Pivotal after a month. Very sad for me, since Pivotal is an amazing place.
I seem to have written one of the few blog articles expressing negative feelings about my pair programming experience. I do make clear, however, that for most people who have used it, pairing is as productive and satisfying as you describe.
http://mwilden.blogspot.com/2009/11/why-i-dont-like-pair-programming-and.html
Great post. I love this line: “Pairing does not amplify my productivity. Instead, it erases all the bad habits I have that keep me from being a superstar on my own.”
@Seth – I’m so looking forward to it too! I love it when the valley gets more awesome.
@Anna – I have trouble writing even for myself, hence the blog that gets maybe one update a month. I’ve been thinking about that too. Pair writing?
@Mark – thanks for that perspective. I’ve been thinking about writing a followup on the Dark Side of Pairing. I do think there is one, though for me the good outweighs it.
@Chad – thanks! That line was hard to write. It felt important, though, to acknowledge that I’ve had jobs where I didn’t live up to my potential. It turns out that sticking me in a room by myself with ticket-tracker comments for social interaction isn’t the best way to get good work out of me.
Chad- that line has stuck with me as well!
Just introduced a colleague into pair programming, and was really interested in what he thought. It was only a few hours, but…
Sarah- pair writing honestly gives me the hives. It just freaks me out. I think I’ve had way too many a-hole editors to consider it positive, though theoretically it should have the same benefit as pair programming, right? Still, it’s personal expression which is tough to do as a pair.
Priceless!
[…] 写代码是我的工作，我也乐在其中，你可以想象一下在某个风轻云淡的炎热夏日，我在面对屏幕在宿舍不停的敲打键盘，间歇时便啜口白开水，然后继续… 一个web应用，从数据库设计，业务逻辑代码，很酷的特性，前端页面和样式一手包办，老实说如果让别人帮我作，我都不放心，我担心他写出东西不符合我的期望，又难以启齿说他写得不好。这样，我发现一直以来都是一个人在写代码，我可以写出一个别人都喜欢用的应用程序，但是却没有人会在看完你写了一段很酷的代码而大声称好，也没有人乐意指出我的不足，跟你说这块代码写的有问题。我觉得很沮丧，就像你写的书无人问津。而即使现在在公司里也不例外——团队之间的合作似乎并不体现在共同参与同一个项目，更多的是一种依赖关系。项目里你负责的部分写好了代码，只要它工作正常，在项目计划好的时间内完成，那就成，没有人在意你写成什么样。我想结对编程可能会是个好主意，但是结对编程绝对是幻想，公司不大可能付出这样的成本，但是我觉得可以尝试，就像Thoughts on two months of pairing说的那样，结对编程真的会解决一些问题，”Get Shit Done”，而且对现在的我来说可以解决我的问题。结对编程的好处是： […]
Thanks for the post. I saw the Pivitol presentation at Railsconf also. We are looking at trying a bit of pairing at my workplace. It will be interesting to see how things go.
Nice post Sarah. On the pair writing, you can definitely do it. In one of my previouls roles I worked with an editor and we paired remotely while working on techinical documentation. It takes a bit to get used to it, and it probably won’t work for everyone. I found though many of the same benefits one gets when code-pairing also accrue when using it for other mediums.
Good luck in your new position.
On the “commodity programmer” – I generally hold the same view.
However, I’ve come to realise the level of interest in doing after-hours coding, moves in waves. For months at a time, I may not do much coding after hours – but may focus on reading about biology or buy a new camera and spend time editing photos and thinking about new lenses or editing old videos etc
Stretching your interests like this may be necessary to generating new ideas and new projects to work on
Great post about pairing. I’ve been working on getting my team to embrace it more, but the initial uptake has been slow to say the least. Am going to forward your post along to help show the benefits of pairing as seen from the trenches. That should help them better embrace my pushing further down this road in the coming weeks.
I often hear programmers – mostly young, mostly single – talk disparagingly about “commodity programmers.” They usually mean people who program at work but spend their free time on other stuff, and aren’t really interested in tech.
I think we have similar but different definitions of “commodity programmers”.
To me, and in other places I’ve heard it, it refers to programmers who treat their work as generating programs in return for pay, and nothing more. That does tend to exclude the folks who have a personal interest in programming and do it in their free time, but that’s not the main criterion.
The key feature of a “commodity programmer” is a lack of interest in either advancing the state of their craft, or advancing their own skills, other than as a means to find a better place to assemble widgets in return for pay. Literally, commodity programmers view their work as a commodity to be produced in order to get paid.
So while the folks who program both as a job and as a hobby are rarely commodity programmers by this definition, there are plenty of non-commodity programmers who don’t practice total tech immersion.
I think pair programming is a combination of getting rid of your bad habits solo and having two minds working on the same problem. It certainly doesn’t amplify productivity but it makes each party more productive.
Re: The section on the 9-to-5er… I know tons of people in all sorts of fields who keep their work at work. And you know what? They’re totally awesome at their jobs. Just because you don’t like to bring work home, and you don’t spend your days and nights coding and reading tech blogs doesn’t mean you’re not excellent at what you do. And anyone who feels superior because they spend their days doing just that should probably take a reality check and then take a break every once in a while and see there’s more to life than that.
That is so true about focus. A lot of the benefits to pairing are intangible. Focus. Gradual dissemination of knowledge about the team as we rotate pairs – not just about the code, but about tools. You make a good point about how helpful it is to have a pair partner there to remind you to do TDD etc. …AgileBill4d
[…] Thoughts on two months of pairing by Sarah Mei – “I don’t take shortcuts. I write the tests first. I refactor code that needs it. I focus on doing the simplest thing that could possibly work, without being sloppy. I make sure I understand what I’m doing before I do it.” […]
I actually thought that the curious cat management blog was ACTUALLY about managing my curious cat. I was slightly disappointed. ):
[…] Thoughts on two months pairing – Sarah Mei reflects on her experience pair programming and the benefits it has provided her professional & personal life. […]
Lovely post. I tried some pair programming but found that there are times where need to keep the God to thyself. Any way, I love the concept and I’m slowly slipping to XP! 😀
[…] Sarah Mei » Thoughts on two months of pairing (tags: pair programming practices experience) […]