What A Lot Of Things: Tech talk from a human perspective

In this episode, Ian and Ash embark on a meandering journey through the digital wilderness, pondering the merits of a smartphone-free childhood and the peculiar world of software code review and pull requests. From nostalgic ramblings about bakelite phones to imagining a world of smart telegrams, our intrepid hosts navigate the treacherous waters of modern parenting and software development practices. Expect tangential detours, impromptu time travel, and a healthy dose of silliness as they attempt to make sense of it all - or at least have a good laugh trying.

Links
Email us at TechnologyEeyores@whatalotofthings.com

Creators & Guests

Host
Ash Winter
Tester and international speaker, loves to talk about testability. Along with a number of other community minded souls, one of the co-organisers of the Leeds Testing Atelier. Also co-author of the Team Guide to Software Testability.
Host
Ian Smith
Happiest when making stuff or making people laugh. Tech, and Design Thinking. Works as a fractional CTO, Innovation leader and occasionally an AI or web developer through my company, craftscale. I'm a FRSA.

What is What A Lot Of Things: Tech talk from a human perspective?

Ash and Ian talk about interesting Things from the tech industry that are on their minds.

Ash:

Think you've got an announcement to make.

Ian:

What what announcement have I got to make, Ash?

Ash:

You're going on holiday.

Ian:

I am going on holiday, or I've just come back from holiday. Don't ask me how it was though. Yeah. Because this podcast isn't a time machine.

Ash:

No. How will it be?

Ian:

How will it be? Oh, it will be awesome. I will be doing the things.

Ash:

Where will you go?

Ian:

I will remind myself and let you know when we record the next episode.

Ash:

That was one of the strangest announcements. Even if the podcast was a time machine, that announcement made no sense. I'm

Ian:

quite used to coming on here and saying things that make no sense.

Ash:

Okay. No further announcements.

Ian:

So, yes, I am going on holiday, but by the time you hear this, I'll have come back. So it's a bit confusing. It's a the temporal distortion field of recording podcast episodes before they come out.

Ash:

Yeah. Yeah. Are you ready for some things?

Ian:

Maybe. Maybe. Maybe.

Ash:

Based on our extremely complex fairness calculations, based on the previous episode of the person who went first

Ian:

But do you think we need to weight these calculations by the length of the discussion about each then?

Ash:

Where what it depends where the discussion length is a positive weighting or a negative weighting.

Ian:

Well, now I feel like, if a thing had a lot of time devoted to it, then that must mean that that person whose thing it was got more benefit.

Ash:

Are you saying that

Ian:

No. I'm not talking about the benefit to the world. What kind of fairness algorithm do you think do you think we're entertaining here?

Ash:

You sidetracked me slightly with that. I've got a lot of comments.

Ian:

Yes.

Ash:

So total amount of time and the order in which the things

Ian:

We'll build were talked about

Ash:

in the previous episode.

Ian:

We'll build a database and an API. Yeah. And, I I can do this really quickly. It'll just says return. Ian can go first.

Ian:

Right. There's no need to do any calculation.

Ash:

So in the interest of fairness, I'm gonna go first.

Ian:

Yes. I think, in both broad and narrow terms, you should go first.

Ash:

Okay. So my thing this time is the smartphone free childhood that I never had. No. I did have.

Ian:

How you're not that young, Ash.

Ash:

No. I definitely had a smartphone free childhood. I had a phone free childhood.

Ian:

Yes. Yes. No. I didn't have a phone free childhood because we had one on in our lounge. Yeah.

Ian:

Yeah. And it was made of bakelite and, had a very loud ring.

Ash:

Yeah. And it had a very clucky Yeah. Yeah.

Ian:

It had a dial, and my parents had one in their room. And if you dialed numbers on the 1 in the room, it the one downstairs dinged quietly for each so if you dialed a 9, you'd get 9 dings Yeah. Downstairs.

Ash:

Yeah. And you could if you had 2 in the house, you could pick up the phone.

Ian:

And both talk at the same time.

Ash:

Both talk. It was amazing when you think about it, wasn't it? I was a kid. I was like I was like, this is amazing.

Ian:

We have various family funny stories from my childhood of, of things with phones, like, sitting, listening to it, dinging, and then one of my brothers running downstairs and saying, I wasn't just ringing up. So

Ash:

You were ringing someone else up. Yeah. So it's not that kind of phone free childhood. No. Because a more modern take.

Ian:

Because the word phone I mean, if you if we hadn't had telephones 50 years ago and a 100 years ago, what would we call the things that we have now? Would we still call them telephones? Because telephones is Greek, isn't it? It's like, tele for far away.

Ash:

Yeah. Right. Okay.

Ian:

Yeah. Phone meaning sound or something like that. So it's it's far away sound, isn't it? So would we still call it that? Because talking on it is almost the Mhmm.

Ian:

The last refuge of scoundrels.

Ash:

Almost. Maybe if we'd stuck with the telegram, we'd all be walking around with smarts, grams.

Ian:

Basically, fax machines.

Ash:

And they just have a constant ticker tape of the things that are happening on our phones coming out, and everyone would just be walking around with really long, strips of paper coming out of

Ian:

their pockets. Yeah. You'd be sitting you'd be sitting in a, in a in a party. You'd be standing in a party, talk talking to people, and suddenly everyone's pockets would start sprouting reams of paper, and you'd be like, oh, they've called the general election.

Ash:

It's like, oh, I I I text you an hour ago. It's like, hang on. I'll just go back through.

Ian:

Yes. Yes. I I feel as though, we've missed out on something because we've had telephones in between telegrams and what we have now.

Ash:

So this isn't about having a tele a smart telegram free childhood because we've all had that Yes. And we will continue to have a smart, telegram free childhood.

Ian:

Yes. So it means we don't have to say stop in between each sentence.

Ash:

Yeah. Exactly. Oh, well, that's quite fun, isn't it?

Ian:

Yes. Stop. Send send help. Stop. Go now.

Ian:

Stop.

Ash:

Stop. Stop. So circling back around to a smartphone free childhood. So did you know that apparently, no?

Ian:

Crying midloud.

Ash:

