Write Like You're Ron Jeffries
I know of Ron Jeffires, 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.
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 thestart
andfinish
, as they do now. Then we can adjust eachupdate
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
andfinish
. 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.
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.
This is still true of course of these kinds of "lab notes" as well: "In Toward a History of Epistemic Things I attempted to show that the experimental order of things is realized in a dynamic process condensed in experimental systems." as Hans-Jörg Rheinberger says in On the Narrative Order of Experimentation on page 86. As programmers, we're similarily involved in a quite dynamic process and the narrative form can only convey so much of its volatility. ↩︎
-
← Previous
DailyDogo 1406 🐶