Matt Parsons, Author of Production Haskell: Succeeding in Industry with Haskell

Len: Hi I'm Len Epp from Leanpub, and in this episode of the Frontmatter podcast I'll be interviewing Matt Parsons.

Based in Denver, Matt is a programmer and blogger who is currently Lead Software Engineer for Mercury, a service that helps US-incorporated startups manage bank accounts that scale with their business.

You can follow him on Twitter @mattoflambda and check out his website at parsonsmatt.org.

Matt is the author of the Leanpub book Production Haskell: Succeeding in Industry with Haskell. In the book, Matt guides readers through the pitfalls and opportunties of actually working with Haskell to build large software projects. You can follow his progress on the book on Twitter @prodhaskell.

In this interview, we’re going to talk about Matt's background and career, professional interests, his book, and at the end we'll talk about his experience writing a book.

So, thank you Matt for being on the Leanpub Frontmatter Podcast.

Matt: Thank you for having me.

Len: I always like to start these interviews by asking people for their origin story. So, I was wondering if you could talk a little bit about where you grew up, and how you ended up in a career in programming?

Matt: I was born in Colorado Springs. My family moved around a whole lot. I found myself in Georgia around age 12. I didn't know what I wanted to do with my life, but I know I really liked playing video games. I wanted to be a video game programmer. That seemed like the most natural thing that I'd want to do.

Then an issue came out of Electronic Gaming Monthly, that went into what it's like to actually be in the video game industry, and I excitedly flipped to the page about programmers. And the page basically said that the video game industry was horrible, it was long hours and the pay wasn't all that great anyway. It's like, "Okay, well, I'll never program a computer then. I'm out of that."

I spent about ten years thinking I would do something with like pharmacy or biochemistry or biotech, or something like that. Eventually I failed out of a biochemistry program at the University of Georgia. I took a few years off to do IT support,and finally was like, "Oh man, I've got to get out of IT support, what can I do?" And Computer Science seemed like the easiest way to get back into the world at large. So that's what I jumped into. I got into Computer Science, and have been programming ever since.

Len: It's really interesting you mentioned a magazine dissuading you from getting into programming from gaming. I've interviewed people across the generations on the podcast, for many of whom, their entry into computer programming was actually flipping through a magazine, gaming magazines. Which - in the old days, would actually have the program printed on the page. Then they'd enter it into the computer, and experiencethe magic of seeing it. But you're the first person I think I've interviewed who was dissuaded by a print magazine.

Matt: I'm an extremely lazy person. And the thing was just like, "They're long, hard hours." It's like, "Okay, well that's not for me."

Len: And so you studied Computer Science, and you did it formally at university and did a degree at the University of Georgia, I believe. And you didn't graduate all that long ago.

Matt: Yeah, I think - oh man, I think it was 2016 that I graduated. So I've only been out in the world for about five years now.

Len: And what was your experience like doing a degree that recently? Was it something where you felt you just loved every moment of it? Did you ever regret taking all those years to formally study Computer Science, when you could've found some other way into programming?

Matt: Yeah, it's interesting. Because my education left me in about 40, 50 thousand dollars of debt. And my only experience of my education mattering is - I applied for an internship at a fancy New York investment firm that uses functional programming, and got a rejection within three hours on a weekend. I'm pretty sure it's because my university wasn't on one of the - it wasn't one of the options on the drop-down list. So it seems like, if you get like a degree from Stanford or MIT - that's worth a lot. But if you don't get a degree from one of those places that's pretty high reputable, high status - you're just carrying around a piece of paper that doesn't really do a lot for you.

Len: Yeah, that's actually something I have a little bit of experience in myself, but from the other side. For my sins, I'm a former investment banker. And back when I was starting out, I was applying to all the banks. I was in England at the time. I applied to some of the big name American banks, and it was very different from applying to investment banks in other countries, in my experience. Specifically, actually, I remember one actually went down to naming your high school.

Matt: Wow.

Len: So they clearly ha -- I mean, I'm just going to be kind of crude about it - they clearly had a list of east coast prep schools that they were sorting for.

And one of the really interesting features of it, is it can sound like - when you hire someone like that, you're hiring a way into their network. It's one of the things that if you're not born into a family with that kind of network, it can seem really, really unfair - and it is.

But the explanation there isn't just snobbery or whatever. There actually is - from the perspective of organizations like that, there can be a value to just hiring someone with a famous last name, if you know what I mean?

Matt: Yeah, absolutely.

Len: And also - I won't go on about it forever. This podcast is about you. But it's actually very seductive, right? Like I remember, after a while, if someone showed me a slide with, "Join the team," and one of the people on the team had gone to the University of Saskatchewan, I was like pfft. And I went there, myself.

Matt: Nice.

