Larry Garfield, Author of Thinking Functionally in PHP

Len: Hi I'm Len Epp from Leanpub, and on this episode of the Frontmatter podcast I'll be interviewing Larry Garfield.

Based in Chicago, Larry is Director of Developer Experience for platform.sh, a platform-as-a-service company that helps teams build powerful modern web apps.

You can follow him on Twitter @Crell and check out his website at garfieldtech.com.

Larry is the author of the Leanpub book Thinking Functionally in PHP. In the book, Larry introduces readers to the basics of functional programming, the academic and theoretical computer science behind it, as well as discussing in particular the new capabilities related to functional programming in PHP 7.4.

In this interview, we’re going to talk about Larry's background and career, professional interests, his book, and at the end we'll talk about his experience using Leanpub to self-publish his book.

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

Larry: Hello world, good to be here.

Len: I always like to start these interviews by asking people for their origin story. So, I was wondering if you could tell us a little bit about where you grew up, and how you first became interested in computers and technology?

Larry: Well, first I was born. But that's going back quite a ways now. Born and raised in the Chicago area. I actually live now about a five minute drive from the house I grew up in. So I didn't go very far.

I first got interested in computers, I suppose around 12, 13, when we got our first PC. A 486 no-name, no-brand computer that didn't work right from day one. So someone had to figure out how to fix it, and that ended up being me. Kind of the standard story of the kid knows - the kid has to figure out the technology, because the parents don't.

Later on, I went to DePaul University for college, in human-computer interaction. Which - these days we'd call "usability" or "user experience." The names have shifted throughout time, but it's the same basic idea of, focusing on the user and making the user's experience with technology better.

And then also, I went to grad school in straight Computer Science. I finished wishing I'd done straight-up Software Engineering. So I went all the way across the spectrum from the soft skills over to hard skills, essentially. Although I hate those terms. We can get into that later.

Then I got a job. While in grad school, I worked as an IT journalist covering Palm OS and cellphones, if you remember that old thing. At the time I worked at infosyncworld.com, which in the early 2000s was the world's largest handheld and wireless news website.

Basically, there was a period when anything that came out for running Palm OS, I reviewed. And that was kind of fun, but there was no money in it.

So, I'd also been doing web development on the side, as a freelance consultant, working mostly for area politicians. I've been heavily involved in politics as well.

And then after I finished grad school, I started working with a local agency that did mostly non-profits - universities, museums, recycling companies - things like that, as a PHP developer.

I also got involved in the Drupal project. That's open source CMS written in PHP.

And about a year, year and a half after I started at the agency, we switched and became a Drupal shop. The degree to which, that was my doing - had always been a subject of some debate, and I was happy enough with it that I didn't really bother debating it.

Over time, I became one of the lead developers of Drupal itself. I led the big rewrites, that was Drupal 8. I was one of the lead architects of that. I have since stopped working with Drupal entirely, I'm separated from that.

About four years ago, I moved to my current company, Platform.sh, to work in developer relations.

Along the way, I also found that I really like teaching. I really like presenting. I really like conferences, that whole vibe - so I've become one of the regulars in the PHP circuit, at PHP conferences, and also some other conferences, and general language conferences. I think I've been at a JavaScript conference or two. The way I like to describe it is - I get to teach, but I don't have to grade papers, so -

Len: I've got a lot of questions about a lot of these different things, thanks for touching on so many different points. It's hard to capture a life in a two-minute spontaneous presentation. But I think you did a pretty good job sort of setting the stage there, which is really great.

One thing I wanted to ask you about, was - you say you got your start in computers by fixing a computer. I've interviewed people whose introduction to computers spanned many different generations. One person I interviewed for the podcast once, Jerry Weinberg - he was, himself, the first computer he ever worked with. He was from that generation.

So when you fixed the computer, what resources did you have available to do that?

Larry: Honestly, at the time my main - so, when I say "fix," that also includes "learn how to use DOS." We'd previously had a Commodore 64, which is a very different beast. A very good computer, but a different beast.

And frankly, my number one resource was the manager at the local electronics boutique. I don't remember his name, unfortunately, but he was a really nice guy, super helpful, always happy to answer rudimentary basic questions from this little 13 year old. And so we bought lots of software there, and lots of software books. It was a really good symbiotic relationship for a long time.

I also picked up a couple of books - as I mentioned, for what at the time was, "DOS For Dummies," or "Windows For Dummies," or other books along those lines.

I actually got into web development. Because I learned how to use Windows, the spec - in the Windows 3.1 days - my father's a college professor, or was. He taught at DePaul, and I was the kid who came in and fixed everyone's computer there. "Fixed" meaning, I knew how to reorganize the icons in Windows. All things are relative here.

And so when the department was told by the university that they had to put together a department website for this new thing that's come out called "the web," they just - "We'll just have Larry do it." And so my dad came home and said, "Larry, do you know anything about building web pages?" I was like, "No, but give me a bit and I'll learn."

And so I picked up a copy of "Creating Cool Web Pages with HTML 1.2," or something like that, as the title. And read it in one sitting and got started, and I'm very happy to say that first site is no longer online. It's for the best. But that's how I got started in web development too, was just the plucky little kid who everyone trusted to deal with that computer stuff.

Len: Thanks very much for sharing that. That's such a great story. I've heard a few versions of that before, including one where there was a city administration that had a server room that - I'm putting it in quotes - "broke," was about as specific as they could be about what was wrong. And they got a couple of teenage kids whose parents worked in the library or something like that, to - I'm getting it all wrong, but it was some version of that.

And it's really interesting too, to think about the different types of skills that are required for solving various kinds of problems, or learning various kinds of things, and how those have evolved over time.

I know that you mentioned that you're interested in teaching, just in general. And in the days when you didn't have the World Wide Web to go to really, for solutions - there was no Stack Overflow, there weren't things like that. I'm not saying it was - the world that we live in presents us with many challenges constantly evolving. It's not like it was harder in some objective way in the past. But it was just a different kind of challenge, to try and find solutions to things. And often the book in the bookstore - the one book the bookstore had, was the resource that you used. So then after that, it was off to the races.

Larry: Yeah. I don't think it's necessarily easier or harder.

I mean, back in the 90s, you had fewer resources that you could access when you needed them. But there was also a lot less going on.

I could learn to build a website by picking up one book, reading it in one sitting, and cranking out some HTML tags and a text file.

These days, doing serious web development - you're writing in four different languages, with three different layers of compiler, and version control - and that's the barrier, that's the ground floor.

I kind of feel bad for people trying to get into web development these days. Because at the entry level, you need to know HTML, CSS, SQL, JavaScript - and one of four different background languages, at least - before you're even useful.

And then there's the giant tool chain that each of those have. Which is, in some cases, terrible. The barrier to entry now, I think, has gone up faster than the available resources to deal with it.

Len: That's a really interesting observation. One question that actually often comes up on this podcast, that I like to ask people - because people that I interview who are into programming and tech come from so many different directions, and end up in so many different places. One thing I like to ask them is - if you were starting out now - say you were 18 years old, you've just graduated high school. I mean, bracketing the specific circumstances of the "now" that we're in, which we'll talk about a little bit later - but if you were in a conventional "now" and you were starting out, intending to have a career in tech, would you advise yourself to do a full Computer Science degree at a university, and specifically in the United States, or not?

