3 ms·

I disagree. The problem with believing that "good code" is good enough to deliver business value is short-sighted. Good code is highly maintainable so that yo

I disagree. The problem with believing that "good code" is good enough to deliver business value is short-sighted. Good code is highly maintainable so that you can continue to meet business objectives in a timely manner without regressions. Often this means (ironically) taking a little bit of extra time early on to think about how to make your code readable and "simple enough" for someone else to be able to jump in and maintain it.

nailer 3y ago
> Focus instead on writing code you can throw away easily, code that you are wholly unattached to and is isolated enough that rewriting it won’t cost absurd hours. > Good code is highly maintainable so that you can continue to meet business objectives in a timely manner without regressions. I think you essentially agree on what people should do, regardless of whether you call this 'good code' or just maintainable code. Write tests. Give things good names. Use comments to explain why you're doing something, not how to program. Don't copy and paste the same implementation x times because that way there's only one place to fix it.
- nkjnlknlk 3y ago
  > Don't copy and paste the same implementation x times because that way there's only one place to fix it. But also sometimes it makes more sense to copy and paste over trying to fit an abstraction where it shouldn't be. :) I think the purpose of questions like the ones by OP is not to figure out "rules" (which are useful only for beginners) but to figure out where and why rules were broken. Sometimes (often) the answer is time, but that in and of itself is a useful example. Good intermediate (I suppose Sr. in our industry) level code is notoriously difficult to find examples of and mentor toward.
  - johnnyanmac 3y ago
    >But also sometimes it makes more sense to copy and paste over trying to fit an abstraction where it shouldn't be. :) depends on goals. diverging modules should be copy-pasted, two modules that rely on the same functionality should be consolidated (not necessarily abstracted, but synchronized somehow). Those are both two common cases, so there's no general advice on which is better. >Good intermediate (I suppose Sr. in our industry) level code is notoriously difficult to find examples of and mentor toward. so much industry code and knowledge is proprietary, so I imagine that is by design. even intermediate code has a bunch of value to a company, even if the company lets go of that engineer to make their earnings report 0.1% higher.
  - gwbas1c 3y ago
    > But also sometimes it makes more sense to copy and paste over trying to fit an abstraction where it shouldn't be. :) I find that's a smell of limited languages: Maybe a language has poor error handling semantics, maybe it's not expressive enough to make a parameter generic. It can also be a smell of not understanding the language well enough, too. Maybe there is no need to copy and paste, but the programmer didn't understand the language well enough to make a generic abstraction.
    - nkjnlknlk 3y ago
      I agree. I've had the unfortunate experience of moving from more expressive languages and interesting problems to less expressive languages and boring problems as the size of my TC and company go up. :') But you can only do what your tools allow you to do.
Zetice 3y ago
The problem with this “maintainability” argument is the presumption a) that it will be maintained (note I recommended rewriting frequently) or that b) it’s in conflict with meeting business objectives.
- alpha_squared 3y ago
  Rewriting frequently (reference a) is often out of the hands of the developer because of (reference b) business objectives. Writing code is entirely in the hands of the developer only at the time of writing, not a "henceforth and forever" sort of situation.
  - johnnyanmac 3y ago
    And I suppose a dev who only cares about paying the bills would still resonate with this advice. It's not their problem once the suits take charge of the product and give a thumbs up. Why bother with future dev maintenance? the suits will pay for that bride when it burns down, and having that happen is 100x more easy than trying to explain good code upkeep that delays business for a few weeks.
- eternityforest 3y ago
  Rewriting throws away years of accumulated edge cases handling. Suddenly the thing doesn't work because one particular model of printer needs an undocumented command to enable some feature, or users are inputting bad data because you forgot the checks you accumulated... Seems not ideal for end users, unless you're working with microservices or something with well defined specifications that people are actually paying attention to.
  - Zetice 3y ago
    Depends on the field, but what I work on generally evolves so much over time that by the time I'm ready for a rewrite, the "edge cases" I had to account for when I started are either solved, partially solved, or can be isolated into some tiny part of the codebase that could be ported over from the previous code. Beside, "rewrite" here doesn't mean "new repo, new project, new everything" it means reimplementation, usually based on the lessons learned from the previous implementation, and that does include edge case handling, as well as expanded functionality to "underwrite" or justify the effort spent on the rewrite.
shortrounddev2 3y ago
"maintainable" code is disposable. Modern web stacks are built on the idea that you can delete a file and re-implement its interface with a different service behind it later on. Instead of writing code which will be easy to modify, write a good interface which solves your problems in a way that's easy to reason about, and feel free to write garbage implementations that will get "refactored" (thrown away) every year or so
- boredtofears 3y ago
  You can write good code behind well defined interfaces, too. There's no reason you have to pick one or the other. Bad implementations are still bad.
  - vendiddy 3y ago
    I usually find it faster to define a good interface, hack together and implementation, then rewrite it. A good interface limits the blast radius of my refactor.
