I am used to seeing ring buffers implemented using an array. They are FIFO if you write to the maximum offset and read from the minimum offset but they are double ended if you have a method to read from the maximum offset and write to the minimum offset.

I was a bit surprised that deque is implemented as a linked list and not, for example, a ring buffer. It would mean that index reads would be constant time (though insert and delete at an index would be linear time), the opposite of using a linked list.

pip is a perfectly usable package manager and is included in most python distributions now. Is it perfect? No, but it is good enough for every team I have been on.

I had a worse experience. My first internship was doing web development in ColdFusion. Why that language? Because when the company was first starting, none of the funders wanted to learn Linux/Apache administration and CF ran on Windows.

Also, the front end development team did not have version control but shared code via a file server.

C does exactly what you tell it, no more. Why waste cycles setting a variable to a zero state when a correct program will set it to whatever initial state it expects? It is not user friendly, but it is performant.

I also like checked exceptions. I like having a compile time check that I thought through error scenarios.

Is it perfect? No, but it should be iterated upon, not discarded.

FYI, catching and rethrowing as an unchecked exception is a pretty bad anti-patern (and a foul code smell).

They forgot the Erlang approach: throw exceptions but never catch them. If you are throwing an exception either your code is wrong or your system is bad. In either case, you should crash violently and let another instance handle the retry.

If you are creating an alternative implementation and leaving the old one in place, you are not fixing a problem, you are just creating a new one (and a third one because you have duplication of logic).

Either refactor the old function so that it transparently calls the new logic or delete the old function and replace all the existing usage with usage of the new one. It does not need to happen as a single commit. You can check in the new function, tell everyone to use it, and clean up usage of the old one. If anyone tries to use the old implementation, call them out in a code review.

If removing or replacing the old implementation is not possible, at least mark it as deprecated so that anyone using it gets a warning.

That should be a disciplinary issue. The engineers in question should be brought forth in front of management to explain why they thought that this particular change should be exempt from testing and why this was not explained, in detail, in the code review.