I think we we might be on course to beat the record for a thing in trial length for an unblemished 5th time in a row or whatever it is.

Ian:

And now and now you've said that, we won't be able to edit it out. We could start this thing with you saying we're on course for a record for the world's longest thing intro length.

Ash:

There's no way we're editing all this out.

Ian:

No. It's it's gold. This is what people listen to us for, is to hear about ticker tape, mobile telegrams.

Ash:

The smart the smart telegram. Alright. So before before we dissolved into puddles of laughter, I was gonna say that apparently, 91% of 11 year olds have a smartphone.

Ian:

What happened to the other 9 no. Sorry.

Ash:

Well, you see, that's an interesting question, isn't it?

Ian:

Remaining percentage.

Ash:

Yeah. Well, apparently, they might be made up of a small but growing number of agitators or at least a very small subset of very loud people that say that this is very bad, and children are missing out on their childhood. So we shouldn't give out smartphones to anyone who's under 16 because of various effects.

Ian:

So They might learn how to deal with them.

Ash:

Yeah. Yeah. So apparently, it's bad for your, attention span. My attention span has got things to say about that, to be honest.

Ian:

Sorry. What were we talking about?

Ash:

Exactly. And, apparently, there's bad things on the Internet, which, children of a certain age should not be able to access.

Ian:

Okay. But we have to separate some of these things out from each other because bad things on the Internet is is a quite different problem to solve than than

Ash:

Yeah. So there's a there's a website called smartphone free childhood dotco.uk, which celebrates a move growing movement, or at least they say it's a growing movement, which, ironically, they use WhatsApp to organize themselves, which, you know, I I understand, I I mostly understand irony, but, apparently, it has a bunch of these bad effects on children. As in they're addictive, they correlate to mental health problems, they expose children to harmful content, and they reduce attention spans.

Ian:

So the comedian, is it Jimmy Jimmy Carr? Mhmm. Is that have I got his name right?

Ash:

Yeah. Yes. Yep.

Ian:

He's quite forthright Yeah. Gentle gentleman.

Ash:

He always starts everything with, this is going to end my career, but here's the joke.

Ian:

Yeah. Yeah. Something like that. Well, he I saw a clip of him recently in which he said something along the lines of, I love my children. So what what do they want?

Ian:

They want McDonald's and playing video games all day. Yeah. That's a recipe for fat, stupid adults. And do I want that? So and then he talks about how he wants to love their potential

Ash:

Okay.

Ian:

Rather than loving them by giving them what they necessarily want now.

Ash:

Yeah.

Ian:

Which I suppose is another take on on that.

Ash:

Yeah. Yeah. The thing

Ian:

is, it's what again, it's one of those it's nuanced, isn't it? And people would like us to think it's simple.

Ash:

Yeah. Yeah. I think, yeah, the the the the smartphone free childhood movement, if you like, does try to distill it down into, you know, something simple and doesn't mention all the other, I say, McDonald's, video games, and all the other ways that all the other things that kids and indeed adults want, but are not necessarily yeah. Exactly.

Ian:

It's like it's like living in the air of steam around here sometimes. These people chuffing along the the pavement blowing enormous clouds.

Ash:

Yeah. Yeah. Yeah. Absolutely.

Ian:

Not all most a lot of them are under 16.

Ash:

Yeah. Yeah. So I'm always like we seem to want kids to have, like, other hobbies and then, like, simultaneously sell off all the playing fields and fill the world with sports utility vehicles, which are not involved in sports ever or utility. They're just vehicles. So rendering like the outside sphere very difficult to navigate.

Ash:

So I I I can't help but think that this is double standards on the part of a bunch of adults in a lot of ways, because we all disappear into our screens for a long, long time. We all get that terrifying notification every Monday saying how much your screen time increased in the previous week.

Ian:

Is this because you've got a new phone that

Ash:

you've got? Yeah. Yeah. It tells me things that I'm like, don't tell me that.

Ian:

I try not to look in my Apple screen time app. But, yes, I think as adults, we don't model that behaviour very well. A lot of well, maybe I mean, obviously, some people do Yep. And some people don't. I find this quite interesting because my my son, George, who's, to be fair, 19

Ash:

Mhmm.

Ian:

But he's he's very opinionated about this. He's very down on his smartphone.

Ash:

Okay.

Ian:

And for a while, he took up having a, a dumb phone.

Ash:

Did he get the Nokia 3310 out again?

Ian:

I'm not sure. I can't remember exactly what it was, but I it drove me nuts because, I wanted to talk to him in our family, imessages group. Right. And he wouldn't he didn't get the messages, and I wanted

Ash:

to just plain snake or something.

Ian:

Yeah. Well, yeah. I mean, probably not even the thing was that he he he opted him out of a lot of things that actually were quite useful. And, you know, he's, working towards he he's sort of building a, he's trying to build a business and and become an entrepreneur. And it's quite hard if you divorce yourself from a lot of the ways that people can get in touch with you.

Ian:

Yeah. And there is a a terrible thing that happens when you are constantly being notified and distracted about communications. Yeah. But there's something that's also quite bad when you are divorced from them and you don't notice them.

Ash:

Yeah. Because some are useful.

Ian:

Yes. A lot

Ash:

of it is noise, but some are useful

Ian:

Indeed.

Ash:

Even for even if you are probably, like, even if you are a teenager or in your becoming a teenager years. So, you know, not having a smartphone might put you at a bit of a disadvantage to to find some useful things.

Ian:

I I think that's that's true, and also accessing some kinds of information and help. Yeah. But, I mean, the thing is, it is addictive. There's no question that the behaviors I mean, there's many things that are addictive. So sugar is addictive, nicotine, alcohol, all these things that we know are addictive, that is not a physical substance that you ingest, but it is still addictive, and it generates the same behaviors, the same dopamine.

Ash:

Yeah. Yeah. Absolutely. Absolutely.

Ian:

And, you know, I wouldn't yeah. I mean, we give kids sweets, don't we? We give them

Ash:

Yeah. Yeah.

Ian:

It it is a I guess what I'm feeling now at this point in the my train of thought about it is that are we going to avoid giving children addictive things Because that seems like a a good idea. Yeah. Or are we just going to pick on one addictive thing and ignore all the others?

