jml's notebook

Thoughts from Jonathan M. Lange

2018-12-11

Professionalism

Epistemic status: working hypothesis.

My first real job was big on “professionalism”. By this they meant showing up on time, wearing a suit and tie, and never using “use” when “utilise” would do. This soured me on the term.

More recently, I’ve started to value it, particularly in the context of work-life balance.

A friend quoted this to me:

A professional is someone who does their best, even when they don’t feel like it

I’m offline now, so I can’t source the original author or exact phrasing.

I like this idea. To me, it’s much healthier than the sometimes cult-like demands that companies make of their employees: “bring your whole self to work”, “believe in our mission”, “we’re a family”. Instead: show up; work hard; go home; get paid.

Don’t misunderstand me. It’s great to believe in your company’s mission—it makes life much easier for everyone, and can open channels of creativity and energy that wouldn’t be there otherwise. Likewise, if you love and trust your colleagues like family members, then that is a wonderful thing that should be cherished. But these aren’t essential, not even in the long term.

The problems in both approaches become obvious when it comes time to leave employment. Leaving a cult (or a family!) is intrinsically traumatic. It’s hard, and it leaves you broken and needing to recover. It probably only happens when things have become unbearable. Leaving a job should not be like this.

On the other hand, if a true professional sticks to it even when they don’t feel like it, how will they know when it’s time to go? Should they leave only when a better offer comes along? When the business is failing? This framing of the relationship doesn’t provide any answers, but clearly there are times when enough is enough.

There are other things I’d like to explore around the idea of professional duty (especially with respect to security and privacy), but this is enough for now.

2018-12-05

Review: So You Want to be a Wizard

I reached out for this book because I was feeling pretty glum, and wanted the solace of some good YA fiction: adventure, hope, nothing too grim, and home in time for tea.

So You Want to be a Wizard provided all of that (a welcome relief!), but isn’t going to stand out as an all time fave. It’s got a kind of heavy handedness that I think I would have appreciated had I read it when I was ten or eleven, but find a bit plodding now.

For example, Nita’s good with plants and Kit’s good with machines. Nita consciously notices this several times, and wonders if those will be their respective specialties. It’s the sort of thing I thought a lot as a thirteen year old (alas, my specialty in wizardry has yet to reveal itself), but as someone in my mid-thirties, I don’t need to be told, and when I am, I want to take Nita gently aside and tell her that “You’re essentially X, and I am essentially Y” thoughts are just not helpful.

Points awarded for a magical, dearly loved city, even if it’s the wrong city. Also for good, no big deal, character diversity.

Nita’s “If” at the end is a very powerful idea that I wish were executed better. I hope the sequels make more of this, but I’m not going to rush to find out.

I think I’ll dip into Madeleine L’Engle next time I want to read YA. Until then, I’ll continue to heartily recommend Diana Wynne Jones, and keep this one as a backstop.

2018-12-05

Review: By the Pricking of my Thumbs

Content warning: I talk about dementia without really knowing what I’m talking about.

An Agatha Christie novel featuring Tommy & Tuppence. Would not recommend.

There are quite a few fun moments, but overall it feels like a bit of a mess. It doesn’t just rely on coincidences to get the plot started, but also to keep it moving.

It’s not clear that anyone does any actual sleuthing, and when the mystery is resolved, you’re still not sure why it matters

There’s a possible interesting reading that I’m not willing to develop fully, due to lack of expertise, but will sketch out here.

Senility and dementia are themes that run through the book, and “simplicity” and madness act as sorts of foils. It could be that the confusing plot, the overwhelming levels of details and clues (lampshaded in the book), and the seemingly arbitrary gaps in the narrative are meant to impress upon the reader what it’s like to not trust your own thread of consciousness.

When you get to the end, you discover everything has been resolved but not really how or why. Everyone around you looks happy and content though, so maybe it’s best if you just play along with them to preserve some dignity.

I have no personal experience of dementia, but know through others that it can be deeply troubling for both the sufferer and their loved ones. My apologies if the above is insensitive.

2018-12-04

Values

The organizational kind, not the other kind.

I was chatting with someone who worked with me at a previous company that had a lot of great employees. The subject ranged to hiring new people, and the topic of our old corporate values came up.

For reference, these included: reliable; rigorous; precise. The people at that company actually did generally display these virtues, and it would have been very hard to succeed there without them.