Larry: That's really tricky. There are definite advantages to a good Computer Science program. I think we, as an industry, spend far too much time ignoring the extensive lessons of the past. A lot of the presentations I give and a lot of the writing I do is based on - this is an industry that wasn't invented 10 years ago. And if you want to be good at it, you need to understand that a lot of these problems were solved in the 60s - and we're still resolving them, because no one pays attention to the history. And you're not going to get the history if you come in kind of sideways.

On the other hand, some of the best developers I know are people who didn't go to school, or didn't go to school for programming. They just picked up a text editor and started cranking stuff out, and searching online. And failing the first few thousand times, and stuck with it, and learned that way.

Honestly, I would take someone with four years' experience, over someone with a four year degree. I'll take someone who has both over someone who has either. But between the two, I'd rather someone who has four years real experience developing software, than someone with a four year degree in it. There's no substitute for getting your hands dirty and failing a couple of times.

One of the things I tell anyone just getting into programming, whether they're in a school program or not, is: "Your first 100,000 lines of code are going to suck. Doesn't matter how smart you are. Doesn't matter what language you're writing in. Doesn't matter what your background is - what your various ethnicities or gender or whatever are, your first 100,000 lines are going to suck."

It just takes that long to train your brain to think in a computer-y kind of way. And you just need to get through that 100,000 lines as quickly as possible, before you really start to understand what you're doing.

Len: It's really interesting. I'm Leanpub's resident non-programmer. I do do some programming, and I have to be familiar with all kinds of programming concepts and stuff like that - and I've been fortunate enough to learn from so many interesting people reading their books and interviewing them for this podcast, in fact - but I have a bit of a background in investment banking. And so that involved making pretty complex financial models in Excel.

I didn't know until after that I was programming. And so, there were lots of things I was doing. Like I learnt the MOD function. It wasn't until like literally last year, that I learned that was something from math, that I learned.

I guess what I'm getting at is like, the challenges that you're faced with as a programmer - like, "Go solve this problem, go build this thing," require constant engagement with learning new things. Like you said - many different languages, many different frameworks. Stuff like that.

And so, after a few years - even if you don't necessarily - and this isn't an answer to the question that I asked, necessarily - but even if you don't necessarily have the names of the theories, or you have a theoretical background, you will have faced the challenges of having to understand the concepts at some point.

Larry: Yeah. And just jumping ahead a little bit, advanced spreadsheet development is functional programming. So congratulations, you're a functional programmer.

Len: We'll be definitely talking about functional programming going forward, but sorry to sort of hijack the conversation there.

Going back to you - you mentioned you were reviewing Palm OS devices around the turn of the millennium. That was an exciting time for technology, not that it isn't always. But, so - what was that experience like? Were you getting cool devices in the mail all the time?

Larry: Yes.

Len: And then writing reports on them? If you could just set the context a little bit - rhere are people listening to this podcast who would not have been alive at that time. What was the Palm device?

Larry: So the Palm OS devices -

Len: Or range of products, yeah.

Larry: Yeah. It was the first actually successful handheld computer. There were a few models before that, like the Apple Newton, that went absolutely nowhere.

The Palm Pilot was the first one that was actually commercially successful, and had an ecosystem around it, and had a very long and complicated and sordid history of the company breaking up into pieces and re-emerging again, and licensing and not licensing. That's a whole other podcast, and a book into itself actually - that I have read, I didn't write.

During its height, the Palm OS had devices from Palm, from Handspring, from HandEra, from Sony, from a couple of other companies, including the first combined PDA, personal digital assistant/cellphone/pager. It was doing the kind of stuff that we now do with smart phones 15 years ago. 10 years before the iPhone, it was already moving in that direction.

And, so for a time, every week I'd have some new Palm device or some new accessory or some cellphone that showed up at my apartment. And I would put it through the paces, test it, run some software on it - and write a review on that for our website.

I also was reviewing software as well. For a while I ran the news desk for the company. So it was a lot of, "Here's what's going on in this nascent industry." I also worked briefly at a company doing Palm OS development, writing code for the Palm. That blissfully didn't last long. That was a terrible company. Nothing wrong with the Palm, just the company itself was a terrible place to be. So I'm glad I did not last long there.

Len: It's really interesting, the story of these handheld computing devices. Often the concept of ereaders comes up on this podcast, for obvious reasons. And there's this weird thing, where they started coming out in the very late 90s - and then kind of went away, until right around 2007, 2008 - when the Kindle came out. That's a very short version of a big story. But the Palm OS devices that you're talking about - they didn't have keyboards, typically, if I recall correctly. They had a screen -

Larry: There were one or two that did, most did not.

Len: Okay - they had a screen and typically you interacted with a stylus, right? Like a little kind of pen.

Larry: Yeah.

Len: That you drew on there. Why did that go away for a time, instead of just kind of evolving into the iPhone? Which, as people would often think, just sort of came out of nowhere. But in fact, it was just that there had been a few years of these other type - these sort of screens going away.

Larry: So it's not that they went away, per se. On ebook readers in particular, dedicated ebook readers in the late 90s, early 2000s, were needlessly expensive. And when you already had a three, four hundred dollar PDA - with just as good a screen, why have a separate ebook reader? I read hundreds of books on my Palms. Various kinds. Greyscale screens, color screens and so on. So the ebook market was alive and well on those devices.

The thing that changed with Kindle, was the technology got cheap enough that building a dedicated ebook reader, became commercially viable. And it also helped that Amazon was big enough, that they could subsidize the cost. So you were never paying the actual cost anyway. They sold those things at a loss.

Handhelds in general - Palm stagnated as a company for a lot of reasons. Some technological, some just business stupidity. Which, again, that's a whole other topic, I won't get into here. But I got to watch it up close and personal.

They also, during that time, slowly got taken over by Pocket PC - which was later called the "Windows Mobile."

They changed names about four times. Which had a number of advantages over Palm, in terms of its hardware. But its software, was, honestly, not as good. It was not as well-suited.

But Palm was not advancing, and so Windows devices kind of took over in the mobile space. And then Steve Jobs came back to Apple, and decided to build a personal media device.

The iPhone 1 was originally supposed to be a video player. It was an advanced version of the iPod. And in the development of it, they realized, "It would be useful if we could put a wireless radio in this thing - not just populated locally, but also have a Wi-Fi connection and a cellphone connection that makes a nice add-on feature for the media player. And oh, by the way - as long as we've got that connection, we might as well put phone capability in it."

The cellphone side of it was always an afterthought. But that meant they could then brand it as a phone. I was not directly involved in that, but that's my understanding of that development. And then, the Steve Jobs reality distortion field took over, and suddenly Apple decided that smartphones were ready, even though they're not phones - they're handheld computers that happen to have voice capability. And it had the blessing of the Steve - and therefore now it is an arbitrary technology, and it took off.

So a lot of that history is not the technology, it is simply the personalities and the marketing and that side of the industry, which is always way more important than people give it credit for.

