Having LLMs write out their design and reviewing it seems more efficient. Have LLMs, maybe with a different model, check that the implementation meets the design.

When hiring for a permanent position, I have the expectation that a programmer can learn a new language and environment. An OCaml programmer for a position that is python or C would be looked on very favorably. Far more attention-getting than “full-stack programmer”.

After over 40 years of programming, I continue to reduce the size of functions and find it easier to write and understand when I return to them. Ten lines are now a personal guideline.

However, a linear function with only tiny loops or conditionals can be easily understood when hundreds of lines are long, but not so much with nested conditionals and loops, where there is natural decomposition into functions.

I observed that the same guidelines became rules problems when test coverage became popular. They soon became metrics rather than tools to think about code and tests. People became reluctant to add sanity check code for things that could should never happen because it brought down code coverage.

I know in five seconds if a Circos plot is worth looking at.

I try to use exception chaining to create a message that is useful for the user to actually debug the problem (solution-directed error message).

The classic toy case is either getting back "permission denied" or "can not open foo" but not both. Chaining of error messages gives a straightforward mechanism for this.

Then, the high-level text, along with the caused-by messages, is displayed without a stack trace to hopefully give the user enough information to address an issue.

Chaining can be done with explicitly returned errors as well as exceptions. The hard part is actually thinking about "is this use to the end user"

Why checksum metadata if the SSD is so safe?

    #!/bin/bash
    set -beEu -o pipefail
    cat <(date) <(false)
    echo did not exit non-zero

For unit tests, a developer is going to try something out anyway, so capturing it in a unit test for the future should be just a little extra work. Also, writing a unit test means the developer has minimally used what they are writing.

Higher-level (system) testing, especially with GUIs, can be more work than the value added. It is a cost trade-off, but ultimately, a human adds value not matter how much automated.

AI will help too, but these are also tools. Drop QA and you are trading off costs for quality.

IMHO, not backed up by research.

Sometimes even those of us who love programing want to use software rather than develop it.