Bad Software Advice: Three Interesting Links #7

WARNING: This edition contains: Artificial Intelligence Hype, punctuation

Interesting Links

I have been trying to study AI along with four other things, so today’s links are focused on AI:

The Prompt Engineering Playbook for Programmers - coming from Addy, this is something to pay attention to even more closely. It matches my experience using Claude on a recent project.

My AI Skeptic Friends Are All Nuts - a nice shot, chaser with the last link.

Kelly Vaughn, a worthwhile person to follow in general, has started working at Zapier, and posted their AI competency matrix:

Also: Apple’s widely-discussed and infrequently read recent paper: The Illusion of Thinking

Misc

If you are useful, it doesn’t mean you are valued

Unsolicited Book Review

Beautiful Code: Leading Programmers Explain How They Think

I started this book, not kidding, 15+ years ago (published in 2007). I would read a chapter, and then put it down and think about it.

It is a fantastic book, with each chapter written by a different author about a project they thought had some “beauty”:

• Discussion of the NASA dashboard uses for the Mars rover missions (J2EE)

• MapReduce

• NumPy’s C implementation

• JUnit’s design choices

• BioPerl (!), and gene sorting

• Different approaches to writing an XML verifier

• Python’s dictionary implementation in C

• A long discussion about code that was beatiful because it was NOT written

My notes are too extensive to give a good summary, but here are a few:

• Is all cool software in my early career just the result of someone being really good with C? (discussion of NumPy C implementation, Python dictionary, 4+ other chapters)

• NASA on their large J2EE CRM implementation for the Mars rover mission: “In any large application, the key to success is integration, not coding”

• “There is no permanent place in the world for ugly mathematics”

• “As software engineers, we are responsible for our own stress tests. Those that don’t believe this - those have some patrician notion that writing such tests is too coarse for the delicate hands of a Gentleman Engineer - will deliver chronically broken software.”

• “Unfortunately, interactive debuggers as they stand do not support the scientific method. To be sure, debuggers are great tools to poke around and investigate code and its results at will. This is a good thing - but only for skilled programmers who know how to use debuggers systematically. I’d rather see programmers trained in systematic debugging methods than in fancy debugging tools.”