Programming Under Pressure

Programming Under Pressure

Released Sunday, 21st July 2024
Good episode? Give it some love!
Programming Under Pressure

Programming Under Pressure

Programming Under Pressure

Programming Under Pressure

Sunday, 21st July 2024
Good episode? Give it some love!
Rate Episode

Episode Transcript

Transcripts are displayed as originally observed. Some content, including advertisements may have changed.

Use Ctrl + F to search

0:19

Hey Ben how are you doing my friend. Yeah yeah, this is I think depending on which order we put these out. We may have already commented but we have changed the way we record these now.

0:20

Hey Matt just grooving along to our theme song.

0:34

And as a result we get to hear the theme music and it's a lot of fun for us. Ah, otherwise you know we don't hear it. It was just a weird 2 people talking to each other over a Zoom call which is I mean the guess is not that weird. But.

0:46

I got a compliment from our listener the other day that they really dug the theme music so shout out Inverse Phase for making awesome theme music. Yeah, ah.

0:49

Oh oh, that's awesome. That's fantastic. Yeah inverse face would love to hear good feedback like that. Um, for all your retro ah music needs. You should check his website out. Um.

1:01

Okay.

1:04

But we're talking about then today I don't think we actually discussed this I just clicked book record it and the excitement of knowing that we have this new system.

1:10

Ah, so 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 thirty to 45 minutes so get prepared and it is programming under pressure.

1:16

Ok, ok.

1:29

Ah, or talking ah doing a podcast episode under pressure. Well all my best were but well immediately some things under pressure are easier ah like for example, if I'm in a restaurant I'm usually I will defer at choosing what I'm having.

1:30

Or doing a podcast under pressure or yes.

1:47

Until everyone else has gone then the waiter is looking at me. The server is saying Yeah, what are you going to have then and then the pressure of like well I have to come up with something allows me to like get over the hump of making a decision the otherwise but but I don't think that's a healthy way to to do anything and similarly with programming right? I think one can navelgaze too much.

1:47

Ah.

1:57

Ah ha.

2:02

Yeah, ah.

2:06

And 1 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 that's not necessarily what you said under pressure. So like that is some form of pressure like if I know I've got six weeks to complete something and it's like.

2:23

Ah.

2:25

and and I agree 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.

2:36

Ah.

2:43

Well I actually mean sort of all dimensions of this so including some variance of the situation that you're talking about. But also you know we're losing a large more amount of money every hour and we need to fix this right away kind of problems as well. Um.

2:44

Ok.

2:56

Okay, well so let's start with that first one 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 you could be.

3:00

But and everything in between I think is worth ah, worth talking about? Yeah yeah.

3:14

Ah.

3:16

Ah, something awful. Could be going on and you you need to diagnose it very very quickly and that is very stressful. It's a lot of pressure you often have somebody 2 or 3 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.

3:21

Um, yes.

3:36

If you've done all the things we espouse tested your code very well. Um and had a great deploy system and all the 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? exactly.

3:46

Right? Yes, all of your untested code. That's where the bugs are yes right? right? right? yes.

3:55

Exactly And if you you know you'll fail fast if you can't test it. You know obviously was not soon enough or or too late still. Um, so yeah, that's right and none of them are good.

4:04

All the things that are happening for the very first time in the world ever today right? None of them are good.

4:11

So yeah, that is ah there's a pretty unhealthy situation to be in and I think I think there are different types of characters that deal with it. So personally I don't mind that ah as long as it's very very rare and my fault as yeah, like is inverted comments fault like it's something that like. Okay, this is clearly my issue or whatever. Um I don't mind doing this if it's like it's the vendor's fault for the fifteenth 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 it? What I suppose we are. That's you just said programming under pressure. So it's it's difficult you can make some silly mistakes.

4:33

Then ah.

4:37

Yeah.

4:50

Obviously um, if we talk 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 or maybe I have I mean most of the time these things are operational stuff. It's like the the trading system is down what set of processes am I killing.

5:01

For him.

5:07

What processes can I care 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's very programming adjacent.

5:16

