Recent takeaways from pairing
In July I received a welcome visit from an experienced work mate, to enable a week of pair coding. Having had a head start in coding a web app for a mobile application (built with Xamarin), our objective was to quickly knock it into shape and ship it out.
During the time of pairing, I learnt even more lessons than previous pair programming sessions with other programmers. Here are a few of my main takeaways:
1. Do less
I was constantly reminded of how the best programmers have less to focus on. A change of context is a huge price to pay. For example, on Jannie’s desktop he uses it as an actual physical desktop, and that means he one has ONE thing on there that he’d be working on! I thought that was genius as sometimes I struggle between juggling different projects. The simple fix here, is really, out of sight – out of mind. As simple as that.
As a result of this, I simplified my work environment by getting rid of Homestead in preference to Laravel Valet, and quickly hashed out a script that allows one to get and store whatever project you want to work on. You can grab it here: bash script
2. It’s all about maintenance
During the time, we got to discuss about tools and which ones make sense and the ‘why’s’ behind that. In Jannie’s mind, as far as I could read, it all boils down to maintenance and doing things easier. He was very clear that frameworks succeed not because of any sort of flashy-thing, but because they are solving current problems better or in a much more easier way to manage. This little tidbit helped give me context why we have so many competing frameworks and the pitfalls of just following any one thing because it’s deemed “hot”. One has to take the time to know why it’s hot, on a more practical, applicable way to your problems. Don’t code blindly, ask questions.
3. There are no stupid questions
Being able to ask why x is x and not called y is just a good feeling! To get the most from pairing with someone who is better, I’d say ask away to get all the context and understanding you need. I think it really defeats the purpose of pairing if you still walk away from a session with questions in your head because you let your ego get in the way.
4. Good code is produced in cycles
This is sage advice but something we constantly overlook. Good code is not written the first time you write something. In our case I discovered once the tests are green, that’s when real learning occurred when we started tweaking for performance, maintainability and documenting the reasons why we chose one method over the other.
There are more lessons to share, that are more technical than this one so keep an eye for my next few posts. Thanks for reading!
This post first appeared on Chiko’s personal blog at chikomukwenha.co/