3 ms·

As a junior dev, sometimes I've been blocked for hours because I want to show that I can solve problems independently. But I've definitely had cases where I sho

As a junior dev, sometimes I've been blocked for hours because I want to show that I can solve problems independently. But I've definitely had cases where I should've asked questions early. A question that takes 1 minute to answer could have saved hours. For instance, I was stuck on figuring out how to send an email through AWS. Turns out we have a lambda function that handles all the authentication and security things that are specific to our company. Once I asked my coworker and found out about this function, it was trivial.

ZephyrBlu 3y ago
The distinction between trying to solve a problem yourself vs ask for help is: are you figuring out a new problem, or figuring out the system? If you're trying to figure out the system, you should probably ask for help ASAP and build up some knowledge. Over time you'll need to ask questions about the system less frequently. If you're trying to figure out a new problem related to your work, slogging away at it for a while is more ok because it's value-add and a good learning experience. The lines are a bit blurry, but that's how I tend to think about this.
- smeej 3y ago
  I had a manager when I was a new hire who had no concept of this difference at all, and it led to his firing me in my 4th week because I "should have been coming in with more knowledge." He actually told me I should have just come in and started doing things whatever way seemed best to me, like he did, when he was the first employee in the company in the role. Never mind that it was a compliance-heavy role in risk analysis and I was the 5th person on a 5-person team. Sure, I knew plenty of ways to solve the problems. What I didn't know were what systems they had (or, in most cases, didn't have) in place to document investigations, which absolutely must be done. I know plenty about what I'm doing. What I need to know is how you want it recorded. And in fact he had reinvented the entire documentation system during my 2nd week, on a whim. Firing me that fast was the best gift that company could have given me, because things would not have improved between us.
eminence32 3y ago
As you get more and more experience, I think this will become easier. You'll eventually get a feel for what types of questions you should just work through yourself, and which types of questions you should ask someone else about, and the threshold for moving between the two (you'll develop a sense of "let me investigate theory A, B, and C, and if I still can't figure it out, I'll ask for help"). Some of this will probably be via an increased understanding of the types of problems you can and can't solve. And some of this will probably be because you'll eventually know more people who can help (something like "oh yeah, I know Sam worked on a similar problem last month, let me see if they found a solution")
- switchbak 3y ago
  There's also a minimum bar of seeking that you need to have both performed and can demonstrate - this shows you're doing your due diligence, and not just wasting the more senior developer's time. It also provides you the context you need to understand the solution. The last thing you want is a LMGTFY moment from someone who was interrupted from deep focus on a hard problem (or worse: a series of them).
NhanH 3y ago
The nuance here lies within the “hours” quantifier. A junior member being blocked for 3-8 hours semi-regularly is expected. Once every other month you probably should be blocked for several work days as well. In your example, the challenge would have been realizing you wouldn’t have been the first one trying to send an email in the team. Recognizing that and it is very easy to know that you should just ask the question right away. It’s not a technical skill, but something a bit more meta.
- wins32767 3y ago
  This is really bad advice. Don't let yourself be blocked for several days. Try for 2-3 hours and ask for help.
  - dkjaudyeqooe 3y ago
    I'd say that's excessive. An hour max would be more reasonable otherwise you're just creating a discouraging workplace. Note that would be an hour of real effort though, not half arsed googling. Making a genuine effort is more important than the time taken.
    - c0pium 3y ago
      The amount of time is entirely dependent on what kind of work it is and what kind of blocked you are. Can’t get your build to succeed? Ask for help quickly. Can’t get your research model to produce useful results on the first try? Maybe try a few things first.
      - NhanH 3y ago
        Yeah, it's a bit disheartening to hear some (presumably) experienced people advocates for never allowing the junior to dig and deal with things on their owns. I can imagine the scenario where a build fail due to some missing incantations that needs to be invoked, and sure, you shouldn't spend more than 15 minutes on trying to resolve it. But that should be rare, while the common blockers for junior tend to be their lack of understanding in even bog-standard systems and situations (why can't system X do Y, why did person Z require A). In those cases, part of the expectation when assigning them the work would be for the junior to learn those on their own.
SkyBelow 3y ago
If you lost hours digging through the code and trying things to solve the problem, they aren't really lost. The knowledge you gain from this, the code you dug through, etc. all help builds up the experience that leads to one day no longer being a junior. Being given the answer is fast, but it doesn't lead to as much learning, especially in a career where knowing how find answers is more important long term than knowing the answers.
nerpderp82 3y ago
Blocked for hours is you learning and totally OK if you are learning. If one is operating open loop and stabbing at configuration options in a brute force manner to "make something work quickly" that isn't learning. Not saying you did this, but I do see this in a number of folks. They don't learn, and they don't form a model of the system. Those folks can be replaced by an LLM and Z3.

ZephyrBlu 3y ago

The distinction between trying to solve a problem yourself vs ask for help is: are you figuring out a new problem, or figuring out the system? If you're trying to figure out the system, you should probably ask for help ASAP and build up some knowledge. Over time you'll need to ask questions about the system less frequently. If you're trying to figure out a new problem related to your work, slogging away at it for a while is more ok because it's value-add and a good learning experience. The lines are a bit blurry, but that's how I tend to think about this.

smeej 3y ago
I had a manager when I was a new hire who had no concept of this difference at all, and it led to his firing me in my 4th week because I "should have been coming in with more knowledge." He actually told me I should have just come in and started doing things whatever way seemed best to me, like he did, when he was the first employee in the company in the role. Never mind that it was a compliance-heavy role in risk analysis and I was the 5th person on a 5-person team. Sure, I knew plenty of ways to solve the problems. What I didn't know were what systems they had (or, in most cases, didn't have) in place to document investigations, which absolutely must be done. I know plenty about what I'm doing. What I need to know is how you want it recorded. And in fact he had reinvented the entire documentation system during my 2nd week, on a whim. Firing me that fast was the best gift that company could have given me, because things would not have improved between us.