Yeah, yeah, yeah, and I don't just mean programming I mean sort of the whole act of supporting software in any sense under pressure whether it is a you know, ah multi multi-month long you know project with ah 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 or mitigate it in some way and they're the ones that are you know?? Ah oftentimes I feel like in those situations the amount of programming that you do is tiny. It's like.

5:40

Right? right.

5:53

Triage a problem for ninety hectic minutes and then come out out 1 line in a bash script and restart it right? and it's like okay, it's it's not on fire anymore right? like that kind of thing.

6:02

Yep, yeah, that's that's fair I think yeah, the so we have ah we use pager duty and you know when you get paged. It's I mean I I speak from experience rather unfortunately last night I got paged at both not last night night before

6:09

Go ahead.

6:19

Ah, just 30 minutes past midnight and then three thirty and then my dog woke me up at four thirty 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 you know there is a form of pressure because it's not so much that.

6:20

On.

6:27

M.

6:34

I'm under a huge amount of pressure because I wasn't it's just the fact that it's three thirty in the morning I want to go back to bed. Um, so I think and and what 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.

6:37

Right? right.

6:52

Ah.

6:54

Really I just think there is no substitute to being that person under pressure 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 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 3 in the morning right.

7:11

And.

7:20

Sophy. But.

7:25

And right.

7:28

So those things become important and obviously Matt should move the damn log files shouldn't they but you know that's that's a whole other conversation. Um, so yeah I don't I don't know I I again. So yeah, ah from a personality point of view I think i.

7:32

Yeah.

7:45

Personally I do quite well in that situation I think that's ah something I'm I don't mind I like the the under the pressure problem solving type thing but I know people who don't um.

7:55

Um I I I don't know that I really I would struggle to say that I like it. Um. 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 page 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 in pain.

8:11

So.

8:18

Yes, yeah.

8:26

For me for something that I can never really truly take control of and resolve I tolerate it I tolerate it way way better when it's like oh I wrote this bug right? or I you know manage the team. Yes.

8:37

Yeah I could have reasonably foreseen this and I didn't or it was a tradeoff 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 Mayor a culper. Oh fair enough.

8:45

Right? Exactly right? right? right? right? right? because I'm benefiting from that from taking those risks 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.

8:54

Yes.

9:05

When I when I have these sort of like external exogenous unforeseen you know the electricity is broken kind of risks 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.

9:12

Right.

9:24

Kind of the human condition. But it's not fun. Um, but you know I don't know that I that I necessarily can say that I enjoy those moments of firefighting and I deaf what I definitely know is that my thinking in those situations is worse.

9:40

Right? right.

9:42

Like I I have seen in many situations where I have really had 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're you're kind of in fight or flight mode right.

10:14

Right? right? You know it.

10:17

And I don't think that that's uncommon but I know that it's true for me and so you know when you accidentally the database. Um, it's It's really, you got to 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.

10:36

That's ah, that's a very good observation. Yeah, and I think that's true of most people you know like that being under pressure means that it easy to make. Well first of all, you know you need to make some kinds of tradeoffs I think in order to pragmatically get something done under time pressure.

10:48

Havena her.

10:52

So you might cut corners that you otherwise wouldn't dream of court 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 you know hey normally we do a pull request and normally we get someone to review the code but like we don't have time.

11:09

Ah.

11:12

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 well That's true. Um, but then you know knowing what which ones are okay to cut excuse me.

11:15

Um, they are literally going off. Yeah right.

11:30

Knowing which one which corners are okay to cut ah 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 about things in a way that makes you like less. Um, yeah, as you say you're just not working on. Um.

11:38

Ah.

11:49

Yeah.

11:50

Firing on all as I am now under pressure as I'm trying to make ah as I'm trying to demonstrate here because um, 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.

11:55

Yeah.

12:02

Yeah, yeah.

12:08

Maybe maybe you don't allow people to force push. Ah maybe 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 so you can't just log into the machine and edit everything and then restart it because.

12:13

You have.

12:22

Ah, him.