Len: Thanks for explaining that. There was a lot in there that I actually wasn't aware of. I've always had a kind of like really simple pub table theory about it, which is that people have a kind of superstition about computers.

You mentioned the Palm was a PDA, that was a personal digital assistant. And so in people's minds, when something's marketed that way, it's like, "Oh, it's a computer. Oh dammit, I'm going to have to figure it out. That's really complicated."

There's a great tech writer for the BBC, who said that he once told his mother that her remote control was a computer - and she stopped using it.

Qhen iPods came out, if anyone remembers those? It was a music player, not a computer. And so when the Kindle came out, it was an ebook reader, not a computer - even though it was a computer. It even had a keyboard and an internet connection and stuff like that.

And then, when the iPhone came out, we were buying a phone. Just a phone with more capability, was the way people understood it. You bought it in the phone store. Things like that. And I think that - anyway, that's always been my pub table theory, which is sort of touching on the more complex story that you told, for why there was this explosion around the time the iPhone was launched.

Larry: That's no doubt a factor as well. Branding matters so much. I mean, no one buys cars anymore - they buy computers with wheels. But if you marketed them as a computer with wheels, no one would buy them.

Len: Definitely.

I'm looking forward to talking to you about your role at Platform.sh, and about conferences as well, because I know you've not only spoken at many, but you've also done some conference organizing in the past. And there's something interesting about our current moment to touch on there.

But before we do that, I want to do a total digression into blacksmithing. Just to get to know a little bit better, we'll just take a few minutes to talk about that. So how did you get into blacksmithing?

Larry: Oh dear. A couple of years ago, I fell down the YouTube rabbit hole for medieval arms and armor, which has a couple of really good channels in it. And after a while, I guess it would have been summer three years ago now? So summer 2017. A friend of mine, who's now my girlfriend, said, "Larry, there's this [?] nearby for a place that does bladesmithing. So go do a one short class, just to try stuff out."

I'm like, "Er, I don't know." Like, "Larry, go try." "Oh fine." I tried it. "Okay, it might be interesting." They've got classes and, okay, they're actually not that expensive for what you're getting. So alright, I'll try it and, coming up on three years later, I've made a bunch of knives, and I have a growing workshop in a spare bedroom at my house.

And that has branched out, because if you're making knives, then you're making not just the steel for it, you're also making the handle and a scabbard. So there's woodworking and there's leatherworking involved.

I'm currently working on building up my woodworking gear and some leatherworking gear. And, yeah, I'm turning into a full medievalist here. It's the only non-digital thing I do.

It's nice to exercise a completely different part of my brain, and to spend some time banging on the hot piece of metal, to get it into shape with no technology anywhere. It's me, a hammer, and a pencil. And an anvil, stuff like that. Or carving a piece of wood against a belt sander or with a file, or hammering in leather to get it into the scabbard shape, or something like that. It's just a completely different head space than what I'm used to.

I think it's really healthy for anyone in technology to have some completely non-technology, non-digital thing that they do as a hobby. Whatever it is. For me, it's bladesmithing. For other people, it could be knitting, jewelry-making, woodworking, sports, music. Just something to exercise a different part of your brain - that is, I think, very healthy.

I also, more recently, have started taking classes in fencing. I was taking a class on European longsword - which I finished shortly before the coronavirus lockdown started, so I haven't been able to continue with that. But yeah, it's something physical, something different than everything else I do. And I like that. It's a way to create in a different area.

Len: Thanks very much for sharing all that, and for being willing to go down a little bit of a digression. I have always been into - not into making, but into knives. And so when I was researching for this interview and I came across your YouTube channel, and I was like, "Oh wow, I get to watch knife videos for my job now." That was fun.

Larry: I've started actually collecting them too.

Len: Oh my.

Larry: So when I've been travelling for conferences, the last couple, I'm like, "Alright, I'm in Venice, is there a Venetian style of knife? I'll go buy one." Stuff like that. So, yeah, it's a hobby that can take over.

Len: I smuggled a butterfly knife in an Indian vase home from a European trip once, when I was 19 years old or 20 years old. They're illegal in Canada. And I thought, "Maybe if I hide it in this vase I got in India?" But I did buy the knife in Italy.

Anyway, sorry, I could talk about this for a long time. But yeah, knives are a thing you can really get into. I imagine blacksmithing is something you can really get into.

But yes, that advice about - if you're like mostly a deskbound digital person, I think almost all of us do actually just naturally find that we have something else in our lives that we do. For me, it's martial arts and things like that. It's really great to have other things to do. Particularly now, especially if you're lucky enough to be able to do them at home.

And so getting back more onto the main track of the conversation - the novel coronavirus and COVID-19 are things that have affected all of us. I'm going to ask you specifically about conferences in just a moment. But one of the privileges of this podcast is we get to talk to authors from all around the world and find out what's going on where they live. How have things gone in Chicago?

Larry: Chicago's still locked down. The State is working on figuring out how we can open, and open in pieces. Kind of the irony for me is, I work from home anyway. And despite the conferences, despite the presentations - I'm an introvert. So my life hasn't changed dramatically. I don't go to dinner with my parents regularly anymore. And I can't go to the forge to do the hot work.

But my routine day is still - get up, commute down the hall to my home office, sit at my computer, do my job - get up to go downstairs to make lunch, and so on. So in many ways, I've been one of the people least hit right now. Which is in some ways nice, and some ways there's survivor's guilt. So I'm trying to stay home, save lives, order from restaurants where I can, tip extremely well - that kind of stuff.

But a lot of it is - I do have friends who have been laid off or furloughed, and a lot of it just comes down to - we can get through this, if we all just get with the program and socially distance and wear masks, and all that kind of stuff. A lot can reopen, it's just a matter of convincing people of that, so - and we're recording this on a video, even though I guess listeners can't see this - so you can see I'm really overdue for a haircut. Those kind of things. Could be worse.

Len: Me too. One thingm just anecdotally - by the way, we time stamp these episodes now - I say ominously, "This interview was recorded on blah blah date" at the beginning of all these interviews. Because they do take sometimes up to a month to come out, and things are changing so rapidly. But one thing, just anecdotally, that I've been noticing, is actual, permanent closures of local businesses. So when I go for my occasional socially-distanced walk, I do see that happening. Have you been seeing that happen in your neighborhood?

Larry: I haven't been out and about much. So, not much. Although, I'm sure we are going to lose some. I believe there are a couple of restaurants that have closed down. There's one I believe that's taking the opportunity to do a lot of renovating, which makes sense. But not all of the businesses are going to get through this.

I think in the end, it comes down to - a lot of them could open, if we do it right. It's a matter of doing it right. And making sure we still support those that can't do it right, just because of the nature of their business. I could easily get off on a digression there about systemic failures in this country to deal with the coronavirus, but that's off-topic.

Len: Well, we could make that on topic, if you wanted to. But we don't have to. In fact, that would actually - that would make a great, another podcast, I suppose. But we should probably try and stick on track. It's just always so tempting in these conversations to do that. But if -

Larry: I'll say - I've been involved in politics as well, for a long time. I worked on a number of campaigns. Right now, I'm working with FairVote Illinois, hich is pushing for ranked-choice voting in Illinois. And now we're also looking at, "Can we get the state to commit to vote by mail for the fall?" We are already a no-fault absentee state, which is good. But we need to go further.

