3 ms·

> Ehhhh if the most important thing about your code is that it works, IMHO, that code should be, call it, deep tech code. I think code that is adaptable and ma

> Ehhhh if the most important thing about your code is that it works, IMHO, that code should be, call it, deep tech code. I think code that is adaptable and maintainable but, doesn't work, is universally useless regardless of context. Definitionally, useless. > Challenge accepted! :) Unfortunately I am a HN denizen and therefore disconnected from the world of end users, who are sometimes convinced by my arguments that refactoring and good testing is important, but in some cases aren't, particularly when they have me on an obscene day rate for a 60 day contract where I'm delivering 3 projects on 3 entirely different codebases I've never seen before (one of which it takes me a day and a half to even compile). I have a constant desire to write fast, good, tests, that run in complete isolation and are entirely reflective of how things run in prod. I miss the mark, many times, and I have a feeling even the purists do, since I keep having to refactor their code.

RangerScience 4y ago
> work Fair. Maybe another way to put what I'm trying to say is that "the code works" isn't the most important thing when, in the problem context, "works" is a fuzzy / non-binary state. Example: The code for each of the blue checks "worked", buuuuut. > they have me on an obscene day rate for a 60 day Oh god totes fair. I will fall back on the twin defenses of "users != clients" and "explain != convince to budget for". > refactor Do you find that better tested code is more easily refactored? Kinda where I'm going: I generally wouldn't consider "this needs to be refactored" an inherent mark of missing that mark, as that can also come from changed needs and requirements. But I would expect "hitting the mark" to result in code that's easy to refactor (and that's part of how I define the mark that I, personally, aim for). Edit: to more clearly define my goal posts; better tested != fully tested. IME too many people don't hold their test code to a good standard; so IMO "better tested" also means that the test code itself is also "hitting the mark" (or close to it).
- tomlockwood 4y ago
  > Do you find that better tested code is more easily refactored? 100% - I am 100% for really good, fast, compartmentalizeable testing that tells you exactly what's broken when it breaks. I am 100% for making people very aware that tests should never require another test before to run to make the test work. It's confusing and bad! Good testing makes refactoring painless, and I love that. It's the implication that test order requirements happen because a developer sucks, that I think is incorrect, and fundamentally displays a misunderstanding of what "good" software is! Good software in my view, primarily works. Everything else is secondary to that. Works is really in the eye of the stakeholders, in my view! It is fuzzy! It is possible to convince stakeholders the problem they have with the code is, incorrect, and then the code magically "works" again. It is possible to refactor people's expectations and have them think that code without good testing, doesn't work. I find that to be the exception rather than the rule. These are of course all just my views and others have good points and will disagree.

RangerScience 4y ago

> work Fair. Maybe another way to put what I'm trying to say is that "the code works" isn't the most important thing when, in the problem context, "works" is a fuzzy / non-binary state. Example: The code for each of the blue checks "worked", buuuuut. > they have me on an obscene day rate for a 60 day Oh god totes fair. I will fall back on the twin defenses of "users != clients" and "explain != convince to budget for". > refactor Do you find that better tested code is more easily refactored? Kinda where I'm going: I generally wouldn't consider "this needs to be refactored" an inherent mark of missing that mark, as that can also come from changed needs and requirements. But I would expect "hitting the mark" to result in code that's easy to refactor (and that's part of how I define the mark that I, personally, aim for). Edit: to more clearly define my goal posts; better tested != fully tested. IME too many people don't hold their test code to a good standard; so IMO "better tested" also means that the test code itself is also "hitting the mark" (or close to it).

tomlockwood 4y ago
> Do you find that better tested code is more easily refactored? 100% - I am 100% for really good, fast, compartmentalizeable testing that tells you exactly what's broken when it breaks. I am 100% for making people very aware that tests should never require another test before to run to make the test work. It's confusing and bad! Good testing makes refactoring painless, and I love that. It's the implication that test order requirements happen because a developer sucks, that I think is incorrect, and fundamentally displays a misunderstanding of what "good" software is! Good software in my view, primarily works. Everything else is secondary to that. Works is really in the eye of the stakeholders, in my view! It is fuzzy! It is possible to convince stakeholders the problem they have with the code is, incorrect, and then the code magically "works" again. It is possible to refactor people's expectations and have them think that code without good testing, doesn't work. I find that to be the exception rather than the rule. These are of course all just my views and others have good points and will disagree.