Humane Development
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 33 | |
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/30671 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
TwitterMultiplication signMaster-GleichungComputer animation
00:36
Information securityInformation technology consultingCartesian coordinate systemProcess (computing)Moment (mathematics)Dependent and independent variablesFreewareData managementComputer animation
01:13
Process (computing)Dependent and independent variablesSound effectAxiom of choiceCASE <Informatik>NumberMultiplication signPressureCodeObject (grammar)Right angleComputer animationLecture/Conference
03:29
Multiplication signWhiteboardRight angleTask (computing)Real numberKanban <Informatik>SoftwareObject (grammar)CodeSoftware testingSoftware developerWritingMereologyBoss CorporationPredicate (grammar)ArmStress (mechanics)Meeting/Interview
05:22
Boundary value problemInfinityExploit (computer security)Distortion (mathematics)Polarization (waves)Field (computer science)QuicksortComputer animation
06:02
Object (grammar)Pattern languagePredictabilityArithmetic meanRevision controlMeasurementGame controllerMeeting/InterviewComputer animationLecture/Conference
06:57
AbstractionSoftware developerMereologyShape (magazine)Multiplication signComputer animation
07:39
AbstractionSoftwareBuildingComputer animation
08:12
Pattern recognitionBitTerm (mathematics)Direction (geometry)Revision controlArithmetic meanMaxima and minimaSoftware developerCompass (drafting)System callComputer animation
09:31
BitPresentation of a groupTerm (mathematics)Projective planeWebsiteData managementIdentity managementLattice (order)Self-organizationInteractive televisionDivisorProcess modelingSoftwareRight angleMultiplication signMereologyWell-formed formulaOperator (mathematics)Software developerProfil (magazine)Electronic mailing listComputer animationLecture/Conference
12:51
Data dictionaryResultantMedical imagingException handlingHand fanRight angleArithmetic meanTurtle graphicsComputer-assisted translationMultiplication signLattice (order)WordProcess modelingComputer animation
13:59
FacebookProcess modelingPlanningSoftware developerMultiplication signPoint (geometry)Arithmetic meanComputer animation
14:35
Point (geometry)Right angleTrailVelocityMultiplication signData recoveryFrequencyLetterpress printingAnalogyBit rateCountingAbstractionVideo gameDivisorOrder (biology)IterationWebsiteEstimatorMobile appAddress spaceBasis <Mathematik>Line (geometry)Data miningStatement (computer science)Instance (computer science)SoftwareQuicksortForcing (mathematics)Communications protocolDirectory serviceSystem administratorTraffic reportingMereologyMetreReal numberImplementationDigital photographySummierbarkeitChannel capacityLevel (video gaming)Inheritance (object-oriented programming)Software testingArmStapeldateiBlock (periodic table)CASE <Informatik>Task (computing)Recursion2 (number)Natural numberResultantEmailLie groupIn-System-ProgrammierungGoodness of fitMeeting/InterviewComputer animation
23:53
ImplementationMultiplication signProcess modelingObject (grammar)CodeGame controllerDataflowOpen sourceSoftware developerPoint (geometry)Error messageException handlingProjective planeEvent horizonSoftware testingSoftwareResultantTest-driven developmentRight angleOrder (biology)BuildingProduct (business)Context awarenessSoftware frameworkDecision theoryPosition operatorAxiom of choiceQuicksortMetaprogrammierungSource codeRule of inferenceDevice driverCoefficient of determinationSelectivity (electronic)Digital photographyStatement (computer science)Asynchronous Transfer ModeGreatest elementWeb pageModal logicDiagramAxiomElectronic program guideMereologyINTEGRALOnline helpAddress spaceTerm (mathematics)Focus (optics)Self-organizationGroup actionData miningAnalogyGodComputer animationLecture/Conference
31:41
Classical physicsCoefficient of determinationAxiom of choiceCondition numberEmailPoint (geometry)Arithmetic progressionGame controllerWebsiteThread (computing)Data managementSoftware developerCodePower (physics)Observational studyBoss CorporationDependent and independent variablesMoment (mathematics)Message passingDegree (graph theory)Vapor barrierRule of inferenceProcess (computing)CASE <Informatik>Self-organizationProcess modelingTelecommunicationDigital photography1 (number)Acoustic shadowData compressionTwitterBookmark (World Wide Web)DeterminantMechanism designTheoryMassCuboidModal logicMultiplication signTranslation (relic)Hydraulic jumpRight angleEscape characterSound effectSubstitute goodSet (mathematics)Field (computer science)Computer programmingDecision tree learningStaff (military)Object (grammar)Object-oriented programmingPlanningBand matrixForm (programming)MeasurementAvatar (2009 film)Meeting/Interview
39:04
Point (geometry)1 (number)Disk read-and-write headCASE <Informatik>Digital photographyTerm (mathematics)Order (biology)Bus (computing)Software developerAuditory maskingMorphingLatent heatLaptopGoodness of fitMereologyControl flowThermal conductivityCodeService (economics)MathematicsOntologyTask (computing)BitComputer animationLecture/Conference
Transcript: English(auto-generated)
00:00
I'm on Twitter at Ernie Miller. You probably shouldn't follow me, unless this is my most popular tweet.
00:25
I'll let you read that. So if you like things like that, go ahead and follow me. I work for a company called Invisium. We're an application security consultancy.
00:40
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
01:00
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 you know, that's not a particularly proud moment for me to say, you know, it's not my fault, is how I fell back on, as far as how I felt about things. But you know, there it is.
01:21
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 gonna do it. How many of you, you're 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.
01:41
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 wanna just do that for the rest of the, that's cool too. Okay, so I think, you know, when we leave jobs,
02:02
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. Is 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,
02:21
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 wanna stick around, conversely, what makes me wanna leave? And so it's time for a story,
02:41
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 gonna matter. So I was brought on to lead a team of technical folks reporting to a CEO. This is a CEO.
03:02
I was concerned I was just gonna end up managing people and not get a lot of time to write code, and I was gonna 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.
03:22
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,
03:43
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.
04:02
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.
04:23
He sent me on my way, but 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.
04:41
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.
05:02
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,
05:20
employees were overwhelmed, and so we were, again, overworked. We're trying to hire. We couldn't hold on to 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,
05:42
but the polarity was inverted, and so it was just affecting him. I was miserable, and I've always been sort of maybe a little more sensitive to this kind of stuff. I've been doing volunteer counseling for about six years now, but even before my volunteer counseling work,
06:02
you know, 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 know, you might think
06:20
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, you know, 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.
06:41
It values things like measurability, and it sees control as the means to those first two, and I completely understand this, right? 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, you know, and companies want things to be neat and organized, and again, it's understandable,
07:02
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,
07:20
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, applied to the problem. You know, we need X resources to times, you know, three hours per resource to make this thing happen, and if you ever thought about that, really,
07:43
corporations abstract humans as resources when the only corporeal thing about a corporation is the humans, that's kinda messed up, and so the thing that I landed on, kind of the underlying philosophy that I wanted to guide the team that I was gonna build
08:00
and any team that I would wanna 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. Really deep, right? It's really deep stuff. Now, I don't pretend to say this is some, you know, mind-blowing revelation.
08:21
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.
08:40
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,
09:02
or at least the way that we do it today. How many of you all do agile today? Like really do agile? Like you're so agile that it hurts? So there's this talk, Uncle Bob gave this talk,
09:21
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.
09:41
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.
10:03
He says he believed that Ward 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.
10:20
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, is Kent Beck actually here?
10:41
If I misquote him, this is gonna 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,
11:02
Ken 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.
11:22
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,
11:41
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
12:00
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 is as organizations began to embrace this idea, this agile methodology,
12:21
they took these things that had been on the left, and it gradually shifted back to the right again. You see what happens. It's like an embrace and extinguish, right? 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 connotes speed,
12:41
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
13:01
comes before hustle is in the dictionary. Okay. Yeah, it doesn't really say much, right? 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 okay.
13:20
But if you look at what hustle really is, right? And people are gonna argue with me about this, and I know this. There are linguists that'll say, well, the words, they change meanings all the time, right? 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,
13:41
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,
14:01
move fast and break things. You all know where move fast and break things came from, right? Facebook, no. Tornadoes. Tornadoes have the motto, move fast and break things. It's a stupid, it's a really stupid motto.
14:20
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?
14:41
All right. To track velocity, because we're sprinting, right? We're sprinting. And sprinting's a perfect analogy because we do a sprint and then we take a recovery period to rest, right? We take some time to kinda recover from that sprint. The weekend, maybe? People say the weekend counts. Now, I'm not much of a sprinter.
15:02
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
15:22
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 Tabata-ing, possibly,
15:41
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 gonna 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,
16:03
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.
16:21
You're not gonna finish the race at all, and there's a very good chance you're not gonna 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 gonna be able to sustain. If all we're looking at is the very next finish line
16:42
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 is only gonna be the next, this is the last 70-hour work week I'm gonna do. But you need to be able to operate at a sustainable pace. How can you plan a sustainable pace if you don't know the destination? So all of this tracks onto one thing, which is estimates.
17:03
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.
17:20
I've shoveled the drive countless times. I think I know how long it's gonna take me. I think it's gonna take me about an hour to shovel this drive. I'm relying on estimates from the weather person who says when the storm is gonna stop. So I think to myself, I'm gonna 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,
17:41
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 two and a 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,
18:00
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 okay because it works out, because we lie to ourself about estimates,
18:22
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 okay because most urgent things aren't really urgent. And this is why it's really important. It's really important to ask why.
18:42
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 to question why. We don't have time. But we all probably have stories of some apps or features that we've written
19:02
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, right? We can't waste time. In this case, the site is down. Well, sure, it's urgent. So you ask why, but why is it urgent?
19:22
The bad answer is, well, because it's down. That doesn't tell us anything. The good answer is to say, well, while it's down, 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.
19:41
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,
20:04
I worked as a sysadmin at an ISP. And this ISP, we don't have, I mean, maybe 20,000 customers or 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 this story.
20:22
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.
20:42
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, yeah, so that's my embarrassing story. Point is, is if I had approached this with a little more of a sense of what was at stake,
21:00
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,
21:21
why do we need a feature by March 20th? And instead of getting an answer, well, we need this other feature by April 20th. 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 gonna get it in very short order. It's really important to kind of combat this
21:43
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.
22:02
We're the tech elite, and the stupid business people, they don't understand, right? 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,
22:22
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,
22:42
they need to know what we're giving up. They need to know that maybe we're gonna make some technical debt along the path to this as well that we're gonna 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
23:01
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 wanna say.
23:22
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 gonna be a lot more likely to say, well, because of thus and such reason if we have empathy for the people that are doing the asking. And if we get attached to setting arbitrary deadlines,
23:43
is it really any surprise that oftentimes we end up with implementations that wreak 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,
24:03
to the timeline, than to actually build the right thing the right way. And so eventually, your business is gonna 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,
24:20
which is to engage crunch mode. Right? We cram all the necessary amount of work into the shorter amount of time. It's 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,
24:41
you might say, well, that looks like you're using exceptions as flow control. We're rescuing our timeout error 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 it an exception.
25:00
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.
25:20
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
25:41
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?
26:02
I kind of 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 can 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
26:22
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,
26:41
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
27:01
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.
27:20
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.
27:41
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
28:00
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.
28:21
That's why I would encourage you to do what I'm calling process metaprogramming. And I kinda had a hard time coming up with a way to sort of illustrate this. And a friend of mine, Glen Vanderburg, volunteered a really great analogy for this. So when Glen was learning to drive,
28:41
his dad brought home one of these driver handbooks. And he sat it in front of him. It's like 100 pages or something, all these rules and 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
29:01
in the bottom that you can't read. It says, please note that this roundabout diagram is 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. Glen's dad had a really great solution for this,
29:21
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. So 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.
29:41
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
30:01
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 Scrumbon Agile Tracker and click the Agile tab. And that's where you do this stuff.
30:21
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?
30:40
You notice the transition again. Transition, now we're the servants of the tool instead of the tool serving us. That 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 leaving room for choices.
31:01
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.
31:20
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 kinda depressing. So starting in 1965, Dr. Seligman was shocking dogs.
31:42
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 ago. 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,
32:01
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.
32:21
So they rigged a dog up in a harness, not unlike this one that was used for the drool 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.
32:43
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.
33:00
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.
33:22
They had been conditioned 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 Roden, duplicated some of these findings with people in a nursing home. They actually did this, this is a wonderful title,
33:41
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 know, 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.
34:00
And 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.
34:22
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.
34:41
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
35:01
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.
35:22
So that's enough depressing stuff. Dog's 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.
35:41
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?
36:00
Stock photo sites, they just never get all, 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,
36:23
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, 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.
36:42
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
37:01
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
37:21
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.
37:40
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 if 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 requiring developers
38:01
to work on site is a joke. Right now, we have the ability to communicate in 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.
38:21
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,
38:40
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 worked 13-hour days. They were afraid they were 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,
39:02
they're gonna miss something. 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.
39:21
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.
39:41
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.
40:00
In creativity research, they actually refer to the three Bs. You all have had this before, the bathtub, the bed, the bus. You have an epiphany in the shower, 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
40:21
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
40:41
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.
41:00
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.
41:22
Violating the code of conduct on film.