 Hey, how's it going guys? I work for Invisium, we do app sex stuff, it's great. They hired me as director of engineering and that's great except that it turns out that there is no chair and there is no megaphone. That is just not in the picture. Instead, what I got was crushing pressure. What it turns out happens if you're director of engineering is that you don't have this common kind of fallback that I've always had in the past. That is, when I've been unhappy on a previous job before, I've always been able to kind of fall back on one simple truth that I believe, right? It's not my fault. It's not my fault that things are sucky somewhere. It's like, you know, it's totally someone else. It's the CTO or the director of engineering or whoever, right? And, or it's Mike's fault. Actually, a lot of times it's Mike's fault when things are horrible. And so I'm not really proud of that. I mean, that's not the most prideful moment that I've had to say that I fall back on. It's not my fault. But I don't necessarily think I'm alone in the room either. So if you're honest with yourself, I mean, most of us kind of do this. In fact, I would say as engineers, how many of you, and keep your hands up, how many of you in this room have been at your job for less than one year, less than two years? Keep your hands up. Yeah, so most of the people in the room currently have their hands up. Most of them actually went up in one year. And so it's really easy to sort of walk away, to say, well, you know, I tried. It's just not working out. And I would be willing to wager that 100% of the people who raised their hand, when they left their job, they took themselves with them, right? So it's pretty safe bet you didn't think you were the problem. But at Invisium, I was hired to help build the software, to help build the team, and to help build the culture. So I guess what that really adds up to is that it's totally my fault if I end up leaving. So I wanted to really think through what that means for me, and what kind of culture do I really wanna work in? What makes me stay at a place? And looking at it from another angle, what makes me leave? So I wanna share a story with you. And it's really important that before I preface this story, with the fact that, yes, it is true, don't worry about the company that it's for. I can almost guarantee you this company doesn't do things this way anymore. And if they do, they won't be around long enough for it to matter. So don't worry about that. So I was hired to lead a small team of technical folks, and I reported to a CEO. And I was concerned at the time that I took on this job that I was gonna end up not getting the code, that I was constantly gonna be managing. I didn't wanna be just a manager per se. And I was assured that wouldn't happen. In fact, every single question, every single issue that I had was addressed very well. He had very good answers for all of my questions. And he really made it worth my while. And consequently, I took the job, and I fast forward about a half a year now. And strangely enough, I'm not spending a whole lot of time writing code. Who would've thought? In fact, I was spending a lot of time wrangling Kanban boards. You all familiar with these? This is my real Kanban board. I was horrible at my job. And I was, oh, hey. I knew that was gonna happen. I was managing Kanban board full of more urgent tasks than we had time and days. And I was managing people that were super stressed out and trying to shield them from the wrath of our friendly CEO who could only be described as mercurial in his temperament at times. So naturally I approached the CEO about this. And he says to me, and I kid you not, this is what he actually said. You're thinking of this all wrong. Think of it like another development task. Your team members are objects in the system, and you're doing engineering just like you would with software. So he sends me on my way. And it was right about then. I mean, it really all became clear to me. I had been really struggling with this, and just those words alone made it super clear that I understood now what was wrong. And it turned out that my CEO had no idea what he was doing. You see, he was an engineer. And he was trying to run the company like he was still an engineer. He wanted to treat the company like software. That's easy because he knows it, right? And we all do that. And there may be a world where the answer to this question is true, but that is not the world we live in. There is no way, so much false. People are not objects. No matter how you try to slice it, they're not objects. And here I was, so it's really no question. I'm like, why am I miserable here? Well, I can't imagine. Now I was working at a company where the leader was actively telling me, yep, I'm dehumanizing my employees. They are totally objects to me. And no wonder that the employees were overwhelmed. So they were overwhelmed. We're hiring people, but strangely enough, we're unable to keep them around for very long because apparently they had boundaries against this manipulative, exploitative stuff. And it felt very frustrating to me because as much as I would talk to my CEO, it felt like he had a reality distortion field whose polarity was inverted. See, the problem was it was only affecting him. And I was really sensitive to this stuff because look, for about six years now, I've been a volunteer counselor and I work with people. I talk to them for hours and hours about problems and I try to work through this stuff, so I'm, but even before this, I would say I've always been kind of a sensitive guy. So, so I made repeated attempts to counsel my CEO on the problems that we had and kind of remind him, oh yeah, people are people, but it didn't really work out. And so I eventually walked away. And you might think, well, this is a really extreme, this is a really extreme case, right? And okay, I'll grant you that. It's pretty extreme. But I also want to say that it's not really unique in that the values that he had are very similar to the values that most businesses have. They value things like predictability. They value things like being able to measure and they value control because they see control as the way toward those things, towards those things they value. And I understand that. I mean, they want things to be neat and organized. Who doesn't, right? It would be nice if everything was neat. But one thing that I've learned is that people are really messy and they're no less beautiful for it. And how does a company really cope with messy reality? Well, they cope with messy reality in the same way that we cope with messy reality in our code. They use abstractions, right? So they try to reduce humans to another resource to be mined and measured out and applied to the problem. They put us in a little box and they just stack us up ever so nicely. I need three humans for this problem, four for this other problem. Did you ever stop to think that corporations, they actually reduce and abstract humans into human resources, into resources when the only corporeal thing about a corporation is the humans? That's a little weird. And I don't think that's sustainable. So I decided that the first thing about any culture that I wanted to be a part of would be one that recognized at first that we are humans working with humans to develop software for the benefit of humans. And you're probably thinking, yeah, thanks. That's great, you're giving me all kinds of wisdom. But if you stick with me, I believe some things arise out of that simple statement that are valuable. So I landed on the term humane development. And it's not just because it put human back into the words into my development methodology, but also because of what humane connotes. So you have certain connotations come along with humane and the dictionary definition, in fact, for humane is, I think, really useful. Humane, what I think really is interesting about it is that it has to do with inflicting the minimum of pain. And I think that's what we all want. We don't like painful, painful development tasks and painful jobs. How many of you do agile? Do agile? How many of you like really do agile? Yeah, some hands are going down. So I think that we do it less than we think we do. And there was a really good talk called The Land That Scrum Forgot that Uncle Bob gave. And I wanna talk a little bit about that talk right now because I think it's valuable. I realize this is a little bit meta, just stick with me. So it's sort of a history lesson on how agile came to be. And he said that he and Martin Fowler were sitting around and they decided, you know, we need to have an organization of some sort. So they called a meeting and they sent out invitations this meeting. They called it the lightweight process summit, right? And at this meeting is where the term agile came about. Nobody was terribly crazy about it, but usually that's how you reach consensus. Nobody really likes it, but so that's what it was. And he says that he believes that Ward Cunningham was the one who said this, that they should come up with a statement of how they value a certain way of working, but they value another way more. And so you know what resulted from this probably. Many of you have read it, the agile manifesto. The idea is that there are all these things on the left, individuals and interactions, working software, customer collaboration and responding to change. These are things that we should value more than the things on the right. And it was at this meeting that he believes, anyway, that Kent Beck had said it should help to heal the divide, this idea, this agile thing, should help to heal the divide between business and development. And around this time, Ken Schwaber came up with the idea that he was gonna start running a certified scrum master course. And Uncle Bob says he thought it was stupid because he was a developer. But the people that didn't think that this was stupid were project managers. Project managers were signing up in droves to take this certified scrum master course. It was something else they could put on their LinkedIn profile because some people think LinkedIn is for real. And... And... And... And... And... And... Right, so the funny thing about that is that scrum masters were supposed to be coaches. They weren't really supposed to be managers. In fact, they were explicitly not supposed to be managers. If they were a manager, we were doing it wrong. And in fact, the role was not even supposed to be a long running role. It was supposed to not just rotate between team members but actually rotate away. Become unnecessary after a period of time. And I like the way that Uncle Bob describes it. He says, I don't think the project managers who took the certified scrum master course liked that particular interpretation. And so you see, like business often does, it's sort of embraced and extinguished. What happened was we took these things on the left and we gradually shifted them back over to the right. And this happens almost transparently. Do you see how this has happened? Now we rely on certain tools specifically and processes to make sure that we're agile. In fact, we define it in terms of that. And agile sounds great, right? Because again, it implies this speed. And speed is great. And if there's one thing business values, it's hustle. Business loves hustle. And this is a Google image search of the word hustle. It's like some kind of messed up wall of motivational posters. I absolutely, I absolutely hate this word. I'm pretty gangster, yeah. I like the one that's like the only place greatness becomes before hustle is in the dictionary. Really? Seriously? Okay, whatever. I hate hustle. I make one exception for this right here. This is the only hustle poster that I would ever put up on my wall. All right, but I mean seriously, think about what hustle really means. And I know at this point you're gonna say something, like all definitions of words change all the time. Find me one definition up there that is remotely praiseworthy. You might say, oh well, you know, busy movement and activity, right? But busy is not a virtue, just because you're busy doesn't mean you're busy about the right thing. I mean seriously, this is messed up. And this is what I think. I think that, regardless of whether you think the meaning of the word has changed, I think that our values have shifted. And we've decided to turn hustle into a virtue of some sort. We consider it very important to have hustle. And we've kind of accepted that in our startup culture for sure. You all know this popular motto, move fast and break things. First made popular by Facebook, now by tornadoes. This is the motto of a tornado. It is a stupid motto. Move fast and break things. Who wants to really aspire to break things? But I think that the notion of hustle as a virtue is the most damaging meme that afflicts us today in our industry. But we accept it because we need to quantify things. You know, we do planning poker, so we can assign points. So we can assign points. So we can track velocity because we're sprinting, right? We're sprinting. And it's a perfect analogy really, because you know, just like any sprint, you have a work to rest ratio. So you know, you sprint for a little while and then you take about three times that amount of time to recover, right? After your sprint. Some people told me, well you know, we have the weekend. When I asked this question on Twitter, we have the weekend, isn't that what weekends are for? Is to recover from our sprint? So I don't know a whole lot about sprinting, but I have done Tabata protocol workouts before. The idea is Dr. Izumi Tabata has found out this way to increase benefits of working out. And the general idea is that you work at your maximum possible output for a certain amount of time and then rest for half that amount of time. And this is what it looks like. So a sprint, you might have one to three work recovery. So each one of these blocks represents 10 seconds. So you might sprint for 20 seconds and then rest for say 60 seconds. So with Tabata, it's 20 and 10, right? You take a 10 second rest period and then start going full bore again. So at the very best, we might be doing Tabatas, but we sure as heck aren't doing sprints. And the thing about this is, these are not designed for sustainability. You're not supposed to be able to sustain the pace of a sprint or a Tabata indefinitely. If we really must stick with some kind of a running analogy, I think we may as well go with marathon. Now I have neither of these stickers on the back of my vehicle, nor do I intend to ever have either of these stickers on the back of my vehicle. However, I do know that some people who have in fact earned the right to put these stickers up have told me that marathons are nothing like sprints at all. Marathons are very much about just finding the way to put one foot in front of the other, repeatedly in a sustainable pace, because for a long portion of the marathon, the finish line is as much an abstract concept as a real thing. And in a marathon, an unsustainable pace is less than worthless. You won't finish the race. Or worse yet, you may not actually be able to run the next race because you've blown out your knee or you've done something horrible. And this is why I believe that a marathon is a better analogy. You need to have an idea of the big picture so you can figure out what sustainability looks like. And this is why I don't think that the big picture is on a need to know basis. And too many companies approach things in a way where they tell you, well, this is the next sprint. You don't think too far ahead. We'll organize the backlog for you, Mr. Developer and Mrs. Developer. You don't need to think about that. So all of this comes down to us wanting to be able to measure progress, right? And so it all really comes down to estimation. So I wanna briefly talk about estimation. This is my driveway about three weeks ago when we had a decent size storm in Louisville, which for Louisville means more than two inches. And then this particular case was about a seven inch snow storm. Now I have had, I have had in the past, snow in this driveway. I know what it's like to shovel this driveway. I think to myself, self, it's gonna take about an hour for you to shovel this driveway. It seems pretty accurate to me based on previous experience. As it turns out, the snow is still coming down. I'm relying on another estimate, the estimate of the weather person, to know when I should probably start this to make sure I don't have to do it again. And the backlog keeps coming down. The snow will not stop. And I go through one pass and I realize, well, it's snowed over what I've done before, so I need to go through another pass and I go through another pass. And then I decide to scrape my wife's car because I'm not really tracking time. I'm just kind of like, well, you know, I'm out here. It's probably been like an hour. I go back inside and I find out that my one hour estimated job turned into two and a half hours. Now, if I can't estimate a job that I've done a million times before and a place that I've done it regularly before because things change, situations change, what makes me think that I can reasonably estimate an abstract concept that is much creative as it is just working from a cue? That's why I think that estimates are lies. And I think it works out okay because even though estimates are lies, deadlines are generally lies as well. So it works out. You miss your deadline, you just move the deadline. Well, okay then. Great, I'm glad we had that deadline. And most things aren't really urgent either. The most important question you can ask as a developer of anybody that comes to you with a task is why. Why is what takes you from a requirement to a reason? You need to know why you're doing things in order to do them in the right way. And most likely, the answer you're going to get from the business is that we're in a hurry and we don't have time to discuss why. Do as you're told. But I bet that we all have some stories of software that we've written to solve problems that turned out not to exist. And that's an incredibly frustrating situation and it can be stopped with one simple question. Why? And you may say, well, there are certain things that are obviously a problem and do I really need to ask why? If the site's down, it's obviously urgent. There's still a reason to ask why. Because there's two answers you can get in a situation like this. And the first is just because it's down, which is a useless answer and that's not helpful at all. But a better answer to why is the site down being urgent is that we're losing something. We're losing credibility. We're losing exposure. We're losing a certain amount of money as the site is down. And a misplaced sense of urgency is honestly sometimes more damaging than no sense of urgency at all. And I learned that better than most in an early, early time. How many of you have stories about doing something urgently, making the situation worse? Yeah, here's mine. When I first started out, I was a sysadmin and I was working for an ISP and we had a customer who's a mail spool. This is back when Pop3 was a thing. Anybody remember Pop3? And so we had a situation where the Pop3 daemon would occasionally corrupt a mail spool. And so I had to go in and I had to re-reason mailers. So I go into the directory and I'm rm-rf on the directory. And it turns out, yeah, let me see where this is going. Turns out I was a directory higher than I thought I was. And so boy, this remove is taking a while and I'm like, you knew the sinking feeling, right? So I got to spend the entire afternoon restoring from backup because I urgently solved this customer's issue and every other customer's issue as well and it was great. You're right, so the other thing is with deadlines and this happens with deadlines pretty frequently. You get this kind of, I call it a recursive non-answer. I mean, you go and you ask why do they need this by a particular date? And you get the answer, well, so we can get this other thing by another particular date. And this, you see where this is going and eventually as with all things recursion and since we are Rubyists, you eventually blow your stack. You get super, super offended that you've gone like 200 wise and you still haven't gotten to our real reason. And I think it's important that we recognize that this divide that we're supposed to heal is really a lie as well. There's nothing really there. It's a construct we created. We are humans working with other humans to develop software for the benefit of humans. That means there's no us. We need to understand the business rationale. We need to understand what it is that the business gains by tasks. And on the flip side, there's no them. They need to understand the trade-offs that they're asking us to make to fully appreciate one another. And this is a shared unity of purpose and understanding that a mission statement does not get you and the only thing that gets you there is empathy. And we need to build empathy in our organizations and in ourselves. Once you have empathy, it pretty naturally leads to another important value and that's honesty. Nobody wants to be told because I said so as the reason whenever they ask why they need to do something. Empathy allows you to get there and to give somebody an honest answer and take the time to explain to them what's up. And if we get attached to setting arbitrary deadlines, is it any wonder that we often end up with implementations that reek of feigned ignorance at worst or at best and malicious compliance at worst? I mean, how many of you have said something like, well, I got what was in the spec done. That wasn't in the spec so I didn't build it. And that's really malicious compliance if the feature is like a customer needs to be able to log in. And so dishonest deadlines encourage smoke and mirrors implementations. They reinforce the idea that it's more important to adhere to a timeline than it is to be building the right thing and the right way. And eventually the business is going to look back and wonder why it's going under when it hit all its milestones. Now, some businesses don't allow that to happen because they simply handle the problem in another way. They cram all the necessary work into the timeline that they arbitrarily decided and it's not at all scrumptious. So crunch mode is and should be an exceptional situation. It should be handled as such. So oftentimes the way we approach building our applications is that if we run out of time, we just engage crunch mode. We sacrifice our time, our sanity, our loved ones for the business goal. But this looks an awful lot like using exceptions as flow control to me. And swallowing an exception to get the, just to return the same result is not helpful. You need to know that something is going wrong. You need to allow that exception to raise. You need to track that exception. And that doesn't mean that you don't handle the issue as it comes up, right? You do, you handle the issue because it needs to be handled assuming the deadline is not a lie. And then afterwards you conduct a post mortem the same way you would with any other production failure and you figure out what went wrong and how do we prevent it from happening again? Look, it's all great, well and good to have heroes, but I'd rather live in a world where I don't actually need them. And the way to do that is to try to refine your process so that you're not constantly needing heroes and needing rescuing. So with that in mind, I wanna show you my best code ever. I have to get this into a slide somewhere because I'm so proud of it. And here it is. It's the best code I've ever written. I'm the most proud of this code. This code, this code has 100% test coverage. It requires zero maintenance and it does exactly what you think. Okay. And there's value in that. And we are so quick. We are so quick to just assume the axiom that no code is the best code. We all say that and we believe it. We would rather not have to maintain code so we don't write code we don't need even though it's tempting sometimes because coding's fun. But formalized processes are code for your company. And they require maintenance and sometimes they have bugs and depending on the interpreter that you're funneling them through, meaning the person, they may result in very strange results. Formalized processes are code for your company. And so if you should be skeptical of coming up with your own code or process, then you should be doubly skeptical of assuming other people's processes. That's, of course, excluding humane development which is awesome and you all should do it. So I like to look at adopting processes as sort of like doing a software integration. You know, there are some that are just kind of lightweight, easy to understand gems. You kind of get the general idea. You add it to your gem file and you're happy, right? And then there are other things that are sort of heavyweight frameworks that require a lot of you and have a lot of opinions and have a lot of expectations of you or your business in the way that you're gonna code. And so I think of adopting processes that way. They're gonna have trade-offs. And then there's the problem where you can adopt a process in name only. It's kind of like you add mini tests to your gem file and then you never write any tests or you never run them. Nobody ever did that, right? So I think processes are a problem statement. And what they're really saying most of the time, they're kind of saying that you don't have trust. They're a stand-in for trust. And in some situations that's warranted, we don't necessarily like with TDD. We don't trust ourselves to write code that does what we think it's gonna do. So we have a process that we follow to try to ensure that we do. But others are more nefarious. Sometimes we just don't trust other people to do things the right way that we have determined because somebody messed up one time. That is not something that needs a process. That is something that you should address the source of the problem. You should go back to that person and you should walk them through what's necessary. And you use processes, formalized processes as a last resort because you will end up with legacy in your processes the same way that you get legacy in code. You've all probably opened up a source file that you haven't seen in years to see a huge nested, if then, set of conditionals. And you know every single one of those things is there for a reason, but you couldn't possibly point to why now. And if they're not tested, then the first thing you do to try to refactor this is you write some kind of throwaway test like Coraline talked about. You try to figure out what the existing behavior is and you treat that as the source of truth. Often in organizations, you end up with the same thing. Somehow the process becomes the definition of right. The rightness is determined by the adherence to the process, but we don't really know why anymore. We don't understand the rationale. And so I like to encourage what I call process metaprogramming. And that sounds like kind of a loaded word so I thought the best way to explain that would be an illustration. This is an illustration of a cat. It's a nice illustration, I think, throughout myself. I'm told that that's apparently not a good enough illustration. So my friend, Glenn Vanderberg, shared a story from his life that I think pretty well illustrates this. And it's from when he was learning to drive. Now I don't think he learned to drive in Georgia, but this just happens to be the prettiest driver handbook I could find. And his father sat him down and gave him the book. And he was like, well, how am I supposed to learn all of these rules? And you know the kinds of crazy rules that you see, right? This is like diagram, and you're looking at this as a 16 year old kid and you're just like, really? I'm just gonna forget I ever saw that. How am I gonna pass that on a test? And the funny thing about this is, this was not intentional, but as it turns out, this tiny little thing down here at the bottom, it says exactly the problem with this kind of a process, which is this roundabout diagram is an example only. Doesn't represent all roundabouts. So this is the problem with processes, right? You can put as many as you want out there, but you're not gonna cover all the cases. This is not the way to solve the problem. You step back, you explain why. And Glenn's dad knew this very well, and what he actually told Glenn was pretty darn wise, actually. Just drive so that everyone around you knows what you're going to do before you do it. That's the logic behind almost all of the rules. And even in the rules that just happened to have kind of an arbitrary decision made about what's going on, the reason that that decision is there is so that people can actually know what the other person is gonna do. It's not just to make an arbitrary decision, it's so that we have a shared understanding. This is really important because if we can do process metaprogramming, if we can tell people the why, give them the context, then it allows them to derive their own solutions for problems you haven't thought of yet. They all have their own processes and they'll be consistent with the general ideas that you've already kind of instilled in them. If we don't do this, what we end up with is tools and lots of them because we need tools to manage our processes and tools to kind of flow through our processes. And if formalized processes are the source code of an organization, then tools are the compiled object code. We feed a team a set of arbitrary processes and they decide to build a tool. And now the tool is, again, it's an abstraction between the real process and how we go about it. And so I think that tools all go through three phases and in the first phase, they reflect the process that actually was in place. There was some manual process, some process that we all understood and we decided we're gonna make it easier with a tool. Eventually, the tools become the process and the way that we get a new hire and we say open up Scrum Bun, Agile Tracker and click on the Agile tab. This is where all of your work will be done. And finally, they define the process. The path to changing the process now involves changing the tool. We no longer have the ability to simply be Agile and respond to changes as they come. We have to first fix the tool or otherwise people are gonna be doing the wrong thing. You see, again, the transformation that occurs. We started out asking the machines to serve us and now we're serving the machines. Now we have to do extra busy work just to be able to change a process that works for people. So I would encourage you to build small tools, primarily because small tools are honest. CP has no, the CP command has no big designs on doing anything other than copying files. We don't expect it to. We know exactly what it's gonna do. It does one thing, it does it well. This buys us flexibility and flexibility is not just important for processes but also for people. This is a guy I've talked about before. Dr. Martin Seligman is considered the father of positive psychology. This is him in the 70s. Looks like a pretty hip guy, right? Looks like the kind of guy you'd like to hang out with. Shoot the breeze, have a party. Certainly doesn't look like the kind of guy that would be shocking dogs, would he? But it turns out he did. And this is hard for me to talk about because this is pretty upsetting. He did an experiment in which he had this box and he had dogs and they lit up an indicator that a shock was going to come. Aversive stimulus is what the scientists call it. It's pain is what it is but we call it that so it sounds better. And at the time that this light would light up the shock would happen momentarily and some dogs were able to escape the shock by jumping over a little barrier. Other dogs were unable to escape the shock and so what happened was after a period of time he took the dogs that had no escape from the shock and he put them in one of the enclosures that did have a barrier they could leap over to get away from the pain. But what he found out was that those dogs just laid down and they just took it. They just took the shock. They didn't even try. And they called it learned helplessness. The feeling that you had no control over your situation that eventually made you stop trying. And as it turns out this translates to humans. This experiment's been repeated multiple times since. One well publicized one was Ellen Langer and Judith Rodin. They did a study that was tantalizingly titled The Effects of Choice and Enhanced Personal Responsibility for the Aged-A-Field Experiment in Institutional Setting. And what they did, the structure of the experiment was that they went to a nursing home and on one floor they instructed the nurses to tell people that they were responsible for themselves. They told them that they had freedom to make choices and they went around and they gave a choice of a bunch of different plants and they asked the person to care for the plant. And on another floor the nurses were encouraged to tell people how much they were responsible for their well-being instead of the individuals, instead of the elderly. And how they would make the choices for them and in fact they would assign a plant to the person. They got no choice. They all got a plant and the nurses would take care of the plant. And what they found out over time was that on every conceivable metric of well-being, these people that were given choices were thriving compared to the ones who weren't. And so if you're a manager, you probably think to yourself, well, there's always one choice. If you don't like it, leave. Everybody has that choice. If your people are resorting to that choice, then there's a very likely chance that you are abusive. This is the excuse that everybody uses. Everybody that abuses power says, if you don't like it, leave. Or if they're still here, they must think it's all right. We're better than the next guy. But there are a lot of reasons that people might feel that they don't have that power. Some of them are financial. I can't be without a job and I can't go look because it would take time away from my job. Some are relational and emotional. There are lots of reasons and it really doesn't matter. You don't need to know the reasons. You just know that if that is their only recourse, then you have failed. And for me, you remember this guy, I was feeling like I was abandoning my coworkers. I really didn't want to leave. But after I got to a point where I had tried and failed multiple times to change the culture, I did leave and I dreaded calling my CEO and he predictably made me feel like utter crap. I mean, this is all really depressing, right? So you all may know this guy. He's kind of the avatar for my favorite Twitter account ever, PHPCEO. And as it turns out, there are a lot of images of this particular model available. And I'd like to just for a minute, suspend disbelief and pretend that PHPCEO's avatar is in fact PHPCEO because as it turns out, PHPCEO really likes ice cream. Like a lot. He really loves it. I found this hilarious. There are more. I don't have time. Anyway, the sad part, the sad part is, we as developers, we're just like those dogs and we're just like those elderly people. We feel helpless sometimes to change things. And it's frustrating because as developers, we have some of the most freedom ever. We can work anytime, anywhere, and in tons of different ways that all will result in productive output. And if you're a manager, you might be thinking, he's crazy. Now there's no way I'm gonna let my head team have all that flexibility. But that's why we've been spending so much time talking about these values, empathy, honesty, and trust. Because once you get to trust, you can begin to relinquish some control and give your people autonomy. And let's just for a moment assume this guy had any point at all. Let's just say people are just like objects and we're doing OOP. Well, as we all know, OOP isn't about objects anyway. Everything about your organization is encoded in messages. And the point of a process should be to be a reusable message. Think of it like a compression scheme, right? You see the same message repeating. So you put it into a process so you can refer to the process once. That's what it should be. It's about increasing the SNR, the signal to noise ratio of your communication so that the important messages will rise to the top and you don't have to say the same things over and over. And since it's all about communication, this is why I think that requiring developers to work on site is a complete joke. We have so many wonderful avenues through which to pursue communication. And people will say very frequently that face-to-face communication is the best, the most high throughput way to communicate. But I'd like us to stop trying to substitute throughput for efficiency because programming is written communication and we should all be good at communicating. So if we can't communicate in our organization, what we end up with is these guys. These are the guys that feel like they have to be around all the time. They're omnipresent. They're on that email thread, someone started within five minutes of receiving it. They work 13 hour days in the office or in chat and then they commit code they couldn't get to during the work day at 3 a.m. And I don't know if they're participating in some kind of sleep study, sleep deprivation study. Maybe they just feel that they are gonna miss something. That's usually the case. They feel like the company's gonna fall down if they're not around because there's no clear channel of communication. And the worst kind of these guys feel like they're heroes. They wanna be the hero. They need to, important point about heroes. Necks are not necessary. You can turn your head whichever way you want regardless of which way you're next facing. They wanna make sure everyone knows they're working harder than the next guy. And these people, these omnipresent people are their organizational morphine. They mask the pain that the organization should feel by continually bailing them out of situations they shouldn't be putting themselves into. And the problem with morphine is it's great for a short period of time but you can develop dependency on it and you're not doing the company a good service if you allow them to become dependent on your heroics. So stop it. Stop doing it. Eventually you need to step back and let the company fail if only in one possible endeavor so that they can understand that the process isn't sustainable. Because, and we say this in counseling a lot but it's attributed to an author, Tony Robbins. Change happens when the pain of staying the same is greater than the pain of change. The funny thing about all this is that we're thought workers. That's what they say we are in this industry. We're thought workers. How do you measure thought? This guy, he's working. And I guess this guy is like working really hard, maybe? I don't know what that even means. How do you measure thought working? And the funny thing is is that we've all had this experience where we're in the shower or something and we have this realization. We wake up and we have this realization. We are literally always working. So remind each other of that. It's okay to step away from the computer. Work doesn't magically happen because your butt's in a chair. That's just not how it works. And if you're a leader, lead by example. In my specific situation, I try not to communicate with anybody on my team except during business hours if I can avoid it. Somebody asked for a vacation time. My CTO told me it was okay. I said that's great, I'll let him know tomorrow morning. It was like 8 p.m. I don't need to be sending him emails at 8 p.m. because it implies that he should maybe be online at 8 p.m. to get them. Really it comes down to four key values, this humane development idea. Empathy, honesty, trust, and autonomy. And the funny thing about those is they're not even engineering specific. These are just values that I want in a human being. And I guess that's really what it comes down to when you're hiring. Stop looking for people to control. And if you've learned one thing that you should be asking right now, it's why. And the reason is that that's just not how relationships work. That's all I've got. Thanks.