An interview with Sandy Maguire
  • January 9th, 2019

Sandy Maguire, Author of Thinking with Types: Type-Level Programming in Haskell

48 MIN
In this Episode

Sandy Maguire is the author of the Leanpub book Thinking with Types: Type-Level Programming in Haskell. In this interview, Leanpub co-founder Len Epp talks with Sandy about his background, working at Facebook and Google, retiring at a young age and travelling, Haskell, his book, and at the end, they talk a little bit about his experience as a self-published author.

This interview was recorded on December 18, 2018.

The full audio for the interview is here. You can subscribe to the Frontmatter podcast in iTunes or add the podcast URL directly.

This interview has been edited for conciseness and clarity.


Thinking with Types: Type-Level Programming in Haskell by Sandy Maguire

Len: Hi I'm Len Epp from Leanpub, and in this Leanpub Frontmatter Podcast I'll be interviewing Sandy McGuire.

Based in Ottawa, Sandy is a software engineer who describes himself as being somewhere between an independent researcher and a voluntarily unemployed bum. After a brief but lucrative career working for big companies like Google and Facebook, Sandy decided to leave the corporate world and focus his time on his own work and projects.

Sandy is the author of the Leanpub book Thinking with Types: Type-Level Programming in Haskell. The book is aimed at being the comprehensive manual for type-Level programming, and we'll be talking about that in a little bit.

You can follow Sandy's blog about Haskell at, and you can read more about Sandy himself and his experimental lifestyle project at

In this interview we're going to talk about Sandy's background and career, professional interests, his decision at the age of 27 to stop working for the man, his book, and at the end we'll talk a little bit about his experience being a self-published writer.

So, thank you Sandy for being on the Frontmatter Podcast.

Sandy: I'm happy to be here.

Len: I always like to start these interviews by asking people for their origin story. Yours is pretty interesting. I was wondering if you could talk a little bit about where you grew up and how you found yourself studying software engineering at the University of Waterloo.

Sandy: I'm from Northern Canada originally, about 19 hours north of Vancouver. A little place called Terrace, BC. It's maybe 8,000 people - if you're kind of generous, and the nearest city is about 600 kilometers away.

And so as you can imagine - it's sort of up there and it's pretty, but there's not a lot to do if you're not all that into the outdoors. I never really felt like I fit in - just because - if you like to go on the mountains, it's nice. But if you want to stay in and work on computers and talk to people about maths, there's not a lot to do.

So when I was 19, I decided I should probably get up and go to university. I'd sort of looked for the furthest away place I could be, which turned out to be the University of Waterloo. I went down there to study software engineering, spent five years doing that - and I guess the rest is history, as they say.

Len: You've written quite a bit about your own life on your blog, and I had fun preparing for this interview reading about some of your adventures. You took a year off after high school before going to university. What motivated you to do that?

Sandy: I had a cousin who is sort of my adventurous avatar, I guess - whe was five years older than me, and was sort of the big sister I never had. When she graduated, she went off to Australia for a year and came back and told me a bunch of fantastic stories about that. At the same time I watched the movie Into the Wild, and that really resonated with me as a impressionable teenager - it's about about getting up and running away, and maybe not taking so much stock in society, if that makes sense?

Len: Yes.

Sandy: So I took a year off high school - just to go and do that. I got in my car and I drove north one day. I just wanted to see what the rest of the world was like outside of my little hometown.

Len: I've got a couple of questions about that. I've worked in the semi-north, treeplanting in BC. I made it a couple hours north of Fort St. John. Anyone listening to this can just Google that on Google Maps, to see how remote that is.

But where you grew up was very remote. Did you have good internet and stuff like that up there?

Sandy: Yes. We had infrastructure and schooling and we had internet and and an airport, even. It’s what I'd describe as a town. It's not a village, there are people and stuff - you can get out. But that being said, I'd say most people only really left maybe once a year, and that was to go down to Vancouver for a week. So it was pretty insular.

Len: Did you find online communities where you could find like-minded people?

Sandy: Yes I did. I was really into StarCraft at the time, and I think that's what motivated a lot of my programming at an early age. There was a website called Camelot Systems, where a bunch of people had reverse-engineered most of StarCraft, and had made tools for doing it yourself. I think a lot of my early interest in computers and skills towards that, came from interacting with those kinds of people.

Len: Was a computer always a part of your household? I'm sorry if that's a personal question, but actually I've interviewed people who were born in like 1930, all the way to the 90s, and so, the story of how a computer came into the house is actually kind of a really important thing for a lot of people, in terms of how they got into tech in the first place.

Sandy: Absolutely. My father is a technical guy. He's sort of an engineer without the qualifications, I guess you'd say? And so he grew up around the telephone system and was responsible for keeping all of them running throughout the north. He was always big on technology, and we - I believe we got a Commodore 64, when I was like three or something. It's a little before my knowledge of these things, but there was always one in the basement to play around with.

I guess I had a personal computer starting from about 12, and there was dial-up internet. I remember my first experience with that was, there was a saved password for the dial-up, and I spent a few hours one day just pressing backspace and typing in the last character to figure out what it was - and sort of reverse engineered the password like that.

Len: That's really cool. I had a similar experience with a computer early on when someone had given me the wrong instructions for getting into the program, and I had to reverse-engineer something that I knew was mistaken, but figure out what the principles were behind it. I did - and it was so satisfying; even though it took me a couple hours and I could have resolved it by just asking someone to give me the instructions again, figuring it out was really exciting.

Sandy: Absolutely.

Len: And so you made your way to the University of Waterloo in southern Ontario. For those listening, that's a university that's in Canada. It's sort of renowned for computer science andtech generally. What was that like going from Northern BC - like really Northern BC - to southern Ontario?

Sandy: It was weird. I remember the orientation the very first week of university, they had all the freshmen out on the lawn. I realized there were more freshmen there than my entire hometown. Just like mind-blowing. There was also this kind of strange thing, because growing up in the north there's a lot of - I don't want to say resentment, but it's in the right vein, towards Ontario. Which is sort of square, where the power in the country lies. And so it was weird to get there and get outside my bubble and realize, "Oh, these people are actually pretty fantastic and not at all the monsters I thought they were going to be."

Len: That's really funny. I think every Canadian who grew up west of Ontario - or as I like to say, "Between the Pacific and Windsor" - knows exactly what Sandy's talking about.

Just a very brief digression. The region where Toronto and places like Waterloo is, is actually on the same latitude as the southern half of South Dakota. Toronto itself is on a longitude slightly east of Miami, and this part of the country is referred to by itself as "Central" Canada. If you want to understand why there’s actually two or three NBA teams north of Toronto, but they call themselves, "We the North," it's because they're north of where the Loyalists fled from at the time of the American Revolution. And within Canadian culture, that's still seen as the central part of the country - eventhough you can't get further south than that.

With that brief digression aside - I wanted to ask you a question about that. You had a really interesting degree, it was a five year program that was designed to get you to understand everything about how computers work. I was wondering if you could talk a little bit about that?

Sandy: I'm not entirely sure I understand the question.

Len: I think most people think of a Computer Science degree as something where you take a bunch of classes in this, and you take a bunch of classes in that. But my understanding from what I read on your blog, is that your program was a little bit more structured. It would leave you with the ability, if you were left on an island or whatever, to actually construct a computer yourself; that you would know not just how to program, but you would actually know how the compiler works and you would know how the microchip works, and things like that. Is that correct?

Sandy: I think that's a great way of phrasing it. The program was structured by year. The first year you were talking about the mathematics behind computers and doing the logic, and figuring out how do like analog circuits work. At the same time, doing all the underlying physics of how to push electrons through copper. As we went through the years, we slowly built on top of the last year’s instructions and classes.

We got to the point where the second year you're looking at digital circuits, and how do those things work. And then slowly building a CPU, how does like memory work, from the physics up. I'd say through probably the first three years were essentially just that - bootstrapping the process of, how can we build these wonderful devices that we all take for granted these days?

Len: One of the questions that I often get to ask people on this podcast - because I interview so many people who are in software engineering - is, if you were starting out again now and you had the same intentions for a career that you did when you started your degree - would you do a degree again, or would you have some other way to train yourself?

Sandy: It's a good question. I was largely self-taught before I got to university. I'd been doing programming on my own for about eight years. When I showed up, I thought I was the hottest dude. That's right. But what I realized was that people who had started later and had a more formal education from the get go, they rapidly caught up to me. And so my eight years were enough to get me through the first one or two at university.

By the end, I wasn't working as hard, because I didn't realize I needed to. And the people who were working were significantly better. I think if I were to do it again, I would do a degree. I might not do the same degree. But I think I would. I definitely see the value in things like Hack Reactor or the bootcamps, gecause there is a shortage of software engineers, and it's a fantastic way to break into the industry. But personally I really enjoyed the degree aspect of it.

Len: In your book, How These Things Work, right in the beginning of the preface, you have this great line, that "Computer science has as much to do with computers as it does with snowmen." I was wondering if you could talk a little bit about that?