Today, I’d say that these are not values I particularly prize, but rather things I find almost necessary. It’s much more difficult for me to work with an unreliable person who communicates in vagaries and regularly leaves gaps in their work or reasoning.

But on the other hand, if I were interviewing a candidate, I’d never say “Wow that person really showed great rigour”.

Another organization I know has “gumption” as a value. That’s something I would prize, as long as it wasn’t confused with beating ones head against a wall.

I wonder if it makes sense to have two sets of values. The first are the necessary ones, without which one cannot succeed. These are likely to be revealed in how people behave already. The second are aspirational, the kind of people we want to be.

2018-12-03

Thoughts on Rich Hickey’s “Maybe Not”

Attention conservation notice: interesting to the degree that you care about my opinion about Rich Hickey’s opinion. You need to watch the talk first.

Written up version of a rant on Slack.

I got nerd-sniped into watching Rich Hickey’s “Maybe Not” talk. It’s about an hour long, but can be easily enjoyed at double speed.

The talk is largely about the shortcomings of optional types, like Haskell’s Maybe, and outlines an alternative approach.

Its structure is more implicit than explicit, so it’s hard to respond in a structured way. What follows is a loosely structured set of reactions to it, from my point of view as a fan of both Haskell and Rich Hickey.

It’s not meant to be a formal rebuttal, and I’m not observing scholarly quoting discipline or references. Lots of my opinions could be due to my own lack of understanding. This is my notebook and I’ll do what I want.

tl;dr: I don’t think he understands how to write Haskell programs, nor much about type theory.

Product types

Hickey says it’s wrong to call Either a sum type, because it’s not commutative or associative. In this, he’s both right and wrong.

He’s right in that Either Int String and Either String Int are different types. But in another sense, he’s completely wrong. The two types are isomorphic.

There are a lot of interesting things one could say about this. For example, elsewhere, Matt Parsons explores the consequences of Either not being associative or commutative in the context of error handling. I’d be really interested to see support for anonymous sum types in Haskell that respected this!

Also, “isomorphic” is always about circumstances—a particular context, a particular point of view—so we could have an interesting conversation about when it’s the right point of view for types, and when it’s not.

Variance

I think he made a very interesting point about covariance & contravariance, although he didn’t use those words. Instead he spoke of restricting return values and expanding allowed arguments.

But there are interesting questions!

If you have f :: a -> Maybe b, and you figure out a way to write f such that it will never return Nothing, what happens next? What should happen next? Is it right that we change the signature and force all the call sites to update? What other ways might there be to adjust the contract without forcing all callers to adapt instantly?

Hickey dismisses having to update all the call sites out of hand, but maybe there’s more to be explored there.

Similarly with changing arguments to be more generous, e.g. g :: a -> b changing to g :: Maybe a -> b.

I hadn’t thought about it before, but there’s a sense in which a is a subtype of Maybe a.

How types communicate

Hickey’s jibe at reverse :: [a] -> [a] is what made me think he doesn’t know much about type theory.

He says it doesn’t communicate anything, and that what you want is a spec that says that the return value is derived from the argument.

But! But! But! Theorems for Free! Published in 1989, it’s a famous, highly readable paper about how this is exactly the case!

Roughly, given type reverse :: [a] -> [a], reverse can only do a narrow range of things: - crash - return a constant [a], regardless of input - return a list with the original elements repeated somehow1 - return a sublist of the input list, possibly reorded, but the new ordering can be based only on positions, not values

That last is exactly what Hickey says that you want a spec to do.

He also says something about how a spec will help you generate tests way better than any type will. I honestly have no idea what he could possibly mean by that.

Records

Say you have:

data Car = Car { make :: String, model :: Maybe String, year :: Maybe Int }

Hickey contrasts this with a Clojure map, which is heterogeneous. He says that in Clojure maps, the keys are also functions, and implies this is much better than what Haskell does.

But in the above example, make is a function, make :: Car -> String. Thus, I’ve got no idea what his point is.

From this same example, he makes much hay over Maybe Int not really telling you anything about what a year is. He’s right! That’s why most Haskellers would do something like this:

newtype Make = Make String
newtype Model = Model String
newtype Year = Year Int

data Car = Car { make :: Make, model :: Maybe Model, year :: Maybe Year }

