Ten Steps to Avoid a Yakshave
Picture yourself on a software project at Hyper Gum Dynamics.
As it turns out, Hyper Gum Dynamics is a Fortune 500 company with its roots in the Defense Industry. Their premier product is a ballistics-grade chewing gum that once hardened is more effective at stopping high-velocity rounds than kevlar. It also leaves a soldier’s breath kissably fresh for those unexpected moments off the battlefield.
HyGD wants you to build a new feature on their GumSculptr app which allows users to remotely chew gum to leave on a Great Wad just outside of Peoria, Illinois. What they need is a way that users can share their gum with their social network using a gum-feed and minty-fresh-likes. It’s all part of a major push into the domestic market. A lot of money is riding on this app really taking off with Millennials.
They’ve already put a lot of work into this darling when you’re brought onboard. They’re figuring it’ll be a week or two before they can launch the new features you’ve been assigned. But that’s not what you discover when you start diving into the code base.
The code is written in a paradigm you haven’t seen before, and whoever wrote it apparently succumbed to pressure to “Get something up quickly”. In any case, you spend the two weeks trying to get started on your first feature, which the code base thwarts time and time again. You spin your wheels. The features don’t get delivered. And the company executives blame you for the loss of billions of dollars in ad revenue that would have been generated from retailers co-chewing the users’ gum and copywriting the DNA in the saliva samples. You. Are. So. FIRED!!!
And think of the children. Millions of Millennials will lose out on connecting with distant relatives over gum. Thousands of jobs are lost over the missing revenue. The economy tanks. The sun stops shining. No one can ever open a jar of pickles again. And it’s all because you didn’t deliver this feature when your bosses said you would.
This classic case of wheel-spinning is also known as a “Yakshave”. Granted, there are times when Yakshaving is appropriate. When it’s scheduled. Unscheduled Yakshaves, however, are a serious problem.
I recently encountered an unscheduled yakshave. It hurt. But there is a solution. There are a series of simple steps you can take to unstick yourself and keep your yak’s hair long, shiny, flowing, gum-free and unshaven.
- Realize that you’re stuck.
- Walk away from your desk.
- Read the code until you find something you don’t totally understand.
- Repeat 4 & 5.
- Whiteboard possible changes.
- Pick a change and try it.
- Realize your stuck again; try another thing from step 7.
Step 1: Realize that you’re stuck.
This is a big one. Being able to identify this quickly is of utmost importance. If you can’t see you have a problem, you won’t be able to fix it. What I like to do is review what I have done every half day. If there’s no meaningful gain, that’s a sure sign of stickiness. Likewise, if you’re not getting into a flow, if you’ve tried to do the same thing three different ways over the course of a half-hour and none of them work, or if you’re feeling a looming sense of powerlessness, you very well might be stuck.
Step 2: Communicate.
Software is about two things: coding and communicating. The two don’t have all that much to do with each other, so you really can’t do one and have the other one take care of itself. Coding is about you working on a problem. Communicating is about how you establish trust and coordinate with others. So if there is a change in status, you need to let stakeholders know as soon as possible so they have the greatest range of options available to them. Also communicate with any relevant team members, as they might have solutions. Even if they don’t, just talking about your problem outloud can give you some ideas of what to do to unstick yourself.
Step 3: Walk away from your desk.
I know, sounds crazy. But programming is about more than just how many clicky-clacky noises you make on your keyboard. It’s about thinking. You need a fresh perspective, and in order to do that, you need to go reset your brain. Step away for at least 10 minutes. Go for a walk. Take a coffee nap. Practice your ollie. Whatever. It just needs to be something that puts your brain in another mode for a while. You may even come up with an idea or two while you’re out.
Step 4: Read the code until you find something you don’t totally understand.
When you get back from your walkabout, go through the code. Read from top to bottom and stop at the first thing you don’t completely understand.
Step 5: Research
Google it. Read documentation and blog posts. Watch videos and tutorials on the mysterious line of code you don’t understand until you understand it.
Step 6: Repeat 4 & 5.
Once you understand that first thing, don’t stop there. Keep going. Return to the code reading further. Every time you read something you don’t 100% understand, stop and research it. Do these two until there is nothing in the code you don’t understand.
Step 7. Whiteboard possible changes.
By this point, you should have a pretty good list of ideas of what could be going wrong. There was the initial frustration which let you know the problem, the time you spent communicating with stakeholders and team members, which gave you a few ideas, the time you spent away from the desk that gave you a few more, and the time you spent combing your code for mysterious passages and researching them. From all this, start whiteboarding out possible changes.
Step 8. Pick a change and try it.
It doesn’t matter which, just pick one and give it a go. Focus on just implementing that one change and see what the effect is.
Step 9. Realize your stuck again; try another thing from step 7.
Each time you try something you learn a little more about the code and why it may not be working. This will give you more insight into the problem until you implement a solution that works. If you’ve exhausted your options from step 7, realize you are stuck. Go back to step 1 and start again, but this time with a better baseline understanding. Do not forget to communicate!
Step 10. Profit.
If you keep moving in this process you will find a solution. Not only will you have found a solution, you will have gained a deep and thorough understanding of the code and of your own capabilities. Don’t fear being stuck. Relish it. Apply this process. Become truly awesome for it. And harm no yaks in the process.