The hottest new programming language is English

The perhaps art of programming

"Sparse is better than dense." -- Tim Peters

I'm a programmer at heart. I care about the craft, a lot. At the age of 43, I'll still get myself into lengthy discussions with juniors about why this particluar line of code is too long, or why our linter's default settings aren't as good as maybe their intuition.

Other programmers are less engaged perhaps in style, though hopefully they still appreciate that readability counts, a lot. These programmers will sometimes abstract away some of the details of coding style via linters that apply changes to the code automatically. This relieves them from having to care about whether to put a space between an assignment operator or not.

I grew up as a programmer without a linter, and honestly being thoughtful of where to apply whitespace and where not is to such a large extend ingrained in my muscle memory that I can't comprehend how these people's brains function who write code for a living, but don't really care about what it looks like. So perhaps my point with a wink is, after all: Maybe these folks are still on their journey to appreciating that readability counts. (And do also consider that you're reading your own code many times while you write it, before you use linting.)

At this point you're thinking: what is this dude on about? Should this really be a blog post about my bitterness around whitespace? It's not.

It's about putting two spaces after a period!

Okay okay, that was also a kind of a joke, though very much related to what I just said.

One thing that was pretty hot about two and a half decades ago, when I started doing software development, was the Unified Modeling Language (UML), and also tooling such as in Rational Rose that would take UML diagrams and generate boilerplate code from it, and vice versa. I never liked this idea either. It went against my desire to craft code carefully, and to my aversion against fancy *klickibunti* tools for writing software, such as integrated development environments (IDEs).

As an aside, luckily I wasn't alone in this space of aversion. The idea that we shouldn't need fancy tools to write code seemed to be at the core of the Python programming language's philosophy at the time, namely that code should be concise and approachable to the point where one only needs a simple text editor with a search function and perhaps grep to be as effective as the next person. I feel that today this idea is sadly lost among the noise and affinity for tooling such as linters and heavy IDEs, which have become the norm for starting Python programmers. (Distracting autocomplete and popups are another favourite topic of mine!)

Prompt engineering reduces your problem to the skill of good writing

"The hottest new programming language is English" -- Andrej Karpathy

Now I did blog about an unfinished experiment lately where I generated (untested) code for parts of a game using generative pre-trained transformers (or LLMs). At work, we continue using machine learning and LLMs in many different applications, such that it feels like a good idea to eat our own dogfood off-work too. In other words, using LLMs for generating code for work or hobby projects, or even using it privately to answer one of my kid's great questions about life things (and letting them do it themselves in a safe way) is a great way of learning by doing the art of what's called prompt engineering.

I don't think many users of LLMs (or SLMs) appreciate yet that, while prompt engineering is perhaps not a very technical skill, it's still very much a learned skill which can't be replaced by copying and pasting snippets, but can be learned best by doing, and making mistakes and trying again. The skill of writing prompts is naturally closely related to the skill of expressing ourselves in language in general, including at work. (A colleague gave me the idea of using "please" to address an LLM, such that the chat conversation with the LLM would be attuned to a friendly tone. Same colleague was also implying that I should say "please" more often myself. :-)

By the way, Nicholas Carlini has a really nice though lengthy article on the topic of how he uses AI that I recommended already a few times.

Evidently, prompt engineering is a very hot topic and techniques and tricks continue to be discussed online since perhaps a year. One thing I can probably add to this existing breadth of information out there, and consider that due to a hype, some of those articles might not always be of high quality, is the following advice for learning prompt engineering:

Don't look too much for example prompts to literally copy and paste from. Take your time to try and develop the skill of expressing yourself clearly, to the machine and to humans. Perhaps start writing a blog too. Perhaps also try to learn to type faster, so you're less tempted to copy and paste. These are all learned skills! And when you succeed in dedicating some time to these, you might even be rewarded by becoming a better human!

Collaborative prompt engineering

"Readability counts." -- Tim Peters

Now one idea for how to try and learn prompt engineering together at work with your colleagues is this: Create a #prompt-engineering channel in your chat server, perhaps you're using Slack, and then when anyone of your colleagues or yourself encounters a new idea of a prompt and tries it, they probably learned a lesson or two, they will write the prompt and the results down into that new channel, and this way share their learning with everyone. It's like sharing a nice essay, and your colleagues can also learn from your own trial and errors, since what you're sharing is at a minimum: this is what worked for me.

Another advice for collaboration is this: Try not to bottleneck the work of prompt engineering and evaluation of said prompts to programmers or AI specialist. Instead, make accessible your prompts to everyone in your team who is curious, perhaps those close to the business problems you're trying to solve. And then you'll also find yourself participating in the (generally important) activity of demystifying AI for your colleagues in general. They will probably appreciate it. They might understand that LLMs can be a more effective partner in their life. And they will find themselves with maybe more nuance and background when it comes to the topic of AI in public.

How I wrote my first non-trivial Python script of 105 lines with an LLM

"Attention Is All You Need." -- Team Transformer

Yesterday I decided to do an experiment. I had a problem at work which I wanted to solve. The problem is a typical programming problem which involves monitoring resource usage of processes on a computer. For those curious, there's some documentation here around what this program that we wrote yesterday does exactly.

So the experiment wasn't writing the program, but it was the idea of generating a non-trivial Python script entirely using an LLM that happened to be Claude 3.5 Sonnet. The rules: I wouldn't be allowed to make any changes to the code after the fact. The code would have to be generated by the LLM functionally correct and without bugs entirely! And: I would use only one prompt, and no chatting after the initial prompt, to keep things reproducible. And so doing that took much of my afternoon, but boy was it worth it! I found myself iterating many times, and this was the process: