12 ms·

At my job we treat all warnings as errors and you can't merge your pull requests unless all automatically triggered CI pipelines pass. It requires discipline, b

reaperducer 2y ago
At my job we treat all warnings as errors and you can't merge your pull requests unless all automatically triggered CI pipelines pass. It requires discipline, but once you get it into that state it's a lot easier to keep it there. Sounds like what we used to call "professionalism." That was before "move fast, break things and blame the user" became the norm.
- LeifCarrotson 2y ago
  It very much depends on the nature of your work. If manual input can generate undefined behavior, you depend on a human making a correct decision, or you're dealing with real-world behavior using incomplete sensors to generate a model...sometimes, the only reasonable target is "fail gracefully". You cannot expect to generate right outputs with wrong inputs. It's not wrong to blame the user when economics, not just laziness, say that you need to trust the user to not do something unimagineable. I think this is the kind of situation where a little professionalism would have prevented the issue: Handling uncaught exceptions in your threadpool/treemap combo would have prevented the problem from happening.
- dheera 2y ago
  > That was before "move fast, break things and blame the user" became the norm. When VCs only give you effectively 9 months of runway (3 months of coffees, 9 months of actual getting work done, 3 months more coffees to get the next round, 3 more months because all the VCs backed out because your demo wasn't good enough), move fast and break things is how things are done. If giving startups 5 years of runway was the norm, then yeah, we could all be professional.
- robocat 2y ago
  > professionalism." That was before "move fast, break things I think you're professing a false dichotomy. Is it unprofessional to "move fast, break things"? I'm a slow moving yak shaver partly due to concious intention. I admire some outcomes from engineers that break things like big rockets. I definitely think we learn fast by breaking things: assuming we are scientific enough to design to learn without too much harm/cost.
  - tonyarkles 2y ago
    > I admire some outcomes from engineers that break things like big rockets. I work in unmanned aerospace. It started with 55lb quadcopters and got… significantly bigger from there. I’ve thought a ton about what you’re saying over the last 5-6 years. I have broken things. My coworkers and underlings have broken things. We’ve also spent a bunch of time doing design review, code review, FEA review, big upfront design, and all those expensive slow things. Here’s, for me, the dividing line: did we learn something new and novel? Or did we destroy kilobux worth of hardware to learn something we could have learned from a textbook, or doing a bit of math, or getting a coworker to spend a few hours reviewing our work before flying it? And I 100% agree with your last statement: you can “move fast and break things for science” professionally. But… if something breaks when you weren’t expecting it to, the outcome of the post-mortem really should be surprising new knowledge and not “this made it to prod without review and was a stupid mistake”
  - int_19h 2y ago
    > Is it unprofessional to "move fast, break things"? Most of the time it is. The sorry state of software in general is a testament to that.
- mardifoufs 2y ago
  There's basically no proof that software used to be more "professional". Sure the process was more formal, but I've not seen any proof (and I'm not talking about peer reviewed stuff here, but even just anecdotal examples) of the "end result" of those processes being better, more robust or even less buggy than what we get out of what some may call "move fast and break stuff" development.
berkes 2y ago
The last point is the key. It then creates immense value by avoiding a lot of risk and uncertainty for little effort. Getting from "thousands of warnings" to zero isn't a good ROI in many cases, certainly not on a shortish term. But staying at zero is nearly free. This is even more so with those "fifteen flickering tests" these 23 tests that have been failing and ignored or skipped for years. It's also why I commonly set up a CI, testing systems, linters, continuous deployment before anything else. I'll most often have an entire CI and guidelines and build automation to deploy something that will only say "hello world". Because it's much easier to keep it green, clean and automated than to move there later on
- Calamitous 2y ago
  That's because it moves from being a project to being a process. I've tried to express this at my current job. They want to take time out to write a lot of unit tests, but they're not willing to change the process to allow/expect devs to add unit tests along with each feature they write. I'll be surprised if all the tests are still passing two months after this project, since nobody runs them.
  - temporallobe 2y ago
    That’s why TDD (Test-Driven Development) has become a trend. I personally don’t like TDD’s philosophy of writing tests first, then the code (probably because I prefer to think of a solutions more linearly), but I do absolutely embrace the idea and practice of writing tests along side of the code, and having minimum coverage thresholds. If you build that into your pipeline from the very beginning, you can blame the “process” when there aren’t enough tests.
    - ptmcc 2y ago
      The flip that switched for me to make me practice something TDD-adjacent is to replace most manual verification with writing a test. Once I got in the habit I find it so much faster, more consistent, and then I have lasting tests to check in! I don't typically write tests first so it's not true TDD but it's been a big personal process improvement and quality boost.
dataflow 2y ago
> At my job we treat all warnings as errors Pretty sure what you actually mean is that you treat some warnings as errors, and disable the others. I would find it hard to believe you're building with literally all the compiler warnings enabled all the time.
- connicpu 2y ago
  We do have a couple disabled by default in the config, but it's still a lot of warnings: -Wall,-Wextra,-Werror,-Wno-type-limits,-Wno-attributes,-Wno-deprecated-declarations And of course some are suppressed with a pragma for a short section of specific segments of the code where you can make the argument that it's appropriate during code review, but those pragmas stick out like a sore thumb.
  - dataflow 2y ago
    > We do have a couple disabled by default in the config, but it's still a lot of warnings A lot, yes, but definitely a lot more than 2 that you still don't have enabled. Might be worth looking into them if you haven't already -- you will definitely disable some of them in the process. (And I assume you already have clang-tidy, but if not, look into that too.)
    - connicpu 2y ago
      Yep, plus static analysis in CI. We also run ubasan, tsan, and valgrind on our unit tests.
  - kelnos 2y ago
    -Wall + -Wextra doesn't actually enable all warning, though. There are quite a few others that you still have to enable manually.

reaperducer 2y ago

At my job we treat all warnings as errors and you can't merge your pull requests unless all automatically triggered CI pipelines pass. It requires discipline, but once you get it into that state it's a lot easier to keep it there. Sounds like what we used to call "professionalism." That was before "move fast, break things and blame the user" became the norm.

LeifCarrotson 2y ago
It very much depends on the nature of your work. If manual input can generate undefined behavior, you depend on a human making a correct decision, or you're dealing with real-world behavior using incomplete sensors to generate a model...sometimes, the only reasonable target is "fail gracefully". You cannot expect to generate right outputs with wrong inputs. It's not wrong to blame the user when economics, not just laziness, say that you need to trust the user to not do something unimagineable. I think this is the kind of situation where a little professionalism would have prevented the issue: Handling uncaught exceptions in your threadpool/treemap combo would have prevented the problem from happening.
dheera 2y ago
> That was before "move fast, break things and blame the user" became the norm. When VCs only give you effectively 9 months of runway (3 months of coffees, 9 months of actual getting work done, 3 months more coffees to get the next round, 3 more months because all the VCs backed out because your demo wasn't good enough), move fast and break things is how things are done. If giving startups 5 years of runway was the norm, then yeah, we could all be professional.
robocat 2y ago
> professionalism." That was before "move fast, break things I think you're professing a false dichotomy. Is it unprofessional to "move fast, break things"? I'm a slow moving yak shaver partly due to concious intention. I admire some outcomes from engineers that break things like big rockets. I definitely think we learn fast by breaking things: assuming we are scientific enough to design to learn without too much harm/cost.
- tonyarkles 2y ago
  > I admire some outcomes from engineers that break things like big rockets. I work in unmanned aerospace. It started with 55lb quadcopters and got… significantly bigger from there. I’ve thought a ton about what you’re saying over the last 5-6 years. I have broken things. My coworkers and underlings have broken things. We’ve also spent a bunch of time doing design review, code review, FEA review, big upfront design, and all those expensive slow things. Here’s, for me, the dividing line: did we learn something new and novel? Or did we destroy kilobux worth of hardware to learn something we could have learned from a textbook, or doing a bit of math, or getting a coworker to spend a few hours reviewing our work before flying it? And I 100% agree with your last statement: you can “move fast and break things for science” professionally. But… if something breaks when you weren’t expecting it to, the outcome of the post-mortem really should be surprising new knowledge and not “this made it to prod without review and was a stupid mistake”
- int_19h 2y ago
  > Is it unprofessional to "move fast, break things"? Most of the time it is. The sorry state of software in general is a testament to that.
mardifoufs 2y ago
There's basically no proof that software used to be more "professional". Sure the process was more formal, but I've not seen any proof (and I'm not talking about peer reviewed stuff here, but even just anecdotal examples) of the "end result" of those processes being better, more robust or even less buggy than what we get out of what some may call "move fast and break stuff" development.

berkes 2y ago

The last point is the key. It then creates immense value by avoiding a lot of risk and uncertainty for little effort. Getting from "thousands of warnings" to zero isn't a good ROI in many cases, certainly not on a shortish term. But staying at zero is nearly free. This is even more so with those "fifteen flickering tests" these 23 tests that have been failing and ignored or skipped for years. It's also why I commonly set up a CI, testing systems, linters, continuous deployment before anything else. I'll most often have an entire CI and guidelines and build automation to deploy something that will only say "hello world". Because it's much easier to keep it green, clean and automated than to move there later on

Calamitous 2y ago
That's because it moves from being a project to being a process. I've tried to express this at my current job. They want to take time out to write a lot of unit tests, but they're not willing to change the process to allow/expect devs to add unit tests along with each feature they write. I'll be surprised if all the tests are still passing two months after this project, since nobody runs them.
- temporallobe 2y ago
  That’s why TDD (Test-Driven Development) has become a trend. I personally don’t like TDD’s philosophy of writing tests first, then the code (probably because I prefer to think of a solutions more linearly), but I do absolutely embrace the idea and practice of writing tests along side of the code, and having minimum coverage thresholds. If you build that into your pipeline from the very beginning, you can blame the “process” when there aren’t enough tests.
  - ptmcc 2y ago
    The flip that switched for me to make me practice something TDD-adjacent is to replace most manual verification with writing a test. Once I got in the habit I find it so much faster, more consistent, and then I have lasting tests to check in! I don't typically write tests first so it's not true TDD but it's been a big personal process improvement and quality boost.

dataflow 2y ago

> At my job we treat all warnings as errors Pretty sure what you actually mean is that you treat some warnings as errors, and disable the others. I would find it hard to believe you're building with literally all the compiler warnings enabled all the time.

connicpu 2y ago
We do have a couple disabled by default in the config, but it's still a lot of warnings: -Wall,-Wextra,-Werror,-Wno-type-limits,-Wno-attributes,-Wno-deprecated-declarations And of course some are suppressed with a pragma for a short section of specific segments of the code where you can make the argument that it's appropriate during code review, but those pragmas stick out like a sore thumb.
- dataflow 2y ago
  > We do have a couple disabled by default in the config, but it's still a lot of warnings A lot, yes, but definitely a lot more than 2 that you still don't have enabled. Might be worth looking into them if you haven't already -- you will definitely disable some of them in the process. (And I assume you already have clang-tidy, but if not, look into that too.)
  - connicpu 2y ago
    Yep, plus static analysis in CI. We also run ubasan, tsan, and valgrind on our unit tests.
- kelnos 2y ago
  -Wall + -Wextra doesn't actually enable all warning, though. There are quite a few others that you still have to enable manually.