Two's Complement - Programming Under Pressure

Episode Date: July 21, 2024

Ben and Matt come up with a podcast on the spot, which they do every month but also this month too. Our hosts discuss on-call rotations, fighting (virtual) fires, and working to meet deadlines at the mercy of the world. Ben says the letter 'P' a lot. Matt's brain freezes, but he's OK.

I'm Matt Godbolt. And I'm Ben Rady. And this is Two's Compliment, a programming podcast. Hey, Ben. Hey, Matt. How are you doing, my friend? Just grooving along to our theme song. Yeah, yeah, this is, I think? Just grooving along to our theme song. Yeah, yeah.

This is, I think, depending on which order we put these out, we may have already commented, but we've changed the way we record these now. And as a result, we get to hear the theme music, and it's a lot of fun for us. Otherwise, you know, we don't hear it. It was just a weird two people talking to each other over a Zoom call, which is, I mean, I guess it's not that weird. I got a compliment from our listener the other day that they really dug the theme music so shout out oh that's awesome for me

that's fantastic yeah inverse phase would love to hear good feedback like that um for all your retro music needs you should check his website out um what are we talking about then today i don't think we actually discussed this i just click book record it out of the excitement of knowing that we have this new system so uh i'm i'm gonna put you on the spot and i'm gonna throw out a topic which you're gonna have to talk about for the next 30 to 45 minutes so okay and it is programming under pressure. Or talking, doing a podcast under pressure. Under pressure. Well, all my best work. Well, immediately some things under pressure are easier.

Like for example, if I'm in a restaurant, I'm usually, I will defer choosing what I'm having until everyone else has gone. And the waiter is looking at me, the server is saying, what are you going to have then? And the pressure of like, well, I have to come up with something allows me to get over the hump of making a decision. But I don't think that's a healthy way to do anything. And similarly with programming, right? I think one can navel gaze too much and one can think about it a lot or too much, but having a deadline and just abstractly having a deadline is a good thing. It's a forcing function. So that's good, but it's eminently achievable in say six weeks then that doesn't feel like pressure as much as just like don't don't take three weeks off and do

something else just focus on it but by saying under pressure you imply like considerable pressure well i actually mean sort of all dimensions of this. Oh, okay. So including some variants of the situation that you're talking about, but also we're losing a large amount of money every hour and we need to fix this right away kind of problems as well. Okay. And everything in between, I think, is worth- So let's start with that first one. Yeah. Let's start with the first one. That's fun, right?

So you and I work in trading. You and I have worked on desks where that is literally true that you could be losing money hand over fist or something awful could be going on and you need to diagnose it very, very quickly. And that is very stressful. It's a lot of pressure. You often have somebody, two or three people standing around your desk or at least meaningfully glaring at you while you're trying to deal with probably a very complicated problem. Because if you've done all the things we espouse, tested your code very well and had a great deploy system and all the good stuff that we talk about, then unfortunately, the only kind of issues that are left are the horrible issues that are difficult to find, right? Right. Yes. All of your untested code, that's where the bugs are. Exactly. Exactly. And you'll fail fast if you can't test it. Obviously, it was not soon enough or too late still. All the things that are happening for the very first time in the world ever today.'s right right none of them are good so yeah that is that's a pretty unhealthy situation to be

in and i think there i think there are different types of characters that deal with it so personally i don't mind that as long as it's very very rare and my fault as you like it's inverted commas for like it's something that like okay this is clearly my issue or whatever um i i don't mind doing this if it's like it's the vendor's fault for the 15th time and i'm that's a very different situation but we're not talking about how it feels we're just talking about how how it well i suppose we are that's you just said programming under pressure so it's it's difficult you can make some silly mistakes obviously um if we're talking about programming specifically i don't know that i've ever had to program a fix that i needed to get out like that

day and maybe i have i mean most of the time these things are operational stuff it's like the trading system is down what set of processes am I killing? What processes can I kill? What things do I have to manually go and quickly edit to just make it work, to restart it, to get it up and running again? And that's not really programming, although it is a, you know, a multi-month long, you know, project with, with deadlines and a lot of coordination and other things, or the situation that we're kind of talking about right now, where it's like, no, there's an urgent ongoing operational problem. And only the people who understand the code can fix it or mitigate it in some way. And they're the ones that are, you know, oftentimes I feel like in those situations, the amount of programming that you do is tiny.

It's like triage a problem for 90 hectic minutes and then come out one line in a bash script and restart it, right? And it's like, okay, it's not on fire anymore, right? Yeah. Like that kind of thing. Yeah, that's fair. I think, so we have, we use pager use pager duty. And when you get paged, I speak from experience. Rather unfortunately, last night, I got paged at both, not last night,

