Pretty much all object oriented languages have some concept of "destruction": objects need to release any resources they acquired at construction. In a lot of cases, we don't need to customize this terribly much, but when we do, it's vitally important to do it correctly.

Nancy's co-worker perhaps didn't understand the "correctly" part. So this was the standard pattern of C++ destructor that they wrote:

James's management had more work than they had staffing for, so they did what any company would do in that situation: expand their staff. No, of course not, I'm kidding. They bundled up a pile of work and shipped it off to the contractor who gave them the lowest bid, provided absolutely no oversight or code-quality standards in the contract, and hoped for the best.

What they got back was a gigantic pile of code that compiled. That is the only positive thing one can say about the code, because it certainly didn't work. Within a few weeks of starting reviewing the gigantic pile of garbage the contractors turned in, the dev team reached the decision that it would be quicker to rewrite from scratch than it was to try and pick apart the trashpile and reshaped the refuse into something approaching their actual requirements.

Mira was trawling through some old Python code. This particular block of code needed to load some data from JSON. The data was an array, and the code needed to know how long the array was.

Python has a handy len function that does this on anything enumerable. If our developer had used len, we'd be looking at different code today.

One of Tim's co-workers needed to handle a simple condition: if a control in their web app was enabled, show it, otherwise hide it.

Now, if you or I were writing that, we might write some awfully verbose code, like:

Iterating across a list is a very simple task. It's a CS-101 type thing, and if anything, it's the one thing I'd expect any developer to be able to do without confusing me too much.

Brendan has a co-worker that wants to change my mind about this.