Blast from the past
I recently had reason to check one of my older email accounts and found what I can only assume was meant to be the first blog post of a series that never happened. As such, I thought I would share it here to see what wisdom (if any) the 2011 me had.
I have recently been pairing with someone who does not have an in-depth understanding of the code that we are working on or even the processes we are trying to implement. I regularly find myself in a bind. The bind is that I have a holistic understanding of the code base (having written or paired on a majority of it myself) and I have trouble trying to ensure that I am not just sitting there implementing the code or just giving directions on what to type next v’s times when I sit back to try and allow my pair to take the lead. The issue being that when I do sit back and try and let my pair take the lead and implement the next section of code I get feedback saying “if you know the solution why don’t you share it”.
How do you find a balance being ensuring code gets written, making sure that it is a team effort and not feeling like my pair is just a passenger.
Given that the project itself is under time pressure, I often find myself falling into a trap of being a keyboard hog and just sitting there are writing code and trying to explain my thought processes as I go, with the only input from my partner being agreement that he understands the reasoning behind the code.
Looking back on this post, I find that even after all these years I still have the same feeling now that I did then.
On the plus side, I have found better ways of working with junior staff members and new starters, ways that allow me to impart the knowledge I have to others without missing deadlines. Hopefully, some of my thoughts will help others out there who feel as I once did.
Work to their speed not your’s
Sure it’s important to work quickly, but if the company thinks it’s worth the time and effort to train someone, then why argue against that.
It good to get stuff wrong
Maybe not for you, but it’s really the only way people learn, no one really listens when people tell them something doesn’t work, they have to experience it for themselves.
Don’t preach, at least not too much
Always try your best not to infect people with your belief’s. Guide then, tell them about yours if you must, but let them form their own. Rant warning: Convincing juniors that spending time learning the full vim syntax will make them better developers is a pet hate of mine.
Have fun
Remember that it’s fun to code, make sure you keep it that way when you pair.