3 ms·

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

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.

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.