Len: So it's a very seductive - the world of brand name companies and educations and stuff like that is - it can be problematic.

But anyway - doing research for this interview, I gather you did find your first work in Athens, Georgia?

Matt: Yeah, that's right. My first two internships - one was a JavaScript internship, and the second was a Ruby on Rails internship. And those are really where I learned how to do actual programming, and not just the basic stuff you learn in like a C Tier school.

Len: And did you learn Haskell in university?

Matt: Kind of. I studied it independently for the most part. But in my senior year of college, I was able to use Haskell as a - the AI professor that was teaching the course that I was in, would allow the students to use any language they wanted, as long as you could provide a Bash script or whatever, that would compile it and print out the right answers. And so I took that as an opportunity to use Haskell for all of those problems.

Then in my second semester senior year, I was able to use Haskell and study category theory for an independent research project. So I kind of got to use it. I had - my final internship in college was with Layer 3 Communications. They use Haskell on the back end. So I was able to get some Haskell real-world production experience as well.

Len: And just before we go on to talk a little bit more about your career - I know that you actually- this is your first day at Mercury, and I was wondering if you could talk, list a little bit about what your role is going to be at that company?

Matt: Yeah, I think we're still hammering it out, exactly. But I'm going to be a team leader. And the team that I'm going to be forming, is going to be working on developer experience and developer productivity. So some of the projects I think we're going to be tackling are the like IDE situation in Haskell. Right now, the main Haskell language server doesn't work on our code base. I guess because our code base is like too big, or uses some weird features or something, that I'm probably going to be working on coordinating to get that working out - to help everyone else, get their productivity to go up.

Len: Actually when we get closer to talking about your book specifically, I might have some questions about the inherent difficulties around productivity in Haskell training and coding. And also, yeah, the development environment. Basically, from what I understand - and I'm not an expert, it has some issues as well, that would be really -

Matt: Lots of rough edges.

Len: It would be really interesting to talk to you about why and what potential solutions might be. But before we do that, actually - one thing you mention in your bio is that, "There's an underpinning to writing music, learning mathematics and making beautiful programs that resonates with me."

Matt: Yeah.

Len: I just wanted to give you a chance to talk about that, if you're up for it. What is the underpinning that you see between music, math and programming?

Matt: Well, in a very reductive sense, they're all based on math. I don't know the math of music. I understand that there's some group theory involved. But I've never studied it. I just know that it's a thing. I've studied music theory, the composition of songs. And that's - using the same word, "composition," that we'd use so much in Haskell, where we're composing functions. And when you compose a song, you can just like go directly by the books. You can do all the rules right. And it'll sound cool, it'll sound good. But then when you break some of the rules, it'll sound even cooler - if you know what you're doing.

And programming, I feel, has a lot of the same tradeoffs, in that - a lot of the times, there is a right way to do things. And if you just do the right thing all the time, it'll work pretty well. But then you have to know when to break the rules. You have to know when to make code less readable. To make it more performant. Or you have to know when to break an idiom, in order to achieve the end that you need with your code.

Len: And when you say, "Less readable," can you go into a little bit what you mean by that?

Matt: Yeah. Hmm.

Len: Like do you mean - I guess I'm sort of like - from the naive perspective, do you mean like less readable by a person, or by the machine?

Matt: Yeah. So there's like a number of tradeoffs with readability of code. You can have code that's write-friendly, and you can have code that's read-friendly. Code that's write-friendly is really, really terse. It doesn't have a whole lot of stuff that you need to type to get stuff done. It might, in Haskell, use a lot of operators - that'll make it really, really fast to bang out an idea really quickly.

When you're prototyping, that's fine. But when you're not prototyping, when you're building for long haul - you want to build something that is really easy to read.

And this usually means that it's a little more verbose than the write-friendly style. It's a little more annoying to actually put it down, but it's a lot easier to pick it back up.

And then there's also some concerns and tradeoffs with like - especially in Haskell, when you're writing really high-performance code, it's often the case that restructuring the code to be a little bit more - not difficult to read, but the - making the code fast, necessarily requires you do some things that are very unidiomatic, and can be kind of difficult to work with.

Len: And one of the problems with - one of the tradeoffs with being unidiomatic would be remembering in the future what you did, or communicating to other people what you chose to do?

Matt: Yeah. If you're using really high-level abstractions, you can almost format your code such that the structure of the code itself, as it's laid out on your monitor, suggests what's going on under the hood. But, if you can't really use those high-level abstractions for whatever reason - be it performance or the abstraction just doesn't really fit exactly, you can't really structure your code in the same way.

Len: This is really interesting, actually. We're kind of jumping ahead a little bit. But since we're here, you write in your book that with Haskell, the layout of the code can be like the layout of a poem.

