2 ms·

To be clear, I'm not against automation. What we do for a living is write code, so when I say "automation is just more possibly buggy code", I'm not opposed wri

by lapcat 3y ago

To be clear, I'm not against automation. What we do for a living is write code, so when I say "automation is just more possibly buggy code", I'm not opposed writing more code (though I am opposed to overengineering). My point is that I don't place all of my faith in automated tests, and I'm not opposed to rolling up my sleeves, getting my hands dirty, and doing manual labor. Manual labor can be tedious, though, and that's probably why a lot of engineers hate it.

samus 3y ago
The problem starts when people do neither: only superficial test suites, not running a few test cases locally, and only start using the debugger when they need help from other people with neither the time nor patience to just stare at the code and argue about things without actually trying to get answers. For example, by provoking the problem and turning on the freaking debugger. I fear half of my team can't run the application locally. To be honest, there are lots of moving parts in the codebase, but it's not only that.
eru 3y ago
Yes, we mostly agree. Apropos "automation is just more possibly buggy code" is also a good argument for static typing. Good static typing can express (some of) your business logic, so that (some) invalid states are forbidden by the types. The result is that quite a few invariants that need to be checked via tests in eg Python can be expressed in the type system in eg Haskell. The type checker already exists and is implemented as fairly battle hardened code, so this way you reduce the amount of new, possibly buggy code. An example: in Go the convention is that when a function can go wrong, it returns a tuple of two values and exactly one of them is supposed to be the null pointer. But the compiler doesn't help you enforce that convention at all, so you need testing (and perhaps careful reasoning). By contrast, Rust's Result type enlists the compiler to make sure that you return exactly either an error or a business-as-usual value.

by lapcat 3y ago

samus 3y ago

The problem starts when people do neither: only superficial test suites, not running a few test cases locally, and only start using the debugger when they need help from other people with neither the time nor patience to just stare at the code and argue about things without actually trying to get answers. For example, by provoking the problem and turning on the freaking debugger. I fear half of my team can't run the application locally. To be honest, there are lots of moving parts in the codebase, but it's not only that.

eru 3y ago

Yes, we mostly agree. Apropos "automation is just more possibly buggy code" is also a good argument for static typing. Good static typing can express (some of) your business logic, so that (some) invalid states are forbidden by the types. The result is that quite a few invariants that need to be checked via tests in eg Python can be expressed in the type system in eg Haskell. The type checker already exists and is implemented as fairly battle hardened code, so this way you reduce the amount of new, possibly buggy code. An example: in Go the convention is that when a function can go wrong, it returns a tuple of two values and exactly one of them is supposed to be the null pointer. But the compiler doesn't help you enforce that convention at all, so you need testing (and perhaps careful reasoning). By contrast, Rust's Result type enlists the compiler to make sure that you return exactly either an error or a business-as-usual value.