Pair Programming is a term that has always made me want to giggle with its obvious connotations and offshoot euphemisms, but in terms of learning a new language, pairing up with someone can help keep you focused, motivated – even accountable. Saying “I don’t know” shouldn’t make someone feel vulnerable and subject to judgement –  but having every possible remix of “Call Me Maybe” as their ringtone might.

I’m entirely convinced that the person who coined the term “throw them into the deep end” was also the proud owner of one of those dinky turtle shell pools in which underage fraternity brothers love to party as much as 3 year olds love to pee. As developers, we’re often tossed into this technical deep end, and it can feel like that first 10 meter dive, not wanting to look down and all too aware of the potential of some serious swimsuit relocation efforts at the end of it, or worse, having to deal with photographic evidence of said incident.

Part of the appeal of working in this industry, is just how fast things can change. The buzzwords speak for themselves – from cutting edge to bleeding edge to even losing that same edge. At times, the pace can be overwhelming making the cookie cutter production line type of work momentarily appealing. According to the recruiting world, Steve Ballmer got it horribly wrong with his sweaty Developer chant. We are not just developers, we might be Gurus. Or Rock Stars. Or the never-seen, never-heard-but-can-undoubtedly-code-like-a-badass Ninja, because that is what Ninjas do when they have clocked out of stealth mode.

Job descriptions make developers out to be even more legendary – requesting 10 years of experience in a platform that has only been around for 5 or listing every language ever used expecting expert knowledge in all of them. It’s not realistic, but to a certain degree it is expected, and it’s that expectation that makes a developer’s job interesting and inherently challenging. The only predictable thing about our work is that it’s not. No amount of education can prepare you for this universal truth, it can only be understood by doing.

As a student, there are few lessons that can be learned from an instructor that have more use or value than those learned doing actual self motivated project work. Hours spent lost in complete frustration cursing every inanimate object within eyesight in five different languages, none of which you know but just sound right – ensures that there is little chance of that happening again. Those hours lost are annoying, but they are not wasted. Those are the hours that differentiate between a developer than can do and one that knows.

Back to the deep end I go. This time it’s to learn Objective-C. And for the first time, I’m fortunate enough to not be doing it alone.

Meet Ben. Ben is my Objective -C study partner. I am sure that there is little part of Ben that will hate me in the very near future for repeatedly asking him 100 million questions in the tone of that insatiable 5 year old why . Until then, I will keep asking. And asking. I’m sorry Ben, for both my present and future self. Cut to me submerging Ben – using him as my own personal underwater step stool so I can breathe air instead of water. Please accept my apologies in advance, Ben.

I’m confident enough in what I don’t know to admit that Objective-C used to scare me. I learn most quickly by doing, and often I’m learning something new mid-project, which requires a certain amount of fearlessness. This time, I’m approaching it a bit differently and the experience has been far more rewarding, because partnering up with someone else means I’m far more motivated. Self-directed learning needs to be focused, and with my attention span optimally being that of a caffeinated squirrel , it also needs to be distraction free. Working with someone else, we’ve done a few things that have really helped expedite the process, and perhaps these ideas will help someone else.

1. Get a book

It’s been years since Ben or I have used a technical book as a primary way to learn – thanks to things like Stack Overflow, Quora, blogs – even our IM list. We purchased the Big Nerd Ranch Guide to IOS Programming based on another IOS developer’s recommendation. I ended up using the Kindle Cloud Reader the most – it just seemed to fit my workflow better than a hard copy book or the Kindle device itself. Technical book publishers – you are all missing one feature – and that is the ability to see the publication’s errata in context. When following a technical tutorial based book, it’s confusing when examples don’t work or code doesn’t compile, and having the errata overlaid or accessible on the actual text would make that entire workflow much more efficient. We followed the book, but it wasn’t the main way we learned. The book provided the structure needed – but we often digressed from the book as well. This book is definitely one of those technical publications that are worth every single penny – we can’t recommend it enough.

2. Adopt Agile Principles

Each morning starts with  Ben and I conducting our own version of the agile  “stand-up” meeting. Yesterday’s accomplishments, today’s goals, and current obstacles are shared. Show and Tells allow us to discover alternative ways to solve similar problems.  We created a backlog of items we wanted to learn or determined to be most applicable, prioritized them, and we hit those up and share our learnings.

3.Create Small Defined Challenges

We try to push our learnings by creating small, well defined challenges. We define the parameters of these challenges and give them a time limit. Although we do these separately, we share our solutions as we go along.

4. Practical Application through a Project

Working on an actual application – with features and functionality defined, gives a greater purpose to our learning efforts. A book will provide a great structure, but a self directed project can teach you much more, much more quickly. So as we do these other things to learn the language and ultimately the platform, having a small project provides the best context to apply and forward those learnings.

5. Distraction Free

Seriously? Yes.
This means :

• No Social Media – Twitter  (I think a little part of me just died writing that – or at the very least I’ll be making that ugly cry face while having a tiny flailing fist tantrum)
• Headphones –  ambient music (start here: MUSIC TO WORK TO: Chill & Ambient Instrumental Mix)
• Shut down the IM (and email)
• Ensuring others respect this – which might mean blocking time off on your calendar to notify other people that your time is currently dedicated and focused somewhere else.

Oh Pair Programming – let me count the ways that I can make fun of you. Admittedly, I’m thankful that Ben isn’t sitting next to me, pointing out that missing colon while I’m awkwardly pecking at the keyboard with two digits,  silently praying that he isn’t reading my growl notifications. But I’m also thankful that he’s on the same journey that I am and more importantly – that my creative cursing at compilers is both heard and appreciated. Learning in a pair has provided the much needed focus  - with a soon-to-be completed iOS application along with a relatively clean google search history as proof.

Looking for more developer discourse?
Introducing Blocker
Team Development Tip: VirtualHost
Try and Try Again – Why Prototyping Matters.
Chrome Extensions Are Good for You
The Parable of the Preloader
Overcoming shebang (#!) without Javascript
Getting Inspired with WebGL