Ash:

Yeah. It appears to be so I think that when when we had a conservative government, they were quite keen on banning them entirely in schools' smartphones. I think I think schools do discourage them anyway, but it does seem to be like a one of those lovely populist sort of topics where you can, you know, you can come up with a good policy and get people on board, and give a and give a good message that you care about the future of children. But there's a kind of flip side to that as well, because most of life's important services are online now. Yeah.

Ash:

And there's, there's groups of people who can't access them because they don't know what to do with technology. They don't know how to use phones, and they don't know, you know, how to use the Internet well and email. A lot of older people don't still don't have those skills. So it's like, how do you build those skills safely in order to make sure that people can access, all the facilities and important services that they need, like, for mental health and things like that that are all online now.

Ian:

And there's the nuance.

Ash:

Yeah. Yeah. Yeah. Absolutely. The boring answer is probably moderation, isn't it?

Ian:

Yes. Yeah. That's moderate smartphone use rather than moderated smartphone use.

Ash:

Yeah. Yeah. Well yeah. Exact well

Ian:

Probably both.

Ash:

Yeah. Yeah. Yeah. Absolutely. Absolutely.

Ian:

It's interesting to see the things that get put into and not put into things like Apple's screen time, which you can use to to moderate your Yeah. Children's phones. You can lock them up so that they can't you can you can do things like, okay, you can go on Instagram, but only for 15 minutes a day. Yeah. You can, you can never use this, or or during these times, everything is unavailable apart from that.

Ian:

You there's a lot of sort of ways you can sort of tune that.

Ash:

Yeah. So the but I guess the smartphone free childhood is like a it's the simplification of of that. I I don't I don't wish to engage with all of that. I just want it not to be a problem. And also, I think there's some nostalgia there as well, where it's like my childhood was this.

Ash:

Therefore

Ian:

And the only thing that's changed since then Yeah. Is the introduction of smartphones.

Ash:

Yeah. Exactly. So, yeah, it's it's just kind of this gross oversimplification of decades' worth of change.

Ian:

But people love that.

Ash:

Yeah. Yeah. Yeah. Absolutely. Absolutely.

Ian:

Always, probably said this before on this podcast, but I always remember the yes minister episode where sir Humphrey, who's a civil servant, is addressing, another civil servant and explaining the realities of life to him by saying, all the British people want to know is who are the goodies and who are the baddies? And then he goes on to say, but, unfortunately, sometimes we have to do deals with the baddies or work with them in for something, and sometimes we have to not help the goodies when they're in trouble. Yeah. And, you know, the idea is the British people must never know. But it's this is good and this is bad, but nothing's purely good or purely bad.

Ash:

Yeah. Yeah. There was another interesting article on a kind of, on a related note. It was in, it was in The Guardian about kids and video games, and why do kids need to disappear into video games. And it basically said, we've created a terrible world for them.

Ash:

So their desire for distraction and disappearing into digital worlds is now getting stronger and stronger because the actual world doesn't feel like it was geared towards them.

Ian:

But I don't don't think that's any different from me. When I was a kid, I read the Lord of the Rings. Yeah. And I disappeared into that for hours, and it was a book. Yeah.

Ian:

And, you know, the these peep the the same people are probably, who are saying video games are terrible, probably wouldn't say that same thing about books. Yeah. But actually, a good video game is all about telling a story that you get to participate in. So in that way, it's more compelling and immersive perhaps

Ash:

Yeah. Yeah.

Ian:

Than a book was. But it's still the same thing of, I mean, I I didn't enjoy being a teenager whatsoever. I really hated it, and being able to disappear into the lord of the rings or other books that I read

Ash:

Yeah.

Ian:

Was my escapism.

Ash:

Yeah. But did you refuse to come out of it?

Ian:

Well, I used to read I I I got in trouble in my primary school Yeah. For they had desks with little drawers immediately under them, and I

Ash:

Oh, yeah.

Ian:

Put a book in the drawer and just read it Yeah. Rather than play part in the lesson. And I used to read when I was meant to be in bed asleep. So in that sense,

Ash:

yeah. Yeah. Yeah. I always used to get comments when I was young that I read too much, and I was like, I I don't I don't know if it was a problem. I don't know what the expectation was with how much I should read, how much I should play video games, how much I should use my smartphone.

Ash:

But again, that's the we kind of circle around to it again, don't we? It's like, what is the expectation for using these all these different mediums of consuming information. So, does it really change over the years, I guess, is, like, is what is what you're alluding to, isn't it? And there's there's, like, a degree of escapism, and the escapism has just changed. And we just, you know and there's always a movement against it, always people who say, oh, there's too much of this or too much of that, but it's just the medium that's changed.

Ian:

Yes. I think that's true. But we also come back to in shitification, don't we? Yeah. Because the the the problem with, with your phone and the things that are on it that are addictive is that there are basically attention in those things attention in those things.

Ian:

And everyone I know at some point or other has gone on Instagram and wasted an hour and a half

Ash:

Yeah.

Ian:

Just mindlessly scrolling. And these things are designed, literally designed to be addictive, to give dopamine Yeah. Hit in such a way that it it really, it keeps you in Yeah. Keeps you locked in. Yeah.

Ian:

And I think that wasn't true of the things we had in our Mhmm. Childhood.

Ash:

Yeah. I

Ian:

mean, sweets. I mean, sugar is addictive. They're probably, you know, the the things like that. But

Ash:

Okay. So you've got, like, this this sort of I guess it again, it's it's back into the nuance, isn't it? So you've got the actual smartphone itself is It's like the delivery mechanism in itself. It's it's not, you know, there's nothing wrong with a a feed of images of people. You know?

Ian:

That you know.

Ash:

Yeah. Exactly. Nothing inherently wrong with that. But then how it's all been designed within the applications that deliver those feeds It's designed to give you the the maximum dopamine hit and keep you scrolling up Yeah. For as long as as humanly possible.

Ash:

So there's this so the smartphones themselves, they're just, they're just like a gateway into a a set of applications, which are designed very, very specifically for addiction. Yeah. And to make sure that they keep your focus and, you know, they you they sort of keep you, viewing their content and their advertisements.

