For those uninitiated, pair programming is exactly what it sounds like — two developers sharing a screen to write code together. One person typically navigates by recommending steps while the other mans the keyboard. Many tech consulting firms, Presence included, encourage or require this practice — not only to catch bugs early, but also to help engineers share knowledge of a codebase.
Some of our students thrive off the symbiosis and chatter happily with their partners; others simmer with resentment, as if they’ve been tragically saddled with the class slacker for a group project. No matter the reception, Ken and I stand firm — we repeat, like broken records, to “talk with your partner!” We promise that they will reap the rewards.
I didn’t know anything about programming’s best practices, much less care about them, two short years ago. Before working in software engineering, I worked in glamorous West Hollywood at a less-than-glamorous job — as a paper-pushing personal assistant to a film director. For a little over a year, like so many other freshly minted film school graduates, I played the roles of HR team, accounting department, and office manager for my production company — that is, if I wasn’t canvassing downtown with movie posters or penning Valentine’s cards for my boss’ girlfriend.
Being a Hollywood assistant is a notoriously thankless job, and working in show business was as grueling as it was breathlessly glorified by everyone who wasn’t in its trenches. Yes, there was that afternoon I shared an extremely awkward elevator ride with Charlize Theron. Or that time I shook sweaty hands with Rupert Grint at a casting call. Whether these episodes were worth fielding surprise calls from my boss on Saturday nights was unclear.
After putting in my dues and realizing two years too late that I didn’t particularly envy my boss’ job, I cleaned out my desk and packed my bags for Silicon Valley to make something of the Ruby on Rails hobby I’d picked up in recent months. It wasn’t until I physically landed in San Francisco and enrolled in a web development bootcamp that the full weight of my naive decision sank in. I was one of the few students with no STEM background, and one of six women in my 40-person graduating class. I was unemployed in one of the most expensive cities in the country. I was, in short, out of my depth. Failing to complete the program, which at the time of my panicked epiphany seemed likely, would be both excruciatingly humiliating and costly.
For the first time in my life, I had the sickening feeling that my absolute best was not good enough. With other endeavors, simply “trying harder” or putting in longer hours had always fixed whatever problem I came across; my rewards were directly proportional to the amount of effort I put in. With development, the longer I blindly banged my head against a problem, the more amorphous and inscrutable it often became. I was a creative writer and film theorist. I had no business being in Silicon Valley, managing MVC architectures or trying to figure out the difference between a stack and a queue.
My saving grace was pair-programming. Pair-programming — in essence, teaching to learn — not only gave me the guidance and mentoring I craved, but also forced me to offer the same to others. It broke me down and built me back up as a true student. It taught me to stop searching for shortcuts and to force myself to examine the gaps in my foundation and fill in those deficiencies myself. It taught me how to learn and reason from the ground up. I became a stellar teacher to a less-than-stellar student — myself.
When offered my first software job, I experienced another panicked epiphany — that blundering my way through a bootcamp was by no means on par with tricking employers into thinking I was truly an “engineer”. I was one of two women on the engineering team and the only person who did not have a computer science degree. I went through every day terrified of being found out for my incompetence.
And yet, I got through these growing pains — not because I was a genius of a developer, but because my teammates valiantly took it upon themselves to shepherd me in the right direction. They pointed me towards tutorials and cheat sheets. They set up environments for me; they installed things for me. They took precious time away from their own work to pair-program with me.
The development community, to paint with a broad stroke, is a community of autodidacts and “ex”s — ex-designers, ex-marketers, ex-filmmakers. We know what it’s like to start from scratch and fight through wall after wall of frustration. We pass on any help we can, not because we are saints, but because we know how it felt when we first arrived in the Wild West of Web Development.
I teach, and I demand that my students teach each other, because I’ve learned that being a good student puts you in a position to be a good teacher, and that being a good teacher cements the concepts you learned as a student. Besides, progress in this industry is far from a zero-sum game — the more information that is shared, the more everyone benefits. We developers are incredibly lucky to work in an industry that both allows us to build on the achievements of others and constantly challenges us to do the same for our peers.
Even though I am in my third year of development, I would be lying if I said the imposter syndrome didn’t still flood back full-force every once in a while. When it happens, I am shuttled back to those late nights, wading bleary-eyed through Stack Overflow questions, praying for a solution to my umpteenth bug before the sun comes up.
These days, though, the feeling lasts just a few minutes. As soon as I feel my wheels spinning, I’ll tap my neighbor on the shoulder and ask if he can pair with me in a few minutes. He’ll glance up from his screen, eyes still a little unfocused from having just torn himself away from his own work. He’ll cheerfully nod “yes”.