Sandy: There's this notion of computing, which I think is fundamental to the universe. It pops up everywhere that you have systems with really any amount of power. There's this old saying that any complicated system slowly evolves to be a Lisp), but badly coded and with bugs. This is true not only in computer systems, but also in organizations. And like physics itself, all seem to correspond to this idea that information can flow. By setting up the right system and having information on one side, you can push it through the system and get different information on the other side.

Which is this thing we call "computing." Computers themselves are the device that makes that easier, but that's not to say they're necessarily - like, our first programming languages were invented back in the 20s, decades before we had computers.

Len: Just one more question about education - I found on your blog that you're pretty open about being preoccupied with pre-university math education, and you have strong opinions about that. I was wondering if you could talk a little bit about that?

Sandy: I think math is poorly taught. It was probably about three years into university before I realized - what was this thing that people are trying to teach me? When you're in grade school and even earlier, a lot of it's this focus on numbers. And they're like, why do we like add these things, and what's the answer to these computation problems? It's valuable, I guess, for everyday life. If you're at the supermarket, it's valuable.

And that's the reason that people push these things, is that they're valuable. The thing is like nobody cares. You look at this and people say proudly that they hate maths. That to me is misguided. I think that's due to bad teaching.

Len: It's interesting just, just to butt in.

Sandy: Sure.

Len: There's actually - coincidentally, I recalled this just now. But it wasn't that long ago that there were actually a series of articles in the Toronto Globe and Mail newspaper about specifically the training that high school teachers in Ontario get around math.

Len: There was a survey, and you could you could take it yourself, asking basic questions, solving basic mathematical problems. Let's just say that the pass rates were alarmingly low for people who were in university.

It is a really interesting issue. I mean why is it that it’s okay to brag about being bad at understanding the basic relationships between things in the world?

Sandy: I think a big part of it is that the math that we teach isn't all that valuable. Historically, these were the first things we found. But to me I think we should teach math a lot more like we teach music. Where you dive in - and you're not entirely sure what you're doing, but you get to have fun. So you look at like things like Sudoku, which are mathematics, but not presented as such.

It's keeping your mind to all these constraints, and trying to deduce more information given what you know. It's this problem-solving process. I think that's what a lot of mathematics is, just unfortunately not the stuff that we're taught. So I think maybe the reason that people are proud of this stuff is because they've correctly identified that it's not all that useful. I think we are doing them a disservice by presenting the least useful, or at least the least interesting parts of mathematics to them.

Len: That's a really interesting idea. I'm going to think a little bit more about that. I hadn't quite put it in those terms myself. I always thought that part of the problem was that - there you are you're six years old, and all of a sudden it's like, "Here's your multiplication tables" and, "Here's a red pen, and you're going to get a grade, and you've got 10 minutes to finish." And it's like, “Oh my God, there's so much more going on than just math here.”

Len: I'm not against pressure or anything like that, or marks. But there's a lot more going on in the learning scenario like that when you're getting introduced to a subject, than the subject itself.

Moving on to your really interesting career, what was your first job out of out of university?

Sandy: My first job out of university was working at Google on their security and IM platform team. Essentially it's the idea that like - the ownership model for all the Google resources of who owns what. So our team was building the permissions behind like why you can read your e-mail but other people can't.

Len: And did you move to California to do that?

Sandy: I did,. I moved to San Francisco and spent three hours or so a day on the bus commuting down to Mountain View. My thought was that I'd commute to go to work, but I probably wouldn't commute to go have fun. It's just not the person I am. So I figured I'd have more fun living in the city and spending that time on the bus.

Len: What was the atmosphere like there? Speaking of pressure and environments - I've interviewed people who worked for Google on this podcast before, and I've read the normal things in the news that people have read. But what was your experience like? Were you nervous about performing well or were you like, "This is a breeze?"

I didn't get the imposter syndrome that everyone seems to. I certainly did for the interviews, and there was a lot of interviews - my God. But by the time I got there - Google has this weird hiring process where they make you sign a contract and then like 10 months later they tell you what you'll be working on. You don't really have a lot of say in that. And so between the time I had signed the contract and I had started the job, I was a little less than excited about working at Google.

So I came in with what you might call a negative mindset. Mostly because I had discovered other techniques that Google wasn't particularly excited about. So the imposter syndrome really never happened to me. The reason I left I think is along those lines - I'd never really particularly felt inspired by the people around me.

