PRE-RECORDED SPEAKER: Collaboration between different disciplines in your organization can be difficult, and finding clarity and alignment on both the right problem to solve and the right solution design is even more so. We each approach improvement from our own (limited) perspective, without taking into account the whole story. How is that effective? Paul Rayner's EventStorming Facilitation Virtual Workshop is a multi-day online event that promotes collaboration between different disciplines in order to solve business problems in the most effective way. This virtual workshop with Paul consists of 4 sessions on Sep 28-Oct 1 from 9am-Noon (CDT) each day. To register and get 20% off your ticket, visit virtualgenious.com/events and use the code VGGTC. In this highly hands-on and interactive virtual workshop, you'll learn advanced EventStorming facilitation skills spanning from large scale business discovery to collaborative solution design at the team level. Once again to get 20% off your ticket, visit virtualgenious.com/events and use the code VGGTC. JAMEY: Hello and welcome to a very exciting 200th Episode of Greater Than Code. I am one of your panelists, Jamey Hampton, and I'm here with my friend, Rein Henrichs. REIN: Thanks, Jamey and I'm here with our guests, Damien Burke. Damien Burke started working on Internet startups in 1999 and never stopped. He has been an engineer, founder, CTO, VP, and product manager. Outside of tech, Damien is certified in ontological coaching, hypnosis, and neuro-linguistic programming. He spent several years as a professional poker player, has performed as an actor in theatre, commercials, network television, and film, and currently serves on the board of his local neighborhood council. Damien is the co-creator of EarlyWords, earlywords.io, a tool to help aspirational creatives achieve flow. He is the creator of the Neighborhood Council Management System, ncmanager.org, which supports volunteers working in very local government and he is also the creator of Neverbust.com, the bankroll manager for professional poker players. Finally, Damien offers coaching and consulting for software product teams at TalariaSoftware.com Hi, Damien! DAMIEN: Hi. If I had known that you're going to read the whole thing, I would not have sent such a long bio. [laughs] JAMEY: I kind of liked it, though. It had like, you do a bunch of really interesting things that I want to ask you about now. [laughs] DAMIEN: Yeah. That's the bio for trying to impress people, that's not the bio for reading out and expecting someone to listen. JAMEY: I don’t know, but I’m impressed now so it worked. [laughter] DAMIEN: Awesome. JAMEY: Before I ask you questions about your bio, there is a question that we always ask. You've been on the show before, so you may be expecting it. You've answered it before, but I'm still wondering what is your superpower and how did you acquire it? DAMIEN: Oh, wow. Okay. So I anticipated the first half of that question. I did not anticipate the second half. How did I acquire it? Wow and of course, I have so much anxiety about being asked to say good things about myself. That bio was really hard to write and hear, but I felt the need to be entertaining and say something new, but I don't have anything new. It's the same. It's like, if you can ask me the same question, I'm going to give you the same answer. It hasn't changed. My superpower is being able to hold contradictory beliefs at the same time, which opens me up for a whole world of great and very obvious jokes, which I'm going to try to avoid. JAMEY: I do really appreciate the internal consistency of like, I already told you what my superpower is. This is it. [Laughter] REIN: A little bit ironic, though given what your superpower is. DAMIEN: Which it also is not my superpower and again, those are the jokes I’m trying to avoid! [laughs] REIN: Okay, I have to ask this question, it’s on my mind. So Neighborhood Council Management System says “volunteers working in very local government.” What do you mean by very local government here? DAMIEN: So the city of Los Angeles has what is called the Neighborhood Council System. There are 99 neighborhood councils covering various neighborhoods in the city as an advisory board of the city. So the one I'm on, the Hollywood student council, I'm on the board. I'm the secretary of the board—covers an area of about one of the quarter square miles. I should know this. We have something on the order of 30 or 40,000 residents and multiple other stakeholders. So this is literally the smallest government, as I know, exists in the United States. JAMEY: That's so interesting. DAMIEN: Yeah. I have strong political opinions that government should be as local as possible and democracy only works on a very small scale or at the very least works passing a small scale. What I found out that this exists and I was like, wow, I have to put my money where my mouth or my effort where my mouth is and there I am. JAMEY: That's great. I really admire that. People are like focus at home. I like, I agree with that, but they normally don't mean that close to home as you just said. So I find that interesting. DAMIEN: Yeah. One of the quarter miles, you couldn't walk around it. You know, it's a long walk. You'd be tired most of your day, but it would be nothing to walk the borders of the huddles, the district. Walking every street though, that's kind of a weeklong sort of endeavor. REIN: So you didn't think we were going to let you get away without telling us how you required your superpower, did you? DAMIEN: I was all set to meander into that question and I was like, eh, I had nowhere to go. Let's see, how do I acquire that superpower? Woo, don't want to tell that story, but that's not that true story anyway. Huh? JAMEY: Wait, are you saying that you have a fake origin story for your superpower that's not even true? DAMIEN: Honestly, I think I got [inaudible] this question last time. I don't know how I acquired that power. I came up with a story, decided that didn’t work. Just now I came up with this story that I didn't want to tell, but it wasn't a true story anyway so. It's a true story—it doesn't explain how I acquired that superpower. I will say, maybe not how I acquired it, but how I came to recognize it is through my training in hypnosis and neuro-linguistic programming and greater understanding of the limitations of human rationality, of human cognition—mostly human rationality—and how humans are not rational in the way that we think rationality works. That may not be how I acquired it, that's a [inaudible] of how I came to recognize it. REIN: So Damien, it's good to see you again. There's a whole bunch of stuff we could talk about. I know you wanted to talk about bad code and I'm excited by that. Should we talk about bad code? DAMIEN: I think we should! The last time I was here, [laughs] I loved the title. The [inaudible] to give it the title, Going Off the Rails. I absolutely love that title because we spent the whole time just way off the rails and the philosophy and metacognition. REIN: Largely my fault. [laughter] DAMIEN: Well, you're the host so if you let me go there, I'm going to go there and boy, did we go there. So let's talk about bad code because that's so much more practical and I think it's tightly related. JAMEY: Well, I think the first thing I want to ask you as we had started talking about it is well, what is bad code? DAMIEN: I am so glad you asked because that is the first thing to talk about. When I write about it, I put bad in quotes. Oh, you guys can see me. The people we have on the podcast can see me making air quotes around bad. So yeah, what is bad code? I have a computer science degree from MIT and the thing about being at MIT is that the people there think very highly of themselves and their technical ability and I'm including myself, I was one of them and we tend to have very strong opinions about what was technically bad and technically good and technically correct and technically wrong. And these things sort of infect the people there, infect people in probably a lot of CS programs and infect the people in software engineering teams. So you get these judgments like, “Well, there's a duplication here,” “There's something you can extract there,” “This can be done in three languages instead of four.” Or, “Don't use ternaries,” which is true, don’t use ternaries. Except when you do. [laughs] We have all of these tools that we learn in our CS programs, that we learn elsewhere and we apply them as much as we can and when they're not applied, we think okay, this code can be improved by applying these tools, but that's not always true. Sometimes it's very, very false. So I think I'm going to talk about what really is – so that's what I wanted to talk about when I say bad code, I think. I'm making this up as I go along. Things where our knowledge and our skill and our hard-won technical expertise hasn't been applied to make the most beautiful abstract kind of platonic ideal of what software code should be and that we judge that as bad because it's not there. JAMEY: I was going to say, I'm not sure that I've ever written any code that feels like the platonic ideal of what software should be or worked on any. DAMIEN: Certainly not in the real world, but maybe you’ve got an exercise like that. Maybe you've done – Exercism has great exercises. They’re all very [inaudible] problems. If you're doing something like hamming distance, there are beautiful examples of functions that calculate hamming distance in all sorts of languages and they're all very beautiful. They all tell you a lot about the language and about computing and about idiomatic in various languages. But that is not the job. That's an exercise. JAMEY: I think this whole thing is predicated in an interesting way on this idea that some code is better than other code and code can be beautiful. And I agree that code can be beautiful, but I think that for people outside of our industry, like my partner, doesn't know much about code other than like what he hears from me and it doesn't occur to people that it's so subjective. I guess, it seems like it doesn't work and it's broken or it works and it's good. It's all or nothing and obviously, that's not how it is and feels to people who work on it. But I think it's kind of interesting the way that computer science and code kind of is in the middle of – art is totally subjective, a lot of math is pretty objective and software's kind of like in the middle. That wasn't a question, I'm sorry. DAMIEN: No, no, but there is one thing I wanted to dig into there, but then there's new things like, is there sort of – I feel like I'm getting more abstract and I'm trying to avoid that. [laughs] REIN: Oh yeah, it’s my fault. Okay, all right. [laughter] DAMIEN: You understand that it’s your fault, it wasn’t me. REIN: I’m beginning to reconsider. [laughter] DAMIEN: Yeah. Is there a spectrum between objectivity and subjectivity and if there is, where does software code fit on that spectrum? I don't know if that's true, but practical stuff. You said two really interesting things. Code and beautiful and I think code should be beautiful because things should be beautiful, especially things that we work with on a daily basis. If you're not having to look at the code again and it's ugly, it's fine. But if you're going to have to look at them and work with it, it should be beautiful because that makes you happy. Beautiful and then it works, which is functional, right? Like it does what it needs to do or it’s intended to do or it’s what's best for its users or best for the people paying you or hopefully all of those things at once and I think these are the two greatest metrics, the two best metrics to measure code on. Does it make the world a better place? Does it serve its users? Does it serve the people creating it? Does it serve people paying to have it created? Does it serve the world? And beautiful, which is a great metric by itself because it's inherent, it's an aesthetic thing. It's like, “I look at this now, I feel pleasure.” So that's great in of itself. But also, I think that's a factor of, is it clear? Is it easy to understand? Is it easy to work with? Does it convey the meaning that wants to be conveyed? I think those are what I mean, or those are the aspects that make code beautiful to me. So these are the two important things that I want code to be. REIN: How do you make code that serves the people who pay for it and also, the world because I don't know how to do that. DAMIEN: You choose the right people to pay for it. REIN: Where are they? How do I find them? DAMIEN: Okay. So I was going to blame you for going really abstract, but this isn’t abstract. This is actually just, it's farther away from code. REIN: [inaudible] where are those people? Show me those people. Bring them to me. DAMIEN: [laughs] Sometimes you have to be those people. I'm not currently employed because I can do that better than anybody who is willing to employ me and paying me very well. But maybe I have to compromise and get employed anyway. But there's this concept in economics that the goal of a corporation, the goal of a company, the goal of economic activity is financial improvements. Do you make more money? Does the number of dollars increase? That's the only goal. If you really operate with this as your only goal, you're a psychopath. Right and this is the idea that corporations and companies should be psychopaths and the people who manage them and work for them should behave to satisfy those psychopaths and I disagree with this wholeheartedly. And there's another school of thought that when you do good, you do good. If you're really out to serve people, you'll make more money in the process. I'd like to believe that, I’d like to believe things that nice, but I don't believe that's necessarily vital to actually doing that. If it costs you a little bit of money not to be a psychopath, pay the money! JAMEY: Yeah. Money well spent. DAMIEN: Yeah. JAMEY: Right, I can't believe I'm sitting here listening to you say, “Show me those people.” When this is episode 200, you can go back some of those 200 people, come on! REIN: Okay. [laughter] JAMEY: All right, I'm done scolding you. I'm sorry. REIN: I gratefully accept the rebuke. So Russell Ackoff has a different thing that he thinks is the purpose is the corporation and Stafford Beer thinks that the purpose of an organization in general is just to survive, but he thinks that the purpose of a corporation is to provide a comfortable lifestyle for its executives. DAMIEN: I love that first definition because it's so Darwinistic; the purpose of things that is, are to continue existing. We know that's true because if it's not true, they would stop existing. The other one is weird because a comfortable lifestyle for its executives. I feel like a corporation is designed to serve the shareholders. But then again, the executives are agents of the shareholders so maybe there's an agency problem there. REIN: It’s theoretically designed to serve the shareholders, but then the decisions are made by the executives. DAMIEN: Yeah, so there you go. So that definitely an agency problem. REIN: So how do you know when code is bad? DAMIEN: I like the metric Jamey brought up: functional and beautiful. Does it serve people and is it pleasant? REIN: So you look at a piece of code and you go, “That's bad!” How do you decide what to do with it? DAMIEN: I'm so glad you asked that question because I want to get back to that. Sometimes, I decide not to do nothing. Not to do nothing. REIN: And maybe you decide to do something? DAMIEN: [laughs] I decide to do nothing. There we go! Again, I have a CS degree. I see code that don't look good, that isn't beautiful and honestly, I read code for the pleasure. I love to write and I think it's great and making it beautiful is the best part of that. And so, when I see something that's not beautiful, I work on changing it and I want to change it, but sometimes – well, okay no. When I see something that's not beautiful, I want to change it. But the wiser decision is often to do nothing for a couple of reasons. One, maybe that bit of code doesn't need to be beautiful. Again, if you're not going to look at it again, why fix it? If it's just going to sit on some bits on a – we don't have hard drives anymore, huh. If it’s only going to sit with some bits on an SSD, why does it need to be beautiful? For the aesthetic pleasure. Okay, sure. But at least admit to yourself that you're doing something for aesthetic pleasure, not for it's productive. But also, if it is something you have to work with, maybe today's not the day to make it beautiful because today's not the day you know enough. One of my favorite phrase is, “You will never know less than you know right now.” If you don't have to make that decision now, put it off. If you don't know how to fix, how to make this beautiful, how to fix this piece of ugly code, then why do it now? Wait. As late as you can, which is probably going to be next time you want to change the way that code works because making it beautiful will help you do that. But if you can wait, wait. That was a long way of saying don't touch the bad code unless you have to! I know it's bad, it's okay. If it works. JAMEY: That's so comforting. “I know it's bad, but it's okay.” I feel comforted now. DAMIEN: Ah, that's so hard. It's so difficult. REIN: Sometimes, I just need someone to tell me that I'm bad, but I'm okay. DAMIEN: You are bad and you are okay. [laughter] REIN: Thanks, Damien. DAMIEN: By the way, that was a huge, huge realization for me. I literally couldn't make a lot of self-improvements because I couldn't admit that I had things that needed to be improved because if I did, that would make me a bad person and that was something my ego would not allow. JAMEY: We've talked about the code itself. But what about if the problem is that you're working with someone else who doesn't agree with you about what makes code good or bad, then what do you do? DAMIEN: I'm going to steal some advice that somebody gave someone else in the Slack channel I was in this week and I feel bad that I can't credit them because I don’t know who it was, but they said, “Go to values. What are the values you have?” And I think everyone in this occupation, everyone writing code for an occupation and most people writing code in general, there are a few values that they can agree on or that we can agree on—I guess I’m one of those people, also. Well, there's one really big one that I guess I should go through second. The more important one, but the second more important one is, can we understand this? Does it convey the meaning that we want it to convey? And that is different for different people. Some people like functional code. If you drew up in LISP or JavaScript or some other abomination without state, I don’t know. Long chains of functional code make a lot of sense to you when you can follow that and that's how your mind works and you're like, “Yeah, I know exactly what that does,” For a person who is more versed, embedded, “Eh, pick your own verb, pick your own adjectives.” Who is more into the object-oriented world, they're going to go, “Okay, wait, what in the world does this thing even return? How am I supposed to follow these three chains of things that are transforming this collection? The things don't have names, what are they? I have no idea what's happening here,” and that's one example and the truth is this happens on every axis. There are things people are more comfortable with, other people are less comfortable with. There are things that fit better internal models. One person’s internal model doesn't fit another person's internal model. And so what is most communicative—and this is true in every language, not just computer languages, but what is most communicative for individuals varies. And so, if you're working with individuals who have strong variation among that, then you get to find a compromise and then when you go to the value, it's like, “Okay, what is the value here? I want this to communicate something and I look at this and it doesn't easily communicate that and maybe it communicates easily to you, but can we accommodate what's easier for me to understand, what's easier for the rest of the team to understand?” And sometimes you're on a team with ten SQL pros and these nested left joins are just the thing that I have to learn to deal with. I've been there and then I have to learn to communicate the way they do. It’s not as bad as joining a team when they speak Spanish, but it's not easy. I think that's what it comes down to is like code is a language, it's communication, and there are dialects and there are different ways of expressing yourself and the values and the goals is hard to communicate. So when you go from that point, you may not like where you ended up, but it's easy to find – well, you have the tools to find a compromise in there or to find an agreement. JAMEY: This is really small, but I just caught the way that you started to say, “You have to find a compromise,” and then you stopped yourself and you said, “Get to find a compromise,” and I really liked that. DAMIEN: Yeah. Rein reminded me I was an ontological coach and that was one of the biggest language things that they kept doing and they trained me to do. REIN: I don't know if ontological coaching does this, but Virginia Satir trained [inaudible] to add yet at the end of limiting things that I say about myself like, “I can't play the piano yet.” DAMIEN: Yeah, that's a great trick and you'll find that in mostly any neurological NLP training, which got it from Virginia Satir, I'm sure. JAMEY: I've been working very hard for the past couple of years on thanking people instead of apologizing. Instead of “I'm sorry,” I was like, “Thank you for being patient.” DAMIEN: That is a wonderful, wonderful trick and I'm so glad that is something that you can do now. JAMEY: I'm still working on it. DAMIEN: Oh, so all three of these things—because I promised that this was going to be more practical. All three of these things are deeply embedded in hypnosis and NLP and that I heavily use in ontological coaching even, but they're all language. These are all ways to communicate and communicate clearly and by making these changes, you communicate a different thing. In the same way that changing the name of a function, communicates a different thing about that function. When you say, “I cannot play piano yet,” what you're communicating is that “At this present time, I can't play piano. In the future, I may be able to,” which is a different statement than “I can't play piano.” When I say you get to do something instead of you have to, what I'm presenting is an opportunity, a chance to do something that you want to do instead of a limitation or obligation. I did promise to be practical; I was trying to bring it back to code. Be precise and careful with a variable and [inaudible]. There. JAMEY: You've mentioned hypnosis. Obviously, Rein read it in your bio, but you've mentioned it a couple of times, I'm the one taking it away from code now so you don't have to feel bad about it. I'm just curious about that like I wonder if you could tell me a little bit about what you do with that, or maybe how you got started in it. It's just like, it seems really interesting. DAMIEN: Yeah. I mentioned it three times because it's in my bio and Rein read my bio and so, when people remind me I'm a hypnotist, I started acting like one. REIN: That's how the trick works. DAMIEN: Yeah. [laughs] The most important thing to know about hypnosis is hypnosis is not something that a person does to you. A hypnotist does not hypnotize you. The hypnotist gives you clear, simple, and easy instructions to follow through which if you want right now, you can be hypnotized. I love it so much. And so, what it comes down to is it's a use of language to help people into a trance state and the use of language to speak to their subconscious. And we talked about that a lot like, how the importance of how what we do is communicate and we communicate in a language and being able to communicate to the subconscious is very much like being able to communicate with a computer. It's just a different language. You have to speak differently and we do it all the time. If anybody pulled somebody off the street, most of them will be able to give you a recipe. If they've ever cooked anything, they can give you a recipe for it. Just like anyone you communicate to is, in some ways, speaking to your subconscious. Intentionally as a strong word, but not accidentally, I'll say. People know how to speak to the subconscious. One of these ways to do it is thinking about how you speak to a child. Children are almost entirely subconscious. They don't have the critical filter developed, which is why when you tell them things, they believe it. So be careful what you tell them. The same is true of adults. We have a critical filter so we are less susceptible, but there are techniques to bypass the critical filter and the easiest one to apply is repetition. If I repeat something, if I tell you something over and over again, even though your critical filter may prevent it from getting into subconscious, through repetition it will get through and your subconscious will take it in. So yeah, I also cannot play piano yet, but I'm getting better. REIN: I was thinking about a thing I did, a recent thing I cofacilitated where we got a bunch of people together and tried to think about basically, new experiments we could try that could help the company deal with a challenge that it's currently facing. And so, the first thing I did is I explained what are the three failure modes of adaptive systems, which are bounded rationality, where you can have local decisions that are good locally, but don't lead to a good global decision. So locally rational, but globally irrational. The second is following a plan when you shouldn't anymore. And then the third is – okay, I can't remember it. But what I did is, I did a stage setting where I explained those three problems and then I said, “We'll think of any experiment you want that we could try as a company,” and then all of the experiments I got back had to do with one or more of those problems. We didn't explicitly say, “We're trying to solve these problems.” I just sort of offhandedly said, “Oh, I'm going to tell you about adaptive capacity now,” and then I said, “Go think of things that we can do,” and just conveniently, they were primed to think about, to be aware of those problems. DAMIEN: Yeah. Priming is the exact word they use in NLP, hypnosis, magic and I think sales, also. [laughter] REIN: So one of the answers was like, “Why don't we do like a speed dating thing with all the team?” We have like 50 teams in our engineering work where each week, a pair of teams will get together and then 25 teams are paired with one other each month and then that'll rotate around. So each month your team is paired with a different team and then we just talk about how things are going, what you're trying. And so, that was an idea that came from the people in the meeting. I thought it was great and it directly addresses bounded rationality; it gives people a broader context. DAMIEN: Yeah and so, that bit of priming that you did in that meeting was super useful. You didn't have to tell people that's what you're doing, you didn’t have to tell people that was the goal they're solving. So we can also do that in code. I'm trying to think of an example. I can't think of one right now. I'll use a different example that is not as relevant, but it is very obvious to me right now. There's a campaign, there’s multiple campaigns actually right now, surrounding the RuboCop gem. The language around Rubocop is very prescriptive. It's very much, “You do this, otherwise your [inaudible] are bad. This is an error. This is –” And so once you put it in that system where you're judging people, you're judging code, you’re bringing up a carceral punishment system [inaudible] it. Now there's nothing wrong with code styles and style guides and there's nothing wrong with choosing a style and sticking with it. These are good things. I like them for the most part. I use a very strict style guide, but the language around it is around judgment and punishment and that's going to impact how the engineers view what they’re doing. REIN: Yeah. This reminds me of when I facilitate incident reviews, I start out with the Agile Prime Directive, which is everyone here is doing the best they can with the information and resources they have available to them. The reason I think that's so important is that there is research that shows that the severity of blaming judgments has a lot to do with immediately prime mental states. So if I'm feeling happy, I don't blame as severely as if I'm feeling angry. Sort of obvious, but if I've just been told that everyone is doing their best, I will be less likely to think that people weren't doing their best and thus, blame them for being incompetent or malicious. DAMIEN: That’s such good advice and it's especially important when doing incident mitigation and it just goes to how important that is throughout your team, throughout your organization, in order to keep people—ah, what’s the word I’m looking for—safe, healthy, productive, there’s a lot of words. JAMEY: Rein used the word blame in his description of it and it got me thinking how give blame is kind of the same with the language; it puts you on the offensive with people. DAMIEN: Absolutely and the synonym for that again, is annotate, which is a shame because it's a long word that's hard to even spell. REIN: I use credit. I have a global good alias for blame that’s credit. DAMIEN: I like that. So yeah, we're talking about these things and individually, they're tiny, or at least they look tiny, but they're not, they have impacts. As we study sales and magic and hypnosis and NLP and [inaudible] down that line, we can see what those impacts are and knowing these things allows us to make the impacts we want to make as opposed to ones that we may not want to make. REIN: Yeah. I saw a study that claimed that saying somebody instead of anybody gets more responses. So if you say, “Does anybody have any ideas?” you get less responses than if you say, “Does somebody have an idea.” DAMIEN: I like that. I think I have a more effective technique, which well, I want to look for more effective technique and my instinct is to go, “Who has the first idea?” We presume that people have ideas or who has the idea they want to share first. REIN: I think it's really interesting. Like you said, we're talking about a lot of small changes and it seems like some small changes matter and others don't as much and I'm not exactly sure why that is. DAMIEN: I think they all matter. I mean, I guess they matter to different extents, but the small things add up and actually, more than add up, they multiply. The difference between a really good day and a bad day is small things. Was there mud where you stepped instead of grass? Is your tea over steeped or not? PRE-RECORDED SPEAKER: This podcast is brought to you by An Event Apart. For over 15 years, An Event Apart conferences have been the best way to level up your skills, be inspired by world-class experts, and learn what’s next in web design. An Event Apart is proud to introduce Online Together: Fall Summit, a three-day web design conference coming to a device near you, October 26th through 28th. The Fall Summit features 18 in-depth sessions, each followed by a live, moderated Q&A session with the speaker, plus unique one-on-one conversations with some special guests. You’ll learn about advanced CSS from Miriam Suzanne and Una Kravets, design systems and patterns from Mina Markham and Jason Grigsby, design engineering from Adekunle Oduye, inclusive design from Sara Soueidan and David Dylan Thomas, and much more. Attending An Event Apart boosts your brain, inspires your creativity, and increases your value to your teammates, employers, clients, and most of all, yourself. And you can boost it even further. Purchase a Three-Day Pass and receive six months of on-demand access to their first three Online Together events. That’s six full days of jam-packed content for the price of three. Greater Than Code listeners can get $100 off any multi-day pass with promo code AEAGTC. Once again, that promo code is AEAGTC. So grab your spot and join An Event Apart’s Online Together: Fall Summit, October 26th through 28th. See the full three-day schedule and register today at AnEventApart.com. JAMEY: There was something else in the list of things that you sent us that we might want to talk about that I was thinking about and hoping to get back to you and I think it's kind of related, which is the incredible amount of time and effort it takes to do things even when they're easy and that resonates a lot with me. I just started a new job and I'm onboarding and ramping up and feeling like oh my God, it took me long to do this, even though it was easy. So that was kind of on my mind. But now, as you're talking about like little things and how they have impact and they're so important. It feels like well, yeah, even if it seems easy, it takes time and effort because it's important and it fits in this whole web of things in this complex way. But I wanted to hear what you were thinking about that. DAMIEN: This is something that I had struggled with very recently. Like yesterday. [laughs] JAMEY: Me too. [laughs] DAMIEN: I’m glad to hear it. I think I’m glad to hear it. Thank you for sharing, there we go. But it's so fascinating observing myself having to assume that something will go quick or immediate, be done quickly or immediately, simply because it's simple and easy. Simple and easy does not mean fast! After college, I biked across the country. I biked from Boston, Massachusetts – we actually went out to the coast just so we could go coast to coast. I biked from Boston, Massachusetts to San Francisco, California and that's a simple thing to do. Honestly, it's not even that hard. Riding a bike is easy, west is that way, just get up and do it and it was a great time, but it took a long time and I look at that and I go, “There's no way it can't not take a long time. That was 3,000 or 4,000 miles.” But I look at intellectual work, I look at writing and writing code and I go, “Oh okay, I know exactly how this is going to work. I know exactly how to do that.” Why do I then spend all day on it? Well, because it takes time. It still takes time. JAMEY: And that's so true of intellectual work, too. Particularly when we have this habit of measuring our productivity in how many lines of code did I write and it doesn't take into account well, who did you have to talk to, to figure out what you needed to do and thinking about this and thinking through ways that could potentially touch other things and all of that is like important work that's not really reflected in how many lines of code you ended up having to write. DAMIEN: That's a really good point because I brought up one particular blind spot of mine, which is if something's easy, I think it should go very fast. But you brought up other blind spots that I had been less aware of—we talk about language and I get better at it. Otherwise, if I had been less aware of, that hour or two hours I spent on the couch wondering how in the world I’m going to do this thing I don't know how to do, that was work. Not a single line of code came out of it. I might've, at the end, done a three-body diagram on a piece of paper and that's all that came out of it, but that's still two hours of work. I was still working there at that time and that was stuff that I had to do and it wasn't easy, it wasn't fast, and it wasn't going to be because it's yeah, I'm sorry. I'm just preaching to myself. [laughs] Like acknowledge the work you do, Damien. JAMEY: You're preaching to everybody, I think. I struggled with this super hard when I went from being a developer to a senior developer because I was like, “I should have more responsibility. I should be writing more code! I'm doing all these things.” But I was writing less code because so many of the things I was doing were more abstract and I struggled with that. I felt really unproductive and it took me a long time to be like, “No, I am being productive. This is part of it. These are the things I have to do. Someone else was doing these things for me before and now I'm doing them myself.” [laughter] DAMIEN: That is a great example. I had a similar experience when I switched from engineering to product management where I could work for hours and literally almost no keys get touched. I'm just staring at this problem going ah! And again, that's work. There’s not a lot of output that I can look at. Honestly, when I do it well – again, happens in code sometimes. When I do it well, it's less output, fewer keys because I go, “No, this is the same thing and this is a simple way to solve that user problem!” and it still takes time and I'm still staring at the screen—well, not staring at the screen or maybe I am—and I'm still working. The only course that I had to that as a senior engineer was when I was pairing with engineers that were less comfortable with the code base, less comfortable with the technical stack and because I had anxiety about the amount of not as much lines of code, but story points, features and things I can say we're done. I had anxiety about doing enough, that when I'm here with engineers who are very unfamiliar, I'm like, “But we have to go fast. We have to go fast. We have to do this,” and I get frustrated with them for slowing me down and then I don't know how long this took me, man. Oh, but it was a relief. [chuckles] Made life better for everybody; for me and for those poor, unfortunate souls who were pairing with me. One day, I realized wait, a big part of my job is getting them up to speed. If we sit here for four, six, eight hours and only result is that they're better doing this job, that is a huge win. JAMEY: That makes me feel great. Literally this morning, before we were recording this, I just started a new job like I said, I'm like getting used to things and someone got out and paired with me and found something that I was missing and I felt so stupid afterwards. I'm like, “Oh, I should have known that. I was looking in the wrong file.” And I felt really self-conscious about it! So this was also comforting. [chuckles] DAMIEN: Yeah, and I can tell you like that – [laughs] I guess, I don't know, I've been there. No matter how much of an expert I have been, I have absolutely had—and this is why I advocate pairing even though I don't enjoy it—I have so often been on the other side of that where not only do I not know enough to know I need help, I know so much that I can't imagine I need help. [laughs] And two, three, four hours, eight hours, two days later, somebody goes, “Oh no, this.” That's an experience. REIN: One of the things I like about pairing is that it's not a traditional teacher-student relationship. You can have a mentor-mentee relationship, but you're both focusing together on a problem. It's not a teacher focusing on teaching a student correctly because I don't think that even works for anyone. I don't think teaching works very well. I think learning works very well. But I don't think teaching works very well. DAMIEN: I love that distinction between teaching and learning but yeah, and I think the best pairing structures are when you can minimize the power differential. I think there’s an inherent power differential between teachers and students I guess, at the other end of that and that power differential makes it difficult to learn. And again, we’re back to the distinction between teaching and learning. REIN: Russell Ackoff—I'm going to keep namedropping him, I guess. But he tells a story that I love that I'm just going to recount really quickly. So he was in the faculty of the Wharton Business School, so big, important guy and there were a bunch of foreign students from South America who were in their civics course or their civics department. So someone in the school was teaching a class on third world development or something, it was called at that point and the students all came to this teachers’ meeting, to this faculty meeting and they said, “We want to get involved in this. How can we join the class?” and then when a cop said, “No, no, no, you're going to teach the class.” So these 13 students, they said, “How are we going to do that?” and he said, “Well, same way that the professors learned to do it. You're going to figure out what to teach us. You're going to design a course and you're going to come and work and then we're going to be your students.” And they did it and then every one of those 13 students then went into politics in their home country and they became ministers of finance and things like that. Every single one of those 13 left that school and then had positioned to where they could make significant changes in their home country doing that thing that they learned to do by teaching. DAMIEN: So maybe teaching doesn't work with students, but it sure as hell works with the teacher. REIN: Yeah. Trying to teach is a great way to learn. It's not a great way to teach. DAMIEN: [laughs] Oh, that's such a great – oh man, I love that. JAMEY: I know this is true because I learned by having to write or talk about a concept, which is the same. REIN: Yeah. I mean like, how did you learn English? Did someone teach it to you? No, you learned it. I think we need to get better at learning and focus less on teaching and I think that that has a lot of impact for the mentor, especially in tech. DAMIEN: Both these cases, the teaching is goal-driven. In fact, in all of these cases. Sorry, the learning. In all of these cases, the learning is goal-driven. The goal is to teach, the goal is to communicate, get your [inaudible] and then in programming, the goal to improve the product. So I think that was my point. You bring out a user story like this person wants to accomplish something. So that's how you learn is you have that goal and you go, “Okay, how do I achieve that goal?” REIN: Yeah. I think that's exactly right. Actually, Ackoff says, “If you want someone to learn something, you don't figure out how to teach them, you figure out how to motivate them.” DAMIEN: Give them a goal. A goal they want to accomplish. There's a saying in acting, “You don't pay actors to act, they act for free. You pay them to wait around.” I love that and I want to bring it to engineering. I don't get paid to write code for you, I get paid so that I can pay my rent and groceries, which frees up time for me to write code for you! [laughs] REIN: I get paid to care about your boring business problem. DAMIEN: Ah, I mean, that works, too. But can you imagine a world where employment was not like – there's a control structure of employment, right. I give you something – or a transaction; I give you something, you give me something in return. Can you imagine a world where it’s I give you this so that you can do the thing you want to do because it's something I want done? JAMEY: That's like patrons of art. DAMIEN: Yes! Yes! This is the thing that exists. There are patrons with code. There are rare and not a lot, but it happens and then of course, there is the power differential there which can lead to that relationship not working the way that I dream of it. Working more like the way people normally see employment, but hey, [inaudible]. JAMEY: I wouldn’t let that stop us talking about it better. DAMIEN: We're not going to reach perfection in our lives, in our institutional structures, or in our code. But sometimes, there's good reasons to move towards it. That was overly qualified. Sometimes, there's good reasons to move towards perfection. Maybe not. I’m going to stick with it. REIN: But can you be too perfect? DAMIEN: Perfect is [inaudible] so no. But also yes, because perfection is undesirable and being close to perfection is often sometimes undesirable. REIN: One thing that I see happen so much that I almost want to call it a natural law is that the closer you get to perfection, the more effort it takes, but exponentially more. So it might take the same amount of effort to go from 90% to 99% as it does from 99% to 99.9% as it does to 99.9% to 99.99% so. DAMIEN: Yeah, that's the Pareto principle, the 80-20 rule. It works fractally and you end up with a [inaudible] relationship. REIN: There are distributed systems proofs that are literally, you can have this property, it can't be perfect, but you can get asymptotically close if you pay exponentially more like the FLP paper that has that result. They're actually surprisingly many of them. DAMIEN: It’s so great when we can prove these and mathematically describe them. I think it's especially great because there are natural laws and it's nice to have a clear understanding of those natural laws. Yay, math! REIN: Well, I like it because I can say to people, “Look, the thing you're doing, we can do, but here's what it's going to cost you.” DAMIEN: Yeah, there is a great – and this is probably cultural, but there is a great power in being able to point to numbers. [laughs] REIN: It's interesting, but there's also a great power in storytelling and I think they have different places or different mechanisms like, if you can justify yourself with figures, sometimes there are other places where that works very well. But if you can tell a story, sometimes that works better. DAMIEN: Yeah, and it's context and it's cultural and it's individual and if you want to be the most effective, do both. JAMEY: Yeah, numbers can tell a story, for sure. I saw a really interesting talk about that once and it talked about like all of the data that they had from Foursquare about where people went and the interesting stories that you could extrapolate from the numbers of like, this is where people went at a certain time. DAMIEN: That sounds like a great talk. But yeah, there are cultural and context variations on how important, not just numbers, but rationalizations. I said rationalization because I'm thinking of rationalization, not rationality and objectivity because humans – yeah, there are cultural contextual differences between how important rationality and objectivity are, but humans are not inherently or overwhelmingly rational. So if you want to communicate best and achieve your goals most effectively, it's best to combine both a story and the rational reason. Numbers are great for rationality, unless they're irrational numbers. Couldn't help myself, sorry. [laughs] So yeah, and it's great if we could intervene because for humans, the story will change their mind and change their behavior and the numbers and the rational proof will give them a reason to accept that and allow that to happen. REIN: I think that what stories also do is they help us with why questions and with what four questions. So numbers are good at giving us knowledge like, giving us descriptions of things. They're not good at answering questions like, what ought we do or why is it good to do this? DAMIEN: And those questions are fundamental and unavoidable. Those are the more important ones. REIN: Ackoff, again, has a hierarchy where knowledge is about descriptions of things. So if I can tell you where the pizza shop is, that's knowledge. Understanding is about explanation. It's about know-how. If I can tell you how to get to the pizza place, that's understanding. And then wisdom is about why. If I can tell you why you need to go to the pizza place—we're hungry, we're going to go there—that's wisdom. So numbers can't get you wisdom, but stories can. So I think that's the distinction I'm trying to make all. DAMIEN: Oh, I love that because it ends with a really great, powerful story about the value of stories. REIN: I think if you want to change people on the level of changing what they value or what they want to do or what their goals are, you need stories. Numbers can help, but you need stories. DAMIEN: And so, that's another aspect of good code is that it tells the story or it communicates the story. I like communicate better than tells because tells describes the code, communicates just describes what happens in relationships between a person and the code. JAMEY: I like that. REIN: There are a lot of different ways that you could write code to do something, so we have a lot of choices to make. So you can choose to value a lot of different things and I think thinking about what you value in your code and whether you value understandability, whether you value storytelling, that's something that I've spent some time pondering for my own career and I think that time has been well spent. DAMIEN: I agree. JAMEY: Someone tells you something, it doesn't necessarily mean that you understand it. if someone communicates with you, they're making an effort to make sure that you understand it. DAMIEN: If someone tells you something, they might not have communicated it. There's a saying, I think in neuro-linguistic programming, “The meaning of a communication is the response it [inaudible].” Probably the reason I like that is because I like the word [inaudible]; not a word that gets used very much. But yeah, communication happens in the relationship and what is the impact of a communication is the value of that communication, which leads to some very curious context-based things where I've known people who were particularly skilled at speaking to humans and they would say the exact opposite. They would say things that sounded the exact opposite to different people, but it was communicating the same thing. REIN: One of the things that I think is really important when you're communicating face-to-face is being able to create not just a shared understanding, but an agreement that we have a shared understanding because we need that to build on if we want to actually like construct new understandings together. If you want to learn or I want to teach or we want to do something together, we have to start with a foundation of understanding and I think that's really hard to get across in code because the code's ability to communicate is somewhat limited and it's not reactive or responsive, it's just there. It's kind of like, “Oh, it's hard.” Like if you look at all of the exposition that goes on in novels, it's because it requires a lot of work to get across a shared understanding of where this character is, what they're doing, what their world is like, where if you were talking to someone, that could be shortened. So I guess, the questions I'm getting at here is if it's hard to write code in a way that guarantees a shared understanding with future readers, who you won't necessarily know, what can you do to make it more understandable? DAMIEN: I mean, I want to make your statement even stronger. It is impossible to write code in the way that guarantees a shared understanding. That's just not going to happen. So what is it? There's no right or wrong, there's always tradeoffs. So how do you decide on those tradeoffs? One of the things, and again, this is another reason why I advocate for pair programming, even though I don't like it, but just finding out what the code communicates to different people is going to make it possible to make it communicate what you want. It's going to make it easier to communicate what you want. It's a weird thing about code! Outside of pair programming if I'm writing a novella, if I'm writing a novel, if I'm writing any sort of prose at all even poetry, any sort of human writing, there's a feedback. I write something, I show it to a person, I see what that communicates to them, what impact that has on them and I adapt based on that and I learn based on that. And it's a weird thing that where that feedback doesn't happen in programming, largely outside of pair programming, but being able to have that active feedback about what's being communicated and being able to have it with different people because everybody's different and also, the context changes. So being to have it with different people over different periods of time! That's very helpful for improving or getting the code you write to communicating things you want communicate more. REIN: I think that's a thing that code review can potentially help with. I think that the way it's often done makes that somewhat unlikely because it's mostly just checking off some boxes, but it could be about getting multiple different people to read the thing you wrote and see if they understand the context in the same way that you're trying to, while you're still around to tell them if they were right or not. DAMIEN: Yeah. [crosstalk] REIN: And usually, [inaudible] saying right or not. DAMIEN: There's so many barriers to that asynchronously. One of them being well, you're not writing the code right now so it's an extra activation as you can go back and make changes based on what you learn. One of them being like, there's an opportunity for a judgement context where it’s like, “I wrote this and you're judging it.” That's not conducive to collaborating on improvement. So many barriers that makes it so hard to do that when you’re separating from actually writing the code together at the same time. PRE-RECORDED SPEAKER: Businesses all over the world right now are trying to reinvent how they connect with the world. Whether a business is delivering packages, treating patients, or running a global customer support center, their customers need them to invent new ways to stay connected. Twilio is the platform that Fortune 500 companies and startups alike trust to build seamless communications experiences with phone calls, text messages, video calls, and more. Really, the only limit becomes your developer’s imaginations. It’s time to build. Visit twilio.com to learn more. JAMEY: This has been a really great conversation, but we're getting to the point at the end of the show where we have to kind of wrap up and what we normally do is everyone will reflect on something that stuck out to them, or may they want to think more about, or that they want to bring into their lives and let it inform the things they do or anything like that and I'll go first. One thing that I have been thinking about over the course of the whole show is this idea of doing things you see yourself. I think it came up in a few different ways from all of us. Like I was talking a little bit about being a senior engineer and taking responsibility for things that other people used to do. And Damien was talking about how someone doesn't hypnotize you, they help you become hypnotized. And Rein was talking about teaching and learning and how you have to do learning for yourself. I think that that theme is really interesting to me because it suggests that you have to take this responsibility, but I think it also suggests that you kind of get to take – assert control and power over yourself and the things that you do in a way that could feel very affirming. And I want to think more, I guess, about that as I'm doing stuff like oh, I have to do this for myself” and no one will help me or is it like people will help me, but I get to do this myself the way that I want to do it and the way that I feel comfortable with it. DAMIEN: I like that. It's so empowering that these are the things that I do for myself. Learning is something I get to do for myself and that's only the way it happens and self-care and—I speak for myself again—something I need to do for myself, that’s the only way it happens and all the other examples. That's just, yeah, it’s super empowering. Thank you. REIN: I've been thinking a lot about the importance of small changes, even small changes in the language we use, maybe especially small changes in the language we use. And I think that part of the importance is not just the change it has now, but there can be longer-term ramifications or sort of reverberations of those changes. I think that the way I've heard it said before is the easiest way to make a big change is to make a bunch of small changes. I think that's very true and I guess, what I'm going to be thinking more about is how to find those nudges, those small changes, how to know when there's an opportunity for one, to work. Because sometimes they work really well, sometimes they have a huge outsized effect and sometimes they're not even noticed. And I don't yet understand how to know the difference and I think if I did, I could be better at making those small changes. JAMEY: Another thing that was really striking to me was at the very beginning of the episode when we were talking about code being beautiful and then Damien said was like, “Well, I want code to be beautiful because I like things that are beautiful,” and I really liked that because there doesn't need to be another reason. [laughs] And I like that small, simple reason like, that's the reason. I want to use that. “I like it and there's no other reason.” DAMIEN: Yes. JAMEY: [chuckles] It makes me happy. DAMIEN: Oh, I just want to absorb that. Isn't aesthetics purpose itself?! And isn't that valid? REIN: Well, depending on who you listen to, it's either the only purpose that matters or it doesn't matter at all. DAMIEN: Well, I can believe both. [laughter] JAMEY: I read a lot of Oscar Wilde and it's definitely the only purpose that matters. DAMIEN: And then Rein with this small changes like that's so great. I feel honored to have been part of a conversation where those things came out. I feel something super special. I could leave on that cause that's a beautiful note, but I'm going to say something else. Which is the thing that I want to take away from this, though is the power of language and story and its application not just matches in rhetoric and politics and art and those worlds, but its application in the engineering world, both within a team and its application even as dismissive. It's application in the code you write. Computer code tells stories, computer code is language and small changes and careful choices in that language and in those stories are very impactful. I remember that as I write. REIN: That was really nice. JAMEY: Thank you so much for coming on. This was really great. I think this was a great episode 200. DAMIEN: [laughs] Thank you so much. I really enjoyed being here. On a milestone episode, too. See, that's so special. REIN: Well, I think it was a special episode and I'm really glad that you were the one to do it with us. All right. Well, you can all go away now because we're done.