Oddly Influenced

Brian Marick 0:04
Welcome to oddly influenced, a podcast about how people have applied ideas from outside software to software. Episode 15, and Mark Seemann on /Blindsight/ and /Thinking, Fast and Slow/.

Brian Marick 0:22
Before I get to the interview proper, just a note on the structure. I deleted a couple of sections that were mostly me rambling on. I'll turn both of them into properly scripted episodes someday. Another topic was some programming language geekery that I'm guessing will have a smaller audience. I've moved that to the very end as an appendix. I haven't tried to paper over the discontinuities and rearrangements, just adding the usual bass riff between sections. I don't think that will be a problem. I hope that won't be a problem. Onward.

Brian Marick 0:58
So today is a first for the podcast, someone other than me will tell us about a book, two books actually, that have influenced him. Mark Seemann is a prolific blogger, Stack Overflow contributor, speaker and book author. His most recent book is /Code That Fits in Your Head/. And from what I've been reading on Twitter, it's been getting reviews that make me, frankly, jealous. Mark? Are there any highlights of you that I've missed?

Mark Seemann 1:28
No, I think that's fine. You know, I've been I've been doing this for a couple of decades now. So you could say lots of things, but you know, whatever floats your boat is fine with me.

Brian Marick 1:39
So what's a bit of your history in the industry?

Mark Seemann 1:46
Your listeners should probably know that I started out being a Microsoft IT person, and got into programming that way. So I've been always associated with the Microsoft world of programming. So that's where a lot of people know me from, but I try to look beyond Microsoft technology and the Microsoft stack. So even though I'm a C# developer, and an F#developer, I have also taught myself Haskell programming, which is, you know, way beyond the normal Microsoft stack.

Mark Seemann 2:21
So, I tried to look beyond. I've read a lot of Patterns books by Kent Beck and Robert C. Martin and Martin Fowler, those those kinds of things as well. So I hope I have an outlook that is a little bit more broad than your usual Microsoft.

Brian Marick 2:36
Okay. The two books that Mark wants to talk about are /Blindsight/, a science fiction novel by Peter Watts, and /Thinking, Fast and Slow/ by psychologist and economist Daniel Kahneman, one of the pioneers of behavioral economics: to the point where he shared the 2002 Nobel Prize in Economics. I've read both of the books, /Blindsight/ more than once, and I can see a connection between them. But I'm excited to see if my guess at the connection is correct.

Brian Marick 3:07
Because BLINDSIGHT is probably already the all time winner, past and future, for "oddly influencing" books that are going to be covered in this podcast, let's start with that. Peter Watts is a hard science fiction writer who used to be a professor of Marine Biology. I've read everything he's written, even the video game novelization, but he's definitely not for everyone. There's a blurb on one of his books from Peter Nichols that reads "whenever I feel my will to live becoming too strong, I read some Peter Watts." Charlie Stross describes BLINDSIGHT as "a first contact with alien story from the point of view of a zombie post-human crewman aboard a starship captained by a vampire" – which is an accurate description, though it makes it seem a little less weird than it actually is.

Brian Marick 4:04
So Mark, would you like to summarize and tell us why it resonated with you?

Brian Marick 4:12
If you're gonna go where I think you will, spoilers are unavoidable. So feel free.

Mark Seemann 4:21
I was definitely wanting to warn the listener about this as well, because it's a wonderful book, but I think you might spoil a little bit of the excitement if you already know what the central reveal is. So if you're listening to this, and you haven't read the book, and you want to, you should stop right now and read the book first.

Mark Seemann 4:43
So the idea with this book, the thing that really got me thinking, set some gears in motion in my brain, is that it's a first contact novel. These are some of the most alien aliens I've ever encountered in a book.

Mark Seemann 4:58
And one of the main points is that it turns out that even though they are intelligent, they're actually not sentient. So the whole point of the book is basically that there's probably a lot of intelligence in the universe, in the galaxy, but all the other intelligences that are out there, are basically not sentient.

Mark Seemann 5:29
That means that when they come into contact with human radio signals, they started to try to decipher what human communication is all about. And it [cost] them a lot of energy and a lot of effort to decipher this idea, this notion of sentience. It is carried along as a virus in the communication stream that they are picking up from the earth, which makes them hostile, because it's not efficient. So they actually want to wipe out... not intelligence as such... and they don't care about humans, but: they don't like that noise in the signal.

Mark Seemann 6:14
So the basic point of the book is that there's this attempt to deal with the sentience of humans. If you can eradicate the sentience, that's fine, we can actually leave the humans alone, but the sentience has to go. So that's basically the idea.

Mark Seemann 6:37
I don't know if you read the book that that way. I just reread it this summer, because I knew I was going to talk to you. And it's wonderful, even for a second read.

Brian Marick 6:47
Yes, so the big reveal is that there's there's no "I", there's no "me" inside the aliens, there's no consciousness. But they build spaceships and so on and so forth.

Brian Marick 7:09
And the idea of what consciousness *is* runs through the book, because all of the characters in the book are in some way, in each in a different way, post-human in a way that reflects on reflects on consciousness. So all of the characters are very interesting.

Brian Marick 7:32
And if you're a fan of the unreliable narrator, the narrator Siri is unreliable. And he explicitly says in the book that everything he tells us about the other characters is dumbed down and interpreted for us.

Brian Marick 7:53
It's an interesting book, and I want to make a note that it is free for download on Peter Watts's website. I'll put a link to that and also to Mark's various stuff in the show notes.

Brian Marick 8:22
So besides the "don't make first contact with a non-sentient nonconscious alien race", what conclusions do you draw that might have to do with software?

Mark Seemann 8:38
Yeah, so that's not obvious I understand. But when I read the book... maybe in 2007. And the general notion that sentience could be thought of as being decoupled from actual intelligence was really something that was a revelation for me at that time.

Mark Seemann 9:11
I must have been around, you know, 30, 35. I had not encountered that idea before. That really just struck me as being absolutely devastating, in a sense, but also very, very intriguing. This idea there's an "I" inside of you, and then this book comes around and says, "Well, maybe maybe intelligent processing might actually happen even if you're not self aware of that processing actually happening. So that just lingered. I thought that was very interesting. That really changed my my view of some mental processes, but I did not really connect that to anything having to do with software at that time.

Mark Seemann 10:05
That's, that's the reason why we now need to go to another book. If we switch over to /Thinking Fast and Slow/, then the connection starts to appear.

Mark Seemann 10:18
/Thinking, Fast and Slow/, as you already introduced, was written by Daniel Kahneman, who's actually an experimental psychologist, he's not really an economist. But he and his collaborator, Amos Tversky, started this thing called behavioral economics. And the book is basically about all [their] research: it's like a popular science, retelling of a lot of the research that he had been doing over the decades about how humans often arrive at irrational decisions.

Mark Seemann 11:02
/Thinking, Fast and Slow/... the reason for that title is that he distinguishes between two mental models or two decision making models that he calls System One and System Two. System One is the fast system, and System Two is the slow system. The Slow Thinking system – or system two – that's the one we are actually aware of. This is where we make deliberate decisions, where we think about things, we mull things over. Maybe we even sleep on it, and we get up the day after and think, "Okay, why should I buy that house?, or should I buy that car?" – whatever it is.

Mark Seemann 11:45
So all the big decisions that we are aware of often engage System Two, and that's our conscious thought processes.

Mark Seemann 11:57
But then there's System One, and System One is a part of the brain that makes decisions all the time, but it's not something that we are actually aware of. It might just be motor functions, like when you're walking down the street talking to a friend, you don't think about where you put your feet. Your body and your brain just does that for you, and you're not really aware of it. So the point that Daniel Kahneman is trying to make in that book is that system actually ends up making a lot of decisions for us.

Mark Seemann 12:38
Often those decisions are not very precise. Because that system runs on a heuristic, where it's more important for us to actually arrive at a decision fast, more than that the decision is actually always correct, you know, and on average, it might lean towards making good decisions, but it makes a lot of mistakes along the way. And then you can sort of exploit that with various different experiments, like Daniel Kahneman did, and then he could show that he could influence people's monetary decisions in various ways that were not rational, by phrasing things in different ways. And his hypothesis is that this system one, thought processes that we're not aware of, they're actually making a lot of the decisions on our behalf, even though we don't actually know why that is happening. So that's when when I started having a light bulb going off in my brain and saying, huh, that's interesting, because if we are making more than just basic motor functions, but actually making decisions [that we assumed] were in the realm of the conscious, rational decision making... it actually turns out that those decisions, even though some of them might be quite complicated, [we were] actually unaware that we are actually making [them]. I was beginning to think, okay, so what actually happens when we're working with code? And what happens when we are reading existing code? What happens when we are writing new code? Maybe maybe some of the things that are going on in our brain are actually going on in [System One], even though we're not aware of it.

