Home » Two heads are better than one

Two heads are better than one

I freaked out the first time I looked at CodeWars.

I was fresh from six months of JavaScript self-study. As it turned out, the knowledge I’d shoehorned so painstakingly into my brain was suddenly nowhere to be found. It had abandoned me.

CodeWars is tough. Even the sign-up process requires new users to complete two code challenges. Once in, the list of problems was overwhelming.

My attitude to programming has changed today after completing the Ronin taster day. I still believe that a collaborative, problem-solving approach is best, but until now I haven’t had much opportunity to develop my coding skills in this way. Most of the code I’ve learned and written so far has been done in isolation, as part of my sometimes lonely digital nomad life.

With me today were eleven participants from around the world, all brought together via video-conferencing. The host started us off with a stand-up session, in which everyone introduced themselves and their goals for the day. He explained how Ronin works and what we could expect from the event.

But more importantly, he explained what the Ronin programme isn’t. It’s not a course in JavaScript or Ruby, although those skills are taught in depth. The overall goal of Ronin is to teach its students to adopt a new mindset. It teaches them to think like programmers.

I’ve been struggling with this for a long time, even while being aware of it. Although I’ve learned difficult things from scratch before (Mandarin, for example), there’s something about talking (and writing) in computer-friendly languages that feels overly abstract and hard to relate to. But to learn programming, one must learn to be comfortable in the unknown.

At least I already know that memorising syntax is NOT the way to become a good programmer. As my successful self-taught programmer friends tell me, Google is there for a reason. I fully agree. I mean, why make life harder?

Most programmers rely on Google to look up bits of syntax. They may memorise certain elements of it, especially the most common ones, but this happens through doing. As Jordan said, ‘you just need to be aware of what’s possible.’

Think about logic first, then code. Decide on the sequence of steps that can take you through the problem from start to finish. Only then should you start trying to translate the logical steps into aspects of code.

It’s essential to develop a hypothesis when you start to tackle a problem.Force yourself to use it and don’t assume anything to be the case. Test everything and be explicit about your expectations.

This is where pair programming can be really powerful.

We did two hours of pair programming during the taster day, programming with two different partners and swapping over the roles. This worked surprisingly well even over a video connection. We were encouraged to keep up a constant flow of dialogue with our partner, to explain what we were doing at every step, and ask questions about what they were doing.

At first there was that scary moment of feeling exposed, nervous about looking incompetent in front of a total stranger. But that soon passed and the process became enjoyable and motivating.

Effective pair programming requires communication and collaboration. Working together over a video link demands extra clarity and precision when explaining ideas and giving suggestions. It becomes easier to figure out problems and both people in the partnership come away with added confidence.

I’ve worked as a language teacher and a journalist so my communication skills are already quite well-honed. But pair programming adds a new layer to that existing ability. It’s unlike anything I’ve done before, but I found it very fulfilling and even fun! An hour passed by in a flash.

Now I need to go and practice my regular expressions. Those are tricky!