night before, just 30 minutes past midnight, and then 3.30. And then my dog woke me up at 4.30. So that was not the best night's sleep ever. And it's very, very, very rare. And so I don't want anyone to think that this is like normal. But there is a form of pressure, And it's very, very, very rare. And so I don't want anyone to think that this is like normal, but you know, there is a form of pressure because it's not so much that I'm under a huge amount of pressure because I wasn't. It's just the fact that it's three 30 in the morning. I want to go back to bed. Right. Right. Um, so I think, and what's been top of mind for me as my team has grown is how do I spread the load around my team so that it's not just me and another person being paged um and really I just think there is no substitute to being that person under pressure I I don't know if you can teach that skill you can make it a little bit easier for people by saying tooling is good here's a playbook but really trying

trying I think it's just a trial by ordeal at the end of the day you just have to be put in that situation and go okay i see i get it now i get it why you matt bangs on about like why the log files are in the really awkward and silly place because they're always hard to find and they're hard to find at the best of times they're even harder to find when you're panicking at three in the morning right right? So those things become important. And obviously Matt should move the damn log files, shouldn't he? But that's a whole other conversation. Yeah.

So yeah, I don't know. Again, so yeah, from a personality point of view, I think I personally, I do quite well in that situation. I think that's something I don't mind. I like the under the pressure problem solving type thing, but I know people who don't. I don't know that I really, I would struggle to say that I like it. I know that I really don't like it when, as you say, it's sort of like someone else's problem that's been inflicted on me.

I really, really hate like getting paged, getting alerts for something that I can't because it's like about loss of control, right? It's like, there's nothing that I can do to fix this. It's just suffering and pain for me for something that I can never really truly take control of and resolve. Right. I tolerate it way, way better when it's like, Oh, I wrote this bug. Yeah. Right. Or I, you know, I could have recently foreseen this and I didn't, or it was a trade-off. It was a risk I took myself and I made, I had agency in that decision and now it's come to bite me and may a Culper. Oh,

fair enough right right right because i'm benefiting from the from taking those risks yes right like i take a risk that means that i can defer some amount of work or i can do some other thing that's going to be more valuable and that benefits me when i when i have these sort of like external exogenous unforeseen you know the electricity is broken kind of risks. Right. Like, that's just very, I don't get anything out of that. It's very unrewarding. It's very frustrating to have lost control over things and just be at the mercy of the world, right? Which

is kind of the human condition, but it's not fun. But, you know, I don't know that I necessarily can say that I enjoy those moments of firefighting. And what I definitely know is that my thinking in those situations is worse. to slow down a lot and also get confirmation from, you know, my colleagues about doing things, or I will, I just think dumber in those situations. You know, I just, I don't, my reading comprehension drops, my reasoning ability drops. Um, it's just bad all around when you, that adrenaline is flowing and you know, you, you're, you're kind of in fight or flight mode. Right. Uh, and I don't think that that's uncommon, but I know that it's true for me.

Right. And so, you know, when you accidentally the database, um, it's, it's really, you gotta be really careful about the steps. I have to be really careful about the steps that I take following those moments because I can't really trust my own thinking anymore. That's a very good observation. Yeah. And I think that's true of most people. Being under pressure means that it's easy to make, well, first of all, you know you need to make some kinds of trade-offs, I think, in order to pragmatically get something done under time pressure. So you might cut corners that you otherwise wouldn't dream of cutting, given the time pressure.

And so there's an area of mistakes you can make, a whole category of mistakes that you can make to do with cutting. Hey, normally we do a pull request, and normally we get someone to review the code, but we don't have time. There's no one else up at this time in the morning. I'm just forced pushing to main and then we're going with it. And you know, like all of the alarm bells should be going off and they should.

They are literally going off. Well, that's true. Yeah. But then, you know, knowing what, which ones are okay to cut. Right. Knowing which one, which corners are okay to cut is, is an important skill. And as you say, you're already kind of impaired because you're maybe panicking or at least concerned a little bit uh about things in a way that makes you like less

um yeah as you say you're just not working on um firing on all as i am now under pressure as i'm trying to make as i'm trying to demonstrate here because um yeah but yeah so maybe then then like some of the safeguards that one can put in place are worth quickly discussing you know like you know we talked about things like pull requests and stuff like that and like maybe you don't allow people to force push uh maybe uh i know that for example our deployment systems that you and i both work on have make it very very very difficult for you to do any kind of on-machine changes, kind of on purpose. It's like, yeah, you can't cut corners here.