Mark Seemann 14:27
So the connection that I thought was interesting was that we think we tend to think about software development and programming as being this very, very intellectual activity that we engage in where we are very much aware that we are doing it. Yes, that is also true. But what if System One is still always looking at the code? It might make a lot of decisions... it might get confused if things are not the way that it wants things to look. And it may also arrive at all sorts of good or bad decisions on our behalf, even though we're not rationally arriving at those decisions – it just does those things. So that's what starting started me on this whole path towards looking into what actually happens in the brain? And how much can we actually trust our the rational paths and the self aware parts of our brains when we're looking at code? And what else is going on?

Brian Marick 15:31
There's a related book that I'll put it in the show notes. It's a bit older. It's by a neuroscientist, I believe. It's called /Why Choose This Book?/ And one of the points that he makes in the book is that just sitting around, your brain consumes 20% of your body's energy. While having 2% of your body's mass. So brains are very expensive. And it's to the brain's advantage to do as little work as possible, which is why it relies so heavily on heuristics and such things.

Brian Marick 16:15
And getting back to Peter watts, the aliens are [called] Scramblers. They have decided that actually all the expense... well, they haven't decided, because they're not sentient... but all the expense of System Two,is not worth the trouble. So they just work with System One.

Mark Seemann 16:39
Yeah, yeah, that's a good summary. There's actually also a passage in Kahneman's book that says System One consumes much fewer calories than System Two does – just to make that explicitly clear. So. So the point of the book is that when the Scramblers, the aliens, when they when they try to engage with human communications, they just expend so much energy because they have to emulate System Two in order to understand what's going on. And that just costs them a lot of energy. And that's basically what they don't like about it, if I wasn't being clear.

Mark Seemann 17:25
So yeah, so that was basically the spark. A sort of two part spark where first the you have the idea, the seed is planted by /Blindsight/. And then Kahneman comes around and starts talking about, "Okay, how much of our brains are actually... where we are not aware of the decision processes that are going on there?" And then I thought that was interesting. And I started to look into that.

Mark Seemann 17:57
So that's basically the story. And you know, I ended up writing a book called /Code That Fits in Your Head/. I thought that was an interesting influence... there's lots of other things as well. There's another book, by the way, by Felienne Hermans called /The Programmer's Brain/. I don't know if you've heard about that one.

Brian Marick 18:20
I think so. Yeah.

Mark Seemann 18:23
She works in the University of Utrecht, I think, and she does a lot of practical experimentation with code reading, and also with kids and trying to get kids do coding with Scratch, and all sorts of things. So she's very interested in those things as well. So she wrote this book called /The Programmer's Brain/ that also talks a lot about how do we actually read code and I, I did not read this book until after I'd written my own. And then I was really apprehensive about reading hers, because she really knows what she's talking about. What if everything she would be saying would be the entire opposite of what I'm saying. But it actually turns out that these things actually go pretty pretty well, hand in hand. So that's... I think I may be onto something. But you know, lots of other people are onto the same idea. So that's validation – at least, it's promising so far.

Brian Marick 19:21
So I'll put a link to that book as well in the show notes. So what are some of the things you say in your book?

Mark Seemann 19:32
Oh, in my own book, I'm trying to give people some heuristics for writing code that is, well, code that fits in your head. The idea is that code should be simple. So one of the things we know [is] there's a big line between the System One [and] our short-term memory. It's not quite the same system, but they seem to be somehow connected in a way. And we know there's this result from 1956, called "the magical number seven plus or minus two" by George Miller. The idea there is basically that our short term memory is very, very limited. [So] then when you encounter code, and you have to understand code that's already written, and now we have to engage with that code, because you need to either understand how it works, maybe you want to change it, maybe you just want to understand why there's a defect in it, you know, whatever it is, you're now engaging with code that maybe you wrote six months ago, maybe your colleague wrote it, but now you have to understand it.