Matt: Yeah.

Len: That the layout has meaning, and it's not just to make it easier for you to look at - but it tells you something.

Matt: You can usually like line up - especially with binary operators, if you split up your code such that you have the left hand side, several spaces, an operator - and then several more spaces on the right hand side, and you repeat that pattern across several lines of code - that might make the structure of what you're doing jump out a little bit better.

I have a blog post called Elegant Fizzbuzz, where I was just trying to solve Fizzbuzz in Haskell for fun, and I realized that there was an interesting structure going on. And I realized that because I had formatted my code in a specific way.

Len: That's really cool. We actually have a book about Fizzbuzz - so for anyone who's not familiar with what that is, I'll put a link to that book too, and you'll have a really fun way of learning all about that. But yeah - that was a really fascinating thing for me to learn about Haskell, that I didn't know.

Before we go on to talk about your book more directly, I wanted to ask you something. I mentioned before we started recording that - basically back in March, which is getting to be towards a year ago now - I started adding a little section to these interviews, where we talk about the guest's experience of the pandemic, and what it's been like for them where they live. So, I was wondering if you could talk a little bit about how - just generally speaking, how it's affected you in Denver, in your life and in your career?

Matt: I've been extremely fortunate. I haven't gotten the disease, and no one that I know has had a severe case of the disease. And so, in that sense, I'm really lucky.

Most of my hobbies are just going outside and riding my bike, or reading a book, or being on the computer. I'll go out and socialize to the bar or something, like maybe once a month or so. But otherwise, nothing that I really like to do all that much got shut down. I can still go to the grocery store. I can still ride my bike. I can still go to the dispensary and the alcohol stores. So I guess I have all the fun I want to have. I just can't see people. And I'm pretty introverted, so that was fine for like the first four or five months. But now I'm real excited to go out and do stuff.

Len: And did people in your neighborhood start wearing masks early on?

Matt: Pretty early, yeah. Denver is pretty reasonable as far as cities go. I'm out in the suburbs a little bit,but it's still like a pretty reasonable suburb. There's a couple of restaurants that were a little salty about it, like, "Our employees have to wear masks and we have to ask you to wear masks, and we're sorry. We think it's overreach, but like you gotta do it". All told, it feels pretty good to me.

Len: Thank you for sharing that. I've mentioned this before, but here - I live on Vancouver Island in a city called Victoria, and people didn't really start wearing masks outside until - I don't know, about six weeks ago, or something like that. Even now it's about half,and that was because the incidence here was low. People reacted pretty quickly. And yeah, it's - with respect to this anyway, it's a reasonable city. I know what you mean by that.

It is interesting, given the wide variety of people that we interview on this podcast, some people will give the similar answer to the one you've given. Other people are like, "It's been terrible for me personally." But there's always a lot of empathy, which I really appreciate. Because, I mean - even if it hasn't affected some us - very directly, we all know every day how it's affecting people all around the world.

Matt: Absolutely.

Len: Actually, I didn't ask you about this before we started recording. But, doing my research for this, I listened to a podcast or two that you were on,and I believe you mentioned that you were relatively recently diagnosed with ADHD?

Matt: Yes, that's right.

Len: I think I saw you talk somewhere about how it's important to talk about things like that. Do you want to talk a little bit about that experience?

Matt: Yeah. So, like my whole life just about, I've had this experience of getting really, really, really into something. Video games was the first thing. And then I got really into playing guitar. And then I got really into home-brewing beer. And then I got really into - it's a whole long list of things. And when I get really, really into something, I can get pretty good at it pretty quickly. Because I'm spending like eight to ten hours almost every single day - focused effort - just reading about it, studying it, practicing it - all that stuff. And for a really long time, I didn't get really into anything that was useful for careers. And so I had this dead-end IT job at the university.

And then, by just a stroke of luck, I got really into programming computers. I got really excited about programming functional stuff with Haskell. And I just put weeks and weeks and weeks of time into studying, and getting really good at this stuff. Those phases will last between one year and five years.

And then once that phase is over, I have a really hard time picking it back up. And one thing that I realized early last year, or maybe a little bit before that, was that I was actually having a really difficult time focusing on programming.

And I kind of noticed, "Oh no, Uh oh. If this goes like how everything else in my life has gone, I'm not going to be able to program effectively anymore. Because I'm going to get stuck on some other project or some other task, or some other hobby." That really spooked me.

So I started doing research on what exactly was going on. Is there any way I can like stop this? What can I do? And I found a couple of threads on Twitter, where someone was talking about, "Hey, you may have ADHD if this describes your life." And I read the thread, and it's like, "Oh man, this describes my life."

