Current Hackbright engineering fellow Wendy Dherin is deep into her fifth week at Hackbright Academy, and she has been regularly documenting her Hackbright experience. This blog post provides insight into the very first week of her Hackbright journey and reveals some of her first impressions. Prior to Hackbright, Wendy worked in publishing after getting her degree in Slavic Languages and Literatures.
By Wendy Dherin (Hackbright Academy – Fall 2014 Class)
I’ve just finished my first week at Hackbright Academy. So far, it has frankly exceeded my expectations. I’m really happy and having so much fun and learning a lot and meeting impressive women and appreciating the teaching skills of the staff very, very much.
Just to give you some frame of reference, I’ve had my doubts about the program (“is it really worth all that money?” and ”is it was worth doing at all, since I’ve learned so much on my own already?”) and about myself (“what if I lose interest in programming, even though that seems impossible?” and “what if I’m wrong about thinking I’m actually pretty good at this?”).
I waited until the last possible moment to sign the Hackbright contract (I sat with it for several months), because I was so on the fence about having to pay the tuition. I knew that if I did Hackbright and felt disappointed by the outcome, I would have a hard time forgiving myself for spending that kind of money. I did a ton of research, talked to dozens of people, and in the end, I decided to take the leap and sign.
The great news is that so far, I think I’ve made a great decision. I feel a little starry-eyed about it, and I’m sure in time this will be tempered with some some frustrations and disappointments, because that’s the reality of trying to teach 40 individuals to be software engineers in 10 + 2 weeks.
But for now, I’m pretty damn happy.
Why It’s Well Done.
There are 40 of us. We are different. We have different learning styles, and we have different backgrounds. We have different strengths and different weaknesses. We have personalities. We have insecurities. We have had different amounts of exposure to programming already: some of us have been programmers before; some (like me), have already studied programming on their own for a while; some did the prework and that’s it. We have problems and issues and drama we’re dealing with outside of the fact that we’re here, trying to become software engineers in 12 freaking weeks.
This is one of the main things that worried me. I worried about how a challenge as complex and time-sensitive as this could possibly be dealt with a satisfactory way. I worried that I wouldn’t be happy with the pace or the depth of the material. I worried that I wouldn’t get enough one-on-one with the teachers. So far, I’ve been wrong. From everything I’ve seen, the instruction and exercises and attitudes are all designed to address the wide range in backgrounds and abilities.
Most lectures are well thought out in advance and presented in a thoughtful manner. In the lectures, we are given the core information: not too much detail, not too superficial either. For example, even if I’ve already studied the given topic pretty well, I come out of the lecture having learned something deeper and having gained some important details I’d missed on my own. Questions are encouraged and addressed with clarity, consciousness, and a sense of humor. The hours of exercises that follow require us to research and think more deeply about what was covered in the lecture. Each piece builds on the last and prepares us for the next.
And then, of course, there’s pair programming.
Pair Programming: The Great Equalizer
Each day, we pair with a new partner who almost certainly has a different knowledge set than our own. This is one of the many reasons why pair programming is so brilliant, especially in the context of a classroom: If Partner A knows more than Partner B, she’s forced to slow down and explain things to Partner B, and help Partner B work through the concepts. Even if Partner A knows the topic well, she must now explain it to Partner B, which may end up challenging her superficial assumptions about the topic. So Partner A wins because she now understands the topic even more deeply, and Partner B wins because she just got a great one-on-one tutorial on the topic.
Of course, it doesn’t always work out that way. If one or both of the partners don’t communicate freely or clearly, the whole thing can fall apart. So, in addition to the aforementioned benefits, pair programming provides us the opportunity to improve upon social skills and communication. Shy people must learn to speak up if they’re not being listened to. Dominant personalities must learn to be more aware of others’ needs. Impatient people must learn to be patient.
In other words, there is a lot going on.
Maybe I’ve just been lucky so far, but each day of pair programming has been phenomenal. I haven’t yet programmed with a woman who has a larger knowledge set than I do, and I’d like to have that experience, but on the days when I had a larger knowledge set, I’ve gotten a ton out of it.
Sure, I can code something up much faster if I don’t have to hash everything out with another person. But here’s the thing. Pair programming puts speed bumps down in spots where I’ve been cruising through. It’s forcing me to slow down and notice the nuances and deeper significance of the concepts I thought I knew about. Now that I’m having to explain these things, I can clearly see where my grasp is slippery and where it’s not.
Pair programming is a beautiful thing.
Onward.
This post was originally posted at Wendy Dherin’s blog. You can follow her current Hackbright journey there.
Application deadline for Hackbright Academy’s engineering fellowship this winter is November 14, 2014 – We’re only a few weeks away so be sure to apply now!