You can't just log into the machine and edit everything and then restart it because it's a read-only image. You have to do it properly. We have to have an audit trail. We have to know who did what. And that's probably a good thing to put in practice ahead of the time. But you need to be able to quickly make a patch release or something, have some process. Right.

There's a quote that I – Alan Cooper? There's some quote that has stuck in my brain about this for a very long time, which is, your process is what you do in a crisis. Everything else is kind of like fluff in a way, right? Now, there might be reasons why you have a more involved process for deploying testing software, all these things, you know, when there's not a fire burning, right? But for the most part, the real process of sort of baseline process is what you do when the fires are burning. So as much as possible, trying to bring those things into alignment with the things that you do every day will make it

more likely that when those fires are burning, you're just doing the things that you do every day, right? So an example of this that I have, and I have been a big proponent of is around sort of like integration tests. When you have integration tests that are part of your CI process that depend on external systems, that means when those external systems are experiencing problems, you can't deploy the way that you normally deploy. And you are either doing some other kind of deployment where you're copying code up to the server manually, or commenting out tests, or doing a whole bunch of things that you probably don't want to be doing for the very first time when the fires are burning. And so one of the risks with those styles of integration tests is that you find yourself in that situation. And that's why one of the things that I do in one of the projects that I'm working on right now is we have a stage in our CI pipeline that runs after deployment that runs very specific types of, they're not even, we call them system checks just to have like a different name. But they basically like ping the running system to do things that verify that the points of integration work as expected.

And then they produce a report. So when you do a deployment, if one of those points of integration is not working correctly, that will fail. But it will have happened after the deployment has happened. So it doesn't block you from deploying. So if you have, for example, a situation where the database is down, and the reason the database is down is you brought it down by putting a bug in your code, you can still deploy the fix to your code

to bring the database back up, right? Yeah, yeah. But you'll still get the notification saying that you broke the build. If you do this in a test environment or in a branch environment, your PR will fail saying like, hey, you broke a system check because you changed the way that you interact with some piece of thing. Did you know you did that? But it won't prevent you from deploying. And so I think that's an example of trying to design things that you can bring that, the sort of process is what you do in a crisis. What are the things that you would have to do under the gun? What would be the things that you would bring that, you know, the sort of process is what you do in a crisis. You know, what are the things that you would have to do under the gun? What would be the things that you would have to do very quickly, but also reliably? And how do you make it be so

that that's the thing that you do every day, day after day, time after time, so that when you're doing it in a crisis, it's boring. It's like, yeah, we're doing another deployment. We've done 12,000 deployments on this project so far this is 12 000 and this is no different even though maybe the fires are burning around us and we either way yeah that's an interesting point yeah and as you say it's if it is the the standard way you deploy software then there's no surprises for you nobody needs that uh this is sort of a similar thing but um uh one of the things a trading system may do when it starts up is it may have to go and get a snapshot of what the system of the world looks like. And you need to do that whenever you've lost a connection.

You have to start up during the day. But if you start up early enough in the day, you don't have to do that because there's nothing happening in the market. And it's very easy to write a trading system that works perfectly well when you turn it off at seven in the morning and it works runs all day and then when it fails at like 2 30 in the afternoon and you have to restart it and then suddenly you discover there's a bug in the snapshot code so we had a system which started at seven and then it would restart itself for like 8 15 so that it's like yep every day even though we could avoid this we deliberately make it so that the surprising case the everything's on fire case is actually part of our normal startup and then if

we get any problems with it obviously we get an hour or so to fix it before uh we deploy but it's not surprising then anyway so that's just a similar um example of don't do something unusual at the worst possible time that you haven't tested at the heck of a lot. Right, right, right. You want to limit that as much as you possibly can, right? And I think that when you think about things in this way, you come up with some sort of interesting conclusions and you make some maybe non-obvious trade-offs to say, yeah, you know, it would be cool if we could have like three different ways to do this, but we're not going to do that. We're going to do one way. And it's maybe not ideal for every situation, but if we can use it in every situation and it will be the same in every situation, there's value in doing that, right? There's value in simplifying in that way.

Because, you know, the more variables that you have in these chaotic situations, the more likely it is that you're just going to miss something. Some interaction between two pieces of code or two systems that you just never thought of comes out of the woodwork and surprises you and makes your bad day even worse. Right, right, right. Again, it sort of comes back to the complexity,

an unnecessary complexity, perhaps, they're reducing that by saying like, hey, we don't need three different builds. One will be good enough and we'll have this other system just to make it so anyway that covers i think well i'm sure there's more to say but like that's the i'm under the gun i've got three people staring at me yeah i'm logged into this production system and i'm poking around hoping to god i'm going to find what the actual issue is so that i can fix it properly in code using one of the things that we've just described, one of the approaches. But so then what about medium term? I'm going to call that short term, medium term pressure. The idea that somebody,

