Tales from the jar side: Going Meta
Welcome to Tales from the jar side, the Kousen IT newsletter, for the week of June 2 - 9, 2019. This week I mostly worked on the Kotlin Cookbook and Managing Your Manager books, with some other business-related work on the side. I also finally did another Groovy Podcast. I've also decided, at long last, to start giving titles to the individual newsletters that are more descriptive than just the week involved. The title of this week's newsletter is Going Meta.
I'll start with a burst of free association:
Going Meta sounds like the title of a Terry Pratchett book -- specifically, Going Postal, when the quality was still there but was starting to suffer, no doubt due the author's progressive illness.
Terry Pratchett also wrote (along with Neil Gaiman) the book Good Omens, which is now a six-part series on Amazon Prime.
I binge watched Good Omens (the miniseries), and it had been so long since I read the book that most of it was a surprise. I followed that by re-watching it an episode at a time each night with my wife, without telling her I'd already watched the whole thing. Way too many people can identify with that situation, which is such a phenomenon of this decade that there ought to be a term for it.
I just googled that, and apparently it's known as Netflix cheating and is considered highly dangerous to relationships, which is not a surprise.
As much as I liked Good Omens, the really hot (no pun intended) TV property these days is HBO's Chernobyl. I also binge watched all five parts of that, because once I started watching, I couldn't stop. There was no way my wife was going to watch that. It would upset her way too much.
I remember the actual events around the Chernobyl disaster, at least to the extent they made the popular press, because a few years before the disaster, during my college years I spent three summers working at the good old Peach Bottom Atomic Power Station in Delta, PA.
My performance ranged from mediocre to lousy. I'm not a good blue-collar worker at all, in the sense of working with my hands at a regular 9-to-5 type of job. I got along well with everybody, and I learned a lot, but I had no particular aptitude for the work.
A friend of mine and I had fun talking to the operators in the control room, who were the real experts. We kept trying to come up with scenarios to melt the place down, and they would laugh and explain in detail all the ways they could prevent that from happening. Meltdowns were practically impossible, because the entire system was designed against it. All that was necessary was to shut down the reactors ("scram", which meant injecting all the control rods immediately) and make sure there was enough water in the core to keep it from melting.
They had lots of ways of making sure water got into the core, but everybody's favorite was the button of last resort, informally referred to as the "balls to the wall valve", which basically let river water directly into the core. That was also known as the "fish in the reactor" valve. :) Obviously, it never came to that.
In reading that Wikipedia article, I see that a few years after I left the company was cited by the Nuclear Regulatory Commission for a variety of problems, including operators sleeping on the job. That didn't fit my experience at all -- the operators I knew were incredible professionals. They could get bored, though, if nothing was going on, which is probably why they had time to talk to us.
I have other Peach Bottom stories, but I'll save them for a future newsletter.
Getting back to Chernobyl (the link is to the Wikipedia page), the events there were made much worse by design decisions that never would have passed inspection in the U.S. We had to go through layers of prep just to enter "secondary containment", and the Russian reactors lacked even primary containment. That's a staggering decision that made a crisis all but inevitable.
One thing the show got consistently wrong, however, was their treatment of how radiation actually works. For example:
Radiation is not contagious. There's no way touching a person suffering from radiation poisoning would hurt you, unless it involved some fluid coming from inside that person. Radiation is absorbed and does damage internally. It doesn't "infect" anybody else.
That whole scene about the mother and the baby is ridiculous. There's no way the baby absorbed radiation instead of the mother. It doesn't work that way.
Just touching an irradiated person won't make your hand turn red. See above.
Those three divers who volunteered to empty the water? All of them survived. Two are still alive today.
The miners who dug the tunnel to install the heat exchanger to keep the melted core from hitting the ground water? That's a real tragedy, because all their work turned out not to be necessary. The core never melted through the concrete barrier.
Still, the show was really good, and the events described happened pretty much the way they were depicted. Apparently a really good reference is the book Midnight at Chernobyl, which I'm planning to add to my reading queue at some point.
Okay, that's enough. The subtext of all those bullet points is that I'm very productive when I'm trying to avoid doing what I'm supposed to be doing.
Speaking of which, a few comments about the two book projects:
Kotlin Cookbook
I have about four recipes all half finished, which means I have the code worked out but I'm not happy with the text. One of those recipes involves Nothing, a data type defined in Kotlin that is guaranteed to confuse Java developers. It has two use cases:
It's the "return type" for a function that never returns, i.e., when it throws an exception
It's the type of a variable that isn't typed and is set to null.
Wait, what? I mean if you write:
var x = null
then you haven't told the compiler what type of variable x is, and by setting it to null it can't infer anything. The resulting variable is of type Nothing?, where the question mark indicates that it's nullable.
Believe it or not, that's not the fun part. It turns out that Nothing is also a subtype of every other type, which is another weird statement. What that means is that if you have a function that sometimes returns a value and sometimes throws an exception, then the formal return type is the type that is occasionally returned, because Nothing is a subtype of it.
If that sounds confusing, you understand why I'm struggling with that recipe. I'm planning to give a talk in the future on "Kotlin features guaranteed to confuse Java developers", and Nothing is at the top of the list.
Incidentally, the Kotlin library has a function called, of all things, TODO(), which returns Nothing. How does it do that? Its implementation is to always throw a NotImplementedError, and that means the return type is Nothing. It's pretty useful, actually, but I haven't quite finished that recipe, either.
While playing with that I stumbled across the Random class, which is used for random number generators. It has a fascinating design, in that it's an abstract class that defines a bunch of methods with default implementations, then overrides them inside a companion object. Then they add a handful of extension methods to it as well.
The result is that kotlin.random.Random as four different nextInt() functions to return an integer inside specified bounds, three of which come from the companion object and one of which is an extension function. I can't decide whether this is a good practice to recommend or not.
I guess you could say I'm making progress. I'm hoping to hear soon whether either or both of my proposals for KotlinConf have been accepted, which will provide a real deadline. KotlinConf is the first week of December in Copenhagen, and I'd like to have physical copies of my book at that conference. First I have to get accepted, then I have to basically draw a line and finish the book. The tentative deadline for that would be early August, given the production requirements around the book. We'll see.
Managing Your Manager
Progress has been slower than I'd like, partly because of pressure to get the Kotlin book done, and partly because I've been struggling with my own confidence. I've given the associated talk hundreds of times over the years, to very positive reviews, so I should know that it's valuable, but when I write it all down it's just me, and I can be a pretty harsh critic.
Part of that problem was expressed by a fellow student I knew as an M.I.T. undergrad. She used to say:
"All the math I know is arithmetic."
Though you probably get the point, what she meant was, she could be working on real analysis or partial differential equations or linear algebra, but if she understood it, it was arithmetic. That happens to all of us, I think, in any field requiring learning. The parts you know seem easy, because you already know them. The parts you don't you either dismiss as unimportant or view as impossibly high mountains to climb.
I live with this fear all the time. When I'm writing a technical book, at least I have a guide as to what others feel is important -- the features of the language, or the main use cases for a technology, or an overall specification. With the manager book, it's all being made up out of whole cloth based on my own experiences, and what if I'm wrong?
I'm currently working on a chapter about the Chain of Command and how it ties into the loyalty relationship. Most of the advice in my book consists either of techniques to make your life easier or ways to avoid making your life harder. Violating the chain of command is one of the latter -- there are ways to do it, but it's a lot riskier than most employees realize.
In my view, there are two primary messages you want to communicate to your boss:
I got this.
I got your back.
I'm planning a whole chapter just on those two messages, on both their positive and negative aspects, and both go to the heart of the loyalty relationship.
When I'm talking to an audience, I can see how they're reacting and whether they agree or not with what I'm saying. Even online there are built-in ways to get feedback. But when I'm writing, it's just me, at least until it goes to my editor, and that's an added layer of pressure and uncertainty.
All of that gets into the "meta" problem I used as the title of this week's newsletter. Going meta here is when I talk about how something is written, rather than just writing it. As another friend says, most people prefer to solve the meta problem than the actual problem.
For software developers, that's writing code that generates a system, rather than writing the system itself. For a speaker, it's making part of your talk be about the process of creating a talk, which is almost always a bad idea.
So here I am, writing about writing rather than actually writing. That's a bit harsh, but I am writing a newsletter about writing a book, rather than spend the same time and energy actually writing the book.
Still, going meta has its uses. In this case it's letting me process my fears and uncertainties "out loud" rather than letting them keep me from writing at all, and who knows, some of you may find all this interesting.
Bottom line, though, is that it's probably time to get back to work. :)
Last week:
Writing recipes for Kotlin Cookbook
Editing two chapters (Chain of Command and The Prisoner's Dilemma) for Managing Your Manager
Assorted business proposals and other office-related work
Next week:
More writing on the books
Prepare additional proposals for new online training courses at O'Reilly
Wait patiently (hah!) to hear about my proposals for KotlinConf