3 ms·

It depends entirely on how you define perfectionism. The article unfortunately doesn't explain well what they meant. Assuming it is following, paradigms, desig

• jmac01 2y ago
  Clean code leads to more testable code leads to more tests leads to better products. Don't be so quick to dismiss "clean code" as some BS. I've seen first hand how someone writing a 500 line function struggles to test it. But splitting it up into more manageable chunks of functionality makes it easier to write a test. Imo perfectionism is chasing that last 5% performance. Clean code, design patterns etc are just good engineering practices... Not perfectionism ....
  • aswanson 2y ago
    Absolutely. Breaking a design down into verifiable, testable chunks is, imo, the major delineator between a school project and a professional product.
  • dgb23 2y ago
    Le me clarify: good modularization and abstractions emerge from engineering concerns (like the ones listed above) and not the other way around. The reason I wrote the above comment is because I've seen this being flipped on its head too often by myself and others.
  • dakiol 2y ago
    > Clean code, design patterns etc are just good engineering practices... Not perfectionism .... This is what I don’t like about software engineering. The dogmatism. The absolutism. The more I work in the field, the less I talk about “clean code”, “ddd”, “good practices”. I find myself saying more and more “it depends”, and more often than not what the business requires is not 5 layers of code in which the concerns are separated among dozens of files and following good design patterns, but a damn single file that get things done. There’s place for what you call good practices and clean code, but many times those things don’t lead to good products.
    • rectang 2y ago
      I really liked how jmac03 put things, and I don’t see the dogma you’re seeing — consider that it’s “struggles to test” not “impossible”. I don’t see any advocacy for ”dozens of files”, just breaking functionality down into “manageable chunks” to facilitate testing. In fact, “dozens of files” are arguably not “manageable“, and I don’t see an argument for that, any more than you’re arguing that every function needs to be 500 lines. Every single startup I’ve worked for has eventually come to terms with needing some best practices. In my view, there actually is a baseline: CI, partial coverage unit tests for the most easily testable code, and modularization/loose-coupling so that unwinding tech debt has linear rather than exponential cost. But even that is driven by my opinions about ROI, not theory in isolation.
    • johnnyanmac 2y ago
      >There’s place for what you call good practices and clean code, but many times those things don’t lead to good products. Clean code for a bad product won't turn it into a good product. That's the core issue. These are engineering principles but you are looking at them through business logic. The best metphor here is to compare clean code to insurance. You don't want to insure this? Okay, you can take that risk and maybe save if nothing happens. But if/when something happens it'll be more expensive than if you paid the insurance up front. Meanwhile, Clean code from a good product will make it resiliant to becoming a bad product. I'm sure if you played any modern video games that you've had at least a few games that you loved but had horrible technical hiccups. Unoptimized, untested logic, crashing. The issue is some of these games still sell, so maybe the business logic prevailed over properly engineered code. But they are entertainment at the end of the day, not Crowdstrike.
• Buttons840 2y ago
  In my experience, the people who are best at error handling, performance, test coverage, nailing down invariants/validation/parsing, etc, are also the people pushing for those nebulous perfections like "cleaner" code. Getting all those things right requires the code to be pretty darn clean.
  • dgb23 2y ago
    I'm not arguing against decomposition, modularisation, clarity or abstractions. Just don't do them for their own sake.
    • lazide 2y ago
      How do you decide when it’s ’for it’s own sake’ and when it’s not?
      • dgb23 2y ago
        That's a very good question that I need to think about way more.
      • rectang 2y ago
        To be cynical and uncharitable, in my experience non-engineering leadership tends to be receptive to the idea that engineers are by their nature wasteful and self indulgent, and saying “just don’t do that stuff for it’s own sake” reinforces said leadership’s prejudices and will ingratiate you with them. I’ve most often heard such arguments from people shitting on me for advocating for tests. But the bulk of my experience is with small startups where the stakes are high; tensions around productivity are natural, and working through them is essential.
      • piva00 2y ago
        Personally, the "Rule of Three of Software Engineering" has been a good enough practice for most cases, as usual with any rule of thumb there are exceptions but most of the time I can apply it. I've been using it for many, many years and it has saved me a countless hours by postponing abstractions, modularisation, etc. to the point where it actually emerges as a pattern in the software I'm working with. Let the code repeat itself, copy and paste, and only after some pattern repeat itself for the 3rd time I start to think on how to abstract, or modularise it. It's always so much easier to rework repeated code/patterns into abstractions than fixing misguided abstractions done too early.
• binary132 2y ago
  >design patterns and code cleanliness aren’t “actual engineering concerns” sigh
• daliusd 2y ago
  IMHO article defines perfectionism doing both things you have mentioned too early. E.g. you do prototype and instead of showing that to stakeholders you clean it up, cover with tests and etc.
• II2II 2y ago
  I like that word: diligent. Jordan seemed to be talking about it: prioritizing; helping, rather than burdening others. Gregor seemed to be describing a lack of diligence: not fleshing out learning, fretting over less relevant details. In my mind arguing for dilegence is a better here. It implies that the product matters, even if it is imperfect. Arguing against perfectionism is bad. To some it will imply that the product does not matter, that sloppy work is okay if you can somehow justify it (getting the job done, doing more, etc.).