maybe your manager is sort of saying to you, hey, we need that thing done by the end of next week. Right, right, right. Is that helpful? Yeah. So I think there's some overlaps between that and probably the sort of long-term pressure thing. But I want to maybe dial in on one specific scenario, which is someone else is waiting on your work. Oh, interesting. I think that's a very common situation for programmers where they feel pressure, maybe rightly so, but they feel pressure and they might feel like they need to cut corners in order to deliver because someone else is

basically blocked on whatever it is that you're waiting to deliver. Right. Right. And so I, I think, you know, that is a very common thing. And I think that talking about effective techniques for dealing with that situation that are beyond just programming. There's programming ways to deal with that situation. But there are, I think, non-programming ways to deal with that situation, which are equally useful and sometimes more useful. I was going to say more so because we're all programmers here. But the other bit, the squishy human bit, is the difficult bit to get our head around. Yeah.

I think it's easy and maybe even sometimes tempting in a sort of like, you know, martyrdom, heroic way of thinking to say, oh, I'll do this. I'll just work late and I'll just crank this out and I'll get this done. And, you know, I would be lying if I said that I have never in my life had a little bit of enjoyment from that process of sort of like, I'm just going to like sprint'll get this done. And you know, I would be lying if I said that I, I have never in my life had a little bit of enjoyment from that process of just going to like sprint to get this done. Like it feels good. It probably isn't great for you mentally to do that all the time. And it's probably not great for your organization to put itself in a situation where like the success of this thing is hinging on one person. And if they screw it up, then bad things are going to happen.

Right. Like that type of heroism, I don't think leads to sustainable types of organizations. Right. No, absolutely not. But you know, setting,

setting that solution to the problem aside for just a moment. Okay. Something that is always worth asking is, am I, is this actually the right problem to be solving? Right? Like, is there a way to do a simpler, more rudimentary version of whatever it is that you're trying to do that will unblock the other person? Maybe even perhaps just temporarily to relieve this pressure. And I think something that I know that I do as a programmer is I have solutions in my mind for how things should be and that other people are going to potentially use or depend on.

And I want to give them the good solution. I want to give them a solution that's, that's like fit for purpose and does all the things and works and is great. But it might be two weeks. And so what I need to do is sort of check my ego a little bit and be like, okay, but couldn't they just get away with a bash script for a day? Or can't you just copy this file manually? Or can't you just do some temporary thing to get that person unblocked right now? And then you can have a leisurely two weeks where you can think about the problem deeply.

And solve it properly. And solve it for real. And remove that pressure so that you can focus a little bit more. That's probably better for everyone involved. Right. I think the place where programmers sometimes get scared is sort of like well what if what if the bash script is good enough well that's i think what if i'm wrong about my solution being so great right it's it's true or or perhaps worse than that i mean obviously

that that's the blow to the ego yeah uh-huh um but then there's the it is good enough barely but it won't scale it doesn't do whatever it doesn't check errors properly it requires someone to keep retrying until it does what all these other sort of side effects but then you move on to something else because something's more pressing and it's kind of it's it's almost you know like if it didn't work at all then you'd have the reason to work on it right if it works perfectly that would be fine but this is the worst bit somewhere in the middle where it works only just good enough for someone to get on but not bad enough for you to actually have to fix it properly and then you know and maybe sometimes that is a right call and that hurts our egos as

you say with the bash script maybe works perfectly but like in my experience what ends up happening is that some set of the your customers just i mean especially in our industry where our customers are uh are internal uh they're like oh i guess this is just how it is they kind of lump it and they and then you know two years later you come back to them and you discover are you still doing that thing with with the bash script well yeah oh god no please oh yeah exactly and they're like oh i thought this was the only way and then you erode the trust between the two so i think you that's a great i love the idea of buying yourself the time to doing it properly provided you do get

the time to do it properly and it isn't then eroded away by either you personally and either here chasing the next shiny because you know like hey i've got a bit of spare time oh i might as well fix the other thing and then forgetting about the original thing right so you're going to be disciplined but also the organization needs to be disciplined and say like okay the reason we've got the thing that's working now well enough for some definition of well enough is because ben is working on the real version that's going to take us three weeks and although you might think you can put him on something else now, no, he is doing that thing. And then we will replace it and everyone will be happier. I promise you three weeks time, everyone will be happier. Person who uses it, Ben will be happier. And then you can get on with the next project. But that does take discipline,