Ian:

Yeah. Absolutely. It seems to me that if you're a parent and you want to do the best thing for your child Mhmm. Then you do want to stop them from it would be nice if they could leave their childhood not addicted to anything.

Ash:

Yeah.

Ian:

And so as a good parent, you feel like, oh, I want to do these things. You know, I want to moderate their smartphone use or or in some cases, apparently, ban ban them. Although my experience is that when things are banned, they normally find a way around it. Yeah. But,

Ash:

you know Especially alluring for for younger people as well when you ban things.

Ian:

Yeah. Yeah.

Ash:

Suddenly, it just seems to make you want to do it even more.

Ian:

It does. And there's always gonna be a a spectrum of attitude. So whenever they're going to school, some people are gonna have these things. Some of their friends will have them, others might might not. So, actually, it's really hard being a parent.

Ian:

Mhmm. And one of the things that happens is that you've got as an adult, you've got a limited store of energy to to do stuff with. Yeah. And if if one of the things you have to do is spend hours fighting with your kids about are they allowed this and are they allowed that Mhmm. And can you please lift this restriction so they can do that thing, it's pretty tiring Yeah.

Ian:

On top of the fact that we're all working longer hours for arguably less money in a lot of cases. Yeah. These things have a very great benefit for the parents in the sense that they they may be storing up pain for their child in the future in some Yeah. In some sort of way. But actually, they have to live through the present, the parents.

Ian:

Yeah. And sometimes with, you know, the level of stress and time and work that they they are dealing with already, it's kind of asking them to to do this on top of that is a very big task. I mean, is it realistic even?

Ash:

Yeah. Yeah. Absolutely. I think it's it's probably just been added to the list of things that fall into that particular category, isn't it?

Ian:

Yeah. I mean Does

Ash:

it need to be moderated?

Ian:

I mean, if you're going on a long journey, do you want, are we there yet? Are we there yet? I I want this. Give me that. Or do you want blissful silence while they play Pokemon Go or something?

Ian:

I I Yeah. It's that version of the decision is quite different

Ash:

Yeah.

Ian:

Than, than than this. Anyway, the I suppose the answer is it's nuanced, like everything.

Ash:

Yeah. Yeah. And I feel like campaigns like this are just sort of an oversimplification of the world and a desire to replicate a childhood that maybe you didn't even have. The nostalgia pushes us down that that route as well. So I don't know.

Ash:

I'm always wary of calls to ban, veto, things that are an integral sort of part of of life that, a lot of important social interactions and functions that you need to access are present on these you know, on via your smartphone. So it's it's about coming up with a, like, a sensible, moderate approach to to using these devices, which I don't think, as adults, we particularly do particularly well. No. So I'm like, well, maybe we could model the right behavior, ourselves before going back trying to deny children access to the things that we absolutely take for granted. Yeah.

Ash:

So that was my thing, the smartphone free childhood and the oversimplification of a complicated world.

Ian:

Yes. I think, I think that's a really it's a really great one. And I think parents wrestle with this all time, these kinds of demands. Yeah. And, you know, I think we should cut parents some slack because it's bloody hard.

Ian:

Mhmm.

Ash:

Okay.

Ian:

Well, have we got any interludey things to talk? Oh, talk about Elkie Live?

Ash:

Yeah.

Ian:

That might be quite interesting. That should've been an announcement.

Ash:

You kind of destroyed the announcements with your, wibbly wobbly, timey wimey holiday. I'll tell you where I'm going when I get back.

Ian:

You know? No. It wasn't I'll tell you where I'm going when I get back. It's it's I'm trying to position myself after I get back and say I've forgotten, but next episode, I'll be able to remember.

Ash:

So I'll kill you live.

Ian:

I'll kill you live. Yes. So this is a sort of interim interim interlude

Ash:

mini episode.

Ian:

Yep. So Ilfley Live is a music festival that's taking place this weekend in Ilfley, and, it's very good. And I did the website for it because I'm a nerd.

Ash:

So this is at venues and in people's gardens.

Ian:

All around the town.

Ash:

All around the town.

Ian:

And it's free, and it has currently, like, 93 performances in it.

Ash:

Amazing.

Ian:

Which was 10 times more than the first one 4 years ago.

Ash:

Yep. And what's your favourite feature of the website, Ian?

Ian:

My favourite? Well, my least favorite feature is the alleged caching that's meant to be happening of API calls. Oh, well. I've got a bit of a bill for that.

Ash:

You know, cache invalidation, naming things. Yes. Very difficult.

Ian:

Yes. That could be a thing, couldn't it?

Ash:

Definitely.

Ian:

Naming things, especially. So my favorite feature of the website is, is that you can pick from the programme what you want to go and see. And because there's 93 things or whatever, there's a lot of program, but you can go through it and choose the things you want to see, and then it then you can go in this nice, my program page where you get a nice summary of all the things you're going to do and tells you how long it takes to walk between things using the Google Maps distance matrix API. And then if you tap on the little pictures of the maps, you get a, a nice Google Maps or Apple Maps directions on your phone that help you walk there. So very pleased with that feature.

Ash:

Mhmm. Just need to encourage the people to use it now, Dylan.

Ian:

We do. Yes. So I think by waiting till after the festival to release a podcast episode to tell people to do that, they will, they will be very happy that they

Ash:

Set yourself a reminder for next year.

Ian:

Yes. Yes. Yes. Indeed. So but yeah.

Ian:

So I'm I'm excited about being I love being involved in Health and Live, and, I'm very excited about it. And the fact that I'm going on holiday for the second on the second day of it, so missing half of it Yeah. Is, is a bit of a shame. But, no, it's not because I'm looking forward to going on holiday in the past.

Ash:

Which is your present. So, Ian, soon as we we we fairly attributed the first thing in this episode to me, then I believe it's only right that you should follow-up with the second thing.

Ian:

Yeah. But I think the priority of this thing should be raised because of the 6 hours we spent talking about the first one.

Ash:

6 hours? Has it been 6 hours already?

Ian:

Yeah. Yeah.

Ash:

Yeah. Okay. Fair enough. Well, we'll we'll do a sec.