So fast forward about a year, which is the amount of time that it took for me to overcome my ADHD brain, with actually going through the system and getting treatment. I start treatment, and it's like a lightbulb switched on. I'd been working - I had the idea to work on Production Haskell, and I had a table of contents, for about like two and a half years, before I actually started writing it in earnest. And between starting ADHD treatment in August and November, I had written like three or four hundred pages in the book.

As soon as I started, it's like, "Oh wow, I can do things that aren't the thing I'm most obsessed about right now. I can just be productive, and I can just choose what I want to focus my energy on." Aside from like saving my job and allowing me to contribute to the community really well, it's also allowed me to split my attention between other things that are valuable in my life. I was getting really into riding my bike, and I'd be able to ride my bike for a ten hour day. That's fun and I love doing it, and I want to go do it again. But now I can also read books. I can lift weights and do other things that are fun, rather than just ride my bike all the time.

Len: Are there any resources that you would like to point people to, if they're curious about themselves, and whether this might be something they could benefit from looking into?

Matt: I really wish I could remember. It was a tweet thread that got me started with it. But then after that, it was kind of a bit of a self-diagnosis. I talked to a psychiatrist, and the psychiatrist was able to work with me on my symptoms, and figure out what's going on.

I think if you believe that ADHD is your problem, don't be afraid to stand up for yourself. Because the first psychiatrist I talked to, wanted to treat me for bipolar disorder. Which is not at all what my symptoms were. But I thought I would be a good sport and try it out. And the medication that they gave you for bipolar disorder is horrifyingly bad. Or at least, it was really bad for me. So I found a different psychiatrist, that was willing to take me seriously and actually treat the ADHD. And it has been excellent.

Len: Thank you very much for sharing that. I haven't had any direct personal experience with that kind of thing myself, but there's a kind of - that advice about standing up for yourself, sounds to me to be - I mean, really, really important. And it's particular to - certain types of practices have what I call, not a vicious circle, but an infernal circle,where the practitioner themselves is trapped by a presumption that they have. The example I like to give, which I hope is kind of funny - is if like an old-timey psychoanalyst says to the analysand, "You're repressing something", and the analysand goes, "No I'm not." And then the psychoanalyst goes, "See."

Matt: Right.

Len: And so, being on the lookout for that - that is just peculiar to certain kinds of health-related professions, where the practitioner is so accustomed to being a totally dominant authority in all of their interactions, that if they ever did have a self-questioning voice in their head, they stop showing it even to themselves after a while. But thank you very much for sharing that.

And actually, speaking of things that you really got into - you brought it up, that you've written hundreds of pages of your book Production Haskell and it's still marked as 85% done, and we'll talk a little bit about what that means, maybe in a little bit. But I was wondering if you could start talking about just what your inspiration was for writing the book in the first place? How did it come about as a project?

Matt: Well, I've been writing in my blog for a long time. And that started off just as a baby, beginner programmer, writing about, "Oh, this is how I figured out this library. This is how I did this one beginner thing." And people really latched onto it. They were like, "Wow, this is good stuff." So I just wrote progressively more and more kind of advanced topics in Haskell."

But then what I realized is that everyone is writing advanced topics in Haskell. Everyone wants to talk about how to do this fancy, cool new technique using this crazy, dependent type simulation stuff.

And there's a lot of value in that, but everyone is doing it. If you're excited about Haskell, that's probably the sort of thing you're excited about. But I want to use Haskell with my job. And there's like one book, Real World Haskell, published in 2008. That's like the only one that even like tries to talk about being a real world book.

And so my inspiration - Sandy Maguire actually contacted me, and he was like, "Hey, we should work together and come out with a book. It'll be the Advanced Haskell book, that everyone needs to read." And I was like, "Yeah, that sounds cool." This was pre-ADHD treatment. So I never actually worked on it. Sandy got fed up, and he released Thinking With Types, which was his half of the table of contents. But yeah, the Haskell Weekly, they do a survey about once a year, and every single time, people are like, "We need intermediate documentation. I have no idea what design patterns to use. I have no idea how to structure a large application."

And there are definitely a lot of people that know that. Very likely better than me. But they haven't written a book about it yet. I have worked on several production applications. I have some idea of what works and what fails and the ways in which it's different from other environments. I want to encode that knowledge, so I can give it to the rest of the world. They can have their own successful Haskell projects, and more people can have Haskell jobs.

Len: And there's definitely obviously a demand out there for it, because it's been quite a successful book on Leanpub so far, and found a lot of readers.

I wanted to ask - so one of the really interesting things about the book is that - I mean, sort of like people who are accustomed to reading programming books might go into book called "Production Something," and think, "Oh, it's about getting code into production, and what are the practicalities of that." And that certainly is a really important part of the book, as you just described. But it's also about other aspects of having Haskell in production, right? And one of those is hiring.