which starts to look a lot like the examples in spec.

Put another way, he doesn’t explain why formally describing free-floating attributes is better than formally describing values.

Specs & selection

This seems like a pretty cool idea if you’re committed to open systems.

I’m going to be cheeky, then I’m going to be charitable.

It looks like he has complected things. He’s constructed himself a problem of “how do I aggregate data and use it as an aggregate when I only need some of it?” How about… you disaggregate it? (I don’t really like using this style, but I just endured an hour of it!)

The Haskell way of saying “I’ve got a function that needs a make and definitely needs a model but doesn’t need a year is this: “

f :: Make -> Model -> whatever

Being more charitable, maybe he actually has a reason for why this isn’t good. If so, it wasn’t made clear to me in the talk.

nil

The talk opens with Hickey being flippant about Sir Tony’s “billion dollar mistake”. Flippancy is basically not worth responding to.

However, I really would have liked to see him circle back to this opening point. What should we do in the presence of possible nulls? How do specs help?

Unfortunately, to explain what I mean, I have to do the work that he should have done.

Say you have a list of cars as above, and you have to do something with them based on their make & model (e.g. as f above). How do you handle the fact that sometimes they won’t have models?

This isn’t a Haskell problem. If a car is implemented as a map, then sometimes the map won’t have a model.

This is where I struggle, because Haskell’s type notation is really good, and I find it hard not to reach for it. But on the other hand, Hickey hasn’t provided an alternative.

Let me try with Haskell:

g :: [Car] -> [whatever]
g cars = mapMaybe doTheThing cars
  where
    doTheThing car = case model car of
      Nothing -> Nothing
      Just model -> Just (f (make car) model)

That is, if f needs a Make, and you have a value that might not have a Make, you have to do a runtime check to decide whether to call f, and you have to decide what to do when you don’t have a Make.

It would be really interesting if spec let you do something genuinely different.

Meta

Rich Hickey’s excellent talk Hammock-Driven Development introduced me to Polya, which in turn introduced me to things like varying notation as an explicit problem-solving technique, and the importance of writing down problem statements. In that talk, Hickey strongly emphasised reading about an area before haring off and building a solution.

In that light, it was really discouraging to watch “Maybe Not”, a talk that rambles about a half-defined problem, ignores the literature, and swaps formal notation for put-downs and crummy analogies.


  1. The original post omitted this option. Thanks to DRMacIver for pointing out the omission. 

2018-11-28

Review: How to Invent Everything

From Ryan North, writer of The Unbeatable Squirrel Girl and probably a bunch of other stuff comes this book pretty squarely aimed at the “Christmas gifts for your know-it-all friends” market.

The book is framed as a manual for a stranded time traveller: the quickest way to repair your broken time machine is to rebuild civilisation from scratch, here’s how to do it. To that end, it comes with instructions on agriculture, medicine, mathematics, material science, the scientific method, and lots more.

I would definitely want this book if I were stranded in the distant past. It’s well researched, and entertainingly written, and it covers a lot of bases.

The book makes much of the fact that we could have invented lots of things much, much earlier than we did. All you need for a hot air balloon (it claims) is a basket, some fabric (silk works great), and a fire. And yet, it took us until the 19th century.

On the other hand, my personal circumstances made reading this book very frustrating, for two reasons.

The first is that I’d just read How to be a Tudor, in which the author speaks not only from research but from personal experience in actually living out Tudor practices. She frequently points out that things are a lot more complicated, precarious, or just plain difficult than they first appear. Lots that might appear simple is actually an advanced skill.

Second is that in doing management, it’s really easy to observe how a bunch of people who know what they are doing somehow fail to achieve the outcome they set out to achieve, with no obvious single root cause and no one worthy of blame. DRMacIver points out that “decision making in large groups of people as the fundamental problem of civilisation”. I’d go one step further and say coordinating groups of people is the fundamental problem of civilisation.

What this meant is that I ended up flipping through the pages going “I bet it’s not as simple as that” and “Yeah, but who do you get to mind the charcoal fire, and who’s bringing them lunch?” There’s a (very cool) tech tree at the back, but there’s no plan for what to get done in your first ninety days, or how many people you’d need to convince.

