Many many years ago, when I took my first programming course in high school, our instructor had… opinions. One of those opinions was that you should manually syntax check your code and not rely on compiler errors, because back in her day, you had to punch your program into cards, drop it off in the computer lab, wait for the technician to run your batch, and then pick up the results on the printer. It needed to work the first try or you might be waiting a whole day before you could try again.

One of her other opinions was that your code should contain as many comments as it contained lines of code. Everything needed comments. Everything. Which brings us to this code from Doug.

Frequent contributor Russell F stumbled across this block, which illustrates an impressive ability to make a wide variety of bad choices. It is written in C#, but one has the sense that the developer didn't really understand C#. Or, honestly, programming.

if (row["Appointment_Num"].ToString() == row["Appointment_Num"].ToString())
{
    bool b1 = String.IsNullOrEmpty(results.messages[0].error_text);
    if (b1 == true)
    {
        row["Message_Id"] = ($"{results.messages[0].message_id}");
        row["message_count"] = ($"{results.message_count[0] }");
        row["message_cost"] = ($"{results.messages[0].message_price }");
        row["error_text"] = ($"{results.messages[0].error_text }");
        row["network"] = ($"{results.messages[0].network }");
        row["to"] = ($"{results.messages[0].to }");
        row["status"] = ($"{results.messages[0].status }");
        row["communicationtype_num"] = ($"1");
        row["Sent_Date"] = (String.Format("{0:yyyy-MM-dd hh:mm:ss}", DateTime.Now));
        row["Sent_Message"] = row["Sent_Message"].ToString();
    }

    if (b1 == false)
    {
        row["Message_Id"] = "0000000000000000";
        row["message_count"] = ($"{results.message_count[0] }");
        row["message_cost"] = ($"{results.messages[0].message_price }");
        row["error_text"] = ($"{results.messages[0].error_text }");
        row["network"] = ($"{results.messages[0].network }");
        row["to"] = ($"{results.messages[0].to }");
        row["status"] = ($"{results.messages[0].status }");
        row["communicationtype_num"] = ($"1");
        row["Sent_Date"] = (String.Format("{0:yyyy-MM-dd hh:mm:ss}", DateTime.Now));
        row["Sent_Message"] = row["Sent_Message"].ToString();
    }
}

Like the tides, the popularity of low-code development environments comes in ebbs and flows. With each cycle, the landscape changes, old tools going away and new tools washing up on shore. One one hand, democratizing access to technology is good, on the other, these tools inevitably fail to actually do that. Instead, we get mission critical developed by people who don't understand how to develop, and are thus fragile, and released on platforms that are almost certainly going to be on legacy support in the next cycle.

I don't want to imply that low-code tools are automatically bad, or insult non-developers who want to give developing in a low-code environment a shot, though. Especially when professional developers can't really do any better.

When someone mentioned to Abraham, "Our product has an auto-sync feature that fires every hour," Abraham wasn't surprised. He was new to the team, didn't know the code well, but an auto-sync back to the server sounded reasonable.

The approach, however, left something to be desired.

Using built-in methods is good and normal, but it's certainly boring. When someone, for example, has a list of tags in an array, and calls string.Join(" ", tags), I don't really learn anything about the programmer as a person. There's no relationship or connection, no deeper understanding of them.

Which, let's be honest, is a good thing when it comes to delivering good software. But watching people reinvent built in methods is a fun way to see how their brain works. Fun for me, because I don't work with them, probably less fun for Mike, who inherited this C# code.