Some Suggested Reading
A couple of interesting articles crossed my virtual desk yesterday. Links and some reflection within.
My work this morning, when I get around to it, will be affected by two articles, which I recommend you read and consider:
The first article is “Death of a Craftsman”, by Einar Høst. Einar takes personal exception to the label “craftsman”, for some good reasons, while still valuing some of the valuable notions embedded in the “craftsmanship” idea space.
The second is “Small Functions considered Harmful”, by Cindy Sridharan. Cindy, as the title suggests, talks about when small functions are harmful, and when they are not.
I’ll comment very briefly here about the two topics of “craftsmanship” and small functions. I’m not commenting on the articles at all. They’re both worth reading and considering. I am talking about my thoughts on those topics.
I am a bit saddened because the C term has at least two strikes against it. It has “man” in it, which makes it less inclusive than we’d like it to be, and it has become associated with a very authoritarian, discipline-oriented, you’re evil if you don’t do this, line of thinking that is way off base in my view.
There is a third concern, and I believe Einar is referring to this, which is that to be a truly effective contributing developer, we need a lot more than pure programming skill. We need the ability to work with others, and to look beyond our keyboards and algorithms. This is true and I agree with it.
And … I truly enjoy the pure craft of programming, the shaping of ideas into code that does the thing it’s supposed to do. I have spent a huge fraction of over a half century of my life studying, learning, and practicing the art, craft, engineering discipline, call it what you will, of programming. Me and the computer, mano-a-main(), going at it, making things happen.
While I completely agree that there are higher forms of contributing in software, I also observe that feeding the hungry and ministering to the sick of heart, mind, and body is a higher form of contribution than even the best dev team member you can imagine. We get to choose our profession.
The Wiccan Rede is An it harm none, do as thou wilt. If you want to dedicate your life to the minutiae of cross-compilers for stone henges, I say go for it. It’s your life.
And … if you want to really contribute in software, pay attention to the people like Einar. They’ve got some things you should think about.
I like small functions. On one of the Slack groups I share with him, GeePaw Hill commented yesterday that the “real” topic isn’t length but expression. I think he’s on something. I mean onto something. Pardon me, I misspoke.
A function should express an idea, and it should be as long as it takes to express that idea, and no longer. Also no shorter.
In the olden days, we used to print out our programs on paper. (This was after the even older technique of pressing them into clay with a wedge-shaped stick had dies out.) I recall many times poring over a listing–we called them listings–and circling some bit of code and saying “I see what they’re doing here!”
Whatever blob of code I was then reading, must have been doing two or more other things, the one before, the one after, and who knows how many other circles I might wind up drawing. Today, my practice, when I’m on my game is to “extract method” or “extract function”, to pull out that circled bit and give it a meaningful name. You saw me do that yesterday, with the code that scales the game to fit the screen.
You also saw me do too much of it by my own standards. Yes, it is possible to do too much of this. I agree with Cindy on the principle. It’s quite possible that I don’t agree on the details.
Back when I was programming in Smalltalk, our practice, following the Smalltalk masters who preceded us, was to write very small methods. Our average method length incredibly short, I don’t recall the number, but like three lines or less.
In general, you don’t drill down to look at those methods. At the level you’re looking at, you see something like, in no particular language:
reserveTheRecord do: [ getTheRecordFromStore processTheRecord putTheRecordBack ]
You don’t care how reserve works. You don’t care how they get the record or put it back. You do care about the processing, so you drill only into that. And so on.
The names, when they’re decent and you’re familiar with them, tell you enough so that you are usually right when you think “no need to look into this”.
In Smalltalk, this tends to go on forever, not least because if you want to follow all the way down to how “+” works on your numbers, you can do it. All the code is there, literally all the way down to the calls on the C-language interpreter. (You can’t see in there without looking elsewhere, sorry.)
A Smalltalk programmer isn’t even remotely surprised to look down and down and down and find that the bottom-most method does something trivial like
moneyValue ^ self asMoney
The result of that is that I have a high tolerance for tiny methods, and in fact I like them. I like it when a complicated idea winds down into a lot of trivial bits. That’s how complicated ideas should work. But when you’re new, or when you’re not practiced in “tiny methods”, this code is weird.
Suppose you’re browsing some class, just clicking through its methods to see what it does. Almost everything you click on, just going through in order, almost everything doesn’t do anything of interest. Where’s all the stuff? Everything just returns six or something.
The upshot is, method size, or good expression, isn’t just a fact about the code, it is about the writer and the reader. A team needs to find its own level, as does an individual.
This is, to reflect back to the beginning, a matter of knowing the craft … and working with people, ourselves included.