The trick with that test is that they’re not looking to see whether you can do it. They know you can’t. They’re looking to see whether you think you can. If you show signs of believing it’s possible, that’s probable cause for a search. If you believe you actually pulled it off, you’re drunk.

Reddit, is that you?

In my experience, this often doesn’t happen. So many developers are either inexperienced or cowboys, and there’s nothing inherently wrong with either. But at places where projects are small and numerous, teams often end up with nothing but a combination of the two.

As one of our office’s engineering “fixers”, I’ve taken over maintenance of several such projects. They usually have shattered remnants of code taken from other projects, open source libraries, internal libraries, stack overflow, and so on. Whole source files copied into the project, modified in ways that introduce impressive new failure cases while failing to add new functionality, and used in ways that completely ignore the features natively implemented in that code while those same features are bodged in as barely-working piles of if statements, balanced on a knife’s edge to avoid triggering the failure modes added by the project’s modifications of the copied code. I’m usually able to purge 20-30k lines of code from such projects in the first month, simultaneously closing multiple outstanding issues the PM had been led to believe were intractable.

That probably sounds like arrogance and/or shitting on everybody else’s work but it’s just reality at many workplaces due to a pace driven by unreasonable expectations from management. I just happen to be the person here that ends up sifting through the wreckage when a project reaches the inevitable osteoporosis phase, because of a natural disposition for reverse engineering. It would be great to escape for this and other reasons, as far as I can tell, most places aren’t that different.

This is correct. Additionally, if x is NaN, then x ≠ x.

cries in verilog