And every State [should] commit to universal vote by mail, as soon as possible. Not doing so is - I'm not going to go as far as say "criminal," but certainly immoral and irresponsible. And politicians who are blocking vote by mail, have no business being in office - regardless of party. I'll stop there.

Len: Okay. Yeah, we could talk about that for a long time. And in fact, a lot of people are talking about this. If you're interested in Larry's politics, check out his Twitter feed at @crell.

Larry: Lots of it there.

Len: There's lots of it there, and it's - there's nothing being hidden about his political commitments, because he's committed to politics. And it's a really interesting Twitter feed to follow.

So specifically, with respect to things that are changing in people's professions - perhaps things we can talk about that with politics aside, although I do love -

Larry: Nice segue there.

Len: That's a segue - one thing is, conferences. So not too long ago, I interviewed someone named Kyle Simpson - who you can follow on Twitter @getify - for this podcast. And he talked very movingly about how, although he does a lot of conference speaking, or he did a lot of conference speaking - particularly, his business, in addition to self-publishing books and teaching people through things like Frontend Masters and stuff like that, with screencasts - was in-person consulting. So, being paid by a company to come to a company and talk to them. That has collapsed, and might not be coming back as a practice, as something that companies spend a lot of money on.

So conferences - I know you've done a lot of work about conferences, you've even written about things like diversity at conferences, and things like that. And one thing that actually has come up on this podcast before, is O'Reilly closed their in-person conference business permanently, relatively quickly, actually. Which I took as an ominous sign for conferences, because they're pretty smart cookies at O'Reilly. What do you think is going to happen with in-person tech conferences in the near term?

Larry: In the near term, I've kind of written off 2020 for in-person conferences. I know of one or two that are still trying to have an in-person conference sometime this year. But I honestly don't have my hopes up. The ones that are going online or switching to like user groups that are calling in remote people, I think is much more promising in the near term. Long term, I suspect some will come back - but not all of them.

In many ways, there was already a surplus of conferences - a lot of the conference organizers I know, many of them were having trouble getting sponsors and getting attendees, in part, because certain markets just are so oversaturated, especially in North America. And not all of them are going to come back. It was a market that was due to have some shakeout. It's kind of unfortunate that they shook out this way.

But yeah, in-person conferences are not going to go away entirely, but I think they are going to be reduced for a long time. The irony of course being, that I managed to get gold status on my airline this year.

Len: Oh my.

Larry: Just barely. So of course, I can't use it this year, so - you can blame me. The last time I had managed to get gold status, something else blew up, and I had to cancel a bunch of conferences. So, yeah - I just need to not get gold status with airlines, that's all there is to it.

Len: I hope you don't mean literally blew up.

Larry: No, but it was - there's a reason why I'm not involved in Drupal anymore, let's just leave it at that.

Len: Okay, got it. So on that somewhat dour note, but with some hopefulness that in-person conferences and in-person consulting and things like that really do have some value, and eventually we may - the world has experienced plagues and things before, and has not necessarily come back to where it was before, but emerged sometimes in an even better place, eventually.

Moving on to - so you say, you work from home, and you work for a company called Platform.sh. You're Director of Developer Experience there, and I was wondering if you could talk a little bit about what the company does, and what you do as a Director of Developer Experience?

Larry: So platform.sh is a cloud hosting platform as a service. The basic idea - for the developers in the room - for the non-developers, you may not understand this. I'll try to make it understandable.

Any website these days, or web application, includes its own source code. Plus it includes configuration for, "I need this kind of database. I need this kind of search index. I need this ancillary service. I need this ancillary service."

And managing all of those is a pain in the butt. So what we offer, is - your source code goes into version control. We use Git as does most the tech industry at this point. Along with instructions declaratively for, "I need a [?] post that has SQL database. I need Elasticsearch. I need Redis for caching," and so on, "And in appropriate configuration."

You push that to your Git repository that's hosted with us, and we spin up an environment built out of your application code - which could be PHP, Python, Ruby, Node, Java, Lisp. We just launched Elixir support. I feel like I'm missing one in there - Go. That was it, Go. We're very multilingual. So yeah, that application - plus the database you specify, the version you specified - and so forth. And that's now a full-running cluster, using container technology for your website.

If you make a branch - that's an alternate copy of your code base - and push that as well, you get a separate copy of your complete site. And then we can do a copy on the right/underwrite clone of your production data.

The long and short of it is - you have your website running, you want to experiment with it. You push a button, and two minutes later, you have a complete copy of everything. Code, database, uploaded files - everything, in roughly constant time.

And you can experiment with it. Try new code, try different configuration, change your branding - and that's a completely separate environment that you can then show to your customers, show to your manager, show to your stakeholders, and iterate on that, and you can have any number of those at the same time.

So I can be working on changing the color scheme in this branch, in this environment - and completely separate from me, someone is working on improvements to the single sign-on functionality. We can both have our own complete environments with all of the production data - without bumping into each other.

And then when either of those gets approved and it's ready to go live, we just do a simple Git merge back into the production environment. That redeploys with a new code. All the data's still there. And so you have enormous freedom to run your site and experiment with it safely, in an environment that is as identical to production as it is possible to get.

In the devops world, the hosting world, you always want your testing environment and your production environment to be as close as possible. We offer as close as possible. Because you're running exactly the same code, exactly the same configuration. The only difference is the amount of CQ and RAM, the amount of resources that we throw to the environments. Because a test environment is going to have one or two users, instead of one or two thousand users. So that's what we do, in a nutshell.

Director of Developer Experience is the fancy way of saying, "I'm the senior member of the Developer Relations team." Developer Relations is a kind of squishy field. It's part development, part marketing, part customer service, part outreach. It's kind of a glue role.

