Real World Examples
I talked with Dave Rael about running and education service, the appeal of functional programming, the lessons of computer science applied to life, and really listening.
Transcript
[00:00] [background music]
**Dave Rael**: [00:02] Developer On Fire" with Dave Rael, expressing, exposing and sharing the humanity of software geeks since 2015.
[00:08] [music]
**Dave**: [00:09] Today's episode is brought to you patrons of the show and by Codeship. Codeship is a hosted continuous integration service that lets you ship your apps with confidence. Choose between Codeship Basic, a simple out-of-the-box testing and deployment service with pre-installed CI dependencies that works out of the box.
[00:34] The average set of time for Codeship Basic is less than three minutes, or give Codeship Pro a try. Codeship Pro is a fully customizable, continuous integration and delivery service with Docker support. It makes it easy to test and deploy your micro services and push to any registry.
[00:50] It's also perfect if you want to deploy with Kubernetes, and comes with a convenient local command line interface tool that allows you to run your builds locally, helps encrypt your environment variables, and guarantees 100 percent parity between your development and production environment.
[01:06] Both Codeship Basic and Codeship Pro come with a free plan that grants 100 builds per month, unlimited projects, and unlimited users. Open source projects are always free on Codeship. Visit codeship.com today or check out codeship.com/features to find out which Codeship product is the best fit for you.
[01:24] What's happening geeks? Developer On Fire — firing up geeks everywhere. I'm stoked to present today's special guest, Eric Normand. It's a pleasure to have you here, Eric. Let's light this thing up. Does that work for you?
**Eric Normand**: [01:35] Yeah, let's get going.
**Dave**: [01:36] Eric Normand is a long time functional programmer, excited to see at entering the mainstream. He loves teaching and cooking. You can learn functional programming from him at PurelyFunctional.tv and read his thoughts in the PurelyFunctional.tv's newsletter. If you visit him in New Orleans, you can meet his wife and daughter. He'll even make you some gumbo if you tell him you're coming.
[01:58] That is a regional bio that tells us some things about you, Eric. Some of your interests in this long time functional programmer thing being functional before it was cool, I think is something interesting we'll talk about. Before we get into any of that, I want to find out more about Eric the person. Who are you personally? What makes you tick?
**Eric**: [02:18] I was born and raised in New Orleans. Been doing programming for quite a long time. I remember, when I was six or seven years old, my mom was in a conference with a teacher, and I was there, too. The teacher asked what I would like to do when I grew up. I somehow said, "Computer Programming." I don't think I really knew that was, but I don't know why I thought of it.
**Dave**: [02:47] That's funny. Something appealed to you about it, somehow. That's pretty wild. You've always been a New Orleans person. That's pretty remarkable. I imagined that the Katrina time frame has that special significance for you. What was that like for you?
**Eric**: [03:06] I, actually, was lucky enough to be out of town when it happened.
**Dave**: [03:11] Oh, wow.
**Eric**: [03:13] I was actually in the Peace Corps in West Africa during that time. Funny story. I was in training for the Peace Corps. A lot of the other volunteers were talking to their parents regularly — once a day, once a week. One day, people started coming to me, "Hey, I heard that there's a really bad storm in New Orleans."
[03:37] Now, I wasn't getting any news from back home. I had lived abroad before. My parents were just like, "Oh, he's gone. We'll talk later." I kept getting people saying, "I think there's some big storm," and I was, "Ah, there's always a big storm. New Orleans has hurricanes every year. It's probably nothing." That went on for four, five days, and I wasn't worried at all.
[04:06] It's always overblown on the news, whatever. Then, one day the head of training — who usually wasn't there — he came up to me and he was like, "We got a message from your parents. They said they're OK."
**Dave**: [04:22] Oh my gosh.
**Eric**: [04:23] Yeah. Hearing that, I was, "Oh, wow! If my parents are trying to get in touch with me, there must have been something big." That's when I started digging deeper and realized how bad it was.
**Dave**: [04:37] I can imagine that being away might even been worse than being there with worry and what not. It sounds like you dismissed it until you heard...The first thing you heard was "We're OK," which, I guess, [laughs] it eases a lot of that suffering. That's pretty remarkable.
**Eric**: [04:52] Yeah. Exactly. The other thing was there wasn't anything anyone could do, whether you were here or elsewhere. It's not like you could just come back and start helping people. At that point, there really was...The water was still in the streets. They were just trying to get people out of the city. It wasn't like I should go back and start rescuing people or something like that.
**Dave**: [05:17] Yeah. Sure. It reminds me of when the Columbine school shooting happened. I was not in Denver at the time. I was in Omaha. Somebody came and told me, "There was some kind of shooting at a school in Colorado, and it starts with a C." Of course, my immediate thought was, "Oh, my cousin goes to Chatfield High School."
[05:35] It was pretty frantically scouring for information pretty quickly there. It wound up being, obviously, a very big deal, but it wasn't as closely personal to me as it could have been.
**Eric**: [05:50] No, it wasn't personal.
**Dave**: [05:51] Interesting stuff. You were a functional programmer before it became the in thing to do. How did that come about?
**Eric**: [06:01] I first saw Lisp — I think it was Common Lisp — in college, in an AI course. This was when AI was still about game trees, simple parsers, and stuff like that. Now it's all statistics. I liked it. I got it. I got the idea that there was this list data structure, and all your stuff is just operating on that. That felt nice. I wasn't that good at it.
[06:33] I remember the teacher saying, "Oh, you could have done this in a more efficient way." I was like, "You gave me two days to do it. I'm learning a new language. Come on." Then what happened was, I wanted to write a game. I had some time on my hands. I was still in college, and I didn't want to have to deal with C. All the games at that time were written in C.
[06:57] I just looked at, "I'll have to do all this challenging game programming, plus I have to deal with memory." I just didn't want to do that, so I started looking around for options for other languages. I started looking, also, at maybe writing my own language. I came across an interview of Richard Stallman, who created Emacs.
[07:27] He was talking about Lisp a little bit, and how Lisp was something you could write in a weekend. You could write an actual implementation of Lisp very easily, so I got intrigued. I started writing my own Lisp implementation. That was so fun, I never got to the game. It had a garbage collector. It had a HashMap implementation and a little interpreter.
[07:53] What was so cool about it was it was a missing piece of my computer science education. All of this parsers and garbage collectors. I never did anything like that.
**Dave**: [08:09] You became enamored with this exercise of create a language interpreter, or a parser, or whatever it was. That captured your imagination more than solving the problem at hand, right?
**Eric**: [08:23] That's right. Now, I think I would be a lot more practical, but, of course, there's a lot more solutions out. That was back in 2001. Now you can start doing game programming with Unity right away.
**Dave**: [08:37] Has gaming always been something that matters to you?
**Eric**: [08:40] I'm not a big gamer. I used to play a lot, but I was never any good. The thing with me is, every time I would play a game, I would feel like, "Oh, I want to be making the game." I had so many ideas for how it could be better or different in the way I would want it to be run.
**Dave**: [09:02] The reference to the daughter in the bio. How old is she?
**Eric**: [09:05] She's four-and-a-half.
**Dave**: [09:06] Four-and-a-half, OK. I was wondering if you've got her writing any code yet, but that's probably a little early for that. [laughs]
**Eric**: [09:11] No, a little early. We don't really let her use a computer yet, or an iPad, or anything like that. We do have a game called Robot Turtles.
**Dave**: [09:23] Oh, sure.
**Eric**: [09:24] Have you heard of this?
**Dave**: [09:25] I have, yeah.
**Eric**: [09:27] It's a cool board game that teaches...I would say they're super-basic ideas, but really important ideas, like the idea that you can describe actions separate from doing them. At some point in the game, you lay out the actions for your turtle to take. Then the adult who's playing is supposed to do the actions and actually move the turtle.
[09:56] Just that thinking about separating the action from the description of the action that we do as programmers is one of the most fundamental things in programming.
**Dave**: [10:11] It's pretty cool. I think I heard about it from Scott Hanselman. On his was where I first came across that. I think it was in the Kickstarter time. Yeah, my kids have really enjoyed that. I know my son just...He wants to play that all the time and it's a lot of fun.
**Eric**: [10:26] I look at things like that. Computer science is actually really telling us a lot about our world, about how things work, in a way that we didn't have the description for before. The whole idea of universal computation. Why sorting stuff takes a long time. Things like that. I think that a lot of people don't know that.
[10:52] My daughter is at a school. There's a debate at the school. Like, "Should kids be learning computing and stuff like that?" What they mean is, should the kids learn how to use apps? Should the kids be tapping buttons, and moving windows around, and stuff like that? To me, that's totally uninteresting. One side of the debate is saying like, "That's not important. It's not important."
[11:18] What is interesting is the more computer science side, which no one else, none of the non-programmers at my school even have glimpsed into. They don't know that this is a whole thing. I have a book recommendation — "Algorithms to Live By." It's actually a really cool book. It talks about why does it take longer to do laundry in big batches as opposed to small batches.
[11:52] It's because you have to sort your laundry. Sorting is, at best, N-login. If you have a smaller N, it's actually going to take longer. If your batch size is smaller it's going to...Sorry, if it's the smaller N, it's going to take less time. You're better off doing two or three loads instead of letting it pile up and doing one big load if what you're concerned about is time.
[12:16] Same thing with dishes. You have all these dishes laid out on your counter. You're looking for the dishes that you need. That every look is like an order-in operation, scanning around on it. If you could keep that batch size small — meaning do dishes more often — it actually takes less time which...As someone who's a slob...
[12:40] [laughter]
**Eric**: [12:40] that actually speaks to me as a programmer and a slob. It's like, "Oh yeah, that's why people like to keep their dirty dishes down to a minimum."
**Dave**: [12:54] That's interesting. Nonlinear run-time. Something that's greater than linear, then you have greater inefficiency with these larger batches than just doing the thing in the first place. I guess it's really just a better way to live to keep things neater. I like that.
[13:12] Applying run-time analysis to the way you live your life. That really speaks to the efficiency geek in me. The self-optimizer, that kind of thing. That's really appealing.
**Eric**: [13:24] Yeah, and the book is much deeper than that. It's all about how algorithm make thinking in computer science analysis is actually shaped...It actually explains a lot about how we already think and how you could analyze it in model things and very precise ways that are analogous to known problems.
**Dave**: [13:46] That's really cool. I was looking at the About page on PurelyFunctional.tv. It was talking a little bit about being created out of your desire for some better materials around teaching functional programming. Can you tell me a little bit that experience? What was it that you were looking for and that you were trying to create?
**Eric**: [14:08] There's a lot of books in object-oriented programming space. Object-oriented programming hasn't being around as long, but it's been big in the industry. There's a lot of good books like industry books, whereas, when you look at functional programming books, they're more academic.
[14:30] They're more about how to use these interesting type system or how to do AI research. Things like that. There isn't so much about actually making production software with functional languages. I'm thinking about very practical books, like "Refactoring," that define the term. The term existed before, but when we think about refactoring, what we think about is the stuff in that book.
"[15:04] Design Patterns." I'm not such a big fan of Design Patterns myself, but, in terms of affecting an industry, it's a seminal book. We just don't see that with functional programming. What are the design patterns in functional programming? What are the best practices? How do you break down an application into parts in a functional way? No one is really taking about that.
[15:36] Maybe they talk about it a tiny little bit, but there isn't a tome that's like, "Here's a hundred ways of doing it," like you have in object-oriented land.
**Dave**: [15:46] I guess that's the appeal, to me, of Design Patterns, that you've got this authoritative reference, and you've got this vocabulary terms. I can speak to you in meaningful terms by using these things that we share in common. This understanding of certain things.
[16:03] That's really what it was that you were looking for — Where do I find that information that I can then talk to somebody and we can just have this common ground to share? Am I close on that?
**Eric**: [16:13] Yeah. That's a big part of it, just having some common understanding. I know, when I was first learning Lisp, so much stuff was still on Usenet. I would search through old Usenet posts to see how people solved problems. That stuff is basically lost. It's just in Lisp programmers' heads.
[16:40] The longer it's in their heads, the harder it will be to get it out into some kind of more modern form, I guess, is what I want to say. I learned so much. It's such a rich resource, but, of course, no one did the work of putting it into more easily digestible form.
[17:02] I have started [laughs] doing stuff like that. I don't know if I'll ever finish, but I started compiling things like that. Maybe I'll get it into a book one day.
**Dave**: [17:14] Remarkable. The picture that came in mind is ancient humans passing things on through word of mouth, eventually getting it down into something along the lines of a Bible or something like that. The written history follows the oral history, and I guess that's a part of the thing.
[17:32] Tell me about PurelyFunctional. What is it that is there that's available for listeners that they can go check out, and why should they be interested?
**Eric**: [17:43] Right now, PurelyFunctional.tv is me teaching Clojure, mostly in video form. It's about 38 hours. I keep adding to it, so it's probably more by the time you listen to this. 38 hours of video of varying topics surrounding Clojure. There's intro to Clojure. There's Web. There's core.async. There's a bunch of stuff about basics of functional programming, stuff like that.
[18:15] It's not nearly complete. I have grand dreams of finishing Clojure, and being like, "There, that's it," but, so far, people keep asking questions. There's new libraries all the time. There's new topics. Really, I can't keep up with all the new stuff going on. I don't know if I'll ever do that.
[18:38] It's a subscription service where you pay a monthly fee or a yearly fee, and you get access to all the videos, and you learn Clojure.
**Dave**: [18:50] OK. It sounds like a lot of it is user-driven. You mentioned questions driving some of the content. Is that right?
**Eric**: [18:57] Yeah. I try as hard as possible to answer actual problems that people have. It's really easy to just talk about stuff that is either obvious, that no one really needs explained, or not really explaining it as in terms of an actual problem. It's really easy to just talk about the syntax of Clojure.
[19:22] No one really has trouble writing out numbers with decimal points. It's nothing.
[19:27] [laughter]
**Eric**: [19:29] It's really important to me to get a lot of feedback from people who are actually learning.
**Dave**: [19:34] Yeah, the programming world could certainly use some better examples of things [laughs] to work on, for sure.
**Eric**: [19:41] If I can complain a little bit, one of my pet peeves is people who understand Clojure and don't really teach it, but telling me that, "Oh, you need to talk about this kind of scoping because it's the perfect thing," or, "You need to say that that's a vector." No one cares.
[20:00] [laughter]
**Eric**: [20:01] No one has ever asked me that question. It's just the typical way that people explain it, I try to steer clear of those typical ways. I'm not really focused on avoiding the typical ways. I'm more focused on solving real problems.
[20:21] I have this example that I pull out a lot. In some books, where they explain how the number system works, a lot of times I'll just read a paragraph in it and I'm like, "No one really has this problem with numbers. What is the problem that this paragraph is trying to solve?"
[20:42] The text is dense, and knowing how it works, I can see how it's technically correct, but no one is going to learn how it works by reading this. I try to avoid all of that. My biggest thing in teaching is that there's always some physical metaphor, a social metaphor, something from real life that we're doing in our programming language.
[21:07] I mentioned laundry before. This is actually a really cool topic. I'm really interested in how these functional programming concepts are actually stuff we do all the time in the real world, but we have divorced in our minds programming from the real world in a lot of ways. We're so used to programming in a certain way, we don't realize that, even in our everyday lives, we're doing something.
[21:39] If you tried to explain to someone that sorting is actually hard, and you gave them five things to sort, and you say, "Look, Bubble sorts the worst." They're like, "What are you talking about? It is so easy to sort five things. I can do it in three motions, right? Just move the first one..." They're like, "Why is sorting hard?"
[22:01] If you gave them a hundred things or a thousand things, then they would start to see. "Oh, yeah, the time it takes me to travel from there to there, and move it to the end. Now it's starting to take a ton of time." I try to bring those visual, physical metaphors to my teaching.
[22:23] For instance, I have some videos called "Three Functional Tools." The three functional tools are map, filter, and reduce. I was on a call with someone, pairing with them, and they were like, "I don't know how to make this more functional." I was like, "Well, why don't you use map here? Why don't you use filter here?" They're like, "What are those?"
[22:45] I'm like, "OK, I need to make videos about that," because, to me, that's one of those things that is obvious, because I've been doing functional programming for so long. Anyway, in the videos, I redid them several times, and finally, the last time, I was like, "I need something more concrete." I went around my house and I looked for every kind of filter I could find.
[23:08] I got coffee filter. I got an air conditioning filter. I got a sieve for pasta. A bunch of things like that. I just kept pulling them up in the video, like, "This is the same thing. We're pouring pasta water in here. The water falls through the holes and you keep all the stuff you want."
[23:29] Same with an air filter. You're letting something pass through, and then the clean air passes and the dust stays on the other side. It's something that we do all the time. When we try to explain it in computing terms, we just mess it up, make it too, I don't know, technical and complicated.
**Dave**: [23:54] Yeah. I think the real world examples, that's very appealing. That's a good way to teach things. That's really cool. How's it going? Are you finding this education path? Are you getting some results with people learning some things from you?
**Eric**: [24:11] I get a lot of positive feedback and reviews from people saying that they're learning a lot, that they like the style. I have to say this, another brag.
[24:24] When people quit, the most common thing that they tell me when they quit the service, is they say, "Oh, I learned everything I needed to learn," or, "I got a job in Clojure, so now I'm being paid by them to learn, so I don't need these videos."
**Dave**: [24:39] Really?
**Eric**: [24:40] Those kinds of things make me happy. [laughs] I don't like losing the money, but, of course, I'm glad to have been of service.
**Dave**: [24:50] If you're losing customers because you've served them so well, there's a lot of reward to that, I'm sure. That's great. Why Clojure?
**Eric**: [24:56] Wow. I was doing Common Lisp. I even tried to do a little startup in Common Lisp back in 2007. Then, in 2008, I went to a conference. It was a small event for the 50th anniversary of Lisp. The first Lisp paper was published in 1958, so 2008 was 50 years. Part of the theme, the topic of that meeting, was the future of Lisp.
[25:36] Rich Hickey was invited to talk about Clojure, and then he was also on a panel, talking about the future of Lisp. At first, I was very skeptical. It was on the JVM. That's weird. Certainly, it didn't have the same stuff I was used to in Common Lisp. Common Lisp is a very capable, professional, great platform.
[26:00] Clojure, at the time, was pretty new, but I decided to give it a try and I haven't looked back since. That's how I got into it.
**Dave**: [26:12] What was so appealing? Why did you take to it like that?
**Eric**: [26:17] I liked that it had the literal data structures and they were immutable. You did a lot more functional programming than you do in Common Lisp, which is weird to say. Lisps have such a long history that they've had to be on computers with less RAM and less computing power, where it just wasn't that possible to do everything so purely.
[26:46] The compromise is nothing is pure. You can treat it like it's pure if you want, just don't mutate it if you don't want to. In Clojure, the idea is, everything's going to be concurrent eventually, so you might as well start with pure data structures. That was one thing. The other thing was, I was working in Java at my job.
[27:11] Being able to use libraries and my existing code from within Clojure really easily was very appealing. This is an example. Someone at that conference was like, "I want to use Common Lisp, but every time I go to a client, a big enterprise client, and try to sell them on it, they say, 'Well, can it do SOAP?'" There was just nothing for Common Lisp.
[27:43] Before he said that, everyone was like, "Oh yeah, Common Lisp can do whatever you need it to," but it can't do SOAP. It can do Web services, but it's more like RESTful web services. The Lisp attitude has always been, "Oh. Well, you don't really need SOAP. It's kind of a bloated thing anyway," but at an enterprise you do. Clojure closes that gap immediately because it's on the JVM.
**Dave**: [28:12] All right. Cool. A lot of listeners out there are probably listening to this and feeling like there's a lot of appeal, potentially, to functional programming, but not really having a good idea of where to go, how to start some of that. What should an imperative or an object-oriented programmer, what should they know about functional programming? What's the interest and the draw in it?
**Eric**: [28:36] This is the question I ask myself all the time because I do want to have a good answer, and I don't know if I will ever find one. I don't want to give a hypey answer. I went through the object-oriented hype cycle — that it's going to give us totally reusable software, and fewer bugs, and stuff like that. I don't think it's true.
[29:04] What functional programming gives you is a different approach to the problem. Also, maybe, a little push out of your local minimum of the design space that you would think about in an object-oriented problem.
[29:28] Instead of thinking about, "What are my entities and what are their relationships?" you might start thinking about, "Well, what data do I have?" and, "What data do I need?" It's just a different switch in perspective that might be a much easier path to a solution.
**Dave**: [29:52] I like that idea that it's not necessarily a cure to all your problems. It's not the promise that object-oriented was, and I think that's appealing. We always hear, "This is the thing that's going to make the birds sing, and the planets align, and the sun comes out from behind the clouds."
**Eric**: [30:10] For sure. One of the things I really appreciate about Lisp is it has always been the not popular language. It had a very short time in the limelight, but it has always pushed other languages to get better. Even going back to something like the if statement. The if statement comes from Lisp. Before, they wanted to have...Fortran and Algol were supposed to have conditional jumps.
[30:45] They are the ones who pushed structural programming back in the day. Also garbage collection. The idea of having native data structures in your language probably goes back to Lisp instead of just arrays. I see functional programming like that. It's pushing Java 8 to have lambdas in Streams and stuff.
[31:14] It's going to be pushing JavaScript programmers to program using map, filter, and reduce for instance, even though you are not using functional programming everywhere.
**Dave**: [31:25] Sure. Those functional tools are appearing all over the place, and pattern matching is becoming a first-class citizen in a lot of object-oriented languages these days. That's very appealing that it is a bed for innovation, a place for different ideas.
[31:43] Just like you said the local maximum is the place where you get pretty good at something, but then, ultimately, there's a higher peak to scale not that far away.
**Eric**: [31:52] Yeah, right. It's just another bag of tools. I guess the biggest question is — How hard does your language make it? If you have a language that's more suited to functional programming, you would probably have an easier time with it. There's always been this problem where you show what you could do with functional programming and people are like, "Well, I don't really need to do that."
[32:23] It's mostly because it's hard in their language. Without lambdas, it's actually hard to do something like get rid of for loops in Java. You want to be able to pass in a lambda some function, but instead you have to make an anonymous instance of an interface. Then it's like, "Wow. This is more error-prone [laughs] than actually iterating through an iterator or something."
**Dave**: [32:51] Yeah, just doing gymnastics to do things that could otherwise be pretty straightforward. Surety, right? You mentioned the pure by default nature of Clojure as being appealing. Pure is right there in the name of your service as well. What is purity in functional programming and why is it so important?
**Eric**: [33:12] That's a good question. It's kind of a silly term. Let me say it that first. When you have a function, a function can have side effects. Meaning, it might print to the screen, it might write to a file, it might send something over the network. What that means is you can't call it twice without having twice the effect on the world. Now, those are called the impure functions.
[33:45] There are pure functions that don't have any side effects. They're a pure calculation. They take in everything they need in their arguments. The only thing that they do is return a value that they've calculated from that. That's a pure function. Why is that important?
[34:04] Well, sometimes when you have a function that has all these side effects, it becomes very difficult to reason about because you don't know how many times it's going to be called or, at least, you have to keep track of how many times it's going to be called.
[34:23] Whereas with a pure function, you can ease your mind. It doesn't matter if it's called twice. It's not going to change the result. It lets you think a lot more compartmentally. You can say this part is totally safe to call as many times as I need to. I don't have to worry about that any more.
**Dave**: [34:45] It's another one of those things that anybody that's done any testing has experienced that. If I have a function and I'm dealing with input and output and just mapping those things together, then testing is a pretty straightforward exercise.
[34:57] You may not have put the terminology to say, "Hey, this is a pure function versus impure," but that lesson is pretty easy to learn and if you test for any amount of time.
**Eric**: [35:10] Right. For sure. The way I like to think about it, talking about physical metaphors is, if you can you can do the calculation of what you are going to, say, need to buy at the store without actually going to the store and buying it. Often, we confuse the two.
[35:32] If you are doing a calculation in your head, or thinking, or whatever, even if you use a piece of paper like a piece of scratch paper and you make a shopping list, that is totally different from actually going and spending your money at the store.
[35:47] I know, myself, when I write procedural code, I will often just say, "Go to the store. Figure out how much milk you need to buy, then go buy the milk. Go out figure out how many eggs you need to buy. Go buy the eggs." That is mixing what could be pure, which is just thinking, with the actual actions, which is impure. Going to the store twice is totally different from going to the store once.
**Dave**: [36:14] Yeah, deciding what I want has an output that is deterministic and can be done over and over again. Yeah, that's a nice illustration. You mentioned that functional programming is not the thing that's going to solve all of your ills. In our histories, we've all got some big problems and things that have happened.
[36:33] Could I get you to tell a story about a time of failure, a time you failed, fell flat on your face when things have fallen apart?
**Eric**: [36:40] Wow. Does it have to do with functional programming, or anything?
**Dave**: [36:43] Not necessarily. Just something and especially thinking about, maybe, some lessons you've learned from it.
**Eric**: [36:49] OK. I guess here's one. This is not programming-related. I was in the Peace Corps. I was in a small village in West Africa. It's a totally different culture. One of the things that you really have to learn — there's training in it, and then you get a lot of experience — is adapting to the culture and starting to integrate into the culture, which means you start acting like the locals.
[37:18] I was enjoying that process of integrating. It felt really good to integrate into a culture that liked being very social. It liked being nice to each other, sharing with each other, being a part of the community. As somewhat of a loner, it actually felt good to be encouraged to do those things more than just like, "Hey, come do this with me," and I'd say, "No."
[37:50] They would be like, "No, you have to come."
[37:52] [laughter]
**Eric**: [37:52] This is a communal thing. We're all going." Then I'd go and I'd have a good time. I'd learn something and feel closer to everybody. It'd be like, "Oh, that's what integration feels like," because I never felt that integrated in the US in a social group. When I came back to the US, I was thinking, "OK. Now, I get to reintegrate into the US, into the culture here."
[38:23] I really bought into a lot of things that I regret buying into. I know this might not be exactly the kind of thing you're asking about, but the thing about the culture here is that it's very individualist and, so, buying in is actually the opposite of what you need to do. [laughs]
[38:53] By buying into it, I just started to feel like I was in a very...I don't know how else to put it, but in an icky place. I didn't like where I was. I didn't like American culture. I didn't like the way society worked here, so I had to get out.
[39:16] That was like several years of my life of doing that, giving in to the culture, and realizing that something was wrong and then making some choices to get out of it. What I did was I just traveled around the world again.
[39:32] I just went all over to different places, and rekindled my affection for the US culture, and seeing it in a good light again, and then deciding to come back and doing things differently now.
**Dave**: [39:54] Interesting the contrast of those experiences. There's one that is you buying into the culture and having a really enriching experience of learning something about yourself, and the other one taking you further away from yourself and maybe turning you into something that's not necessarily true to your being. It's an interesting contrast.
[40:16] You are an educator and helping people get up to speed. How do you stay current with what you need to know?
**Eric**: [40:22] Wow. My big thing is that a lot of the...One of the biggest problems with computer programming right now is that it's a "pop culture." This is quoting Alan Kay. Things trend and they change all the time needlessly and people don't know the history. They're just looking at Hacker News to see what framework they need to learn next.
[40:57] One thing that I do — here's my individualism coming in — is I try to ignore those channels as much as possible. I go and I read papers from the '60s and '70s. I read books, things that have gone through a long editorial process. Those things tend to be more timeless and, so, always are going to be useful.
[41:26] Now, that said, there are still practical things that you do need to keep up with, especially since people are asking...People ask about reframe. That's what I'm working on right now, is a reframe course. Reframe is a ClojureScript framework built on top of React. Obviously, it's new because React isn't that old, and it's changing pretty frequently.
[41:57] I have to keep on top of it because I'm trying to teach it. I just commit to studying. I read the docs. I try stuff out. I make notes. I try to put things into a larger perspective, like, "Why are we even doing this?" and, "What's the point?" I try to find things that seem to have that kind of perspective. Luckily, Clojure is like that. It's one of the reasons I like it.
**Dave**: [42:26] All right. You mentioned hearing directly from Rich Hickey was the start of your path down to Clojure. Are you still seeing a lot of interesting things out of him?
**Eric**: [42:36] I am. I think that he's got an interesting perspective that's transformed software engineering, in a tiny way at least, and he just keeps applying it. To me, it's the same perspective over and over. He's just the best at it [laughs] and better than anybody else. He is doing it before other people get to that.
[43:06] His last talk at the Clojure/conj in November was about dependencies and dependency management. I had never thought to apply simplicity to dependency management. I felt pain independency management, but I never thought it even practical to try to solve it.
[43:32] He has a lot of good perspectives on what makes it so difficult, what are the problems with it, what are the decisions behind those problems, and the assumptions behind those decisions. If you just go back to first principles and look at it step-by-step, a lot of it is totally created by the solution. All those problems are created by the solutions that we have.
[44:04] It's something that I really respect about him. He's constantly doing the same thing to a new field and it's like, "Oh, yeah. [laughs] That makes total sense. Why didn't we see that before?"
**Dave**: [44:16] Those are the people to attach on to. The ones who look through all the noise and see, "Here is the essence." This is the thing that matters in this question and can just go straight to that thing.
**Eric**: [44:28] Right, and you can see it all the time with him like starting his talk with a dictionary definition. He's like, "What are we even talking about? Let's look it up in the dictionary." That kind of a thing, it's turned into a joke in the Clojure community, but this clarifying thing that no one does.
[44:46] They're talking about dependency management and he'll look up, "What does depend mean? Why are we even doing this?" No one is doing that. They are just hacking on NPM or something. They're just guessing at the issue, trying to patch something up, and never going back to first principles.
**Dave**: [45:11] What has you most excited currently?
**Eric**: [45:13] Right now just growing my business, growing the number of subscribers, trying to find new sources of traffic and things like that. I'm actually really excited about reframe. I mentioned I'm doing a course on it now.
[45:30] I'm actually doing a suite of courses because I pulled my email list and asked them what problems they were having with reframe and ClojureScript, and what they wanted to solve? The number of different things, I thought it would be like four or five little problems that were all related, but no. Everyone had a different problem.
[46:00] It was a huge breadth of different things from how to get it set up to getting the compiler to work both in production, and then also the little details about what this concept is and this one thing. I was like, "Wow. This is big. It's not one course. It's a whole suite of courses trying to cover the whole front-end, back-end web dev thing."
[46:33] That's going to take a while, but I'm confident that it's going to be profitable, first of all. Always have to think about that, but also valuable to people who want to actually make a difference in the web space.
**Dave**: [46:51] What's life like for you now? You've got this business. Is there any other form of employment, or is that really your only thing, and what's a typical day like?
**Eric**: [47:01] Yeah, it's my only thing right now. I started full-time on it in the beginning of November. That's my plan A. My plan B is to get a job. It's not paying all the bills right now, so I might have to fall back on Plan B, but I've still got some runway.
[47:22] My day starts with me waking up at about 6 o'clock, have breakfast, make lunch for my daughter. I wake her up at about 7:00. Get her ready. We hop on a bike and go to school. She's got a tagalong, which is like a third wheel that attaches to my bike with a seat and handlebars.
[47:48] We go we take a nice path down the bayou. Go to her school. I come back, and then I just start with the tasks for the day. Maybe I record something. Maybe I'm doing accounting or admin stuff. Yeah, that's the week.
**Dave**: [48:10] It sounds like a pretty good way to live, pretty good way to do things, and I like it. My final question is to ask you to provide three tips for delivering more value. They don't have to be programming or software related. They certainly can be. Just three things you do and recommend to really make sure you deliver.
**Eric**: [48:26] First one is talk to your users as much as possible. You don't have to do everything they say, but you have to listen. When I say listen I mean like really be empathetic with the issues that they are going through. So often, it's just easy to say, "Oh, this feature isn't supported," or, "That's a user error," but, really, see from their perspective what it's like to use your software.
[48:58] If that's your thing it's a software product. Number two, take care of yourself. It's hard to deliver value if you're sleepy or out of shape. Number three, I guess get some perspective like historical perspective, outside perspective. I like to look at stuff from historical narrative, maybe even a philosophical perspective, ethical perspective.
[49:34] There's all sorts of different ways to see your thing. The more different ways you are looking at it, the better decisions you can make. More often, this is going to be harder.
[49:44] [laughter]
**Eric**: [49:45] I'm not saying it might make it easier, but you'll actually deliver more value.
**Dave**: [49:51] Right on. Right back to what you said about escaping that local maximum, having different ways of looking at the problem, I certainly assist with that. It's great. Before we go, how can my listeners follow you and keep up with what's going on in your world?
**Eric**: [50:03] Go to PurelyFunctional.tv, sign-up. There's a newsletter, which I write every week. It's made to inspire Clojure programmers, so it's about 10 links about stuff I'm looking at and stuff I've found. Not necessarily the news. It's called the newsletter, but often it's very old stuff that I've found. Also I'm on Twitter, @EricNormand. Those are the two places.
**Dave**: [50:30] All right. Sounds good. Thank you very much for your presence today, Eric. It's been really great hearing about what you have to offer.
**Eric**: [50:38] Thanks, Dave. This was a lot of fun.
[50:39] [music]
**Dave**: [50:39] You just heard the amazing and inspiring story of a top notch geek. Thank you for listening. Go and find the show notes at developeronfire.com. Support the show at developeronfire.com/support. Join the community and engage at facebook.com/groups/developeronfire.
[51:06] [music]