Embedded chip documentation is sometimes very bad, and very confusing. Frequently it's difficult to really understand the ins and outs of a given chip without simply getting experience.

Which is why Mr. Scrith was a bit surprised with this code, which came from someone who definitely should have known better.

Sam worked on an application which needed to parse files out of a directory. There was a ticket to change the search path for those files to search an additional directory. That didn't turn out to be terribly hard, but the existing code raised some serious eyebrows.

def get_info_for_identifier(base_name: str, identifier: str) -> dict:
    ...
    all_ids = os.listdir(base_name)
    ...
    results = {}
    for i in all_ids:
        results.update(parse_identifier(base_name, i))
    ...
    return results[identifier]

Robert H was trawling through the JavaScript front-end for his team's ASP.NET MVC application. The goal was to prepare for a complete rewrite of the front-end, because, well, it had problems and wasn't reliable or maintainable.

As an example, Robert sends this:

Pearl was paying down some technical debt. She was trawling through their NodeJS application with a search for TODO and console.log. She was triaging the TODOs, and replacing the logs with a real logging framework.

The application was old, had many complicated routes for requests to be handled, and buried deep in a file was this code, which was clearly testing code that was never meant to end up in production:

Usually, we don't pick on game code, as it's frequently bad because of the time constraints under which it's developed and because the concerns are more around "making a fun, performant game," and not "writing good reusable code".

But there are some egregious exceptions, like what happened to Patrick. He was handed some C# game code, and told, "Good luck!"