At a meta level, it’s even more frustrating that there’s no invention or discovery in the field of management that merits inclusion in the book. Logic rates a whole chapter, because it’s amazingly useful, a prerequisite for computers (which in turn are a prerequisite for video games), and because dropping first order predicate logic in a page or two can save two thousand years of wandering in the wilderness. But, with management, it’s entirely possible that we are just as bad at getting a group of people to work together toward a goal as we have ever been.

If you’re not in the same circumstances as I, and haven’t asked “Yes, but how do we actually execute on that?” in the last six months, then you might well enjoy this book.

2018-11-27

Assumptions belong in types

I’m writing a piece of highly situated software to log in to a crappy website.

This website asks for three random characters of my password, which I don’t know, because I use a password manager. So, for example, when I log in they might ask for characters 3, 5, and 11 of my password.

I don’t know why they picked “three” as the magic number of characters, and I don’t know whether they are going to change it. But because I’m not writing a general library, and because it gets the job done, I’m going to assume 3.

My first cut of this code stored the three requested positions in a list: [3, 5, 11], and then accessed each element of this list as needed: positions !! 0, positions !! 1, positions !! 2. This is fine.

However, because scraping is a bit of a dark art, and because websites can return different things at times, what happened was that the parsing code could merrily return an empty list of positions, and then the code that used these positions would blow up with Prelude.!!: index too large.

A different post would go on about partial functions. This isn’t that post. For this highly situated software, it’s OK if things blow up because of unhandled cases. The problem is it’s blowing up in the wrong place. The bit that actually failed was the parsing, but that failure only manifested itself in the code that was assuming that there were 3 positions.

The solution is to move the assumption from the code to the type. So we change positions :: [Int] to positions :: (Int, Int, Int). This makes it impossible for the parser to construct a wrong value, which forces the failure into the parser.

In some ways this is just a riff on “make illegal states unrepresentable”. The insight for me is that “illegal” carries connotations of “bad”, “wrong”, “immoral”, whereas the advice holds for “against the (arbitrary) rules” or “out of bounds”. It’s “illegal” in the sense that picking up a football and carrying it toward the goal is illegal—it’s just not what we’re doing here. In this case, there’s nothing wrong about the website asking me for 4 characters of my password (or even all of them!), I’m just assuming that they won’t to save myself some time.

In summary:

2018-11-25

Review: Lies Sleeping, Ben Aaronovitch

Spoiler free.

The latest book in the Rivers of London series. I really enjoyed it. I can increasingly see why people compare the series to the Laundry Files or the Dresden Files, but this, honestly, is vastly better written and better crafted.

I read the ebook, but in my head I heard the voices as read by Kobna Holdbrook-Smith, who reads the audio books and is really very good at it.

For me, one of the highlights of the book was an anti-London rant from a major character. It came as a refreshing change of perspective.

I feel like this one lacked some of the humour and warmth of others in the series. There are good reasons for that, but I missed it nevertheless.

2018-11-22

Recent(ish) reading

I used to do a quarterly post on my personal blog listing what I’d read that quarter. That fell by the wayside earlier this year, for reasons that I haven’t looked into.

Here’s some stuff I’ve read since my last post:

Fiction

The Wind’s Twelve Quarters, Ursula K. Le Guin. I bought this just after she died, because I wanted to have a legit copy of The Ones Who Walk Away from Omelas to give to Jolie to read. It’s twelve short stories from various stages of her career, each with a short preface. I hate even attempting to review them, especially since the details have faded. What I remember is her passionate intensity, her heavy (but not heavy-handed) playfulness, and her intimidating intelligence. The stories are universally excellent, but very few are entertaining.

The Flowers of Vashnoi, Lois McMaster Bujold. I love Bujold and will read anything she writes. I didn’t get into this one as much as others. I wonder if she likes Ekaterin?

Uprooted, Naomi Novik. This is charming. Howl’s Moving Castle meets Polish fairytales, or something. I enjoyed it so much I went and bought three volumes of her Temeraire series, which is not quite as good.

The Consuming Fire, John Scalzi. I mostly buy Scalzi’s books to support his blogging habit. This sequel to The Collapsing Empire is fun, light reading that only rarely insults your intelligence.

The Labyrinth Index, Charles Stross. I’ve been reading The Laundry Files for an age, and don’t really know how to stop. This one is probably my favourite of the last three or four.

