As a new developer facing an unfamiliar problem you often need to ask for help. There are many people out there that can and will help, but asking for help itself is actually a skill you need to learn.
When asking for help there's ways you can quickly and easily demonstrate you're committed to solving the problem, that you're not asking someone else to do all the work for you.
If you're summarizing the problem as "it doesn't work" then you're thinking like a user. While that's fine when you are just a user, like if you're using a vending machine and it "doesn't work" when you put in money, it's not enough when you're the one who's trying to fix the problem.
You'll need to be assertive and take responsibility for the problem.
First, Ask "Why?"
"Doesn't work" is an important initial observation, but ultimately you'll need to figure out what's wrong, so "Why?" is the first question. Before you ask for help make sure you've already done this, as answering this question quickly uncovers important context.
Some problems are really complicated, and you won't be able to answer with a simple "Why?", but you will be able to run through a quick check-list that helps narrow down the problem's scope. The goal is to rule out, in the broadest possible strokes, possible root causes.
As an example, say you're responsible for fixing a vending machine that someone's told you "doesn't work". Before you give up and call a technician to help fix it there's a number of things you can do.
Simple checks like this: Is it plugged in? Are the lights on? Does the coin return work? Are there drinks in the machine?
These diagnostics don't have to take long, a quick check is often better than nothing, and avoids situations where you ask for help only to find out the solution was, effectively, you forgot to plug it in.
Know What's Supposed to Happen
Be sure to have a clear goal in mind. The opposite of "doesn't work" is "works", but what does that mean? It's important to be able to verify that a solution works, so having something in place that can test any possible solutions is essential.
Using the vending machine example: It should dispense a single drink if the right amount has been paid, and according to the selection made. There's obviously more layers than that, but this simple explanation sets the expectations.
Demonstrate What You're Doing
If you have a programming problem, have code ready to show. In particular, know what code you need to focus your attention on. Dumping the entire source of your application in someone's lap isn't going to work, but neither is showing part of one line. There's an ideal amount of context that depends on how complicated the problem is.
Using the vending machine example: Know what parts of the machine are likely to be causing the problem and be able to give a quick summary of what things you've already checked. It's plugged in, each selection is loaded with drinks, and it was working fine earlier in the day.
Be Ready to Test Solutions
When you're stuck on a problem, sometimes the best use of your time is to write more test code to better describe what it's supposed to do and identify places where you suspect things might be going wrong, but can't be sure.
If you can't test a possible fix you're really not ready to ask for help.
Using the vending machine example: Have enough change on hand that you can test purchasing a drink. Know what drinks each button should dispense.
Many problems have situational variables unique to your circumstance, so know what these are and what impacts they might have on the situation.
Diagnostics are Key
It's really important to know where things like error logs are kept, how you turn on the console, or other tools that are used to dig up low-level diagnostics to help diagnose the problem. If you don't know where these are, maybe you're missing a message intended to alert you to the root problem.
If you're not getting any diagnostics, are you sure they're reporting correctly? Sometimes you need to break the thing even more until you know it should be reporting errors, so if it isn't you now have an additional problem to solve.
Using the vending machine example: Is there a control panel or some indicator lights you can check to ensure the machine is configured correctly? Did you check the manual to see if there's any way of performing tests on the machine?
Be Prepared to Iterate
Maybe the problem you have is simple and can be fixed by adding or changing something on the first try. Often you'll need to work towards a solution by trying different things, observing the results, and trying something else based on that.
With a really complex problem you'll want to keep track of the things you've tried. This is not only so you can un-do things that could have introduced new problems, but so you don't waste time doing the same thing over and over and expecting different results.
Using the vending machine example: If a common problem with that particular machine is a stuck can in the dispenser chute and you've already checked for that, rule out that cause and try something else. Maybe if no can appears to be stuck you'll instead check that the stuck can sensor is working correctly.
Manage Your Problem Stack
Sometimes one problem is actually caused by another problem, and solving that requires resolving yet another problem first. You can end up ten layers deep in solutions and forget what you were working on in the first place.
Using the vending machine example: When trying to tighten a screw on a loose bracket you stripped the screw, so you needed to drill it out, but the drill was broken, so you needed to sort that out. The drill charger didn't seem to be working, but it was actually the outlet that was dead, so you had to figure out that first by testing with a lamp. When you fixed that, the chuck on the drill was jammed and you had to try and wrench that open...
Figured it Out on Your Own?
If you figured it out on your own, take the time to explain what you did that got it working, don't ghost. Even a quick summary helps provide closure, the person helping you won't have to wonder if you ever fixed it, and if someone else comes along looking for answers then that knowledge can be shared.
Using the vending machine example: If the solution was to connect a wire inside that had wiggled loose and it stops working again in the future, that might be the first thing you check. If you share this knowledge someone else could do it instead, saving you the hassle, but only if they know what to do.
Try Something, but Don't Overthink It
One approach to solving problems is to try the stupidest thing that could possibly work first. It's surprising how many times this is the thing holding you up.
Overthinking things tends to lead to things like people blaming compiler bugs or reinstall the whole server on the pretence of it being a computer virus. This is when you end up mistakenly perceiving a highly improbable cause as being highly probable.
The stupidest thing is often the most probable. Start there. Common causes are typos, mismatched arguments, calling the wrong function, ignoring an error condition, or not capturing a return value correctly.
Using the vending machine example: You plugged it into a different outlet and it worked again.
Skill Up!
The better you are at asking questions, the better you'll be at answering them, too, as you'll know what process to follow.
One of the most reliable ways to know you're progressing as a developer is when you're asking fewer questions and starting to answer a lot more.
Top comments (0)