Leanpub: Publish Early, Publish Often
An interview with Brian Marick
  • November 9th, 2017

Brian Marick, Author of An Outsider's Guide to Statically Typed Functional Programming

1 H 7 MIN
In this Episode

Brian Marick is the author of the Leanpub book An Outsider's Guide to Statically Typed Functional Programming. In this interview, Leanpub co-founder Len Epp talks with Brian about his background, the origns of both Agile and Waterfall programming practices, his book, and at the end, they talk a little bit about his experience as a self-published author.

This interview was recorded on June 2, 2017.

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.

A Note About the Leanpub Frontmatter Podcast

This summer we split the old Leanpub podcast into two distinct podcasts:

Frontmatter, which is a general interest podcast where you can listen to Leanpub authors talk with Leanpub co-founder Len Epp about their books and their areas of expertise, from data science to molecular biology, to the history of labor and management. And for those interested in the nitty-gritty of what it takes to be a successful self-published author, at the end of each episode Len asks the author about how they made their book and how they are spreading the word, and other publishing shop talk.

Backmatter, a new podcast focused specifically on the publishing industry and its latest trends. In each episode Len interviews a professional from the publishing world about their background and their insider's perspective on what's happening in the huge and evolving world of book publishing.


A Leanpub Frontmatter Podcast Interview with Brian Marick, Author of An Outsider's Guide to Statically Typed Functional Programming

Len: Hi I'm Len Epp from Leanpub, and in this podcast I'll be interviewing Brian Marick. Brian is a well-known software process and agile former consultant and programmer, and one of the original authors of the Agile Manifesto. Brian has written two conventionally published books with the Pragmatic Programmers, Everyday Scripting with Ruby and Programming Cocoa with Ruby.

An Outsider's Guide to Statically Typed Functional Programming by Brian Marick

He is also the author of a couple of Leanpub books, including one of our bestsellers, Functional Programming for the Object-Oriented Programmer, and his latest book, An Outsider's Guide to Statically Typed Functional Programming.

You can find out more about his work on his website at exampler.com, and you can follow him on Twitter @marick.

In this interview, we're going to talk about Brian's career, his interests, a little bit about Agile, and his work writing and publishing books.

So, thank you Brian for being on the Leanpub Podcast.

Brian: Thank you.

Len: I always like to start these interviews by asking people for their origin story. I was doing a little bit of research on you beforehand, and I was surprised to see that you are a former English major.

Brian: Yes. I graduated from the University of Illinois. I have two Bachelor's segrees from there, and then a later Master's. It turned out to be relatively easy to get both a degree in English and a degree in Math and Computer Science. So I got both.

The English degree has arguably been more useful. Not least because if - as I have at times in my career - gone up against people with PhDs, having only a Master's degree - when you only have a Master's degree, the pecking order is very clear. But when you tell them you are an English major, you have now become an interdisciplinary person, and are harder to put in a relative status position. So I try not to talk too much about the CS degrees. But that was really the main degree that I got. I was a computer programmer person from the beginning.

Len: And how did you first become interested in programming and in computers? What was your first experience with a computer, if you can recall?

Brian: I grew up in Illinois near a community college sort of place. At that time, there were no personal computers. This was 1976, and this college was on the PLATO computer-aided instruction network), which was an early graphical CAI type system that was networked across the country. On Saturday mornings, they would open it up so that people could use computers for what computers are good for - which is playing games.

So on Saturday mornings, I would go there and play games. And there was one particular game, Empire, which was the inspiration for X-Trek later. That was only available to programmers. So I wrangled my way into a programming job, so I could play this game, and I turned out to be pretty good at programming. I was also much better at programming than I was at my normal summer job, which was working for my dad building houses. So I took the programming job.

Later I went off to college to be an astronomer, and discovered I was in fact not smart enough to be an astronomer. So I went back to programming at the University of Illinois, which is more or less the area where I still am. Just down the street.

Len: And when you first started programming, what was the process like?

Brian: I worked for a chemistry professor, and he would say, as I recall, "Here are the quizzes and the answers for a mass spectrometry lab. Go and do something with it." And so I would go and do something with it.

Len: At the time, if you needed to learn something, how did you go about doing that? Go to the library and get books?