Len: That's really interesting. For some reason, it recalled to me that the people I've interviewed who've worked at Google for this podcast before - all struck me as being very independent-minded, and what they liked about Google, was that they could focus in on exactly what they wanted to do. And there was no discussion of - I've never actually heard anyone talk about their colleagues positively or negatively, which I now can see was a negative thing, perhaps, in its own way.

Sandy: Don't get me wrong. The people I worked with were all fantastically skilled and brilliant. But I never got the vibe that like - you know, the feeling of inspiration? Where you just say, "I want to know so much about you." And you sit down, you talk about something for like six hours. That really never happened to me there there. And so the people were fantastic, but I think we just didn't really click.

Len: And did you move on from there to Facebook?

Sandy: No I didn't. I did an internship at Facebook.

Len: Oh so I got the order wrong, sorry about that.

Sandy: That's okay. Yes, I did an internship at Facebook while I was in university, and I was working there on the growth team.

Len: And you wrote about accidentally making them a lot of money.

Sandy: Yeah. So my intern project was to make friending go up by 5%. Which is hard, because it's the number of times people press like the "add friend" button, which is not really a thing you can influence by any traditional means. You can't just say, "Everybody needs to make 5% more friends." And so we're - what happens if we play with the advertising revenue that Facebook pays to itself, in order to advertise its own things?

We thought about what would happen if, when the little ad comes up saying, "You might know these people" - at the time, that would come up several times a day with all the same people. And we realized, "Maybe that's not particularly valuable. If they didn't click on it once, they're probably not going to click on it two or three times." And so we did this, and I was running a lot of experiments trying different algorithms for this - and none of them were working.

Some of them were giving us a negative percentage of friend increases, and just nothing was working. I was super stressed, because I really wanted the job, and my internship was almost over. I realized, in one of them we had increased the revenue of the company by like 1%. Which sounds small. I had written it off, except when you realize that Facebook is huge. That's actually quite a huge amount of money.

So I was unsuccessful with my friend angle, but I made them a lot of money and I guess they were happy about that.

Len: And how was it that what you did drove up revenue?

Sandy: I'm not entirely sure, to be honest with you. I guess I'd call it an accident. I think what was happening was that they were just over-bidding a lot of times on things that weren't paying off. And so we tweaked the algorithm to be, I think exponentially dropping off for the same people. And so you multiply three times a day by I guess an hourly multiplication. But you understand what I mean when I do this - showing so few ads that it works out a lot [?] more.

Len: That's really interesting. And so eventually you decided to retire at the age of 27. I was wondering if you could talk a little bit about that journey?

Sandy: Sure. At the time I was working in the financial tech market with some of the most brilliant people I knew. But finance tech was never all that exciting to me. And so after a few years, I was just sick and tired of being in the Bay. I realized I was working to make money that I didn't really need, to get experience. I was hating my time there. And so I realized like, "What's the point?" The only thing keeping me there was the fear of the unknown.

So I decided, "It's time to take matters into my own hands," and I quit my job and I subsequently got deported from the US, because I was there on a work visa. I found myself just like - what are you going to do, right? So I decided to keep my runway long. I was going to move to Eastern Europe, which is the place I'd always promised myself I'd go when I retired. I was expecting it to be much longer down the road, but that's how it happened. So I ended up in Lithuania just doing my own thing, without really any plans, without any income, without really any friends there. Just into the wild, I guess?

Len: And you were in Vilnius, I believe?

Sandy: Yes.

Len: I've actually got a specific question. Did you ever pop over into Belarus?

Sandy: I was there not intentionally. I was there for a layover, when I realized my flight had gone missing and I didn't have a visa - and I was stuck in Belarus.

What was it like living in Vilnius, not knowing anybody to begin with? How did you make friends?

Sandy: I made friends with the tourism girls. They did daily walks and they'd tell you about the city. After a few of those that I went on - I was meeting people there, and ended up meeting the tour guides, who are all fantastic people and all spoke English much better than everyone else. Which was great, because I don't speak Lithuanian. They slowly introduced me to the town. But I found it was socially quite difficult to meet people outside of that. Part of it was the language barrier, and part of it was a culture barrier - which I was not expecting.

Len: And were you taking some time to think about the next project to work on, or were you working on projects at all?

Sandy: I've got this bad streak of just starting a million projects, and never really finishing any of them. And so that was what I was doing. I probably had like 14 projects on the go, because I had nothing else to spend time on. I had no job and I didn't have a huge social circle, and I was in a weird country. And so it was just like, "I'm going to build things." The goal was not really to build anything in particular. It was just keep myself busy, and keep learning things. That's what accidentally turned into this book.

