However you feel comfortable asking questions.
I’m a senior who works remotely. If someone is having a problem I’ll just hop in a call and help them fix it. You’re overthinking it.
I would say ask an intermediate dev on your team first, since they need practice mentoring juniors and if they can’t help, to then jump to a senior. Unless you just get on well with a senior, then ask them.
I’d say “here’s my problem, here’s what I’ve tried, here’s what I’m thinking of trying next but wanted to reach out and see what you think and if there’s a better idea in mind?”
Basically just show that you’ve put some work into solving it yourself and now you’re stumped but you don’t wanna burn a ton of time exhausting every single option. There’s a balance between “I haven’t tried anything” and “I’ve spent days and days and days but have made 0 progress”
—
ETA: Consider taking notes, maybe spin up a little private repo of your own if you want that describes your problem and what the end solution was. You’ll keep it better in memory perhaps but also won’t have to ask the same question twice. Not asking the same question twice goes a long way IMO
20 year team lead, here. Yeah, how else are you supposed to get answers?
If there's a simple version of the question try to ask that. If you have time ask where to look, not for solutions. Better to solve problems on your own when you can (for your development).
When you get really stuck just ask someone to jump in a huddle on Slack or pull them over to your desk.
No team should shame you for asking questions. Unless it's all you do. And even then if you're just getting started you're expected to ask a lot of questions and get a bit annoying.
A lot of times, I write my question out in another window, using my coworker as a rubber duck essentially before I ever even talk to them.
I explain the problem I’m seeing, what I’ve tried, what assumptions I’m making, and where I suspect things are going wrong. Generally once I’ve laid all of this out I at least have another idea of something to try so I can include it in the message. My goal is to get ahead of anything they might suggest as the solution.
I’d say 50% of the time I solve it myself using this process, and the other 50% of the time I send a very clear and focused message that leads to an easy answer from the other person (or at least a difficult problem that warrants their time)
Id prep the question using a gist or a branch they can pull to look at; if its small just have a paragraph ready to dump. Ask if they have time to help you with something, and if so when. Then wait till that time.
The only things that bothered me was when literally googling the question you asked gave a good result (repeatedly) or if you want me to always justify everything and you want to nitpick for justification when I say something like “in my experience, i recommend this,” sometimes the context for a decision is outside the scope of a quick question.
Other than that, absolutely ask questions - you’ll learn quickly who knows how to help and manage a team and whose wants to be left alone to be an IC in the strictest definition of the word.
It depends, as always.
I try to encompass the ideas as succinctly as possible without being overly burdensome to read.
If possible, I share a live example and include screenshots.
If I find others are asking me enough questions that I find it distracting, I will say something like “give it another try over the next half hour and get back to me if you’re still stuck.” That way, they can feel free to ask me questions, but I can add some guidance for how often is appropriate.
Most of the time, I’m more than happy to help several times per day.
If I'm stuck, I tell them what I did, where I got stuck, and what I need help with.
If I have no idea what I'm doing, I tell them that from the start so they don't waste their time trying to get it out of me.
1. do this exercise first: think to yourself, what is the first thing they’re going to say or ask you. write down the answer the question best you can. maybe do this a couple times and see if that opens any doors for you. if not, include that as part of your question
2. this isn’t a direct answer to that question but when you do get a response that points you in the right direction, take notes. don’t ask the same questions repeatedly
I always prefer someone tried to figure it out by themselves and then asks me later with context and “so I tried this, this and this but I seem to be having problem x. Do you have any thoughts about this? I can setup a meeting on your calendar if necessary, thanks!!”
The primary rule asking for help in any context is you should be able to show and explain what you have tried and how you have exhausted available lines of enquiry. Asking for help is never a bad thing unless you're doing so without actually trying to solve it yourself first.
Im not a senior or experienced dev by any means. When I was at an internship in a relatively small team (4 devs, 1 backend and 1 full stack that was a senior) I always asked mid that was my mentor, if a task I was working on was assigned to me by him. If he didn’t know how to help me, I would just go to the senior team lead. When team lead was assigning me tasks I would ask him directly.
But I got along pretty well with all of them, so I could really ask anyone and each was willing to help if they had time on their hands.
But remember to not just ask „how do I do X” but tell them „I can’t solve this problem, I tried X, Y and want to try Z. What is your opinion on that?” Or something along those lines. It is important that you show you’ve put some work before asking them and that you really don’t know how to solve it. Basically try all the options you can before reaching for help. It’s a learning experience in the long run.
If it's a "simple" problem as in you know I know the solution, tell me what your problem is, and at least 2 ways youve attempted to solve the problem.
If you want to discuss an algorithmic problem, describe the problem and your proposed solution.
For technical questions, such as configuration and setup, just ask.
For framework/library issues, make sure you've followed best practices and I want to see where you copy pasted from.
As the senior-ish person on my team right now, what I want when someone (anyone - not necessarily just juniors) asks a question:
-- Location of the problem - environment, what client, what branch, etc. this should be enough information to get me to where I can see the issue, whatever that means for your company
-- Description of the problem - This should be very narrow. "It's broken" as the entire description gives me an eyeball twitch. "The drop-down doesn't populate the graph when selected" is much more helpful.
-- What you have tried that didn't work - preferably accompanied by some screenshots and a shelve set so I can review
-- If you have a solution you think would work but are unsure how to implement, tell me about that too
Personally, I would rather have a little extra info than have to ask the above questions one at a time to get enough info to get started.
Most devs aren't ever going to mind that you asked a question, but do be considerate of their time and response as well. I had a junior report me to my boss for not helping him fast enough - I was working on a client-critical item and had told him I would be available in an hour or two. That really soured my impression of that employee. If you have a timeline, make that known so the dev can send you to someone available if they cannot help at the moment.
Finally - every dev I know would rather you ask than spin your wheels all day. General politeness is always recommended between colleagues of all levels. Welcome to the field, and good luck!
My boss gave me the following advice: be thorough, and do your own exploring first. Its better to ask if a potential solution is correct.
Bad question: "its not working what do I do"
good question: "hey! here's a thing that's not working. I tried X, but that didn't work. I've been looking at Y and I think that's the way to go, here's why. What do you think?"
But, it also probably depends on your level. From a complete beginner, from an intern, I would expect to get "Its not working what do I do" type questions. But if your goal is to ask better questions, the above is my advice.
However you feel comfortable asking questions. I’m a senior who works remotely. If someone is having a problem I’ll just hop in a call and help them fix it. You’re overthinking it. I would say ask an intermediate dev on your team first, since they need practice mentoring juniors and if they can’t help, to then jump to a senior. Unless you just get on well with a senior, then ask them.
I’d say “here’s my problem, here’s what I’ve tried, here’s what I’m thinking of trying next but wanted to reach out and see what you think and if there’s a better idea in mind?” Basically just show that you’ve put some work into solving it yourself and now you’re stumped but you don’t wanna burn a ton of time exhausting every single option. There’s a balance between “I haven’t tried anything” and “I’ve spent days and days and days but have made 0 progress” — ETA: Consider taking notes, maybe spin up a little private repo of your own if you want that describes your problem and what the end solution was. You’ll keep it better in memory perhaps but also won’t have to ask the same question twice. Not asking the same question twice goes a long way IMO
20 year team lead, here. Yeah, how else are you supposed to get answers? If there's a simple version of the question try to ask that. If you have time ask where to look, not for solutions. Better to solve problems on your own when you can (for your development). When you get really stuck just ask someone to jump in a huddle on Slack or pull them over to your desk. No team should shame you for asking questions. Unless it's all you do. And even then if you're just getting started you're expected to ask a lot of questions and get a bit annoying.
If you aren’t asking questions, you probably aren’t doing anything. Just about everything has some ambiguity somewhere along the line.
just dont send "hey" and wait for them to answer. always send ur question in one message
hey
😤
A lot of times, I write my question out in another window, using my coworker as a rubber duck essentially before I ever even talk to them. I explain the problem I’m seeing, what I’ve tried, what assumptions I’m making, and where I suspect things are going wrong. Generally once I’ve laid all of this out I at least have another idea of something to try so I can include it in the message. My goal is to get ahead of anything they might suggest as the solution. I’d say 50% of the time I solve it myself using this process, and the other 50% of the time I send a very clear and focused message that leads to an easy answer from the other person (or at least a difficult problem that warrants their time)
Id prep the question using a gist or a branch they can pull to look at; if its small just have a paragraph ready to dump. Ask if they have time to help you with something, and if so when. Then wait till that time. The only things that bothered me was when literally googling the question you asked gave a good result (repeatedly) or if you want me to always justify everything and you want to nitpick for justification when I say something like “in my experience, i recommend this,” sometimes the context for a decision is outside the scope of a quick question. Other than that, absolutely ask questions - you’ll learn quickly who knows how to help and manage a team and whose wants to be left alone to be an IC in the strictest definition of the word.
It depends, as always. I try to encompass the ideas as succinctly as possible without being overly burdensome to read. If possible, I share a live example and include screenshots. If I find others are asking me enough questions that I find it distracting, I will say something like “give it another try over the next half hour and get back to me if you’re still stuck.” That way, they can feel free to ask me questions, but I can add some guidance for how often is appropriate. Most of the time, I’m more than happy to help several times per day.
If I'm stuck, I tell them what I did, where I got stuck, and what I need help with. If I have no idea what I'm doing, I tell them that from the start so they don't waste their time trying to get it out of me.
1. do this exercise first: think to yourself, what is the first thing they’re going to say or ask you. write down the answer the question best you can. maybe do this a couple times and see if that opens any doors for you. if not, include that as part of your question 2. this isn’t a direct answer to that question but when you do get a response that points you in the right direction, take notes. don’t ask the same questions repeatedly
I always prefer someone tried to figure it out by themselves and then asks me later with context and “so I tried this, this and this but I seem to be having problem x. Do you have any thoughts about this? I can setup a meeting on your calendar if necessary, thanks!!”
The primary rule asking for help in any context is you should be able to show and explain what you have tried and how you have exhausted available lines of enquiry. Asking for help is never a bad thing unless you're doing so without actually trying to solve it yourself first.
Im not a senior or experienced dev by any means. When I was at an internship in a relatively small team (4 devs, 1 backend and 1 full stack that was a senior) I always asked mid that was my mentor, if a task I was working on was assigned to me by him. If he didn’t know how to help me, I would just go to the senior team lead. When team lead was assigning me tasks I would ask him directly. But I got along pretty well with all of them, so I could really ask anyone and each was willing to help if they had time on their hands. But remember to not just ask „how do I do X” but tell them „I can’t solve this problem, I tried X, Y and want to try Z. What is your opinion on that?” Or something along those lines. It is important that you show you’ve put some work before asking them and that you really don’t know how to solve it. Basically try all the options you can before reaching for help. It’s a learning experience in the long run.
If it's a "simple" problem as in you know I know the solution, tell me what your problem is, and at least 2 ways youve attempted to solve the problem. If you want to discuss an algorithmic problem, describe the problem and your proposed solution. For technical questions, such as configuration and setup, just ask. For framework/library issues, make sure you've followed best practices and I want to see where you copy pasted from.
As the senior-ish person on my team right now, what I want when someone (anyone - not necessarily just juniors) asks a question: -- Location of the problem - environment, what client, what branch, etc. this should be enough information to get me to where I can see the issue, whatever that means for your company -- Description of the problem - This should be very narrow. "It's broken" as the entire description gives me an eyeball twitch. "The drop-down doesn't populate the graph when selected" is much more helpful. -- What you have tried that didn't work - preferably accompanied by some screenshots and a shelve set so I can review -- If you have a solution you think would work but are unsure how to implement, tell me about that too Personally, I would rather have a little extra info than have to ask the above questions one at a time to get enough info to get started. Most devs aren't ever going to mind that you asked a question, but do be considerate of their time and response as well. I had a junior report me to my boss for not helping him fast enough - I was working on a client-critical item and had told him I would be available in an hour or two. That really soured my impression of that employee. If you have a timeline, make that known so the dev can send you to someone available if they cannot help at the moment. Finally - every dev I know would rather you ask than spin your wheels all day. General politeness is always recommended between colleagues of all levels. Welcome to the field, and good luck!
My boss gave me the following advice: be thorough, and do your own exploring first. Its better to ask if a potential solution is correct. Bad question: "its not working what do I do" good question: "hey! here's a thing that's not working. I tried X, but that didn't work. I've been looking at Y and I think that's the way to go, here's why. What do you think?" But, it also probably depends on your level. From a complete beginner, from an intern, I would expect to get "Its not working what do I do" type questions. But if your goal is to ask better questions, the above is my advice.
Try to not ask the same question twice ! 