5 ms·

I can't upvote this enough. It breaks my heart when I see a manager with some engineering background, whose idea of better is to make the code coverage number

by tetek 4y ago

I can't upvote this enough. It breaks my heart when I see a manager with some engineering background, whose idea of better is to make the code coverage number higher.

SamuelAdams 4y ago
Is it weird if I would be *thrilled* to work with a manager like that? People here have great arguments against tests. I agree that they’re not always useful. Aiming for 100% code coverage is a waste of time. But if a manager wants easily measurable metrics to hit and they have the budget and bandwidth for it, why should I complain? Writing tests is easy, predictable work. My rate is my rate and if this is how management dictates I spend my time, I’ll take an easy couple weeks and paychecks any day.
- IgorPartola 4y ago
  > Writing tests is easy, predictable work. But is it useful work? This is the problem: engineers have at some point decided that keeping busy writing tests is better than finding other ways to write correct code. Now that TDD has died down as a religion the current fad became strong typing. I will repeat it again and again, I have yet to see an error caused by me passing an int where an array-type was expected in Python or JavaScript. I have been doing this for a long time. This too shall pass and we will see posts like “Show HN: new lightweight dialect of XYZ without the burden of types”.
  - Veuxdo 4y ago
    Not for nothing, but static type checking isn't some kind of fad. It's been the rule, not the exception, since the 1980s at least.
    - IgorPartola 4y ago
      For some languages it’s a whole lot more important than others. Python and JavaScript are memory-safe so you don’t need to worry about writing a bigger object into a too-small memory allocation. You will discover that you reversed the order for parameters to a function by running your code with much less effort than annotating all your code. This type annotation is entirely useless: def get_user(email: str, create_if_not_exists: bool)
      - pfdietz 4y ago
        Additionally, if you are testing the code anyway for other reasons (like, to check that the logic is correct), you exercise the dynamic type checking for free.
      - blep_ 4y ago
        And then it silently creates a user named True because the non-empty email address you passed as `create_if_not_exists` evaluated as truthy.
  - gregors 4y ago
    I really don't understand how strong typing does anything related to testing behavior. I keep seeing this statement and it makes me believe maybe these devs idea of testing behavior are testing nulls or maybe trying to pass in hashes with missing keys. What a waste of time. If you don't have tests, all that means is you or somebody else is testing it manually.
    - IgorPartola 4y ago
      I equate the two as popular HN religions, not as substitutes for each other. TDD is on its way out as a religion. Strong typing in dynamic languages is gaining popularity.
  - yamtaddle 4y ago
    Static typing is machine-readable and machine-validatable documentation largely of a sort you should be writing anyway. If adding static types is a substantial burden either you're stuck with a really bad language, or you weren't writing enough documentation in the first place. Further, if things like much-improved autocomplete, far better editor-provided errors while editing, and better refactoring aren't saving you time, overall, we must write code very differently. And during handoff of code, static types are really nice and save tons of time.
    - IgorPartola 4y ago
      I am not writing code to make it easier for the computer to do its job. I am writing code so that the computer can make my job easier. Wasting time telling a computer how to show me autocomplete suggestions is better spent on creating APIs that are easier to use and require less of it. Or creating smarter autocomplete algorithms.
      - adwn 4y ago
        > Or creating smarter autocomplete algorithms. Ah, the Sufficiently Smart IDE, companion to the Sufficiently Smart Compiler. Sure, go ahead and wait for the magic autocomplete algorithm that can deduce precise function signatures in a large Python or JavaScript code base. Meanwhile, some of us have work to do, and we'll use the best tools at our disposal for managing non-trivial code written by many people across teams. And those tools include modern static type systems.
      - wadd1e 4y ago
        I think what the person replying was saying was not about static typing being easier for the compiler to understand, but the fact types being documented in some way(whether it be embedded in syntax or via documentation) make code far more readable. Python was my first programming language(cliche, I know) and I didn't understand the whole "static typing is good" thing until I learnt languages like C, C++, C#, and rust. Python also introduced type hints and made them a valid part of syntax for good reason. You'd typically end up writing a docstring with the return type of a function and the types of the parameters anyway, which is what the person replying to you was presumably referring to. It's not about passing in an int instead of an array, but rather but being able to figure out what a function wants without needing a stackoverflow thread or having to search through tons of documentation for something that would be otherwise trivial in statically typed languages where the function declaration tells you quite a bit about a function. Hence it's safe to say that types documented in code in some way are very useful for humans, and if you have issues with statically typed programming languages, there's a chance you were not documenting your code enough already.
  - striking 4y ago
    Refactoring is easier when you have either tests or types, but I think it's easiest when you have types as tests don't always remain compatible during refactorings. In TypeScript I let the types guide me as I change code. Too many times I've looked at a type error, thought "why would this be an issue", ignored it, patched up my test suite, and realized the type checker was right all along; I would have saved time just listening to the types.
  - prewett 4y ago
    I have had a number of times where static typing would have saved me a lot of time in both Python and Javascript. I have a recursive-descent parser for a non-trivial language in Python, so when you pass something incorrect down in the bottom it bubbles up and fails up the stack and a bunch of calls later. But if I'd had static typing, the compiler would have caught it immediately. Similar story for a 3D model generator in Python. I've wasted enough time on stuff like this that then next Python project I do that I think will be over 1000 lines long I'm going to write in some statically-typed language.