Len: I've got some questions to ask you about that in just a minute. But I'm also curious about how you ended up in Ottawa.

Sandy: So part of the charm of the University of Waterloo is they have these internships which happen every four months. You spend four months at school, and then four months working somewhere. It's great in terms of work experience, but it's not so good in terms of staying in one place. By the time I'd gotten to Lithuania, I realized, I had moved something like 19 times in the last eight years.

I realized I wasn't particularly happy in Vilnius after about six months. I wasn't really settling in. My visa was for two years, and I realized by the time two years rolled around, probably I'd just be getting comfortable with the place - and that didn't seem like a very good investment. So I thought. "I'm going to move, I'm going to leave - and I need to go somewhere." But there was nowhere in particular to go. All of my friends have gone across the world, and there's not a particularly big group of them anywhere. My parents had left their hometown - and even if they hadn't, I probably wouldn't go back. And so I was left with this open field of where to live.

The only thing I really wanted was a place I could stay. And so that meant not having to deal with visas, which restricts me to Canada. And then Ottawa just happened accidentally, honestly. I had a friend who was visiting and she said, "We should meet here." And so we did. Then she left and I didn't. And I figured, "This is as good a place as any to be." And so I just stuck around.

Len: I've got one last question on that topic. I've moved around a fair amount in my life. I had a somewhat similar experience where I was working in investment banking in London and making a fair amount of money doing a high-level job, and just realized I didn't love it. Although aspects of it were very exciting, I didn't love it and it was stupid to work 120 hours a week on something I didn't love doing. So I just left and moved to Montreal and drank beer and wrote a novel for it for a year.

Sandy: Right.

Len: I mean I did a lot of other things too, but none professional. And one thing, it took me a lot longer than it should have to realize - was not that moving from one place to another is exciting to me, but that leaving places behind is easy for me. It was just so natural to me to be able to just pick up sticks and move - that I never realized, not everybody feels that way. In fact a friend of mine once told me that he saw a survey that said the hardest thing that people will say that they ever faced in their lives, was moving. Even worse than divorce and things like that. Is that something that you identify with? Is it easy for you to leave places?

Sandy: That strongly resonates with me. Yes, it is easy for me to leave. That comes with its own problems, where I would realize like - I'd be in maybe a relationship I wasn't particularly happy with. And instead of oing through the issue of like dealing with it, I'd just say, "Oh well, I'm leaving anyway, I can stick it out for a few weeks." And that wasn't particularly healthy.

I guess that's been my mantra for the last couple of years. There was never really a sense of permanence anywhere. And sao I would be afraid to put down roots. I'm not sure if it was easy to leave because I wasn't putting down roots, or the causality with the other direction. But yes, that strongly resonates.

Len: Thanks for sharing that. Not everybody's like that, and it's questionable whether it's a superpower or not.

Sandy: I think it just is, right?

Len: Well actually to be honest - there you go.

Moving on to the subject of your book.

Imagine you were speaking to someone who doesn't know anything about computers, how would you explain to them what Haskell is?

Sandy: I think there's this common perception of programming as being like a recipe. Where you say, "You’re going to throw some things in a bowl and stir it." I don't know? I'm not much of a baker. The idea is more like how do you do something, maybe with less focus on what are you trying to accomplish. That's the way that that programming exists, in the vast majority, throughout history, and throughout the industry today.

Haskell is a member of these languages called "Functional Programming," which take the approach of, "What are you trying to do?" Rather than, "How should you do it?"

The idea being - if you can specify quite clearly what are you trying to do, then we can just let the computer deal with the how. And this turns out to be a fantastic way, I think of thinking about programming. Because all of a sudden you feel a little less like a code monkey, and more like you're actually dealing with ideas all of a sudden.

Len: That's really interesting. I guess that leads naturally into my next question, which is, what's Type-Level programming?

Sandy: If you're familiar with programming, you've probably heard of types, which are the reference class of what you're working with. And so you might have a type which is number, and then you have values which are 1 - which is a number.

I feel like a lot of people today are of the opinion that types just get in the way. They say, "I don't want to deal with these things, so I'll just say, 'There will be no types anywhere'".

And this works. The world runs, and most of it is based on these ideas. But it turns out that types are a good way of checking to make sure you know what you're talking about, and making sure the thing you're trying to do makes sense.

So, in the cooking analogy, like - maybe you don't want to throw an orange into the oven, or something just by itself.