Matt: Yes.

Len: I was wondering if you could talk a little bit about that? Because you can't get code into production, without hiring people to do it, and I was wondering if you could talk a little bit about what are some of the particular challenges, or the particular nature, of hiring Haskell developers for projects?

Matt: So the experience that every single Haskell engineer or Haskell hiring role has - is that you put out the job ad, and you get a hundred applicants, and they're all super qualified,like they've all got PhD's, they have a ton of experience, they're really bright. You have this really, really, really solid hiring pool from which to draw on, if you're capable of doing full remote. If I were to try and do a Haskell company and hire just from the Denver area, there might be like ten people total that I can hire. And I'd have to hire from other people that are doing Haskell with [other] companies.

So you have a small hiring pool, but it's pretty high quality. And that hiring pool's also a bit bimodal. So, there are some people that are working with Scala or F# or Java or Kotlin - or any number of languages. And they are really excited about Haskell, and they really want to do it. And so these are five, ten year experience engineers. They're really good at their thing. But they've never used Haskell in production, and they want that Haskell experience really badly. These people are often willing to take a pay cut, in order to work with a language.

But here's the problem. If you base your hiring policy on hiring these people that are willing to take a pay cut, they're going to get that year of Haskell experience, or that two years of Haskell experience, and they're going to be right back up to their regular market rates. And you're going to have spent two years ramping them up on this obscure language and technology, only for them to jump ship to somewhere that's going to pay them quite a bit more, and still let them use Haskell.

So there's kind of a double-edged sword, and there's a lot of relatively cheap talent. But if you take advantage of that cheap talent, you're going to pay a ton of money and a ton of time in onboarding, ramping people up - and then losing them in turnover.

Len: That's really interesting. I think, if I remember correctly, you've written similar about how there's such a limited pool of trained Haskell programmers, that if you get one, it's almost like a zero sum thing, right? If you get one from some company, they probably just spent two years training them up. So, then they have to train someone else. So if you think of like the pool of Haskell development happening out there, it's just kind of like - it's got a limited number of people, and they're all just moving from one thing to another, leaving vacancies behind them.

Matt: Yeah, it's small. And a lot of organizations are reluctant to train up pure juniors. So they'll hire someone that has a lot of experience outside of Haskell. But they're a lot less willing to hire a new college graduate that does not have any experience, that doesn't have much experience - period.

It's a huge problem, when you fail to hire that sort of thing. Because you lose the ability to keep your code base simple enough that you can onboard easily. And when you train people up on your code base, they're worth way more than when you first hired them. And they're also worth way more to you, than they are to whoever's able to hire them away.

Len: It's a really fascinating challenge. You also talk in the book, in addition to hiring - there's teaching. Teaching is something that you might have to do,even if someone's got their PhD in Computer Science, and maybe they wrote their thesis on Haskell topics.

But then, getting them into a position where they can learn the code base that a company's actually using to provide a service, and then getting them to be productive on it. How would you recommend -? I mean, let's actually - rather than using the PhD example, let's say - it's just someone who's really smart, who wants to learn Haskell - and you hire them up, confident that you can train them. How would you go about doing that?

Matt: Part of this is how you structure your code in the first place. I think one thing that's difficult about Haskell, and I think Lisp probably has a similar problem, is that you can increase the incidental complexity of your code base, almost without bounds. You can do incredibly fancy things that are difficult to understand, that are super productive, that are really cool, that solve real problems. But, that are really hard to understand - that have nothing to do with your domain. And so, whenever you bring a new engineer on, you have to kind of level them up - both in the domain of your business, but also the incidental complexity of your code base.

And so if you keep your incidental complexity as low as you can, you have less of a problem ramping people up to teach it in the first place. That's not to say that you can't be fancy ever. But you should be really careful about how much time you're spending being fancy - making sure that your documentation is really up to par with that. Because if you don't have like the documentation and the supporting materials for the techniques that you're using, you're going to have a hard time bringing anyone on board, regardless of how smart or experienced they are.

Len: And is getting too complex like a particular problem for Haskell?

Matt: Yeah, I've seen it in a number of Haskell code bases. The very first Haskell code base I was responsible for, I got really excited that I got to use Haskell. And so I used it as kind of a learning ground for a lot of fancy techniques. And when we were starting to onboard people, I realized really quickly that those fancy techniques might have saved me like a few hours of work. But they were going to be like dozens and dozens of hours of teaching and training for every single new person that came on board - unless they already happened to know the pattern I was using.

And Haskell is - it's sufficiently different. It's sufficiently novel that just the syntax is already a lot to learn. And every little thing you throw on top of that pile, is just going to increase the difficulty of getting onto the code base.

