<story><title>Ask HN: How to improve code quality while maintaining decent velocity?</title><text>Hi,
I believe I&amp;#x27;m a decent programmer, may not be a rockstar or anything. Recently I&amp;#x27;ve changed my company to one of the &amp;quot;sought afters&amp;quot;, and I&amp;#x27;ve noticed that I&amp;#x27;ve been getting some comments about the quality of work and some uncomfortable questions about my skills.  I&amp;#x27;ve been forced to change my design more than once during code review and there were other times when my PR was outright rejected as it did not meet the required standards.&lt;p&gt;Now I&amp;#x27;m a little worried that if my situation doesn&amp;#x27;t change, my career would suffer. I&amp;#x27;ve started to watch a few videos online about design.  But I&amp;#x27;m not sure if they&amp;#x27;re going to really help as they usually talk about very basics which doesn&amp;#x27;t help in real world coding.&lt;p&gt;I usually take 3-4 tries with some significant amount of testing to get my code to a working state.  I refer to stack overflow or ask my colleagues if I get stuck on some design &amp;#x2F; technology feature which I haven&amp;#x27;t seen before. I feel the above contributes to reduction in my speed of delivery and the rush to complete the deliverable on time, compromises the quality.&lt;p&gt;Are there any good ideas to improve one&amp;#x27;s coding &amp;#x2F; design skills significantly ? The challenge here is to deliver good quality code, while maintaining a decent speed of delivery.</text></story><parent_chain><item><author>jordanpg</author><text>Right, but there is another side to this coin.  There are good questions, and then there are questions that evince&amp;#x2F;exhibit:&lt;p&gt;* basic reading comprehension issues&lt;p&gt;* trivial matters that could have been looked up in an obvious reference&lt;p&gt;* completely unrelated tangents, asked out of idle curiosity&lt;p&gt;* questions asked solely to demonstrate &amp;quot;participation&amp;quot; (nothing wrecks a classroom like a &amp;quot;participation&amp;quot; grade)&lt;p&gt;In my experience, these comprise the bulk of questions that are asked in non-STEM university and graduate settings.&lt;p&gt;I don&amp;#x27;t call these questions stupid, but they are a waste of time, do not move the ball down the field at all, and discourage self-learning.</text></item><item><author>Rainymood</author><text>&amp;gt;Also a confused guy stopping meetings is the worst - taking time out of the entire team who now has to listen to stuff they already understand explained again. Pull someone aside afterwards for clarification.&lt;p&gt;&amp;quot;Also a student stopping lectures is the worst - taking time out of the entire classroom who now has to listen to stuff they already understand explained again. Pull someone aside afterwards for clarification.&amp;quot;&lt;p&gt;You are part of the reason why people are scared to speak up and ask &amp;quot;stupid&amp;quot; questions, and I feel like that ends up being a net negative.</text></item><item><author>rubber_duck</author><text>&amp;gt;Asking questions is a sign of strength.&lt;p&gt;Hell no ! Asking good questions absolutely - asking generic questions that can be googled in less than five minutes shows that you either can&amp;#x27;t search and solve problema on your own or don&amp;#x27;t respect my time.&lt;p&gt;I&amp;#x27;ve seen a lot of newbies take this approach when someone tells them this advice - I usually tell them after a few times and then if I see this pattern I recommend not keeping them because they end up being a net negative.&lt;p&gt;Also a confused guy stopping meetings is the worst - taking time out of the entire team who now has to listen to stuff they already understand explained again. Pull someone aside afterwards for clarification.</text></item><item><author>Pfhreak</author><text>Write down the things you got called out on in review. Build a checklist of them. Perform a self review for them.&lt;p&gt;So more code reviews and design reviews for others and try to ask why whenever you don&amp;#x27;t understand what you are looking at. Asking questions is a sign of strength.&lt;p&gt;Spend a little more time on design, and whiteboard with a coworker before you implement. Draw the boxes and arrows of your approach and reason about where it will break. It will break on some axis sometime, tell yourself where it is.&lt;p&gt;Find a mentor. There are tons of folks who would spend an hour every week answering questions about design that you were too shy to ask in the bigger group.&lt;p&gt;Stop meetings when you don&amp;#x27;t understand a term. Ask for a clarification.&lt;p&gt;Talk to your manager, be open about wanting to improve this specific skill. Speaking as an engineering manager myself, one of the most fulfilling parts of my job is seeing someone ask for help and giving them a chance to stretch and learn.&lt;p&gt;Accept failures. A failure just means you learned something. I&amp;#x27;ve seen some big failures and caused some big failures. I learned and moved on. That said, don&amp;#x27;t fail the same exact way more than once if you can help it.&lt;p&gt;Ask for peer feedback. Maybe no one else thinks you aren&amp;#x27;t performing. Maybe you&amp;#x27;ve set up a false narrative about yourself.&lt;p&gt;Ask, specifically, &amp;quot;am I asking for help too soon or too late&amp;quot; and really listen to the answer.</text></item></parent_chain><comment><author>RuleOfBirds</author><text>Just out of curiosity, where does your experience with &amp;quot;non-STEM university and grad settings&amp;quot; come from that you are judging and contrasting it so harshly with STEM?&lt;p&gt;Seems like you&amp;#x27;ve been in higher level STEM settings and your experience outside of that has been low level electives, you&amp;#x27;ve had limited and unusually poor samples, or you&amp;#x27;re just speaking out of bias for (presumably) your own path in life.&lt;p&gt;I don&amp;#x27;t think people who are not &amp;quot;STEM&amp;quot; are generally going around navigating the world and school like uninformed, idiot freshman who don&amp;#x27;t know how to participate in their own education... At least not any more then people in STEM are ;-)</text></comment>
<story><title>Ask HN: How to improve code quality while maintaining decent velocity?</title><text>Hi,
I believe I&amp;#x27;m a decent programmer, may not be a rockstar or anything. Recently I&amp;#x27;ve changed my company to one of the &amp;quot;sought afters&amp;quot;, and I&amp;#x27;ve noticed that I&amp;#x27;ve been getting some comments about the quality of work and some uncomfortable questions about my skills.  I&amp;#x27;ve been forced to change my design more than once during code review and there were other times when my PR was outright rejected as it did not meet the required standards.&lt;p&gt;Now I&amp;#x27;m a little worried that if my situation doesn&amp;#x27;t change, my career would suffer. I&amp;#x27;ve started to watch a few videos online about design.  But I&amp;#x27;m not sure if they&amp;#x27;re going to really help as they usually talk about very basics which doesn&amp;#x27;t help in real world coding.&lt;p&gt;I usually take 3-4 tries with some significant amount of testing to get my code to a working state.  I refer to stack overflow or ask my colleagues if I get stuck on some design &amp;#x2F; technology feature which I haven&amp;#x27;t seen before. I feel the above contributes to reduction in my speed of delivery and the rush to complete the deliverable on time, compromises the quality.&lt;p&gt;Are there any good ideas to improve one&amp;#x27;s coding &amp;#x2F; design skills significantly ? The challenge here is to deliver good quality code, while maintaining a decent speed of delivery.</text></story><parent_chain><item><author>jordanpg</author><text>Right, but there is another side to this coin.  There are good questions, and then there are questions that evince&amp;#x2F;exhibit:&lt;p&gt;* basic reading comprehension issues&lt;p&gt;* trivial matters that could have been looked up in an obvious reference&lt;p&gt;* completely unrelated tangents, asked out of idle curiosity&lt;p&gt;* questions asked solely to demonstrate &amp;quot;participation&amp;quot; (nothing wrecks a classroom like a &amp;quot;participation&amp;quot; grade)&lt;p&gt;In my experience, these comprise the bulk of questions that are asked in non-STEM university and graduate settings.&lt;p&gt;I don&amp;#x27;t call these questions stupid, but they are a waste of time, do not move the ball down the field at all, and discourage self-learning.</text></item><item><author>Rainymood</author><text>&amp;gt;Also a confused guy stopping meetings is the worst - taking time out of the entire team who now has to listen to stuff they already understand explained again. Pull someone aside afterwards for clarification.&lt;p&gt;&amp;quot;Also a student stopping lectures is the worst - taking time out of the entire classroom who now has to listen to stuff they already understand explained again. Pull someone aside afterwards for clarification.&amp;quot;&lt;p&gt;You are part of the reason why people are scared to speak up and ask &amp;quot;stupid&amp;quot; questions, and I feel like that ends up being a net negative.</text></item><item><author>rubber_duck</author><text>&amp;gt;Asking questions is a sign of strength.&lt;p&gt;Hell no ! Asking good questions absolutely - asking generic questions that can be googled in less than five minutes shows that you either can&amp;#x27;t search and solve problema on your own or don&amp;#x27;t respect my time.&lt;p&gt;I&amp;#x27;ve seen a lot of newbies take this approach when someone tells them this advice - I usually tell them after a few times and then if I see this pattern I recommend not keeping them because they end up being a net negative.&lt;p&gt;Also a confused guy stopping meetings is the worst - taking time out of the entire team who now has to listen to stuff they already understand explained again. Pull someone aside afterwards for clarification.</text></item><item><author>Pfhreak</author><text>Write down the things you got called out on in review. Build a checklist of them. Perform a self review for them.&lt;p&gt;So more code reviews and design reviews for others and try to ask why whenever you don&amp;#x27;t understand what you are looking at. Asking questions is a sign of strength.&lt;p&gt;Spend a little more time on design, and whiteboard with a coworker before you implement. Draw the boxes and arrows of your approach and reason about where it will break. It will break on some axis sometime, tell yourself where it is.&lt;p&gt;Find a mentor. There are tons of folks who would spend an hour every week answering questions about design that you were too shy to ask in the bigger group.&lt;p&gt;Stop meetings when you don&amp;#x27;t understand a term. Ask for a clarification.&lt;p&gt;Talk to your manager, be open about wanting to improve this specific skill. Speaking as an engineering manager myself, one of the most fulfilling parts of my job is seeing someone ask for help and giving them a chance to stretch and learn.&lt;p&gt;Accept failures. A failure just means you learned something. I&amp;#x27;ve seen some big failures and caused some big failures. I learned and moved on. That said, don&amp;#x27;t fail the same exact way more than once if you can help it.&lt;p&gt;Ask for peer feedback. Maybe no one else thinks you aren&amp;#x27;t performing. Maybe you&amp;#x27;ve set up a false narrative about yourself.&lt;p&gt;Ask, specifically, &amp;quot;am I asking for help too soon or too late&amp;quot; and really listen to the answer.</text></item></parent_chain><comment><author>sailfast</author><text>Agreed, provided one is not so aggressive at preventing the questions you list that you effectively chill the environment for questions out of fear subsequent questions are “the bad ones”.&lt;p&gt;That for sure is a much worse outcome than the occasional “really?” kind of question. Some simple nudges to colleagues as checks (did you do the reading? Did you try to answer it yourself first?) before asking questions to keep things productive, for example, might be a good starting point rather than a Potentially more hostile approach that could frustrate well-meaning questioners.</text></comment>