"Don't concatenate long strings," is generally solid advice in most languages. Due to internal representations, strings are frequently immutable and of a fixed length, so a block like this:

    string s = getSomeString();
    s = s + "some suffix";

Martin's company had written a set of command line tools which their internal analysts could then string together via shell scripts to do their work. It was finicky and fragile, but frankly didn't work too badly for most cases.

There was one tool, however, which seemed to be the source of an unfair number of problems. Eventually, Martin sat down with an analyst to see what was going wrong. The program would exit successfully, but wouldn't actually do any of the work it was supposed to. Instead of doing the normal thing and writing errors to STDERR, the tool wrote to a file. Which file, however, was determined by reading some shell variables, but the shell variables used by each of the tools were slightly different, because why would you build a consistent interface for your suite of analytical tools?

Let's say you saw a method called StrToGuid, in a C# codebase. Your first thought might be: "Wait, isn't there a built in parse? Well, I guess maybe they might do some sort of exception handling. But it still doesn't seem right." And then you'd take a look at the method signature and see that it takes both a string, and an integer named counter, and you'd think: "Wait, what?"

Henrik H had a similar experience. His team hired a new developer, someone with 15+ years of experience. This is what they contributed to the codebase:

"There are a few more functions like this in the same file," writes Jenny, about today's submission. This is one which largely does speak for itself.

const gright = () => {
  setIscountright(isCountright + 1);
  if(isCountright === 0) {
    setIsleft(!isLeft);
    setIsfirstdot(!isFirstdot);
    setIssecdot(!isSecdot);
    setInfof('Once activated buttons on the right panel will appear');
    setIssquareleft(!isSquareleft);
    setIsanimBottRightIn(!isAnimBottRightIn);
  }
  if(isCountright === 1) {
    setIssecdot(!isSecdot);
    setIsthirddot(!isThirdtdot);
    setInfof('Tap on them to change content of the projection on the wall');
    setIselmscale(!isElmscale);
    setIssquareleft(!isSquareleft);
    setIsmap(!isMap);
    setIsmapdot(!isMapdot);
    setIsborderwhite(!isBorderwhite);
  }
  if(isCountright === 2) {
    setIsright(!isRight);
    setIsthirddot(!isThirdtdot);
    setIsfourthdot(!isForthdot);
    setInfof('Use the menu bar in top left corner to switch between pages');
    setIssquareleft(isSquareleft);
    setIsanimBottRightIn(!isAnimBottRightIn);
    setIselmscale(!isElmscale);
    setIsmap(!isMap);
    setIsmapdot(!isMapdot);
    setIsborderwhite(!isBorderwhite);
    setIsindicator(!isIndicator);

    setTimeout(():void => {
      setAnimain(false);
      setMainsec(true);
      setIsindicator(false);
      setIsindicator2(true);
    }, 1000);

    setTimeout(():void => {
      setMainsec(false);
      setMainth(true);
      setIsindicator2(false);
      setIsindicator3(true);
      setShowdone(true);
    }, 2200);
  }
}

Austin's team received a bug report. When their C# application tried to load certain settings, it would crash. Now, since this was a pretty severe issue in their production software, impacting a fair number of customers, everyone on the team dove in.

It didn't take Austin long to spot the underlying problem, which isn't quite the WTF.

In the endless quest to get asynchronous operations right, we're constantly changing approaches. From callbacks, to promises, to awaits, to observables. Observables are pretty straight forward: we observe something, like a socket or a HTTP request, and when something happens, we trigger some callbacks. In a lightly pseudocode version, it might look something like:

requestFactory.postFormRequest(url).subscribe(
    resp => myResponseHandler(resp),
    err => myErrorHandler(err),
    () => myRequestCompleteHandler()
)

Lacy's co-worker needed to collect groups of strings into "clusters"- literally arrays of arrays of strings. Of great importance was knowing how many groups were in each cluster.

Making this more complicated, there was an array list of clusters. Obviously, there's a code smell just in this data organization- ArrayList<ArrayList<String[]>> is not a healthy sounding type name. There's probably a better way to express that.