Two's Complement - Are Dirty Hands Right?

Episode Date: November 23, 2024

Matt and Ben preach the gospel of "dirty hands are right," then spend 30 minutes explaining why that's completely wrong unless you're the right person, with the right skills, at the right time, working on the right thing. Also, don't cook chicken with dirty hands.

It's like free as in goldfish. Hey, Ben. Hey, Matt. We should really not be talking over the intro so that I edited it out, should we? We should be more professional about this thing. I don't know. It's better than me singing, I suppose. It can be a good source of

outtakes. That's very true. That's very true. It gives me the cold opens and cold closes and stuff, which is worthwhile. We'll do the cold open at the open. That'll be a new, interesting way to do it. A new, interesting way to actually just launch into one and then go, oh, I suppose we should press the button to make the theme music play now.

I was actually thinking about this the other day. i was thinking about arranging the theme music for uh clarinet uh cello and drums so that me and my kids could play it together and it'll be kind of a cool thing but you know given that they think everything i do is the most terrible thing boring thing to do I don't imagine that that will go through. Anyway, that's not what we're here to talk about today. Although we could. Music is fun. We could talk about anything that we want. We could.

That's the amazing thing about this podcast. No one can stop us. No one can. That's very true. What power we have. What power we have. But you and I already discussed. We went out with friends last night. And on the walk to the bar where we met our friends you suggested this topic and we had a little little pre-game and so i think we should talk about it and yes that topic is about hands

hands uh you've spoken about this is one of your little you know you're fond of aphorisms and little like cute sayings. And do you want to even say? Go on. What is the one that we're talking about? So the one that we're going to talk about today is Dirty Hands Are Right. And this comes from an internet deal. This is before memes, I feel like.

I mean, memes in their cultural, cultural culturally appropriated as opposed to the scientific sort of Richard Dawkins ish memes that yeah okay yes the cult of done so this was like a set of ideas uh invented by I was gonna say a guy I don't know that they're a guy a person named uh brie pettis um and he basically like sat down one day and came up with approximately 10 rules for getting things done and it took him like 25 minutes and he's like i'm just gonna knock this out and there's gonna be already rules and i actually have you can i was gonna say there's say there's a, there's a poster. I know that it's there from having been to your house. There is the Dunn manifesto, right? Is that what it says?

Yes. It's a bit blurry. Um, and the Dunn manifesto is the manifesto of the cult of Dunn. And this was introduced to me by a friend of mine back in, gosh, 2008, something like that. And it has, it's like, it's like the thing that I love about it, it literally was created in like 20 minutes. Right. It's not super well thought out. Right. That's kind of the point. Because it's just now it's about getting things done. It doesn't have to be super well thought out. It just needs to be done. And then you can move on from it thought out. It just needs to be done.

And then you can move on from it and you can learn from it and you can improve it and you can do things with it. But if you don't ever finish it, then you can't do those things or it's harder to do those things. And so you can Google this dear listener. If you want the cult of done, the done manifesto, you will find it. But one of the things in the cult of done is, and I'm going to try to quote this directly from the quote from the cult of done, um, the manifesto people without dirty hands are wrong.

Doing something makes you right. And, uh, that's actually interesting because that's not how you've said it to me before. Yeah. Yeah. I've said it as dirty hands are right.

That's the shorter version of it right but there is there's a subtle difference yeah yes so i wanted because i wanted to talk about this because i had repeated this many times since learning it and i have thought about it and i think my fifth my thinking on this has become more nuanced, perhaps like the original quote, it was more nuanced. And it has shifted a little bit because I think if you want to apply this in an effective and useful way, you need to really understand what it means to have dirty hands. Because being able to kind of walk around and be like dirty hands are right uh is a is a

great way to make a lot of mistakes very quickly if you uh are not careful about sort of wielding the power of dirty hands right so should we just talk about first of all that that simplified version that you spent which is dirty dirty hands are right and like forgive me for simplifying further but what this essentially says is like if somebody's in the middle of doing something and they say we should do it this way and you aren't in the middle of doing it trust them they're probably the right person to be doing it right you know you don't have don't throw stuff in from the peanut gallery just because you might have an opinion. Don't bike shed. Unless you're doing it yourself, you have no horse in this race. Shut up.

Yes. Let them get on with it. Exactly right. And that's how I've taken it to be from all the things. And from that point of view, I understand why it gets things done, because it means that you don't have this constant interruption from other people saying, have you thought about doing this? And you're like, no, I haven't. And I'm not going to. I chose to do it this way and I will therefore get this thing done and then we will move on to something else.

