Write Like You're Ron Jeffries

I know of Ron Jeffries, because he is one of the founders of Extreme Programming and one of the signatories of the agile manifesto which makes him an important part of software development history.

But that's not what I wanted to write about. I just love to read his writing on doing the actual programming while it is happening! At the moment he seems to be working on a python project:

My peregrinations led me to a problem that interests me: steam locomotive linkages. I’ve decided to play with animating them with Python. My understanding is that the “real” way to solve linkages is with matrices, and that is exactly not my plan. I plan to solve the problem geometrically. Probably lots and lots of triangles.

I’ve started prior to this article, so we’ll pick up in the middle and explore the beginnings as we need to. The essence of my thinking is that the locomotive’s drive wheel will be the origin of the motion, not, as in real locomotives, the drive pistons. I think that given a position of the drive wheel and the crank pins on it, we can calculate where the rest of the linkage has to be.

— Now For Something ...

A little later in the series of posts about this:

Intuitively, it seems that we should be able to refactor to pass the two points to update, while leaving the update alone, to fetch its own copies of the start and finish, as they do now. Then we can adjust each update method one at a time. keeping the airship flying the whole time. And returning the two points can be deferred, since as things stand, we do have methods to return them.

This is an over-simplification, I’m sure, not least because our objects aren’t yet fully consistent in their use of start and finish. We could, of course, continue as we were, saving this change for later, but I am inclined to go ahead with it now.

Let’s look to see how we might use the PyCharm Change Signature and other refactoring operations to make this job safe and easy. When you specify a Change Signature, you can enter default values for parameters, which PyCharm will insert into the calls. I’m not sure quite how to use that capability, so let’s look at some current update calls.

There’s this one in the code that draws my animations:

for component in components:
 	component.update()
 	component.init_draw(canvas)

I’ll do that by hand, right now … no, in fact I won’t. Despite my decision above, I think we need to do a bit of preparation before we proceed with this. Patience, Prudence, patience.

— Improvement Idea

And so forth. I have read many a text like this - albeit from different fields and times - in my time as a student of history of science and technology and have always loved glimpses into the minds of people who are trying to solve a problem.

Texts like this are very different from how you'd write a "how-to": Everything is out in the open. Things that are unclear are not hidden. The meandering pace of solving a problem, of how ideas develop and how people create are not replaced by the slick surface of the perfect how-to in which everything seemed to have worked on the first try, was clear from the beginning. Jeffries' texts on the other hand document the doing in the making, learning in the making. It makes it obvious that that which is presented is very often not how it was derived.^[1]

I personally want to read and write more texts like this. About programming and otherwise.

P.S.: I found a post in which Ron Jeffries himself reflects on these "dev lab notes" in the context of LLM as a pair programmer (which he doesn't like, but that's a different story):

In recent years, by which I mean many recent years, I have not had a pair to work with at all. My pair, such as it is, is the article I write while programming. The writing gives me the chance to see the code from more distance and gives my mind time to come up with alternatives, issues, ideas, similar to what a pair might do. It’s far from perfect, but it’s what I’ve got.

• ← Previous
  DailyDogo 1406 🐶
• Next →
  WhileDo