Mark Seemann 20:51
And then what you engage in is a mental process where you're essentially running an emulator in your brain, and you're trying execute [or] interpret the code that you're looking at in your own head. And as you probably know, when code is running, it often depends on state. So now we have to keep state in your head. And your short term memory can keep track of about seven things. So if you have more than seven things going on in a piece of code that you're looking at, it becomes really difficult for your short term memory to keep track of that. So one of the things that I've tried to do with the book – and also it's based on various different coaching I've been doing [in] a lot of teams – is I'm trying to give people some fairly simple, rough mechanisms for quantifying when code starts to become too complicated. So basically, one of the heuristics that I'm trying to give people is to say, "well, just look at how many objects, and particularly objects that might change state, how many of those are actually in scope and being activated at this point [in] this code – and taking all the surrounding stuff into account: if you have global variables, you need to think about those as well. And basically, if you have much more than, say, six or seven going on, you should probably start to refactor the code in a way so that you can split it up.

Mark Seemann 22:23
Once we arrive at an idea like that, from the position where we've now talked about all of these things, it shouldn't really sound very surprising. But my experiences when I've talked to various different professional developers is that telling them that they should start to refactor or start to think about design, when only seven things are in scope - that is a very radical notion, just in terms of size. Because, you most people are used to working with God classes that span hundreds, if not 1000s, of lines of code. And now I'm basically telling them, "yeah, you should probably more look at things that are like 10 or 20 lines of code." That's a big step.

Brian Marick 23:11
Yeah, that's interesting, I know of seven plus or minus two, but I've never thought I should actually keep count of the number of objects or values that I'm working with. That's cool.

Mark Seemann 23:29
Yeah. And again, it's not an exact thing, it's just a rule of thumb that you can give people to guide them toward doing a little better than they tend to do at the moment. So, yeah, that's basically the idea behind that.

Mark Seemann 23:47
But what you said reminded me of something else that I also write about in the book, and that's that very simple life hack of getting away from your chair and doing something else, as a productivity thing. So, I have this routine where either I go for a run or I do some other physical exercise, because that's the only thing I do with my body, you know, because otherwise, I'm just sitting in front of the computer all the time. And [my] experience is basically that all the good ideas that I get are when I'm away from the computer. And it's never when I'm at the computer.

Mark Seemann 24:26
So I think you have to engage with a problem for a certain amount of time, by actually working with it on the computer, but then at that point [where] you're not really making any progress, you have to go and do something else. And then again, we come back to this notion of the brain, still doing a lot of intelligent work, even though you're not aware of it working. So I get lots of good idea when I go for a run. And Rich Hickey has said this in a talk where he talks about hammock-driven development, I think he calls it. And that's basically the same notion.

Brian Marick 25:08
This will be my chance to butcher a foreign name. The French mathematician Poincaré describes exactly the same thing, his style of thinking was to really immerse himself in a problem, and then go away from it. He has an essay, which I will also put in the show notes, in which he talks about [how] he'd been mulling something over for a long time. And then he was stepping onto, I think, a street car or something. And between one step and the other, his brain kind of announced, "Here's the solution." Yeah, there are lots of tricks that we could learn.

Mark Seemann 25:57
Yeah, so it's not a new insight, because Poincaré is at least a couple of 100 years ago, as far as I remember. But I just think it reinforces this idea [that] the brain is actually performing intellectual work, even though you're not aware of it. And that could explain why you arrive at insights, once you are doing something else, like stepping onto a street car, whatever.

Brian Marick 26:27
Yeah, I wonder how it varies by person, because I can speak for myself. My knees are too shot for running. But I don't have insights while walking. I do have insights while riding my bicycle. And I have no idea why one kind of movement works for me and the other doesn't. But maybe people need to try different ones.

Mark Seemann 26:58
Yeah. I think you need to engage in a physical activity that is not too demanding of you, at least intellectually demanding, so you probably don't want to engage in, say, fencing or something like that.

Brian Marick 27:15
Yeah, I fenced once and I don't think...

Mark Seemann 27:18
I haven't, but I could imagine that you have to be very concentrated to do that.

Brian Marick 27:23
Do you mention code smells in your book?

Mark Seemann 27:28
I probably refer to some of them, I suppose. I actually can't remember. But I would be very surprised if I don't.

