<story><title>Ask stupid questions as a new software developer</title><url>https://www.nikitakazakov.com/ask-stupid-questions-as-software-developer</url></story><parent_chain><item><author>onion2k</author><text>Very often you won&amp;#x27;t get that upfront research because juniors don&amp;#x27;t have the knowledge necessary to even start looking for themselves. Because you expect them to come to you with evidence before they ask you, your devs will just avoid asking you and spend hours wasting time instead. Any minimum requirements are a barrier. Barriers are bad for learning.&lt;p&gt;You need to welcome questions even from people who have apparently done no research at all, or juniors will always worry that you&amp;#x27;ll accuse them of not doing the &amp;quot;necessary&amp;quot; work up front. If you&amp;#x27;re kind and approachable, and you don&amp;#x27;t tell people off for failing to meet your minimum requirements, you can guide them to finding it themselves.</text></item><item><author>mceachen</author><text>Please ask me any question, regardless of how dumb you think it will make you look, after you&amp;#x27;ve spent at least 5 minutes trying to answer it yourself.&lt;p&gt;Bonus Points if you summarize your quick research efforts.&lt;p&gt;Extra Bonus Points if this leads to more questions.&lt;p&gt;(Caveat emptor: _many_ engineers are decidedly antisocial, but if you show that you did prior research before asking, you&amp;#x27;re showing to them that you value their time as much as your own, and there&amp;#x27;s a better chance that they will be receptive to collaboration.)</text></item></parent_chain><comment><author>gregkerzhner</author><text>I would argue that those &amp;quot;hours wasting time&amp;quot; looking for an answer yourself before you give up and ask someone more senior aren&amp;#x27;t a waste - they are an invaluable part of becoming senior yourself.&lt;p&gt;As a senior engineer, you will often spend hours and days stuck trying to solve hard problems with noone else to ask, and having the grit, determination and creativity to do this is one of the greatest skills you can teach an engineer. Having barriers and friction in the name of this self sufficiency is totally fine and likely beneficial to the development of a junior dev.</text></comment>
<story><title>Ask stupid questions as a new software developer</title><url>https://www.nikitakazakov.com/ask-stupid-questions-as-software-developer</url></story><parent_chain><item><author>onion2k</author><text>Very often you won&amp;#x27;t get that upfront research because juniors don&amp;#x27;t have the knowledge necessary to even start looking for themselves. Because you expect them to come to you with evidence before they ask you, your devs will just avoid asking you and spend hours wasting time instead. Any minimum requirements are a barrier. Barriers are bad for learning.&lt;p&gt;You need to welcome questions even from people who have apparently done no research at all, or juniors will always worry that you&amp;#x27;ll accuse them of not doing the &amp;quot;necessary&amp;quot; work up front. If you&amp;#x27;re kind and approachable, and you don&amp;#x27;t tell people off for failing to meet your minimum requirements, you can guide them to finding it themselves.</text></item><item><author>mceachen</author><text>Please ask me any question, regardless of how dumb you think it will make you look, after you&amp;#x27;ve spent at least 5 minutes trying to answer it yourself.&lt;p&gt;Bonus Points if you summarize your quick research efforts.&lt;p&gt;Extra Bonus Points if this leads to more questions.&lt;p&gt;(Caveat emptor: _many_ engineers are decidedly antisocial, but if you show that you did prior research before asking, you&amp;#x27;re showing to them that you value their time as much as your own, and there&amp;#x27;s a better chance that they will be receptive to collaboration.)</text></item></parent_chain><comment><author>mceachen</author><text>Agreed, it&amp;#x27;s a tricky balance.&lt;p&gt;To be clear, I don&amp;#x27;t believe I&amp;#x27;ve ever said these &amp;quot;rules&amp;quot; aloud.&lt;p&gt;When someone comes to me for help, the first step is for them to explain the problem. The next step is for them to discuss what solutions they&amp;#x27;re considering. If they&amp;#x27;re at a loss, I open a browser window and ask them what they think a good query would look like, and pattern behavior that helps them in the future, and we work off of that for a bit before I may suggest actual implementation strategies, and walk through pros and cons of each approach.</text></comment>