It was Monday morning, and I’d been thinking about it through my weekend. A developer in my team wasn’t making any progress and now a ticket was delayed.
They weren’t asking for help, and our offers to help them were not being received as we hoped. Instead of accepting the team’s help, they kept saying they were almost done with the task.
All I wanted to do was help get the tickets out, and help them get unstuck.
While I worried about not coming off as a micro manager, and drafted my questions to them in the best way I could to avoid stressing them out, they were worried that they had waited too long to ask for help.
“How do I even ask for help?” “Is it too late to ask?” “I wish I had asked earlier”.
It doesn’t have to be this way.
Your team wants you to succeed.
Think about the last time you were stuck and waited for more than an hour to ask for help.
What stopped you? What was your decision making process like?
If you aren’t sure why, and you don’t know how to avoid this in the future, you can use this list to help you decide how to ask for help.
Open a blank document and write down
What am I trying to achieve?
- Good: send a POST request to the server at /card to create a new card
- Less good: create a card
- Bad: finish my ticket
What is happening? (vs what you want to achieve)
- Good: I am able to submit the card to the /card endpoint, but the server responds with a 422 error despite the fact that I sent all the required fields. The error message says “Validation failed”
- Less good: I get an error
- Bad: I can’t create the card
What did I try?
- Good: I read the documentation on the /card endpoint, and verified that I’m sending all the required fields (name, description, tags). Here’s an example payload: {name: “hello”, description: “Hello I am debugging”, tags: “hello, I, am, a tag”}
- Less good: I verified the payload I’m sending, it seems correct.
- Bad: I tried submitting through JavaScript
What research did I do?
- list anything you googled (exact keywords help a lot)
- list anything you used as reference (docs, notes)
Why does this work?
- Because it helps you find the problem yourself. It’s similar to rubber ducking, in that by forcing yourself to explain the problem in detail to another person and showing them your work, you often find the solution on your own, or a useful clue.
- Because if you don’t find the problem, you know for sure there’s not time to waste. You need to go and ask for help.
- Because when you do ask for help, you can send this same debugging list to your team, and they’ll be able to help you a lot better than if you said “the validation isn’t working for me”.
Your team will be delighted to find out you did your research before asking. They will be better at helping you because of all the detail provided, too.
You won’t have to wait for hours, and stay stuck on a problem for no good reason. If going through the list doesn’t help, then You will know that you need help.
What if I don’t know how to answer the questions on the list?
Then, you absolutely need help. Don't waste more time. Start by writing down what you can, share it, and explain that you don't know where to start debugging or what to try. Your team will be happy to teach you, and you will learn more debugging techniques, too.
This post is part of my series for remote software developers. You can check it out and subscribe here https://rowasc.com/engineers-working-remotely/
Top comments (0)