Len: I'm probably going to ask this the wrong way, but hopefully I can get my point across. As I was researching for this interview, there seems to be something - something particularly about vulnerabilities that seems to be at stake in type-level programming. If I understand correctly, it's partly like - if you don't have an understanding of what is being accomplished and you're, as you say, being a code monkey, just like going to Stack Overflow and figuring out what to paste in here to do this thing - if you don't have an awareness of actually what's going on, what's being achieved, what categories of action are being undertaken here - then you can leave yourself vulnerable to security leaks and things like that.

Sandy: Yes, this is certainly true. I think this is the value of type-level programming. Which I guess, just to clarify, is designing your types in a way that a computer can validate and make sure that what you're doing is sane, to a much stronger degree than it's done in the industry today.

This is definitely a huge area of implementation for type-level stuff, of saying, "I've got this company that's on the blockchain. We're doing things that are multiple millions of dollars per second." That's a very expensive mistake if you've got a bug there that crashes your system; you might be throwing money away.

And so the value of type-level programming is, you can prove properties about your program that are validated by the computer. And so the idea is - you want to just say, "Here's my problem and make sure that the solution you come up with is actually solving the problem, and in a wa that's fair."

Len: And this involves an interaction with the mysterious compiler. I know that like 90% of people listening to this know what a compiler is. But if you could explain a little bit about that, what that does - because I think to a lot of people it's a bit of a black box.

Sandy: Sure. So the way we interact with computers as humans - at least if we're creating software - is through the use of programming languages. And programming languages exist only in terms of an implementation. And so what we provide as a programming language is actually just text that gets accepted by a computer program. The computer program is the compiler. And so the compiler is what takes ideas from humans and turns it into things that run computers.

Len: It's instructions for the machine that's actually going to be doing the work. But that machine itself has to have some built-in way of interpreting the text that we feed into it.

Sandy: Exactly.

Len: And then if you understand the built-in way that it accepts these instructions, then you can operate at a higher level with respect to things like - well I guess, I mean vulnerabilities.

Sandy: Sorry, can you repeat that?

Len: Actually probably I can't. I guess what I'm trying to say is that if you really understand how your instructions are being interpreted, then you can create instructions that are more likely to do something that's verified and secure.

Sandy: Yeah absolutely. The way I look at it is - the types are mathematical proofs. And you say, "If I solve the problem in this way, then we're guaranteed to not have vulnerability, we're guaranteed to not crash, we're guaranteed to not lose money - what have you. And so that's a formal specification that any code you then write is checked against, to make sure that the code you're writing accomplishes the goals that you want to accomplish.

Len: Thanks for that. That's actually exactly what I was trying to get at. Is like how is it that, you can actually have a guarantee of that kind?

My last question on that subject is, if you could talk a little bit about means for something to be type safe?

Sandy: Certainly. The idea of type safety is just making sure that you're not doing anything stupid. For example, you can like compare two colors, and like they're similar. So there's some notion of similarity between them. But there's not really a notion of multiplying them or turning them on, or something like that. Even though you can turn on the light switch. And so the class of things that we're talking about limits the things we can do. Type safety is just making sure that you're not trying to use some ID in the wrong domain.

Len: My last question about the book is, who's the audience for this?

Sandy: I'm not entirely sure, to be honest with you. It's aimed at an audience of people who are intermediate Haskellers to professional Haskellers, of whom there are not really any. There's maybe five companies in the world who write Haskell. So it's a small market on that front. But there is this huge community of people who would like to be doing these things, who've found this language, and it's spoken to them in some way. And they would love to be doing this professionally. But the industry keeps saying, "It's hard to hire these jobs, so we're not going to do it." And so there's this weird catch 22.

More specifically, the book is aimed at people who write code and then feel uneasy about it afterwards. And they say, "I know that this thing can crash if n equals four. We can write some tests to make sure that's not the case, but what if we didn't write enough? What if we forgot to write a test somewhere?" And the people who lose sleep at night saying, "Maybe my code isn't as robust as I think it might be?" So that's the audience, I guess?

Len: It sounds like it's for people who are working on the kinds of things where if a mistake is made, the consequences can be dire.

Sandy: Absolutely. I think a lot of software falls into that category, even though we we don't think so. The reason most phone apps are crap, is because they get written really quickly and people miss all these weird cases.

There is the matter of life and death, but it's also just a matter of taking pride in what you do. If you want to build something, you want to make sure it's going to do what it does - or what it's supposed to do. And so there's definitely this aspect of making sure that it's applicable in all the places it needs to be. But I would like to see a world in which it's everywhere.

