<story><title>6 days to change 1 line of code (2015)</title><url>https://edw519.posthaven.com/it-takes-6-days-to-change-1-line-of-code</url></story><parent_chain><item><author>nojvek</author><text>The core issue here is reviewer saying “if you change this, you also have to fix other pending issues in codebase”.&lt;p&gt;That should be the point of push back “Great feedback, and appreciate the direction to improve code quality, however the implications of changing Y means we need X, Y, Z approval and it will many days. I am making a tech debt task with what you described and will be done in a follow up PR based on priority and bandwidth.&lt;p&gt;Let’s focus on what it would take to get this surgical PR out.”&lt;p&gt;The biggest lesson I learned is to make focused PRs, and learn to pushback when reviewer asks for a scope creep. Mostly other engineers have been pragmatic.&lt;p&gt;It’s unrelated to number of lines as you can reformat while codebase but not change anything logically, or change some feature flags which could have a huge impact. But ONE FOCUSED CHANGE AT A TIME</text></item></parent_chain><comment><author>Paul-Craft</author><text>&amp;gt;  The core issue here is reviewer saying “if you change this, you also have to fix other pending issues in codebase”.&lt;p&gt;I don&amp;#x27;t agree. IMO, the worst issue being displayed here is that of the &amp;quot;6 days to change 1 line of code,&amp;quot; almost half of them elapsed &lt;i&gt;before an engineer ever looked at the issue.&lt;/i&gt;  If this is such a high priority issue that the company would &amp;quot;need&amp;quot; (scare quotes intentional) to do a layoff if it&amp;#x27;s not implemented soon, those 2-3 days before anyone looked at it should never have happened.  And that is apparently what passes for &amp;quot;the fast track&amp;quot; in this development process.&lt;p&gt;And then there&amp;#x27;s the 2 days at the &lt;i&gt;end&lt;/i&gt; of this 6 day period where it looks like nothing happened, because the test plan was deemed insufficient.&lt;p&gt;&amp;quot;If you change this, you also have to fix other pending issues&amp;quot; only took up 2 hours here.  There are at least 2 or 3 other things I could fill in here that I&amp;#x27;d flag as core issues with this process before I&amp;#x27;d even &lt;i&gt;think&lt;/i&gt; about dealing with this part of the process.</text></comment>
<story><title>6 days to change 1 line of code (2015)</title><url>https://edw519.posthaven.com/it-takes-6-days-to-change-1-line-of-code</url></story><parent_chain><item><author>nojvek</author><text>The core issue here is reviewer saying “if you change this, you also have to fix other pending issues in codebase”.&lt;p&gt;That should be the point of push back “Great feedback, and appreciate the direction to improve code quality, however the implications of changing Y means we need X, Y, Z approval and it will many days. I am making a tech debt task with what you described and will be done in a follow up PR based on priority and bandwidth.&lt;p&gt;Let’s focus on what it would take to get this surgical PR out.”&lt;p&gt;The biggest lesson I learned is to make focused PRs, and learn to pushback when reviewer asks for a scope creep. Mostly other engineers have been pragmatic.&lt;p&gt;It’s unrelated to number of lines as you can reformat while codebase but not change anything logically, or change some feature flags which could have a huge impact. But ONE FOCUSED CHANGE AT A TIME</text></item></parent_chain><comment><author>figassis</author><text>Usually I avoid making any improvement that is not directly related to the tasks at hand. Even adding a missing semicolon risks bringing this to the attention of an overzealous reviewer that will then make me follow a rabbit hole of legacy fixes.&lt;p&gt;I’d rather create issues silently so I don’t forget instead of even adding a FIXME or TODO. I think this part of reviews is broken. Resolving tech debt should not be a requirement for completing a task, it should be planned.</text></comment>