Right. So that makes a lot of sense to me. And obviously, I mean, everyone can think of reasons why this isn't always true, but it is not a bad first approximation to in a startup kind of environment like we have been for a while. Let's just, hey, if you're interested in doing it and you're already doing it, you keep on trucking and we'll trust you to get on with it. Absolutely right. And if your goal is to get things done, this is very effective, right? If your goal is to be SOX2 compliant, this is maybe not the approach you want to use. But if your goal is to get things done, this is very effective, right? And I think that you've distilled the core of it down very well in that summary.

So I think it's actually more interesting. So let's just take that and be like, all right, that's useful. That's a thing. You can do that. That's a good way to think about stuff. The interesting part of this is i think talking about the exceptions when are dirty hands wrong when you're preparing food when you're preparing food is a great example of when dirty hands are wrong you're in the kitchen you

know uh you just took the trash out and you're like, I'm going to cut up this chicken anyway. That's right. Yeah. That's one. Okay. It was a slightly silly way, but it's, it is. Yeah.

And, and you know, like the, you know, socks to compliant thing is definitely like, yeah, you can get things done and then you're not going to be compliant with that. But like, I think the,

the, one of the more important nuances that I have added into this, especially in the last five years, is understanding the distinction between the hands that are currently dirty and that they are building a thing and the hands of the people who will be expected to support that thing. And if those are not the same hands, then that is a situation in which a dirty hands can be wrong. Interesting. So yeah, this reading that back to you, that is, you know, the,

the sort of typical support engineer versus productionization engineer and like say Google, you know, you, you have the, oh gosh, I can't even think what they're called now, but SREs who are supporting it. And at one stage, way back in the time, it was like engineers threw it over the fence and the SREs just had to deal with the fires and they pushed back.

And eventually it was like, no, before you can throw this at me, the SRE has to sign off on it. And, or you also get to go on the pager duty rotation for that thing so that everybody learns and then hopefully one distills a correctness out of that process but but just because hey i'm the guy who wrote it i'm right yeah that doesn't follow when when it's like but i'm also not the person who's going to be woken up at four in the morning when the when the memory leak finally actually crashes the machine right it's like um the the problem with that transition of like i'm gonna build something with dirty hands

and then i'm gonna take my filthy dirty hands and use them to hand this thing to you is uh just a mix of metaphors here this is great i love it it's like it's like free as in goldfish right like you're i've never heard that before is that yours no i got i got that from somewhere i forget free as in goldfish yeah free as in puppy you know exactly yes this is yours now but it comes with massive amount of responsibility right right i've given you this thing and really it's like it's like a curse right yeah like now you are responsible for this and all of my mistakes have become your mistakes which is great for me and terrible for you absolutely awful for you yes um and so i i think like the main way to avoid this organizationally is just don't do that don't let engineers

absolve themselves of their own sins by passing software unsupported off onto other people, right? So I personally think, I'm gonna couch this a little bit more. I was gonna say something else, but I'm gonna couch this a little bit. I'm gonna say, I don't understand how to apply the software engineering techniques that I know and I've been successful with

to that kind of SRE model, right? Where you have software engineers that build software and then they hand it off to SREs and the SREs support them. And because of that, the SREs need to have a lot of oversight over what the software engineers are doing. You can certainly build software that way.

I'm not saying that. I'm just saying, I don't know how to take all of the useful, effective techniques that I have and fit it into that model. Right. Because they all just completely fall over when you're like, yeah, I'm just going to build a thing and then I'm going to hand it off to these people and then I'm going to

go on to my next project and I'm never going to have to worry about it again. Right. Like, so I think one way to avoid this, this, this failure of dirty hands are right and allow dirty hands to be right is to just don't let people do that. Or maybe more realistically, don't structure your organization to do that on purpose. Right. Right. Because I think you're going to suffer if you do that. Or at least you will not be able to get things done in this way. And it's a useful way to get things done.

It is. As I say, it doesn't necessarily, yeah. Perhaps we should talk about the original phrasing in a second, but I can think of another example where dirty hands may be not always right. inexperienced either at that particular task at hand or at software engineering in general it's i mean and i can't help but feel like this is maybe just i'm a grumpy old man who wants to tell say everyone just needs to do these young whippersnappers previously stated this is our podcast and we get to say whatever we want i know i know but it doesn't come without you know repercussions we like to think i like to be thoughtful about these things as you know as you are as well um so i don't want to say anything that's particular but so i'm i'm with that in mind um it is the case that you can have a junior developer or somebody who isn't a software engineer develop something and you look at it as a seasoned engineer or somebody with more domain experience and go wow you've really made that hard on yourself

