Here's the scenario: You are moving through your day as a software engineer, coding to your heart's content, happy and productive. Then, sadly, something isn't working as you expected. You've coded it the standard way, and followed the code examples in the documentation, but you are not experiencing the desired results. You have banged on it every which way, but to no effect.

You are frustrated, doubting your very existence. You swallow your pride. You are just about to ask for help when you hear this blog post supportively screaming at you "NOT YET! YOU'RE NOT READY FOR HELP!"

Asking for help is not easy. While the appearance of weakness can be very awkward, we are not really talking about that here. Lets examine the preparation required to provide the context to those you are to receive the assistance you need. It takes a lot of effort, but it can accelerate answers and solutions when done properly.

Before Asking, Take Stock

Since you are already frustrated, a natural reaction can be to lash out. To start firing off questions in every direction.

Stop.

Take a series of deep breaths. Take a walk.

Before you start asking for assistance from others, examine how you are approaching the problem. Sometimes a solution may present itself.

Stop Coding, Start Thinking

Thrashing at the code may not work. And if you find yourself churning on the problem it would be a great time to stop acting and start thinking.

Start asking yourself hard questions: Is the problem your code? Or could it be the code architecture or design that you are fighting? Are you trying to solve the right problem?

Slowing down and thinking can also help you find simple mistakes: Are the correct properties being set? Did you spell the property correctly? Did you somehow break the formatting of your code file?

"This should be working!" should change to "Why is this not working?" when you take that deep breath and begin to see things more clearly.

Leverage the Available Resources

If there is documentation available about the feature or technique you are attempting, double check it in case you overlooked some minor detail. Often, developers see sample code to copy and paste while missing out on the juicy details "hidden" in the paragraphs above or below that code sample. Actually reading the documentation? Who knew that could be effective.

On larger projects with repeated coding patterns, it is not very often that a coder is the first person to implement a feature dissimilar to your approach. There may be other parts of the product that have the feature implemented. You may find that you were the one who coded it. Surprise! Dig into other areas of your own code to be sure you are duplicating the pattern correctly.

Also, if you are duplicating a coding pattern, maybe now is a good time to refactor this code in a centralized place ⏤ like a service, or a utility ⏤ so that it can be easily reused, thus preventing code duplication and reducing maintenance.

The Rubber Duck Effect

Pro Tip

Rubber duck debugging is defined on Wikipedia as "a method of debugging code by articulating a problem in spoken or written natural language." A developer who is having a problem they are having difficulty debugging, they will tell themselves the problem which can present a solution. The act of explaining the code helps illuminate any problems in the code. I've heard of companies giving out actual rubber ducks to their developers to promote this helpful activity.

"I am not going to sit in front of my computer and talk to myself." I hear you. But it works more often than you might think.

Let me try to explain, unscientifically, how I believe it works for me. While verbalizing the problem ⏤ verbalization is the critical part here ⏤ it activates different areas of my brain as it is rerouting through the area that processes language. Rubber ducking brings more of your brain online to help solve the problem. Its kind of a super power.

And you don't have to talk to a rubber duck like described in that Wikipedia. You can do this with a mirror, with your pet, and with people who don't even know how to code. I can't tell you how many times I have had conversation with someone that sounded like "First, you come to the screen after... never mind. I know what is wrong."

Give rubber ducking a try. It is often worth it.

Strengthen Your Google Fu

Often, a developer who is encountering a problem with immediately open up a browser window and start a search on Google. They'll scan the results and start clicking links. Sometimes search results quickly lead to a solution. Sometimes the developer falls down a black hole of possible solutions that may or may not be associated with the problem at hand.

Before you get dragged into the information overload singularity and disappear from our reality, consider some developer search engine best practices.

  • **Use Your (Correct) Words: ** If you are searching for assistance on the Internet, consider the search terms you are using to get that assistance. "Page won't load" really isn't going to cut it. Neither will "404 error." Before you begin your search, try to understand the terminology necessary for getting the best results. If, for instance, you are using Jasmine and Karma to test and run your unit testing environment, and you have a unit test which is failing with an error, you might enter the search terms "karma jasmine error cannot read property" to get focused results.

  • Look for the Right Dates: The Internet tends to not be as organic as one would hope. While the tools, frameworks, and utilities continue to grow, blog posts and articles may grow old, and rot with irrelevance. Checking the date of any link in your search results should be your first thing to scan for when the page loads. If you are looking for a solution to a problem with a modern framework, links to articles from 2008 might be considered less than helpful. Of course, your mileage may vary.

  • Understanding Over Copy/Paste: Yes, a search result can lead to a Stack Overflow post with the code right there ready to be copied, pasted, and compiled into your code. Yay! Problem solved! Now on to better things. But wait! Did we learn anything? Have we examined all the results of the solution? Just because it worked (On the first time? You did manually test to ensure it always works, right?) doesn't mean this is the right solution to your problem. It is vital that you understand any code that you may have found on the Internet really works for your desired solution and ensure that you can explain why it works. Otherwise, you (or a future developer) could find themselves assigned to fix another bug that was introduced by your new code.

Important: Set a Head Banging Timer

Pro Tip

Banging your head against a wall does have it's limits. I mean, eventually, you'll get a concussion.

But, seriously, here's a tip to keep you from losing your mind. Before you start to churn, grinding on trying to solve a problem, set a timer for, say, an hour. One hour to explore options. One hour to fight. Just one hour. Then, once the hour is done, stop. Give yourself a break.

Sometimes when we take a moment after fighting a code defect a solution can magically present itself from our unclouded minds.

Try Something Crazy (or Experiment and Observe)

Sometimes a developer gets into a situation with some unfamiliar code, a code base that they do not normally work in or have not worked in for a long time, and are challenged with an unexpected experience. Often, they may be assigned a reported bug to fix, but the reported steps to reproduce do not produce the reported experience. These are often times where doing "something crazy" can be helpful. Change some code that you know will break the process the code is moving through to see what happens. Experimenting and observing the results can often lead to earning a more insightful view of the code and the problem. And a solution can be found through the process. Just remember to "un-break" any code you broke to get there.

In Conclusion

So, you have a development problem. It has you stumped. You have taken a moment and cleared your mind. You have reviewed other parts of your code base to see if the implementation may appear to provide clues to whether there are insights there. You have "rubber ducked" by yourself or with a friend or a pet. You have leveraged the power of a strong Google search. And you tried more than one crazy experiment. And only to find that a solution to your problem is unrevealed.

Now, you are probably ready to ask for help. But there are some more things to do before you do. Check back here for a follow up post to be published soon revealing your next steps in your quest for assistance.