12:27

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 that's that's probably a good thing to put in practice ahead of the the time but you need to be able to ah you need need to be able to quickly.

12:32

Ah.

12:45

Make a patch release or something have some process. But yeah.

12:45

Right? I There's a quote that I Ellen Cooper is this who there's some. There's some quote that I 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.

13:04

Yep.

13:05

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. 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. So an example of this that that I have and and I have been a big proponent of is um.

13:28

Yeah.

13:43

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.

14:11

Ah, you write right.

14:14

1 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 on 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.

15:07

Ah, right? That's interesting. Yeah yeah.

15:10

But you'll still get the notification saying that you broke the build if you do this in ah in a test environment or in a branch environment. You know your Pr 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 right? And so I think that's.

15:26

Got it? yep.

15:30

And example of of trying to design things that you can 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 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 12000 deployments on this project so far. This is 12001 Yes, exactly.

15:59

This is and it is no different even though maybe the fires are burning around us and we otherwise 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 this is sort of a similar thing but um, ah one of the things. Ah, 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 um.

16:21

And.

16:34

It's very easy to write a trading system that works perfectly. Well when you turn it up at 7 in the morning and it works runs all day and then when it fails at like 3 2 30 in the afternoon and you have to restart it then suddenly you discover. There's a bug in the snapshot code so we had a system which started at 7 and then it would restart itself for like 158

16:37

Yeah.

16:48

Ah ha ha.

16:52

So it's like yep every day even though we could avoid this. We deliberately make it so that the surprising case 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 we deploy.

16:52

Ahha.

17:08

Yeah.

17:10

But it's not surprising then anyway, so that's just a similar. Ah um, example of don't do something unusual at the worst possible time that you haven't tested ah at the heck of a lot.

17:17

Right? right? right? right? You you want to limit that as much as you possibly can right? and 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 tradeoffs to say. Yeah, you know it would be cool if we could have like 3 different ways to do this but we're not gonna do that. We're gonna 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. Um.

17:47

Right.

17:52

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 right? Some interaction between 2 pieces of code or 2 systems that you just never thought of comes out of the woodwork and and surprises you and makes your bad day even worse.

17:59

Yep.

18:08

Right? right? right? Is it that ye again as sort of comes back to the complexity, an unnecessary complexity. Perhaps they're reducing that by by saying like hey we don't need 3 different builds. One will be good enough and we'll have this other system just to make it relevant so anyway that covers I think well.

18:14

Manha. Right? right.

18:24

I'm sure there's more to say but like that's the I'm under the gun I've got 3 people staring at me. Um 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.

18:27

Yeah, yeah, yeah.

18:40

Ah.

18:41

So then what about medium term I'm going to call that short term medium term ah pressure. You know the the idea that somebody maybe your manager is is sort of saying to you hey? um you know you we need that thing done by the end of next week is that helpful is.

18:43

Yeah.

18:53

Right? right? right? so yeah so I think there's there's some overlaps between that and probably the sort of long-term pressure thing but I want to maybe dial in on 1 specific scenario which is someone else is waiting on your work.

19:08

Oh interesting. Yeah, very much. Yeah.

19:10

Right? I think 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.

19:27

Right.

19:29

Um, 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. Yes.

19:48

So say more so because we know we're all programmers here but the bit the squishy human bit is the difficult bit to get ahead around.

19:58

Yeah, it's it's I think it's easy and maybe even sometimes tempting in a sort of like um, you know martyrdom Heroic way of thinking to say oh I'll do this I'll just work late and I'll I'll just crank this out and I'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 sort of like I'm 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.

20:18

Yeah.

20:32

Itself in a situation where like the success of this thing is hinging on one person and if they screw it up then ah bad things are going to happen like that type of heroism I don't think leads sustainable types of organizations. Um, but ah.

20:40

Right? No no, absolutely not.

20:51

You know setting setting that solution to the problem aside for just a moment um 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.

20:54

Ah, okay.

21:08

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 ah.

21:13

Yeah.

21:26

That other people are going to potentially use or depend on and I want to give them the good solution right? 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 I it might be two weeks and so.

