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. – Wikipedia
While we didn’t switch roles frequently, the pair programming I did last week was more of a mentorship of sorts. I was helping a colleague of mine with some refactoring of some test code he had written. I’ve been working with those tests, and in Ruby, for much longer than he had and also over all may possibly have had more experience as a developer in general. He drove.
It was great being able to work with him to solve a new feature file he was working on and I hope that he feels he received some solid benefit from our time together. In addition to helping guide his refactoring, I tried to inform him in some useful skills that I’ve picked up in my quest to learn.
Minimize function scope.I typically open talking about this advising to make functions as dumb as possible. This phrasing probably isn’t the greatest, but what i mean by that is only give a function as much data as it needs to perform its duties.
If you’re working on an API project, don’t pass the request object you get all over the place as it’s not likely everything in your system needs all that data. If it does, I’d recommend giving your project a once over and reconsidering your design. Anyway, if a GET to your API only needs a certain query param from your requet to perform its duties, pull that query param out and send its value to wherever it’s needed!
Working on a function that takes five arguments? There are probably few places where this type of behavior really makes sense and is likely a smell that something is wrong with the implementation.
Specialize your functions to do one thing and do it well.Don’t overload your functions by having them either a) do things they aren’t supposed to, or b) doing too many things at once. Break things out into helper functions if something is doing too much, and turn that function into an orchestrator/controller of sorts. Additionally..
Try to keep your function's tasks at a similar levelYou may find your functions overloaded when they do things like text formatting, looping through a data object, passing data to a helper functions, and more. In all actuality, this function that feels like an orchestrator should be doing just that. Text formatting? Put it in a function. Iterating through an object for a particular reason? Put it in a function.
If you have a function that formats text, that’s all it should do. It shouldn’t be called to format some text and then pass that data off to some larger function to continue whatever process you have going. Just return the data and have whatever called the formatter figure out how to handle it.
Name things in ways that are meaningful and descriptive to you & your readersThere’s the joke that there are two hard things in computer science: invalidating cache and naming things. This definitely comes from a place of truth as naming things definitely is hard! While you’ll hear out there to name things like you would a child, I think that’s an overstatement meant to illuminate how important naming is.
One example from our working together was a function that was named something along the line of wait_for_status. In this function there was a loop that’d retry until a particular API job returned complete. Okay, fair enough there as that seems to match up. What didn’t match up though, was the check of the API’s response for validation of some video types.
I was able to help my colleague more skillfully and thoughtfully reorganize things and that’s awesome! 🎉
If you’ve got questions about pair programming, comments on this topic, or have feedback good, bad, or otherwise: please reach out or leave a comment below!
Thanks for your time and for reading!