as I say, both personally and organizationally. Yes. Yes. And I want to focus in on discipline and what organizational discipline means specifically in that context for a bit, because I think it not only plays into this scenario that we're talking about right now, but also sort of the longer term scenarios, right? Which is if you are an engineering leader in an organization, you're like a director, you're managing teams of teams, right? And you feel the need to control the priority of those teams. There might be valid reasons to do that. But one of the things you are doing is taking away the ability for the programmers and for the sort of technical leads in your organization to make these decisions that we're talking about right now, right? They are going to be less likely to just give them the 20 line bash script or the open source

tool that sort of kind of does it and then go off and build the right solution asynchronously. If you are going to take control over that prioritization away from them, right? Right. And every time you take that control away from them they will be less and less likely to do something that is in the best interest of the organization and get a good solution out quickly and get the better solution out later and they will be like no no no no i'm not going to deliver anything because that's the only leverage that i have here right the only leverage that i have to sit on it until it's right. And this goes for not only those situations where it's like,

oh, it wouldn't be as scalable. It wouldn't be as ergonomic from a user standpoint, but also reliability. If they know they're the ones that are going to get those pages at three in the morning, if they put out the temporary solution, they're going to be much less likely, just as I was talking about at the start of the podcast, they're going to be much less likely, just as I was talking about at the start of the podcast, they're going to be much less likely to take those risks because then they've lost control, right? If they feel like, okay, I'm going to give you the temporary solution

and I'm going to accept that I might get paged, but I know because I have control over the priority that I'm not going to be working on anything else for the next two weeks. I'm only going to be working on this and I can accept for two weeks that I might get paged in the middle of the night. That's fine. But if I feel like I have no control over my own priorities and I have no agency to be able to say, I'm going to give you this temporary solution and I'm going to replace it. And I'm just not going to do that. Right. I'm gonna be like, Nope, there is no solution. I'm working on one. I'll tell you when it's ready.

Yeah. So I think that when it comes to, you talk about disciplined organizations and discipline in this sense, what to me that means is, is that you're pushing down the decision-making for prioritization to the people who are, have, have their feet kind of like in both worlds, right? They understand all the technology. They understand the trade-offs at a very deep level. They know what risks they're taking on. And they're probably the ones who are ultimately bearing the primary costs of those risks. And they know enough about the broader organization to know like, yeah, we're holding up this other team that's bad. We need to unblock them and here's why. Right. Yeah. That makes, that makes sense to me. Yeah. I, uh, I, my brain is just

frozen. Uh, I mean, my brain has just frozen. So this is what happens under pressure. Um, but yeah, I mean, the reason it's frozen is because I've been thinking about everything you just said applies to exactly what I'm doing in my day job and sometimes i do wonder if you just bring these subjects up because what you're really doing is trying to mentor me and what i my day job i mean you're not denying it you know i i feel like with this podcast i get to i get to share some hard fought wisdom. You know, my, it's possible that the reason for your existence is just to be an example of other people, not what to do. And I have, I have definitely had a lot of these things where I sort of look back and

I go, wow, that was really stupid. Why did I do that? Why did I do that? Oh man. But yeah, I, and I think this, this definitely ties into that sort of long term pressure as well. Right. This, this sort of the same thing. It's a little bit different in that dimension though. Quite often you're going to have, oh, go ahead. I was going to say, so what do you think about when you think about long-term pressure? What

even is long-term pressure? Because long-term pressure sounds like something which is going to give you an early heart attack and add to your general ill health. Right. I think pressure could just be knowing a good direction, having somebody saying, well, I need it by the end of the year. Right. Just to have direction. I haven't seen many organizations that plan more than about a year out, right? Most quarter, I mean, we plan at Aquatic about quarterly, basically. We have yearly goals, but the kind of planning that you and I do is quarterly.

And I think that's pretty typical, right? I'm sure that there are organizations out there in the world that have 10-year plans, and maybe they actually execute on those 10 year plans. And that's amazing. But, you know, most of the things that I see are much more the long term is more short term. Right. The long term is like three to 12 months, let's say. Right. that you're trying to accomplish in that span of time, I feel like you have a lot of future choices

that you're going to make. And it's important as you go through those future choices to be able to make intelligent trade-offs, right? So another situation that I think I have seen before, and I saw this in my consulting work, and's, it's, um, and I've seen it other, I've seen it in my day job too, but it's, it's this sort of dysfunctional, like artificial deadline, right? Where for not really good reasons, other than I don't know how to motivate programmers. So I'm just going to come up with an arbitrary date and tell them that it has to be done by that day. I'm going to invent a day to have a certain amount of work done. And I'm going to tell everyone in the organization that they have to do it by that day.