21:30

Of course.

21:42

What I need to do is sort of like check my ego a little bit and be like okay but like couldn't they just get away with like a bash script for like a day like or like 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 for real and ah remove that pressure. Um, so that you can you can focus a little bit more right? That's probably better for everyone involved.

22:00

And solve it properly right.

22:11

Write.

22:14

I Think the place where programmers sometimes get scared is sort of like well what if what if the bash script is good enough. What if I'm what if I'm wrong about my solution being so great right.

22:22

Well, that's I think it's it's true or or perhaps worse than that I mean obviously that that that's the blow to the ego. Um, but then there's the it is good enough barely.

22:30

A yeah aha.

22:37

But it won't scale. It doesn't do whatever yeah it it doesn't check errors properly it it requires someone to keep retrying until it does. What are 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 to work on it.

22:40

Ah.

22:44

And. Right. Right.

22:56

If it worked 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, ah, maybe sometimes that is a right call and that hurts our egos as you say with the bash script. Maybe what's perfectly but like. My experience what ends up happening is that some set of your customers just I mean especially in our industry where our customers are are internal. Ah, 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.

23:19

Man.

23:25

Right? right.

23:33

Yeah, are you still using the bash gift. Oh God No please? Yes, Ah yeah, yeah, yeah.

23:33

Well yeah, oh yeah, exactly and they're like oh I thought this is the anyway and then you erode the trustss 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.

23:50

Ah.

23:52

Then eroded away by either you personal Anto here chasing the next shiny because you know like hey I've got a bit of spare time or like 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.

23:56

A.

24:11

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.

24:19

Right.

24:25

And then you can get on with the next project. But that does take discipline as I say both personally and organizationally.

24:29

Yes, yes, and I want to I want to focus in on 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 pressure scenarios right? Which is if you are.

24:42

Longer term.

24:48

An engineering leader in an organization. You're like a you know director, you're managing teams of teams and you feel the need to control the priority of those teams. There might be valid reasons to do that. But 1 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 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.

25:16

Um.

25:25

Go off and build the right solution Asynchronously if you are going to take control over that prioritization away from them 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 ah good solution out quickly and get the better solution out later.

25:33

Right.

25:45

And they will be like no 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 is 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.

25:49

Right is to sit on it until it's perfect because this yeah yeah.

26:02

You know, ah ergonomic you know from like a user standpoint but also reliability right? Like if they know they're the ones that are going to get those pages at 3 in the morning if they put out the temporary solution. They're going to meet 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 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 going to be like nope there is no solution. I'm working on 1 I'll tell you when it's ready. So I think that when you 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.

26:58

Yeah, yeah, yeah.

27:15

Have have their feet kind of like in both worlds right? They understand all the technology they understand the tradeoffs 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 cost 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.

27:39

Yeah, that makes that makes sense to me. Yeah I My brain is just frozen. Ah I mean my brain has just frozen So This is what happens under pressure. Um. But yeah I mean I 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.

28:09

You know 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.

28:24

Ah.

28:29

Why did I do that Why did I do that? ah man. But yeah and I think this this definitely ties into that sort of long term um pressure as well, right? This is sort of same thing. It's a little bit different in that dimension though. Um.

28:30

Ah.

28:33

How.

28:43

Um, so I was gonna say so what? What? What do you think about when you think about long-term pressure. What even is long-term pressure because you know longterm pressure sounds like something which is going to give you an early heart attack and and add to your like you know.

28:49

Quite often you you're going to have oh go ahead.

28:54

Yeah.

29:02

General um ill health. But I think you know pressure could just be knowing a good direction having somebody saying like well I need it by the end of the year ah just just to have direction. Maybe.

29:02

Right.

29:09

Right? right? I I haven't seen many organizations that plan more than about a year out right? Most quarter I mean we we plan at aquatic about quarterly basically something we have yearly goals but like you know the the kind of planning that you and I do is.

29:26

This quarterly? yeah.

29:28

More quarterly. Um, and I think that's pretty typical right? like you know so I'm sure that like 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. Um, but you know most of the things that I see are much more the the long term is more shortterm.