Temeraire and Throne of Jade, Naomi Novik. Dragons: check. Napoleonic naval fiction: check. Bromance: check. I don’t think I could recommend it strongly if these are not your things.

Non-fiction

Managing Humans, Michael Lopp. I’ve been trying to get better at being a manager, and I thought I’d revisit the book that got me into this in the first place. I found it very hard going. Lopp definitely has good advice, but so much of it is predicated on assumptions that just don’t hold for me. Also, he is way too brash and confident. These days, I’d recommend The Manager’s Path by Camille Fournier instead.

Accelerate, (too many to list here). This is a review of a bunch of research that shows that lean practices in IT correlate (and sometimes cause!) great outcomes for the business as a whole. If you already believe that, you’re not going to get a huge amount out of this book. I think 80% of the people who talk about it haven’t read it (it’s very dry), and that’s actually OK.

The Internet of Garbage, Sarah Jeong. I have a deep and abiding interest in rubbish. Jeong points out that much of the Internet is garbage and we don’t have systems in place for dealing with it. It’s a very good, short analysis of the problems we’re facing now. I only wish it were longer.

2018-11-21

What language to learn?

Thinking about trying to learn a new language.

Here’s the shortlist, with reasons.

Honourable mentions for Brazilian Portuguese (I love the sound of it) and Arabic (super widely spoken within London, very hard to learn).

Reading through this, I guess I’d like to learn a language that will

  1. help me speak to more people in London
  2. be useful in future travels
  3. open up new cultures and new ways of looking at the world

Happy to take input from others.


  1. But not the UK’s 

2018-11-17

Review: How to be a Tudor

Before I read this book, I spent half a week being regaled by anecdotes from it as J read through it. She couldn’t recommend it enough, and it was a quick read, so I thought “why not?”

Also, it dove-tailed nicely with my ambitions for collaboratively building a history for a medievalish setting for a D&D campaign.

One of our players has stipulated that as far as our history is concerned, ordinary lives matter. That is, our history should not be merely “kings and battles”, but also the day-to-day lives of ordinary folk.

What good fortune to get a book on day-to-day life in Tudor England!

The book starts with waking up from bed, proceeds through chores, breakfast, the working day, dinner, leisure, supper, and then to bed. It talks about cheese making and fashion and how to walk and ribald songs and what pubs were like and the difference between ale and beer. It shows the tricks that poor people used to emulate the fashions of the rich (when it was legal for them to do so!). It’s wonderfully rich and informative.

The author has been described as a “method historian”. She doesn’t just take a recipe for cheese making as written, she actually goes and tries it. Early on in the book, she shares her experiences following the Tudor approach to personal hygiene (frequent linen changes, little to no bathing), and the reactions of her fellow cast & crew (they didn’t notice). Almost everything she brings up from sources, she then enriches with notes on her actual experience of what it’s like to try it.

Two big revelations for me.

First is that, in London, there were probably many skilled woman artisans. They are nearly invisible on the historical record due to their not being allowed to form or join guilds, nor to hold property in their name unless they were widows. A not uncommon thing would be for a widow to set up a business, and then later to perhaps marry a man in a related business, then working together. I’ve known intellectually about women’s contributions being diminished in history, but this was a really interesting concrete example.

Second is the sheer number of things women had to do around the house. While your average bloke spent all his time doing back-breaking ploughing, his wife would have been doing a thousand little and not-so-little things to keep the house going. At a guess, both days would have been exhausting, but the woman’s would have been far more stressful.

The book is also peppered with many contemporary quotes, and wry observations from the author. Her delight in the material shines through, and makes the book a joy to read.

Very highly recommended to anyone who enjoys history, wants some light shone on the worlds of medieval fantasy, or who wants a happy, stimulating, but not challenging non-fiction read.

How to be a Tudor: A Dawn-to-Dusk Guide to Everyday Life, Ruth Goodman

2018-11-16

Review: The Feeling of Value

I just finished reading The Feeling of Value by Sharon Hewitt Rawlette.

It was lent to me months ago by Matthias, my boss. It’s a PhD thesis arguing for “moral realism grounded in phenomenal consciousness”. Roughly, that there is an objective (“judgement-independent”) good and evil, and these are found in the experience of pleasantness or unpleasantness. The disgust you feel when eating burnt toast is intrinsically bad.