Right. I think that that leads to a lot of negative behaviors in programmers and in engineering organizations. It leads to a lot of unnecessary complexity because if the goal is like, hey, you're going to get promoted if you can add these 10 pieces of functionality by the end of the year, and then you're going to go and move off onto another project and get your own team, and now you'll be like a team lead instead of just a programmer, then you're creating all the motivation in the world for that person to

just shove as much code into the code base as they possibly can in the next 12 months. So they can deliver on the five pieces of functionality that you want by the end of the year. And then they will never have to worry about it again. Yeah. They're gone. And they're gone. Yeah. Someone else gets to pick up the pieces of their, their mistake. You've, yeah, you've incentivized the wrong behavior. Yes. Yes. So if gets to pick up the pieces of their mistake. You've incentivized the wrong behavior. Yes. Yes. So if you want to add a lot of unnecessary complexity to that code, that's a great way

to do it. The antidote for that, I think, I mean, depending on the structure of your organization, that might actually be like an economically rational thing to do, although that would make me hate my job. But, you know, depending on the structure of your organization, if you want to try to push back on that, one of the things that I use to decent effect, again, in my consulting work, when you have very little power as a consultant, like you have basically no power as a consultant, right? You're just there and you're just like, I'm just

going to say some words and I don't know, is it's sort of the old thing of just ask why. So it's sort of like, okay, this needs to be done at the end of the year. Okay, well, what will be the cost if we don't? Because we need to be able to make, and I'm saying this completely ingenuously. Ingenuously, the opposite of disingenuous. Genuously? Undisingenuously. Undisingenuously, yeah.

Anti, yeah, all right. Antidisingenuously, I'm saying, like, if we don't make that day, what happens? Because I want to be able to make intelligent trade-offs and I want to be able to take intelligent risks and I need to know what the parameters of those are. What is the sensitivity to that day? What are the things that go on with it? Right. Yeah. Not just the absolute, right. Is this a situation where we're going to be cutting a golden master on that day? And if we don't have the functionality it's like there's zero value in doing it after that yeah or is there it's a christmas deadline it's got to get

to the factory and that's the end of it all right or or is it yeah as you say barry just made up a a number because he wanted to come up with a date in which case so i mean i i wanted to say to you know you made this issue like some people motivating whatever i think sometimes having a uh a deadline if only so that other people can plan around it and you can have some dependency chain that makes some level of rational sense you're like well if you don't know when it is let's just pick a day and then let me just tell you and maybe this is where you're going with this that like as long as you're honest that look i just thought it would take about three weeks. So I've told, I'd like to tell the other team

that it will be ready in three to four weeks. Is that okay? And then start from that as a negotiating point or, you know, like, no, no, well, you're like, well, it might be three, it might be four, it might be five. Is that okay? You'll be like, well, that's fine.

I'm sure there'll be fine with a week slippage. But like, that's a very different sense from, no, three weeks is the hard deadline or else you're out. And yeah, yeah, yeah, yeah, exactly. Exactly. And, and, and yes, there is absolutely value and, and you often should, you have a large organization, lots of different teams, lots of different people are trying to coordinate them, you know, herding cats and all that's trying to stuff. You're trying to get everybody moving toward the same goal. It can be very useful and very effective to say, we are going to try to accomplish this thing by this day as a group. Right. Mostly. So I'm giving you folks tools to

say no, right? Like don't do this other thing, right? Just do the thing that we all said we were going to, we were going to agree to do. Right. Again, quarterly planning is exactly that for us. It's like we kind of throw our dice, kind of make a guess at best of where we're going as an organization. And we say, well, what can we reasonably do in three months? And then we say, well, the things that we know we need to do, the things we would like to do, and the things that other people want us to do, we kind of find something and say, okay, in three months time, which of those will be done? We'll set those as our goals. And I like to set them to be actually achievable goals. None of this nonsense like 80 achievement oh god i hate that so much but like no i'd like

to be able to tick off all of those things although if you look at my uh my current set of things it's very sad but let's not go into there i'm learning i'm learning but um and then it becomes a planning it's less of a goal it's less of the pressure it's just like well i committed to it because i thought it was achievable and now i've communicated to the rest of the organization and then the only pressure i'm putting on is my own pressure. It's like, I said that this was okay. And that feels okay. That's in, I was going to say what the opposite of is exogenous was internal. I suppose internal pressure is one thing, but exogenous pressure is harder to bear, but yeah, you buy externalizing it by putting it in a document and letting other people rely on

