Stew’s CS Blog

Okay, so in my ongoing efforts to keep my post title’s Trading Card Game themed, this may be stretch. But, I think it’s better than my original idea: “The Heart of the Cards is Teamwork”. Between the two, you can guess that today we are voyaging out of high-brow technical discussions of frameworks and system designs and moving into the often much harder realm of “Soft Skills”. Yep, today we are talking about what it takes to work on a team.

In the ongoing saga of Making the Trading Card Game Maker we are making progress and also running into the lovely cross-section of coordination that is part of having a team built of devs spanning time zones, life commitments and experience. Let me start out by saying, it is all going surprisingly well, but I wanted to talk about a few categories of building positive team environment inspired by this work. I want to add that these themes are a huge part of my experience as a professional software engineer, and I don’t think importance of positive team dynamics can ever be understated.

Division of Labor:

This is a key part to the development process, but is often fraught with complicating factors in terms of team dynamics. For instance, on a team of devs with a list of tasks divided up, do we prioritize giving tasks to folks who have something to learn from doing it, or who will finish it the quickest. What if multiple people want to work on the same thing? This is one of those questions that will always have a unique answer for the given collaboration. Are we working to a deadline, or with a looser time frame. Is this a one and done project, or can we say “you get first pick this sprint, and then you get first pick next sprint”. On our team it was a simple as coming up with the tasks and people all seemed interested in taking different ones, so we divided it up pretty easily. But then what happens as the process progresses?

Output Result:

This is the big inspiration of my post. How does a team handle the difference in time it takes to accomplish different tasks. For instance, if one person takes on a task using an entirely new technology with a steep learning curve complex technical requirements, while another takes on one with a familiar technology and relatively standard technical requirements. This is exactly what has happened on our team. Where one team member is bogged down in the learning process feeling he has fallen behind, another team member has finished his designated tasks and the third is on-pace with the plan and having manageable time completing the designated tasks. The simplest solution to this is pair programming, right? Just have the person who has completed their designated work hop in with the person who is feeling behind. This is a good approach in some ways, but also leads to lots of complications. Sometimes bringing in another person on a task actually slows it down, or can be disillusioning to the person who has been plugging away. This brings me to my final pitch:

Pair Programming: The Consultant Method:

I have been involved with a number of situations where I plug-in with or have someone plug-in with me on a in-flight project. There are many approaches to “Pair Programming”, but to me the approach which works best is what I call “The Consultant Method”. Having someone jump in with you and try and take on an even share of the work is rough and often leads to more overhead. What I recommend is that the person joining the in flight project treat themselves more as a consultant and extra hands for side-tasks. If they jump in and demand to be brought up to speed and fully plugged in this slows things down, but if they say, “Why don’t you share screen with me and show me what you’re working on” then they become more of a rubber duck than another chef in the kitchen (If you’ve never heard of Rubber Ducking I recommend looking up the term, it is a great tool for programmers). Your job as the Consultant is to ask good questions, notice things that a person whose been staring at the same code for weeks might miss, and complete some of side tasks they may have let fall to the wayside. Offer to write up documentation for them or research questions they had which we outstanding. I recently had someone at work “pair program” with me, hopping in halfway, and they noticed there was one part of the project which required communicating with other teams at the company. They happened to have worked with the PM for that other team and offered to initiate the discussion. They took point on this inter-team discussion piece of the progress so I could stay heads-down on my primary sub-task. And it worked GREAT!

Conclusion:

Really, the point of all this is to say, Teamwork is about listening. It’s about noticing what’s missing and filling that niche. Trying to do the same thing your teammate is doing does not reduce the time it takes to get it done. It complicates thing. Working together is always about becoming the missing piece. That’s what my team is doing great so far, and that’s what I think we could all work on.