Tic-Tac-Pairing

working_together

The other night, I met up with my programming partner-in-crime, Deborah, to pair program and finish the great tic-tac-toe project. I’m both embarrassed and ashamed to admit, after uncountable years advocating and observing the benefits of pair programming, this was my first time ever navigating / driving “for real.”

Before setting a timer, we started with a bit of instruction on how to pass and receive between methods. I was under the impression that I couldn’t create a method to return something (bool, int, etc.) without first receiving data of the same type. Why did I think this? Your guess is as good as mine.

With that bit of futility squashed, we set a timer (10 minutes), and started pairing to update my “computer makes a move” method to select a random location on the tic-tac-toe grid (from current state where computer simply chooses an index in ascending order).

I hopped into the navigator’s seat and immediately felt a tinge of discomfort: the guy who needed rudimentary instruction on how to return something from a method was now in charge? There’s a reason kickers aren’t playing quarterback.

I started exploring out loud:

“Currently, the cpu player is looking through each ‘game grid’ index in numeric order, trying to parse the value, and if it can be parsed as int, play the move there.

Instead, what if we create a temporary list with all the valid (i.e., not X or O) indexes, randomly select one from that list, and update the game grid array at the selected index?”

Deborah said something exciting: “Sure, let’s try it.” And she started coding. Wait a second – are you telling me I just… contributed?!

This was unexpected. I had a feeling of enjoyment, real happiness, that I contributed something to move us forward – despite the fact I was working with someone vastly more experienced than me!

Another unexpected feeling: C# is not Deborah’s primary or highly fluent language. As we took turns navigating and driving, we both had to look up existing methods in the .NET library, such as converting from object to int (Convert.ToInt32) and the class that allowed us to select a random index. I distinctly recall thinking to myself, “it’s okay to need help!”

In this moment, I noted an important observation from my coaching perspective. Despite our familiar relationship, agreement to teaching and learning, and absence of workplace stress (e.g., deadlines), Deborah still offered multiple apologies that she didn’t have all the answers, all the time. Even in the space of safety and zero expectations, at times, Deborah felt guilt and needed to check-in with me regarding her vulnerability. This was an important reminder that safety and respect in a team should never be assumed.

As we progressed along in updating the method, we discovered that the computer was often making a move that had already been played. For example, despite generating a list of valid moves, the cpu was somehow choosing an index in the game array that had already been played.

At this point, I found myself only partially comfortable with the logic thus far and, during debugging, the knowledge gap was rapidly forcing me into a place where I was just listening. I didn’t have answers or ideas… thus, I noticed I was inclined to say “sure, let’s do that” to anything she suggested. It was less an affirmation of a good idea, rather an attempt to escape the place where I felt helpless. Where I needed time to step through each line of code to follow the progression, she knew exactly where we were and could hop from line to line suggesting changes.

Returning to the coaching stance: we failed each other. I wasn’t completely lost, but I certainly wasn’t present, either. I enabled my own falling behind by not announcing that I wasn’t feeling confident in my understanding. Further, Deborah did not check-in with me to ensure I was keeping up. Whether this was mostly my fault for not sending good signals, or just something that happened, when I’m facilitating a coaching conversation I make it a point to check-in often.

Therefore, I wonder about working agreements when pairing? Similar to how I empower people I’m coaching by asking for their preferences and needs, perhaps good practice in pairing would be to establish simple guidelines for interaction. Coaches: if two friends, under no pressure or stress, could still step into these shades of dysfunction, this warrants our attention.

The Current State of “The Program”

I’m quite happy to announce that my first program in C#, a resplendent tic-tac-toe application operating in the finest console environment known to man, is “done”.

The source code is here.

Done means: A human player can play a game of tic-tac-toe against a pretty “dumb” computer that randomly selects where to play. Yes, I wanted to develop the ability for the computer to play a “smart” move, but the idea of a decision tree seems awfully intimidating right now. At least the game validates user input to make sure things are proper, right?

Deborah has already alluded to the fact that there’s plenty of code to be refactored. I’ll take my time and work through it… for now, feel free to be a second (or third, or fourth!!) collaborator and let me know where my code needs improvement!

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s