JESSICA: Good morning! Welcome to Greater Than Code. I'm Jessica Kerr and I'm happy to be here today with co-host, Jamey Hampton. JAMEY: Thanks, Jess. And I'm really pleased to be on the show with my co-host and friend, John Sawers. JOHN: Thank you, Jamey. And I'm here with our guest, Chris Stead. Chris works as a software developer specializing in JavaScript, developing for the web and server environments, as well as authoring developer tools. He's led workshops and spoken to a number of meetups, private events and conferences, most recently at Deliver: Agile. He also spent his evenings teaching software development. When he isn't teaching, Chris plays in a rock band and spends time with his wife and daughter. Welcome to the show, Chris. CHRIS: Thanks, John. Excited to be here. JOHN: We're going to kick it off with the question that we always ask at the beginning of the show. What is your superpower and how did you acquire it? CHRIS: I knew this is coming and I did lots and lots and lots of thinking about it. And the more that I thought about it, the less I knew about it. So, what I realized is that I do a really good job of not knowing in public. JOHN: Very good. CHRIS: The way that I acquired that, it kind of came from, to start, it came from when I was in college. I majored in Math and I minored and Philosophy. And both of those disciplines specialize in not knowing. "I don't know this. Let's find out. I don't know that, what do I know that it can lead me there." And so, I spend a lot of time kind of saying, "Well, I don't know that. Let's find out." I try to share that with the other people that I'm around rather than trying to just stand there and be the expert and pontificate. JAMEY: I have that superpower, too, I think. I feel like so often people come to me and be like, "Wow, how did you learn how to do that? Wouldn't it be great?" But I feel that. When I was new in tech, I felt so stupid when I had to ask a question and I was so nervous to ask a question because people would think I didn't know anything. As I started to feel more like I do know stuff and people respect me. Maybe hopefully, they won't think that about me. I started asking questions very loudly because I was like, there are other people I bet on this call who also don't know this, who are more embarrassed to ask about it than me. CHRIS: Yeah, my students do that a lot. They're like, "I don't know if I should ask this." I'm like, "If you're thinking about asking, you probably should because you're not the only person." JAMEY: So I would ask you even if I do know and pretend like I don't know, so that other people hear the explanation without having to ask. CHRIS: I think that's awesome. I love that. JAMEY: Chris, one of the things that you said that you've been thinking a lot lately when we talked before the show is about source documents. And it strikes me that that's similar to what you're talking about with your superpower, because it's about learning things and teaching them and knowing them and having everyone know them. So I'd love to chat about that. Because lately I've been thinking a lot about source documents and their relation to people. I would love to hear your general philosophy on that, to start out with. CHRIS: I think the biggest thing when thinking about source documents, at least the way that I think about them, is if we look at Grace Hopper's work and we kind of say like, "Okay, why did she create a compiler? What was the value in this?" She wasn't creating it. So that way, we could more effectively write hex or binary, so that way, we could write source documents that are actually English or English-like. So that way, basically we're writing a document in a human readable way and something that makes sense to people. And I've heard people talk about like, "I optimize my source to make sure that it's as fast as possible," and that kind of thing. But then it's not human readable anymore. There are things that you're going to have to optimize. You're going to discover that something is too slow or could be changed in a way that serves the user better. But those things, they're not the norm. The norm is that you're going to have people that are going to come back later and they're going to need to maintain that code. And the more that you can put context in the code, the more that you can put a story about what happened last, the easier it is for the next person to discover what you meant and why you meant it. And so, it's much more comfortable to come in saying, "I'm not certain, but I can find out and I have the right things to lead me to questions." And that's really where I kind of come from with source documents because they are for people. They're not for the computer. The computer actually ultimately digests something else and even interpreted languages. Ultimately, I run through an interpreter and then run on a virtual machine. JESSICA: Right. I read the phrase the other day, the critical complexity. We need to figure out what's the critical complexity of your app or these components of your app. And sometimes, that's performance. Sometimes, it's network standpoint. If you're on a really, really technical project that usually, the critical complexity is in the domain. And that's what we communicate when we write code for people. CHRIS: Right. I agree. And actually, I was fortunate enough to start going to meetups with Indu Alagarsamy. She runs a meetup in Southern California, all about domain-driven design. And she started talking about exactly that, Jess, what you're talking about with the complexity of the domain and the complexity of the software. And the complexity of the software, it's really easy to have that just spiral out of control. And so, by trying to come back and meet the complexity of the domain as close as possible, you start to model that domain and then [inaudible] which leads us to exactly what you're saying, the complexity of the domain being the main complexity of the project. JOHN: When I was working with bootcamp students, we would often get sent over to some sort of code kata website where they'd look at different ways of writing the same algorithm. And pretty much universally they'd all say, "Oh man, look at all those short, really concise code that I don't really even understand. That must be the best code. I wish I could write code like that." And every time, I would have to push back and say, "No. This is useful for stretching your muscles and thinking about the language and learning its features. But you really almost never want to write that into a production code." JESSICA: Right. That's its own little game and it's a cute game and have fun with that. But when you're playing the infinite game of ongoing software development and production code, please aim for [future humans]. JAMEY: That brings me to a question which is, how do you encourage or legislate almost on your team? Like, "This is what we're going to do with our code." How do you get other people to do that? CHRIS: Legislate is a really strong word, I would say. I lean more into the encouragement because sometimes you win, sometimes you lose when you have those arguments. And it is okay to lose the argument. It is okay to say, "You know what? Okay. We're just going to do it that way, because that's what makes sense to you right now." JESSICA: And [crosstalk] is more important than whatever the argument is. CHRIS: Exactly. So typically, what I try to do is model what I want people to lean into. And even when I'm teaching, I tend to say, "You know what? We have some canned code. This name right here, it doesn't make sense to me. It's an abbreviation. It doesn't mean something that the rest of the world can read. So I'm just going to rename that right here." I'm using an IDE, so I have refactoring tools. I just hit F2 and I rename and I move on. So you can rely on a bunch of those built-in refactorings as well to help people just start to kind of budge the needle. In domain-driven design, there's this idea of event storming. Event storming basically is a way to get together with stakeholders and product owners and developers, and everybody just kind of start saying, "Okay, this is a business event that's going to happen." Somebody wants a refund. Somebody wants to make an order. Somebody does whatever. And so, they're just like these high level business events. And then you start figure out like, user requested a refund. It's always past tense. So issue refund would be the command. And that's always present tense, imperative. Then you would have some sort of like, this is the next event -- there's a piece that I'm missing. But nevertheless, the reason I bring that up is because I did a simplification of that. So that way, you could do like just unit level discovery where it's like, user clicked the submit refund button. What is the thing that the system is going to do to handle that behavior? Then you kind of go through and say, the command is do the issue refund bit. And the outcome should be the refund was issued. But that could fail. So now, you have two cases at least - refund couldn't be issued or refund was issued. And by doing that, you're now speaking even in the small about the problem space and the domain. And so I call this ECO Mapping because it's event command outcome. And I use that a lot with my team to help them discover the things that they need in order to make sense of the problem in the small piece, that little unit that we're working on right now and how it plays into the larger problem. JAMEY: So rather than making rules, like creating culture, I feel like is what you're getting at. CHRIS: Ideally, yes. JESSICA: Creating a language. CHRIS: Yes. JESSICA: You know how people love to invent programming languages and they want the perfect programming language for their particular problem? JAMEY: I do know that. JESSICA: Yeah. That's the thing. We actually do get to create a language for every application. It is the domain language. CHRIS: I agree. JOHN: And it's a hard one to create. This goes back to naming things is hard. That's the work of the software development is getting that right. And I think we tend to think about it mostly not in those terms unless we're trained in DDD, which is just like, "Oh, a series of procedures and methods and callbacks," and whatever. And then you lose sight of what the actual thing is. CHRIS: Absolutely. Arlo Belshee has this thing that he, I don't know if he devised it or if he -- anyway, he talks a lot about the seven stages of naming. And so you start off with something that has no name. You go from missing to nonsense, from nonsense to honest, from honest to honest, to complete and so on through this path. I can't remember them right now because I don't have it in front of me. But basically, you end up at this place for your domain abstraction. So missing would just be like I have a magic number. I have this conditional that is meaningless now, that kind of thing. And so, the idea is to just iteratively name things and it's just as you discover. That's kind of what I've discovered is good for them. JESSICA: I like that progression from missing to nonsense to honest to complete. Is that right? CHRIS: Yeah. Missing to nonsense, nonsense to honest, honest to honest. Actually, John just posted a link because I can't remember all of them. But yes, that's it. That's progression. JESSICA: Yeah. Because I said earlier that we create a language, but largely we discover it, not totally. It doesn't all exist yet and we wind up finding concepts that no one talked about, but really are essential to the domain, whether sometimes those are abstractions, sometimes those are really specific. CHRIS: Yeah. JOHN: Actually, I'm really excited to read that piece because I'd say 40% of my pull request feedback is about the names of things. And so, having a framework for understanding those and iterating into better ones, I think, would be really useful. CHRIS: That's fantastic. I love the work that you did with it. I think the link that you posted, I think that link that you have is his old post. So, you might want to take a look at that, because he has a whole new series of articles about it. And so, you can actually go through that. He details every single one of the steps and says like, "Here's how this one works and here's why you do it," and what have you, which can be really useful for understanding how to kind of make those moves. JESSICA: Yeah. And clearly, we should have Arlo on the show, too. CHRIS: Yeah, I think he would have a lot of really useful stuff to say. JOHN: We're talking about a narrative earlier and I feel like that's a really important word to highlight, especially in teaching, but and also just in communicating about code. I've always felt like tutorials where they name all the things A, B, and C are so much harder to follow than tutorials where it's like, we're running the factory that makes widgets, let's add widget feature, door handle and just having those non-abstract things to follow along makes it easier. And I would imagine it applies in a lot of other cases that you've noticed. Can you talk some more about that? CHRIS: Yeah. I heard you mention using A, B, and C widgets, that kind of thing. And actually I found -- because my old example code used to use a lot of widget and widgetizer and that kind of thing. And I found that people would go, "I don't know what a widget is either. I don't know what A, B, and C are." And so widget is better but then widget is still confusing. So I've started now to kind of say, what is some thing that we can talk about? It has a name and someone understands it. And it doesn't have to be magical. It could just be razor blades because everybody understands what a razor blade is. So you can talk about like, this is a blade maker and this is the multi-blade head assembly. You can model any kind of physical work or whatever within code. And this doesn't have to really mean anything other than like, I'm going to just assemble this stuff and store the outcome in some way. So then people can start to actually follow along. They've got concrete stuff, so they no longer have to try to digest this like, "Okay, I'm working with a widget. What was that again? Oh yeah, it was a widget. And it has a [inaudible] and it has a display and it has..." whatever. So it's something that already has properties that they understand. JESSICA: Another beauty of that is that you can call the user something other than user because they're either assembler or in the case of razors, I guess they're shavers. CHRIS: Yeah, exactly. It could be a buyer. It's like the buyer, this person that's purchasing a razor blade for whomever. Let's say that you've got a buyer for a company and they want to buy 10 cases of five blade razors and three cases of the two blade razor heads and what have you. It's still something that would that would be totally meaningful. So, it could be a shaver, it could be a buyer, it could be whomever. Exactly right. JOHN: I think expanding beyond tutorial examples, are there other places that you found that narratives are really important in software? CHRIS: Yeah, the narrative in business, that's something that I really love because I view it as being almost like a biography of the product you're building or the problem that you're trying to solve. Because they tend to be bigger than just like, here's my toy problem. It tends to be, this works with that or with this other thing. For instance, I got to work for an irrigation company. And so we have controllers and we have sprinklers and we have various different other systems that irrigate in various different ways. And all that stuff ties together with solenoids and pipes. And all that stuff has meaning in the system. And so now, it's not just simply 'I have this one particular head, it sprays in a particular way', but it's 'I have this array of heads. I have this assembly. I have this site that needs these things'. And also now, you're talking about a really rich story about the domain. And there's a lot that you can say about the domain in that story. So you can say it was born of this need, this particular type of customer needs these things. So, we have a distributor. The distributor needs these things. We have people that are on site that are installing things. They need extra number of solenoids and so many feet of drip line and so many heads and what have you. And they need a controller that can control this many solenoids which then also now, we need to be able to program it. And we need to be able to ensure that the program runs at the right time and that various different solenoids are actually interleaved. That way, you use the least amount of water and maximize the amount of efficacy within the shortest amount of time. So all of this stuff starts to kind of tie together. And it does create an actual story. And if you can have some domain abstraction that says, "This is what I know," and you have another abstraction somewhere that also says, "This is this other thing that I know." You have a third piece that says, "This is how those two pieces work together." Then you're now speaking in a language where someone can actually read that story. And they can edit that story and they can say, "I'm going to go back and understand what these pieces mean." And if they do have questions like, "I've never heard of this thing before, I've never worked in the irrigation industry before, so I have no idea what this particular term means." JESSICA: What is a solenoid? CHRIS: Exactly. What is a solenoid? They could go to the product owner. They could go to some other person that's in the industry and say, "What is a solenoid?" And of course, they would get the answer. I say, of course, that's like just. It's this, "Of course, everyone should know this," which is never the case. They would say, "Well, a solenoid is a device that turns the water on and off when you apply an electrical charge." And of course, this programmer would say, "Huh, I've never thought about that kind of hardware because I build software." So all of sudden, it leads you to asking the right questions about the domain. JESSICA: You said it leads you to ask you the right questions. You said something about that earlier, too. CHRIS: Yeah. JESSICA: That's so important. It's not the answers that we need to get to so much as the right questions. CHRIS: Yeah. Software is all about learning. And the more that we can facilitate that learning, the better off we're going to be. JAMEY: I think a phrase that I hear people use sometimes is, "My Google-Fu." CHRIS: Yes. JAMEY: It's kind of silly, but I think that being able to get stuck doing something in your work and compose a Google search that will find you the thing you need is like a real skill. It's an important skill for us in our industry. CHRIS: I agree. I have my students practice that all the time. I actually make mistakes in class and they're honest mistakes. It's not something where I "make a mistake" and like, "Whoops, I better fix that. Here, I'm going to do this completely contrived thing." I own mistakes. If I forgot something, I say, "I forgot. Let's go look up the documentation," because it's more important for them to see that everybody forgets and everybody has to go and look things up. And they also get to see how I learn and how I discover. And I hope that I'm giving them a good model that they can build from, because ultimately they're going to have to learn how they learn. But if they know that everybody has to learn, then at least they can start pursuing that. So, yeah. Google-Fu is absolutely a thing. JAMEY: In my last job, I did technical interviews. We did pairings. So I would be on coding. It wasn't really a live coding exercise, it's much like a collaboration exercise. And I would be like, "Oh, if you don't know this in text, just look it up." They're like, "I can Google it right when I'm on the interview call with you?" I'm like, "Yes, so I could test." I would Google it if I didn't know it when I was working. That's what happens. You do it, actually. I think it was really useful to see what they would Google and what they would look at. CHRIS: Absolutely. Oh, my gosh. We actually do mobbing interviews. Whoever's coming in, we have them actually sit down and work with mobbers to actually solve the problem. The first thing we have them do is just write some code to kind of loosen up. It's simple stuff that really should be kind of muscle memory. But the goal is not to see whether or not they can remember this thing, it's to get them loosened up so they can actually sync. And then from there, the rest of the time is all spent saying, "Okay, here, person, this is what I want to accomplish. And so we'll have a mobber that's acting as a driver and then they can navigate and say, "I want to accomplish this. I don't know how to do that. Let's take a look at this thing." And so, what we really look for is exactly what you're describing, Jamey. Are they looking stuff up when they don't know? Are they asking questions? Are they communicating? Are they collaborating? Are they able to work in a team to build and edit source documents? JESSICA: That sounds like a very realistic, maybe even useful interview. CHRIS: I really enjoyed it. We have a lot of candidates that when they leave, they're like, "Wow, that was super fun. I'm really glad that I did that," which is lovely. I always feel good when I hear that. I would rather people walk away feeling like they learned something, they've got something of value because it's four hours out of their day. So why would we not provide them with some value? They shouldn't feel like they came in and they were just kind of our entertainment for the day, code and we shall watch you. [Laughter] CHRIS: We want to see them actually interact in a way that everybody's gaining something. JESSICA: Well, and you put them into a system that is similar to a real work system because everyone's a different person in different contexts. CHRIS: Exactly. That is something that's really interesting that happens is you'll actually watch people change throughout the interview as they become more comfortable. The problems are, we have like a debugging problem, we have a refactoring problem, we have a sequel problem, we have a softer design problem. Those are all things to just get them thinking in different ways. But as they go through, you see them shift. The first one, they're kind of like, "I just have to get it right. I just have to do the right thing." And by the end, they're kind of like, "Well, let me think about that for a minute." And then you get to start really seeing what they do and how they actually sync and communicate. And yeah, it's pretty magical. And then plus at the end, we do Lean Coffee. And so everybody kind of sits and chats and says, "What do you like?" And, "What do you do for fun?" Rather than just like, "Why did you leave your last job?" Because everybody has a story for why they lost their last job or why they're leaving. That's something that will emerge over time. It's never that brief answer. JOHN: I like that you were talking about getting a candidate to the point where they can say, "Let me think about that for a minute." That is an amazingly good sign at the level of comfort you are able to create with someone, which I think is so important. Because like you were saying, the moment you walk into that interview room, you're all wound up super tight and you're not going to be creative and you're not going be collaborative because you're under stress. And so being able to wind people down and get them into their natural state where they can work effectively, that in itself is a powerful process, even aside from the fact that it tells you all this other things about how they work and tells them what the work environment is like and how supportive the team is and all that stuff. CHRIS: Absolutely. I was on one interview. I've only ever really had one interview that just went horribly, horribly awry. There are times where we've had people come in and they are brand new. They're still in the process of learning. They're not able to actually work effectively in a software environment yet. And I put 'yet' in there because I am certain that in time, it's a skill and they'll build it. But there was one particular case where somebody came in and sat down and there were three of us there. They looked at the computer and they looked at us and they said, "I'm sorry, I can't do this." And they stood up and left. They didn't touch the keyboard. They didn't talk to anybody, didn't ask any questions. They just like shook and then left. I felt terrible because that was somebody where I'm certain that if they had been willing to have the conversation and if we could have found a way to start the conversation, they would have started to become more comfortable. They were so intimidated by the fact that they were going to have to talk to more than one person. I don't know. I was lacking the skill at the time to be able to negotiate that circumstance, I think, is probably the way I'm going to say it. JOHN: Definitely, like I've worked with people who have had almost panic responses at the thought of going in and trying to talk about code especially with more than one person and finding ways to accommodate that. I like the way you were saying about how you're focusing on what you can do right at that beginning point. Like how can you get them just into that, slightly starting to loosen up and getting more comfortable so that you can then get them down the rest of the curve. It's so important because there certainly are people who are going to freak out when they realize what that situation looks like. CHRIS: Absolutely. I always empathize because I remember some of my very first interviews. I mean, they were forever ago. It was back in 19 [murmurs] [clears throat and chuckles]. But nevertheless, I remember those interviews even still because some of them were so terrifying. And there were some interviews where people really did a nice job of saying, "You know what? Let's talk for a second. Let's just see what's on your mind." Versus, there were others where you come in and they would just say, "What can you do? What can you do for us?" JESSICA: Yeah. JOHN: And test on Java syntax. JESSICA: So transactional. CHRIS: Yeah. Well, you know, that comment, Jess, you're saying it's transactional and you're right. When businesses start remembering that it's people, it's people all the way down. It's people who are working for the business. It's people who are developing the software. It's people that we're delivering the software to. And I mean, even if you're developing a system that's an API for other computers to use, you're still ultimately building that for people, because without people, why would you bother to build something at all? So, the more that we can refocus on the people that are involved in the system, the more that we can refocus on having people collaborate together and work on the software together and focus their attention on the people that are going to use the software and the people that care about the software and the stakeholders that are trying to deliver software to people. The more that we can focus on all of that, the better off that I think everybody will be - businesses, developers, managers, all of us. JOHN: That's practically a mantra for this show. "It's people all the way down." I love it. [Laughter] CHRIS: That's actually why I started listening to this show. I've been listening to this show for a couple of years now, and that's exactly why I started listening this show is it just really spoke to my soul. JAMEY: There needs to be a lot of empathy in this whole process. And I think that me, having done interviews from the company side and my thought a lot about how to make people feel comfortable and how to do interviews that feel fair and useful and empathetic has helped me a lot. Now, I'm job hunting and I have a lot of anxiety about this kind of thing also and I'm on this other seat. And it's given me, I think, some confidence in that if I go and walk in an interview and I'm treated in a way that I don't think is empathetic or fair, because I've done that, I think I'm better at now being like, "Well, I don't like what you just did in your interview and I don't like the way I was treated. That's good information for me about if I want to work at your company or not." Whereas before, I didn't have this experience and I would just feel bad about myself. I did bad and I failed it. I've been thinking a lot about that lately and the empathy that's involved on both sides and kind of like the confidence on both sides almost. If people are empowered in interviews to be themselves and act normal and act like how you want to act, if everyone could do that, then it would be such a better process for everyone involved, because everyone would get a better idea of what they're walking into with their company and with their candidate. And people can't do that because we've made it this extremely stressful thing. [Laughs] CHRIS: I agree. I think the more that we can serve the people that are coming in to interview, I think the better off they're going to be. We're going to find people that are going to be well-suited to do the job when we treat them kindly to start, we assume that they're going to do well. And something that I was saying before that I lack the skills in that first interview. That was a long time ago. At this point, it was years ago. But now, one of the first things that I say when I talk to people is, "We're on your side and we want to see you at your best." And I highlight that because I want people to know that we would rather see them struggle and succeed than see them quietly suffer until the end of their interview and then go out with their head slung low. And it seems to work out okay. JAMEY: I think that's great because you said that makes it better for your hiring. But I think treating people kindly in this way also even if it doesn't end up being a good fit and you don't end up hiring them, I think you're also empowering them to feel like they deserve to be treated that way in other situations. CHRIS: I really hope so. JAMEY: I hope so, too. JOHN: I think it's powerful to give someone that experience of an interview where even if they don't get the job or it didn't work out for whatever reason, they still felt completely respected. And to realize that that's actually a possibility and that you could actually have that experience interviewing somewhere, that's, I think, a pretty powerful mindset shift for someone to go through, especially if their entire experience is based on unpleasant interviews. And then they can start saying, just like you were saying, Jamey, like, "Oh, maybe it's not just me being a terrible person that makes these interviews horrible. It's that the system is kind of broken." And then you can step out of it a little bit and not take it as a referendum on your worth as a human being and say, "Okay, so this is what they're doing in this process and it's got these problems." And either, "I've still determined that it's a company that I'd like to work with because I can see the humanity of the people I was with despite the system." Or you could say, "Well clearly, they have no consideration for people as humans. I don't even care if I get a callback. Now I know that I don't need to care about this company." And those are both incredibly empowering. CHRIS: You said something I thought was really interesting because you were saying they see whether or not another team is considering people as people or as humans. And something that I've noticed because every so often, I take an interview just to kind of see what's going on out there. What are people doing? How are they interviewing? And it's typically that intro call, that screening call. And I found that in thinking about the interview process and thinking about just treating people as people, that even when a department seems to be geared toward kind of de-humanizing and mechanizing people, I can still find that humanity in the person that I'm talking with just because at some point, they start letting their guard down. I'm so used to now talking to people and assuming that there is a human in there that by the end of the conversation, like, "Wow, I didn't-- ha!" And we both kind of walk away with this new experience because now, I've gotten a chance to talk to someone who's experiencing something different than I have. And likewise, they're talking with someone that is experiencing life in a different way than their department is currently, too. So it has really made a positive impact on my experience with other people. And I don't mean it as in like it's changed the way that they view me, but rather the way that I view the rest of the world, which has been really wonderful for me. JOHN: Yeah. I think actually what you described there is sort of a step beyond what I was just describing, which is that the ability to step back and sort of feel like you have a bit more control of the process. Whereas like you're sort of going the next level up and saying, "Well, I have the choice about whether to come into this situation and treat everybody else as humans also. And maybe I can even influence the process enough that it could become more humane just by the way I come into it, rather than coming into it, being freaked out and tensed and worried about what's going to happen. Like now, I've got that confidence that I could actually influence it and bring it into something that that would be a pleasure for everybody involved." CHRIS: That's my hope. Most of my experience at this point now and I don't mean experience as a work experience, I mean, just kind of like the way that I've been trying to kind of shift how I experience the world is really human focused. I'm kind of a late comer to the party, but I've been reading Peopleware and I also have a couple of books from Jerry Weinberg. JOHN: Yes. JESSICA: Ooh, ooh, yeah. I just read Secrets of Consulting a few months ago and it was amazing. CHRIS: I haven't read that one, but he's on my short list. I've got a little stack of books and I'm just working my way through them. But I read the Mythical Man-Month and I loved it because I mean, we're talking about basically a 50-year old book at this point. And 50 years ago, Fred Brooks was saying, "People, it's all about people." And yet, we still haven't figured that out as an industry in the last 50 years. And then, I also read Cathedral and the Bazaar. I'm just kind of looking at my bookshelf to make sure that I don't forget the titles. And that was another ones, like you can build software and you can lock it away in a safe or you can make it available so everybody can see the source. And then people can work together to make it better for people. And it's just like, there's this theme. And it's magical. I'm really enjoying it because it's re-calibrating how I look at code every single day. Because every day I ask a question like, "Is this serving me or someone else better?" And if it's not, then I ask, "How could it?" And it doesn't have to be that huge sweeping, "We're going to rewrite the whole system to serve everybody right now." It's, "We're looking at this thing. Can we make it work a little bit better for the next person?" Can we make it a little bit easier for the next person to build context more immediately? Can we make it, John, as you said, more humane? Can we actually make that whole experience of working in the code more humane? A friend of mine, actually he's the person that recommended me for the show, Willem, he chatted with -- I don't remember who he was talking with. But Willem Larson, he and I worked together with my friend, Jason. The three of us were looking at code and it was code that was written by someone else. And we knew roughly when it was written and why it was written. And we could tell just by looking at the code that it was written in a panic. And just looking at it, just trying to work through it made all of us feel really anxious. And it was because not only did they write the code in kind of a harried way, the code actually stores that emotional energy. The way you write it conveys what you were feeling. And if code can convey what you're feeling, it's clearly for people and it's clearly written by people because other people can actually feel some sense of what you're feeling at the time. And so, when we would come across that stuff, if it was something that was impacting what we were working on, we would make it a conscious effort to go and try to weed some of that harried, panicked emotion out of there and put some more calm, thoughtful energy in. Because when you're feeling calm and thoughtful about what you're building, then other people will feel more calm and thoughtful when they come back. This brings us right back to ultimately, if you're reading that, it's like reading a good book. It's like sitting down with that old friend, the page turner, and you understand it and it says something to you and speaks to you in a way that you can walk away and go, "I'm thankful I read that. That actually made my day a little bit better." And that's really what I would love to see in all the source documents we produce. There's no promise, because there's always going to be that time when you're just like panicked and just like trying to, "Can I just make it work? I don't...ugh! It works. Good enough. I got to walk away." Right. That will be there. That will live in that code now. But that's also okay. When you know that it stores an emotion, it gives you a lot more empathy toward the person that wrote it last, because ultimately, that understanding that they were probably feeling this when they wrote it, you can now look at it and say, "I understand why. I understand why I'm feeling uncomfortable right now. I understand why this code is not written the way that I would like to see it," because they were probably feeling something. They were probably experiencing something that was making it difficult for them to make choices that would make it easier for someone else to digest code or to work in this code. It wasn't the person and it wasn't conscious. It was the system that they were in at the time and how it impacted the moves that they made. That whole idea of energy stored in code is really what kind of drives me. JAMEY: I love that. JOHN: Yeah, it ties in with, I think, a point we probably mentioned a couple of times on the show, which is that I think some people default to like, you read some code like that and you say, "Well, this person was a terrible developer." Or they write a lot of bad code or whatever it is, because you stripped it off of all context of why it was written that way. But bringing in that empathy of saying, "Oh, I can really tell this was written because they had perhaps something in production in 10 minutes or they were worried about their job," or whatever it was. You have that empathy for why it was written the way it was written. Then you say, "Oh okay, some stuff was going down at the time, but now we [inaudible] collected and we can make this better," and then pass on the good vibes to the next people. CHRIS: Hopefully. Hopefully. JAMEY: I think that's really important too, if you still work with that person. Nobody likes for their name to come off on git blame and then someone's yelling at them about something they did two years ago. [Laughs] CHRIS: If it's code that you wrote two years ago, I mean, I look at code that was two years ago and I'm like, "Boy, that was a mistake." But it's because I'm looking at it with eyes that are educated in a different way now. JOHN: And actually that brings back right to the education thing we were talking about earlier where trying to talk to early career developers, people are still learning coding about that experience of, and it takes a while because you need some months to pass. But if you have them go back and look at their early projects and say (a) it looks like terrible code because now you're better at coding. It's a good way to show progress. But also (b) look how easy it was for you to forget all the details about this code even if it was only a month ago that you wrote this because so much has happened since then. And so, this is why we're paying attention to the way we're writing and the way we're communicating about it and making it understandable to other humans, because those other humans may very well be you. CHRIS: Absolutely. Oftentimes, it is, at some point. If you're at the job long enough, it's going to happen. Something I actually brought up with a student of mine last night. Actually, there are a couple of things and both of them playing directly to what you're talking about there as far as that experience looking back. There are a couple of graphs that I really like. And of course, this is a non-visual medium, so it's going to be really hard to see what I'm waving my hands about. But if you imagine your progress, it's going to be monotonic in a direction. It's going to basically go up and to the left. And then your experience which is actually what you're going to see as you work through that is there's going to be this sinusoidal movement across that line. Even if you're at a plateau, you're never going to get worse as you learn. You'll never be worse today than you were yesterday for having learned something new. You'll always be the same or better. So what you're experiencing is actually what's defining how you feel at the day. You're feeling on top of the world because you feel like you've learned something new and you're mastering it. Now all of a sudden, you swooped below. I feel like I don't know anything. I'm looking at this and I don't understand what I'm doing. Now, I feel on top of the world again. There are those memes that go around and say, "One minute, I'm amazing; and the next minute is, I'm so terrible." People reflect that by looking at their code and saying, "I don't understand this code because I'm terrible." And really what it is, is you're experiencing this, "I don't understand how to solve this problem yet. And so, I'm feeling bad about it. I'm struggling in some way and it's causing me to have kind of an emotional dip." So really, it's just this sinuous kind of move. And then the other thing and I know that I'm not the first person to say this because I got it from someone, but there's like the valley of despair. So when you first start and you're learning, there are all these resources and everything is learning and every little thing is an order of magnitude better than what you were doing before. But eventually, that runs out. There's only so much that you can do that's brand new that you've never seen before, because eventually, the things that are new become fewer and longer between. So all of this stuff that's kind of condensed at the beginning starts to spread out. So you feel worse about it and becomes harder to find resources to drive you forward in new directions. You kind of feel a little lost at sea. And so, you kind of do this swoop downward into the valley of despair. And this is kind of you're like beginning as high, then you're mid, like your early mid-career years are kind of low because you just don't know where to look or who to turn to. And then as you start to kind of finally make those new discoveries and you find a community that makes sense to you, then you climb out of the valley of despair and then your career really kind of moves into this new place where you're feeling okay about things again. And now when you discover something you don't know, instead of feeling you're disappointed that you're not better at this, you're feeling like you've discovered something new that you can explore. And so all these things kind of helped to bolster your mood. So even though you still go through those little swoops of up and down, you have this movement. Rein isn't here, so I'm just going to say Virginia Satir would talk about this as -- [Laughter] CHRIS: But yes, I mean, it does kind of mirror that Satir Change Model, but in a different way. And it's personal. It's distinct for every person. JAMEY: Earlier when you were talking about our writing, reflecting our feelings, you said something about when you're reading a piece of code or a document or something, having the feeling of like, "I'm glad I read this and it made my day easier or better." I really like that. But I'm wondering, how do you determine if something you're writing is going to do that? Because sometimes I think about like, "This is helpful for me when I'm thinking about it." How do you go about trying to decide, like, will this be helpful for someone else? CHRIS: I kind of assume that it's not my place to know whether it will be better for someone else. All I can do is make it better for me and the people that I'm working with at the time. Because I figure if I do that, somebody else will come along and say, "Oh, I can make this better." And then they'll add some improvement. So I don't think that it's a one-pass done. I think it takes a lot of people over time to build that. And this is actually why I've really been using that metaphor of a book, at least mentally, I will talk about it a little bit, is because you can go and edit and edit and edit. It doesn't have to be this one final document. A book is eventually published, but ultimately, I mean, the source code will iteratively go through editing process. And every one of this is both an author and an editor, but in all likelihood, we're going to edit someone else's work and we're going to author new work. And then someone else is going to edit our work and then they're going to author a new words. And so all of that will come together, hopefully, to create that experience of a wonderful experience for someone. JESSICA: Nice. So it's not your responsibility alone to write the humane code. It takes more of humanity than just you. CHRIS: Right, exactly. JAMEY: I like that. Because it's a big burden to put on yourself if you're like, "I'm the one who has to fix off this in my organization." CHRIS: Oh, my gosh. Yeah. If you're feeling that way, then either your organization is probably putting some burden on you that's unfair, or possibly you're being unfair to yourself and you can offload some of that responsibility to others around you because they would love to feel empowered. JESSICA: Yeah. Okay. Now reflections? I have a reflection. I just love the bit about how code can convey emotions that it kind of captures your feeling at the time. Sometimes the characters really do look different if I hit a key harder. Usually, it's just that I'm naming with [inaudible] the code itself can make you calmer and more thoughtful when those are the feelings that went into it. So even a code can be Greater Than Code. CHRIS: I love it. JOHN: I can go next. For me, I don't think we were expecting to dive into interviewing and hiring questions with this. But I love how we just so effortlessly smooth right into that process because it is part of the interface between humans and coding, is that job acquisition process. And it's so important that right now, it's so broken for most of the industry. And so, the way that you were talking about structuring your interviews with the goals around comfort and familiarity and getting people into that place where they can actually perform at their best is really striking to me and something I'm going to keep thinking about for quite a while. JAMEY: I, too, was thinking about a conversation about imbuing things with the feeling when you wrote it, because I think that it's cool that it kind of has an action [inaudible] both sides because we talked a lot about reading code and feeling those feelings of whoever wrote it. But I think it also says something about what you can do. If I'm feeling frustrated and I write a note in the code about my frustration, that's helpful. But maybe I could write it in a way where I'm thinking about who's going to read it and how it's going to immediately make them feel. There could be two notes that give someone the same takeaway about my frustration and what I was going through when I wrote this code. But it could be written in different ways where one of them is like I'm yelling and I immediately stress out this new person with my stress. Whereas another one can be like, "Here's the context. But I'm trying to present this in a kind way." If you realize that someone else is going to be feeling your feelings, you can set them up in a better way, even if they feel it either way. You can set them up in a better space to feel that, I think. That's a cool action item for thinking about how I express that into my code intentionally, instead of accidentally. CHRIS: I appreciate where you were going with that. The one thing that I would encourage anybody that's feeling that to think about is that if you're feeling frustrated, kind is great. And I encourage you, if you are in a space where you can stop and say, "I'm going to try to be kind with this." But sometimes you don't have it in you. And so, you're just going to do the best you can at the time. And so, I wouldn't want anybody to feel like, "I have a responsibility and due diligence for the next person." It's kind of like, "I'm going to do the best I've got right now. I'm going to give it my best. And hopefully, the next person will empathize with where I was, understand that maybe something was going on that had me feeling uncomfortable," because ultimately there's only so much you can do. And I wouldn't want anybody to feel like there's this emphasis that the burden is now on them to make the next person feel good, because you can't make anybody feel any way. They're going to feel how they feel. But if they start with a place of empathy, if they look at the code and they start with, "I understand that this person is feeling this way," or maybe they're having a bad day and they're cursing everybody that's in the code. I mean, just knowing that that person did the best they could and being able come back at some point and say, "Okay, I'm letting it go, I'm taking a breath, and now I'm going to come back into this with a clear head," then they'll be able to better understand where you were at. So, don't take all the responsibility, leave them with [crosstalk]. JAMEY: You can't create someone's whole experience but you can try to set them up for success. CHRIS: Sure. You can definitely give it your best. Actually, as far as reflecting, I don't know that I have any new thing to add. John, much like you, I was really surprised that we ended up in the interview space, but I loved it because I do believe that everything is a systemic whole. There is no this piece and that slice and these are not connected because the makeup is the whole system and things that come and go, things that flow through. I'm back in Willem Larsen land because it is the thermodynamics of emotion. It is that how are people experiencing this whole together. And so, the interview process will impact that because the people that are going in there will bring what they feel at work. And the people that come into the interview that are interviewing will also bring their experience from the outside. And so, that will actually change. Even if it's just momentarily, it will actually change the way that the day goes, which will impact the way that the document is created, which has upstream and downstream effects. JOHN: It's great. That's a great [inaudible]. JESSICA: Thank you so much for coming on. CHRIS: Thank you all for having me. I really appreciate all of you. It's been a real joy getting a chance to actually chat with all of you because I spend so much time on the other side, listening. And so, it's really awesome to get a chance to actually chat with you all and get your thoughts on. JAMEY: That's really cool. We have a really cool community of Greater Than Code and the people we've had on and the people who listen and the people who participate in our Slack and everything. And so, it's particularly cool to have someone on the show who's already a part of that community. CHRIS: It's big hearts. JESSICA: Thank you, Chris. And thank you to all of our listeners who are tuning in to Greater Than Code. You can leave us a review on your podcast app. Or if you would like to join the conversation with all of us, you can donate to our Patreon at Patreon.com/GreaterThanCode. Get an invitation to the Greater Than Code Slack channel where we are very kind to each other.