- xtracto 4y ago
  I don't think it's weird at all, in general. I actually believe that's the thinking of the majority of programmers. As employed by Tata, HCS, HP, IBM, Oracle, Cognizant and so many other huge corps employing developers. We feel it "funny" because that culture is perpendicular to the Startup culture that abounds in this forum. But number-wise, it's a minority. The great majority of people are not wholly in love with their craft. They just want to do their job to get paid. They dont read about Rust on weekends, and dont program yet-another-X in their spare time. And that Ok. Thats what the majority of the world does.
- sgustard 4y ago
  > if this is how management dictates I spend my time, I’ll take an easy couple weeks and paychecks I would rather my employees (and contractors!) work on what's actually valuable, and not just take blind instruction. The people closest to the code should be most empowered to improve it. Is that not a common management view?
- quickthrower2 4y ago
  I find writing tests is often not easy because test tech debt is usually worse than regular code tech debt! Really with non TDD the tests are doing gymnastics to test that code. Code smell example: GetInternalHitCounter_ForTests()

by tetek 4y ago

I can't upvote this enough. It breaks my heart when I see a manager with some engineering background, whose idea of better is to make the code coverage number higher.

SamuelAdams 4y ago

Is it weird if I would be *thrilled* to work with a manager like that? People here have great arguments against tests. I agree that they’re not always useful. Aiming for 100% code coverage is a waste of time. But if a manager wants easily measurable metrics to hit and they have the budget and bandwidth for it, why should I complain? Writing tests is easy, predictable work. My rate is my rate and if this is how management dictates I spend my time, I’ll take an easy couple weeks and paychecks any day.

IgorPartola 4y ago
> Writing tests is easy, predictable work. But is it useful work? This is the problem: engineers have at some point decided that keeping busy writing tests is better than finding other ways to write correct code. Now that TDD has died down as a religion the current fad became strong typing. I will repeat it again and again, I have yet to see an error caused by me passing an int where an array-type was expected in Python or JavaScript. I have been doing this for a long time. This too shall pass and we will see posts like “Show HN: new lightweight dialect of XYZ without the burden of types”.
- Veuxdo 4y ago
  Not for nothing, but static type checking isn't some kind of fad. It's been the rule, not the exception, since the 1980s at least.
  - IgorPartola 4y ago
    For some languages it’s a whole lot more important than others. Python and JavaScript are memory-safe so you don’t need to worry about writing a bigger object into a too-small memory allocation. You will discover that you reversed the order for parameters to a function by running your code with much less effort than annotating all your code. This type annotation is entirely useless: def get_user(email: str, create_if_not_exists: bool)
    - pfdietz 4y ago
      Additionally, if you are testing the code anyway for other reasons (like, to check that the logic is correct), you exercise the dynamic type checking for free.
    - blep_ 4y ago
      And then it silently creates a user named True because the non-empty email address you passed as `create_if_not_exists` evaluated as truthy.