29:47

Um, yes, Mr.

29:47

The long term is like 3 to twelve months let's say so if you've got things that you're trying to accomplish in that span of time I feel like you have a lot of choice. 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 tradeoffs so another situation that I think I see I have seen before I saw this in my consulting work and it's it's 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.

30:22

Right? yeah.

30:24

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.

30:37

Ah.

30:44

Um, 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 ah, you know if if the 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 on to 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 codebase. As they possibly can in the next twelve months so they can deliver on the 5 pieces of functionality that you want by the end of the year and then they will never have to worry about it again right? They're gone. Yes.

31:30

Yep, they're gone and they get to go. Yeah, someone else gets to pick up the pieces of their their mistake. You've yeah, you've incentivized the wrong behavior.

31:38

Yes, yes, So if you want to add a lot of unnecessary complexity to that code. That's a great way to do it. Um, the 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. Um. 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 used 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 like I'm just going to say some words and I don't know um is.

32:06

This is.

32:14

It's sort of the 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 what will be the cost if we don't because we need to be able to make and I'm saying this completely ingenuously. What's the opposite of disingenuous. Yes, undisingenuously I am.

32:25

Um, ah ingenuously the opposite of disingenuously genously on disingenous yeah anti Yeah, all right? okay.

32:33

Anti Disingenuously I'm saying like if we don't make that day what happens because I want to be able to make intelligent tradeoffs and I want to be able to take intelligent risks and I need to know what the parameters of those are exactly yes.

32:42

Right? What is the sensitivity to that day. What are the things that go on with it right? Yeah, not just a absolute right.

32:50

Is 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 0 value in doing it after that or is there exactly right right? yes.

32:57

Ah. Yeah Christmas it's a Christmas deadline. It's got to get to the factory and that's the end of it or else or or is it. Yeah as you say Barry just made up a a number because he wanted to to come up with a date and which case so I mean I wanted I wanted to say to. You know you made this. Ah, issue like some people motivating whatever. But I think sometimes having a 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 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.

33:24

Yes.

33:31

Man.

33:35

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 3 to four weeks um is that okay and then start from that as a negotiating point or ah, you know like no no well you're like well it might be 3 it might be 4 might be 5 is that okay, you'll be like well that's fine I'm sure they'll be fine with a weak slippage but like that's a very different sense from no three weeks is the hard deadline or else you're out and yeah.

33:56

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 different people who 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 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 gonna we were gonna agree to do right.

34:18

Right.

34:28

Right? This is again quarterly planning is exactly that for us. It's like we kind of throw our ah dice kind of make a guess of best of where where we're going as an organization and we say well and what 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.

34:33

Yeah.

34:46

And the things that other people want us to do. Um, 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 nonetheless nonsense about like 80% achievement which I think you're probably go but like no I'd like to better tick off all of those things. Although if you look at my. Ah.

34:54

Yes, oh God I hate that so much. Yeah.

35:03

Current set of things. It is very sad but let's not go into their eye 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 what 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 is like I said that this was okay and that feels okay, that's in in.

35:06

Ah, yeah, yeah, yeah.

35:11

Yeah.

35:17

Yes.

35:23

I was going to say what the opposite of is ah exogenous what internal I suppose internal pressure is 1 thing but exogenous pressure is harder to to to bear. But you yeah you buy externalizing it by putting it in a document and letting other people rely on it then you are in um, ah.

35:25

Yeah, yeah, yeah, yeah, yeah, right right.

35:40

What's the word you are inviting external pressure I suppose but and and maybe that's okay.

35:44

Yeah, yeah, well no I mean it's It's kind of like signing up for a talk that you don't really know how to give yet right? you know of course never not once ah 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.

35:51

Never done that Ah, right.

36:01

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.

36:16

Yep.

36:18

Which means the quarter after that I can plan on using it and that has a lot of value 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 what that thing is. Because it is so intertwined with the technology that you can't You can't really 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 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.

36:38

Ah.

36:51

