 I'm on Twitter at Ernie Miller. You probably shouldn't follow me unless, like, this is my most popular tweet. I'll let you read that. So if you like things like that, go ahead and follow me. Yeah. I work for a company called Invisium. We're an application security consultancy. And I am the director of engineering there, which turns out does not come with an awesome chair or a megaphone. Instead, it comes with a crippling sense of responsibility. You see, in previous jobs that I've had, I've been able to fall back on one great excuse. If I've ever been disappointed in how things have worked out, if I've ever been kind of let down by my managers, I can always go back and say, well, it's not my fault. If I wasn't given free reign, maybe. And that's not a particularly proud moment for me to say, you know, it's not my fault is how, you know, I fell back on as far as how I felt about things. But, you know, there it is. And I don't necessarily think that I'm alone. I think there are a lot of you. In fact, by show of hands, I hate shows of hands, but we're going to do it, how many of you are showing your hands already? I haven't asked the question. How many of you have been at your current job for less than a year? Keep your hands up. And if you have been in your job for less than two years, raise your hands. Okay, so look around the room before you put your hands down. Realize that half the people in this room right now, fully half of the people in this room have not been in their job for two years. Okay, you can put them down. Unless you want to just do that for the rest of the, that's cool too. Okay, so I think, you know, when we leave jobs sometimes, you know, first off, you all took yourselves with you when you left the job. So I'm assuming none of you thought you were the problem. Was that accurate? You know, and so, you know, you might have felt like it wasn't possible to fix, like you didn't have any choice. So it's just easier to move on. Now the problem for me now is that as director of engineering, I'm responsible for the software. I'm responsible for the team. I'm responsible for the culture. So essentially it all adds up to being it's totally my fault if I end up leaving. This is a lot of pressure. So I started thinking about, you know, what is it that I really find makes me happy in a job, makes me want to stick around, or conversely, what makes me want to leave? And so it's time for a story, and I want you to know this is a true story. It is not important the employer who this story is about, because first off, they're probably not running things this way anymore, and second, if they are, they won't be around much longer, so it's not going to matter. So I was brought on to lead a team of technical folks reporting to a CEO. This is a CEO. I was concerned I was just going to end up managing people and not get a lot of time to write code, and I was going to hate that if that was the case, and I was assured that wouldn't happen. And you know, I raised a number of other objections that he had a number of excellent answers for as I continued working through the process. And so I went ahead and took the job. Fast forward about half a year. Sure enough, I'm not spending as much time writing code, who saw that coming. In fact, I was spending a lot of time triaging a Kanban board full of more urgent tasks than we had people and time to deal with. This is my real Kanban board right here. I didn't say I was good at it. And I was doing the best that I could to shelter my team members from the wrath of this formerly so jovial CEO. And so I went to approach the CEO about this. And I said, you know, look, this isn't what I sign on for. People are super stressed. I'm not getting to write code. I'm not getting to do engineering. That's what I signed on to do. And he said to me, I kid you not, 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. He sent me on my way. It was then that I realized, probably not the way that he wanted me to, that I knew now why I wasn't happy. I knew now what the problem was. The problem was, my boss was an engineer. As a former engineer, he wanted to run the company like it was software. He wanted to treat it like it was possible to engineer. But there may be a world where the answer to this predicate is true. It is not the world that we live in. People are not objects. It doesn't work. So here, now you can imagine, it's no wonder I was miserable. Here I am. I'm working at a company. My leader was actively working. He was telling me, I'm dehumanizing my employees. They're not humans. They're objects. And surprisingly enough, employees were overwhelmed. And so we were, again, overworked. We're trying to hire. We couldn't hold onto new hires because, surprise, they had boundaries against manipulative and exploitative stuff like this. And so I felt like I was the only one that was seeing this. I felt like my CEO had a reality distortion field, but the polarity was inverted. And so it was just affecting him. And maybe I was miserable. And I've always been sort of maybe a little more sensitive this kind of stuff. I've been doing volunteer counseling for about six years now. But even before my volunteer counseling work, you might say I've been a sensitive guy. And this was really excruciating. And I had repeatedly attempted to use all my counseling know-how to counsel my CEO on this. Like, hey, maybe people aren't objects. Maybe they're people. Eventually, I walked away. And certainly, you might think this is an extreme example. And it was. But I don't think that it's unique. I think that I've seen this pattern before. And I think that the business values some things that are kind of in conflict with what it is that we might value. And it values things like predictability. It values things like measurability. And it sees control as the means to those first two. And I completely understand this. You need to be able to make promises. And you need to be able to know that you can keep them. So I've seen this pattern before. Just not quite as pronounced. And companies want things to be neat and organized. And again, it's understandable. But that's not how people are. And companies are made of people. And people are messy. But it doesn't make them any less beautiful. And so how does a company deal with messy reality? Well, it deals with messy reality the same way that we do as developers with abstraction layers. So you abstract away the human part to get the shape that you want. And you reduce humans to just another resource to be mined, measured out, and applied to the problem. We need x resources times three hours per resource to make this thing happen. And if you ever thought about that, really, corporations abstract humans as resources when the only corporeal thing about a corporation is the humans, that's kind of messed up. And so the thing that I landed on, the underlying philosophy that I wanted to guide the team that I was going to build and any team that I would want to work with in the future, is pretty simple. It just needs to recognize that we are humans working with humans to develop software for the benefit of humans. It's really deep, right? It's really deep stuff. Now, I don't pretend to say this is some mind-blowing revelation. What I do say is that if you stick with me for a minute, there are things that kind of naturally arise from a recognition of this fact. And so I settled on the term for this called humane development. Mainly because of what humane means. Humane is defined as having or showing compassion or benevolence. It has to do with inflicting the minimum of pain. These are all things that I think I would like to see in my workplace and in my coworkers. So I think it's in direct conflict sometimes with something that we do today, or at least the way that we do it today. How many of you all do agile today? Really do agile? You're so agile that it hurts. So there's this talk. Uncle Bob gave this talk, The Land That Scrum Forgot. And it's really interesting because it's a bit of a history lesson on how we came to the term agile that we know today. And I thought I would share a little bit of what he had to say in this presentation as well. Because it's really useful. So he said that he had sat down with Martin Fowler. And said we should form an organization. And they set up a meeting and they sent out invitations. And they called the people that became part of this organization. They called it the lightweight process summit. And at that meeting, they came up with the term agile. He says he believed that word Cunningham is the one that suggested we need some way to say what we believe without disparaging the old way of working. So to say that we value the old way, but we value these other things more. And so we landed on the agile manifesto. You all have probably seen this site before. You've read these four very, very sane insights over the kinds of things we should be focusing on, these things on the left, individuals and interactions over processes and tools and working software over comprehensive documentation and so forth. And I hope it's Kent Beck actually here. Because if I misquote him, this is going to be bad. But I'm quoting Uncle Bob as quoting Kent Beck as saying that if we call this agile thing agile, it should be to heal the divide between business and development. And everybody agreed. And around this time, and not too long later, Kent Schwaber formed something called the Scrum Alliance. And he said that he wanted to start running these certified Scrum Master courses. And so this is really interesting. He says that the people that were taking the certified Scrum Master courses were not developers. In fact, he's a developer, and he thought it was a stupid idea. Who didn't think it was stupid? Project managers. Now, project managers were taking these courses so that they could list Scrum Master on their LinkedIn profile, because they think LinkedIn profiles actually are important. And so they were taking these courses, and now they were Scrum Masters. This was part of their identity. And a Scrum Master was never supposed to be a manager. It was explicitly not supposed to be a manager. But here we had these project managers getting certified as Scrum Masters. And in fact, the idea was supposed to go away. The idea was that you eventually didn't need a Scrum Master at all over time, and you would rotate it among the team members. And I like the way that Uncle Bob said this. I don't think the project managers who took the certified Scrum Master course liked that particular interpretation. And so you see what happened as organizations began to embrace this idea, this agile methodology. They took these things that had been on the left, and it gradually shifted back to the right again. Do you see what happens? It's like an embrace and extinguish. And I don't know that it was intentional. I just think that that's the way that corporations work. But we like the term agile, because agile cannot speed. And speed sounds great. And speed is closely related to another term that we seem to love in the startup industry, especially, hustle. I don't really like the term hustle. This is a result of a Google image search for hustle. It's like some kind of a messed up wall of motivational posters. I like the only place greatness comes before hustle is in the dictionary. It doesn't really say much. But I do make one exception. I'm not a fan of hustle. I do make an exception for this image right here. This is Pizza Cat riding the Taco Turtle. That's OK. If you look at what hustle really is, and people are going to argue with me about this, and I know this. They're linguists that will say, well, the words, they change meanings all the time. I don't know. I think we're fooling ourselves. I think that hustle still means very much the same thing. Find me a definition over there that's remotely laudable, like forcing someone to move hurriedly, engage in prostitution. What is it that's so valuable about hustle? We've turned hustle into a virtue. And in fact, in startup culture, a lot of us have adopted this motto, move fast and break things. You all know where move fast and break things came from, right? Facebook, no. Tornados. Tornados have the motto, move fast and break things. It's a really stupid motto. And I think that the notion of hustle as a virtue is one of the most damaging memes that afflicts us today, as software developers. But we have it. And we spend a lot of time playing planning poker and assigning points. Points? Get it? All right. To track velocity, because we're sprinting, right? We're sprinting. Sprinting is a perfect analogy, because we do a sprint, and then we take a recovery period to rest, right? We take some time to recover from that sprint. The weekend, maybe? People say the weekend counts. Now, I'm not much of a sprinter. I have been doing Tabata protocol stuff for a while now. This is Dr. Izumi Tabata. He's a researcher that actually did some tests where he discovered that one of the most optimal ways to increase your capacity for exercise is to work for these tiny intervals at super intense work level, and then rest for half that amount of time. So I would argue that a typical sprint might be one to three recovery. Each block is 10 seconds in this case. The red blocks are work blocks. I would argue that maybe we're not sprinting. We might be Tabataing, possibly. But it really doesn't matter, because none of these are designed for sustainability. You're not supposed to be able to maintain a sprint. You're not supposed to be able to maintain a Tabata pace. If we're going to stick with a running analogy, I think probably marathons would be a better analogy. Now, I am not a marathon guy. I am told that in a marathon, you're more focused on the finish line being something of an abstract concept for a long period of time before it becomes real. You just focus on putting one foot in front of the other at a sustainable pace. Because if you can't move at a sustainable pace, it's less than worthless. You're not going to finish the race at all, and there's a very good chance you're not going to be able to be in the next race as well. And this is why it's important to be willing to share the big picture with your coworkers. The big picture can't be on a need-to-know basis, because the big picture is what lets us determine what we're going to be able to sustain. If all we're looking at is the very next finish line that's 100 meters in front of us all the time, then it seems easy to force yourself to push a little harder. Ah, this isn't going to be the next. This is the last 70-hour work week I'm going to do. But you need to be able to operate a sustainable pace. How can you plan a sustainable pace if you don't have the destination? So all of this tracks on to one thing, which is estimates. This is a photo of my front drive in February. We had some decent amount of snow, which in Louisville, Kentucky, where I'm from, is like anything more than two inches. We had about seven inches of snow. I've lived in this house for over five years. I've shoveled the drive countless times. I think I know how long it's going to take me. I think it's going to take me about an hour to shovel this drive. I'm relying on estimates from the weather person who says when the storm is going to stop. So I think to myself, I'm going to go out and get this knocked out in an hour. It should be stopping while I'm out there. Well, the snow kept coming. Backlog kept showing up. And I kept shoveling. I still didn't really keep track of the time, per se. And I thought I was probably close to an hour when I came back in. Turns out my one-hour estimate was 2 and 1 half hours of shoveling in this drive that I've lived in this house for years. I've done it a million times. If I can't estimate something like that, where I'm concrete results, how can I possibly be expected to estimate things that are abstract and that I honestly don't know until I start trying to build and that are subjective in nature? I can't. And that's why I believe that estimates are lies. And I think it's OK because it works out. Because we lie to ourselves about estimates, but most deadlines are lies, too. So it's like, oh, we missed our estimate. Well, we'll just move the deadline. Well, then was it a deadline at all? Why did we set that date to begin with? And it's OK because most urgent things aren't really urgent. And this is why it's really important to ask why. The simple question of why is what gets you from a requirement to a reason or a rationale for what it is you're trying to build. And it's really easy in our hurry to say that it's just crazy the question of why we don't have time. But we all probably have stories of some apps or features that we've written that turned out didn't need to exist because nobody asked why we needed them. And so it's actually interesting because you would say, well, there's certain things that are obviously urgent. We can't waste time. In this case, the site is down. Well, sure, it's urgent. So you ask, but why is it urgent? The bad answer is, well, because it's down. That doesn't tell us anything new. The good answer is to say, well, while it's down, we're losing. What are we losing? Credibility, exposure, whatever. It's really important to know what's at risk, so you can assign proper importance to the fix or the way that you might go around the fix. In particular, my friend Pamela in her talk just before mine, she was talking about sharing, I'm sorry, not Pamela. I'm sorry, my friend Kylie was sharing a story about how she had done some embarrassing things. Like, for instance, say the wrong friend's name. And when I was first starting out, I worked as a sysadman at an ISP. And this ISP, we don't have, I mean, maybe 20,000 customers, something like that, it was small. There was a customer who had an issue with his mail spool. Now, we were using mailder mail spools, which not relevant for the purpose of the story. Just know that you have to remove a directory in order to actually remove somebody's mail. We had to clear out the guy's mail spool. So I go into a directory, IRM-RF, the directory that I think I'm doing. You probably know where this is going. I was a directory higher than I thought I was. So because I acted with urgency, I now fixed this person's problem and also the problem that nobody else knew they had, apparently having mail. Yeah, so that's my embarrassing story. The point is, if I had approached this with a little more of a sense of what was at stake, there's a good chance that I would have been a little more careful as I did it. It's really important to know what you're standing to lose as you go about your tasks with urgency. Deadlines are a little trickier than urgency in that you often get these kind of recursive non-answers. So you ask a question like, why do we need a feature by March 20? And instead of getting an answer, well, we need this other feature by April 20. Well, that's helpful. And you keep asking why. You get the idea. It keeps on going. And eventually, there might be a real reason somewhere there, but you're not going to get it in very short order. It's really important to combat this by asking for the real reasons. And you don't get there as long as you believe in a divide. And I believe that the divide is a lie. And that is the first step to healing the divide is to realize there really isn't one to begin with. And what's generally there is one that we've created. We are the tech elite and the stupid business people. They don't understand. And we owe this sense that there is a divide a lot to our own behavior. We have to remember that we're humans working with humans to develop software for the benefit of humans. It means there's no us. We need to understand why the business needs, what it needs, in order to better address their needs, in order to better be able to give them what they want instead of what they ask for. Sometimes they don't know, but we need to actually begin to ask the questions. There's no them, either. The business needs to understand the kinds of trade-offs that they're asking us to make. Whenever they're asking us to sprint really hard in this next iteration to hit something, they need to know what we're giving up. They need to know that maybe we're going to make some technical debt along the path to this as well, that we're going to maybe regret later. We can't reach this sort of shared understanding with just a mission statement. Companies love mission statements, giving people a statement that everybody supposedly can get behind. Usually, they say a bunch of nothing. They don't build the kind of shared understanding and appreciation that we really need. What we need to have is empathy. What we need to build is empathy, both for our coworkers, for our stakeholders, for our customers, whatever you want to say. And if you have empathy, then it's a lot easier to reach something else that's super important, in its honesty. Nobody wants to be told because I said so whenever they ask why. We're going to be a lot more likely to say, well, because of, that's not such a reason, if we have empathy for the people that are doing the asking. And if we get attached to setting arbitrary deadlines, is it really any surprise that oftentimes we end up with implementations that reek of feigned ignorance at best, malicious compliance at worst? Dishonest deadlines encourage smoke and mirrors implementations because they're reinforcing the idea that it's more important to adhere to the deadline, to the timeline, than to actually build the right thing, the right way. And so eventually, your business is going to look back and say, oh, why are we failing? We hit all of our milestones right on time. And of course, there's another solution you can approach to this problem, which is to engage crunch mode, right? We cram all the necessary amount of work into the shorter amount of time. One approach. The problem is that crunch mode should be and is an exceptional situation. We should handle it as such. If I showed you code that looked like this, you might say, well, that looks like you're using exceptions as a flow control. We're rescuing our time out there just by sacrificing our time and sanity. And look, swallowing an exception and getting the same result is not really helping. In the event that we do have to use crunch mode, we should consider an exception. We should conduct a post-mortem the same way that production error would trigger it. And it's okay that we have heroes, but I'd rather live in a world where we don't need to use the heroes. So with this in mind, I wanna show you my best code ever. I'm really proud of it. Glad I got to show it in this talk. Here it is. It's great, right? It has 100% test coverage. Requires zero maintenance. And it does exactly what you think. Oh, we laugh, but I mean we pretty readily accept the axiom that the best code is the code that we don't have to write. So then I want you to consider that processes, formalized processes anyway, are code for your company. They're gonna require maintenance. They might have bugs. And if we should be skeptical of our own processes, then how much more skeptical should we be of someone else's? I kinda look at it like, oh, aside from humane development. Don't, you know, humane development's awesome. Don't be skeptical of it at all. Obey. So I could look at it like doing integration, like with software. You know, sometimes it's like bundling kind of a lightweight and easy to understand gem into your project. And other times it's like an opinionated framework that expects you to adapt to work with it instead of the other way around. Look at the processes and decide, you know, what it is that you're willing to give up. But be skeptical of them. And you know, it's funny because you can kind of, you can also adopt processes just like you can adopt software in name only. You know, maybe you have many tests in your gem file but you haven't ever written a single test or you don't run them, right? Processes are really more of a problem statement. And what's the problem? The problem is that we generally try to use them to replace trust. Now, some processes like test-driven development are warranted. That is, we don't trust ourselves enough to write the code that does what we think it should do. And so as a result, you know, we use test-driven development to help make, like check our assumptions. But others are more nefarious. Like sometimes we just don't trust others to do the right thing for whatever our personal definition of right is in a particular situation. And oftentimes it's because someone made a mistake just once. And if somebody makes a mistake, mistakes happen. Address the source of the problem, the misunderstanding. Don't immediately resort to defining a process. Processes should be your last resort. The other thing about processes that's very similar to code is that there can be legacy in process. Oftentimes what happens is, say you have a piece of legacy code that wasn't covered by tests. The first thing you do is you assume the current behavior to be the source of truth. So you generally wrap some maybe throwaway tests around that code in order to verify that as you refactor this code now, you're getting the same behavior. Not unlike that with processes, you get into a point where absent the context surrounding the decisions that you made, the massive nested if then construct that you've built, the process itself becomes the definition of right versus wrong. But we don't really know why, we don't know the rationale. That's why I would encourage you to do what I'm calling process metaprogramming. And I kind of had a hard time coming up with a way to sort of illustrate this. And a friend of mine, Glenn Vanderberg, volunteered a really great analogy for this. So when Glenn was learning to drive, his dad brought home one of these driver handbooks. And he sat it in front of him. It's like a hundred pages or something of all these rules in minutia that you have to remember to learn to drive. Here's a selection from the one that I just put a photo up of. I like this one a lot. Mainly because I didn't know this at the time that I took this page out of it, but there's this little quote down here in the bottom that you can't read. So please note that this roundabout diagram as an example only does not represent all roundabout designs. That's kind of the problem with processes. We can cover the things that we can think about or that we can think to illustrate, but it doesn't really tell us what we need to know. Glenn's dad had a really great solution for this, which was there are gonna be a few things that you're gonna have to memorize. But the real thing to remember is that your goal is to always drive so that everyone around you knows exactly what you're gonna do before you do it. He gave the rationale. And so then in that context, a lot of the rules, a lot of the minutia start to make sense. They start to come into focus. It's important to try to simplify because if you start to drown in too many formalized process, it inevitably leads you to build tooling to manage or to follow those processes. Now, if formalized processes are the source code of your organization, then tooling is the compiled object code. And the problem with tools is that initially they may start to reflect the process as you follow it. And so it's just reflecting the way that things are going and the way that you do things at a given point in time. But then they become the process. So you have new hires come on and you start to explain to them how to do things and it's like log in to Scrum Bon Agile Tracker and click the Agile tab and that's where you do this stuff. And so then after that, eventually they come to define the process. If you ever wanna change the process at that point, it's not enough to simply define a new process. You have to change the tool first. You have to build new features into the tool and it becomes a bottleneck to being able to react. So you see what happens here? You notice the transition again. Transition, now we're the servants of the tool, instead of the tool serving us. And it doesn't mean don't build tools. It means build small tools because small tools are more honest about what they do and don't do. And it's really all about, it's really all about leaving room for choices. Choices are super important and not just for processes, but for people. This is a guy by the name of Dr. Martin Seligman. He's considered the father of positive psychology. This is him in the 70s, seems like a nice guy, right? Like a guy you'd like to hang out with maybe, throw a few back. He seems like a guy that would have enjoyed yesterday, especially. He doesn't seem like the kind of guy that would do horrible things to dogs. I want you to zero in on this cute pug here and remember this, because we're gonna talk about some heavy stuff now and it's kind of depressing. So starting in 1965, Dr. Seligman was shocking dogs. He was trying to study the relationship between fear and learning. And the funny thing is, he was actually trying to replicate experiments or at least some findings that Pavlov had found a long time that you're probably familiar with classical conditioning or Pavlovian conditioning. The experiment where a dog was presented food and every time he was presented food, he was also a bell was rung and at some point then you can ring the bell and the dog drools as though food has been presented even though it hasn't. So the thought was, okay, so we're gonna do this and we're going to condition a fear response so that when we play a tone, then the dog will try to avoid something. So they rigged a dog up in a harness, not unlike this one that was used for the drill experiment and they administered a small electric shock to them every time they played a tone. The idea being that when they played the tone, the dog then would eventually try to evade the pain or something like that. And then they put the dogs that had been conditioned in this way into a shuttle box that looked like this. They would play the tone. The intent was that the dog would be able to jump to the non-electrified floor and escape the shock. But what happened was they played the tone and the dog didn't move. They were not expecting this at all. Then they administered an actual shock. The dog didn't move. In fact, the dog just lied down and like I said, this is like sad. So they administered a shock, nothing happened. And they came to figure out that they came up with this theory, learned helplessness. And the idea translates to humans. That is, the dogs didn't know that there was anything to do to get away from the pain. They had the condition that the pain was inevitable and so they didn't try to avoid it because they thought it was futile to do so. Doctors later, Dr. Ellen Langer and Judith Rodin duplicated some of these findings with people in a nursing home. They actually did this, this is a wonderful title. The effects of choice and enhanced personal responsibility for the age, the field experiment in an institutional setting. They were set up in a nursing home where they had two floors. And in one floor they were telling patients, you're responsible for yourself. You have freedom to make your own choices. And they went around with a cart of plants and they let everybody pick a plant if they want one. And they would take care of the plant. And then in the other floor, they emphasized how much the staff was responsible and how we would make the choice for you. And by the way, you all get a plant and we're gonna take care of it for you. And it turns out that in nearly every way that they could measure happiness and healthiness and every sense of well-being, the people that were given some choice over their condition thrived compared to the ones that didn't. And now you might, the funny thing is, this is the thing, it's all about choices, having the choice. And you have to perceive there to be a choice. That dog had a choice to jump over the shelf and to be over in the place where he wouldn't feel pain, but he didn't know it. And people are the same way. And so you might say, if you're a boss, well, everybody's got a choice. If you don't like it, leave. I think that's an absolutely horrible thing. That should be a last resort. If somebody's leaving to get away from you, you've already lost. A lot of people don't even feel they have that power. There's lots of barriers to leaving. There are financial barriers. There are relational barriers. There are emotional barriers. In my case, I had relationships with a lot of my coworkers in this previous job that I was in. And I felt like I was abandoning them to this boss that I knew didn't have their best interests at heart. And it was really upsetting to me. And when I actually left, when I knew I was doing the right thing by leaving my job, I still dreaded calling my CEO. And he predictably, he made me feel like utter crap, like I was letting everyone down on the team. I can't believe you would do this to us. So that's enough depressing stuff. Dogs shocking and learned helplessness and abusive bosses. You might have noticed that last photo was a little familiar if you like Twitter, like me. My favorite Twitter account is PHPCEO. That was the PHPCEO model. But for purposes of this exercise and to cheer us all up a little, I want everybody to suspend disbelief and let's pretend that the model that is used in the PHPCEO avatar is in fact the PHPCEO. Did you know that the PHPCEO likes ice cream? Let's talk photosites. They just never get old. Gift that keeps on giving. He really likes ice cream, seriously. So the funny thing about this is the real shame is software developers have probably some of the least reason to feel helpless. I mean, we can work at any time, anywhere, and in so many different ways. So many ways can work. And if you're a manager right now, you might be saying there's no way I'm gonna let my team work just anywhere, and have all that flexibility. That's hilarious that you think that would happen. But there's a reason that we've been talking about some of these concepts, these empathy and honesty and trust. And it's that they're interrelated. They're a progression. You move from empathy to honesty to trust. And eventually it gets you to a point where you can actually relinquish control and grant autonomy. Autonomy is the goal. And it's not just for us as developers that that's valuable, but a manager, the best managers don't wanna spend all their time managing. They want people that can self-manage to some degree. And so it's ironic then that we hire thought workers and then tell them to shut off their brains. And so let's just for a moment assume that my horrible boss was right and that people are just like objects and it's object-oriented programming, baby. Well, the funny thing about that is that object-oriented programming was never really about objects. It's all about messages. You know that. Everything about your organization is encoded in the communication between the various people in that organization. And processes are and should be reusable messages. The good ones are anyway. They think of it like a compression mechanism. You see the same message a ton of times then you find a way to make the repetition unnecessary, but it's still just a message. It's about increasing the SNR, the signal-to-noise ratio, so that the messages that need to get through can get through. There's room for them. So we're trying to figure out ways to be more efficient in communication and this is why I think that the requiring developers to work on site is a joke. Right now, we have the ability to communicate an incredibly high bandwidth with each other even when we're not in the same room. And honestly, it's much more beneficial for us to know how to choose the right channels to communicate over whether or not we happen to be in the same room. If you're an efficient communicator, you're gonna be that much more helped on the cases when you are in the same room, right? It's silly to try to substitute throughput for efficiency. They can live together and honestly, if we can't communicate, we've got problems because programming is a form of written communication. And if you fail at communication, you might end up with these guys. These are the guys that are omnipresent. They're on that email thread someone started within five minutes of receiving it. They were 13-hour days. They were afraid they're gonna miss something. They're hanging out in chat all the time and they commit code they couldn't get to during the workday at 3 a.m. Maybe they're in some kind of a sleep deprivation study. I'm not really sure. Often they just think that if they're not around, they're gonna miss something and the company's gonna suffer. In any case, the worst ones are the ones that actually just love playing the hero. Side note, apparently, you can turn your head independently of your neck. I'm looking the wrong way in that photo. The point is, they wanna make sure everybody knows that they're working the hardest. These people are organizational morphine. They mean well, but they mask the pain that the company should feel. The fact is, you need to feel pain in order to have change. You need to actually experience the pain. It's fine to deal with something in the short term to eliminate some of the pain, but if you're habitually doing it, then you're preventing the company from learning a lesson or from growing. You're actually doing a disservice to your employer. So, we do thought work. This means we're working when we're thinking. How do you measure that? This guy, he's doing some work, looks like he's thinking. Is this guy doing really hard work? How do we measure thought work? It's an honest question. I don't know. And in creativity research, they actually refer to the three B's. You all have had this before. Bath tub, the bed, the bus. You have an epiphany in the shower, right? Places where you just get an idea because your mind is working on it. You're literally always working if you're thinking. Remind each other of that and watch each other's backs. Maybe encourage somebody to let another part of their brain do some work for a little while. And if you're a leader, lead by example. Try not to communicate off hours because people are gonna assume that they should be doing the same. Try to take a break. Encourage people to. I just went on vacation about a week before I came out here. I didn't even take my laptop. My CTO was awesome. He was like, no, I wish I could make that mandatory for everybody. So, these aren't really engineering specific values, this empathy and honesty and trust and autonomy. These are just things that make people good people. And so I realized that really I need to, as a person who's looking to hire, I need to stop looking for people that I can control. And if you've learned to ask one question through all this, it should be why. And the answer is because that's not how relationships work. That's what I've got. I also have stickers and I would encourage you if you want a humane development sticker to come on up and get a sticker, a free hug or whatever you want. Not whatever you want. I mean hugs. Violating the code of conduct on film.