- johnnyanmac 3y ago
  >Modern web stacks are built on the idea that you can delete a file and re-implement its interface with a different service behind it later on. and that paradigm is exactly why my domain is the start opposite of front end web development. Code I write may be used by thousands of other engineers over decades. I can't take into account every edge case, but I do try to write with the assumption that one day some archeologists will uncover that code as some Rosetta Stone. Of course, modern demands never let me reach that ideal, but it teaches care and good documentation.

nailer 3y ago

> Focus instead on writing code you can throw away easily, code that you are wholly unattached to and is isolated enough that rewriting it won’t cost absurd hours. > Good code is highly maintainable so that you can continue to meet business objectives in a timely manner without regressions. I think you essentially agree on what people should do, regardless of whether you call this 'good code' or just maintainable code. Write tests. Give things good names. Use comments to explain why you're doing something, not how to program. Don't copy and paste the same implementation x times because that way there's only one place to fix it.

nkjnlknlk 3y ago
> Don't copy and paste the same implementation x times because that way there's only one place to fix it. But also sometimes it makes more sense to copy and paste over trying to fit an abstraction where it shouldn't be. :) I think the purpose of questions like the ones by OP is not to figure out "rules" (which are useful only for beginners) but to figure out where and why rules were broken. Sometimes (often) the answer is time, but that in and of itself is a useful example. Good intermediate (I suppose Sr. in our industry) level code is notoriously difficult to find examples of and mentor toward.
- johnnyanmac 3y ago
  >But also sometimes it makes more sense to copy and paste over trying to fit an abstraction where it shouldn't be. :) depends on goals. diverging modules should be copy-pasted, two modules that rely on the same functionality should be consolidated (not necessarily abstracted, but synchronized somehow). Those are both two common cases, so there's no general advice on which is better. >Good intermediate (I suppose Sr. in our industry) level code is notoriously difficult to find examples of and mentor toward. so much industry code and knowledge is proprietary, so I imagine that is by design. even intermediate code has a bunch of value to a company, even if the company lets go of that engineer to make their earnings report 0.1% higher.
- gwbas1c 3y ago
  > But also sometimes it makes more sense to copy and paste over trying to fit an abstraction where it shouldn't be. :) I find that's a smell of limited languages: Maybe a language has poor error handling semantics, maybe it's not expressive enough to make a parameter generic. It can also be a smell of not understanding the language well enough, too. Maybe there is no need to copy and paste, but the programmer didn't understand the language well enough to make a generic abstraction.
  - nkjnlknlk 3y ago
    I agree. I've had the unfortunate experience of moving from more expressive languages and interesting problems to less expressive languages and boring problems as the size of my TC and company go up. :') But you can only do what your tools allow you to do.

Zetice 3y ago

The problem with this “maintainability” argument is the presumption a) that it will be maintained (note I recommended rewriting frequently) or that b) it’s in conflict with meeting business objectives.

alpha_squared 3y ago
Rewriting frequently (reference a) is often out of the hands of the developer because of (reference b) business objectives. Writing code is entirely in the hands of the developer only at the time of writing, not a "henceforth and forever" sort of situation.
- johnnyanmac 3y ago
  And I suppose a dev who only cares about paying the bills would still resonate with this advice. It's not their problem once the suits take charge of the product and give a thumbs up. Why bother with future dev maintenance? the suits will pay for that bride when it burns down, and having that happen is 100x more easy than trying to explain good code upkeep that delays business for a few weeks.
eternityforest 3y ago
Rewriting throws away years of accumulated edge cases handling. Suddenly the thing doesn't work because one particular model of printer needs an undocumented command to enable some feature, or users are inputting bad data because you forgot the checks you accumulated... Seems not ideal for end users, unless you're working with microservices or something with well defined specifications that people are actually paying attention to.
- Zetice 3y ago
  Depends on the field, but what I work on generally evolves so much over time that by the time I'm ready for a rewrite, the "edge cases" I had to account for when I started are either solved, partially solved, or can be isolated into some tiny part of the codebase that could be ported over from the previous code. Beside, "rewrite" here doesn't mean "new repo, new project, new everything" it means reimplementation, usually based on the lessons learned from the previous implementation, and that does include edge case handling, as well as expanded functionality to "underwrite" or justify the effort spent on the rewrite.

shortrounddev2 3y ago

"maintainable" code is disposable. Modern web stacks are built on the idea that you can delete a file and re-implement its interface with a different service behind it later on. Instead of writing code which will be easy to modify, write a good interface which solves your problems in a way that's easy to reason about, and feel free to write garbage implementations that will get "refactored" (thrown away) every year or so

boredtofears 3y ago
You can write good code behind well defined interfaces, too. There's no reason you have to pick one or the other. Bad implementations are still bad.
- vendiddy 3y ago
  I usually find it faster to define a good interface, hack together and implementation, then rewrite it. A good interface limits the blast radius of my refactor.
johnnyanmac 3y ago
>Modern web stacks are built on the idea that you can delete a file and re-implement its interface with a different service behind it later on. and that paradigm is exactly why my domain is the start opposite of front end web development. Code I write may be used by thousands of other engineers over decades. I can't take into account every edge case, but I do try to write with the assumption that one day some archeologists will uncover that code as some Rosetta Stone. Of course, modern demands never let me reach that ideal, but it teaches care and good documentation.