Len: I completely agree with that. I have a particular hobby-horse which is the way - and this this is actually at the design level, where people will design things for a what they consider to be a delightful experience. And one convention is hiding information in order to make the experience more delightful.

Sandy: Right.

Len: There's this one payment service provider that we use that I like to bring up and not name, because they're very good in many ways, but they did a redesign not too long ago, and when you go to pay someone, they started showing you just random circle faces from people you've paid before.

There's two things I say about those things. First of all, no one would ever, ever design that in a payments app who'd ever been in a situation where - if they sent money to the wrong person, there was no more in the bank, if you know what I mean?

And another example I like to give is - I will name it, specifically Gmail. If you go like in Chrome and you try to send an email, it will actually not show you the email address. It'll just show you the name of the account. And it'll hide both the "to" and the "from" fields, and just show you a name in a little bar.

So you don't know what email address that's associated with. You don't know if it's the "from" and you don't know if it's the "to," and you have no information about either of those really. And the way--

Sandy: But it's minimal, so it's brilliant, right?

Len: Yeah, isn't that a delightful experience? And the way I like to put it is - if you've ever been in a job where, if you sent an email to the wrong person, billions of dollars or jail were at stake - you would never design something like that.

The analogy, I think I used it recently, is like a glass hammer. What a beautiful thing, and actually completely useless.

Sorry for my little rant there, but I completely agree with you that - we all have this experience of hearing about these huge leaks, and important government websites that fail as soon as they're launched. Software is becoming more and more important in our world, as it's eating everything up. Everything's based on software, and we're still going through - I think a cultural period, where we're just being cowboys about so much.

Sandy: Absolutely. What's particularly frustrating to me is the technology to not have these problems exists, and it has existed for 30 years. And he industry is just behind, and people are - they dismiss things without, I think, thinking about them too much. They say, "Oh this is new and different, and so it's not worth thinking about."

Len: Moving on to last part of the interview, I wanted to talk to you about the process for making your book. You didn't just write a book in stealth mode and then dump it on the public. You actually tested your idea first, and in a couple of different ways. I was wondering if you could talk about that?

Sandy: So I was in Lithuania, and I had a project. I had this idea to write a book on type-level programming. I spent a few weeks on it, and my friend bullied me into publishing it. So I published this 37-page document that was very rough and had a lot swear words in it, and just was like clearly unfinished. But I turned it around, and people loved it for some reason. There was clearly a demand for this somehow. I would not have bet money on it. Before it was just a project of love.

So I set up a Patreon for that, because people said they'd pay me money. I had no income, so I figure it's probably the right thing to do. I decided I was going to publish a chapter every week, get feedback on it, and put my email everywhere, to see if anyone had any comments. So, "Just let me know." And I wanted to write the best book I could, and the only way to do that I think is to solicit feedback.

Len: It's really interesting. We've had people do Kickstarter before for Leanpub books. But I think you're the first person to use Patreon. Did that involve a commitment from you for regular output of new material?

Sandy: Certainly, yeah. I was definitely motivated to work on this. Because all of a sudden people were paying me money, whether or not I did anything. And that was feeling a lot like fraud if I wasn't going to do anything. I'm sure I probably would've gotten away with it if I wanted to, but I didn't. Just having people have their money on the line, putting their money where their mouth was, was so powerful a motivating force.

Len: And with Leanpub, did you publish the book in progress, or was it done by the time you brought it to us?

Sandy: Oh no, it was definitely published on-the-go on Leanpub.

Len: And was getting feedback from people during that process an important part of how the book ended up?

Sandy: Yes, for sure. I offered a tier on Patreon for like anyone who gave me - someone would get early access to the book. I didn't realize that Leanpub also let you sell the book as it went. And so, like accidentally getting two revenue streams, that we're cannibalizing one another. But yeah, so I put this up on Leanpub, just because it seemed like the easiest place to do this. And then people started buying it and started sending me emails saying, "Hey there's a typo here, there's a bug. Hey, this is terribly written."

Len: That's an experience quite a few people have talked about. It's funny how surprised people often are at the generosity that readers have, and the genuine enjoyment that they have when they find it something as basic as a typo - and they can contact you, and then see it corrected in the next version. People just love interacting that way.

Sandy: Absolutely. I think that was the thing that kept me the most - what took me by the most surprise was just this idea that people were excited - for the first time in my life, about something I was working on. And it was super easy to like interact with them and just say, "Hey, here it is. I would love to hear from you." And people did.

