3 ms·

I think he's talking specifically about the Java and C++ code that accompanied that Python file. I'm sure he's seen bad Java and C++ :)

• jdm2212 7y ago
  I've seen some disgusting Java and C++, but that company had pretty high engineering standards so the Java and C++ was always good. The Python was _supposed_ to be good, too, but 20+ devs making changes to this one config generator script meant people were constantly making their own (and breaking each other's) assumptions about how the code should behave.
  • proverbialbunny 7y ago
    At that point the first person to write good unit tests gets to specify how that part of the program is going to run. Though, really it sounds like you guys need a design pattern to address everyone's needs that everyone can agree to. People can change unit tests. The benefit of this, is it's a kind of documentation. People can see the tests and know how it _should_ work, or they can not read them and if they create errors, they'll find out the hard way. Unit tests don't make a specification static, but they do reduce chaos.
    • jdm2212 7y ago
      This was a few years ago. The chaos was partly because of a lack of ownership: one team owned inputs, the other owned outputs, and there wasn't a clear spec. The whole pipeline was pretty experimental and people made up new semantics as needed, and were happy to change failing tests (or just added untested codepaths behind boolean flags in existing functions). Compile-time type checking would've enforced a greater degree of rigor about modeling what was happening and made clear all the ways existing code could be affected.