<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>nthj</author><text>I’ve found people often overlook that while code can be very quickly deleted, gigabytes or terabytes of production data is a huge pain to ETL later. Investing in the data model upfront has huge payoffs for your code and avoiding ETLs later on.</text><parent_chain><item><author>skohan</author><text>Yeah this just hasn&amp;#x27;t been my experience.  If you&amp;#x27;re working on a house you measure twice and cut once because the cost of reworking physical materials is a lot more expensive than the cost of doing a second measurement.&lt;p&gt;If you could delete half your house and re-build it at zero cost, it might be more valuable to just go for the first attempt and learn from it rather than trying to do everything in theory up front.&lt;p&gt;If you find yourself working on a &amp;quot;monstrosity&amp;quot; maybe you haven&amp;#x27;t seen the signs soon enough that you need to take a step back and refactor.  But in my experience, at least starting on the problem with a POC gives you so much more high quality information that even if you have to scrap and re-write part way in, you&amp;#x27;re going to reach such a better result than if you try to map the whole thing out first without actually having tried to solve the problem.</text></item><item><author>jcbrand</author><text>Back in university I had an experience that was really instructive.&lt;p&gt;For a project we had to write a program that differentiates mathematical equations.&lt;p&gt;I dove in and just started writing code. Eventually, I realized that I had made a design error and that my code was &lt;i&gt;much&lt;/i&gt; more complicated and cumbersome than it needed to be and I was getting stuck due to the complexity of the monstrosity I created.&lt;p&gt;Unfortunately I figured this fundamental design flaw the night before we had to hand the assignment in and there was no way I could rewrite everything from scratch. I had to push through and put lipstick on this pig as best I could.&lt;p&gt;In the end, I had spent way more time working on this project than my friends who had spent time upfront designing their programs instead of just jumping in.&lt;p&gt;This has taught me the lesson to always first try and think things through and come up with some kind of initial design, instead of just jumping in and writing code blindly. Yes you can always refactor, but some early design mistakes can cost you a lot of time, and perhaps make refactoring unfeasible compared to a complete rewrite.&lt;p&gt;As they say &amp;quot;measure twice, cut once&amp;quot;.</text></item><item><author>skohan</author><text>The more code I&amp;#x27;ve written, the less I care about code quality.&lt;p&gt;I think the things I could point to in my coding practice which would make the code I write now better than the code I wrote 10 years ago would be:&lt;p&gt;- I minimize interdependencies (changing a line of code should not affect something un-related)&lt;p&gt;- I go for abstractions later, only when I need them, rather than trying to think of the perfect abstraction&amp;#x2F;design pattern which will solve the problem in the most elegant or clever way&lt;p&gt;Besides that, I&amp;#x27;m a huge fan of disposable code.  In my experience 99% of the time, the best approach is to just dive into the problem and try to solve the problem in the most pragmatic way.  Maybe that&amp;#x27;s hard-coding a lot of things.  Maybe that&amp;#x27;s having a small amount of repetition here and there.  Maybe it&amp;#x27;s writing one long function with 1000 lines.&lt;p&gt;After that it&amp;#x27;s all about continuous improvement.  You spend your time solving the problem, and when your code becomes hard to work on, you spend time improving your code to make it easier to work on by cleaning things up, and adding sensible abstractions which solve the problems you actually have.&lt;p&gt;In my experience, over time this approach leaves you with a very ergonomic and easy to understand codebase.</text></item><item><author>rawoke083600</author><text>So True !
After 25+ years of coding, I know one thing. I STILL don&amp;#x27;t know how to &amp;quot;code correctly&amp;quot;.&lt;p&gt;And apart from a few gifted individuals (Rob Pike, Fabrice Bellard Bobby Bingham [ffMpeg team] etc) I&amp;#x27;m HIGHLY suspicious of ppl and programmers who claim &amp;quot;they can program correctly&amp;quot; and that &amp;quot;this xyz is the correct way&amp;#x2F;stack&amp;#x2F;method&amp;#x2F;arch&amp;quot;.&lt;p&gt;Background:CS grad, start coding at around 13 (thank you dad !) I am well versed in C,C++,PHP,Go,TypeScript and to a lesser degree Java and a few bits and bobs in between F#,Haskell,LISP...&lt;p&gt;The above is not to brag (not that it&amp;#x27;s brag worthy after 25 years you bound to pick up a few tools) just to put it in perspective.&lt;p&gt;On Code quality:
I&amp;#x27;ve noticed it&amp;#x27;s easy to agree&amp;#x2F;identify the &amp;quot;extreme cases&amp;quot; the VERY VERY BAD CODING and the very very GOOD CODING. But most of the coders and codebases falls somewhere in between where the code-quality-water quickly gets murky.&lt;p&gt;PS2. Oh and on &amp;#x27;code reviews&amp;#x27;: It would be cool if code-reviews were done &amp;quot;anonymously&amp;quot; i.e I should not know until the very end WHO wrote the code. Helps to keep any personal biases at bay - my 2cents.&lt;p&gt;The &lt;i&gt;best&lt;/i&gt; thus far advise I&amp;#x27;ve seen on code-quality guidelines is from a comment on HN:&lt;p&gt;&amp;gt;I try to optimize my code around reducing state, coupling, complexity and code, in that order. I&amp;#x27;m willing to add increased coupling if it makes my code more stateless. I&amp;#x27;m willing to make it more complex if it reduces coupling. And I&amp;#x27;m willing to duplicate code if it makes the code less complex. Only if it doesn&amp;#x27;t increase state, coupling or complexity do I dedup code.&lt;p&gt;Source: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=11042400&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=11042400&lt;/a&gt;&lt;p&gt;Sure I might just be a dumb idiot or completely not gifted in the &amp;quot;art or science&amp;quot; of coding. :)</text></item></parent_chain></comment><story><title>There’s No Such Thing as Clean Code</title><url>https://www.steveonstuff.com/2022/01/27/no-such-thing-as-clean-code</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>gefhfffh</author><text>When can you rebuild at zero cost?&lt;p&gt;I have made similar avoidable mistakes of not thinking it through enough, could have saved me a lot of rewriting, which was pretty expensive</text><parent_chain><item><author>skohan</author><text>Yeah this just hasn&amp;#x27;t been my experience.  If you&amp;#x27;re working on a house you measure twice and cut once because the cost of reworking physical materials is a lot more expensive than the cost of doing a second measurement.&lt;p&gt;If you could delete half your house and re-build it at zero cost, it might be more valuable to just go for the first attempt and learn from it rather than trying to do everything in theory up front.&lt;p&gt;If you find yourself working on a &amp;quot;monstrosity&amp;quot; maybe you haven&amp;#x27;t seen the signs soon enough that you need to take a step back and refactor.  But in my experience, at least starting on the problem with a POC gives you so much more high quality information that even if you have to scrap and re-write part way in, you&amp;#x27;re going to reach such a better result than if you try to map the whole thing out first without actually having tried to solve the problem.</text></item><item><author>jcbrand</author><text>Back in university I had an experience that was really instructive.&lt;p&gt;For a project we had to write a program that differentiates mathematical equations.&lt;p&gt;I dove in and just started writing code. Eventually, I realized that I had made a design error and that my code was &lt;i&gt;much&lt;/i&gt; more complicated and cumbersome than it needed to be and I was getting stuck due to the complexity of the monstrosity I created.&lt;p&gt;Unfortunately I figured this fundamental design flaw the night before we had to hand the assignment in and there was no way I could rewrite everything from scratch. I had to push through and put lipstick on this pig as best I could.&lt;p&gt;In the end, I had spent way more time working on this project than my friends who had spent time upfront designing their programs instead of just jumping in.&lt;p&gt;This has taught me the lesson to always first try and think things through and come up with some kind of initial design, instead of just jumping in and writing code blindly. Yes you can always refactor, but some early design mistakes can cost you a lot of time, and perhaps make refactoring unfeasible compared to a complete rewrite.&lt;p&gt;As they say &amp;quot;measure twice, cut once&amp;quot;.</text></item><item><author>skohan</author><text>The more code I&amp;#x27;ve written, the less I care about code quality.&lt;p&gt;I think the things I could point to in my coding practice which would make the code I write now better than the code I wrote 10 years ago would be:&lt;p&gt;- I minimize interdependencies (changing a line of code should not affect something un-related)&lt;p&gt;- I go for abstractions later, only when I need them, rather than trying to think of the perfect abstraction&amp;#x2F;design pattern which will solve the problem in the most elegant or clever way&lt;p&gt;Besides that, I&amp;#x27;m a huge fan of disposable code.  In my experience 99% of the time, the best approach is to just dive into the problem and try to solve the problem in the most pragmatic way.  Maybe that&amp;#x27;s hard-coding a lot of things.  Maybe that&amp;#x27;s having a small amount of repetition here and there.  Maybe it&amp;#x27;s writing one long function with 1000 lines.&lt;p&gt;After that it&amp;#x27;s all about continuous improvement.  You spend your time solving the problem, and when your code becomes hard to work on, you spend time improving your code to make it easier to work on by cleaning things up, and adding sensible abstractions which solve the problems you actually have.&lt;p&gt;In my experience, over time this approach leaves you with a very ergonomic and easy to understand codebase.</text></item><item><author>rawoke083600</author><text>So True !
After 25+ years of coding, I know one thing. I STILL don&amp;#x27;t know how to &amp;quot;code correctly&amp;quot;.&lt;p&gt;And apart from a few gifted individuals (Rob Pike, Fabrice Bellard Bobby Bingham [ffMpeg team] etc) I&amp;#x27;m HIGHLY suspicious of ppl and programmers who claim &amp;quot;they can program correctly&amp;quot; and that &amp;quot;this xyz is the correct way&amp;#x2F;stack&amp;#x2F;method&amp;#x2F;arch&amp;quot;.&lt;p&gt;Background:CS grad, start coding at around 13 (thank you dad !) I am well versed in C,C++,PHP,Go,TypeScript and to a lesser degree Java and a few bits and bobs in between F#,Haskell,LISP...&lt;p&gt;The above is not to brag (not that it&amp;#x27;s brag worthy after 25 years you bound to pick up a few tools) just to put it in perspective.&lt;p&gt;On Code quality:
I&amp;#x27;ve noticed it&amp;#x27;s easy to agree&amp;#x2F;identify the &amp;quot;extreme cases&amp;quot; the VERY VERY BAD CODING and the very very GOOD CODING. But most of the coders and codebases falls somewhere in between where the code-quality-water quickly gets murky.&lt;p&gt;PS2. Oh and on &amp;#x27;code reviews&amp;#x27;: It would be cool if code-reviews were done &amp;quot;anonymously&amp;quot; i.e I should not know until the very end WHO wrote the code. Helps to keep any personal biases at bay - my 2cents.&lt;p&gt;The &lt;i&gt;best&lt;/i&gt; thus far advise I&amp;#x27;ve seen on code-quality guidelines is from a comment on HN:&lt;p&gt;&amp;gt;I try to optimize my code around reducing state, coupling, complexity and code, in that order. I&amp;#x27;m willing to add increased coupling if it makes my code more stateless. I&amp;#x27;m willing to make it more complex if it reduces coupling. And I&amp;#x27;m willing to duplicate code if it makes the code less complex. Only if it doesn&amp;#x27;t increase state, coupling or complexity do I dedup code.&lt;p&gt;Source: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=11042400&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=11042400&lt;/a&gt;&lt;p&gt;Sure I might just be a dumb idiot or completely not gifted in the &amp;quot;art or science&amp;quot; of coding. :)</text></item></parent_chain></comment><story><title>There’s No Such Thing as Clean Code</title><url>https://www.steveonstuff.com/2022/01/27/no-such-thing-as-clean-code</url></story>