and at that point those dirty hands they're like well we've just done it this way this is where we are now it's hard to argue that they're right i mean they're right in as much as they've got something done presumably they maybe have and maybe that's how you get out of this. Maybe it's the wiggle words. It's like, well, they're done. V1 is done. And now we need to think about this again as a V2. Yeah, yeah.

Well, maybe. Discuss. What do you think? Right. So I think that point is absolutely correct, is that if you, any time that you put someone in a situation where they're not capable of doing the task that you've given to them, you need to think about how you're going to make it possible for them to succeed, right? So if you want to operate an organization and you want to have this mantra, where is it? We're going to get things done, we're going to say dirty hands are right, then if you're going to give someone a task that they may

not be capable of doing, then you need to find a way to support them that cannot be the thing that we were just talking about where you've got some seasoned engineers like, did you think about this? Have you considered this? Have you bike shedded this yeah and they sort of like do this fly by advice like either at the very end of a pull request that's like already you know you've designed the system and got it like all right and and yeah or or as you say fly by literally someone posts in slack and says hey i finished my thing and then everyone takes a pot shot at it and that's not a good right right so you have to get the seasoned engineers hands equally dirty yes that way you're going yes well and in the right way right because and it depends on what you're trying to do here i think most software engineering

organizations value developing the skills of their engineers not all do but i think the better ones do and so like you can use this as an opportunity to teach those junior engineers, the things that they don't know that make their dirty hands decisions bad. And you have to do it in a way where you're not just inflicting your help on them, right? Like you have to give them a goal. You need to tell them that it's like, this is too much for you, right? This is this game on hard mode. And if I just left you alone, you wouldn't be able to do it right. Not well, like you're smart. Maybe you're going to figure out how to do it, but it's like, you're going to make a lot of mistakes if we just give you no help. So we're going to give you some help and we're going to

structure it in this way. And the particular way that you structure it depends on the person, the organization, and a lot of other factors that we can go into if we're running out of time, but, or if we need to fill time. But the, the key element here is if you just overwhelm somebody with a task that is way too hard for them, they're going to compensate for that in ways that are bad for everybody. And one of those ways is to make a bunch of dirty hand decisions that the organization is going to be very upset that they made. Right, right, right. And this sort of comes to things that you've,

I don't know if we've mentioned on the podcast before, but certainly internally at work, you've given presentations where you've talked about the zone of proximal learning. Is that the right term? Zone of proximal development, yes. Development, right. Which is, you know, just,

it's kind of like the Goldilocks zone of giving something, one, something which they couldn't achieve on their own but with a little bit of help they can achieve and that's the best place to be learning you know just that's the kind of like stretching yourself a little bit without being overwhelmed exactly it gives me a perfect opportunity to use the the word whelm neither over nor under but whelm is just the right amount of... Yes, that's the zone. You want to be whelmed. Whelmed, absolutely. Not overwhelmed, not underwhelmed. You want to be whelmed. That's when you're learning. That's right. So you heard it here first, everyone.

Yeah. So that kind of covers folks who are less experienced and um you know obviously it requires a certain amount of forethought in order to give them a task which is you know stretching and that you have somebody on tap to be equally dirty handed or in the correct way yeah um that doesn't always happen though so this is an example of where you know it's particularly and i'm thinking now in more general terms where folks who are smart and wanted to just get a job done have gone off by themselves and gotten that job done. And then you're stuck with the decisions that they made. And that's another case where dirty hands maybe

aren't right. Folks have gone, well, pragmatically, we needed a solution to store our files. So I made a directory on the network share and I stored 250,000 files in one directory and it works for me. And you're like, fine, just never type LS in that directory or else your computer's hanging for the rest of the day. And you're like, well, maybe we can fix this and whatever. And at that point, it works. Why are you bothering me? Right. Yep. No, that's exactly right that's not a it's not a junior software engineer it might be like a senior analyst who learned a little bit of python just so they can automate some parts of their job and then built this thing and you come along one day and you realize that the operation of the entire company depends on this untested 1000 line python

script where half the code is commented out. I mean, you just reminded me actually of like, maybe I have said this before on the podcast, but like I remember the very first day I interviewed at the finance job that brought me to America. I was speaking with one of the people in their London office and said,

oh, what are you doing? You know, expecting to hear some kind of cool debugging story. So yeah, I'm debugging this spreadsheet. Right. What? Oh yeah, the traders have written things using spreadsheets. They're like, oh my life.