- gregors 4y ago
  I really don't understand how strong typing does anything related to testing behavior. I keep seeing this statement and it makes me believe maybe these devs idea of testing behavior are testing nulls or maybe trying to pass in hashes with missing keys. What a waste of time. If you don't have tests, all that means is you or somebody else is testing it manually.
  - IgorPartola 4y ago
    I equate the two as popular HN religions, not as substitutes for each other. TDD is on its way out as a religion. Strong typing in dynamic languages is gaining popularity.
- yamtaddle 4y ago
  Static typing is machine-readable and machine-validatable documentation largely of a sort you should be writing anyway. If adding static types is a substantial burden either you're stuck with a really bad language, or you weren't writing enough documentation in the first place. Further, if things like much-improved autocomplete, far better editor-provided errors while editing, and better refactoring aren't saving you time, overall, we must write code very differently. And during handoff of code, static types are really nice and save tons of time.
  - IgorPartola 4y ago
    I am not writing code to make it easier for the computer to do its job. I am writing code so that the computer can make my job easier. Wasting time telling a computer how to show me autocomplete suggestions is better spent on creating APIs that are easier to use and require less of it. Or creating smarter autocomplete algorithms.
    - adwn 4y ago
      > Or creating smarter autocomplete algorithms. Ah, the Sufficiently Smart IDE, companion to the Sufficiently Smart Compiler. Sure, go ahead and wait for the magic autocomplete algorithm that can deduce precise function signatures in a large Python or JavaScript code base. Meanwhile, some of us have work to do, and we'll use the best tools at our disposal for managing non-trivial code written by many people across teams. And those tools include modern static type systems.
    - wadd1e 4y ago
      I think what the person replying was saying was not about static typing being easier for the compiler to understand, but the fact types being documented in some way(whether it be embedded in syntax or via documentation) make code far more readable. Python was my first programming language(cliche, I know) and I didn't understand the whole "static typing is good" thing until I learnt languages like C, C++, C#, and rust. Python also introduced type hints and made them a valid part of syntax for good reason. You'd typically end up writing a docstring with the return type of a function and the types of the parameters anyway, which is what the person replying to you was presumably referring to. It's not about passing in an int instead of an array, but rather but being able to figure out what a function wants without needing a stackoverflow thread or having to search through tons of documentation for something that would be otherwise trivial in statically typed languages where the function declaration tells you quite a bit about a function. Hence it's safe to say that types documented in code in some way are very useful for humans, and if you have issues with statically typed programming languages, there's a chance you were not documenting your code enough already.
- striking 4y ago
  Refactoring is easier when you have either tests or types, but I think it's easiest when you have types as tests don't always remain compatible during refactorings. In TypeScript I let the types guide me as I change code. Too many times I've looked at a type error, thought "why would this be an issue", ignored it, patched up my test suite, and realized the type checker was right all along; I would have saved time just listening to the types.
- prewett 4y ago
  I have had a number of times where static typing would have saved me a lot of time in both Python and Javascript. I have a recursive-descent parser for a non-trivial language in Python, so when you pass something incorrect down in the bottom it bubbles up and fails up the stack and a bunch of calls later. But if I'd had static typing, the compiler would have caught it immediately. Similar story for a 3D model generator in Python. I've wasted enough time on stuff like this that then next Python project I do that I think will be over 1000 lines long I'm going to write in some statically-typed language.
xtracto 4y ago
I don't think it's weird at all, in general. I actually believe that's the thinking of the majority of programmers. As employed by Tata, HCS, HP, IBM, Oracle, Cognizant and so many other huge corps employing developers. We feel it "funny" because that culture is perpendicular to the Startup culture that abounds in this forum. But number-wise, it's a minority. The great majority of people are not wholly in love with their craft. They just want to do their job to get paid. They dont read about Rust on weekends, and dont program yet-another-X in their spare time. And that Ok. Thats what the majority of the world does.
sgustard 4y ago
> if this is how management dictates I spend my time, I’ll take an easy couple weeks and paychecks I would rather my employees (and contractors!) work on what's actually valuable, and not just take blind instruction. The people closest to the code should be most empowered to improve it. Is that not a common management view?
quickthrower2 4y ago
I find writing tests is often not easy because test tech debt is usually worse than regular code tech debt! Really with non TDD the tests are doing gymnastics to test that code. Code smell example: GetInternalHitCounter_ForTests()