We all need help at times, but sometimes we ask for help too soon, or we just find it hard to ask for help
In this post I give you my opinions and experience about when I think you should ask for help, with a checklist of things you can do first before you do ask for help.
1. Debug
Please don't ask for help before you have tried to debug it yourself.
2. Check the logs
Check the application logs, web logs or even the System Event logs.
3. Isolate the code
Can you isolate the code and write a unit test for it? This will make fixing it a lot easier, because it makes testing it much quicker, and you don't have the overheads of an application needing to run, just to test a certain piece of code.
4. Google the error
Don't ask for help without googling the error yourself. You don't want the person to send you a 'Let Me Google That For You' link. Google is your friend, you should know how to use Google effectively to help you solve problems. Other people will have experienced the same problem and asked a question on sites like Stack Overflow or the ASP.NET forums. Make sure you search for the exact error message without your environment specific details. Look for recent results, and don't just copy and paste the code from somewhere unless you understand what it is doing. It is important that you understand what the problem was and how they solved it.
5. Find an example
Usually if you are struggling with something, you might find that the problem has already been solved in a different part of the application, or in a different application which you have the code for. Try looking for such examples to help you get through it without help.
Now you can ask for help
If you've done all of the above and you still need help then go ahead and ask. At least when you ask you won't come across as too lazy or inexperienced to try and solve it yourself.
If you work on your own or remotely and you have no one around to ask. Then isolate the code into a simple example console application or something and write a question on one of the helpful forums like Stack Overflow. All of the research you did above will help you write a good question so you don't get shot down.
Latest comments (12)
I'm still learning to turn to google. It really is a dev's best friend.
I had an issue just now that I was honestly going to ask about but then found the answer in stackoverflow.
Nice article.
Personally, I'd like the sixth point
I think that saying my thoughts in a way I can hear them have a magical influence of understanding the problem 😁
It is shocking how helpful this actually is. I can confirm, and have read in books such as "Pragmatic Thinking and Learning" that there is actual science to why this works.
Sometimes, a small break time will also help. Go for a walk.. Helps me most of the time.
Yes stepping back from the problem by having a small break can really help.
Sleep over it. Sometimes you need to rest that brain of yours
Very true, but if you get stuck on this on a Monday morning, it's a long time to wait until you've had a sleep.
"Give it the weekend to think over"
Has issue on Monday Morning
Plays Tetris for next 5 days
Sometimes I have trouble what to ask for.
Would it make sense to ask other dev what to search for in that case?
e.g.)
I saw a piece of ReactJS code. Someone pointed out to search for HoC (Higher Order Components) and go from there.
That’s true, I suppose when you have gone through these steps you will find this out when you ask the other dev.
Good advice. On your first point, when debugging I find it helpful to apply the scientific method instead of just poking around the debugger and making somewhat random code changes (note: not implying that's what you meant, just as an example I see people often do).
Observe by examining values in the debugger, monitoring the application's behaviour and checking the logs like you said. Then come up with a hypothesis based on what you observed, and derive predictions from that. Then you can carry out tests based on your predictions, not strictly speaking in a TDD fashion but test by changing the data or code, and analyse the results of your changes. There you should gain more insight into the problem if not determine the cause outright.
The point being to make small, specific changes not necessarily just focused on the code, based on your predictions instead of just going on autopilot thinking "oh this tweak will probably fix it." Don't do things without a reason.
This is good advice as a tactic for debugging. Sometimes even just stepping though the code to see where it fails is enough. Some people don’t even do that.