In this episode, we talk to Daniel Higginbotham about writing books, learning Clojure and non-violent communication.
In this episode, we talk to Daniel Higginbotham about writing books, learning Clojure and non-violent communication.
CRAIG: Hello, and welcome to Episode 98 of The Cognicast, a podcast by Cognitect, Inc. about software and the people who create it. I'm your host, Craig Andera.
All right, well, in terms of things coming up in the community, of course we want to talk about ClojureBridge. There's one coming up in Seattle April 8th and 9th. This is in 2016. As always, you can find out more about that event and about all of the ClojureBridge events at their website at www.clojurebridge.org. I encourage you to go there, check it out, and I'll remind you again that you can find a donation link on the ClojureBridge website. I encourage you to stop by and give them whatever you can. It's a worthy organization, and they could definitely use your help.
Then, as far as other news, I want to talk to you about Clojure/west. Of course, Clojure/west itself it happening April 15th and 16th. That also in Seattle, and the website is clojurewest.org. The speaker lineup has been announced. It looks like it's going to be yet another really interesting conference. I think the speaker lineup looks absolutely great.
Right before it, there will be a Clojure training and as well as Datomic training. Those are two separate courses. Those will be held April 13th and 14th, so immediately before the conference. You can find out more about the training as well at the conference website. Again, that's clojurewest.org. I encourage you to go check that out.
Hopefully you'll be able to make it. It's a good conference. I highly recommend you check it out, especially if you're out on the West Coast. But, of course, we have people traveling from all over, so maybe see you in Seattle.
I think that's about it for announcements, so we will go ahead and go on to episode 98 of the Cognicast.
[Music: "Thumbs Up (for Rock N' Roll)" by Kill the Noise and Feed Me]
CRAIG: If you're ready, I'm ready.
DANIEL: Sure. Yeah, let's do it.
CRAIG: All right, let's do it. Well, welcome, everybody. Today is Thursday, February 11th in 2016, and this is the Cognicast. Today, we are very pleased to welcome author, developer, all around nice guy, Daniel Higginbotham. Welcome to the show.
DANIEL: Thanks, Craig. It's awesome to be here.
CRAIG: We appreciate you taking the time to come today. I'm looking forward to the conversation. Before we jump into things probably technical, I have a question that I ask all of our quests we start the show with, and it is a question about art. We like to talk about art.
Specifically, the thing that we like to kick things off with is a question around the guest's experience of art, some experience of art, whatever that happens to be. "Hey, I like to work with clay," or, "I saw a really great movie," or whatever it is. I did forewarn you, as I usually remember to do with our guests, so I'm wondering what you had a chance to think of and what you'd like to share with us today.
DANIEL: Oh, sure. Yeah, so what I thought of was a poem, actually, that had been on my mind, and it's just one of my favorite ones. Occasionally, my mind returns to it. It is The Friend of the Fourth Decade, by James Merrill.
It's kind of a melancholy poem, I think, but I don't know. It's hard to describe it. It's just like describing music with words. It's kind of almost pointless.
But, it's a very beautiful poem. I love the language he uses. I don't know. I suppose I could talk more about it, but the name of it is The Friend of the Fourth Decade, and it's one of my favorites.
CRAIG: Are you prepared to read some of it, or all of it if it's short?
DANIEL: Oh, gosh. Well, it's not very short. I could read some of it.
CRAIG: It's up to you. Totally fine if you don't. We have lots to talk about. But if you wanted to, it sounds–I don't know–you've made it sound good. So, if you wanted to actually share some of the words, that'd be great.
DANIEL: Sure, sure, sure. Let's see here. Okay. Here's one of my favorite parts. This is the friend in the title speaking, and he says,
"Listen." He went on, "I have this friend– What's that face for? Do you think I had only one?
You are my oldest friend, remember. Well, Karlheinrich collects stamps. I now spend mornings
With a bowl of water and my postcard box.
Cards from all over. God! Those were the years.
I never used to throw out anything.
Each card then soaks for five minutes while its ink
Turns to exactly the slow formal swirls Through which a phoenix flies on Chinese silk.
These leave the water darker but still clear, The text unreadable. It's true.
Cards from my mother, my great uncle, you! And the used waters deepen the sea's blue.
I cannot tell you what this does to me. Scene upon scene's immersion and emergence
Rinsed of the word. The Golden Lake [sic], Moroccan Dancing boys, the Alps from Interlaken,
Fuji, the Andes, Titian's Venus, two Mandrels from the Cincinnati Zoo–
All that survives the flood, as does a lighter Heart than I've had in many a day.
Salt lick big as a fist, heart, hoard Of self one grew up prizing above rubies–
To feel it even by a grain dissolved, Absolved, I mean, recipient with writer,
By water holy from the tap, by air that dries, Of having cared and having ceased to care…"
So that's just a little bit from the middle-ish part of the poem.
CRAIG: That's awesome. That's very cool, very cool. I like the imagery. I haven't read the poem. Never encountered, I think, even the poet before. I want to talk about this a little bit. Is it some sort of metaphor for memory? I see this image of postcards kind of soaking in a bowl of water and kind of diffusing it as a bigger thing. It seems almost like a metaphor for memory kind of diffusing as you age. Maybe I'm way off.
DANIEL: Yeah. I think so. I think that that's part of it. I think the overall gist of the poem, my interpretation of it, my guess of it, is that this is perhaps a World War II veteran. This is why maybe it's in the fourth decade. Or maybe it's in his 40s. I'm not sure, but also it mentions him coming home to, like, parades and stuff.
I think that that's part of it, and it's also just like a willful kind of like letting go of your past and then what remains then. This imagery that he shares are these beautiful photos. It's very interesting, and it goes on. It then goes on to write a couple more times of his new adventures. So, I think that memory is part of it, and the narrator, after the part that I just read, goes on to talk about, like, he tries the same thing, but maybe it's the ink that was used, but the text is still there for him. So, the inescapability of some things that you just can't forget.
CRAIG: Wow. Deep.
DANIEL: Yeah.
CRAIG: Although I will point out, as a computer scientist, that technically, I guess, World War II started in the fourth decade. The 30s would be the fourth decade, right? If you count the first decade is the one that goes up to 10 or however you count from zero, I guess. Anyway, I was thinking I'm in my fourth decade. I'm like, no. I'm over 40. I'm in my fifth decade.
DANIEL: That's so true. Off by one.
CRAIG: Yep. One of the two classic problems, right? Cool. That is really awesome. I really appreciate you sharing that with me. That's very, very beautiful, for one thing, and interesting for another. But, I think maybe we will not spend the whole time talking about that poem, although I suspect we could and it would be fascinating. But, let's turn to other things.
Let's turn to some of the things that we tend to talk about more on this show. I think maybe – well, let's maybe start with your book. I want to talk more about your background and Clojure in general, but I really can't have you on the show and not talk about your book. I think I'll just throw it to you because I will admit right away I have not read it. I would like to, but I just haven't gotten around to that one yet. I've heard really good things from other people, but maybe you could talk about it starting with the name, of course. DANIEL: Yeah, sure. The book is Clojure for the Brave and True. It's an introductory book to Clojure, so it assumes that you have no functional programming or Lisp or Java experience.
The approach that I tried to take with the book – oh, it's also free online, by the way. It's at braveclojure.com. The approach that I tried to take with it was to, one, be maybe a gentler introduction than some of the resources out there.
For example, I came to Clojure from Ruby. I knew zero Java and some of the things I would read would mention things like Java interfaces or whatever. I was just like, okay, I don't know what that is. I don't know what this is talking about.
The book tries to take a gentler approach in that regard, and I also tried to make it goofy. Part of, I think, my motivation was that I had thought of a lot of dumb ideas over time, and I was like, "These make me laugh, so maybe I'll put them in a book, and maybe they'll make other people laugh." I tried to make it fun for people, and it seems like that's been pretty successful.
Some people, I think, don't necessarily appreciate the sense of humor in it. The very first review on Amazon, this guy just hated it so much, and it was just like the only thing that I got right, in his opinion, was the topic, which was Clojure. It was like, okay, so it's not for everybody.
Really, though, the overwhelming response I've gotten is that people really enjoy it, they think it's really fun, and it's fun to keep reading. It's not dry. That was my goal.
CRAIG: Cool. I have to ask about the title. It's a great title: Clojure for the Brave and True. Is there a story behind that, you just liked it, or what's the deal?
DANIEL: I think it's just kind of a fantasy sounding title. Actually, my initial thought on it was, like, maybe I'd have a fantasy theme going through it. But, really, the theme that goes through it is probably more just like weird stuff, like monsters, like vampires, zombies, and things like that. But, I don't know. It just sounded fun to me is the main thing.
CRAIG: Cool. Well, it is a fun sounding name. It's certainly eye catching from a purely business perspective, although maybe this had nothing to do with your objectives. I think it's fair to say that if you're going to write a Clojure book, especially an introductory one these days, you've got to differentiate somehow because there are an awful lot of them.
I want to ask whether that was on your mind when you set out to write this, the fact that there is such a plethora of intro Clojure books. And, if so, what your thought process was that helped you overcome that, or maybe you just didn't care. I don't know. What was the story there?
DANIEL: I started writing this back in, I guess it was, 2013. It was like August or so in 2013. My thought process around it was I had an immediate desire to write something, which was that I wanted to use Clojure at work. To do that, I had to try and convince people that we should use this, but the folks that I worked with are a lot of, like, Ruby programmers and JavaScript programmers and were kind of like in the same boat as me. Whereas, I had been using the language for a year and a half or something at that point, for them it's like it felt maybe like kind of a bear to read through some of the existing resources, like I mentioned, the whole Java aspect of it.
I feel like I don't want to disparage what's out there because I feel like they're good, quality resources, like Chas Emerick's book, I think, was the one that I just loved and thought was awesome. But, part of my motivation was I had encountered a lot of, well, a few difficulties learning Clojure.
I was like, well, okay. How can I present this perhaps in an easier manner for people and to get people onboard more quickly? Right? Because, for the completely selfish reason that I wanted to use this at work, and so I just thought if I created a couple resources to get folks at work onboard with it, then it's like, okay, we can actually start using this. That actually ended up working, which was awesome.
But, the title aspect of it, Clojure for the Brave and True, and whether or not I was trying to differentiate it, I think, really, I started writing it. I was like, okay, how am I going to write this so that I don't bore myself? It'd be very easy to not keep writing it because I wasn't getting paid for it or anything. It's a completely voluntary thing.
So, I just tried to make it really silly, and so TrueClojure for the Brave and True, now the cover has a drawing of this dwarf with a war hammer. He's crazed looking. He's on a pig. That kind of silliness, I tried to put it in the book I guess mainly so that I wouldn't bore myself.
CRAIG: That's as good a reason as any, particularly if you're not being paid to do it. How does that work, by the way? You wrote this. It looks like it's available at least on No Starch Press.
DANIEL: Mm-hmm. CRAIG: What does that process look like? I don't have any idea if this is something where they approached you and said, "Oh, you should publish this through us," or it's entirely voluntary. How does that aspect of it work? You have a book, you're about to put it out there, and you do it this way.
DANIEL: Yeah. The book started out online for free. After I had written a few chapters, which, looking back now, it was just more like rough drafts of chapters. But, I put some stuff out there, and people seemed to like it and respond to it. That made me start thinking like, "Okay, well, maybe I could sell this."
I ended up actually putting it on Leanpub, and that worked out pretty nicely for a while, but then I also ended up talking to No Starch because one of my coworkers had his book, Ruby Under a Microscope, published with No Starch, and he really liked the process. I actually talked to PragProg too, the Pragmatic Programmers.
With No Starch, the reason why I went with them, well, there are a couple reasons. One was that I asked, "After this is published, can I put the final product online for free?" That was one of my goals. I wanted to have a full, complete introduction to Clojure, a high quality introduction to Clojure, online for free. They said yes.
The other aspect was that I wanted to have a lot of input, a lot of control over the cover art, and they were cool with that too. Because, really, it was just like, as I said, this was a labor of love. The common wisdom is that you don't make a ton of money from tech books, and it's pretty much true, I think, for the most part. For me, it was just like I wanted to be able to really have fun and be expressive in this project, you know, do something creative that was fulfilling for me.
No Starch was completely onboard with that, and they were just awesome. I'm so glad that I went with them because I think the book is much higher quality as a result of their editing. Their editing process was great. I was just astounded by how great they were.
Some of my other friends had gone with other publishers and talked about being hounded, like, "When are you going to get the next chapter out? We want you to publish this in two months. Write an entire book in two months."
No Starch was fantastic. They would just say, "Take as much time as you need to. This is your thing. Do a great job of it." It was great. I feel like the results I'm really happy with, and the fact that I get to put it online for free, the result of not just my work, but the work of the editors there, is just completely awesome. I'm really happy with how things worked out with No Starch.
CRAIG: Very, very cool. I have to ask you about the art, by the way. You mentioned it. You said you had a lot of input into the cover. I pulled up an image of it. It's really fun. It's, like you said, a dwarf riding on a boar, I guess, carrying a war hammer with a lambda engraved on the head. It's pretty cool.
When you say you had a lot of influence, are you being modest? There are some other fun images at the top of the Web page as well. Is this something that you drew, or did you work with an artist that you knew? How did that go?
DANIEL: I did. I worked with an artist that I knew. It was my wife.
CRAIG: Okay.
DANIEL: Yes.
CRAIG: Awesome. No, this is good stuff. It's really fun. I was going to ask how was that.
DANIEL: It was great. It was cool. I felt bad for her because I would give her these really vague ideas. One of the images on the top of the website is this sock gnome. I was like, "Can you do a sock gnome, which is a gnome that steals socks and uses it to incubate its babies?"
She's like, "Um, okay. Sure." She's like, "This is for a programming book? All right." But she would come back with stuff that just really tickled me. Another one of the drawings at the top of the site, the left most one, is the ghost of John McCarthy, and it just really tickles me.
It was awesome. I would tell her this vague stuff, and I'd say, "Try to make it funny." She'd come back with, like, the drawing on the cover. She did that, and it was great. I loved it.
CRAIG: Yeah, well, they're very fun looking, as I said multiple times already. It's certainly true. People can check them out at braveclojure.com, the website for the book.
By the way, I completely understand how you feel in talking to her because that's the conversation that I have. Every time we do an episode here, we do a cover, and I have nothing to do with it other than having a conversation with Michael Parenteau. He's the artist, among other things. We've had him on the show before. People might be familiar with him.
Anyway, I'll go to him and say, "Yeah, the guest says they don't really care what's on the cover, but they'd like there to be a goat." Okay. Or, it somehow has to evoke type theory and pizza.
DANIEL: Okay.
CRAIG: I completely understand what you're saying. I'm always completely amazed by the output of people whose creative outlet is visual. I do feel that programming is a creative act in ways that are very similar to someone who paints, draws, or whatever. At the same time, I can look at that and go, "Well, you're doing something different than I am, and what you're doing is amazing in its own way," and that's always cool to see.
I think I could definitely relate to your experience where, "Hey, I need a sock gnome programming thing." Yeah, it's fun. Cool. Awesome.
You're brave for working with your wife because, of course. I don't mean that as a comment on marriage or anything like that. You have a close, personal relationship with somebody, and you're working with them, there's always potential there for the two different relationships to interfere with each other in some way.
DANIEL: Yeah, for sure. For sure. Yeah. In this case it definitely worked out okay because I think her attitude about it was like, okay, this is your thing. She didn't have a personal stake in it, I guess, so it was just like, "I'll just try to do what it is that you want me to do," you know.
Even when I'd come back and be like, "Uh, this thing, can you adjust it this way?" Sometimes she'd say, like, "Well, not any time soon," because, like, you know.
CRAIG: Right.
DANIEL: But it was really cool because she got it. It was like, "Okay, this is your thing," and it was really nice for her to do that for me. Also, by the way, Michael Parenteau's stuff, I've seen some of his other stuff on Dribbble, I think. Super cool! Yeah, his design work, I'm a big fan.
CRAIG: I am too. Yeah, he's great. I refer to him as an artist, but I'll wax rhapsodic about Michael a little bit. He's not here. This is a guy who does not have any kind of a technical background, but he's learned. Obviously all of the technology is related to Web design, but he programs in Clojure and ClojureScript.
DANIEL: Oh, wow.
CRAIG: He uses Git with facility. He's really, really very much a multitalented guy.
DANIEL: Dang!
CRAIG: I know, and then he produces these covers that I just love is his covers. That's always one of my favorite parts of every episode is there's a point at which he's like, "Hey, it's done," and I get to see it. That's always neat.
I want to turn back to the book and maybe more specifically to the genesis of the book because I'm curious. You said you came from a Ruby background and that you had decided to write this book because there was a path that you took that wasn't maybe as well trod or at least as well documented as some of the others. For instance some of the Java stuff.
What was the order of things here like? You wrote a book that was helping people through those things. Were you learning some aspects of Clojure as you were doing that, or did you learn them first and then go, "Okay, now that I understand this, I'm ready to pave the path for others"? Which one of those did it, or maybe it was something else?
DANIEL: Oh, yeah. You know, actually I think part of it was I had written a few just blog articles on Clojure, and those seemed to get a really positive response. That's where I started trying to write in this goofy style. That got a positive response, and I would write those articles pretty soon after I learned something. I think some of the stuff that I wrote about ended up in the book, but actually not all that much.
For the book, there were a lot of things that I had learned by that point, but there was also probably more things that I did not know and just learned them as I wrote the book, which I felt like was an okay way to go about it because the difficulties are then fresh in my mind. It was easier for me to try to explain. What is that phrase? "You can't un-ring a bell," right? Once you understand something, it's difficult to really see it from the perspective of someone who doesn't understand it. Just something happens in your brain. Something becomes obvious now and it's hard for it to not be obvious.
That was my experience for a lot of writing the book was that I didn't know, for example, laziness. I didn't know really what that was. Core.async: I had no clue. I'd seen some of the videos and stuff, but I was just like, "I just don't get it."
In fact, probably what drew me to Clojure in the first place was I heard that it had support for concurrency, parallelism, and stuff, but my experience with that coming from Ruby was super limited. I didn't even understand what threads were, really. I had kind of a vague idea, but you don't do multithreaded programming in Ruby or JavaScript, so I didn't have to care about it.
Really, there's a vast landscape, a computer science landscape that was unexplored by me, and I got to kind of explore it a little bit with Clojure as my companion, which made it super fun and made its way into the book. That was really part of what got me so excited about Clojure in the first place was like, okay. I've been doing Ruby for a long time. I did some iOS stuff, which I think everyone is required to do at some point, you know, or else they get their programmer credentials revoked. It's like, "You need to make an iOS app."
I've had, I think, a decent amount of experience. But, for me, Clojure is just opening up this entire new world of stuff that I never really had to think about before, and it's all super fascinating. I mentioned concurrency, parallelism. The thing about Clojure, too, is it makes it so easy to deal with that stuff, so you don't have to deal with all these incidental details.
I can see, like if I want to learn concurrency for C++ or something, it'd be just gross, having to learn all this extra stuff like memory management, and you don't have the great constructs like add-ons, reps, and things like that. You can focus more on the concepts and what you're trying to do than the implementation. Anyway, I'm kind of digressing here.
The answer to your question is there was definitely a ton that I learned along the way, and it was super nice for me because now I feel like I'm pretty decent. I'm okay at Clojure now, I feel like. There's still a whole lot more to learn for me.
CRAIG: I think we all feel that way, by the way, no matter what level you're at. I work with some people who are, you know–
DANIEL: Yeah.
CRAIG: Anyway, I think everybody would say the same thing, which is, "I feel like I've achieved a certain level of mastery or proficiency, at least. But, hey, there's always more." Anyway. Sorry. Didn't mean to interrupt you. Go ahead.
DANIEL: Very true. Very true.
CRAIG: I think it's always that way, right? What do they say? "The best way to learn is to teach," and I think writing a book, especially a book like this one I suspect, is very much about teaching.
It leads me to ask the question. I'm looking at the website. It's a fun text and everything, but it says people are using it to do complex distributed systems, micro services, and user interfaces. When you write a beginner book like this, I think that you have a really tough choice to face. Maybe it's not even a choice so much as a spectrum of approaches.
DANIEL: Mm-hmm.
CRAIG: Obviously you used humor as a strategy, which I think is great. I personally love that sort of thing. But then you have to ask yourself, "Okay, am I going to teach the language, or am I going to teach libraries that are in common use?" What's the narrative of the book or what is the path? Like I said, not having read it, I wonder if you could speak to those of us that haven't about the story of the book is, if you will, how you take people through.
DANIEL: Sure. Yeah. The way that I think about it is like when you're learning a programming language. There are four kinds of broad aspects of the landscape for a programming language. I think there's tooling, and so the book uses Emacs, which some people don't really like, which is odd to me. It was like, "Okay. Should I just not have put a chapter in there about any tooling?" Anyway, I could talk a little bit more about that.
CRAIG: Yeah, we can come back to that, maybe.
DANIEL: Yeah. Yeah, so there's tooling. Then there's the language itself, which I think of as the syntax, semantics, and data structures. Then I think there is the artifact aspect, which is the larger artifact ecosystem of libraries, but then also how you publish your own artifacts, things like that. Then there's also the mindset of the programming language, the philosophy of the programming language. How do you think Clojure? How do you think of Ruby, JavaScript, or whatever?
What the book tries to do it is definitely doesn't – I'll start with tooling. Yeah, it tries to get you to the point where it at least tries to equip you so that you can, with some facility, write Clojure and run a Clojure program. That includes Leiningen, so building a program and running it, Emacs as an editor - one option. I also mention the various other editors out there like Cursive, VIM, whatever.
You need to be able to write. You need to be able to write your code, I think, and something not in Notepad, and be able to do it with some amount of ease so that that doesn't get in the way of you learning. My approach to that is, ultimately, when you're learning, you want to have a quick feedback cycle. You want to try something out, see if it worked or not, or if something blew up, and then be able to go in, change it, see if that fixed it, or see what happens next. That's the tooling aspect of it.
I tried to get people up to speed with at least some tools like, okay, now you can write Clojure. You don't have to worry about it anymore. You can actually write the code. You don't have to worry about that part any more, and you can focus on the language.
The book, in terms of the artifacts, it doesn't really focus on how to. On the different libraries that are out there, it's definitely out of scope. It does talk a little bit about how do you use a different library. Like when you go to Git or something and you see, "Put this in your lein profile." What does that mean? It gives you kind of an understanding of the basics of what I call the artifact ecosystem, but it doesn't focus at all on external libraries. There's nothing about how would you build a website or how would you use core.matrix or something like that.
The book, after introducing the tooling, focuses mostly on the basics of the language starting with how do you do basic stuff. The third chapter is called Do Things. How do you do things? What's a function? How do you write a function? What are the different data structures?
I think it's useful to focus on just very concrete things like, "Try typing this thing. See what happens," and build up at least some level of concrete experience before we start talking about all the amazing, wonderful ideas that Clojure has. I feel like when you start talking about these abstract ideas without being able to relate them to a concrete experience, it's just very difficult, I think, for beginners to make sense of that.
It assumes that you know some programming, like you've used maybe a different programming language before, but I tried to just relate it back to some very basic programming experience. You want to apply a function. You want to get a new result. How do you do those things?
Then, from there, it starts to go farther into the mindset of Clojure. It'll introduce. I think one of the next chapters talks about functional programming. It just talks about, okay, what's a pure function, things like that, but just relating it back to these concrete things that you've already done.
Then I'll start introducing perhaps more functions later. Start talking about programming to abstractions, which I think is more uniquely a Clojure concept and perhaps people would be less familiar with it. But, I try to explain that in terms of, well, it's already been explained and people have an existing experience.
By the end of it, what I want people to understand. I want people to be able to write basic Clojure programs and understand what's happening, for them not to be tripped up by some kind of magic of like lazy sequences, for example. I mentioned that earlier. "Okay. Maps return something lazy for some reason. I don't know what that is, but I'm just going to go with it for now." I don't want people to have that mindset. I want people to understand the fundamentals of the language.
CRAIG: I love that description. I especially like your breakdown, the four areas, and especially that one of them is a philosophy mindset. I like that a lot. I think that's key. It leads me to a question I wanted to ask you, which is: I think it's interesting to talk to people, especially people of different backgrounds. Yours being, as you said, primarily Ruby.
When you come to Clojure, it's very easy for there to be a lot of new things, depending on where you're coming from. I think you could categorize those new things a bunch of ways. But, one way might be, well, it's a Lisp, and maybe one hasn't done Lisp before. It's a functional language. Maybe that's new. It's on the JVM, and maybe that's new.
For me, all three of those things were newish, although Lisp probably the least, so I'd done a bit with that. I know there are probably other dimensions as well. I wonder, with your background, and actually also from the perspective of teaching people via this book, which of those three do you think, if you can pick just one, is the biggest one? How would you characterize your experience and, you think, a typical newcomer's experience in those various dimensions?
In other words, is it easy to teach people the Lispiness of it? Is it easy to teach people the mindset? Is it easy to teach people functional, whatever? What's your take on all that?
DANIEL: For me, and I've also helped out with ClojureBridge, for example, and I had a little study group at McKinsey, where I was working at the time. For me, the Lisp aspect of it, I felt like that was the easiest. I felt like one way to make it easy was to actually not really emphasize it so much.
Lisp is awesome. You can do cool stuff like macros and having this prefix notation is super awesome. But, I tried to actually not focus on it too much. Just say, like, "Okay. Here's how you do a thing. It's kind of similar. Here's how you call a function. It's similar to how you would do it in JavaScript this way and how you do it in Ruby." Let's not dwell on it too much.
There are parentheses. Yeah, but you're already a programmer. You've already done the hard part, which is learning how to program some language and learning how to understand what a program is, right? Lisp is–at least as an introduction to Lisp–just another programming language. It just looks a little bit different. Let's not dwell on it.
Once you see how to actually call functions with it, then you're good to go. It's not really confusing. That's actually the experience I had with people. It was like, "Okay. Fine."
Also, I found in ClojureBridge, too, when people were completely new to programming, there's no question of, like, "Oh, my God! What is this plus sign doing at the beginning? This is dumb. What's with all these parentheses? This is ugly and stupid." You don't get all these reactions that maybe experienced programmers have.
Maybe this is the arrogant Lisp weenie in me talking. But, yeah, it's just another programming language. It's just different. It just looks a little bit different, at least when you're starting.
The JVM aspect of it, I feel like that's kind of a different category of things to know about. Probably the more difficult aspect definitely was functional programming. It definitely was for me.
One of my first Reddit posts in the Clojure subreddit about Clojure when I started learning it, I had been learning common Lisp thanks to Conrad Barski's book, Land of Lisp, which was super fun and I loved it. I was coming from that. And so, when I was learning common Lisp, I was like, okay, well, how do I get objects? There's the common Lisp object system. I was like, okay, this is kind of neat. Oh, it's more objecty than any other object thing I've ever learned. Crazy objects in meta programming everywhere. That was cool.
Then I came to Clojure, and I asked, like, "Okay. How do I make my objects?" The kind folks in the Clojure subreddit were like, "Okay. Hold on a second there. Let's talk about whether or not you actually need objects and whether or not you actually want to use them."
I was confused and angry. I said, "No, I love objects." You know, like, "Don't take them away from me. How dare you."
That was definitely, I think, the more difficult transition for me and for other folks, especially coming from Ruby, where–I think probably Java too–I spent a whole ton of time investing in learning about object-oriented design, patterns, and all this stuff. Just to learn: Hold on. You don't need that stuff. Your life is a lot easier and simpler if you do it this other way.
You have to think about it a little bit differently, but maybe part of it was just learning to let go of all that time investment I had made. But also, it was definitely a different way of thinking.
Syntax, I feel like, was not that hard to pick up, but just really changing your habits of breaking down a problem. That was the challenge.
CRAIG: Mm-hmm. Yeah, I think your experience very much matches most other people's or at least mine in that it was the shift in thinking and much, much less the syntax that was the big deal, which I suppose is unsurprising when you think about people.
DANIEL: Yeah.
CRAIG: All right, so I want to turn to the future a little bit in the form of a couple questions, one of which is: Do you feel like you have another book in you? I always feel bad asking authors this question when their publication of their previous book is fairly recent because I know it's an ordeal that, for most people, takes a little getting over. But do you think you would?
I guess maybe two questions: Would you do it again? If so, whether or not that's true, do you have thoughts that you would do it again on a different topic?
DANIEL: Yeah, well, Craig, you know, I've been going through all this therapy to deal with the last book.
CRAIG: Yeah.
DANIEL: Now you bring it up again. No, I've been getting back into writing. I did, after I finished the book, I definitely stopped for a while and just started fiddling around with doing more of the programming project ideas that I had and getting into single page apps, Hoplon and Reframe - super fun.
But, in terms of what's next, it's funny that you say you're talking about the future because I have been writing what I think will become kind of a mini ebook just on parallelization. The goal of it is for people to understand the reducers library, but the larger goal is for people to understand what is parallelization, why does it matter.
Kind of an example app that I have for this little, mini ebook is a palm-reading application. The idea, like a palm-reading application, is that you take your iPhone, and you turn it so that its camera faces your palm. You take a little photo, and you get your future told to you. The name of the app is iFacePalm.
CRAIG: You are a master of naming, sir.
DANIEL: Well, thank you.
CRAIG: I love names. Names are great, and that is a good one. Yep. Okay. All right. Where do I invest, by the way? I want to be your Y Combinator for this effort.
DANIEL: I have an Ethereum account set up now. Bitcoin, if you don't know, is passé.
CRAIG: Right.
DANIEL: Ethereum is the future. We're talking about the future. I can share the details with you, I think, offline.
CRAIG: All right, great. I will not be posting that because this is just something I want to keep to myself for when you make $1 billion with iFacePalm. By the way, as an aside, some of the people here invented an alternate currency based on bacon that they call Bacoin. I wonder if you'll accept Bacoin. That'd be good.
DANIEL: Well, as a vegetarian, I'd have to decline.
CRAIG: It might be vegan, just like Ba-Cos are vegan. I don't know if anybody is aware of that, but Ba-Cos is the little bacon bits you get in the saltshaker type thing and contain no animal products whatsoever.
DANIEL: Okay. Well, sure then.
CRAIG: It's possible that Bacoin is vegan. I'll look into it. I certainly wouldn't want to send you a big pile of pig flesh, but we can work on the Ethereum thing too.
Okay. Well, this is cool. You said you're working on this little ebook, and you've been playing around with single page apps. I'm curious to hear more about this. Are those two things connected somehow, or you were trying different technologies and that was one of them?
DANIEL: Oh, yeah. They're not connected.
CRAIG: Okay.
DANIEL: Yeah. Well, for the book, for Clojure for the Brave and True, I started to have a section on reducers. I was like: I can't explain this in the time that I want to finish this book. It would take too long to really figure this stuff out and explain it.
My kind of M.O., I guess, when it comes to writing is to look at a Rich Hickey post or watch one of the talks or something and just sit there and say, okay. This sounds really cool, but it's too far beyond me. Then I go, sit back, and say, "Okay, how do I explain this thing?" Not to say that he's bad at explaining things. There are often times when there'd be a lot of assumption of knowledge, which I simply don't have. I didn't know what parallel programming was, so of course I don't understand what reducers are and why they matter.
I started to learn about reducers. I thought it was real interesting. I learned a lot about parallel programming in the process of writing Clojure for the Brave and True, but I just couldn't really fit it in there. But, I thought it was super fascinating stuff. It's really interesting, and so now I actually gave a talk. Oh, I just found out today that I will be doing a talk on parallelization for Clojure/west, so it's very awesome.
CRAIG: Congratulations!
DANIEL: Yeah, thanks. Yeah, so I'm looking forward to that. It's just fascinating, but completely separate from the single page app thing. I don't know. I just have goofy ideas sometimes.
CRAIG: I think it's a great sign. I don't think it's possible to succeed without having a whole bunch of widely varied – I mean maybe there are people out there that are like, "I want to do this one thing, and I go straight towards it," and they never veer off on the side. I find that when I talk to our guests who are producing just fascinating work, they've generally got six or seven unrelated things going on in their lives.
DANIEL: Yeah.
CRAIG: Speaking of the future and everything, you have recently shifted gears a bit career-wise, isn't that right?
DANIEL: Yes. Yeah, that's true. Yeah. Back in, I think it was, April of last year, I had been working at McKinsey and Company, the consulting company, for about five and a half years. I decided to quit and do nothing for a while, or just do nothing that paid me anything, anyway.
I don't know. I just felt like I had a chance to do that, and so I wanted to take it. It was nice working at McKinsey, but I just wanted to say, "What would it be like to not work? What would that be like?" It turns out that it was pretty awesome.
CRAIG: I'm glad to hear that. I'm glad to hear that. Yeah.
DANIEL: I don't know if many people would suspect that, but yeah, it was great. And so, during that time–I don't know–I did yoga. I feel like I had a lot of experience working with this one pose called Programmer's Pose, for most of my life. Just – yeah.
CRAIG: Yeah, I'm familiar. Yeah, I'm still getting over it, frankly. Anyway, go ahead.
DANIEL: Yeah. Well, yeah, so I started doing yoga to kind of help with that, and that was really cool. I really enjoyed it.
I finished my book. I worked on some other stuff. I started to learn Om, not Om Next, Om Current or Om Now. I'm not sure what it's called. I think it's Om Now.
CRAIG: I think we call it Om Heritage. Yeah. No, I'm kidding. Anyway–
DANIEL: I like that. I think that's what it should be. Yeah, so I was learning this before there was even a whisper, I think, of Om Next.
CRAIG: Your path was through this period of reflection, I think it's fair to say, and exploration. Where did it land you?
DANIEL: Right now I'm working at Adzerk. I'm working there part time two days a week. That's mostly so I can focus on – I mean I work at Adzerk because the people there are awesome: Alan Dipert, Micha Niskin, the guy that's behind Boot and Hoplon. Alan, by the way, is the person who got me introduced to Clojure, and that is a fun story, so I think I'll share that if that's okay.
CRAIG: Please.
DANIEL: Okay, cool. I think, back in, like, 2012 or 2013, or something, I was working at McKinsey. I'd been using Common Lisp for a while. I went to their New York office for, like, this quarterly developer day thing, and we had a guest speaker named Alan Dipert. I didn't know who he was or anything, but he talked about this language called Clojure. I was like, "Oh, my God! This is a Lisp. This is really cool."
He started talking about it more. I was like, "Wow! This looks way easier to use than Common Lisp. It's a lot less verbose and I can use JVM stuff, so I can actually be productive with it," at least for what I was trying to do. I was trying to make this kind of online game, which never went anywhere. It just looked super fascinating, and Alan, as you know, is a very funny and entertaining speaker, so it got me really intrigued.
About six months or so later, I think I ended up moving to Durham. I think it was like nine months. Anyway, I moved to Durham, and I went to a Clojure meet-up. I didn't realize it then, but Alan was the organizer. I didn't recognize him anymore. I guess he had shaved since then or something.
But, yeah, it was like, "Okay, is anyone new to Clojure or is this your first meet-up?"
I was like, "Yeah, this is mine."
He was like, "okay, well, how did you get into Clojure?"
I was like, "Well, this guy gave a talk back in New York a while back at McKinsey."
Actually, I didn't say where it was because McKinsey folks are really cagey where I worked.
"That's how I got interested in it."
He was like, "Where was it?"
I was like, "It was in New York City."
He was like, "What was the name of the company?"
I was like, "It's McKinsey."
And he was like, "I was that guy."
Oh, my God. Yeah, but anyway, now I get to work with him. He was the technical reviewer for the book, and it was awesome.
CRAIG: Alan is great. He and I used to work together a lot when he was at Relevance and I really enjoy him. He's been a guest on the show multiple times, and I suspect you are far from alone in being the person who saw him speak about Clojure and decided that it must be a good idea. He's a very excellent speaker, very convincing, and obviously a deep thinker. The work that he and Misha have done are really good stuff. Boot, Hoplon, and all the rest of the things that they've come up with are super interesting.
DANIEL: Yeah. Yeah, absolutely. Super happy I get to work with them, and so it's two days a week. The rest of that time it's writing.
Actually, I'm working on a couple programming projects. I'm working on a kind of Clojure-only job board, but then also a place where people can post their open source projects. I've been noticing where people are asking, "How can I get involved or do something?" so I think that would be a nice resource for the community. The job board would be paid. The open source part would not be because that would be terrible.
CRAIG: It would be a little odd, for sure.
DANIEL: Yeah.
CRAIG: I have a question for you. This is something that we have guests on a lot, and they're all very humble people despite their accomplishments. I think they're hesitant to self-promote, but I have to ask you. It sounds like you have a few days a week where maybe you could take on – are you looking for work? Should people feel free to contact you for a contractor?
DANIEL: That's very kind you'd ask, but no, not right now.
CRAIG: Okay.
DANIEL: Yeah, I'm good.
CRAIG: Awesome. No, that's fantastic. I'm sure people would greatly benefit from your assistance, but it sounds like you've gotten yourself to a wonderful place, so kudos to you, sir.
Well, cool. Well, so we've covered sort of past, present, and future. We probably should start winding down a little bit so we can both get back to the things that we need to do that aren't these enjoyable conversations. Before we do wrap up, I want to make sure that I give you a chance to talk about anything that we didn't get to today. If you have anything in mind you'd like our listeners to be aware of or that you'd like to share, that'd be great, before we get to our final question.
DANIEL: Hmm. There was a little bit I wanted to talk about something that's been interesting me a lot. It's nonviolent communication. This is a completely different subject. It's really non-technical.
CRAIG: Please, let's talk about it. Yeah, absolutely.
DANIEL: Sure, sure. This is actually part of what prompted me to quit was to kind of pursue, well, how could I do something with nonviolent communication. I'm still exploring that, but it's interesting to me.
At the time, one of my ideas was maybe I could write something called Nonviolent Communication for Programmers. The title kind of makes me laugh because when you think about some of the maybe not friendly conversations that you see online, like on Twitter or from Linus Torvalds or other folks online, it's very easy. We collaborate a lot online, and online is very easy to be not very nice to folks.
CRAIG: Maybe you're getting there in a second, but could you define what nonviolent or, by contrast, what violent communication is?
DANIEL: Yeah, sure. Nonviolent communication is almost like a template for communicating with people, like in conflicts, developed by a man named Marshall Rosenberg. There is a book out there called Nonviolent Communication, which really explains it very well.
The idea behind nonviolent communication is that when you find yourself communicating with someone by perhaps labeling them or blaming them in various ways. Like for a child you think, "Oh, you didn't clean your room. You're so lazy." Right? What the book talks about is just taking a step back and saying, "Okay. What's actually happening here?"
Saying, "You didn't clean your room. You're lazy," that would be an example of violent communication. The way I think about it is that you're reducing a human being to an object by perhaps trying to coerce them through guilt or just through aggression to do something different because you want them to.
The idea behind nonviolent communication is the reason why we talk this way is in part because we're not clear about what it is that we actually need, what our own personal needs are, and we're not clear about what our feelings are. In these moments when you speak to people in such a way, it's like, "Oh, God. How could you push that release? We lost 10,000 orders. You're an idiot." When we talk to people like this, a much more effective way to talk to people is to identify what is your need.
In the example with the cleaning, it's like I have a need for a clean house. When you don't clean like I would like you to, I feel like you don't respect me. Maybe the need actually there is for respect.
In the nonviolent communication process, you make a specific request. "Can you please clean your room now?" something like that or, "Can you please at least say that you hear me, understand what I'm saying?"
What's interesting about this to me, this process of identifying, saying this event happened, like you didn't clean your room. I feel X about it. I feel upset, or I feel sad, or I feel angry because X need wasn't met. My need for beauty in my home, or my need to feel like my child listens to me and respects me.
This process of saying these things and then making requests, "Can you do this to help me meet my need?" is so different from saying, "You didn't clean your room. You're lazy," in a couple ways. One is that I find that actually trying to understand what is your need in that moment is incredibly powerful and liberating.
Now you understand what's actually going on inside you. You understand this is why these emotions arise. You don't have to just react. And you understand instead of feeling like someone else has this power over you, they're doing things and now you feel bad and want to act out on it, you understand, "Oh, wait a minute. Okay. I have these needs. I can work in a kind and loving way with this other person to get these needs met." We don't have to argue at each other.
The premise, one of the premises of nonviolent communication is that there are no conflicting needs. Perhaps there are conflicting strategies for meeting those needs. But, through this process of conversation and sharing your needs with each other, then you can come up with some kind of strategy that works for both people or for all people where their needs get met.
To me, I've thought about this in relation to work life and programming life, collaborating with other people, or collaborating with customers. I don't know. I just think that this process, what you end up doing is getting in touch with yourself and what's actually going on for you in a way that I think that a lot of times most people, myself included, don't really do. When you do that, I think life becomes a whole lot easier and the amount of conflict that you have in your life gets reduced immensely.
I don't know. I just care very much about it because I feel like definitely there are so many facets of life these days, which have enormous amount of conflict in them, beyond programming, but on a larger, political scale.
CRAIG: I find this really fascinating. I think, to the extent that I have enjoyed success in consulting, I feel like it's really fallen out. Yes, to technical ability, I've worked hard to make sure that my technical ability is up to the level that it needs to be. But, to the extent that I've been successful in consulting, I feel that, to a very large degree, it's about understanding that software is fundamentally about people.
DANIEL: Yeah.
CRAIG: In a really, really deep way. But, the thing that your comments make me think of is that I've always approached that. The tool that I've used is: Try to understand it from the other side, typically the customer. What do they want?
DANIEL: Mm-hmm.
CRAIG: It's really interesting to hear you discuss nonviolent communication and the emphasis, at least in part, on understanding what I want.
DANIEL: Yeah.
CRAIG: Or what we want from the other side. It sounds really complimentary. I'm going to have to really think hard about how to put that into practice. I should add the book that you mentioned, which I guess is titled Nonviolent Communication–easy enough to remember–on my reading list and move it up towards the top. That's very, very interesting.
DANIEL: Yeah. I'm glad I piqued your interest.
CRAIG: For sure.
DANIEL: It's a great book.
CRAIG: I feel like we could probably do an entire show about that topic and about how it relates to software, at least, but maybe we will leave that for your next appearance on the Cognicast. Unless you had anything else you wanted to talk about today, it seems like a great place to wrap it up and say until next time.
DANIEL: No, no. Thanks for giving me the chance to talk about it. Definitely it would be awesome to come on again, and we can chat about it some more.
CRAIG: Yeah, for sure. Okay. Great. Well, like I said, this seems like a great place to put a bookmark in this conversation, get it out to people, and pick it up again some other time. I do have one more question for you, as we always do. And so frequently happens, you have already imparted a great deal of advice, excellent advice I might add. But we do, of course, always ask people to end the show–guests end the show–by providing a little bit more advice or sharing advice, I should say. This might be advice that you've received, advice you've given or like to give, or possibly just advice you've overheard. Hopefully you've had a chance to think of–since I warned you about this as well–a piece of advice you'd like to share with our audience.
DANIEL: Yeah, sure. My advice for the audience is to read a book. It's an excellent book. It's called A Mind for Numbers, and it's by a woman who thought that she was terrible at math, just would suck at engineering, and ended up becoming, I think, a professor of engineering. She describes new things that researchers have learned about how people learn.
If you want to learn a new programming language or anything technical, or really, I think, nearly anything, at least when it comes to knowledge things, this book, A Mind for Numbers, is great. It's full of extremely useful advice about how to effectively, effectively learn. Don't waste your time doing things that really don't help you, like a lot of times people do things like reread something that they've read. It's like, "Okay, I get this now." Not the best way to approach learning. The book has more. It's excellent. It's called A Mind for Numbers.
CRAIG: Very, very cool. I think anything that makes us better at learning winds up making us better at everything. Not only better at everything, but better at getting better, so that's high leverage advice.
Well, Daniel, thank you so very much for coming on today. I really enjoyed our conversation, as I have every time that we've had a chance to talk. It was really nice to be able to sit down with you today for longer than we had, say, at Clojure/conj, which was the last time I saw you.
DANIEL: Yeah.
CRAIG: Thanks a ton for coming on. Really, really fascinating stuff. Your book looks great. Like I said, I very much want to read it. I also particularly enjoyed the conversation at the end about nonviolent communication, so thank you many times over for all those things.
DANIEL: Thanks for having me. It's been such a pleasure, and I enjoyed it too. It's been really great, so thank you.
CRAIG: All right, well, we will close it down there. Thanks to Daniel again, and thanks to everyone for listening. This has been the Cognicast.
[Music: "Thumbs Up (for Rock N' Roll)" by Kill the Noise and Feed Me]
CRAIG: You have been listening to the Cognicast. The Cognicast is a production of Cognitect, Inc., whom you can find on the Web at cognitect.com and on Twitter, @Cognitect. You can subscribe to the Cognicast, listen to past episodes, and view cover art and show notes at our home on the Web, cognitect.com/cognicast. You can contact us by tweeting @Cognicast or by emailing us at Podcast@Cognitect.com.
Our guest today was Daniel Higginbotham, on Twitter @nonrecursive. Episode cover art is by Michael Parenteau, audio production by Russ Olsen and Damian Mack. The Cognicast is produced by Kim Foster. Our theme music is Thumbs Up (for Rock N' Roll) by Kill the Noise with Feed Me. I'm your host, Craig Andera. Thanks for listening.