Brian: As an instructional system, there was a fair amount on the system about implementing itself. It was in a weird programming language called TUTOR, as in a learning tutor. They also had sort of a predecessor to USENIX newsgroups, what we might think of as things like Reddit or or Hacker News nowadays. So you could ask questions there. They also had a thing called, "Term Talk." In which there were actual consultants available, and you could essentially do text messages on the computer back and forth to them. They would usually be able to answer your questions, because that was their job.

Len: That's really interesting, I've never heard of that before.

Brian: It was a pretty forward-thinking system.

Len: And you moved on from there to be a professional programmer. Can you talk about what your first experience was like? I mean, for example, did you work for large companies or small companies?

Brian: I basically followed a friend of mine to a local start-up. This was 1981. They were a C Shop. They were putting PDP computers on the ARPANET at the time. They had the first implementation of TCP for the PDP-11. At one point, I've lost it since, but I had something called the ARPANET phone book, which was the name and address and phone number of everyone on the ARPANET, which later became the internet. It was about an and a half or so thick.

hat was my experience. I was a C Programmer doing networking protocol modules that were basically using PDP-11s as sidebar processors for big military Burroughs mainframes, which were overloaded, because in the event of nuclear war, there would be all sorts of problems with these machines crashing. So they were offloading some of the networking code onto the little sideboard processors. I wrote some of the modules that were never actually used, because we didn't have a nuclear war, as it turns out. So shucks.

Len: It's funny, just very much by coincidence, someone yesterday was just describing to me, as a metaphor for what the world is doing around Donald Trump now, how the internet was invented to be able to flow around problem areas. We might get to that a little bit later.

I would be remiss if I didn't ask you a question that often comes up on this podcast. Because a lot of Leanpub authors are people involved in software development and have various histories, one of the questions that often comes up is, if you were starting out now, would you go to university and study computer science, or would you pursue a different path?

Brian: I'm a big believer in the traditional liberal arts education - learning how to think, getting a lot of broad experience, meeting a lot of odd people. University of Illinois has 35,000-ish undergraduates. In my day, computer programmers were not the glamorous, romantic figures that they are now. They were the geeks and the nerds who got picked on in high school. And so it was very wonderful to go to college, and be able to find people like yourself. I'm not so much into vocational training. I like the traditional college.

Len: It's something I've reflected on a little bit myself, that especially people who may not have come from what might be described as a deprived social background, often miss about that some part of the value of university campus life is the broad range of people that you can meet, and then the acquaintances that you can have throughout your life, and friends of course.

It's one of the great secrets. It's a bit of a tacky thing to say, but it's one of the secrets to middle class existence that, if you end up in legal trouble, you can call your old lawyer friend from college. Or if you have a question about medicine, you can call your doctor friend. All these professions are actually don't seem alien or inaccessible, because you remember your awkward friend when they were 19 - long before they became the District Attorney, or something like that. There's all kinds of very practical things that one learns in that life, in that time.

So you worked professionally as a programmer in the 80s, and then you eventually transitioned to being a consultant. I was wondering if you could talk a little bit about what led you to make that change?

Brian: Somewhere along the line there, I had gotten - so, I have spent quite a lot of my life expressing alarm at things around me, or being a troublemaker. And this company was actually quite nice, in that, for whatever reason, the guy who ran it kind of liked troublemakers. So I was not squelched as much as often happens when you have this socially maladroit, loudmouth, obnoxious, programmer type wanting to fix everything.

But in any case, I complained about testing, and so was given the job of doing testing. Along the way, I wrote a code coverage tool in C. There was a modification of the new C compiler, and somewhere along the line - this company kept failing and being bought by larger companies, which then failed. The final company that failed was Motorola, which has since failed, and is now a part of Google - so sell your Google stock.

But I decided I didn't much care for Motorola, which was not a great company in a lot of ways to work with, and I conceived of the idea of trading some work for this code coverage tool, with the idea that I would open source it - because it was based on GCC, so it had to be open sourced - and I would make money off of consulting and payments to upgrade the tool.

So I was open source before open source was cool. In my first year of work, I made $500 - gross, not net, which was some concern as I recall for my mother-in-law, since I had recently gotten married and my daughter was a resident at the Vet School at Illinois. She didn't have any money, and here I was having traded in my well-paying job for this job where I made $500 net per year.