Brian Marick 27:37
I think the phrase "code smells" was... my understanding is it started as a joke. "Grandma Beck's rule for child rearing? If it smells, change it."

Brian Marick 27:53
But I think the idea of smells is really good. Because smell it seems to me of all the senses is the one that most routes around System Two when you smell something bad. Your reaction is instant. And I think that's what you're trying to get yourself to [when programming]. I had this one amazing experience where I had a bunch of Java code, and we were in a workshop. And I said, "Why don't people help me refactor this code?" And I forget who was there, but it was Ron Jeffries, and JB Rainsberger, and the guy who wrote nUnit and a couple of other people.

Brian Marick 28:49
Just watching how they worked with the code! They'd say, "Well, how about moving this over there?" And then "Look, they kind of look similar now... maybe you can extract..." They were clearly doing System Two things in a System One way – in a way that was reflexive, a way that I couldn't do. I had to think about it. They could just perform.

Mark Seemann 29:25
Yeah. But this comes with exercise. So you just have to keep at it for another 20 years, Brian, then you will be good. No, I'm kidding you.

Brian Marick 29:38
Well, I've gotten better at it since it was probably around 20 years ago.

Brian Marick 29:47
Okay, do you have any recommendations for what people should look into? Books to read? I sort of sprang this on you without warning, so...

Mark Seemann 30:02
Yeah, yeah, so /Blindsight/. And it's really a fantastic book and the sequel /Echopraxia/ is actually pretty good as well. It's not quite as good, but it's still pretty decent.

Mark Seemann 30:15
If you want to do something fun with programming... and I think this is broad... There's a wonderful book called /Mazes for Programmers/. Have you heard about that one?

Brian Marick 30:27
I own it, and started working on it. And then got sidetracked. Yeah, a really fun book.

Mark Seemann 30:34
I just had a ton of fun with it. All the code examples are in Ruby. And I didn't know Ruby before I started the book. But you know, it's object oriented enough, so that you can easily pick it up. And it's really one of those things where it's just, it's delightfully unpractical in the sense that... I read an entire book of how to [write] algorithms for drawing and solving mazes. And I have no idea why I would ever do that. But it was just so much fun. So. So that was a delight. So let's recommend that.

Brian Marick 31:13
I've been thinking of getting back to that. And this encourages me.

Brian Marick 31:18
Well, it's your evening, I guess, getting close to your evening. So have a good evening. And I'll have a good afternoon.

Mark Seemann 31:27
Yeah. Thanks for doing this.

Brian Marick 31:34
What follows is Appendix A: Programming Language Geekery.

Brian Marick 31:40
I had one question. It's kind of a tangent. When you [were] talking about reasoning through code by emulation... you hear Haskell people talking about reasoning algebraically, where you do the equivalent of algebraic simplifications to understand code, as opposed to running it in your head. I know Haskell, but I can't say I ever got to the point where I was doing anything like that. Do people actually do that? Do you?

Mark Seemann 32:19
I sometimes do that. I've been doing Haskell for seven, eight years now. Not full time, but quite quite a bit, actually. And I often find myself, you know, when I'm presented with a function that I haven't seen before, what I typically do is I started just looking at the type signature of it and saying, "okay, it takes this thing as input, and this is the output. So it... sometimes it seems fairly obvious that [there's] basically only one way, those dots can connect in a pure function. In a way that would actually work. It takes some time, it takes quite a bit of experience, but once you get there, you just look at it, and you say, "Yeah, okay, these dots must connect in that way." Because, you know, the arrows are all pointing in that particular direction, if you will.

Mark Seemann 33:17
It doesn't always happen like that. And you know, Haskell can definitely get very, very cryptic as well. So not always. But yes, it definitely happens to me. And it happens to me more often with Haskell than it happens to me with F#, but it happens to me more often with F# than it happens to me with C#. So there's definitely this sort of gradual process. So there's some truth in it. But then you shouldn't believe everything that Haskellers say to you, because a lot of it is also...

Brian Marick 33:49
aspirational.

Mark Seemann 33:51
Let's just leave it at that. Yeah, that sounds good. That's, that's good.

Brian Marick 33:54
That's interesting. It brings to mind something that I heard from Dick Gabriel, who is a Lisp programmer extraordinaire.