Right? Which again? Yeah yeah.

36:57

Um, and and so yeah and but it's coming from like a very well-founded place and I think one. Ah one of this is an I man I'm just talking too much about consulting today. 1 of the other things that it was like a really obvious thing. Um that I remember a bunch in my consulting work is I would get and this was like a lot of like.

37:15

Right? right.

37:15

Agile type shops or you know 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 yeah, there's a billion different stupid systems for this and they would like go and they like okay well we've been averaging about you know what's call them. Flops. We've been calling. We've been averaging about like ten flobs per week right? So we're committed to doing 10 flobs of work 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.

37:35

Ah, right.

37:50

Ah, right? that seems pretty. Yeah yeah yeah.

37:50

Is that what you you're committing to a 50% chance of success that sounds like a bad idea. Maybe you should figure out what the distribution of that actually was and maybe plan for I don't know 90% success just throw that out there.

38:04

That's a really interesting point. Yeah, yeah, yeah, yeah, that was definitely a what was it velocity. Yeah flobs you said to flobs because you didn't want to use any of the words.

38:09

Yes, you know there's like so dory points and velocity and all this other terrible nonsense that is well-meaning perhaps. But yeah.

38:18

I Mean if well meaninganing as most of these things are well meaninganing. But you know humans humans are not. We don't We don't do well when we measured in such ways I don't think.

38:28

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 I realize that some people are actually motivated by that they're like I'm gonna be an olympic runner one day and they sort of know in the back of their head that they're not gonna 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 ah five miles in the morning before they go to work. Yes, right? And if.

38:49

Um, yeah, and it's a lie that they've told themselves and they're fine with it. But and it works right for size you say for some people it. It's ah it absolutely does work. No.

38:57

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, but what do you? no that's not. It's not happening like I can play Tiger Woods Golf on a playstation that I could do that's.

39:08

No, no, but that's true.

39:15

But I'm not and I'm not that's not a realistic goal for me. So I want I want those ninety five ninety and 95% chance achievable goals right.

39:23

Yeah, yeah, yeah, I'm 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? Um so let me ask another? let me ask a question of of you now? What if we didn't have any pressure.

39:32

Yeah.

39:41

What would be the the result of taking away all pressure and just say have at it. You know, maybe the golden days of got say Google where it's like you know you could sit in ah in a room somewhere and just sort of tinker around on stuff with no real um goal.

39:46

Um, oh gosh that's of yeah yeah.

40:00

No real expectation of success. How would you I mean So maybe you personally how do you feel you would do under those situation.

40:06

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. Yes.

40:25

It's boring. It's boring. Ah I love you so I so when I interviewed at Google it was a good friend of mine and ah, who who had sort of said you should come work. Basically he'd been taking me down the pub. Um, for years and we would chat and then you'd say I'd love to tell you what I'm doing but I can't it's secret at Google should the only way you can I can tell tell you more about this is for you to get a job here and i' like grow a grumble grum grump and eventually I acquies I I got the job or whatever. Um, and then a couple of months after I started. Ah my friend took me to one side and just said oh yeah, by the way. I.

40:46

Everything.

40:59

1 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 at back of my mind I'm thinking god I'm terrible about that. So but the fact that that question was asked of my friend and it was so.

41:07

Ah.

41:16

Clearly in the mind of of ah of the boss ah person ah meant that it left a mark on me afterwards like I recount this now. What fifteen years later like oh my gosh am I a finisher it was clearly really really important to somebody somewhere that you complete and.

41:25

Naha.

41:34

You know you and I have friends who are amazing idea people but are not finishers that 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 like Wow What did you? How do you do this? It's amazing, but it would be cool if you were like complete it. Um.

41:37

My heart raha.

41:47

Um, but.

41:49

Yeah.

41:53

Anyway, so coming all the way back I feel the exactly the same way as what I was seeing without um without like ah an actual somebody saying concretely this needs to be done then that last 10 percent which takes the remaining 90% of the time and effort and willpower and grinding and and it's thankless and it's no longer solving problems. It's just.

41:54

