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.