It’s true what they say, two heads really are better than one.
CodeWars is tough. Even the sign-up process requires new users to complete two code challenges. I bluffed my way through those with the help of Stack Overflow. But once in, the list of problems was overwhelming.
My attitude to programming has changed today after completing the Ronin taster day with Makers Academy. 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.
Let me explain how today’s taster day worked. The entire day’s programme lasted six hours, which seemed like a lot at first. But once the first hour had flown by, I was still feeling highly motivated and ready for the rest.
With me were eleven participants from around the world, all brought together via video-conferencing. The Makers Academy host, Jordan, started us off with a stand-up session, in which everyone introduced themselves and their goals for the day. Jordan explained how Ronin works and what we could expect from the event.
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 succesful 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.
The next update will come soon, as I start preparing for my Ronin interview next week.
Now I need to go and practice my regular expressions. Those are tricky!