How to ask for help about code, and how to deal with the answers. A practical guide

#career #beginners #discuss

How to ask for help about code and deal with the answers

For the rest of your life as a developer you will bump into problems that you simply DONT KNOW how to start, how to solve, and you will need to discover by yourself. Its part of the game. How you handle this situation will define part of the type of professional you are and will be. the way that you will organize the problems, thing, present and attack them matters. So let's go to some important points about it:

1. Find the root of your doubt

Did you get the task but didn't understood the description? So it's useless to ask the Dev next to you "hey, I don't know how to do handle this, can you help me?". Even if he/she explains, you won't understand because you didn't even understood what to do, or what kind of problem is happening.

It's okay not to understand the briefing, it means you have a clear reason to ask for help. But its a problem pretending to understand, trying to get things done without clear information and end up stucked.

The task description said to do something in the login but you don't know "what login?", ok: ask. Missing info in description? Notify someone. You really don't understood, ask Lead, PM, PO... Trying to coding something without a clear understanding of what to do is by itself a problem.

2. Try not to pass the ball

Let's imagine that you got a task: show a new message after login. You read the task, understood the briefing, started to code, but suddenly nothing makes sense. Nothing works. This is where most beginners ask someone WHAT to do, and not HOW to do (because you even know what you dont know).

Often the Dev's first move is to call a colleague and say, "I need to show a message after login but I'm not getting it, how could I do it?"

This is not exactly a question, you are passing the ball. The person will basically tell you how to work. And thats ok sometimes, you can learn with it too. But if this starts to get recurrent, then it's better to follow the next steps:

First identify your difficulty

You can't start because you don't know which file to move? Not sure which function to use? Do you know the files but at the time of displaying the message you don't know how to do the modal? Or do you have a lib to show the message and you don't know where is the docs?

These are real doubts. See that then the way to build your questions would change:

Hey, I need to show a message after Login but I don't know what file or function it is in, can you show me?

I'm giving a console log here because I don't know how to do the modal, or if I should use lib, could you help me?

In other words, before declaring to someone that you have NO IDEA WHAT TO DO and need help to give baby steps, it's better to try, look at yourself and think: which part exactly am I not understanding?. Ask a question after question after another if you need to, no prob.

See that I'm not saying that you can't ask someone to show you how to do something entirely. I'm telling that this shouldn't become a modus operandi because will harm your learning and the team dynamics. Try to do it first, understand your own difficulties, list them and ask for help objectively. That way you help yourself to learn, and help the team to help you.

3. Have the ownership of your task

Let's say then that you understood the briefing, did the task, asked for help, pushed the code and tadááááá: A WILD BUG APPEARED.

The worst thing you can do when informed of the bug is to say, "But I did it the way Juliana (or anyone else on the team) told me to do it".

Bug report is not blaming. If someone informs you of a bug, you listen and solve it. Then starts all again.

Sometimes you can say this unintentionally, but it's like trying to blame the other for a non-existent consequence of your own task.

If you do a task, ask for help and then say "but I did it the way X-Person told me to do it", the person who helped you will probably think 10 times before helping you again. Even if nothing comes out of it. Remember: you can ask for help but the task is yours.

The responsibility for bugs should be with the whole team. This is one of the effects of doing code review: other people saw the code, other people approved it. Other people are naturally involved, you don't need to be afraid of being wronged (at least in a healthy team).

4. Ask for Pair Programming

Let's say that you really can't organize your head, you got the task, you have the ownership, you are motivated, but you you have no idea about how to solve it, you need to ask someone to untangle: Ask a colleague for a pair programming :)

If you're totally lost, instead of sending a message or poking the other dev and asking implicitly to "explain how to do your task", ask for a pair: among other things, that's what a pair its for.

5. BE HONEST when in doubt

Don't ask questions pretending to know more than you really do, or embarrassed. Okay to ask (if not, you are on the wrong place). You need a pair prgramming and it's lost? Ok, ask for help: "Hey, can we pair? I have no idea about how to attack this problem". Thats totally ok.

If what you have is a specific doubt, be frank: Hey, I read React's useState documentation, I did what was there, I tried a few things but nothing worked, it's buggy, I don't think I understood, could you help me? Sometimes, the way you ask can make the problem easy to solve.

Conclusion

If you have a cool team, the team will welcome you and you will all grow together, and knowing how to organize and present problems for the team is a skill that you should try to improve as much as possible.

Cover image by NeONBRAND on Unsplash.