How to Unstump a Developer
It takes a special breed of problem to stump the developers on my team. I work with some of the hardest working and most talented software developers in the world, and I rarely see them truly stumped. The amazing thing is, even when they are stumped, they never throw up their hands and give up. But if you’re on the other side of the coin, biting your nails as you see sprint or project goals slip, you could easily miss the dev team’s quiet heroics. I believe we all want to celebrate tenacity, persistence, courage, and selflessness in the face of a problem. But, if a developer is truly stumped, they might truly need a hand getting unstumped.
When Is a Developer Actually Stumped?
Software development is predictable at times, and many times it is definitely not. Problems of any shape and size may arise without apparent warning and delay features or entire projects. Developers do the best they can to prevent delays, firing every arrow they have to solve problems. Sometimes, a feature takes longer than expected, but comes to resolution after the 41st arrow when the problem finally falls down dead (or gets fixed). Other times, no matter how many arrows the developer uses, the problem persists. Though all resources have been spent, often developers have a hard time admitting defeat and will continue working through the problem. To a developer is feels a lot like chasing one’s tail or repeatedly going over the same code, looking for something he missed. That’s when you know developers are stumped.
When developers get stumped, they may need help getting unstumped. Also, project leaders need to be aware of the problem so that they can plan around the problem. The following humble list is my attempt at providing a bit of structure around the process of getting a developer unstumped.
Get Another Brain
Two heads are better than one, especially if one head has been banging against a tough problem for awhile. A fresh perspective combined with the necessity of verbalizing the issue can, often times, unclog the drain (so to speak). Not only is pair programming a fantastic way to reach resolution to a problem, it’s also a great way to prevent getting stumped in the first place. Not that pair programming is the silver bullet, but it sure does help to nip those problems that are caused by simple oversight and tired eyes/brains.
At Acklen Avenue, the first thing a Scrum Master will ask when a developer when it seems like they might be stumped on an issue is, “Have you been pairing? Can I help you find a pairing partner?”
Use Your Circle of Developers
Some developers work alone and seem to like it. Still, countless other developers know how truly blessed they are to work alongside a larger team of skilled software craftsmen. If you are stumped on a sticky issue, and you are surrounded by other talented developers, why not tap into their problem-solving energy. Think back to pairing… if two heads are better than one, how much better are twenty or fifty? The first time you try this, you’ll be absolutely amazed at the insight you encounter as your fellow developers pose questions and poke around at your issue. You may have the problem solved in a matter of minutes and you’ll be free to LOL at yourself for bruising your forehead on the wall for the last hour.
At Acklen Avenue, developers who have been stumped for an hour or more should head on over to the water cooler (or a channel on Slack) to start socializing the problem to see what questions and insights come up.
Alert Project Leaders
Nothing is harder to explain to stakeholders than a feature that was estimated at 3 hours and turned into 10 days. It is even harder when there still is no resolution in sight. Developers are extremely hard workers and are sometimes know to sacrifice their own emotional wellbeing to power through a problem, even if it means running in the same circle 1000 times looking for patterns and microscopic anomalies. Now that I’ve complimented my fellow developers sufficiently, I have to admit that they are also horrible at knowing when to come up for air and say, “I’m stumped!” This step in my process is admittedly a bit futile, but we should try all the same. If you’re a developer and you think you might be stumped, alert the project leaders so they can strategize and realign your team’s goals. If you are around a developer who seems to be banging his or her head against the wall (or you happen to hear them weeping quietly in the bathroom), tap them gently on the shoulder and ask them, “hey, are you stumped?” The first step to recovery is admitting the problem. And in this case, getting that information to the project leaders is the first step to saving your project from imminent peril!
At Acklen Avenue, developers must alert the Scrum Master if they have been stumped for more than an hour and a half. An hour and a half might seem like a lot of time, but it can feel like nothing to a developer who is lost in thought in a world of zeros and ones. This step is, as I mentioned, very hard to take, but we need to try!
Post Problem Publicly
Few methods of problem solving have as much potential success as verbalizing and writing. Some developers have found that the solution appears in their minds before even finishing the post. The simple act of organizing thoughts in order to write a cohesive question for the public might be enough to trigger an insight or reveal something you had missed before. If you’re not that lucky, a publicly posted question can still be massively powerful because, if fifty heads are better than one, imagine a thousand! Yes, writing takes time. But the profits far outweigh the investment. Not only will you expose your problem to the developer community and invite questions, feedback and solutions, but you will also have a well thought out description of your problem to which you can refer back by simply pasting a URL. If you’re stumped and nothing has helped to get you unstumped until this point, don’t go a step further without posting about it publicly.
At Acklen Avenue, developers who have been stumped for 2 hours or more must take this important step and post their problem publicly. From here, the solution is close at hand!
Getting Expert Help
When posting your issue publicly hasn’t led you to a solution or you need to solve the issue more quickly, it might be time to call in heavy guns from outside. Rest assured, there is help out there. The trick is finding the right people and knowing how to compensate them for their help.
When it is necessary to compensate someone for helping you solve a problem, and you’re working with an scrum team, talk to your Scrum Master. He/she should be able to handle getting people paid whether it’s via Paypal, credit card, check or bitcoin. It’s probably a good idea to clear potential compensation amounts with the Scrum Master before you agree to anything.
At Acklen Avenue, after a developer has been stumped for 4 hours or more, it is essential to reach out to the vast pool of experts at our disposal and seek a helping hand.
Contracting Authors and Contributors
If the issue you’re facing is related to a library, tool, or component that was developed by someone outside your team, you may be able to contact the people or person who created it. For example, consider an open source library whose code is stored in GitHub. In many cases, the creator’s GitHub profile includes an email address, which means you can email him/her directly asking for help. Other times, a quick look at the recent committers will reveal one or many other developers who might be willing to respond to an email.
When your problem is related to a commercial product, the path to getting help is as easy or difficult as the provider has decided it to be. Your first mode of attack should be to use the methods they ask you to use. If those methods do not work, then it should not be beneath you to find the names of the company’s management team, look them up on Facebook and LinkedIn, and begin a small email/message campaign until someone responds. Using the “CC” function in email is a good tactic because it causes the folks on the other end to hold each other accountable.
Bounties
If your public posting has not gotten the answers you needed and time is ticking, you can add a “bounty” to the posting to attract more attention. For example, on StackOverflow.com, you can add a bounty to an existing question for almost any amount (for more info, check out http://stackoverflow.com/help/bounty). GitHub issues have a similar mechanism via a few third parties. A really good 3rd party option is BountySource.com which allows you to attach a bounty to an existing issue. In either case, your post gets more attention and, hopefully, gets fixed!
Expert Marketplaces
When it’s not obvious who to approach with your problem, and you’re not getting the right help from the public post or a bounty, or it seems unlikely that a public post or bounty will do the trick, it might be time to re-post the problem in one of the existing expert marketplaces. One of the platforms that seem to give the best results is http://CodeMentor.io. Marketplaces like these allow you to post your problem using tags and a specified budget and make your problem available to their pool of experts. Ideally, one or more experts will respond quickly and set a time to pair with you to resolve the problem.