Ian:

Myself a 1000000 times not to exaggerate.

Ash:

So, Ian, please introduce your thing.

Ian:

Shut up and introduce your thing. Yes. So, my thing's a little on the the nerdy side, but unusually specific for me. So my thing is pull requests.

Ash:

Mhmm.

Ian:

I think it's probably useful to quickly explain what that is.

Ash:

Okay.

Ian:

In fact, I'm gonna try and get you to explain what that is because I feel like I I'm not completely sure I've got a complete grip on it. Have you have you used it much?

Ash:

I've used it extensively.

Ian:

Good. Then you've used it more than me. So

Ash:

Lots and lots of software development teams use Gitflow, I believe, the name of the the particular technique where you will have a mainline branch, thankfully now called main, generally, not master. Got rid of all that that parlance, thankfully. And then say if you want to build a new feature, you will then take the current mainline branch and create a new branch off that one and start to make your changes. So you'll change the files that you need to change, add the ones that you need, delete the ones that you don't, and then you'll commit the changes on that branch. And then you will create something called a pull request, which shows you all the changes that have been made in the the the target branch, which is your mainline branch, whatever.

Ash:

And then tools like GitHub will give you a lovely, interface to view all the changes. Well, it's relative. I'm so used to looking at it that well, it's probably it must be one of GitHub's, like, most used features, one would imagine Yeah. Visually, at least. So then you can you can look at all the changes that have been made, and you can compare them to the mainline branch visually.

Ian:

And the way that is used is that as a developer, you or most commonly used, I should say Yep. Is as a developer, you do all your work. So let's say you're you're implementing a personal programme feature for the ILC Live website.

Ash:

Yes. Let's

Ian:

see what I did there. You might do all the work of that, and then you would raise a pull request with and that would have all the changes you'd made in order to do that. Yep. And the idea is that someone looks at the the content of the pull request to see if you're doing anything crazy or you've misunderstood something or it doesn't work in the way they they think you

Ash:

should the standards you've agreed or or whatever it is.

Ian:

And then when only when they approve that does it then get merged into the mainline branch, which means it appears in the live version of the application. Yep. So that's a that's a pull request, and it's been that feature has been around for a long time, hasn't it? Yep. And I think it was invented because of open source projects, where someone would be the maintainer of an open source Yeah.

Ian:

Package, and somebody else would like to contribute to that package, that somebody else might make a new branch, as Asha's described, make all their changes, and then they would ask the maintainer of the package to review their changes and approve it being incorporated into the pack into the the main application. And I think that context has really set it up for the the people who think that pull requests are a terrible thing. Yeah. And we'll get on to that in in a second. But but it's kind of that environment is where untrusted sources are making changes to your application, and you need to make sure that then with varying levels of, of assurance, given past discussions we've had on this podcast with varying levels of assurance.

Ian:

But if you don't if that developer is untrusted, then you need to check before you can accept their Yeah. Code. And that's the context of pull requests were for open source projects. Mhmm. And, there's a chap called Alan Hollub who attracted my attention to this kind of thing where he he wrote tweet back in 2021 where he says, I think PRs, and he means pull requests, obviously, not public relations people, are a really bad idea, and the really has, like, surrounded by underscores to indicate the emphasis.

Ian:

They make sense in an isolated individual open source model, which we just talked about, but are an anti pattern in most business development context where collaboration, e g mobbing, another definition we're gonna have to provide in a second, is possible. So code reviews aren't needed. PRs just add dependencies, delays, and bottlenecks. So he's basically saying that in that open source environment

Ash:

Yeah.

Ian:

Is fine, where you've got untrusted blah blah blah. Mhmm. But in businesses where you've got people who you're paying and you you're really guarding against errors rather than Yeah. Malfeasance.

Ash:

So you've got a team that is ostensibly working together to deliver the changes, the the changes that are needed.

Ian:

Yes. So

Ash:

to have this extra process seems it adds delay and dwell time into how you deliver, and you should be working together closely on this code anyway. Right?

Ian:

Well, you would think.

Ash:

So why do you need to do that?

Ian:

So he's talking about mobbing and pair programming. Yeah. So pair programming is where instead of having 1 developer working on something, 2 developers sit at the same computer and work on it. Yeah. And you have a driver and a navigator model, don't you?

Ian:

So the driver writes the code, and the navigator notices the things that, the driver might not notice. So they talk and between them produce the code Yep. Which Alan Hollub might say is a better way of reviewing code, review it at the time it's being created rather than having a delay and then reviewing it.

Ash:

Fair.

Ian:

And mobbing. So what what do we think what's mobbing?

Ash:

So I guess mobbing would be it's usually the entire team working on the same thing, and you have a similar sort of driver and navigator, but you rotate that through the team. And other team members might be doing research on libraries that you're talking about using or, you know, doing a review of the user story or or whatever it is, but while you're working on it, asking questions of product people. You basically have all the activities that you would usually have on a feature or story or however it is you split it up, but you're you're doing them together, and you're rotating who's actually, you know, writing the code. But in general, you've got, everyone has a laptop or whatever it is, but you've got the code up on a big screen, and one person cannot work it.

Ian:

Person is working on it. So it's like a pair programming, but it's one to n rather than one to 1.

Ash:

Yeah. Yeah. Yeah. Absolutely. Then the theory is is that, obviously, you just work on one thing altogether until it's done rather than going splitting off and working on multiple things, which is often where the need for pull requests pops up, isn't it?

Ash:

Because everyone's gone off to work on their thing, so you end up with a with a with a A lot of things? Breach. Yeah. Yeah. Well, yeah, pretty much.

Ash:

Pretty much. I mean, for some people, mobbing and pair programming is quite scary depending on, like, your previous work habits, you know, your personality type, how much time you you're comfortable spending with others. So I think often obviously, in a in these in a in a tweet context, it's a very short statement to say, well, you know, where collaboration, e g, mobbing is possible. And, of course, it is, but I think there's probably, like, a path to go on to get to those points where you can all comfortably sit together as a team and mob for a significant period of time because it's it's pretty, like, high high concentration, high focus activity. You know?

Ash:

