When writing software, we like our code to be clean, simple, and concise. But that loses something, you end up writing just some code, and not The Code. Mads's co-worker wanted to make his code more definite by using this variable naming convention:

public static void addToListInMap(final Map theMap, final String theKey, final Object theValue) {
	List theList = (List) theMap.get(theKey);
	if (theList == null) {
		theList = new ArrayList();
		theMap.put(theKey, theList);
	}
	theList.add(theValue);
}

Betsy writes:

I found this snippet recently in a 20-year-old RPG program.

It feels like ages ago, when document databases like Mongo were all the rage. That isn't to say that they haven't stuck around and don't deliver value, but gone is the faddish "RDBMSes are dead, bro." The "advantage" they offer is that they turn data management problems into serialization problems.

And that's where today's anonymous submission takes us. Our submitter has a long list of bugs around managing lists of usernames. These bugs largely exist because the contract developer who wrote the code didn't write anything, and instead "vibe coded too close to the sun", according to our submitter.

Darren is supporting a Delphi application in the current decade. Which is certainly a situation to be in. He writes:

I keep trying to get out of doing maintenance on legacy Delphi applications, but they keep pulling me back in.

Remy's Law of Requirements Gathering states "No matter what the requirements document says, what your users really wanted was Excel." This has a corrolary: "Any sufficiently advanced Excel file is indistingushable from software."

Given enough time, any Excel file whipped up by any user can transition from "useful" to "mission critical software" before anyone notices. That's why Nemecsek was tasked with taking a pile of Excel spreadsheets and converting them into "real" software, which could be maintained and supported by software engineers.