it. Then you are, what's the word you are inviting external pressure i suppose but maybe that's okay yeah well no i mean you're it's kind of like signing up for a talk that you don't really know how to give yet right never done you know of course never uh like no and i think that that is actually the functional way to sort of the the good way to use this pressure is to say, you know, I've done some analysis and I, you know, have figured out, like, I feel comfortable committing to this thing and me committing to this thing and saying that it's going to be done by this day has value to the rest of the organization because it allows other people to plan, right? It's like, oh yeah, Ben said this was going to be done by the end of the quarter, which

means the quarter after that I can plan on using it, right? And that has a lot of value, right? It's like, oh yeah, Ben said this was going to be done by the end of the quarter, which means the quarter after that, I can plan on using it, right? And that has a lot of value, right? But that has to, I think that has to come from the people who really have skin in the game and they have to be the ones that are sort of shaping and molding exactly what that deliverable, what that thing is, because it is so intertwined with the technology that you can't, you can't really, it's, I think it gets really bad when you try to externalize it. But, but when you do that, you get the, you get sort of like the benefits of everything. Like you get a little bit of that pressure that can help people, you know, like you say, like make the decision in the restaurant. Right. Yeah. Yeah. Um, and, and so you, and, but it's coming

from like a very well-founded place. And I think one of the, one of the, this is an, I'm just talking too much about consulting today. One of the other things that it was like a really obvious thing that I remember a bunch in my consulting work is I would get, and this was like a lot of like agile type shops or people trying to do agile for the first time. And so they would like take all the work that they had done and they had maybe like stories and they put points or what, you know, there's a billion different stupid systems for this. And they would like go and they were like,

okay, well, we've been averaging about, you know, we'll just call them flops. We've been calling, we've been averaging about like 10 flops per week. Right. So we're committed to doing 10 flops of work, uh, next week. And it's like, okay, well, you know, that average is 50%, right? So there's a 50% chance you're going to miss this goal. Is that what you you're committing to a 50% chance of success? That sounds like a bad idea. Yeah, yeah, yeah. Maybe you should figure out what the distribution of that actually was, and maybe plan for, I don't know,'t know 90 success just throw that out there really interesting point yeah yeah yeah yeah that was definitely a what was it velocity yeah flops you said to flops because you don't

want to use any of the words story points and velocity and all this other terrible nonsense i mean it's well meaningmeaning as most of these things are well-meaning but you know humans humans are not uh we don't we don't do well when we measure it in such ways i don't think yeah yeah but but yeah i'm with you there i i do not like the idea of i'm gonna commit to a goal that i know that i realize that some people are actually motivated by that they're like i'm gonna be an olymp runner one day. And they sort of know in the back of their head that they're not going to be an Olympic runner one day, but that wakes them up in the morning at five o'clock and gets them to get out and, you know, run, uh, five miles. It's a lie that

they've told themselves and they're fine with it. Right. And it works right. For science, you say for some people it's a, it absolutely does work. Yeah. If that works for you, great. I am not one of those people you tell me that one day i'm going to play golf on the pga tour and i'm like yeah no what do you know that's not it's not happening no no i can play tiger woods golf on a playstation that i could do that's that's true but i'm not i'm not that's not a realistic goal for me. So I want, I want those 95, 90 and 95% chance achievable goals. Right. Yeah.

I'm down with that. Again, I don't, I don't think I can look at my current goals and rate them very well in that respect, but I learned for next time. And that's what we do. So let me ask another, let me ask a question of you now. What if we didn't have any pressure? What would be the, the the the result of taking away all pressure and just say have at it you know maybe the golden days have got say google where

it's like you know you could sit in a in a room somewhere and just sort of tinker around and stuff with no real goal no real expectation of success you, I mean, so maybe you personally, how do you feel you would do under those situations? I, yeah, I think I actually know how I do, which is I don't finish. I don't, as soon as I, here's what I do in those situations. As soon as I realize that what I'm trying to do can be done. I don't want to do it anymore. It's boring. It's boring. So when I interviewed at Google, it was a good friend of mine who had sort of said, you should come work. Basically, he'd been taking me down the pub for years and we would chat and then he'd say, I'd love to tell you what I'm doing,

but I can't. It's secret at Google. The can i can tell tell you more about this is for you to get a job here and i'm like and eventually i acquiesced i i got the job or whatever um and then a couple of months after i started uh my friend took me to one side and just said oh yeah by the way uh one of the big boss people had asked him like as a final step in the interview like is matt a finisher will he finish things and my friend said yes he will and in the back of my mind i'm thinking god i'm terrible but the fact that that question was asked of my friend and it was so clearly in the mind of of of the boss uh person uh meant that it left a mark on me afterwards like i recount this now what 15 years later like oh my gosh am i a finisher it was clearly really really important to somebody