Len: It's actually really interesting - the issue of difficulty is something you address in part by invoking the concept of empathy in your book. And of course, we're all naturally going to think - when we bring up empathy, we think about being empathetic towards other people. But you talk a lot about being empathetic towards yourself.

Matt: Yeah.

Len: And I love the temporal distinction that you use between past self and future self. My brother jokes about like future - his name's Mike, and he's always like, "Future Mike is going to hate current Mike a lot." Or else, "Future Mike's going to be really happy. But present day Mike is really sad."

I was wondering if you could talk a little bit about that. Because I'll just quote you back at yourself here. You've got this great line where you say, "Your past self was excited about a new technique and couldn’t wait to use it. They felt so clever and satisfied with the solution! Let’s remember their happiness, and forgive them the mess they have left us."

That's just fantastic, and I like that idea of like - when you're looking at something where someone was maybe extending themselves too much, or new to something and excited - you can be mad at them a little bit, that they didn't take into account your frustration. But keep in mind that they were happy when they did that, maybe?

Matt: Well, I think everyone, for the most part, is trying to do the best thing they can with the information they've got, and the options available to them at any given point. I think people are rarely like trying to be maliciously bad. Sometimes they can be a little thoughtless, but who isn't? And when you're learning to code and you're doing your job, for the most part, people who get into Haskell do it because - not because it's like a fun mind teaser, but because they think it's actually better. They think they're actually more productive with this. And it's true. Like a lot of these techniques, a lot of these fancy things that I like kind of complain about people overusing, are tremendous time savers, sometimes. And you don't know - you can't know what's going to be a time saver and what's going to be a time sink, until you've developed that experience of sinking a lot of time into something. Or saving a lot of time.

Len: Productivity is such a deep and wide issue in the programming world, and you do write about it. I was wondering if we could talk a little bit about that? You've got this - and I'll quote you back at yourself again: "How do we measure developer productivity? It’s not simple. Many studies exist, and all of them are bad."

I was just wondering if we could talk a little bit about productivity, particularly in the context of Haskell. You've written about how I think Haskell code can in some circumstances be far more productive code to achieve certain goals, than if it were written in other languages.

Productivity isn't just how fast - how many keystrokes I can do, or how quickly I can build out a feature or solve a bug. I'm unfortunately asking maybe an overly general question, but if you could talk about productivity in the context of Haskell, and maybe how you go about doing some version of measuring it? That would be really interesting.

Matt: So, I don't believe in measuring productivity. I think for the most part, it's not like we're building a house - where you know exactly how many bricks you need to lay. And the faster you are at laying bricks, the faster the house gets built.

For the most part, I feel like the most productive moments I've had in programming, was figuring out how to not build an entire wall. Or something similar to that.

But sometimes you do know what it is that you need to do. And I think that Haskell has tremendous advantages in its type system, and in its data type modelling capacities,to develop code and to prototype code extremely quickly to solve problems. And then, once you've developed something, you've got that prototype going, it's really easy to keep it in maintenance for a really long time.

I've gone back to Haskell code from like five years ago, and just jumping back into it was easy, in comparison to - if there's some JavaScript that I wrote six months ago, I'm going to have to completely, ground up, get my context again.

So when it comes to just actually writing code and maintaining code, I have found that Haskell is just a super power. It's amazing. And it's difficult to communicate that to someone without just kind of guiding them through the same experience, where you refactor your code, and the compiler complains at you. You edit the code until the compiler stops whining, and then your code just works, and it's better.

So the problem with that, is that a software engineering role is responsible for way more than just developing code. They're responsible for - usually in like a smaller company, a startup - they're going to be responsible for deploying that code, for documenting that code, for hooking it up for observability. For testing it. For doing QA on it. And if you have team of five engineers, they're only capable of doing five engineers' worth of QA - even if they're able to do ten engineers' worth of programming.

Len: It's a really fascinating subject. I mean, because - for example - another dimension of getting Haskell code into production, is convincing the other people on your team - say if you're at a small startup - that you should do it in Haskell. But if you're maybe at a little bit of a bigger organization, you might have someone who's never written a line of code in their life, who is on on the business side of things. And then you have to go about convincing them to use this really complex thing, that basically the stereotype would be, "Only PhD geniuses can use it, and I can't explain it to you, but I've got to do something to try and convince you that this is the right thing to do."

Is maybe developing a - showing how quickly you can develop a prototype, a way of doing that? How would you recommend someone who's firmly convinced their team should switch to doing something in Haskell, or start doing something in Haskell - how do you go about convincing the suits that that's the right thing to do?