Personally, when I've done pairing and mopping, by the end of the day, I'm absolutely exhausted. Mhmm. And I'm a person who probably needs, like, some time to go off and think about problems in my own space as well.

Ian:

So pairing and mobbing, maybe some people would quite struggle with?

Ash:

Yeah. I think so. I think it's like a it's like a it's something you would need to to to practice, be aware of, like, how much of it you can handle as an individual on a given day. So I said, whenever I've done it in the past, I've been absolutely exhausted.

Ian:

It's a it's a funny one, isn't it? So he's basically the things that that he's really down on about pull requests is the the length of time in between Yeah. I've finished the code, and then you're waiting for someone to review it. Yeah. And the person who's reviewing it has to contact switch into that activity.

Ian:

And then it's likely that when they give you that review back, you have to contact

Ash:

switch Yeah.

Ian:

Into remembering what you had done. And you might find that, actually, there's a lot of contact switching involved in in doing that, which is a bit of a killer. I mean, I think people who are writing code like to be given an an uninterrupted periods of focus to do it in, not having to keep changing. I mean, the big one is also, I keep having to go to meetings instead of writing code. Yeah.

Ian:

But, actually, I keep having to switch back to code I wrote 3 and a half hours ago or yesterday in order to to enact these comments that somebody's made who themselves have to stop doing what they were doing in order to to do it. He's basically saying that's a very poor way. That that really saps your velocity.

Ash:

Yeah. I mean, speaking as a as a tester because testing and reviewing a pull request have some similar problems as in they're done usually after the person who wrote the code has sort of finished it, tied it up, and put it into a presentable state, which they're happy to put in front of other people. So you you're asking them to context switch back for testing as well as well as, like, reviewing a pull request. I think within it, there's, like, there's problems within pull requests, as in they're too large. I've seen plenty of 100 file PRs, which, are very difficult to review and test because there's just too much.

Ash:

There's no way that a person's brain the the the pull request process completely breaks down because if if you've changed a 100 or 200 files, it's like, you've changed the whole system. Yeah. Yeah. So don't worry about a pull request too much.

Ian:

So that way the review comment is looks fine to me.

Ash:

Yeah. Yeah. Pretty much. Pretty much. So you got, like, the size of the pull request, and then sometimes based off that, like, how long they are open for, because then other things change around them, and then they need to be updated.

Ash:

Yeah. So it's like an it's like a having like a long running branch, long running pull request is a is a problem there as well.

Ian:

Because the branch begins as a copy of whatever the current state of the main code is. Yeah. And if if you, make a branch and you make a lot of changes, say for a week, and then other people have been changing that main branch over the course of that week, the chances that your changes are gonna conflict with theirs Yeah. Grows and grows, doesn't it?

Ash:

Yeah. Yeah. Absolutely. So I don't know. I think PRs in general I think it's it's always important to separate the idea of a PR from seeing them done

Ian:

The way people actually use it in practice.

Ash:

Yeah. Yeah. Absolutely. Absolutely. Because I think there's there's there's kind of skills and behaviors issues as well.

Ash:

So, if something if you feel like you can't split something down or you don't see the value in splitting something down to make it easier to review or easier to test, then there's you've got like a there's there's like a training and knowledge issue there, I think, because it's actually really valuable to make them as small as you can while still, obviously, delivering a meaningful chunk of chunk of code because it allows you to sort of progress to the next the next stage of it. So I think whether PRs are bad, I just think that most of the time, they're probably done quite badly, and it's because there's, like, skills and behavior issues where it's just like, I've seen plenty of devs who are like, oh, well, I know it's a 200 file PR, but there's no other way to get the job done. So here you go. As a tester, you're like, well, thanks very much. And then you would then have to, like, almost reverse engineer the PR to pick out all the things that need to be tested.

Ian:

And, actually, what you would have wanted was for the developer to done one of the things Yeah. And then done a PR for that Yeah. And then done one of the things after that and done a PR for that so that you're involved all the way through rather than having some massive thing at the end.

Ash:

Yeah. Yeah. Because there's also the the concept of rejecting PRs as well, which is part of the PR process. So I guess one of the other challenges with with poll requests as well is that it's quite, it can become it's somewhat personal. So if you raise a PR and someone comes back with loads of comments or requests changes on GitHub, there's, like, a button where you can say, I want to request changes to this, then it cannot be merged until those that person has, you know, their changes made, or they take the request changes status off it, which is really interesting.

Ash:

It's like a it is about power as well. So, but one place that works, you needed 2 approvers. But it was never about, like, how good your code was or how, you know, how valuable it was. It was about the people who could get to approval got their pull requests merged. So as long as you were, like, if you were influential enough to get approvals, then your pull request would get merged.

Ash:

If you had less friends, you know, and you didn't go for lunch with everybody, you've had problems getting your PRs met. So there's I guess that's probably, like, here. I think Alan talks about, like, the the sort of a lot about the the technical part of it, but there's it's deeper than that. It's a very, like, team dynamic y thing, in order to get your your your pull requests merged.

Ian:

So we can't say pull requests are bad. We can just say teams' practises can be.

Ash:

Yeah. I think so. I mean, if you had a constant flow of small pull requests with a limited number of changes in them, which built towards a, you know, a wider feature, which were easy to review, easy to test, and then could be merged,

Ian:

Regularly.

Ash:

Regularly with, you know, a few minutes or hours of of them being read, then I don't see between that and, say, trunk based development where you make your changes directly onto the onto the mainline branch behind feature toggles. So I don't see, like, there's a huge difference there. Not huge in terms of time. It's just in terms of how the practice is being used. It's being used to store up change.

Ash:

It's being used to do 2 big changes. It's being used as a as, you know and then those people who can't get the approvals that they need because they don't have the soft skills that they need. Yeah. There's just so much in there that makes me think, are PRs pull requests? Are they so are they so bad, or is it all the stuff that, like, pulls underneath it?

Ian:

Yeah. Perhaps we're aiming out guns at the wrong thing.

Ash:

Yeah. Yeah. I think so. I think so. I think it's like an anti pattern which probably hides multiple anti patterns underneath it.

Ian:

