5 ms·

I saw this advice online somewhere ages ago and I've found it to be incredibly useful-- Before you ask a question, try to answer it yourself for fifteen minute

by aqme28 4y ago

I saw this advice online somewhere ages ago and I've found it to be incredibly useful-- Before you ask a question, try to answer it yourself for fifteen minutes. If you still don't know, then ask. This way, you'll know that it's not a dumb question. But if it really is a good question, you won't be struggling for hours before asking anybody about it. You'll also learn a lot trying to solve it, and remember the answer better than if someone just told you.

onion2k 4y ago
This is good advice but there's an important caveat. After spending 15 minutes trying to answer the question you should still ask the question even if you have an answer. The problem with the advice is that it implies questions have one good answer. For most dev questions there will be many answers, and a lot of them will be awful. For example, if a junior asks themselves "How do I sort this list of things?", they'll probably come up with a solution inside of 15 minutes if they're good. That solution probably won't pass a code review though. The issue is that as a new dev you don't have the depth of knowledge to understand whether you solution is actually a good one or not. Talking about your idea with the rest of the team is critical for learning about some of the nuances around solving problems. (This also applies to more senior devs too. Everyone should be talking about what they're doing occasionally.)
- mejutoco 4y ago
  With certain problems what I do is to sketch a rough Merge Request and share that with others to confirm the general approach. It works wonders, and discussing actual code makes it easier for most people than discussing abstract concepts.
- watwut 4y ago
  If the team will have to solve every problem you encounter, they will eventually conclude you are useless and unable to do work. I mean come on, with this strategy, you contribution to team will be negative. This kind of advice really goes overboard and harms people who would listen to it.
  - onion2k 4y ago
    Firstly, we talking about new devs. Once you get a bit more experience you start making more of these calls yourself. Secondly, sanity checking an approach to solving a problem with rest of the team is just basic common sense - someone else might be solving the same problem, or have some insight into a part of the code you haven't touched, or have experience of the same issue on another team. That never goes away regardless of your level. The suggestion that you should solve problems on your own is far more harmful. Software development is a team sport.
fraudsyndrome 4y ago
Reading this makes me feel like a super slow learner. I've experienced the "15 minute rule" before and for me, 15 minutes goes by so quick. I might have a question, try to find the answer, find several answers and have to dig into them to understand the answer to determine which is likely the better one etc. But this in no way takes 15 minutes, could be 30 45 60 or more. It's like I get a step closer and each "phase" is a new 15 minutes and so a new question to ask.

by aqme28 4y ago

onion2k 4y ago

This is good advice but there's an important caveat. After spending 15 minutes trying to answer the question you should still ask the question even if you have an answer. The problem with the advice is that it implies questions have one good answer. For most dev questions there will be many answers, and a lot of them will be awful. For example, if a junior asks themselves "How do I sort this list of things?", they'll probably come up with a solution inside of 15 minutes if they're good. That solution probably won't pass a code review though. The issue is that as a new dev you don't have the depth of knowledge to understand whether you solution is actually a good one or not. Talking about your idea with the rest of the team is critical for learning about some of the nuances around solving problems. (This also applies to more senior devs too. Everyone should be talking about what they're doing occasionally.)

mejutoco 4y ago
With certain problems what I do is to sketch a rough Merge Request and share that with others to confirm the general approach. It works wonders, and discussing actual code makes it easier for most people than discussing abstract concepts.
watwut 4y ago
If the team will have to solve every problem you encounter, they will eventually conclude you are useless and unable to do work. I mean come on, with this strategy, you contribution to team will be negative. This kind of advice really goes overboard and harms people who would listen to it.
- onion2k 4y ago
  Firstly, we talking about new devs. Once you get a bit more experience you start making more of these calls yourself. Secondly, sanity checking an approach to solving a problem with rest of the team is just basic common sense - someone else might be solving the same problem, or have some insight into a part of the code you haven't touched, or have experience of the same issue on another team. That never goes away regardless of your level. The suggestion that you should solve problems on your own is far more harmful. Software development is a team sport.

fraudsyndrome 4y ago

Reading this makes me feel like a super slow learner. I've experienced the "15 minute rule" before and for me, 15 minutes goes by so quick. I might have a question, try to find the answer, find several answers and have to dig into them to understand the answer to determine which is likely the better one etc. But this in no way takes 15 minutes, could be 30 45 60 or more. It's like I get a step closer and each "phase" is a new 15 minutes and so a new question to ask.