Matt: I think a throwaway prototype is probably the easiest way to do it. Haskell - if you're good at Haskell, Haskell is an incredible language for prototyping in. If you're not good at Haskell, you probably shouldn't be starting a new project in Haskell. At least not one that the business is going to be dependent on. Now, if there's some small utility that you can build in Haskell, where no one's really going to care about what it's made out of - like something that'll pass the CSV and do some transformations on the data - Haskell's great for that.

You can write that binary and give it to your other co-workers who are on the same Linux platform you are, and they'll be able to use it, and it doesn't matter to them what it's written in. And if you end up developing significant Haskell experience or expertise on that - and then you want to start launching a new project idea in Haskell, getting buy-in from the whole team, and understanding that there's going to be considerable training if the experiment's a success, is important. It's not terribly difficult to convince someone to let you do an experiment and to do a prototype in something. It is going to be more challenging to get them to commit to supporting that in the long run.

In my first role with Haskell, the company decided to do the experiment. The experiment was a wild success. We made a lot of money by switching over to Haskell services, because they were a lot faster. We had to use a tenth of server resources from our PHP stuff. And that was great. But then the time comes to hire more Haskell developers - and this is kind of going back to the problem of hiring Haskell developers - is, most of them don't want to be working on anything that isn't Haskell. The people that are interested in Haskell, but cool working with something else, are probably working with something else, just because of the dynamics of the job market.

So if you're advertising a Haskell job, and then it turns out - oh, you're going to have to write about 50% PHP and JavaScript, and 50% Haskell - lots of Haskell developers are going to look at that PHP and skip out on it.

So it's a difficult compromise to reach. It's a lot easier to just start a startup and make a Haskell job, than it is to turn a non-Haskell job into a Haskell job.

Len: Speaking of roles, that reminded me for some reason - you also write in your book about the distinction between a senior and a junior. And you mentioned that these terms can be problematic and controversial in some context. But I really like how you defined "senior." Which is someone - the difference between a senior and a junior in something - it's not age or anything like that. It's the amount of opportunities they've had to make mistakes and face them. I think that's a really great description.

Matt: Yeah, it's - you really have to experience the - hold on. What's that, there's that phrase, "You reap what you sow." There's a lot of people that are doing a lot of sowing, and they don't get to see when the reaping happens. Or, they don't get to see what happens when they reap. And that's a problem, because they go on, and they're like, "Oh yeah, I had these great experiences. At my next job, I'm going to do it again."

Len: It's actually kind of an arbitrary segue, but, that reminded me of something. I've interviewed a few people who've written books about software testing before, and testers have their own communities; actually there are regional variations in testing styles. So there's like the London School, and stuff like that.

The reason I say, "This is an arbitrary segue," is - you actually have talked also about how there's regional styles to Haskell. Without going into the details of how they're different, I was wondering if you could talk a little bit about - do you know how that emerged? That there are like regional styles for Haskell programming?

Matt: Yeah. Haskell's got it's roots in academia. And the University of - oh, I'm probably saying this wrong - the Glasgow University. That's where it all got started. But there was also Utrecht in the Netherlands, and there's universities in Sweden and Finland, and they all have their own distinct Haskell styles. There's not a Haskell style from France, because that's - they use OCaml instead. And then you kind of get over to the United States, and we don't have as much Haskell in our university system. I think the University of Pennsylvania is the main one.

But other than that, you've got some Fintech companies in New York City and Boston. And they have got their Haskell style. Then you've got - you go over to the West Coast, San Francisco and Portland - both have pretty strong Haskell styles as well. And they're all different. They're all subtly different in the kinds of abstractions and syntax formatting that they'll use.

Len: I think that gives me a good opportunity to wrap up this second part of the interview, before we go on to talk about your writing experience. I've come across Haskell in Fintech contexts before. Is there something -? but I'm totally ignorant. Is Haskell particularly popular for certain kinds of Fintech challenges?

Matt: I'm not - I mean, I'm not really in Fintech all that much. What I know is that Haskell's type system makes it really easy to do stuff like automatic differentiation with numbers. So you can define really intricate numeric computations, and then reuse them in ways that are interesting. And so I guess that if I were doing some kind of financial modelling, that would come in handy. You can also do a lot of good encoding with type safety with units in Haskell, though it's not something that it supports like super natively.

Len: Yeah, I was partly curious, just because I've come across Haskell in Fintech context before. But also because - you mentioned being able to reduce the use of a service by 10% or by 90% or something like that. And maybe it's something that's super data heavy, but also can be timing-related. But anyway, that was just an intuition, not an informed thought of any kind.

So, moving onto the last part of the interview, where we talk about your experience writing. I was wondering if you could talk a little bit about why you chose Leanpub as the platform to write your multi-hundred page book on?

