 I'm going to actually introduce Ernie, since that's why Ernie's here, and thank you so much for coming. Ernie, some of you may not know him. He was a childhood television star with his best friend Bert. He, some people got it, I'm surprised by how many of you have never seen Sesame Street. Ernie also wrote Active Record and MySQL, if you guys have used those things. Ernie invented the select statement, which is actually pretty useful. I don't know if you guys use that. Ernie actually is one of the best database people I know. So you should come up and say hello to Ernie and follow him on Twitter, just so you can tweet him all your database questions. Preferably like first try. Step one, tweet Ernie. Step two, Google for an answer, okay? This is Ernie Miller. Can we get a round of applause, please? Good morning. You all look bright-eyed and bushy-tailed. So important business out of the way first. Terrence made a request yesterday, and I want to honor that. I have 154 slides in 35 minutes, and I got a late start because someone had to change into their space suit. So I just want to make sure that everybody is remembering that as I go over. I'm trying to get a sense of whether or not I can frame you all without doing panorama. And I think I actually can. So can we all stand up for a moment for a Friday hug? All right. You all look beautiful. You're all awake. Blood is flowing. You're up, and arms are extended. All right. On the count of three, three. Ha. Oh, you're beautiful. All right. We'll post that later. I suppose I don't really have time to post it at the moment. Silly me. Okay. So with that out of the way, I work for a company called Invisium. I started there back in October. We're an application security consultancy, which basically means we do security audits on applications for people that I would love to tell you about, except they would probably kill me. So they hired me as a director of engineering, and as it turns out, neither a fancy chair nor a megaphone come with that job. What does come with that job, however, is an astounding amount of pressure, because you see in every job that I'd ever held up to this point, I was able to look at myself and say, like, if I was unhappy with a position, if I was unhappy with a company or whatever, I was able to kind of say, well, you know, it's not really my fault, and so I could leave, and I could kind of feel like, well, it wasn't my fault. I didn't make things rough, and I'm not terribly proud of that. I'm really not. I'm a little bit of a shame, but I also don't think I'm necessarily alone. That is, as I understand it, it's not very common for us to stay in a position for very long, right, as engineers. How many of you have been in your job for less than a year? Wow. Okay. Less than two years? Yeah. Okay. So I don't even need to keep going with that. So basically, nobody here has worked the same place for more than about two years, and so I think when you left the previous job, you took yourself with you, right? So you probably didn't think you were the problem either, and you probably felt it was impossible to fix, and so it just was easier to move on. And so here at Invisium, the problem is they wanted me to build software. They wanted me to build the team, and they wanted me to build the culture, which all adds up to saying it absolutely is totally my fault if I'm not happy there. So that put a lot of pressure on me, and I started to think about what is it that makes me stay at a company, or even maybe looking at it from the other way. What is it that makes me leave? So I want to share a story with you. It's about a former employer, and I want to make it very clear to you that it is not important who this employer is. First, I'm sure they're not running things this way, and second, if they are, they're probably not going to be around for much longer anyway, so you don't have to worry about it. So I was brought on to lead a team of technical folks, and I was going to report to the CEO, right? And so when I talked to the CEO about coming over to work there, I was really concerned that I was going to end up just managing, and I really wanted to write code. I wanted to remain technical, and I was assured that wasn't going to happen, and he made it really worth my while to take the risk. And so I decided to make the jump. And so you fast forward about half a year or so, and I wasn't spending much time writing code, imagine that. And instead, I was spending a lot of time wrangling a Kanban board, or some variation thereof. Nobody's Kanban board is actually that simple. And I was triaging, you know, a Kanban board full of more urgent tasks than we possibly had time to do. I was checking in on overworked, stressed out employees, and I was doing my best to try to shield them from the wrath of that jovial CEO. And I went to the CEO, this guy, and I talked to him about it. I was just like, this is a little bit messed up. This is not what I signed on for. And he told me this is not going to wisdom. He said, and I kid you not, this is what he said, you're thinking of this all wrong. Think of it like another development task. Your team members are objects in the system. You're just doing engineering, just like you would with software. And he sent me on my way, right? And it was then that I realized, I mean, everything became crystal clear to me at that point, though it probably wasn't how he'd really hoped it to be. This guy, no idea what he was doing. I mean, he was a former engineer, and he really wanted to treat the company like software. He was comfortable with software, right? But there may be a world where the result of this statement is true. It is not the world we live in. People aren't objects. That's really messed up, right? And so it should come as no surprise that I was really miserable there. I mean, I was working at a company whose leader had actually told me he was trying to dehumanize the employees. And the employees were pretty much overwhelmed. We were putting too much load onto them. They didn't have the time. They didn't feel like they had the time. They felt like if they weren't spending time doing and documenting that they were working on every little thing that they were working on, that it really wasn't happening. And therefore, they wouldn't get credit for it. And they wouldn't be able to go home till 9 PM or whatever. And surprisingly enough, we had a hard time hiring in this environment to fill in the necessary manpower that we needed, right? Surprise, they had boundaries against manipulative and exploitative stuff. I can't imagine why. And it was like my CEO had his own reality distortion field, but the polarity was inverted. And so it only affected him. It was really messed up. And I don't know if part of it might have been like, for about six years now, I've been a volunteer counselor. And so I work with people. I talk to people a lot. And even before that, I would say, I've always been kind of a sensitive guy, OK? And so I was miserable. And I made multiple attempts to kind of counsel my CEO on this. And eventually, I walked away. And you might say that this situation was kind of an extreme. But maybe it was, but I don't think it's terribly abnormal. And I think it's because I've seen this pattern in most of the jobs that I've been really unhappy with. The business has different values than I do. They value things like predictability. I understand why, right? They value things like measurability. And they value things like control because they believe that having control over situations is what gives them those other two things. Understandably, the business wants things to be neat and organized. I get it. It makes sense. But businesses are made of people. And people are messy, but no less beautiful for it. And we need to remember that people aren't always going to be able to be handled in such a way that it makes them fit neatly into these kind of molds that companies want us to have. But so how does a company cope with messy reality? They cope the same way that we as developers do. They use abstractions. And so they try to make us fit whatever mold they want. And they reduce humans to our resource, to be mine. Think about this. Companies, corporations, actually reduce and try to abstract away humans as resources when the only corporeal thing about a corporation is the humans. And so I decided that, first and foremost, everything about any company that I really wanted to work for would have to recognize that we are humans working with humans to develop software for the benefit of humans. And you're probably thinking, well, that's great. That's a real insight. Thanks for that. But just stick with me. I swear I'm going somewhere with this, because other things arise from that realization. So first off, I decided that I would call it humane development. And that's first off because it literally puts the human back in development. And more importantly, because humane conveys the kind of values that I wanted to hold. And here's the definition for humane. I know going to a dictionary definition is kind of a cop out. But I mean, honestly, look at what it means. It's compassion and benevolence and inflicting the minimum of pain. Aren't these things that you'd like to have where you work? You don't want pain, right? How many of you do agile in some way, shape, or form? Most of you, right? Now, I don't pretend that that term means a whole lot these days. But there was a really great talk that Uncle Bob gave a few years back called The Land That Scrum Forgot. And I stumbled upon it while I was doing research for this talk. I want to talk a little bit about that talk, because I think it's really important to share some of the insights that he had. This is a history lesson about where agile came from. So originally, Uncle Bob got together with Martin Fowler and wanted to come up with some kind of an organization. And they sent a bunch of invites to what they ended up calling the Lightweight Process Summit. And that's where they coined the term agile. And nobody was terribly happy with the name, but everybody disliked it, so why not? There was consensus anyway. And he said that word Cunningham had stated that they needed a kind of, let's say a manifesto maybe, something that says what they value more than other things without discounting the previous thing. And so we ended up with the agile manifesto. You're probably familiar with this. If not, you can go to agilemanifesto.org and read it. And it states some things that seem patently obvious when you look at them, right, that these things on the left are more valuable. But it also wanted to not alienate the corporations that they were essentially trying to sell this idea into. And so they continued to say that these other things were also valuable, just not as valuable. Bob went on to say that Kent Beck had reiterated that it really should be about healing the divide between business and development, and everybody agreed. And so a little later, Ken Schwaber came up with the idea to start offering a certified Scrum Master course. Now, Uncle Bob said he thought that was stupid. And every developer he talked to also thought it was stupid. But it turns out that project managers didn't think it was stupid. And they sold tons of these courses and these certifications. And it turns out that it was really what put agile on the map when it comes down to most corporations adopting it. But the problem was that it was making its way into the organization by certifying project managers to be a Scrum Master. But a Scrum Master was supposed to be not a manager. In fact, it was explicitly not supposed to be a manager at all, and it was supposed to rotate. It was supposed to rotate between multiple people and eventually fade away. And I kind of liked the way that he phrased it. He didn't think that the project managers who took the certified Scrum Master course liked that particular interpretation. And so we gradually saw, are you seeing what happens here? This transformation from the stuff on the left gradually starts shifting back to the right. And now most of us are using some kind of special process, named process, or tools to manage our quote unquote agile. We're not focused on those things on the left as much as we might like to be. And so one of the things that that really speaks to, the agile term, is speed, right? It sounds speedy, it sounds fast. And in fact, you can go fast with Scrum or with any agile methodology. And that plays really nicely with another core business value these days, hustle. This is a Google image search for hustle. It looks like some kind of messed up wall of motivational posters. I mean, the only place greatness comes before hustle was in the dictionary? Really? I mean, I absolutely hate this word. I make one exception and it's for this image right here. This is the only image allowed to have hustle on it. But if you look at hustle, oh yeah, you want a little more of that? Yeah. That's pretty good. Okay, so that was definitely worth the extra 20 seconds. Okay, so this is what hustle means according to the dictionary on my Mac anyway, right? Now you might say, look at this list for a second, seriously. And you tell me if anything in that list looks remotely laudable, this is something we should consider a virtue, right? And you might say, well, you know, are any of the definitions of words change all the time? And hustle doesn't mean that anymore. It means something totally different. Okay, I think we're fooling ourselves. I think that hustle still means this same thing and our values have changed. I think that realistically, we've tried to treat hustle as a virtue and we've adopted this in startup culture as well. In fact, you all probably know this wonderful motto, move fast and break things, first made popular by wrong, a tornado. This is the motto of tornadoes. It's, this is a horrible motto. It's stupid, move fast and break things. Yeah, I can get behind that. The notion of hustle as a virtue is one of the most damaging memes afflicting us today. Absolutely barn on the idea that moving fast is somehow virtuous is messed up. You need to be moving in the right direction and we forget about that sometime and we get obsessed and we play games like planning poker so we can assign points, points. So we can, so we, so we can measure velocity. So because we're sprinting, right? We're always sprinting. And you know, it's a great analogy sprinting because you know, we do a sprint and then we take a nice recovery period to rest, you know, like a one to three work rest ratio, right? Oh, the weekend, you know, we do have the weekend. I ask people on Twitter, do you do recovery after you sprint? And they said, isn't that what weekends are for? Now, I'm not really that familiar with most sprint interval training but everything that I could find seemed to indicate that it typically is, you know, more rest than work. However, I am familiar with Tabata protocol. Dr. Izumi Tabata, which I probably butchered the pronunciation of, came up with this great method of getting more benefit in less time. And it involves actually like a two to one work to rest ratio. And in this little chart here, you got like every single one of those blocks is 10 seconds. So you end up with like a sprint where you have this work and then this kind of long active recovery period. But with Tabata, you're doing two to one work to recovery. So you're doing less. And so if anything, I would say we aren't sprinting. We may be Tabata-ing if the weekend counts, maybe. But we definitely aren't getting the amount of recovery that we need to kind of sustain this. And really it's the wrong analogy anyway, because none of these are about sustainability. You're not meant to sustain these paces for any long period of time. A better analogy if we're going to stick with an analogy is a marathon. Now, I'd have neither of these stickers on the back of my car nor do I intend to anytime soon. However, I have been told by people that do have these stickers that apparently with a marathon, you know, the finish line is more of an abstract idea for a very long period of time. You know it's coming, but you don't worry. You don't focus specifically on the finish line. You focus on going one foot in front of the other in a sustainable pace and following the markers. And you know that your training will have paid off. It's about sustainability. And a marathon, in a marathon, an unsustainable pace isn't just worthless. It's less than worthless. It's gonna make you not finish this race and probably blow you out for the next one as well. You just simply can't operate at an unsustainable pace and run an entire marathon. And this is why it's important to realize that the big picture can't be on a need to know basis. If you don't know where you're going, then how can you possibly plan out a sustainable pace? And whenever companies try to gradually feed you just one sprint at a time without letting you kind of focus on the bigger picture, it eliminates the flexibility of you to help plot that course. Now, all of this is geared towards measurability and all of this measurability comes from one thing, estimation. I wanna talk a little about estimation. This is my driveway several weeks ago. We had a big snowstorm, which for Louisville means anything more than three inches. And it was about seven inches of snow. And I was relying on the estimate that the weatherman gave me as to when the snow was gonna stop to plan when I was gonna go out and shovel my drive. I go out there, the snow is still coming down. I figure I'll make one pass through. And I expected that it was gonna take me about an hour to shovel the drive. So I go out, I start shoveling. The snow is still coming down. I'm thinking, man, this is harder than I thought. I make another pass. I make one final pass on the drive to kind of clear things out. I decide while I'm out there, I'm gonna be nice and scrape my wife's car off because she'd appreciate that. And so I kind of went over and above in certain cases. But the whole time I had this backlog weighing on me that kept filling up, right, with the snow that was coming down. And I think it was really interesting that at the time I didn't even realize that my estimate was way off. But when I went back in, freezing my butt off after a certain amount of time, it turned out I was out there for two and a half hours shoveling my drive. I estimated, this is a drive I have shoveled before. Nothing really, really different about it. But if I can't estimate how long it takes me to shovel a drive that I've shoveled plenty of times before in a house that I've lived in for over five years, then what makes me think I can estimate something that's abstract and creative and I don't even necessarily know what the finished product looks like yet. And that's why I think that estimates are lies. So it's helpful though, then, that we are at least buffered from the consequences of estimates being lies because also most deadlines are lies. We let those things slide all the time. Oh, we just have to adjust the deadline. Well then, was it really a deadline? And most urgent things aren't really urgent. And so it usually just kind of works out and so we don't really realize how much we're lying. And so I think that it's really important that we ask why. We need to ask why to pretty much every requirement we're given, every deadline we're given, every urgent task that we're given. We need to ask what is it we're really trying to accomplish. That's what gets you from a requirement to the reason. And it's really hard. People want to skip that step all the time. And we might think it's crazy to question why, but I bet we all have some stories of apps that we've gone away and developed to solve problems that didn't exist because nobody asked why. And so there are situations that seem obviously urgent, right? The site is down, it's urgent, but still it's important to ask why. The bad answer is because it's down. The good answer is what is it that we're losing while the site's down? It helps you to appreciate the urgency in a different way and also not to take steps that might be more expedient but also put at risk some other reason. I remember when I was just starting out, I was working as a sys-edman for an ISP and we had a customer had contacted us and their mail spool had been missed. This is back when people used Pop3. So Pop3, every so often the dame one would have this way of corrupting the mail spool. And so we would have to go in and clean it out. I did an RM-RF on the, it was a mailder format. And it turned out I was one directory higher than I thought I was. Now I was urgently acting, I was acting with a real sense of urgency to solve this one person's mail problem. But now I had created a bigger problem that took me the entire afternoon of restoring from backups to fix, even though I caught it about 10 seconds later as my heart sunk down into my stomach. And you know, that kind of thing happens when we misplace our sense of urgency. We also have, and this happens more with deadlines especially. Deadlines are tricky. They get into this kind of a recursive loop where you're giving non-answers. So somebody comes to you and they say, they need this feature by a certain date. So you ask why? And they say, so we can have this other feature by another date. It's like, why? And you see this is going, right? And you keep digging and you keep digging and eventually there probably is a real reason somewhere but nobody even can articulate it to you. And so I think it's important really to realize that the divide between business and developers is in our head. It's also a lie. The fact is we are humans working with other humans to develop software for the benefit of humans. We're all on the same team and that's not just lip service. There is no us. We need to understand the business reasons to be able to plan whatever we're gonna work on. And there's no them. They need to understand the trade-offs that they're asking us to make so they can appreciate what they're asking. And it's not enough to get this kind of shared unity of purpose and understanding and appreciation of one another with a mission statement. That doesn't work. There's a word for what this is. It's called empathy. We need to build empathy. And after you've built some empathy, then something else kind of follows naturally, honesty. Nobody wants to be lied to and nobody wants to ask why and be told because I said so. It's easy to empathize with that. It's gonna be more likely to make you give honest answers if you believe you're gonna get empathy from the other side as well. Is it any wonder really if we get so attached to setting arbitrary deadlines that we often end up with implementations that sort of reek of feigned ignorance or at best, malicious compliance at worst? Oh, we didn't put that in the specs so I didn't build it. I just had to stay with the deadline. And we end up with these smoke and mirrors implementations because dishonest deadlines encourage that. They reinforce the idea that the deadline is the important part, the timeline is the important part rather than building the right thing. And so eventually the business looks back and wonders why it's failing when all of its milestones are getting hit on time. And maybe they're lucky, maybe they have people that are willing to handle the problem for them in another way. They crammed the necessary amount of work to do it properly in the shorter amount of time from the incomplete specification or whatever. And it's not at all scrumptious, it's crunch mode. Crunch mode is and should be an exceptional situation. You should handle it as such. You know, if you saw this code, you know, it looks an awful lot like using exceptions as flow control. It's swallowing the exception and getting the same work done in a different way. And it's not helping. You're doing a disservice to the company if you don't raise these issues. Now, in the moment, I'm not saying you don't respond to the issue. If there is a real deadline, if there is something that is legitimate and can't be moved and the work needs done, then you do the work. But you conduct a post-mortem after the fact, the same way you would if the site went down in production. It is a problem, it's an exceptional situation. You need to understand it and correct the problem so that it's less likely to happen again. Look, I would rather live in a world where I didn't need a hero. It's great to have the hero to step up, but I'd rather not need it. So with that in mind, I wanna show you my best code ever. I'm really proud of this code and so I had to put a slide up about it. Here it is. It's amazing. I'm really proud of it. Isn't it beautiful? Yeah. This code has 100% test coverage. It requires zero maintenance. It does exactly what you think it does. So why is it that we adopt this philosophy that no code is the best code, pretty universally accepted as an axiom in our industry? And yet fail to realize that when we formalize processes for our organization, those are essentially code for our company. They require maintenance and they might have bugs. And we should especially be skeptical of adopting someone else's processes, except of course humane development. It's wonderful. Anyway, when you're adopting someone else's processes, you're essentially doing integration and it's not unlike what you do with software. So on one hand, you may have this tiny little gem that's super easy to understand and that you really love because it helps you write better code. And then on the other hand, you may have this sort of opinionated framework that expects you to adapt your business to the process and your code to the process instead of the other way around. Processes are the same way as software integrations. You need to look at them that way. And interestingly too, you can run the risk of adopting a process in name only just like adding mini tests to your gem file but not actually writing tests. What does that accomplish? And so what I really think is that processes are more of a problem statement. And what they really speak to in most cases is a lack of trust. Now some lack of trust is warranted. In TDD for instance, we don't trust ourselves to write code that does what we think it does. So we adopt TDD to kind of protect us from ourselves. But in other cases, we actually just, it's more nefarious. We don't trust others to do the quote unquote right thing, whatever that is in our mind, in a situation. And sometimes it's just because someone made a mistake just once. It is overkill to implement process for one mistake. Address the source of the problem and use processes as a last resort. And processes just like code can exhibit legacy traits. You've all probably opened up some legacy code and looked at some complex if then construct, some giant branching statement. And you know every single one of those conditions is there for a reason. But you don't necessarily know what that reason is. And so the first thing you do, especially if the code is untested, is you wrap tests around it that essentially validate the same behavior that is exhibited right now. You consider that the source of truth. And then as you refactor, you try to maintain that same behavior. But the problem with processes is that eventually we begin to conflate the process with some objective notion of rightness. We end up saying that the process is what makes it right. And we forget that sometimes people can use a process to justify doing the wrong thing. And I think that this is a real problem and you get into this kind of a legalistic kind of view towards your processes. And as long as the process says it, I don't have to think it. This engages your brain. What I would like to suggest is that we approach processes with metaprogramming. It's possible to essentially metaprogram in a process. And what I mean by that is difficult to explain. So I thought I would show you an illustration. This is a cat. I drew you this cat. It's a nice illustration, I think. I drew it last night. Okay, so let's, that was, I'm told, not an adequate illustration of what I mean by process metaprogramming. So my friend Glenn Vanderberg volunteered an illustration for this purpose. And it's from when he was being taught by his dad how to drive. Now, I don't think he learned how to drive in Georgia, but that was the prettiest driver handbook photo I could find. So that's what I used. Now, when you're learning to drive, you get a DMV handbook that tells you all of these crazy rules that you have to follow, right? And most of them are very intimidating, especially to a teenager. You're looking at this book that's like yay thick and you're supposed to memorize all of this and take a test on it and let alone apply all of it in real time when you're driving at 65 miles on a highway. That seems really messed up. And what I love about this, and this was a complete accident, I grabbed this screen grab from the inside of the Georgia DMV handbook. And this little thing at the bottom that you can't read here, I'll blow it up for you. Please note that this roundabout diagram is an example only, does not represent all roundabout designs, right? That's the problem with heavy processes. You are never going to cover all the cases. If you do, you're gonna bury yourself. So Glenn's dad had a really great approach and it was, he taught Glenn that the underlying concern for most of these is really summed up in one simple rule. Always drive so everyone around who knows what you're gonna do before you do it. You have very limited capability to communicate while you're on the road. So you wanna make sure people know what you're gonna do to minimize the chance of having an accident. Now some of those rules, some of those processes are simply arbitrarily agreed upon guidelines so that you can avoid having to communicate that stuff so that people will know. But it's really important to, where possible, focus on just building the minimum of process that you need. This is what I call process metaprogramming. It's giving people rules by which they can derive their own process that's consistent with the view that the company has or the goals that the company has. You're helping people understand the why. It's that question again. Why, why do we wanna do this? Explain that and you're gonna save yourself a lot of unnecessary hand-holding. The other thing with processes, heavyweight processes is they tend to multiply and the next thing you know you need tools to manage them. If formalized processes are the source code of your organization, then tools are compiled object code. And in the case of external, heavyweight third-party tools, they're like compiled object code that was installed off a five and a quarter inch floppy that you may not even know where it is anymore. It's really, really dangerous to base your entire business on tooling. This is what happens with tooling. Okay, so at first the tooling starts to reflect the process. The process that is currently in place at this time that everybody sort of understands. You build a tool to help simplify it or to track it. Good enough, makes sense, right? We're developers, we wanna make our lives easier so we build something. The problem then becomes that next thing is the tool becomes the process. You get new hires in your organization and you don't tell them here's the rationale or here's the process that we followed but you say open up Scrum Band Agile Tracker and click on the Agile tab, right? And that's where you go to do this thing. It's really agile. And after a while, the problem is that the tool starts to define the process. It's no longer enough for it just to be how you describe it but if you wanna change the process, you now have to go through and find out some way to change the tool. You can't change the process independent anymore and you're now locked in and you see again the transformation that happens. Somehow we became servants of the machine instead of the machine serving us. So I would encourage you, I'm not saying all tools are bad but build small tools because small tools tend to be more honest. They don't pretend to do more than they can. Be very leery of large tools. Large tools, especially the ones that say that they're configurable to basically solve all of your problems that you have in your organization. Oh, we can totally, there's a configuration module for that. That way lies madness. You're essentially looking at a de facto programming language. It's just masking all of its programming in configuration dialogues or configuration files. And all of this is about trying to build in some flexibility into what you're doing. Flexibility is really important, not just for the purposes of tools but because it helps you as human beings. So this is a guy, folks who have seen some of my talks before might have seen. I'm gonna call him Marty, his name's Martin Seligman. He's a PhD. He's considered the father of positive psychology. This is what he looks like in the 70s. Looks like a nice guy, right? Guy you'd like to hang out with, maybe have a few drinks. Seems to know how to have a good time. Certainly doesn't seem like the kind of guy that might shock dogs. But as it turns out, he did. He did this study where he put dogs in an enclosure. And in this enclosure, they were given shocks. They were administered shocks. They call it aversive stimulus. That's a nice way of putting it. So they're shocking these dogs. And before they shock the dogs, they give them an indication it's gonna happen in the form of a light lighting up in the sound. And there were dogs that were given a little barrier that they could jump over to escape. And then there were dogs that were not given that opportunity to escape. And over time, they took the dogs that had been exposed to this kind of situation where they weren't able to eliminate the pain. And they put them into these enclosures that gave them the ability to move to another location so that they wouldn't get shocked. Do you know what they found out? They found out that the dogs who had been trained such that they didn't think they could escape didn't even try. And they called this learned helplessness. Now, later, this has been confirmed to also happen in humans. These two women, Ellen Langer and Judith Rodin, did a study with a really, really tantalizing name. The effects of choice and enhanced personal responsibility for the age, a field experiment in institutional setting. What they did is they went to a nursing home and they had two groups in experiment and control because that's how you do science. And in one side, they gave the patients or the people in the nursing home choices to make. And they gave them some aspect of control over their situation. In the other, they told them everything that they were gonna be having done. Even down to like, it's movie night. One of them gets told, there's a movie on Thursday and Friday you can tell us which night you'd like to come. The other ones will be like, we'll get back in touch with you and tell you which night you're assigned to. And what they found at the end of the study was that these people who were given choice had better alertness, active participation and they felt better. They had a general sense of well-being. But the thing with humans, and I mean, probably the thing with dogs too, I mean, you can't ask them, is that you have to perceive there to be a choice. You have to see there to be a choice. And so this line is one of the worst ever. If you don't like it, leave. It's essentially the line that's used by abusers of power everywhere in the world. Well, if you don't like it, leave. You must like it okay, because you're still here. And that's not a real choice. There are a lot of reasons that people might not feel like they have that power, whether it be financial, whether it be relational. Sometimes in my situation with my former CEO, even though I knew I was doing the right thing by leaving my job, I dreaded making that phone call. I dreaded it. Predictably, he made me feel like utter crap. I was a horrible person. I'm really surprised that you could possibly do this. I can't believe you would abandon the team and et cetera, et cetera. Man. And I mean, this is really depressing, right? Dog shocking and helplessness and like the way that I felt. So let's lighten the mood for a minute. Some of you may have noticed this is a famous celebrity on Twitter, PHP CEO, kind of my favorite Twitter account ever. And I found this on a stock photo site. And it turns out that this is someone, there exists many photos. All the photos I've used of my CEO thus far have in fact been, have in fact been PHP CEO, or at least the same model. I like to think of them as the same person. I know that's not true, but let's just pretend for a moment. Did you know that PHP CEO really, really likes ice cream? I mean, he seriously loves ice cream. So, okay. So, but what's really sad about this helplessness thing is that software developers can sink and learn helplessness. I mean, we get to work anytime, anywhere and in so many different ways. And if you think, well, that's not true, you must be insane. You know, I can't believe, I can't believe you would say that. Like why would I ever let employees work anywhere they want to? That's crazy. Well, here's the thing. This is why I've been talking about empathy and honesty and trust. These are the things that allow you to replace control with autonomy. This allows you to give people autonomy. And, you know, to go back to my fantastic CEO, let's use his horrible analogy for a second, that people are like objects and we're doing object-oriented programming. I hate to break it to you. Object-oriented programming is nothing about objects. It's all about messages. And processes are really just, at least good ones, are really just reusable messages. Everything about your organization is encoded in the communication, in the processes, and in the communication between people. And the only thing processes should really exist for is to raise the signal-to-noise ratio for communication. And so what you're doing is you're saying, well, this is a repeated thing. It's a pattern we have seen. It's essentially compression. It's a compression algorithm. Here's a repeated thing that we always see. We'll express it once and be able to refer to it. Okay, and this is why, since I say that everything about your organization is encoded in communication, this is why I say that the requirement to live where you work is insane. It's a joke these days. Stop trying to substitute higher throughput communication from face-to-face for efficiency in communication and knowing who you need to communicate to and when. Because you're hiring programmers and programming is written communication. And if you suck at written communication and if you suck at communicating, what ends up happening is you create these guys. These guys, they're omnipresent. They're always around. They're the ones that are on an email thread five minutes after receiving it. They work 13-hour days in the office. They're hanging out in chat. And then they're committing code they couldn't get to during the workday at 3 a.m. They feel like they need to be around all the time. You think they might be participating in some kind of a sleep deprivation study? Maybe they just feel if they're out, they'll miss something, because nobody will let them know. And the company will fail as a result. They might be right, that's a real problem. The worst kinds are actually the ones that like to play heroes. And they wanna make sure everyone knows they're working harder, make sure their commit logs show up at the right time and that email shows up at midnight. And what happens is these people are organizational morphine. They mean well, they mean well, but they're masking pain. And pain is a message that your company should feel. It's okay short-term to mask some pain if it's unbearable. It's not okay to allow a company to become dependent on an unsustainable practice in order to continue to function. That's not okay. And there's an author named Tony Robbins that said it as change happens and we use this in counseling. Aught change happens when the pain of staying the same is greater than the pain of change. So you need to let them feel pain. The irony of all this is that we're doing thought work. We're thought workers, right? How do you measure? We wanna measure thought work. How do you measure thought, right? This guy's doing some work right here, okay? I guess this guy is working even harder, maybe? This is really what really hard work looks like? How do you measure it? And interestingly, psychologists have known for a long time that there are places where we're completely unplugged from everything else. And you probably know this anecdotally to be true. Where you've found solutions to problems that you weren't even aware you were working on. When you are thinking, if you are a thought worker, you are working, you are literally always working. So respect that fact of your coworkers. Remind them of that fact. If you see them online too long, if you see them online, say, you know, 9 p.m., you know they've been on since 9 a.m., tell them, hey, guy, take a break. You know, you need to go take a walk or go hang out with a wife or go play some Destiny or whatever it is you do. And watch each other's backs. And if you're a leader, lead by example. I personally won't send email to people that report to me after hours. If I need to, I had somebody ask to take some time off, not too long ago, my CTO said, hey, that's cool with me. I said, yeah, it's fine by me. I'll let him know the next morning when I get in. I'm trying to send a message that I don't expect people to be online all the time. So really what it comes down to are these four core values. Empathy, honesty, trust, and autonomy. The funny thing is, none of those are values that are engineering values. These are what I want in my company and what I want in the people that I wanna work with. These are human values. These are just what make people cool humans to work with. So to finish then, I just wanna encourage you to stop looking to hire people to control. Stop trying to bring people in to control them. And if you can learn one thing, you'll ask why. And that's because that's not how relationships work. That's all I have. Thank you.