Rawlette argues for why moral realism is worth pursuing, why pleasure and pain are the sole objective grounds for such, and why this means that we should pursue a hedonistic utilitarian ethic.

This might be damning with faint praise, but for a serious work of philosophy it is very readable. I’m far from a philosopher and was able to follow along once I started to tune into which words and phrases were terms of art. Rawlette often labours the point, making explicit things you should have been able to figure out from the proceeding sentences. This is a very good thing. It is a complicated, subtle topic, and the extra help is an encouragement. It’s like having an expert looking over your shoulder saying “Yep, you got that right”.

Overall, I find her argument very plausible. While I would not call myself a utilitarian, it’s a very interesting hat to try on every now and then—perhaps especially so in business or management contexts.

One thing that came up time & again for me while reading this book is how much management and business practice more or less assumes a utilitarian perspective without considering its grounding. At a very practical level, engineers ask “how will the benefit for doing this outweigh the cost?” and to do this regularly is considered a mark of a mature engineer. Perhaps a better sign of maturity would be to have a well-informed sense of duty that shortcuts the expensive evaluation process altogether.

I think we (engineers) also discount the pain experienced by our end users when they encounter fiddly or slow user interfaces. We justify this to ourselves as a business decision—“trade-offs!”—and don’t consider that it’s also an ethical decision.

The book doesn’t talk about either of these things. Instead, it’s a solid, rigorous work on ethics that’s approachable by someone who’s not a philosopher and hasn’t done much reading on the subject. I’d recommend it to anyone interested in ethics, or who wants to sound clever at dinner parties.

2018-11-16

Making history

My old D&D group from Hobart is re-forming for one week next year. We’ve done this two or three times before, and it’s been a lot of fun.

Before we meet up to play, and before we make our characters, we are collaboratively building the campaign setting by writing its history, using a game called Microscope.

Microscope is a fascinating game where a group of people sit around a table and build a history. You start from a big idea like “the rise and fall of a draconic empire” and then iteratively fill in the middle bits, jumping backwards and forwards through history as it pleases you.

It seems a little bit like improv, in that there’s no chance for collusion or group consideration before making a play, and that you have to take what the other players do as a given.

The rules are very well written, and to my managerial eye read a lot like a well-planned retrospective, or structured discussion.

They are also heavily biased toward synchronous play around a shared table, so we are adapting things to asynchronous, distributed play. We are currently in the very early stages of that.

As it is, I haven’t actually played a game all the way through—though I’d love to. My hunch is that it will generate an interesting, lumpy, surprising history with some holes in it, which is exactly the sort of history I’m used to in our own timeline.

Looking forward to playing this almost as much as I am to playing the campaign itself.

2018-11-15

Cold and flu

A few weeks ago, I got the flu. It sucked. I had one day shivering under my duvet, delirious with fever, and then on seemingly random days the week after that, I’d wake up with absolutely no energy, incapable of doing anything.

Two weeks after that, I got a nasty cold. It sucked. It started with a couple of days of brain fog, then went to the horrible mucusy stage, and is now a lingering cough and headache.

What’s weird to me is how different I felt within myself about my energy levels.

With zero energy flu days, I didn’t mind. “I have no energy. This is just how it is. I am going to sit here, staring.”

With the low energy cold days, I was constantly annoyed at myself. “Just pull yourself together and you’ll be able to at least get these clothes folded. What’s wrong with you?”

My actual capabilities during both illnesses were about the same.

This is actually to test that pushing new posts to GitHub actually publishes them. And also that my Cache-Control headers work.

2018-11-15

New beginnings

I want to create a new space where I can write about stuff that I find interesting, without having to think at all about the intended audience.

I want the barrier to posting to be very low, which means it has to be easy for me to write and publish something at a technical level, and also that the quality expectations are fairly low.

I’ve been inspired by DRMacIver’s notebook, which gets a prodigious amount of postings.

There’s going to be a mix of stuff here, running a spectrum of work stuff and personal stuff. I’ll probably also copy David’s “attention conservation notice” and “epistemic status” tricks, more for my own benefit than yours1.

I expect this will completely replace my old personal blog, Echo and Bounce. I’d like to merge the two, but I just don’t have the time. I still intend to post to my professional blog at jml.io, but the things there will be a bit less raw.


  1. This is a test of footnotes.