Programming has now become the on-demand job. We have seen a rise in the number of people who want websites. This could mean a simple way of doing business intelligence or direct traffic to their site. Some may also need to or do some email delivery to their clients. It would be nice for this skill to be taught in school but then programming is all about you owning your learning (YOYO). It involves continuous learning since the languages are always in a state of flux; some get left behind as others gain more adoption.
Starting out as a programmer might be intimidating with all the unstructured data on the internet. More often than not when starting out, we lock ourselves in a room with our computer, hot pot of coffee brewing and immerse ourselves into tutorials. Learning this way may sometime lack inspiration and empowerment especially when you hit blockers. To be more productive, I took to pair programming encompassed with collaboration.
What Is Pair Programming?
This is a practice in which two programmers work side-by-side at one computer, sharing one screen, keyboard, and mouse, continuously collaborating on the same design, algorithm, code or test. Essentially, one person acts as the driver and the other as a navigator. The driver writes code whereas the navigator observes the work, thinks critically, proofreads and determines the next move. The two can interchange the roles for maximum productivity.
What’s the Why and How?
Sometime back, my colleague and I set out on a journey to explore this paradigm. Both of us wanted to share and fill our knowledge gaps. So we decided to pair program. We defined a road map of what we wanted to learn. This acted as our goals for the learning period. Each day we held a five minutes stand up session where each of us shared what we had learned individually in the past 24 hours, the challenges we faced and what we planned to learn in the next 24 hours. Thereafter we would dive into an hour of pair programming. My colleague would write some code or do some integration while I watched and asked questions since he was more experienced than I was. Occasionally we would switch roles and I would be the driver as he observed. This helped us maintain our concentration and maintain optimum levels.
Takeaways
Pair programming proved to be better than code review since bugs were identified immediately when code was written rather than waiting for someone to check your code at a later time and give you feedback. I found out that I made fewer code mistakes that when I code alone. Maybe because someone was looking at me code or due to the fact that there was we were disciplined enough to adhere to best code practices. I got to understand in-depth how system and software work as well as appreciate different thought processes. As they say, there are many ways of killing a rat. And I experienced that in terms of decision making with regards to the best data structures, algorithms, etc.
On the other side, disengagement or distraction of one of the participants may affect the overall productivity of the pair. It is also possible that conflicts might arise due to different thought processes. Having tried it out, I can comfortably say that the practice works well when learning to code for the first time. It saves you a lot of time and teaches you how to work in a team which is a highly sought-after skill by most recruiters.