Yeah. Hey.

42:06

Man.

42:12

Banging it with a hammer until it bloody well gets into the hole or whatever it takes 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. So I feel the same way is and and speaking of somebody who has an open source project that that spends most of its time in the doesn't really have to be finished in any way.

42:14

Ha ha.

42:22

Yeah.

42:32

You can look at how many open issues and open pull requests. There are as and it's sort of like idea of how far behind I am on something where I don't have a deadline right? There's there's no deadline. There's no never no end either. Unfortunately, it's just on for infinity. So.

42:47

Now That's a really great question though I feel like it's something the 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 you know? Ah, ah.

42:59

Yep.

43:02

Forces you to ah you know, ah realize the sort of truth of whatever it is that you made and that can be very uncomfortable. 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 of a paint. Yeah I'll go fiddle with it I'm just I'm not done with it yet. You know.

43:17

Just every now and then I'll go. Ah.

43:21

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 ah that you you know feel. Yeah I Definitely do this where I sort of like ah 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 um I want to I Really want to fix them and like you know if never never goes into production then you're never going to have any of that. So um, it's It's this sort of like um I don't know this sort of reluctance to sort of face. The reality of it. But that's.

43:46

Ah.

43:58

Ah, hundred percent what I do when I don't have any pressure right is I don't finish right and I have to I actually I do this with like my personal projects which you know I'm doing 1 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.

43:58

Is don't finish in. Yeah.

44:15

Right? Because when I start telling people about it I've kind of committed to actually doing it because it's always awkward to be like hey. So yeah.

44:19

Yes, you've given yourself yeah up until that point you you can give yourself the ah 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.

44:24

Right? right? right? Yeah yeah.

44:33

And like oh how are you doing with your ex. Ah oh now now I feel like Id have to say oh I abandoned it or he say no no, it's done Actually yeah, it's an interesting. Yeah yeah.

44:39

Right? right? right? Yeah, let me show you the pictures or here's the website or you can download the app or whatever it is right? Yeah, exactly exactly right? Yeah I think you performed very well under pressure. Yes, ah.

44:47

No, that's cool. Well um, how do we? How did I do under pressure Ben I did okay in the end I can wipe the sweat off my brow now and I can go back and take the pink sombrero off from editing the site that that.

44:56

I I Oh my God The things are mirror. Oh I don't know where it is yes.

45:02

We still have well I I don't know where it is in the office anymore we was near your desk at one stage listener. We 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 Sombre road. There's an actual real big pink sombrero and you had to wear it until whatever tactical fix you've made had been.

45:17

Ah.

45:21

Fully committed into the real repository and immersed and deployed or 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.

45:24

Yeah.

45:31

We we have it I think there might have been because one of the one of the it's ah it's kind of a joke but it actually does serve a useful purposes which is it's ah it's a lock that you acquire you don't ever accidentally have 2 people trying to do the same thing on the same server at the same time.

45:39

Yeah, yeah. Because that you have the some error or say you can't shake a change right.

45:46

Um, because you don't have the sombrero so you don't yeah you can't do it and I think that there was maybe a situation where someone was fixing something and we like put the sombrero on their desk. It was sort of like all right, you just hold on to this and we'll check back with you later.

45:56

That sounds about right? Well, that's the story of the pink sorero as well as a bonus extra content for the end of what I yeah will wear it look making looking like a plum.

46:07

Um, definitely adds to the pressure.

46:14

Yeah, yeah, okay.

46:15

All right? My friend well until next time I Guess that's it we can I can go 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 and.

46:25

Um, right? Yep cool.

46:34

We can make that end somehow and we're still never very very good at ending.

46:37

That's fine.

Rate

Join Podchaser to...

  • Rate podcasts and episodes
  • Follow podcasts and creators
  • Create podcast and episode lists
  • & much more

Episode Tags

Do you host or manage this podcast?
Claim and edit this page to your liking.
,

Unlock more with Podchaser Pro

  • Audience Insights
  • Contact Information
  • Demographics
  • Charts
  • Sponsor History
  • and More!
Pro Features