Some people in the developer experience, or in the developer relations, field, refer to it as "the avocado." Which is good fat - it's a fat, but it's good fat. So it's good for you. And the word "avocado" in French is "avocat." Which is the same as the word for "advocate." So it lines up that way. I can't remember the name of the woman offhand who coined that phrase. I wish I could, because it's a great phrase. But if I remember, I'll give it to you for show notes. [It's Mary Thengvall - eds.]

Len: It also means "lawyer" in French.

Larry: Yeah. Well, like I try not to be that. That's my brother. My brother's the lawyer. It's a very eclectic role.

Len: Yeah, does this mean that, for example, if a developer is having some kind of basic - I shouldn't say "basic" - but like if a developer's having a problem with their like project manager, they come to you? Or if they have a proposal for how to change a process or something like that, you're the conduit to people who make decisions?

Larry: Not as such. It varies a lot, depending on the company. At platform it's a mixture of blogging, conferences. We're responsible for the documentation for the product. So if any time we roll out a new feature, we're the ones writing the documentation for it. Some user support. Like the user comes into our support channel, or discussion channel, asking, "Hey, how do I do x, y, z?"

And we're like, "Oh that's this thing over here. Here's the link to the docs." Or, "Hmm, I don't know, let's figure it out and then put it in the docs." Or things like that.

We've recently started our own webinar series, called "Deploy Friday." Which is kind of our slogan - "You should have enough confidence in your deployment process, that you can deploy on Friday." And that's what we aim to offer.

Most of the time I'm not doing any engineering on the product itself. But we are responsible for maintaining templates. We have a number of open source projects that we host templates for, s you can just push a button and get WordPress running, or get the Symfony framework running or Ruby on Rails or Express or Nextcloud, or various other applications. We are responsible for maintaining those, as well as some user support libraries.

My background is primarily PHP, but at Platform, I'm writing code in PHP, in Python, in JavaScript, in Go. I haven't done Java yet, but there's someone on my team who does a lot of Java. He's big in the Java space.

So it's a very eclectic type of role, where you have to really be leveraging both solid technical skills, and solid people skills.

The people skills are often the harder ones. Despite the fact they usually get called "soft skills," the people skills are the hard ones, and the more important ones.

Len: You signaled that you were maybe interested in talking a little bit about that at the beginning of the interview, about the distinction between soft skills and hard skills, and how you actually view that. It reminds me of - there's a concept from philosophy, there's a philosopher named Hegel, who sort of inverts the significance of abstract versus concrete. Where the concept we have of what's concrete is actually what's abstract. And anyway, it's just an interesting way of inverting it, so that like soft skills are actually like the harder, the harder things - I think, is kind of what you're saying.

Larry: I think the naming comes from - programming is a lot easier to quantify. The tests pass or they don't. The code is faster than this threshold, or it's not. So it's hard and concrete in that sense. Whereas, people skills or management skills or communication skills or writing skills are a lot harder to quantify. It's a lot squishier. So they get called "softs" because you can't throw them in a spreadsheet as easily. Which really does them a disservice.

Because it doesn't matter how fast your code is, if it's not doing the right thing. And if you want to figure out what the right thing is, you have to talk to humans. And if you want to talk to humans, you have to be able to communicate effectively with humans. And communicating effectively with humans, as we've all figured out right now - can be extremely hard, even if everyone is being honest and making a decent attempt at communicating - which is not always the case.

So I often - I like that conference talks are on hard topics, but I think the human interaction of conference talks, the human interaction of connecting with people, the human interaction of learning how to communicate with some new person about something, of getting practice organizing things and managing things, is more valuable in many ways. Because you can learn programming on your own from a book or a website and a text editor, and eventually you'll figure it out.

You can't learn how to ask intelligent questions without other people. You can't learn how to read between the lines and figure out, "Okay, they say they want x, but they really want y - they just don't understand the difference between x and y." Which is like every consultant's life, all the time. You're not going to get that skill without doing it and interacting with people.

And almost no program of consequence anymore is written by a single person. They may be started by a single person, but the big ones always have multiple people involved.

And if you're kind of a jerk, and people don't want to work with you, then it's going to hurt the project, it's going to hurt your career, it's going to hurt the people around you. There are certainly companies that succeed with jerks on their payroll. But that's very much in spite of, rather than because of.

There is a threshold, there is a balance point of, how much discomfort is person's contribution worth to put up with? But it's very heavily weighted towards, "If I don't want to work with them, the team is going to suffer as a result." And that's true, whether it's a company or an open source project, or a conference organizing team. And again, learning how to interact and not be a jerk, you need to practice with other humans to do that. That's hard, and that takes time.

Len: This is a topic, I think we probably could talk about for a really long time as well.

Larry: Oh yeah.

Len: One interesting feature of the current situation - I'm going to ask you a specific question in just a moment, but just to make a sort of hopefully funny observation. One interesting feature of remote work, which many companies are now adopting for the first time, is that some of the - I'll call them "neutral qualities," that can help you advance in certain corporate environments, seem to be - I'll say "cancelled," when you're working remotely.

So for example, being tall. Having a strong chin. Having a confident bearing, or a aggressive body language, are things that can in many environments, can be the necessary and sufficient conditions for advancement in a career. And I don't say that cynically, I say that from having seen it.

Larry: A lot of that is there for a reason. I mean, we don't like to admit it, but we are barely removed from the jungle, metaphorically speaking. And we don't like to talk about or admit the degree to which humans have a lot of ingrained, built in assumptions about what makes a good leader, what makes a good mate, what makes a good friend, what makes a good person to hang around?

That were reasonable filters 10,000, 20,000 years ago. And the person who is big and strong and tough and can break somebody else, is someone you want on your side - even if they are kind of a jerk to be around. When other humans are separated into "people who will help me get lunch," and "people who'll steal my lunch." You want the big, strong guy to be on your side, so he'll help you get lunch, rather than steal your lunch.

That's not quite the way things work anymore. It's a lot more complicated. The skills that lead to actual success are different when success is defined by a stable revenue and happy customers, rather than ability to kill the tiger before it kills you. But our brains are still sitting there looking for the person who can kill the tiger. Which is not always a good thing.

But we can't pretend that that's not there. Our brains have a lot more hard-wiring than we want to admit. And yeah, taking away some of those contextual cues, like, "Oh, like I am forced to listen to someone's words now, rather than their body language." And therefore, the body language advantage goes away, now what do I do? And it's interesting.

Len: I should qualify this, by saying neither Larry nor I are against big guys. Nothing against -

Larry: Some of my best friends are big guys.

Len: I like to think I'm a pretty big tough guy, but what we're speaking to is there are some kind of - I mean, in economics they talk about externalities or something like that. I'm just using that metaphorically, by the way. But like, there are things that can, from a certain perspective, appear to be - in architecture, there's the term, "spandrel," I guess? I'm remembering Stephen Jay Gould writing about this years ago. But there are things that can appear in an evolutionary process that, from a certain perspective, do not appear to be kind of necessary for the system itself to perpetuate itself and to succeed.

And it can be frustrating to see these things in a corporate environment, advance someone's career and put them in a position of authority. From that perspective that I'm describing, it looks like they don't deserve it. And being a big tough guy is in no way disqualifying you from actually having all the other really awesome qualities that are required to be really good at a job. So now I've gone on at length, defending big guys. But -

Larry: But the idea is that there's - there's a lot of things we look for as proxies. Like we look for this attribute in something, because we associate that attribute with this other attribute we want to have - either we've learned or we have an innate biological drive to assume that A implies B. And in some contexts, A does kind of imply B. In hunter-gatherer environments, physical strength can imply leadership, or it can be a good proxy for it.

In a modern world, it's a very terrible proxy. There's no correlation anymore, but our brains are still wired to assume that correlation. That doesn't mean our brains are wrong. It also doesn't mean we should ignore or pretend that that correlation isn't built into our brains. We just need to be aware of all these logical fallacies that we have, that humans are prone to - are there for a reason. That reason is just kind of vestigial, and now we have to deal with that. Now what?

That's, again, a whole other podcast we could down there.

Len: With respect to that - before we got down this rabbit hole, I promised a specific question.

So, we recently hired some co-op students for the summer. Our co-op program - for those who don't know, is a program in university where you're doing a full university degree, but you're required to take terms off from university to work at companies - and one or two of the people we've hired, this is their first job ever - and they're working remotely.

And so, the question I have, is - a lot of us who have been working remotely - I've been working remotely for a long time, you've been working remotely for a long time. But most of us have had an experience of working in the office. I've got a little joke - I'm writing a blog post about how working in the office is how we always should've been using the term "remote work," to refer to that - but isit easier to transition to working remotely, when you've already learned the skills and things that come from working in an office environment? Or do you think it actually might be better to just start in a remote environment?

Larry: Oh that's tricky. See, I'm one of those weird people who does not argue that remote work is inherently better. I know it's trendy in the tech world to say, "Oh, remote work is superior. And if you aren't working remotely, then your boss is a moron." I don't believe that. Working remotely has a lot of advantages. Working with other people in person has a lot of advantages.

I actually have a blog post I did a year, year and a half ago, called [n defence of the office, talking about, "Here's all the challenges that you have working remotely that just don't exist when you're working in person with someone." Most of the things people complain about, about an office, are complaints about open office designs, open plan designsm, not about having a central place to go to work. And open plan offices, those are terrible. No question, end of story.

But that doesn't mean that an office is bad. I don't think either model is superior. They have different sets of trade-offs, and they have different - some people just naturally work better in one than in the other.

I do think we need to have more people working remotely than we do now for environmental reasons. Because it does reduce overall net carbon output. And once we all survive coronavirus - the number one absolute most important thing for humanity to tackle, is climate change, period. That's going to be another great upheaval. We should get used to these. Because they're going to happen, or we're going to die - another tangent.

I don't know? For someone just starting out now and working remote - I'd say, that's a way of working. It is not the only way of working, but it is not a bad way of working. So if that's what you're doing, cool - learn the ins and outs of that model, and get good at it. And once the opportunity to work in person comes back, maybe you'll decide you want to do that instead? Maybe you'll be perfectly happy just working remotely? I'm not going to judge you for either one. Both have advantages. For both employee and for manager.

Len: Thanks for that answer. It's interesting just how tricky and complex these things are to face. And as you say, there are other other challenges - not only, ahead - but just here now, and just kind of behind in the queue of priority, as it were.

So, moving on to the next part of the interview, where we talk about your book. You've written -

Larry: Finally get to talk about the book.

Len: We're finally going to talk about the book. So you've written a book called Thinking Functionally in PHP. I was wondering if you could talk a little bit about what the inspiration was for you to write the book, and who the intended audience is?

Larry: So, I've been writing PHP for 21 years now in some form or another. And I've been interested in functional programming as a concept for nine, ten years. Something like that.

I've not done any serious work in a strictly functional language. But the more I learned about functional programming, the more I've decided that a lot of these concepts were really good, and do lead to better code than conventional approaches of procedural, and object-oriented. And what most people are doing, [?] which is kind of procedural code dumped into an object syntax - because they don't actually understand OO, which is most code out there today.

I had a talk I used to give on functional programming and PHP, a couple of years back at the conferences, that was kind of popular at the time. There have been other books written on functional programming in various languages you wouldn't expect to be functional languages, including PHP. I honestly didn't like any of them. Then last year, PHP 7.4 was coming out.

PHP, for those not familiar with it, is a programming language, it's the language that I work in primarily, historically. It is also far and away the most popular language for doing server-side web developments.

By an order of magnitude, nothing else comes close to it in terms of sheer number of sites. And version 7.4 was coming out last year. It's an open source language, it's built by a community - an open source community.

And one of its new features is short lambdas. Short lambdas - I'm going to lose the non-programmers now, I apologize - are a shorthand way to write anonymous functions. So if you have a function, you can have a named function, like you're used to. An anonymous function, also called a "lambda," also called a "closure." There's some subtlety in the names, but people use them interchangeably most of the time - lets you define a function inline, kind of on the fly, as part of the program.

As the joke goes, a closure is just a poor man's object. An object is just a poor man's closure. They are effectively the same problem space, but different approaches.

PHP has had support for anonymous functions for years, but the syntax form was kind of clunky. It meant that a lot of the things you would want to do if you were in a functional mindset, if you were thinking about your problem in a functional way, rather than an object-oriented way, or a procedural way - were really hard. The amount of typing you had to do to do it, was just annoying. The code ended up being hard to read, so why bother? Short lambdas - it's just a simple feature. It lets you define anonymous function with a much more compact syntax for cases where it's just a single-line function.

Which seems like it's not that much of a big deal, but it means you can now create anonymous functions super easily, and think of them not as, "Oh, I'm defining a function," as much as, "I'm encapsulating an expression that's going to take arguments." And that ability to shift your mindset, opens up the potential now to do functional-style things in PHP, in a way that's a lot easier and more approachable and more legible than it ever was before.

I'd done one book in the past. I wrote a book on Drupal 7 development for Packt Publishing, years ago, along with a number of colleagues at my former job. And that was not a pleasant experience. So I said, "Alright, I'm going to take another stab at this." And so started I working on - I guess somewhere around October-ish of last year? - book on functional programming in PHP 7.4, specifically. And along the way, I realized, "I don't actually know a lot of this material."

The infamous monad, for example, that everyone talks about in functional programming, and no one understands - because by understanding monads, you lose the ability to explain what a monad is - and then, things like that. Which - it's a fancy mathematical name for a design pattern, basically. It's like, "Okay, I don't actually understand this, time for me to learn."

So I spent several weeks not writing, but researching. By which I mean, teaching myself material, so that I could then teach it myself. Which is not the first time I've done that, to learn something.

That's actually a very good way to learn, at least for me, is to approach something as, "Okay, how do I teach it?" Because you don't actually understand something, unless you can teach it. So I hope I've been successful in this book in teaching some of the academic concepts. Because that means I actually understand it myself.

I finished up the manuscripts January/February this year. I knew I wanted to self-publish. Leanpub was the obvious choice for that. That's where most of the self-published tech books are that I know of. And the royalty rate is really good.

It meant I was on my own, so I hired an editor who I knew personally through the PHP community. She's the editor for, I think, half the PHP books out there? And hired a friend's wife to do the cover art, because she's also well known in the PHP community. She's done a lot of other work there. So just tapping into those community resources that I knew through being a part of the community for so long. And in mid-May, then out comes the book, and huzzah.

Len: A number of Leanpub authors are people who set themselves the challenge of learning something new. And they found themselves writing in order to understand what they were learning. I hope I'm getting this, the guest right - but I had Chris Mattmann on the podcast, from NASA's Jet Propulsion Laboratory, a while ago, who was writing the second version of a Manning book on machine learning.

And what he'd done, was he found that like - when he set himself these challenges for truly demonstrating to himself that he understood each chapter that he'd read in this book - he was actually writing new chapters of a book, essentially. And you make the very great point that having to write things down and explain them, even to yourself - is actually a really good way of learning the things.

Larry: It's the same idea as active listening, but in writing. And yeah, as I mentioned before - Platform.sh is all based on container technology. When I started at the company, I didn't actually know what that meant. I didn't understand what containers were. So I wrote an article on containers, and I've given a presentation on containers that I had to learn what containers were, in order to give this presentation.

And now I understand what it is, and I've - it's a very popular talk now, because it really gets into what's going on here without the hand-wavy stuff. Let's get into the nitty gritty, let's get into the details - and to get into the level I wanted to understand. And so I had to teach myself, so that I could then give a presentation on it - and now I understand it.

The category theory is much the same. I kept hearing about category theory, and what does this thing -? Arrows and objects and I don't - what are all these fancy words? But I needed to learn that, in order to write this book. So I spent lots of time Googling, and eventually ended up at Bartosz Milewski's - I think that's how you pronounce his name? - website and book, and ended up buying his book, if I can find it here. Yeah, Category Theory for Programmers by Bartosz Milewski.

I couldn't get through all of it. But I managed to get through enough of it, that I could understand the words, I could put it back together, I could write the chapters on category theory and actually understand what I'm talking about. So in some ways - my attempt was to get around the curse of the monad, by trying to explain monads as I was learning them - and maybe that means I was just on that threshold, of - not quite beyond the veil where I could no longer explain it, because I understood them. To capture that fresh knowledge. And I've gotten at least some good feedback on that, so maybe that was partially successful?

Len: Totally by coincidence, just yesterday we published our latest version of the podcast, this was with an author named Alfredo Deza, and when he started learning Python - a friend of his, named Noah Gift, who's now a co-author of his, said, "What you need to do to really learn Python, is apply to give a talk at a Python conference."

And he's like, "Well, but I can't. I don't know enough." And he said, "But you'll have to, in order to give the talk." And lo and behold, he got accepted and he gave the talk and then - boom, off he went on a little sort of mini-career as a conference speaker, and then book author, eventually.

I think part of the - just as I sort of segue into the last part of the interview, where we talk about self-publishing - if you've gone to the trouble of learning something, and you've actually set yourself the challenge of writing about it - you've got the basis for a book. And often people second guess themselves away from things, like applying to give conference talks, like writing books, and things like that. But if you know something and you've got a facility for explaining it, there are people out there who need your help - or probably do.

Larry: And the thing to understand is that presenting or teaching or writing or explaining - all of those are related, but they're an advanced skill. And it's an advanced skill that not everyone has. If you're really good at that, and okay at technology, there's a place for you teaching that material, so that other people can understand it. And maybe they'll end up being better at actually doing it than you are? And that's a win, that's a success.

Len: You mentioned just now that your first experience writing a book - you did it with a bunch of other people, and that it was a kind of unpleasant experience. Can you actually talk a little bit about that? What was it that made that experience unpleasant?

Larry: The main issue was, it was a book about Drupal 7. Drupal 7, like most open source projects, was scheduled to come out when it was done. Which means, who knows when that's going to happen. And that really didn't jive with the schedule that the publisher wanted to have. They wanted to crank out books at a certain schedule. They wanted everything now. They've got the timelines, they have printing schedules. They have - some things that are completely reasonable requirements, and some that are, "No, you're just being a corporate moron," requirements. And some that are a little of each. And it meant that as an author, working with them was really rather unpleasant.

And then, they also - like, we had six authors in this book. So the royalties that we were all getting were like two, three percent of sales. And they were also doing things like nickel-and-diming us on - "Authors get x number of free printed copies. But there's six of you, so you only get two copies each, instead of 15 copies each." And we were like, "Really dude, really? No." So yeah after that, I'm like, "Okay, I'm never dealing with this company again." I figured I've got enough of a name, that I could do enough marketing myself with my target audience - which is people who already know PHP, but want to get better at it. Which is a large market. And I could do enough of my own marketing there to make up for whatever difference in sales not having them around to market, would be.

And then with Leanpub, it's 80% royalty, instead of 2% royalty. So if I sell 100 copies, I've still made probably more money than I would've made with 1,000 copies with that other company. I'm perfectly happy to sell 1,000, 3,000 copies through Leanpub - that would be wonderful. So please go buy copies.

But it means from a economic and financial point of view, the point of return where I'm making enough on it to justify the effort and the expense of hiring an editor and so forth - is a lot sooner. And so I don't need to sell as many copies to make it worth my while to do. And I still learned along the way, enormously.

At the self-publishing environments, you get a lot less professional support for the non-writing parts, and actually for some of the writing parts too. But that means if you're able to supplement those yourself, then the control you have, the freedom you have, the ease of making back your investment - I think is a lot nicer in that regard.

Len: And how did you find your editor?

Larry: She was the editor for like half the PHP books on the market. It's Kara Ferguson. She's also the editor for php[architect] magazine, which has been around forever. So it really wasn't much of a question. I know Kara. I've talked to her at conferences, I've hung out with her and her husband. So, "Alright, I'll message her. Cool." So that was pretty easy, in my case.

Len: And for those who've never done it before, for whom publishing a book is a big black box - did you hand over to her a complete manuscript when you were done a first draft? Or did you hand her chapters piece-by-piece as you wrote them?

Larry: In my case, I wrote the whole manuscript first. I was using Markdown and Git. Leanpub offers that model, which I prefer. And then, when I brought her on - after I'd more or less finished the book, I copied everything over into a bunch of Google Docs and shared those with her. And she just went to town with Google Doc editing. And a lot of it was typographic stuff, because she's trained to look for that, and I'm not. Some of it was wording things in a cleaner fashion.

Some of it was just validating that the structure I had made sense, and fortunately it did. But that was one of the questions I had for her. "Is the flow good? Is the order that I'm addressing the chapters in good?" She was definitely not providing the level of, take it apart and rebuild it, that a professional editor for a novel would be providing, but that wasn't what I was looking for. I was looking for - is my overall structure for a tech book good, and I need a copy editor to take care of stuff. And she was very good, very efficient, very cost effective for that.

Len: And what was the reason to use Google Docs? We've had a number of - we even had a Google Docs writing mode in the past. And we've had a number of Leanpub authors talk about using Google Docs. We even recently actually had someone ask for Microsoft Word, like DOCX output, so they could share their book with an editor. And I'm just asking - in this case in particular, it sounds like the editor had a preference for Google Docs. Was that so they could put comments on things and things like that?

Larry: Yeah.

Len: Okay.

Larry: Google Docs is really, really good for collaborative editing. It's terrible for writing Markdown. Especially when I'm writing a lot of source code - about a third of the length of the book is PHP code. And writing that in Google Docs is a godawful experience. You don't want to do that. But putting all the text into Google Docs, so that we can use Google's commenting feature, and talk back and forth and make suggestions - I didn't have her - I didn't open it up to editing, I gave her suggestion access. So I could see every change she wanted to suggest, and I could accept or reject everything - and I accepted like 98% of it.

It was a really nice workflow. I use it at work as well; when I'm writing blog posts, I do the same thing.

Len: Just so people get a sense of like the actual how this worked, would you like have like your plain text document of your book content open on the - like say on the right of your screen, and have Google Docs open on the left. And then when you approved a comment in the Google Doc, would you then make the change in the Google Doc, or would you make the change in your plain text file?

Larry: So in my case, I had the canonical version in Git in Markdown. I copied everything over into Google Docs. One doc per chapter. She went through the whole thing over the course of several days. And I was reviewing and following up and commenting there. Everything was in Google Docs. And after she was all done, I just did, "select all/paste, select all/paste, select all/paste -"

Len: Okay.

Larry: To move it back into my Git copy. So I have a Git commit on my history that is -

Len: I can imagine.

Larry: "Importing back changes from editor." Which has a bajillion edits throughout the entire document.

Len: Okay, so basically, you can copy and paste from a plain text file into Google Docs, even if there's code in there. And then you can make changes in the Google Docs, and then just copy and paste it back into a plain text file.

Larry: Exactly.

Len: And that'll work. Okay great, that's what I wanted -

Larry: There's a few fiddly bits in it, but that was generally the approach, and it worked reasonably well.

Len: Yeah, there's always some curating with these kinds of processes. I'm glad to hear that worked.

And by the way, it is really nice to hear about these things in detail. Because it can save people so much time and heartache and stress to know not only what the solutions are, but that everybody faces the same problems, and is kind of fiddling around all the time trying to optimize processes.

Larry: Yeah. It's probably what I would do next time as well. I'm hoping that there's a next time. I'm not quite sure what yet, but that's the plan.

Len: Well, so are we.

The last question I always like to ask on this podcast, when the guest is a Leanpub author, is: If there was one feature we could build for you, or one problem we could fix for you, can you think of anything you would ask us to do?

Larry: I'm going to give you one of each.

Len: Okay.

Larry: So one problem to fix. There's a bug in your rendering system. I cannot do a shruggy emoji.

Len: Oh that's you, okay.

Larry: That's me.

Len: Yeah, okay.

Larry: And that's annoying, because I had one part of the book where I was describing returning null from a function as the program equivalent of shrug emoji. And so I used a shrug emoji like eight times in two paragraphs. Which absolutely perfectly captured the message I was trying to say there. But it would not render correctly in any output. So I ended up changing it to just saying "shrug emoji." Which kind of gets the point across, but isn't as cute. So if there's anything to fix, it'd be that.

In terms of features to add. I know there are ways to do print-on-demand with third-party companies. But it'd be lovely to see that integrated. And have a sense for - like when I'm setting a price for the book, "Alright, what's the price going to end up being if I decide to do a paper version?" Right now, I'm not. Because I'm waiting for some feedback. I'm getting feedback from readers. I might want to tweak a few things. Which is wonderful that I can do that. But my parents are university professors - retired now, but university professors. They want a signed copy, and I can't give them a signed copy yet. So better integration in setting up the print-on-demand option, would be really nice.

Len: Okay, thanks very much for both of those.

With respect to the shrug emoji - or emoticon, I should say. When you're doing things that use Markdown - or in our case - our flavor of it, Markua characters - you often have to escape the character so that it doesn't - "escape" is a technical term, for non-programmers listening.

But it basically means like, "Don't interpret what follows this as code for formatting the book. Just output the thing that the person is typing." But if the escape character is the thing you're trying to escape, like happens with the shrug emoticon, then you can run into trouble.

actually spent some time myself trying out the various things, and couldn't find a solution. So we know about this. It's probably not the kind of thing we're going to have significant developer time for anytime soon. But the higher level problem though, is actually something that's important to us, to have solutions for.

Larry: So there's two different pieces. There's escaping the characters that end up being interpreted as control codes. Also the smiley face in the middle, in PDF, just renders as a square. So that's just a straight up character encoding question.

Len: Yes, that's correct. And we do know, there are some character encoding things that we're aware of, and this is on our list of things.

Larry: And can I just say - thank you for saying "emoticon," rather than emoji. I thank you for correcting me. Because, I don't really like all the fancy graphical emoji, but I do like and have been a fan of the emoticons for years, so -

Len: Yeah, me too. Just for those listening. An emoji is when you see the yellow smiling face in a circle. An emoticon is when someone types a colon and then like a -

Larry: Close parentheses.

Len: Close parentheses, yes - to make a smiley face.

Larry: It's two different art forms that kind of overlap.

Len: Yeah, those are the two different things. And some people like both, some people like neither, and some people have a preference for one over the other. Those of us who have a preference, particularly for emoticons, like to make sure we make the distinction between an emoji and emoticon. And when it comes to producing book output - actually they're very different concepts, and they're very important to have distinct in your mind.

With respect to print books. So we do have a Print-Ready PDF output option. So you can do various settings, and you can click a button and you can get a PDF that - you'll have to tweak it and iterate a little bit if you're using a third-party print service.

We have had the request for integration before. The ideal end point of that process would be a - you click a button, and "make a print copy of my book." "Send me a test print copy of my book." And then you approve it, and then it's just available on some third-party service for print-on-demand, and all you have to do is click a button in Leanpub.

We are in the digital goods business, not in the physical goods business. These are very different kinds of businesses to be in.

Larry: Fair enough.

Len: Just for example, just the concept of refunds and returns in itself - is just like - in Leanpub, we have the magical "Refund my purchase" button. And you get a refund right away and it all works. When you're dealing with physical books, that whole process is just completely different, and full of pitfalls and risks and stuff like that.

And so, I mean, never's a long time, but I'm pretty sure Leanpub will never be in the print book production business. Even via some kind of agreement with a third party.

But we love print books. Print books are very important. And that's why we have our Print-Ready PDF output option. We also have an InDesign output option as well. So for people who've got a complete manuscript, and they want to actually give it to a professional, proper book designer, we actually give you a pretty robust starting point for that process.

So we're aware of it as an issue. We know it's something that authors want. Having the magic button is probably not something that we're ever going to have, but we understand the desire for it completely.

Larry: Even just better integration. So like having a sense of, "If I want to add that, then here's what that price model would look like at these partners." A way to toss a PDF over to some approved partner more easily. Things like that would be very much appreciated.

Len: Yeah, we'd love to have a guide. Part of the issue with having guides, as you would know, with respect to sort of third parties - is the third parties can change their terms any time they want. And then you'd get yourself in a little bit of a potential trap, where someone's like, "Hey, you told me it was going to cost this, and now it costs that. What's wrong with you?"

Larry: Right.

Len: And it's like, "Well, they changed their price, we didn't." And Generally speaking, we prefer to have people who are not a part of Leanpub write about things like that. Not because we're lazy, but just because people - if it's the business that someone's dealing with, and it's money in their profession, in their career, and stuff like that, that they're concerned about - people actually do, more often than you might think - start to conflate different services. So we'll get Amazon's -

Larry: Got the clause about liability.

Len: But we also want people to understand that like - it's actually like - it sounds silly, but like people do get confused. We'll get Amazon support emails.

Larry: Really?

Len: For example, because someone has downloaded the MOBI version, and they're having trouble getting it into their Kindle account, or something like that. Even though the MOBI's perfectly fine, but people don't always see the distinction between the different services that they're using. And so we do try to - I mean, we do try to keep the lines distinct in so far as we can.

Well anyway, Larry - thank you very much for taking the time out of your day to do this.

Larry: It's been fun. Thank you.

Len: I really appreciate it. And thank you for being a Leanpub author.

The book, for anyone listening, is Thinking Functionally in PHP. It's about functional programming. using PHP as the sort of foundation for learning it. But if you're interested in learning about functional programming, both from the sort of basic introductory side, all the way up to the Computer Science-y stuff, as you say in your book description - and then learning about the mysterious monad, his is the book for you.

So, thank you very much Larry, for being a Leanpub author, and for being on the Frontmatter podcast.

Larry: Be well.

Len: 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.