What am I getting myself into? Yep, yep, yep. That is actually sidebar here. When I'm trying to explain to people that are not programmers, why it's so important to reduce complexity in software and why we spend so much time with techniques and tools and just time trying to reduce the complexity of our software. Because, you know, it's like, oh, we can get so many features out, but we need to, you know, refactor, we need to delete some stuff, we need to remove

some things. And they're like, why is this so important? Why are we spending our time on this? I'm like, well, imagine that you had a spreadsheet that was responsible for your entire company. And imagine that there was a whole bunch of stuff in it that you didn't understand, but you were tasked to change it. Our code base is 150,000 lines. Imagine that that spreadsheet was 150,000 lines and not 150,000 lines of data, 150,000 lines of functions. Of formulas that refer to other formulas. Formulas that refer to other formulas. That's what we're dealing with. Yeah. And so if we don't keep it clean so that people understand how to change it,

we'll not be able to change it. Right. So the next time you come to us and you say like, yeah, we need to add this thing. I'm going to be like, well, no, I can't. I literally can't because every time I change this cell, all these other cells break. And we don't understand it. And we don't understand why. Right.

Yeah. Yeah. That's an interesting way of like, yeah. Thinking about the world. Yeah. But to your point about, so you, you have that person that is not a junior engineer eager to learn,

right. That wants to be whelmed. It is a person who's just trying to do their other job, which is not software engineering. And they have, you know, found a way to sort of automate some things. They ask ChatGPT a question and they paste the answer into whatever.py. And so what do you do in that

scenario? I think that is absolutely a case where dirty hands are not right. Right. That's the canonical example of like, it's just like, no. Yep. That interestingly is a facet of another situation in which dirty hands can be wrong. And the hands in question in this case can be someone like us, a very seasoned professional software engineer who's spent a lot of time doing this. And it's when the scenario is flipped, right? Imagine that you have, and there's a few different dimensions of this, but imagine that you have the like, you know, interest rate calculation code, right? And you don't really understand the calculation that's going on here, right? And there's some, you know, analyst or an accountant or somebody who is an expert in

like pricing this thing, right? Maybe not interest rate calculation, but like a pricing algorithm. Yeah, pricing options. It's kind of complicated that it's like, you know. Yeah, yeah. It's just inherently complicated, right? If you go off and you try to build that solution without really involving that other person,

you're almost certainly not going to do it right yeah or you're going to design it in a way where maybe it fits the one particular use case that you thought about but if you if you want to adapt it or you want to use it for something else you're missing the the the context to be able to generalize it in a meaningful way yeah that makes a lot of sense yeah yeah definitely yeah and that has other dimensions too. Like an imagine, you know, a security aspect, right? Or like a privacy aspect or something like that, where it's like, you may be an accomplished software engineer, but if you don't understand like the legal ramifications

of whether or not we obfuscate this field or not that field, or like the, you know, international law around cookie storage, whatever it might be. Yeah, yeah, exactly. Then you can be a very good software engineer and have dirty hands and be very, very wrong. That makes a lot. So really the dirtiness is a function

of a certain amount of responsibility and skill in something. There's a kind of a threshold by which you have to have a certain amount of responsibility and skill in something. There's a kind of a threshold by which you have to have a certain amount of skill and responsibility to be able to sort of claim the dirty hand mantle, be it as a programmer, because all the things we talked up until you brought in the sort of analyst or the security expert have been, well, programmers can have dirty hands,

and if they've got enough seniority or experience, then you're just preventing the bike shedding that could happen when you have four or five other smart people and reasonable ways of doing it. But your analyst isn't necessarily a good programmer. And so his hands or their hands don't necessarily qualify for the the dirtiness in this case but equally we're not saying this is a unique programmer is the thing it's just like if you if this isn't your main gig if you're not expected to be doing this then maybe just maybe you don't count in the dirty hand analogy right there's a sort of implicit thing that says you need to be vaguely competent and skilled and experienced to have this thing but that makes me think so to go back to reading the the original thing because i think there's like we've got like the the the inverse of the the

actual thing is phrased in terms of the inverse of yeah that's right right so maybe maybe that so it's what does it say it says it says people without dirty hands are wrong doing something makes you right so okay if we just take that first half that sort of says if you've got no skin in the game at all then you just can't be right by definition and i think that's probably you know separable in itself it's like you know that stops the peanut gallery that stops the pot shots from other people coming along saying like you know you don't have any experience have you ever written a database before no right then stop telling me how to manage files because i'm i'm doing it right now shush yep um and then the second part again sorry i've got a goldfish memory of aforementioned

