3 ms·

In my experience, the people who are best at error handling, performance, test coverage, nailing down invariants/validation/parsing, etc, are also the people pu

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.
  - johnnyanmac 2y ago
    if we're being frank: When you care about the company and feel the company cares about the tech. Both of those aligning are rare. Broken windows and all that. Now for a proper engineering answer, there's a few (but not limited to) factors to consider when determining software rigidity: - Halo effect: How much code does this module affect? The more things that can break when the module fails, the more need to get proper testing/architecture. - Frequency (in both ways): How often are you changing the code (is it cutting edge, or bog standard 50+ year old algorithms?) as well as how often the application calls the code. The more times its called or changed, the more you may appreciate ways to test new implementations with minimal impact to the current iteration. - Understanding: pretty straightforward. The less you or the team understands the code, the more need to validate that code through tests. This often falls into frequency, because inevitable the less you understand the more you will need to tinker, possibly for unknown unknowns. It's still subjective at the end of the day, but there are metrics you can use to make your case.
michaelt 2y ago
My experience is different. Given the choice between fixing a quality issue that can be easily measured/detected and one that cannot, a lot of people will prefer the measurable, easy-to-detect one. So the folks on the 'code quality' committee end up introducing tools that make it impossible to merge if your markdown file has two consecutive blank lines - rather than spending the time on performance or security which are much harder to keep on top of with automated tooling.

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.
- johnnyanmac 2y ago
  if we're being frank: When you care about the company and feel the company cares about the tech. Both of those aligning are rare. Broken windows and all that. Now for a proper engineering answer, there's a few (but not limited to) factors to consider when determining software rigidity: - Halo effect: How much code does this module affect? The more things that can break when the module fails, the more need to get proper testing/architecture. - Frequency (in both ways): How often are you changing the code (is it cutting edge, or bog standard 50+ year old algorithms?) as well as how often the application calls the code. The more times its called or changed, the more you may appreciate ways to test new implementations with minimal impact to the current iteration. - Understanding: pretty straightforward. The less you or the team understands the code, the more need to validate that code through tests. This often falls into frequency, because inevitable the less you understand the more you will need to tinker, possibly for unknown unknowns. It's still subjective at the end of the day, but there are metrics you can use to make your case.

michaelt 2y ago

My experience is different. Given the choice between fixing a quality issue that can be easily measured/detected and one that cannot, a lot of people will prefer the measurable, easy-to-detect one. So the folks on the 'code quality' committee end up introducing tools that make it impossible to merge if your markdown file has two consecutive blank lines - rather than spending the time on performance or security which are much harder to keep on top of with automated tooling.