So that didn't work out, and I got into the training business, developing courses for, first tandem computer, and then anyone who needed a training course in testing, at first in black box testing for testers. Later in the mid-90s, there was a big xenophobic scare, that the Japanese were going to do to the software industry what they had done to the US car industry. So everybody was trying to import Japanese methods into software companies, and one of the important things that the Japanese did, and do, is emphasise catching the error as close to the point where it occurs as possible.

That turned into a real emphasis among managers that their programmers learn how to test. So I became a person who taught programmers how to test - fairly unsuccessfully, as it turns out. And when the first web boom happened, all the programmers who had been grudgingly forced to test - the balance of power now shifted, and nobody could tell programmers what to do, or else they'd go and move to a start-up. So that collapsed, and I went back to conventional testing, training and consulting and such.

Len: You said somewhere that you used to think of fencing as a good metaphor for testing, and you changed your mind to think that maybe dancing and the tango was a better analogy for that. Do I have that right? The reason it sort of struck me, and I may have misremembered it, is that the metaphor of fighting and testing has come up in my interviews with people in the past.

So with respect to testing and past concerns and controversies - what would you say is your reading of the state of affairs now? Has there been a rapprochement between testing and star programmers, or is there still a sense that one can't tell the programmer what to do?

Brian: I think the industry is now large enough, and has enough centres of gravity, that it's fairly hard to make a sweeping statement. There are certain programmer cultures - Ruby is one where programmer testing is a very big deal. It's just part of the daily job. There are others where it's not, and you still have the traditional antagonistic third-party testers throw it over the wall. I don't think I would make a generalisation or actually make much of a claim, to beat up on things.

Part of my reason for getting involved in Agile, as long as I was involved in Agile - and I think a reason that lots of Agile old-timers were involved in Agile- was they wanted to be able to get jobs working with people who liked to work the way they do. Once we achieved that, the rest of the world can go hang. So I'm not so concerned with how many parts of the industry do things.

Len: Moving on through the 80s and the 90s, now to the early 2000s - as I'm sure many people listening know, and as I said in the introduction, you were one of the original signatories to the manifesto for Agile software development, and I wanted to ask you a little bit about how that meeting came about? You said that it sounds like they were sort of coalescing - a sort of group of personalities who had similar interests and preferences.

Brian: Yes. I was something of a fringe figure. Having said that, from what I've heard other people say about the whole Agile manifesto meeting, is it's sort of a blind man and the elephant thing, where everybody who was there has a different recollection of really important things. In any case, I was involved because I was a graduate student of Ralph Johnson), who is a big Smalltalk person, and was one of the authors of the first Design Patterns book.

Design patterns largely came out of the Smalltalk community, midwifed by Kent Beck in his role midwifing all sorts of things. Design patterns was a big movement then, and has sort of fizzled since. Agile came out of the same community of people that were involved in design patterns. In particular, my interaction with that group was through Ralph Johnson's patterns reading group, where we would read and discuss patterns and books on patterns. Most notably, Martin Fowler's books.

Martin Fowler knew me as a disembodied voice on the other side of recordings of our discussions. He knew that I was the testing guy. And so when the manifesto meeting, the Snowbird workshop came together, he thought it would be a good idea to have somebody other than just a bunch of programmers there. He prevailed upon Bob Martin or Alistair Cockburn or someone to invite me, and so I was there as the token tester.

