Stew’s CS Blog

In keeping with the theme of Trading Card Game based blog post intro’s, are you familiar with Mana Burn? I’ve heard that this rule was actually removed form the official rules for Magic: The Gathering, but there used to be a rule that a player took damage equal to the number of unspent mana left in their mana pool at the end of their turn. For you non-magic players, the basic idea behind mana is: In magic you play “land” cards, during your turn you can “tap” (activate) land cards to produce mana (each land generally can only produce a single mana per turn, and you gather more lands on your board as the game progresses). Spells, creatures and basically everything in the game costs mana to use. Mana burn didn’t affect the game much, because for the most part you tap lands when you are ready to use the mana, so you never unnecessarily tap extra land. It was a rule that prevented certain obscure strategies and most commonly would catch newer players who would just tap all their land at the start of a turn and then try and use the mana only to realize they couldn’t use it all. So what does this have to do with coding, the TCG Maker Capstone project, or anything related to the list of acceptable topics for our mandatory blog posts? Mana Burn is a metaphor for the subtle art of dealing with discrepancy between task allocation management and the reality of what happens when you try to do the work.

I’ve recently hit my 9 month mark at my first company as a Software Engineer (really I started as a Software intern and then got hired on full time). People warned me about it, but I still didn’t quite grasp just how little of the time and energy of a developer/engineer is spent doing everything but actually coding. A huge part of the job is planning work, refining stories, pointing stories, writing documentation, outlining solutions and the list goes on. Basically, lots and lots of trying to guess and predict what a software implementation will require. If development were a magic game it is as if you have to tap land before looking at your hand. Sometimes you over-estimate a task, sometimes under. Sometimes the way you thought you could do something proves impractical and you have to circle back and re-evaluate the plan after starting down a given implementation path. This is okay. It has been hard for me to deal with both the moments in which I realize I tapped too much land (made a task out to be more complex than it turned out to be) and in which I didn’t tap enough (and found my managers and peers waiting anxiously for me to finish something that I thought would be simple and ended up taking far longer than expected).

So whether it is mana burn or mana shortage, I have learned one thing. It is okay. Everyone has been there. It’s the same in our capstone project. One person’s designated task, which in the planning phase seemed an equal piece of the pie to everyone else’s, has proved far more complex and time consuming, while the pieces that myself and others took on were able to be completed in the target timeline. This is okay. None of us feel anything but a desire to support the person who is behind on their target timeline. And ultimately, there is plenty for everyone to do, and we are going to pull it off. The only person truly distressed by the delay is the person working the task. And that’s honestly how it is (for the most part) in a professional setting as well. I mean, of course if you really mess up people get frustrated. But story pointing is always a best guest. And most of the time, honestly saying “I over/under estimated this task” is all it takes to get the full support of your team and manager in either finding the next thing, or re-allocating resources to accommodate the delay.

The round about point is this: Gracefully dealing with divergence from expected work-plans is an often under-appreciated “soft-skill”. The biggest issue that arises from tapping the wrong amount of land for a project is when a developer gets stressed and starts communicating poorly or, even worse, lashing out in frustration. Maintaining a level head and openly admitting the discrepancy not only helps you avoid unnecessary stress, but it is so appreciated by team-mates. I noticed that when I tried to deal with it all internally, that is when I got mana burned. When I talked openly, the new rules applied and the excess or shortage of mana was gracefully dealt with, and often unexpected learning opportunities emerged. So don’t worry too much about the “planning vs reality” divide. It is part of the job. You have to map out expectation in order to task out the work, but everyone knows that things don’t always go to plan. Mana Burn is not a thing anymore (for the most part), but watch out when you’re getting started, because mana burn is still a classic pitfall for new players :D.

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.