eminence32 3y ago

As you get more and more experience, I think this will become easier. You'll eventually get a feel for what types of questions you should just work through yourself, and which types of questions you should ask someone else about, and the threshold for moving between the two (you'll develop a sense of "let me investigate theory A, B, and C, and if I still can't figure it out, I'll ask for help"). Some of this will probably be via an increased understanding of the types of problems you can and can't solve. And some of this will probably be because you'll eventually know more people who can help (something like "oh yeah, I know Sam worked on a similar problem last month, let me see if they found a solution")

switchbak 3y ago
There's also a minimum bar of seeking that you need to have both performed and can demonstrate - this shows you're doing your due diligence, and not just wasting the more senior developer's time. It also provides you the context you need to understand the solution. The last thing you want is a LMGTFY moment from someone who was interrupted from deep focus on a hard problem (or worse: a series of them).

NhanH 3y ago

The nuance here lies within the “hours” quantifier. A junior member being blocked for 3-8 hours semi-regularly is expected. Once every other month you probably should be blocked for several work days as well. In your example, the challenge would have been realizing you wouldn’t have been the first one trying to send an email in the team. Recognizing that and it is very easy to know that you should just ask the question right away. It’s not a technical skill, but something a bit more meta.

wins32767 3y ago
This is really bad advice. Don't let yourself be blocked for several days. Try for 2-3 hours and ask for help.
- dkjaudyeqooe 3y ago
  I'd say that's excessive. An hour max would be more reasonable otherwise you're just creating a discouraging workplace. Note that would be an hour of real effort though, not half arsed googling. Making a genuine effort is more important than the time taken.
  - c0pium 3y ago
    The amount of time is entirely dependent on what kind of work it is and what kind of blocked you are. Can’t get your build to succeed? Ask for help quickly. Can’t get your research model to produce useful results on the first try? Maybe try a few things first.
    - NhanH 3y ago
      Yeah, it's a bit disheartening to hear some (presumably) experienced people advocates for never allowing the junior to dig and deal with things on their owns. I can imagine the scenario where a build fail due to some missing incantations that needs to be invoked, and sure, you shouldn't spend more than 15 minutes on trying to resolve it. But that should be rare, while the common blockers for junior tend to be their lack of understanding in even bog-standard systems and situations (why can't system X do Y, why did person Z require A). In those cases, part of the expectation when assigning them the work would be for the junior to learn those on their own.

SkyBelow 3y ago

If you lost hours digging through the code and trying things to solve the problem, they aren't really lost. The knowledge you gain from this, the code you dug through, etc. all help builds up the experience that leads to one day no longer being a junior. Being given the answer is fast, but it doesn't lead to as much learning, especially in a career where knowing how find answers is more important long term than knowing the answers.

nerpderp82 3y ago

Blocked for hours is you learning and totally OK if you are learning. If one is operating open loop and stabbing at configuration options in a brute force manner to "make something work quickly" that isn't learning. Not saying you did this, but I do see this in a number of folks. They don't learn, and they don't form a model of the system. Those folks can be replaced by an LLM and Z3.