Len: When the meeting was convened, was there an intention to have an output like the [12-Point manifesto](http://agilemanifesto.org/principles.html? Or was that something that just grew out of the general discussion and purpose of the get-together?

Brian: My recollection - again, keeping in mind blind men and the elephant - was that there was a two-fold purpose for the manifesto meeting. One was to get together all of these people who clearly had development styles that had something in common, and were clearly distinct from, what was at the time, the respectable way to do software development. Get those people together and talk about what it was in fact that they had in common. I don't recall if there was an explicit goal to produce a document or a manifesto or anything like that.

The second of the purposes was to come up with a name. Because at the time, they were generally referred to as "lightweight methods", which doesn't sound very impressive. Who wants to be a lightweight? So the goal was to have another name. They picked "Agile." Who wouldn't want to be agile? Do you want to be torpid or sluggish? No, you want to be agile. So it was a marketing meeting, in part - and it came up with a really good marketing term.

Len: Amongst the principles in the manifesto, I wanted to single out one to talk to you about. It says: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

One of the reasons I found that striking was, when I first became involved in the tech start-up world, for a couple of reasons I ended up going to a couple of conferences with "Agile" in the name. I am not a programmer myself, and it was a whole new world to me.

It was an unconference, where people would propose panels, and then you would go. I went to all the ones where I thought I would get to listen to all the unhappiest people there, to get to understand what their problems were. There was just so much unhappiness that I encountered around people. You could tell it was because they were part of a management environment, where they were treated as interchangeable units to produce.

Was something like that part of the motivation behind that principle? Because the idea of building it around a motivated individual is quite the opposite of building a project around a manager who's going to treat individuals as interchangeable units to produce things according to a plan.

You referred to the old respectable way of doing things, which was called Waterfall, which maybe some people listening who are young programmers might not even have heard of. But I was wondering if you could talk a little bit about that? Was that part of the atmosphere? That you can get these really smart, really motivated people - and then they can end up as being treated as mere cogs in a larger managerial machine.

Brian: Yes. That was definitely part of the spirit of the age. I don't know that I have much else to say about that. A lot of the spirit of Agile does go back to the Smalltalk community. A surprising number of people who were at that meeting had experience with Smalltalk. The analogy that Ward Cunningham has used, is that it's shaping software in the way that a potter might shape clay.

That is very different from the conventional approach to software, which is executing a plan. It's very different from the conventional approach to software engineering, which was born out of defence contracting, where you have a traditionally very adversarial relationship between the customer and the producer: government versus company. The company is trying to do as little as they can to fulfil the terms of the contract, and the government is trying to be as precise as they can, so that the company can't weasel out of it.

And that infected everything. It infected the way testers reacted to programmers. It was very foreign from the whole Smalltalk experience, which came out of Xerox PARC, industrial research labs, not going according to plan. So, "yes" is what I have to say to that.

Len: Do you think there's something about the nature of the work of programming that can exacerbate a kind of adversarial relationship between a manager and a worker? For example, if you bring up defence contracting, you can imagine an executive putting on the hard hat and coming down to the shipyard and seeing progress being made week after week or month after month.

You can see the sparks flying from the welder. You can see the people milling about, lifting things and putting things down and pallets and things like that.

And you could imagine the same person walking into a room full of programmers. There's just a bunch of people sitting in front of desks. Maybe typing, maybe with their heads in their hand? Maybe on Hacker News or something like that? Do you think there's something inherent to the activity of programming that makes it difficult for certain kinds of management traditions to relate positively to?

Brian: That was in fact a key selling point of Agile - the frequent releases. In addition, the benefit to programmers is that we can't actually estimate worth a damn. For good reasons, I believe. But the fact is, we can't estimate worth a damn. And managers were in the situation of demanding estimates, because that was the only way they felt they had control.

What we promised was, "We will give you working software every month, every couple of weeks, that you can actually use and show. You get that. We promise you that if you decide halfway through the project that actually we've got all the features that you want, you can just stop then and ship what you have there and fire everyone else, and not finish the project" - which is very appealing to managers.

What we didn't promise is, "We no longer pretend to tell you exactly what kind of text editor you will have at the end of a year. But we do promise you that you will have the best text editor, the most fully-featured text editor, with the most important features that you can have with this team at the end of that year, we just can't tell you now what that will be. You get to do that, you get to know that, because we are going to let you tell us what the most important things are, and we will do those right away, rather than spending a year writing infrastructure before you can see anything." It's both a good way to develop things for most kinds of things, most kinds of software, and it was also a really powerful selling point.

Len: "What happened next?" is a question that a lot of people might want to know the answer to. So you have this meeting. You come up with the manifesto. And it eventually blew up, as they say, and became this huge thing and spawned entire kind of industries of literature and training. Can you maybe explain the moment when you realised this was going to turn into something quite popular?

Brian: There were two moments. One was, Ward Cunningham had the very clever idea of putting the manifesto up on a website, and allowing people to sign it. The sheer flood of people who signed it made it pretty clear that this was not just 15 or 17 people representing 15 or 17 teams that had this weird idea. It was speaking to both a frustration and a desire that lots of people had. So that was one thing.

And the other was something like - after not too many months, there was a write-up in the British business magazine The Economist. That's read by a lot of people who do not go signing manifestos on the internet of the day. All they were saying is, "Here's this interesting thing that happened." It was like a half-page bit. But that also indicated that it had some resonance, at least with people who had the job of being trendspotters for the kind of people who liked to see business trends.

Len: It's really interesting. By the time something gets into The Economist, the assumption is there's already momentum behind it, and it's been around for a while, I think. Which is part of the value it has for a lot of the, let's say, executive types who read it. Seeing it, they don't want to know about just something that happened. They want to know about something that's got some movement behind it. So there's this sort of irony that if you come across something for the first time in The Economist, you're way behind with respect to that thing.

Also, there's an implicit assurance that this thing has been around for some time, and we're not just surfacing the latest development to you. That's really interesting, I didn't know about that.

And so you then spent a few years working as a consultant on Agile-related training. Is that correct?

Brian: At first, I was Mr Agile Testing Guy, because I had been Mr Agile Testing Guy at that meeting. I did a fair amount of Agile testing and such. Later, it was apparent other people who were more in the trenches - like Lisa Crispin and Elizabeth Hendrickson and Janet Gregory - they had more practical experience. So I sort of yielded the crown to them and went back to essentially programmer and team coaching - teaching, sitting with people and pair programming and teaching TDD and refactoring and all these exotic new things.

Len: With respect to the technique or way of going about training and coaching, you talk about the importance of concrete examples. I was wondering if you could explain a little bit about what you mean by that?

Brian: That's always been my thing, examples. Part of it may date back to the 80s when I was a little bit interested in artificial intelligence, and was sort of struck by - there was a book by Pat Winston about, maybe, Lisp for artificial intelligence or something, nd he really stressed the importance of examples for learning algorithms.

To some extent, I refer to myself as a recovering abstractionist, which ties into the functional programming stuff as well, later. But when I was just getting started in programming, I was very much about specifications and abstractions. And I worked on a theorem prover, that you could prove the correctness of designs and such.

Somebody many years later gave me a copy of something I had written that said, "The specification is the only thing. The code is just like this thing, that once you get the specification right, of course the code is right." I gradually lost my belief in that. Partly it was through the AI stuff, partly it was because as a tester I found out how easily writing test cases or documentation for these well-thought out ideas revealed flaws in the ideas. And when documentation revealed it, it was often because, if you're writing API documentation, you want it for complicated API; you want to give examples of how to use it. And then you realise, "Oh, this thing doesn't make sense."

I also fell under the influence of bad companions in the philosophy of science, like Paul Feyerabend, and various philosophers of science, historians of science who've demonstrated that the way we're supposed to do science is this very rule driven, hypothesis-experiment thing - is in fact not the way science actually works. That made me question whether our fetish for abstraction was really the right thing. And the opposite of abstraction is concreteness examples.

Len: And when you say that's not how science really works, how does it really work? Are you saying it's in the lab and it's an on the ground kind of thing?

Brian: There are a lot of different ideas about how science works. Two things I can point to that are write-ups on my web page, on the exampler.com blog - somewhere in there, I wrote a series of posts which was about the philosopher/anthropologist of science, Bruno Latour. [This might be it: http://www.exampler.com/blog/2007/11/06/latour-table-of-contents/ - eds.] He has ideas about how science works.

The other person that had a fair amount of influence on me was Imre Lakatos, who - it'll be going way, way of track if I were to talk about it that much. But there's a blog post on there that's based on Lakatos [This could be it: http://www.exampler.com/old-blog/2003.1.html - eds.], and what he concluded from the history of science, about what really makes scientists stake their career on theories.

One of the examples that Lakatos uses is Newton, everybody's favourite great scientist. I'll cut to the chase. The way we're supposed to think about science is that somebody proposes a theory, and then people make predictions based on the theory. And if the predictions fail, then you're supposed to get a new theory. Lakatos points out that Newton very much didn't do that.

For example, in the Principia, he talks a lot about the orbits of the planets. But he doesn't talk about the orbit of the moon. There are a couple of reasons for that, but one of them is that for many years, his theory was inaccurate when predicting the orbit of the moon. That is because the moon's centre of mass isn't at the centre of the sphere, which throws things off. Mercury's orbit was known for a long time not to fit Newton; we needed Einstein to agree to figure that out.

The way Lakatos tells it, Newton made these predictions and various people said to him, "Sorry Isaac, your predictions don't actually work." Apparently the French Academy of Sciences, which had sort of a rivalry with the English, actually gave a prize for observations that would refute Newton's theory of gravitation. That prize was awarded numerous times over the decades. They finally gave up on that, when Edmund Halley used Newton's theory to predict the arrival of a comet to a very high degree of accuracy.

Among Lakatos' arguments about science is that it's not surviving a bunch of refutations that makes people believe in science, it's a dramatic confirmation. Like Einstein's general relativity. The dramatic confirmation was during a total eclipse, stars you can see - you can measure the bending of the light of the stars. I think that applies as well to software, to get back to the ostensible topic of this.

Which is that, for things like Agile, and for things like databases, it's not the detailed argument answering objections that makes MongoDB suddenly boom. It's that you can suddenly do something with MongoDB that you couldn't do before. The scalability bit. That's what I meant.

Len: That reminds me of a couple of things, one of which was Newton's interest in alchemy. I once came across a representation of that by a lecturer saying, "Looking back, with our Whiggish view of history, we are puzzled why would a scientist like Newton have been so interested in something that, to us, looks like superstition or magic." The point that was being made was that at the time, Newton was looking out in all kinds of directions, with all kinds of uncertainty in front of him, and it was partially his willingness to go down any path that seemed appealing that was part of what led to his successes, ultimately.

Just sort of riffing on the theme, it's easy to see things as methodical and systematic that aren't. So when you talk about a dramatic confirmation - this is an important thing. It's not necessarily in the dry study of calculation, or something like that, that big changes happen. They happen in a human context. Why people go down one path rather than another often has a lot of historical contingency to it as well, including things like national rivalry. What's the motivation there? Is it purely scientific, or is it the French and the English have always been at each other in various ways, and that there's all kinds of things motivating the activity that people undertake. That's a fascinating topic.

Since we're talking about science and developments over time - you brought up AI. It wasn't something that I knew you had experience or interest in. This is a topic that's in the news lately, with AlphaGo winning games against the world Go champion. In the news, we can read about what Elon Musk and Steven Hawking think about AI. But I've got you here, so what does Brian Marick think about the current state of AI? Are you on the side of it's something we should be worried about, or the side of something else?

Brian: Brian Marick is on the side of, "I don't know enough to have an informed opinion."

Len: That's a very fair answer.

Just following the story of your career, at a certain point, I believe it may have been in the early 2000s, you started writing books. I was wondering if you could talk about why what motivated you to start doing that?

Brian: Actually, the first book was published in 1994. It was *The Craft of Software Testing, and it was a book about programmer testing, which is, sadly, still available. I don't want anybody to read it, because it might have been okay at the time, but it's so incredibly out of date that it's embarrassing. It was at the Agile Manifesto meeting that I met Andy Hunt and Dave Thomas, who had recently published their book on Ruby. I got involved in Ruby as a result of that, when it was still a new thing to the English-speaking world.

I have been fairly involved in Ruby, and knowing a scripting language like Ruby is a really valuable thing. Even for testers who aren't diving into the code. But you can write all sorts of useful little scripts to help you in your testing work.

So because I was in the - at that time, there were a lot fewer, I think, programmer-capable testers - so I was encouraged to write a book on scripting for testers. And that was the first book that I wrote, through the Pragmatic Press. They later asked me to write a book on using Ruby to write Macintosh applications. Everything in my career, I sort of blundered into it.

Len: And did you find it enjoyable at first?

Brian: Yes. I have always been fairly good at writing, which was even more unusual than it is now among programmer-type people. I always enjoyed writing. So it was natural. And it was an English major's.

Len: And eventually you made your way to Leanpub, and self-published Functional Programming for the Object-Oriented Programmer. I was wondering if you could talk a little bit about that decision. Why did you decide to self-publish that project, rather than publish it through a conventional publishing route?

Brian: I had been doing Lisp in the early 80's during the big AI boom of around '82, '83. And in fact my experience with AI was because I was a Lisp implementer. I was one of the people who implemented what we would now call a virtual machine for a common Lisp for this extremely obscure brand of computer that no longer exists, from a company that no longer exists.

So I was in love with Lisp, and happened to stumble across Glen Vanderberg when I was visiting a company. We sat down and did some Clojure, and Clojure is Lisp, with a possibility of surviving. So I got fairly heavily involved in Clojure - not making any money from it, but just as a hobbyist.

I do not remember what provoked me to decide to write the book. It had something to do with not being happy with the existing books that were out there.

I picked Leanpub for two reasons. One was just as an experiment to try it out. And because I wasn't so sure this book would work out, if I did it on Leanpub, as opposed to signing a contract with the Pragmatic Bookshelf, I could just say, "I'm going to stop doing this book." So I did [it on Leanpub].

Also, that gave me control of my own schedule. I'm a relatively slow book writer, and that's awkward with a traditional publisher, because they want you to finish. And they're right to want you to finish. They need to have a pipeline of books. So this gave me the freedom to experiment with something that I didn't think would ever necessarily amount to much of a popular book, though it has turned out to be fairly popular.

Len: Did you publish it in progress?

Brian: Yes.

Len: What was that experience like? Did that help you get motivated, because you started having readers before you were finished? Were people contacting you asking, "When's the next chapter coming out?"

Brian: Not that I recall people commenting. I kind of suspect that a lot of people will buy the book just as a token of support, but not actually read it until it's pretty close to done.

It's sort of coming back to me now. I wanted to investigate certain things. That's why the book is somewhat flabby in the later parts - because I wanted to learn how can one actually understand and explain monads).

I have a habit - that was the case with the program-a-Mac-app-using-Ruby book, where I was learning - I didn't know how to do that. I was learning how to do it as I wrote the book. I was, to a lesser extent, learning some of the finer points of dynamic functional programming as I was writing the book.

That means that I do a lot of revision and rethinking things. And to some extent, publishing chapter by chapter is a little extra constraining. Because you don't want to go back to chapters you've already written and people have already read and say, "Oh now you have to read that again."

So I guess I'm not 100% sure about the costs and the benefits of publishing incrementally. I know that I'm not Charles Dickens, where you can publish an instalment of David Copperfield every month, and he must've had it plotted out in advance. I'm not a person who plots things out well in advance.

Len: It's a really interesting question around in-progress publishing. You're touching on something very interesting. at least to me, which is: what are the different implications for in-progress publishing of something that's prescriptive non-fiction, and something that's fiction?

For example, there are readers who really enjoy giving feedback to authors. If someone writes a chapter that's, "Learn how to use this," and they've got a mistake in it, or they go down a path they maybe shouldn't have gone down, then readers respond to them, and then they go back and rewrite it.

Then when they announce, "Hey, I've re-written chapter two," there actually is a subset of reader that's actually really excited to go back and read the rewritten chapter. If the changes are very kind of subtle, then people might feel a little bit cheated by having wasted their time on the first round. It's something that, as Leanpub carries on, we're seeing evolve in terms of reader expectation and author activity.

With respect to fiction publishing, definitely people just generally expect, when there's an instalment of a serially published novel, they don't expect chapter one to change later. I've actually got a novel where I'm doing that on purpose. To change things in accordance with changes in society. But that's a pretty obscure kind of art project.

One thing I can say about - well specifically, Dickens - is that one of the reasons that so many of those 19th century novels that we think of are so long, is that they started to succeed.

Len: If you see the circulation of your weekly or your monthly magazine going up, because everybody suddenly wants to know what Mr Pickwick's up to next, you might find that your plans for that novel change and grow. Sort of like how you might plan two seasons of something, but then everybody loves the zombies, so suddenly it's eight seasons or something like that.

You've got a new book out, and I wanted to give you a little bit of an opportunity to explain what that's about, and what motivated you to write that?

Brian: This is much more of a learning experience for me. I discover all sorts of holes in my understanding when I try to explain things to other people, whether those people are physical or imaginary - constant reader type-people. So I'm using this partly as a incredibly inefficient way to learn about the topic of statically typed functional programming.

The other reason for doing that is. I have been in the world of dynamically typed languages for a really long time. Lisp in the 80s, then C, which is statically typed, but it's not Haskell. Ruby - for such a long time. Clojure. I have never really put the statically typed languages to the test, partly because so much of the underlying philosophy is contrary to my underlying philosophy. I'm not so much a get-it-right-upfront person. Even though I was a math and computer science major, my thinking has gotten fuzzier and woollier and less clear cut over the years.

Which is partly just because I'm old, but partly because I've become less enamoured of artificial categories. Because the world is not clear cut. I've become enamoured in recent years of something that's called "embodied cognition" or, "ecological cognition," which is the study of how much organisms can actually accomplish while using as little brain as possible. Because brains are very expensive organs to have. So you want to minimise the use of brains as much as you can.

I've been interested in things like - something we mentioned before, tango as a metaphor for the way people - in particular, the following role in tango is a metaphor for how people solve problems in these various philosophy of sciencesthing. So, we have this field static typing, which tends to push in the opposite direction from where I am.

In the spirit of trying something new, not the same thing for the fifth time, really diving into it seemed like it would be educational for me. And then the other opportunity I saw in that, is I happen to know that a lot of people think like me and respond to the way I explain things, which is very different from the canonical way to teach statically typing. So there is a market niche, an unfilled market niche for somebody like me writing to people like me.

Also I started using Elm in my frontend work, because the JavaScript ecosystem and all that stuff is just way too much for me to want to learn. Elm - which is a statically typed programming language - is a simpler interface to all the complexity of the web ecosystem. I kind of like Elm, and it gives a nice platform to build on, rather than diving into one of these pedal-to-the-metal, statically typed, everything we know comes from category theory and mathematics types of languages.

Len: It sounds like a really interesting project and I really appreciate you telling us your story over time, including how your thoughts have become woollier over time. That was a really good description, I thought.

I guess our time is almost up here. The last question I'd like to ask you - and I'd like to prefix this by saying - some people just say, "I can't think of anything" - but if there were one thing, one feature you could ask us to build for you on Leanpub, something that you feel has been missing, or if there's something we could fix that you found annoying, what would you ask us to do?

Brian: I'd say I'm content. The only things that bother me are small things. I've never been able to get the programming language for this book to work, so all my code samples say,"Curly Brace language equals Elm at the top." But that's just, paste the thing you've already got stashed. So that's not actually a problem. I posted something about - I want more space after bulleted lists. But that's hardly earth shattering.

Off the top of my head, I can't think of anything large that I'm missing. With this book, I'm making it more of a web citizen, rather than, "Here's a source code repository, download everything." All the solutions to the exercises are clickable links to a wiki, so that people can talk about the solutions.

And with all that stuff, there's been - even though I don't think that was in the design intent, all of that stuff has just kind of worked the way you'd expect.

Len: Is communicating with readers something that you would like to do more, or have more opportunity to do? Is providing more community around the book, or around books, be something that would interest you?

Brian: It depends on how rushed I'm feeling at a particular time. I've generally found, I put my email address in the book, and people send me email. For whatever reason, perhaps I have some sort of hidden, some forbidding personality that's not apparent to me. But generally speaking, I don't get a lot of feedback on writing of any kind - books, blog posts.

I'm a good public speaker, and my talks are solicited by conferences. But it's always been sort of odd and a little bit disappointing that after the talk, people don't flood up and ask me questions. They sort of say, "Yeah, that was good," and then go somewhere else. So I am probably the wrong person to talk, because I am this sort of semi-hermit living in the middle of Illinois, bereft of all human contact. And apparently that's the way it is for me.

Len: It's definitely one of the things that is really great about being in the book world and publishing world, is all the different types of people that write books, and all the different approaches that they take and preferences that they have. I can say I appreciate the one you just described, myself, and I think quite a few of our authors do. Some people want as much feedback from everybody in any way that they can. Others wish they got less attention than they get sometimes. But it does take all kinds.

We're obviously very glad that you've chosen Leanpub as a platform for a couple of your writing projects. I just want to say personally, thank you very much for this interview. I really enjoyed it. In particular, your talk about science.

Thank you very much for taking the time to do the interview. And best wishes for your latest book.

Brian: Thank you. Best wishes for Leanpub.

Podcast info & credits
  • Published on November 9th, 2017
  • Interview by Len Epp on June 2nd, 2017
  • Transcribed by Alys McDonough