I write to you from beautiful and astonishingly cold Waterloo, Ontario, Canada, where the people are kind and the excitement is palpable. (Really – everyone’s excited about what they’re doing and about sharing it. It’s great.) I did a new talk during the morning session about what I learned from my life in editorial that applied to dealing with code reviews as an engineer. Slides to come; for now, I have a written-out version for you over at Truss.works.
In the meantime, enjoy a picture of me in a tuque provided to me by a kind-hearted organizer so I’d be slightly less likely to die on the trek between my Airbnb and the university. I like it here.
Pair programming at 5 pm? Better grab a couple of these.
I knew before coming to school that the Hackbright day leaned heavily on pair programming. During the first five weeks, days unfurl like this:
Lecture
Pair programming
Lunch
Lecture
Pair programming
Break
More pair programming
Profit? Or collapse onto BART. One of those.
I am told that it’s not a super common practice for tech companies, or at least not outside of training or special projects. But I know that people learn better if they have to learn, discuss, and then teach. I know that the general level of knowledge in the room rises if we have to work through problems together, combining what we know to make a greater, more effective whole. One of the reasons I decided to go to a school like this is that I have a well-documented tendency to read about how to make this loop or that data structure, nod to myself with some satisfaction, consider it learned, and move on.
That is a great way to learn some vocabulary terms; it is a piss-poor way to learn programming.
And it’s part of why I decided to go to school rather than going my usual autodidact way. I knew that, with the structure of school and the requirements of a major final project, I would have to read, digest, and then practice. I wouldn’t really learn anything otherwise. And that meant pair programming, with its constant verbalizing, sharing of knowledge, and immediate application of what we’d learned in lecture. Sounded great to me. Sign me up and tell me where to send the deposit.
I was right about every bit of it. Pair programming is a stellar communication tool, and, when paired with available expert help, it’s like having your own half-a-tutor. You learn things from them; you have to explain things to them. You really learn.
That said, I’m pretty excited to get to the second half of my program, because it means less pair programming and more time slogging through my project by myself. And it is absolutely not because of the people I’ve been paired with, who have all had good manners and and the good grace to teach me things.
I hate pair programming because I am a hard introvert with only so much social energy in a given day. The first week at Hackbright, I met about 40 new people, found myself in a new city where I have only two friends, and also had to talk through assignments with a near-stranger for close to four hours a day.
I’m surprised I didn’t actually melt into an Odo-like puddle in a bucket.
I’ve kvetched about this to my advisor. To friends. To fellow exhausted Hackbright students. And yet I’d never advise them to change this part of the curriculum, because I really can’t think of a different, better approach.
Instead, I’ve just dialed back how social I am. I have more lunches alone; I take quiet texting breaks. I don’t go out very much. And it’s a bummer, because I have access to 34 other aspiring software engineers, and so many of them are so very interesting.
But I can hear their life stories while I eat my reheated pizza, or I can have brain to solve programming problems. I can’t have both. So I retreat and read, and I use my social energy very carefully.