Len: And your book is in our "Bring Your Own Book" workflow, which means that you actually used your own workflow to create the ebook files, and then you just upload them to Leanpub. I was wondering if you could talk a little bit about what your process was. You've got PDF and EPUB files, if I'm correct?

Sandy: I'm so happy you asked about this. So I had written my original document in LaTeX, which is academic typesetting software from the 70s. It's still used by most academics today, and it's notable for putting out pretty good looking things without a lot of effort. This is what I knew from my days in university, and I figured this was the right tool for the job. So I put this together.

As I worked through the project further and further though, I realized this maybe wasn't the right tool. For example, I wanted to put little snippets of code into the book. But I also wanted to make sure that those snippets were right. And so they had to be in a wider context. But then there's this problem of, "Do I copy and paste it into the book? How do I make sure that all the code is up to date?" So involved like writing a lot of tools to make, "Can I keep everything up to date?"

And then as I went further and further down this rabbit hole, it more or less works and the book looks good. I did that and then realized afterwards, "Oh I need an ebook version of this." But LaTeX doesn't create ebooks. There are tools that will take a PDF and turn it into an ebook. But they missed the point, I think, because they don't really capture the meaning of what are you trying to do? They capture how much - is I guess my hobby horse.

And so I realized I wrote like 400-line shell scripts that would slowly take pieces of the LaTEX and turn them into something that was more amenable for the ebook. This thing was just like a nightmare to run, and was the price I paid for not using the right tools. I don't think those tools exist currently, and I think there's a lot of potential for a product that is writing documents based on what do they mean, rather than what they are.

To give you an example of that, my book has exercises and solutions. And for my peace of mind, I wanted to write those things beside each other - so you can clearly see the exercise and the solution to it. But in the book, the solution probably shouldn't be beside that thing. And so trying to write, trying to figure out how to make that happen in this published document - I'm saying, "My exercises are here, but the solution is at the back of the book." That thing, that took me two days. That shouldn't be so hard

I think a lot of people solved that problem by not dealing with it. They just say, "I'll copy and paste, I'll put it in back." And then you've lost this relationship between the two that you can exploit later. So yeah, I think there's a lot of value to be had there, if someone's looking to do it.

Len: Yeah. Thanks very much for that. It's always good for us to hear about people's experiences and their preferences. Because everybody's different, everybody's got their own way into writing a book. And people who are particularly - technically, let's say technically sophisticated - often come up with very sophisticated solutions.

It's pretty common to hear the story of like, "It took me a while, but I finally got there building the thing that I want." And for us, that's you cool to hear about. So, thank you very much for sharing that.

My last question that I always like to ask on this podcast is - if there was one thing we could build for you on Leanpub, or one thing we could fix - is there anything you can think of?

Sandy: I think the platform is pretty fantastic, actually. I don't know about building any particular tools. But something I would like to see is, it's hard to find things in the menus - in the author dashboards. Like I said, "I want to update the progress of my book." And a lot of times it would take me like 15 minutes to find that, because there were so many options, and it was never where I expected it to be. I think recently you guys have redone a lot of the menus, and so now my previous knowledge has not carried over again.

Len: Thanks a lot for that. That's something we're always trying to improve. It's a really interesting challenge, because actually Leanpub over the years has - we've got a lot of features and options, and knowing where to put things, like how do you mark the progress, "My book is 80% done?" It's actually an interesting question, because should it be in the book info? Well yeah, it seems like it should. But actually the progress number only shows up in one place, and that's on your book's landing page.

Len: And so deciding should it be in the book info, or should it be where you set what's on your landing page? We currently have it where you set what's on your landing page. Of course these are things that could also appear in more than one place, but that's got its own problems.

Yes, we did just redo our author nav as we call it. It should make finding the pages where you can do things a lot easier. But still, knowing what's on that page is the hard part. So, thanks very much for that.

And thanks very much for taking the time to do this and for being so forthcoming. I really appreciate that, we covered a lot of interesting ground.

Sandy: Absolutely. Thanks for having me.

Len: And thanks for being a Leanpub author.

Sandy: Thanks for the platform, it's fantastic. I would recommend it.

Len: Thanks.

Thanks everyone for listening to this episode of the Frontmatter Podcast. If you like what you heard, please subscribe and review us on iTunes, and rate us as well. And please consider signing up as an author on Leanpub. We welcome everyone who's got interesting things to say and to teach. Because of course, Leanpub isn't just a platform for making books, it's also a platform for making courses. See you next time.

Podcast info & credits
  • Published on January 9th, 2019
  • Interview by Len Epp on December 18th, 2018
  • Transcribed by Alys McDonough