Mark Seemann 34:08
It's the guy who wrote /Patterns of Software/?

Brian Marick 34:15
Yes. It happens to be the top book on my pyramid of books in [the podcast] logo, yes. I was a C programmer at that time. And I was used to reading code basically linearly. And he said that's not the way a Lisp hacker reads code. He said you look for the densest part of the code, which is kind of like the most indented part. And then you read that and refer upwards in the code to see the context for [the dense] code. And ever since then, I've been intrigued by the idea of whether different languages have different natural code-reading styles. I've never done anything with that thought. But maybe somebody out there will.

Mark Seemann 35:15
Yes, I don't know too much about that either. But it does sound plausible in the sense that, for example, if you've ever looked at F# code, F# has this funny – actually very nice – feature where you can't refer to something unless it's already defined. That prevents a lot of circular dependencies. But it has this side effect, if you will, that if you want to start with the most most abstract things in F# and you want to get the big picture. You have to start from the end, because the end is the most abstract things. And the beginning is the most concrete things. It's sort of like, it's the other way around.

Mark Seemann 35:59
I think it was Robert C. Martin, who once had this idea that we should write code just like journalists write articles. Where you should start with... you shouldn't bury the lede, you know. You start with the most important things first, and then you get more and more detail so that an editor can always throw away the details if they run out of space. And I think that sounds like a good organizing principle for code. But you can't do that in F#, it just forces you to basically flip those things around. So if you're used to reading a lot of F# code, you know that you have to start from the end and then go the other way around, which at least makes a little bit of a difference there, just as you pointed out,

Brian Marick 36:40
Actually something that I really like about Haskell is where you say, "definition of a function is this string of symbols", then `where`, and subsidiary definitions are below that. So it's the same principle, except they put the densest part at the top. And I think that, given the way we read, that makes sense.

Mark Seemann 37:11
Yeah, in Haskell, you can choose whether you want to do one or the other. It's F# that is a little bit more opinionated on that part. But it reminds me of something else you said earlier on, when you made the jump from keeping track of state, and then you started talking about Haskell, because one of the things I really write like about functional programming, in general, pure functions have this wonderful quality that you don't have to keep track of state.

Mark Seemann 37:41
I talked about before that keeping track of state when you are trying to interpret and understand what code does – that actually taxes your short term memory quite a bit. But with immutable data and pure functions, there's no state that ever changes. It's just input that turns into output. So there's less load on your short term memory, if you will.

Mark Seemann 38:06
And then there's this other wonderful thing. A pure function [has] – you know this terminology – referential transparency. So I know that you know what that is. But just for the sake of the listeners, we should probably say: referential transparency is... basically, what it means that you don't have to actually execute the function if you already have the result. The result is just as good as executing the function, because the only thing that function does is it produces the results. And it's deterministic. So it's always going to produce the same result. And that means, if you are sitting there, and you're trying to get a big picture overview of how various different pure functions are composed, you don't have to understand the details of how each of these smaller functions actually arrive at the conclusions that they arrive at. You can just look at the values that they produce and say, "Oh, I understand that this value is combined with this value, and it's combined with that value." And that gives you the big picture of things. And then you can always worry about the details, if you decide that you need to worry about the details, but you have this very nice decoupling... you don't have to always understand the details in order to be able to understand the big picture. And the other way around. These things are very well isolated from each other.

Mark Seemann 39:24
So that's also one of the reasons why I love functional programming so much: because my brain is not, you know, powerful enough to keep track of a lot of state. FP just makes a lot of that stuff go away.

Brian Marick 39:38
Yeah, it occurs to me that I'm really fond of pipeline style programming, which seems to be more encouraged in say, Elm, and seems to be less popular in Haskell, at least from what I've seen. But the idea that you just have a pipeline: input flows into the first segment of pipeline, output comes out and goes into the next segment of the pipeline. And there are all sorts of nice, cute things you can do with that. But it occurs to me that really the nice thing about this kind of pipeline-oriented programming is the existence of the pipeline is a signal at this point. That input that was occupying a slot in your short term memory can now be thrown away. Because it cannot be relevant to any more of the computation.

Mark Seemann 40:39
That's a good way to put it. Yeah.

Transcribed by https://otter.ai