The Journey Day 8….
Each one, Teach one
When I started classes for web development we were introduced to the “Rubber Duck” debugging method. “What is the Rubber Duck debugging method?” you might ask with a head scratch. Before you envision setting a rubber duck next to the screen and telling it to debug your code while you walk away, it’s not quite like that. The Pragmatic Programmer: From Journeyman to Master is a book about computer programming and software engineering, written by Andrew Hunt and David Thomas and published in October 1999.
As the story goes, a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line-by-line, to the duck. Sound a little whacky to you? Hear me out a little on this. There are some rules and structure around this process lest the unaware passerby happen upon you and your conversation with your best friend while coding and believe you’ve gone quite mad. As taken from the www.rubberduckdecoding.com website, it goes a little something like this…
Beg, borrow, steal, buy, fabricate or otherwise obtain a rubber duck (bathtub variety).
Place rubber duck on desk and inform it you are just going to go over some code with it, if that’s all right.
Explain to the duck what your code is supposed to do, and then go into detail and explain your code line by line.
At some point you will tell the duck what you are doing next and then realize that that is not in fact what you are actually doing. The duck will sit serenely, happy in the knowledge that it has helped you on your way.
Today I spent most of my day helping fellow cohorts stuck on code, having issues understanding C# and looking for additional sets of eyes on their code. I didn’t really get too much into my own code as I’m rapidly approaching the end of the basic game development code. I spent my time doing what developers learn 101 style when first introduced to coding… I Googled. I searched for different background sprites. I searched for additional spacecraft and enemy sprites and animations. I did research on producing the best looking game play environment that I can while collecting these assets like power ups.
When I wasn’t researching sitting in with cohorts reminded me of rubber duck method. I walked line by line through code, helping to grasp concepts such as how to use transform to change the positions of .position, .rotation and .scale. I went over syntactical structures, debugging methods, Unity setups and such. It was during this time that I started noticing little tiny inconsistencies. “OOhhhh… that’s why my player speed reacts the way it does”. “Oh man, now I see why my controls were initially inverted”. Little things that I found work arounds for but very important things that explained all of the idiosyncrasies that I was noticing about my game.
These moments spent doing rubber duck method decoding is even more beneficial if you are doing it while teaching I found. Whereas the rubber duck doesn’t really have an aural language that we would recognize, working with your team members is rewarding both for them and yourself. It helps them grasp concepts and grow while at the same time helps you to really see those things you say you’re doing but not really doing. In short, the rubber duck method is a fantastic tool.
As defined by Wikipedia, Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.
While reviewing, the observer also considers the “strategic” direction of the work, coming up with ideas for improvements and likely future problems to address. This is intended to free the driver to focus all of their attention on the “tactical” aspects of completing the current task, using the observer as a safety net and guide.
While still doing this remotely, Zoom and Slack allow for screen sharing which makes for a perfect environment for pair coding in this manner. So today I played the role of navigator, reviewing each line of code as it was iterated, while at the same time reviewing my own code. My cohorts did fantastically in picking up the direction that we were going and we were able to help to resolve daily blockers to get projects moving and back on track.
While we don’t really actively employ this strategy regularly in either Lambda or GameDevHQ as a culture, as a budding developer, I want to be familiar with these sorts of structure so I manage my time and efforts utilizing these methods. I can tell immediately why they have become industry standards as well. They are effective. Production and productivity are able to be maximized. Junior devs can help each other logic through functions and methods to arrive at the desired result with effective collaboration. These are the techniques that will help you move into the project lead and eventually engineer roles as your career progresses.
I’ve got to say having a great coding partner is fantastic. Remote work can feel exactly like it’s name implies, remote. So working daily as a team it’s fun to have feedback. Actual, audible feedback, and not the sub-aural quack ramblings of Quackatoa. Not that I don’t really love my duck, Quackatoa (he’s actually an owl but don’t tell him that), but human teamwork is a very rewarding expenditure of time. Having a really cool coding partner also helps immensely.
So now that you’ve heard the case for talking to rubber ducks I know you may be wondering where you can get one of your own. Luckily for you, Amazon.com has a great job board of ducks seeking employment. Don’t believe me? Click the link. Each is looking for their own pay scale but they come in all different shapes and sizes and some even come with their own degree. So the next time you catch a friend sitting at their desk talking to themselves peek around the corner. They may be talking to their ducky code partner whether real or imaginary. Such is the life of a developer. Sanity can at times be in the eyes, or ears, of the beholder.