somewhere that you complete and you know you and i have friends who are amazing idea people but are not finishers they're like start a new project no one ever thought that this project could be done they showed that it can be done and then they kind of dance off in the flowers to do something else you're like wow what did you how do you do this it's amazing but it would be cool if you would like complete it yeah um anyway so coming all the way back i feel exactly the same way is what i would say without um without like an actual somebody saying concretely this needs to be done then that last 10 which takes the remaining 90 of the time and the effort and willpower and grinding and it's thankless and it's no longer solving problems it's just banging it

with a hammer until it bloody well gets into the hole or whatever it takes right that bit doesn't get done if you don't have to and so having a forcing function to get you over the line is really really good yeah so I feel the same way. And speaking as somebody who has an open source project that spends most of its time and doesn't really have to be finished in any way, you can look at how many open issues and open pull requests there are as an idea of how far behind I am on something where I don't have a deadline. There's no deadline.

There's no end either, unfortunately. It's just on for infinity. Mm-hmm, mm-hmm. No, that's a really great question, though. I feel like it's something artists have to experience, too. It's sort of like finishing a work and putting it out in the world

opens you up to criticism. Yep. You know, forces you to, you know, realize the sort of truth of whatever it is that you made. And that can be very uncomfortable, right? It's sort of like, it's much safer to just be like, no, I'm just going to keep this painting in my attic and no one will ever see it. And they'll never say how terrible it will be. Yeah, I'll go fiddle with it. I'm just, I'm not done with it yet, you know? And you're just scared, right? You're scared of, of the, of the criticism of the feedback of the, you know, harsh sunlight hitting this thing that you, uh, that you, you know, feel. I mean, I, I definitely do this where I sort of like,

uh, become way too attached to the things that I build. I think of them as my children and I, um, you know, get upset when they have exceptions and errors and I really want to fix them. And like, you know, if it never goes into production, then you're never going to have any of that. So it's this sort of like, I don't know, this sort of reluctance to sort of face the reality of it. But that's 100% what I do when I don't have any pressure. It's unfinished. Right. Yeah.

And I have to, I i actually i do this with like my personal projects um which you know i'm doing one right now and i do this on my personal projects where i have to wait for the right moment to start telling people about it right because when i start telling people about it i've kind of committed to actually doing it yes it's always awkward you've given yourself yeah up until that point you you can give yourself the uh the out of like well i never really started it i never so i didn't it's not that i didn't finish it it's just i never really started it and then as soon as you say yeah oh i'm making an x i'm like oh how are you doing with your x like oh now now i feel like i'd have to say oh i abandoned it or you say no

no it's done actually right yeah yeah let me show you the pictures or here's the website or whatever it is. Right. Yeah, exactly. Exactly right. No, that's cool. Well, how did I do under pressure, Ben? I think you performed very well under pressure. I did okay in the end. Yes. I can wipe the sweat off my brow now and I can go back and take the pink sombrero off from editing the site. Oh my God, the pink sombrero.

We still have one. I don't know where it is in the office anymore. It was near your desk still have one. I don't know where it is in the office anymore. It was near your desk at one stage. I don't know where it is. Listen, we had for a brief moment in time, we said if you ever have to make a change in production, you have to wear the pink sombrero. It's an actual real big pink sombrero.

And you had to wear it until whatever tactical fix you made had been fully committed into the real repository and then merged and deployed or some, something like this anyway. And I don't recall anyone ever having to wear it, but it was there and it was more the threat of it. We, we have it.

I think there might've been, cause one of the, one of the, it's a, it's kind of a joke, but it actually does serve a useful purposes, which is it's a, it's a lock that you acquire.

Yeah. You don't ever accidentally have two people trying to do the same thing on the same server at the same time because, because you don't ever accidentally have two people trying to do the same thing on the same server at the same time. Because you don't have the sombrero. You don't have the sombrero, so you can't make a change. You can't do it.

And I think that there was maybe a situation where someone was fixing something and we put the sombrero on their desk. That sounds about right. It was sort of like, all right, you just hold on to this and we'll check back with you later. Well, that's the story of the pink sombrero as well

as a bonus extra content for the end of our conversation definitely adds to the pressure yeah we're looking looking like a plumb yeah all right my friend well until next time uh i guess that's it we can i can go relax now i'm no longer under pressure there's no deadline other than editing it and getting this out sometime in the future. Yep. Cool. You've been listening to Two's Compliment, a programming podcast by Ben Rady and Matt Godbold. Find the show transcripts and notes at www.twoscompliment.org contact us on mastodon we are at twos compliment at hackyderm.io

our theme music is by inverse phase find out more at inversephase.com we can make that end somehow. We're still never very good at ending. That's fine.