Yes. I mean, he says here, it's a problem even if you wait only for a few hours. I've never seen a PR process where the review happened within seconds of the commit and happened verbally rather than by written comment.

Ash:

Yeah. So but again, that's the team thing, isn't it?

Ian:

Yeah. And if you did that Yeah. If you did it differently, so it was very quick. Yeah. Then I think the so, really, it's how do you do code reviews is the real question.

Ian:

How do you review what somebody's done Yeah. Yeah. And help them make it better before it gets without introducing a lot of friction.

Ash:

Yeah. Yeah. So I quite like a good a good, like, review checklist because it enables you to add things like security issues, you know, into Yeah. Into the into the review process, which when you pair, might get picked up, might not. Hard to tell.

Ash:

Depends on, like, the context, doesn't it?

Ian:

Yeah. Well so, really, what I'm getting from this is that it all depends on how the team uses it because it permits very poor usages.

Ash:

Yeah.

Ian:

It's, it can be very quite destructive and ob obstructive. Yeah. But, actually, if you could design a way of working with it, that could be a lot better. Although, Alan would say it's almost never a good thing. Yeah.

Ian:

But, you know, it could there are certain ways we could decide to use it that would make it a lot better than I think so. Than some examples. I think

Ash:

I think, like, you raised a really good one where it's like, if you've created a pull request, if you're in a remote team or, you know, a team who who's co located, then it's probably it's your pull request. So speak to some people about it and talk them through what you've done.

Ian:

Don't throw it into the void.

Ash:

Don't put it in a Slack channel which says, you know, please, can I have reviews on this? Because then immediately, you've added sort of dwell time to it.

Ian:

Yeah. And people being able to people thinking, do I want to add this to my workload or not? No.

Ash:

Yeah. No. Exactly. Whereas if you're willing to, actually walk people through it, then that makes an absolutely enormous difference to how quickly they get merged. I think this sort of desire for especially for in development teams and organizations for you know, to delegate that to a Slack channel, which people may or may not pick up Yeah.

Ash:

Is that's another anti pattern within the team. So it's like, well, actually, you even if you have worked on something on your own and not in a paired or mob context, then it's your poll request. You've raised it. So, you know, explain it to people, and then you can get good feedback there and then.

Ian:

Yes. And and sit people down and do it. Yeah. So there's no necessary not necessary to maybe go through using the full, ability of the tool to make comments and then raise these request changes, all this stuff that you were talking about. Actually, it can just be a conversation Yeah.

Ian:

And done very quickly. Yeah. There's there's one more thing I wanted to sort of put to you that he had said. And he said, neither pull request triggered code review nor hardening sprints. I don't really know what that means.

Ian:

Oh, okay. Improve quality. He's taught he quotes w Edwards Deming, who came up with lean that inspires a lot of the way that these things, desire to work anyway. And he said inspection does not improve nor guarantee quality. Inspection is too light.

Ian:

The quality, good or bad, is already in the product. You cannot inspect quality into a product.

Ash:

But that's assuming that this isn't that your code review is an inspection

Ian:

Yes.

Ash:

Rather than a communication between

Ian:

Conversation.

Ash:

Yeah. So I I I do see what you're saying. And, because it depends, again, how you use what you're doing, how you use pull requests as a process. So I I understand where he's coming from. Some people do use it as an inspection, like a, you know, a checklist.

Ash:

Especially like, say, the other dynamic is only the lead, say, our principal developer, does code review. Oh. Yeah. So they sit in their ivory tower and decree from on high whether or not something can be merged. So I've met a a couple of lead and principal developers who solely have merge rights, and only it will only be anything that goes into the main line is only by there.

Ash:

But again, that's an organizational problem, isn't it? Yeah. I mean Manifested as part of a pull request.

Ian:

Yeah. Yeah. Well, that's very interesting. So, I'm I feel a bit more I think I understand it a bit more now. Yeah.

Ian:

So thank you for that.

Ash:

Well, I think our pull requests and all the processes around it the optimal way for a internal development team within an organization to work. No. It's not. Because it does add delay, and it does add dwell time. If you had a set of developers who were skilled enough to do trunk based development, to develop directly on the main link mainline via via test driven development, and make small changes behind feature toggles which are meaningful.

Ash:

That sounds wonderful, doesn't it? But it's not reality.

Ian:

Where'd you get that to?

Ash:

Yeah. Exactly. I've never worked on a team like that. Not ever. I know it's a good thing to aspire to.

Ash:

So I agree with Alan, and it's an aspirational thing to get there. Mhmm. But there's different ways to to get there using pairing, mobbing, and all those other practises. And that all sounds great, but it's a it's a hard it's a hard thing to get there. You're not gonna get there particularly quickly.

Ash:

So I think the path for me would be to say, take a team that uses pull requests as their main method of code review, then say, right. Okay. Well, let's introduce some pairing. Let's try and keep our pull requests as small as we can so they can be reviewed together and merged easily, and try and avoid the whole 100 file PRs issue. Oh, one of my other favorites as well is when you branch off a branch, which is one of the side effects of using pull requests.

Ash:

So you start a feature, and you've got multiple people working on it. And then 1st person branches off the main line, and then the second person needs something on the first person's branch. So they branch off the first person's branch, and then it all just turns into a complete mess because it always does. So but, again, that's like you haven't split it correctly, or in a way that means that you could work on it easily. It means that what you've done is you've, you know, you you're you're kind of stuck with this thing that everyone needs on one branch, and then everyone else branching off that branch.

Ash:

So I try and squash that as soon as I see it. But, again, that's one of the behaviors that does come from pull request culture and process, is that when you can't split it down, sometimes you end up branching off a branch off a branch off

Ian:

a branch.

Ash:

But then before you know it, you've got no idea. And most of the time, I see that work thrown away

Ian:

Yeah. Because it just becomes It becomes too hard.

Ash:

Yeah. Yeah. Exactly.

Ian:

There's a wonderful, very short YouTube video, illustrating merging, git git merge. Yeah. Have you seen it?

Ash:

No. I haven't actually.

Ian:

It is very short. I'm gonna show it to you now. Okay. And then you can enjoy it, and then I'll put a link to

Ash:

it in

Ian:

the in the notes.

Ash:

That seems familiar to

Ian:

It's the last guy that falls down I find quite funny.

Ash:

And then one of the other things that's always on my mind with pull requests is is rebasing as well. So say if your pull request has 20 changes in it, 20 commits, and the for whatever reason, the team have decided that it needs to be nice and tidy. So you squash all those commits into one commit, and then only then can you then merge it into the mainline, which I always found really annoying. Because it's like, well, say if something goes wrong, which it always does, then you could always go back to the changes that actually made, you know, made the problem appear. Whereas if you squash them altogether, then you just have one big blob, and then you're stuck with another big blob.

Ash:

So so there's loads and loads of weird behaviors around pull requests, which make them seem, like, so terrible, but I don't know if it has to be. And I'm always wary of criticizing the thing based on how people use the thing.

Ian:

Yeah. Yeah. I mean, it's the age old thing, isn't it? Do we ban knives, which would stop us from being able to customise our food when we eat because people use them to do bad things?

Ash:

Yeah. Should we ban smartphones? Because it's demolished our attention spans. There's bad things on the Internet. They're obviously addictive.

Ian:

We talked about that recently, didn't we?

Ash:

I think so.

Ian:

Can't remember. It was up having a bad memory, not even a short attention span. I think maybe my, my joke is is is flawed.

Ash:

Yeah. Yeah. So, anyway, if you get a 100 file PR, just put looks good to me, isn't it?

Ian:

Excellent. So you heard you heard it here first.

Ash:

Straight from the tester.

Ian:

Straight from the tester.

Ash:

Just say, oh, just reject it. But don't take don't say anything to anyone. Just reject it on GitHub. And then when someone says, what are they all you doing? Just say, wonderful.

Ian:

It looked good to me.

Ash:

Looked terrible to me. Rejected. So yeah.

Ian:

Just request changes, but just a really tiny change.

Ash:

Request changes. Do it again.

Ian:

Please add the word the into the comment in this file. Rejected. So that was my thing. I hope the nerdiness of it didn't leave too many people behind.

Ash:

I think it's it's more about team than communication Yeah.

Ian:

It is.

Ash:

Than it is about the actual technical practises.

Ian:

Well, it's more our the nature of our conversation about it. Yeah. Where we said lots of jargon. Yeah. And I think we explained most of it, hopefully.

Ash:

So whenever, yeah, whenever you go to a a new organization, you look at how they deal with merging code. It will tell you everything you need to know about that organization Yes. And how they how they behave.

Ian:

If it's like the YouTube video that I showed Ash, which you can, find in the comment in the in the show notes, in the comments. What are we? A YouTube video, Which you can find in the show notes, then, you will have a more visceral appreciation of it.

Ash:

Yep. Yep. So that was 2 things?

Ian:

It was 2 things. Blimey.

Ash:

We've rattled through those for us. We've rattled through those two things.

Ian:

That's gonna be easy to edit at only an hour and a quarter. Not an hour. Not 90 minute. Yes. It's a 105 minute extravaganza.

Ash:

We do like an extravaganza.

Ian:

We do.

Ash:

So what's the, what's the email address to contact us, Ian?

Ian:

Well, I'm gonna say it's technology Eeyores at whatalotofthings.com.

Ash:

And

Ian:

But you're wrong.

Ash:

It has been tested. Therefore, it works.

Ian:

But only if you can spell technology Eors.

Ash:

Yes. That's true.

Ian:

We'll we'll put it in the notes.

Ash:

Yeah. Yes. I think that's a good idea.

Ian:

Are there any other final thoughts? I always remember, do you remember Jerry Springer? The late Jerry Springer, who used to have this reality show where people would come on it and talk about how their girlfriend's brother had done something. And then they would all get together and fight each other, and then there would be bouncers who would come on and try and separate them. But it was all a bit half hearted.

Ian:

I think the the fighting was part of the attraction. And then at the end, Jerry Springer would record a kind of, I'm gonna give him the benefit of the doubt and say, ironic, little thing about how we should all be nice to each other or how you should watch out for this or you should do this. And he was always like his final thought.

Ash:

Mhmm.

Ian:

And I always feel like maybe we should try and have a final thought. That sounds a bit bit terminal, doesn't it, when I say

Ash:

like that? It does. It does.

Ian:

It is my final thought.

Ash:

I wanna have a few more thoughts.

Ian:

Yes. Yes.

Ash:

I'm I'm I'm I'm into having a few more years of thoughts Yes.

Ian:

I think so.

Ash:

Giving my final thoughts. That's my final thought on that.

Ian:

Well, you might keep your final thought. Maybe no one will ever know what it is.

Ash:

I think it's probably

Ian:

It might be like, oh, shit.

Ash:

Yeah. It's like people often ask me, what do you think about when you go running? And I say, I think it's quite warm, isn't it? Or it's raining, or I'm tired, or I feel quite good, or there's a big hill. Or nothing.

Ash:

Or nothing. These are the things that I think about when I go running. Yeah. I don't have any Deep. Deep, unmeaningful realisations.

Ian:

So I sometimes have deep and meaningful realizations while having a shower. Yeah. But I never have any way of recording them. And, my attention span is not long enough to retain them. So basically, they are lost to history.

Ian:

Yeah. Maybe I should put one of those sort of, little whiteboard things in there with a little pen hanging on it, and then I can write,

Ash:

Some kind of shorthand.

Ian:

Some kind of shorthand that will then wash off.

Ash:

Stretch steam off.

Ian:

We've got a bit of a problem in our house at the moment, which is that the boiler's broken. So if we want to have a shower, it's going to be ice cold.

Ash:

Some people very much subscribe to that.

Ian:

So we've been we've been going to the gym a lot, which has not evolved much in the way of exercise, but has involved having showers.

Ash:

Yeah. Yeah. So I've used that particular strategy before.

Ian:

So yeah. So it'd be even less likely that I'll be recording any deep thoughts while in the gym's show.

Ash:

Yeah. Okay? Okay?

Ian:

So thank you for listening, everybody. Yep.

Ash:

Thank you very much. And thank you, Ian.

Ian:

And thank you, Ash. And it's goodbye from me.

Ash:

And goodbye from him.