<story><title>The Economics of Clean Code</title><url>https://frederickvanbrabant.com/post/2020-02-07-the-economics-of-clean-code/</url></story><parent_chain><item><author>gwbas1c</author><text>I&amp;#x27;ve had a few arguments with junior developers about clean code. They want to hyper-abstract everything because that&amp;#x27;s what they learned in school.&lt;p&gt;Then I point out that, if they just refactor to a single method that&amp;#x27;s 20 lines, they can read it from beginning to end and it makes sense.</text></item><item><author>blowski</author><text>There&amp;#x27;s a difference between a super-experienced, super-senior developer &amp;quot;keeping their code clean&amp;quot; and a junior one doing the same thing.&lt;p&gt;Juniors just thrash around from one design pattern to the next, never really achieving anything other than learning what doesn&amp;#x27;t work.&lt;p&gt;A much more experienced developer will have an understanding about what clean code looks and where it&amp;#x27;s necessary. They will recognise when there is a huge amount of uncertainty, for example, so spend less time writing loads of fantastic code before they&amp;#x27;ve firmed up the requirements.&lt;p&gt;So it really depends on the nature of the project and who you have on your team as to whether you need to worry about &amp;#x27;clean code&amp;#x27;.</text></item></parent_chain><comment><author>CaptArmchair</author><text>Here&amp;#x27;s another tip for juniors: Avoid Golden Hammer syndrome.&lt;p&gt;Developers do deep work with a framework which ties them to a specific language and the accompanying ecosystem. So, what you see is the &amp;quot;not invented here&amp;quot; syndrome, and how already solved problems are tackled again in that specific ecosystem.&lt;p&gt;Many solstices ago, I was a PHP developer. If you&amp;#x27;d ask me to split a 2.55 Gb CSV file in several CSV files as a one-off request, I would have fiddled with a PHP script, because that was my bread and butter. Probably would have taken something like &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;csv.thephpleague.com&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;csv.thephpleague.com&amp;#x2F;&lt;/a&gt; off the shelf to get the job done.&lt;p&gt;Well, no, you can do exactly that in a single line with tail, head, split and cat.&lt;p&gt;Since I moved away from PHP, I have come to find a new, deep  respect for the already existing general purpose commands which are part of the Unix spec. And reflecting on my earlier work, I realize that I could have solved some challenges a lot quicker.&lt;p&gt;Now, this is not a stab at clean code or PHP. Both are valuable tools.&lt;p&gt;Rather, a big lesson for young developers is that the cleanest code out there... is the code you didn&amp;#x27;t write at all, as you leverage what&amp;#x27;s already there.</text></comment>
<story><title>The Economics of Clean Code</title><url>https://frederickvanbrabant.com/post/2020-02-07-the-economics-of-clean-code/</url></story><parent_chain><item><author>gwbas1c</author><text>I&amp;#x27;ve had a few arguments with junior developers about clean code. They want to hyper-abstract everything because that&amp;#x27;s what they learned in school.&lt;p&gt;Then I point out that, if they just refactor to a single method that&amp;#x27;s 20 lines, they can read it from beginning to end and it makes sense.</text></item><item><author>blowski</author><text>There&amp;#x27;s a difference between a super-experienced, super-senior developer &amp;quot;keeping their code clean&amp;quot; and a junior one doing the same thing.&lt;p&gt;Juniors just thrash around from one design pattern to the next, never really achieving anything other than learning what doesn&amp;#x27;t work.&lt;p&gt;A much more experienced developer will have an understanding about what clean code looks and where it&amp;#x27;s necessary. They will recognise when there is a huge amount of uncertainty, for example, so spend less time writing loads of fantastic code before they&amp;#x27;ve firmed up the requirements.&lt;p&gt;So it really depends on the nature of the project and who you have on your team as to whether you need to worry about &amp;#x27;clean code&amp;#x27;.</text></item></parent_chain><comment><author>sunaurus</author><text>I assume what you&amp;#x27;re arguing against is using small functions with descriptive names as documentation. If that&amp;#x27;s the case, I think the term &amp;quot;hyper-abstract&amp;quot; is a massive overstatement.&lt;p&gt;In any case, I think the core issue is really how much faith you have in the proficiency of your teammates. If you can&amp;#x27;t trust the developers in your team to actually only write functions that do what they say in the name (without nasty side-effects), then I can see why not having all the logic in front of you in one giant function can be annoying - you have to jump into all the definitions and manually double check to be sure what&amp;#x27;s happening.</text></comment>