Matt: So, I talked to Sandy Maguire a lot - and he was the one that actually kind of got me pointed in this direction. He had put a lot of work into his first book, to make it something that he could publish, and that he was happy with. He was using like very complicated LaTeX code to make his book work out. And I just - I looked at all the work he was doing, and I was like, "No." Kind of going back to the, not wanting to be a video game programmer. I'm extremely lazy, and I want to get my knowledge out there. I want for people to benefit from this. I do not want to spend a lot of time messing around with formatting.

So I saw that Leanpub had excellent formatting right out of the box for Markdown, and all of my blog posts are already in Markdown. I'm already very proficient with writing in it. It's a very like transparent process for me right now, to write in Markdown, get my thoughts down. And being able to publish - basically straight out Markdown, and have a reasonably good looking book - is a pretty amazing one-two-punch of utility for me

Len: And you have been publishing the book in progress. I think last I checked, it was more than 85% or something like that.

Matt: Yeah.

Len: Have you been getting feedback from people along the way who have been reading it and saying, "Oh, I really wish you'd written a chapter about this." Or, "What are you working on next?"

Matt: I've gotten a few pieces of feedback. It's funny because they are like diametrically opposed to each other. Some people really want for me to spend more time justifying my decisions,justifying why I am giving the recommendations I'm giving. And other people want me to make the book a lot shorter by not justifying any of my decisions. Just saying, like, "This is the right way." That's it. "Here's the next recommendation."

Len: Sorry, I'm laughing a little bit. But diametrically opposed feedback is one of the consistent features of doing anything.

Matt: Yeah, right?

Len: Pretty well - what I meant, of putting yourself out there and creating something. For example, like - some of the feedback we often get is like, "It's really easy to write in Leanpub, but your formatting's terrible."

Matt: Pick one.

Len: Yeah, I know, I know. Well that's - I mean that's our philosophy, right? Is it's like - when the book is done, done, then if formatting is really important to you - have at it, whether that means hiring a professional, or doing it yourself. But along the way - and I think, while you're writing - very much, too often - formatting is actually just a form of procrastination.

Matt: Yes.

Len: And we say that sort of both seriously and tongue in cheek. But like, I know that when I'm doing something, when I'm writing something - I'll start toying around with what it looks like. Even if, for example - people will work really hard to get their Microsoft Word document looking right. But that's not what's ever going to appear on a page anywhere.

Matt: No.

Len: And I say that sympathetically. Because I've done that myself. You just find yourself drawn into it and - yeah - hopefully Leanpub books do look good, and we're always trying to improve them and stuff like that. But our goal is to sort of make something that looks - at least good enough, and that you can use quickly and easily - so that you can just get to writing, and getting the next thing out there.

Speaking of formatting. I think your book is the bestselling book we've ever had without a cover image. Peter, my colleague, and I, always kind of laugh when we see it. Because here's this bestselling book, and it's just like the auto-generated thing from when you type in a book title in Leanpub, and then click the button to publish.

Matt: It's pretty ugly. I've got to get something for that. I want to get some good cover art and make for a prettier experience - at least on the Leanpub website.

Len: I mean, I guess maybe it's because I know it's such a high-quality book, but to me, it's kind of like this - it's a very confident thing to do. I've always seen it as sending the message that like this is a book where the writing is the most important thing, and I'm going to prove that by having no cover.

Matt: Well, maybe I don't want to get cover art now. I like the way that works.

Len: Well, I might not be the best person to base your decision on. Sandy, for example, has amazing covers for his books.

Matt: Oh yeah. They always look amazing.

Len: Yeah. The last question I always ask a guest on the podcast - if they're writing something on Leanpub, is - if there was one thing we could fix for you that really bugs you about Leanpub, or if there was one like magical feature you could ask us to build for you - can you think of anything that you would ask us to do?

Matt: That's a great question. My experiences in Leanpub has been extremely positive. It's super easy to get started. I recommend all of my friends write a book on Leanpub, just because it's so easy to get started. And then you get something out there that's cool. No, I mean, I'm pretty happy with it.

Len: Okay, thanks.

Matt: I know that the best thing you can hear is constructive criticism. And I'm - unfortunately, unable to provide any right now.

Len: Well, if you ever think of anything, please don't hesitate to reach out. If it's true that authors can have that reaction to that question, it's only because so many other authors have been like, "Fix this, it's broken." Or, "Please build that, I need it."

So, Matt, thank you very much for taking the time to be on the podcast today, and being so willing to go on the sort of somewhat meandering journey that I sometimes am taking people down. And thanks for being a Leanpub author.

Matt: Thank you for having me on.

Len: Thanks.

And as always, thanks to you for listening to this episode of the Frontmatter podcast. If you like what you heard, please rate and review it wherever you found it, and if you'd like to be a Leanpub author, please visit our website at leanpub.com.