goldfish doing something makes you right doing something makes you right now that is that is more contentious yeah that is the condensed version the second sentence is the condensed version which is dirty hands are right doing something makes you right that's interesting but the the first part about it i i think you're absolutely right is that focusing on that first part is probably the more universally true thing, right? Which is if you're not involved with something, shut up. Don't just go and offer your opinion because you feel like you want to offer your opinion, right? If you don't have any skin in the game game if you're not the person who's going to get uh rewarded if it succeeds or yelled at if it fails then maybe and again it's just unsolicited i'm interpreting it

probably in the best light here like is no unsolicited because obviously yeah if somebody comes to oh yeah and says look hey you don't know what I'm doing here, but can I use you as my rubber duck to debug or to bounce ideas off of? Of course, any one of your highly qualified, smart peers might have reasonable opinions about that. And solicited, I think that seems totally reasonable. In fact, almost by being solicited, you are being handed the mantle of dirtiness. You'll be some dirty gloves that you can put on. That's right. Right.

Exactly. Exactly. So I know it seems somewhat to be torturing the phraseology to fit the actual. But I think so. So the original thesis of our discussion as we walked to Monk's Pub last night was when are dirty hands wrong? And I think we've come up with a few examples of that. Yeah, no, it's interesting because, yeah, it is. It's definitely something that we have trotted out over the last few years as being like, you know, Hey, let's just stop, stop bike shedding about it. But I think it's actually a really good

way to think about the importance of building software in teams because, you know, a lot of organizations like to build cross-functional teams, right? Like you'll have a team that's made up of like two or three software engineers and maybe a trader and maybe an analyst and maybe a risk expert, or you'll have people who are like, oh, we have a product UX expert and we have a couple of front-end developers, a couple of backend developers and a security expert, right? And those kinds of cross-functional teams, like if you structure them right and you sort of align them right and you're like, hey, you guys are you're going to build this thing. You're going to build it together. You need to work together.

You need to come to consensus on how you're going to do it. Then you can kind of solve some of those problems of like, you know, the one senior engineer by himself isn't going to know the pricing algorithm. But when you put that person in the same team as someone who has that knowledge and you have a bunch of people working together toward a common goal, then you sort of like collectively have dirty hands. Right. And you collectively have ownership of the outcome. And if it's not going to work, then you're all going to suffer. And if it does work, then you all succeed. Right. Yeah. Yeah. And I feel does work, then you all succeed. Right. Yeah.

Yeah. And I feel like that is a much better model. Now that for sort of organizational staffing, resourcing reasons that could be difficult to achieve, sometimes those individuals might be very limited in their time or just the number of them that you have. And you can't just like put them on every team and then their goals are divided and it gets weird. So you can't always do it. But when you can do it,

I think it solves a lot of the bad things about dirty hands are right, right? Because you get everyone, you get all the capabilities and the skills. You need to solve a problem together and point it in the same direction. And then as long as people aren't jerks to each other, generally magic will happen. That's the same.

Generally magic will happen. Sometimes, sometimes not, but you can achieve that. Whereas if you have a structure that is more like that sre structure yep where it's like no no you're not on the same team right you get to go home at night and you don't right like that kind of stuff um then i think i think that this attitude is can be very dysfunctional right if you think i'm doing this and i'm right it's i don't i don't even know how you do something like that no you as you said this is not something that you have direct experience or your your many i just i don't i don't understand how you could apply these ideas to that like maybe someone out there has done it

maybe they'll tell us maybe they'll tell us maybe yeah who knows yeah um but but i i don't i wouldn't purport to be an expert in how to do that. Well, I think we've pretty much covered the dirtiness of hands. That is, if you've got skin in the game and you have either someone that you can lean on that is part of your team that can help you, or you have the skills yourself, or maybe you are helping someone else, then dirty hands are right holds. I think that makes sense but it is not always the case that just because you're doing a task that that gives you a free free lunch on the uh dirty hands are right uh you can't ride on that one if you if you if it's not your area of expertise or or if you if you're out of your depth doing it that that sort of makes sense and obviously if you're preparing food you should always have clean hands yes

and especially yeah sing the alphabet song while you wash your hands people that's right that's supposed to work that's the most important theme tune you know whatever that's probably about the same length i don't know we i don't think we've ever played it from a one end to the other i tend to use the same little snippet that we we've got right well we're talking a theme tune um given where we are now i'm imagining it's playing over in the edit talking to edit matt uh so i guess on that note we should uh we should call it quits and uh chat next time sounds good you've been listening to two's compliment a programming podcast by ben rady and matt godbold Sounds good. Find out more at inversephase.com. That's the zone.

You want to be whelmed.