Hannah Smith 'The hidden weight of code'

This is an auto-generated transcript and may contain errors.

S1: Smit is a freelance WordPress developer from Bristol with a background in computer science before freelance life. Among other things, she honed her management skills at the Environment Agency, where she managed large business change projects. She's co-founder of Clean Tech Southwest and is on a mission to raise awareness about the environmental impact of digital tech. Check out Let's Green the Web on Twitter. She also likes dogs, plants and snow. And Hannah is just an all around brilliant person.

S2: I've always been interested in sustainability and I've always felt a very deep affinity and a deep connection with with the earth around me. I've had that ever since I was a kid, but it's really only in the last two years that I've realized that sustainability and digital go together and that they have a relationship with one another. So what Environment Agency for very long time there. For about seven years in total. And when I was there, there was this general mindset that digital is better. Because we could see the reams of paper that came in when people filled in consultations online or when they submitted information, business planning information or any kind of information would see it. You know, we'd stick in the office and we'd have a physical problem of whether or not to put all the thinking paper that surrounds us. So there's always there's always been this sort of this feeling that the digital is better. And as we know, you know, you've taught me a lot about this. We know that digital is just largely unseen. And that is the beauty of it, isn't it? You've delegated someone else. It's someone else's problem to manage and store that information for you. You just want to be able to access it. So it's really only been in the last couple of years that I've realized, wow, okay, hang on. All this all is not what seeing what one seems to think. You know, whoever whoever came up with the terminology, the cloud, I think, you know, what a brilliant bit of marketing that's been, because it really does invoke this feeling of something quite harmless that's sort of floating around and intangible and is really not, is it? It's quite the opposite. So I think in the last two years, I've really, on a personal level, really started to dig into this stuff and realize that there's there's a connection between these two things. I mean, I've always been mindful about the amount of stuff I have in my life. So I've always been very mindful about not buying the latest gadgets anyway. But that's only because I just don't like stuff very much. But yeah, the last two years I've really realized just how much of an impact that stuff has that I had really no no real idea about. And I do these days. And it's interesting as as a tech professional. So, you know Gerry, I'm a developer and I work with code and like I'm not really someone that I would describe as being sucked in by the new and the shiny. But I do love a good new code framework, or I do love this, this awful, this, this opportunity to use something new that might make my life as a developer better, you know? And I think that's wonderful. Great, isn't it? You know, people solving problems and, you know, trying trying to to make things better for themselves and then, you know, making that code available to others. But what I hadn't kind of realized is that all this code stuff that adds up and yeah, sure, you might be using this code base to solve one problem, but actually it comes bundled with a load of other features that you don't need or you don't want. It's not always easy to turn it all off. So as a developer, we've really started to sort of look into thinking about what I'm loading into something, what's running in the background, and why. Why is it running? What is it there? What's it doing? I guess an observation for me is that it's it's an awful lot to know as a developer, to be thinking all the time about what what exactly is this? This bit of code I'm loading and doing down to the the degree that there is a lot of excitement around that too. So I can kind of understand to some degrees why in the developer world we've ended up with all this kind of nutty, bloated code that's come from a good place, I think. But I think, you know, there is an opportunity for us to sort of take a step back now and kind of have a bit of a reassessment about what we're what we're creating and why.

S1: Yeah. Now, that's a great story and a classic story in a way, you know, I mean, the same with myself. It's really I mean, I was maybe a year ahead of you in figuring it, you know? I mean, I've been working in in the Web industry for 25 years. And, you know, I sometimes say if if it takes everyone just as long to figure it out as it took me. Well, with no hope, you know, you know, like I know, you know, it was just exactly as you described. So I'm not going to go into the story from from my side. But, you know, that sense of yeah, that it is a lot of it's hard work, isn't it? I know when you have to really it's easier to take the prepackaged framework than to really, you know, have to think deeply and is at the root cause that, you know, these frameworks or whatever are a response to increase in complexity. But, you know, the price we pay for the convenience is waste. Or is there a way to. You know, is there a way do you see frameworks or approaches to code development that, you know, can give that convenience but not, you know, don't, you know, bring all the packaging off of the waste that comes with it? These solutions to complexity seem to come embedded with a lot of waste that that instead of picking out that, you know, that little bit of code that would really address the problem, that little better code comes with another couple of hundred lines of stuff that you don't need. But because it's all neatly packaged together, it's hard to dissect the little better code that you really need. I'm and to not take all that other stuff that that actually the page or the function or deform or whatever is happening, it doesn't actually need it that that's, you know, or are there new models that are trying to address that issue or, you know. What's your experience there?

S2: Yeah. So I think you said something really interesting there, which is do solutions to complexity come embedded with waste in them? And I think you can't give a yes or no answer to that because it's only going to be waste if you don't know what to do with it or if you don't know how to leverage something within the code base that you're using. Now, something that I struggle with all the time. So I'm a self-employed freelancer. There's only one of me. I can't keep up with all these new solutions that are being created. So do I think that I embed waste in some of what I do? Yeah, probably because I can't I can't always understand or don't always have the time to deep dive into all the code packages or frameworks that I'm using. I probably only use the surface of it, probably with the exception of WordPress core itself. I'm probably pretty, pretty comfortable with what to do there. But WordPress itself comes built with, gosh, the ability to add plugins and themes and all sorts of other stuff. I mean, all the solutions. That was the other part of your question like is is there a way to reduce this waste? Could be if we all slowed down a little bit, that the pace at which we are developing new solutions, new frameworks, new ways of doing things is mind blowingly fast. And that is incredibly exciting. But I don't think as a technical coding community, we often pause enough to let everybody catch up with what we're doing. And I think there therein is an intrinsic sort of set of compromises that we have to make of innovation versus accessibility for all. And I think in the tech industry at the moment, we are a little bit too swayed towards innovation and the new and the shiny, rather than actually making the tools and services that we create accessible to all. And I think if we slowed down a little bit, everyone would probably be quite grateful. I'm sorry.

S1: I think we were causing a a kind of a trap, as you said there. Innovation. I've been thinking about innovation and recently and I was thinking that, you know, actually, innovation is probably a key contributor to climate change and global warming because the very act of innovation is is a very resource intensive type of activity. And that as you're constantly churning through innovations and your you are rapidly consuming materials and and producing and wasting stuff because you're you're constantly moving on to the next thing, so to speak. So the thing behind it is no longer useful or is less useful and becomes more, more wasteful. And a lot of the time, like I look at a lot of this activity over the years and I say, well, what's actually been achieved? You know, all this frenetic innovation is, you know, what what great things are actually being done with all or all of this that, you know, so many websites that I come across could code and should operate in a vastly simpler framework. They really don't need her. Most websites are still quite basic. You know, they're still, you know, the, you know, 95 out of 100 websites are not complicated things.

S2: You know, that they're really not. Yeah. I mean, that the vast majority of them are essentially text and images. But, you know, we've got trends and fashions that that might suggest that, you know, it's important to have those images flashing in and moving in because everybody's losing their their focus and their attention span. So, you know, so we've got because of that societal problem probably being caused by tech in the first place, to be honest, we've we've got sort of loads of different approaches and frameworks for, for animating images and wiggling images around and, and, and focusing, focusing people's attention or rather trying to grab their attention. So, yeah, we do see sort of some small, small, little fringe changes. But I do I do agree with you. You know, a website is fundamentally text and images in video as well. But I don't think video in itself is a bad thing. It just depends on what it's used for. Um, you said something really interesting earlier. You sort of said do changes as a resource intensive activity and boy, it really is, isn't it? Yeah. And I think a lot of people who are developers get really excited by change, get really excited by new. I mean, I don't know if there's any stats around this. I bet there are, but I reckon you'd find that like 95% of projects that develop start, never get finished, go. There is something very exciting about being in control but being in charge of something and creating something, and there is something a lot more humdrum about maintenance. I think you're right. And I mean something a lot of your content that comes out has got me thinking along with some content by Tim Fricke, who's based over in the US. I'm sure you've come across him by now. Yeah, yeah. And it's this idea of kind of of maintaining your content and you know, actually that to be truly sustainable, you are maintaining your content for the longer term. And we know that that's good marketing practice at practice because we know that that is good for SEO. And I do think developers in general could take this mindset into their code base and think, okay, well, you know, if I'm creating this code, what's going to happen to it? Not in one year's time, but in five years time? In five years time, is this going to be a benefit to someone and are they going to be plans in place that we can manage this? Am I going to have written anything down and documented anything? Because that's another thing that most devs will do under duress. But you know, normally a little cajoling involved and I do think is it as a as a tech community, I do think we could put a bit more time and effort into that stuff and talk less about the rockstar side of development, because that phrase just winds me up. I hate that phrase. You're a rockstar developer. Can we I don't know. We need some better terminology that kind of praises the developers that are that think about the long term maintenance and that do those kinds of tasks and keep things running and that repair that code rather than throwing code away. So I work with WordPress. WordPress, you know, we'll have some people cheering and we'll have some people sucking through their teeth going, Oh my goodness, why are you doing that? But WordPress is really, really interesting software because it's just had this 18 year anniversary, which is an incredibly long time for some software to behave around 18 years is is something quite, quite remarkable. And so there was sort of online celebrations and people talking about WordPress and a number of stories surfaced around people updating WordPress from versions that are ten, 12 years ago and that the site still runs and their sites still work. And I think a lot of people don't like WordPress because they don't understand it, but B, because it's been around a long time and has this perception of not being new and shiny. But actually if you take a step back and think about what that software has achieved, it is right. And, you know, I think that there's a real case there for saying that WordPress has a lot of the hallmarks of sustainable software given the longevity of it. Given how backwards compatible.

S1: When you think of how crazy the world we exist within within this web development or design world that, you know, I mean, in human terms, eating isn't old and humans are just a blip in time. Like, I mean, if you if you if you understand physics or the age of the universe, I mean, we're just, you know, totally inconsequential. And yet and yet we've come into this technology world where we're to something that's two years old is old. I mean, how crazy and twisted. And and this is one of the core problems that I began to realize. But if you keep changing things every two years, you're changing resources as well. And, you know, you're dumping or degrading or, you know, the other resource that they've got to waste or else, you know, they hang around in the architecture and get pulled down every time person loads to page, but they never get used. So they're even worse, you know, in, in the process that sometimes you find pages that get stuff added to them, you know, just continue to get bloated over time or. But, but this sounds like, as you said, what what's going to happen to this in five years? I mean, nobody seems to have the, you know, ability to think beyond two years. It to me, how are we going to save the planet if we've got a bunch of developers who can't think beyond two years if software is supposed to help us save the planet? I mean, climate crisis isn't a it's it's not a it's not something you can do a sprint for and fix it, you know?

S2: No, no, no. It's interesting. An image just popped into my head, so. But for the last four years I've been teaching on a coding bootcamp basis based in Bristol, where I'm from. I often used to say to the students, When you're trying to solve code problems, the best thing you can do is really take your time, take it slowly. And I remember saying to them, one of the things that got me into tech sort of 20, 20 odd years ago was the film The Matrix. There's that scene where they're looking at the Matrix in code and there's like three or four screens around the operator, and there's all these like characters running up and down the screen. And I always remember seeing that image and feeling so excited and being like, Wow, you know, tech, you can literally save the world and you can literally save the world through reading quickly change in characters. And you know, everything about the film was was very high, high, high energy and quite intense and quite fast. He needs to say to the students in my boot camp, I was like, If you've seen The Matrix and you think the tech is going to be like that film scene, I'm really sorry to disappoint you, but actually good tech is anything but. Good tech is slow and thoughtful and actually most of the time quite boring. I think as a tech society we need to get a little bit more back to that and have less of this sort of notions of everything's going to be fast moving and the characters are whizzing across the screen and everything's happening. It's happening a million miles an hour and just slow down a little bit.

S1: That's one of the core characteristics I think of digital is speed because, you know, it's a kind of it has this inherent fluidity to it because of its impermanence, you know, because it's, you know, because it's not a chunk of wood or it's not a chunk of steel. You know, it's it's digital is just a more fluid thing. So it tends to it seems to orient itself more to to speed. So we need we need to train people in ways to slow down that that probably a carpenter wouldn't require to train their students, you know, in the sense of, you know, there seems to be just part of the digital culture that a kind of scream speed, whereas, you know, if you want to make a piece of furniture, but hey, you know, are a piece of steel, you know, there is a certain, you know, constraint either from the foreignness or the chisel or whatever, you know, that that constrains the over reaction. And maybe that's part of the why they pull all these frameworks is they don't want to take the time to write the 15 lines of code that really is all that's needed. And it's easier just to pull down 600 lines of code that does the thing, but also does 20 other things as well, which they don't need it to do.

S2: Yeah, it's really, really interesting. They're likening traditional hands on cross cross person. And I know a few people who describe themselves as web crafters, not developers, but web crafters. And I think that subtle change in terminology is really nice.

S1: It is, yeah. I was just thinking when you were talking that the inherent in the word developer is developed. You don't like it, is it? We're developing another word for create. It's it's not, you know, so it's not a maintainer, it's not a craft, it's a developer, you know, it's a kind of, you know, then that language reflects the production culture that you know. And it's interesting to hear that some people, you know, are no longer wished to use that type of letter.

S2: It is interesting. I mean, the term engineer doesn't get used as much these days. People do tend to refer to themselves as software developers rather than software engineers. But I think engineering does give me a slightly different sense of of the of the industry as well. I don't know about you. I tend to think of engineering as a little bit slower. Yeah.

S1: Well it's more comprehensive. I think it's a, it's a more it's a deeper word in the sense it, it, it evokes a greater brat of thinking to me anyway.

S2: I think it does. I think that's you know, that's a really interesting point, isn't it, that yeah. Even the roles that we call ourselves, they have an innate urgency in them and an innate sense of speed. I mean, I'm so, so, so grateful within the now I was going to say the developer industry, maybe I should say the software engineering industry is you got me thinking about that. Now I am grateful within the code industry, whatever you want to call it, that we're talking a lot more about mental health now. It's undeniable that there can be a lot of pressures on you as a developer. You know, I work on my own and I put an awful lot of time and energy into my mental health. And actually one of the things that I do the most is to try and find ways to help myself slow down and breathe a bit more and just go slightly slower, because I actually know that longer term, my solutions are way better, but it actually feels a bit like an almost a daily fight for me to. To manage those emotions.

S1: Well, it's so important. But, you know, it's and again, I know I used the words as well, but, you know, even fight you. You know, we're were so you know, we're going to fight against COVID 19 and we're going to fight, you know, like the language really. Like my wife gets me every night before we go to sleep. She says she's really she studies a lot about positive psychology and we each have to name three things we're grateful for today, you know, that happen. And, you know, this stuff helps, you know, and, you know, the effort you make every day is is so important. And so, you know, because you're not going to say, oh, I live crazy for nine months and then I'll I'll take two weeks to fix my mental health. Like, it's.

S2: Like there's.

S1: No doubt, you know, you fix it every day or you break it every day, you know, in in the process. So, you know, it's wonderful to hear that you're investing that time to nurture that essential, you know, well-being and that, you know, you keep coming back to to slowing down like, you know. And we look at the reverse from fast food. Fast everything is what's killing the planet. You know, the processing that that occurs either in food or or whatever. But but speed, you know, in so many areas, you know, whether, you know, fast delivery from Amazon is not more damaging than than waiting for three or four days for for delivery. So after a certain point, you know, after you know, when you start driving, you know, and it just appears the laws of thermodynamics, of whatever, you know, up to 30 months, you know, 50, you know. But once you get up to a certain speed, dangers increase significantly. Energy consumption really jumps. So, you know, to move a vehicle at 600 versus 1200 miles an hour, you know, the amount of energy required to get, you know, for Jeff Bezos, that idea to go up into space for 3 minutes is just so you can say he's been in space. You know, what an idiot childish thing to do? Like it's like the world has been run by 13 year old idiots. You know, I've been up in space for 3 minutes. I bet you haven't. You know, like, it's so stupid. And yet these are the people who are, you know, but it's all about speed. It's all about, you know, that and figuring out and obviously you don't want to be too slow because, you know, you won't you won't get a lot of places. But once you you know, we all have a threshold like, you know, like if you get hit at 30 miles an hour or 25 is a good chance of surviving. But if you get hit at 60 miles an hour, you very little chance of surviving. And I think if if we're walking at 60 miles an hour, our mental health is going to suffer a lot more than if we're walking at 30 miles an hour. And as you say, we'd probably do much better work at 30 miles an hour.

S2: I think I think we would I think we would certainly do less work. But I think that the work we would do would be the work that cuts out the noise. And it's the stuff that really matters. I mean.

S1: What is it you know, I'm sorry for interrupting, but is it is it less work like, you know, like or is it maybe it's less volume, you know, but it's not it's not less. What if we consider work like wasn't Einstein asked once you know if if you got an hour to solve a really difficult problem how would you spend the hour. And he said I'd spend 55 minutes thinking mm mm.

S2: And that's, you know.

S1: And sometimes we don't consider thinking as work, we only consider developing, you know, I'm only, I'm only working when I'm coding. I'm not, I'm not working when I'm thinking, because often the slowness gives us the time to think.

S2: I think that's so true. I mean, I can think of so many examples of working with my own clients where where they'll contact me and they'll be like, Oh, hey, Hannah, we've got this really urgent thing that we need to do quickly. Here we go. Right. Okay, so why is this urgent? And they'll give me some sort of reason generally to do with a team meeting that's just happened where everybody's decided that they're going to do this thing and then it suddenly become urgent. And actually, I've trained most of my clients now to know that they're not going to get good results out of me if they want me to, to react to something really fast. So I'm quite an introvert, so I do like time to think about things and I've already really realised the power of that. And often I get requests like that from my clients. I sit on it for a week, just see what happens. And nine times out of ten the requirement either then goes away or suddenly it's become less urgent or it's changed. And I do find that, again, just that confidence of being patient and just letting it play out, letting the enthusiasm die down, letting the sort of the dust settle a little bit, can pay off so much, both in terms of my time, but also the business's time as well. If it's still really important in a week's time, then I know it's actually really important. But you know, so often it changes and I'll get like, Oh God, okay, it's urgent. I feel my sort of, you know, my breathing change and then but yeah, just, just sitting on it, that little bit of time does make all the difference. And again, I think that that is something that some as develop as developers or as code craftspeople or whatever we whatever we decide the new term is. I think that that's something we should all learn and be taught.

S1: You know, it's great. I think it's a great principle. It's a great idea. Somebody once, you know, who said didn't nearly never responded to their email, certainly immediately, because they said if it was actually important, if somebody had emailed them again or announced it written, or they did use another form of communication, too, you know, and that was, you know, what you just said reminded me of that sort of these habits, the habits of, of of the slower people, you know, that, you know, to embrace because we know slow food and slow that, you know, that so much good, you know, can come from slow sometimes. Yeah, but you don't want to be slow on a football game or something like that. It's not if the keeper is really slow when the penalty is taken, you know, that's not a good it's not a good strategy. But in so many areas of life, you don't need to be racing around like a lunatic, you know, and particularly when it comes to doing something of substance and something, as you say, that will last, you know, has the capacity to be to last or, you know, be reused in five years time. And and, you know, so that that that concept of slowness and, you know, and maybe it's the wrong word as well. You know, it's more thinking, it's more giving yourself time to think and to really work through. Is this really an urgent problem and to task these core questions rather than to constantly react to the stimulus that has just emerged in your environment?

S2: Very much. I mean, you know, to put put some I think there's only one type of problem where I will literally jump when somebody asks me to, and that's if there is a bug on a production level system. So something's broken in production, but that is something I will jump for. But nine times out of ten, a bug that's been introduced to the system is as a result of trying to do something too quickly. So that's not to say that I don't ever get bugs in my code. Of course I do. I'm human, after all. But when you pace yourself with the development, you do the development slower. You are far, far, far more likely to put a robust solution in place and therefore actually have fewer bugs and therefore not have to be in this cycle of jumping, you know, all the time. So, you know, I say to my clients, if you find a production level problem, put it on my ticketing system and address it is bug and those are the things that when they pop through so oh okay well really sit up and pay attention. So there's some interesting, interesting stuff around there. You know, you just create this sort of almost self-fulfilling prophecy of of having to work quickly. If you if what you're pushing out is, is quick in the first place.

S1: When you be looking at a site, somebody else is donor. So do you see common type of issues of waste of, you know, unnecessary. Oh yeah. This taken 9 seconds to download and and the reason is are you not have you notice any patterns or new patterns are that tend that. Things that people deliberately skip or, you know, don't focus enough attention on or that results in a real common pattern of of wasteful practice in web design is I think that, you know, oh, I keep saying this, you know, why is it why does everybody do this? You know, when when they really shouldn't or anything like that?

S2: I think the one for me is analytics, but is the one the one thing that when I inherit a slight and someone tells me it's slow, okay, there will be other reasons as well. But the most common one is an excessive use of analytics programs. I think people feel that there's safety in data, but actually, you know, it usually just slows things down so that, you know, what I see is a team has a marketing team or a development team have gone, oh, we need to measure X because this is a is a goal for the company. They put system in place to measure X, but nobody ever then comes back to remove X when they then decide that the next thing they want to measure is Y. And so you just get layer upon layer upon layer of analytics programs. And they do, I think, you know, they can really slow the site. Then it's noticeable when Hotjar, for example, is on a site or you've got Gtlm, Google type manager loading in various of the other analytics things. HubSpot, which is a way of embedding forms into websites, seems to come with loads and loads of analytics. I think that for me, if I had to point my finger at one thing, it would be analytics and this this need for data collection, which is not always in Justified, but it is often implemented and then just kind of overlooked in the future is forgotten about another thing, you know, so. So said what? Well, when you look at the new code base, are there any other things? When I look at a code base, I can always tell what kind of client I'm working with by the quality of the code. I've got a code base. I mean, obviously it will the code base will give me some indication of the developer as well. But if I've got a code base that's a right royal mess. I can usually hazard a guess that that client is someone that's going to work quite quickly is going to be innovative. I don't mean innovative necessarily in a negative way because innovation can be really exciting and can be really beneficial. But if it's a client that flexes and changes a lot, I can always tell that from from their WordPress code base because it will be a mess. There'll be stuff in all over the place it's not being used or templates that haven't been cleaned up. We'll see assessments all over the place and clients that generally want quick results out of developers will get a code base that's like that.

S1: I was talking to Tom Greenwald and he was saying, you know, there's an awful lot you can do with a megabyte.

S2: Yeah, yeah, no.

S1: There's an awful lot you can do. I mean, most web pages don't need to be a quarter of a megabyte in size, and yet they're four megabyte in size.

S2: Absolutely. And again, it all comes down to slowing down, because as a content creator, I do quite a lot of writing and, you know, decent teaching as well. And I'll I'll be doing more of that coming up as well with an interesting project that I've got coming up that actually it's actually really, really hard to put a distilled paragraph out. It's much easier to bash out a whole page of content than actually refine it down and think about, okay, what is, what is, what am I trying to communicate? What is my key message here? If you're in a hurry, you tend to write more than if you're in a you know, you taking your time and you're really distilling what you're doing then to make it useful. I think the same is absolute truth coding as well. You know, if you're in a hurry you'll produce more. Actually, the best days that I have that the office of the days where I can take code out, those are always my favorite days. Always feel great when I get the opportunity to remove code from something.

S1: Well, it's, it's a great principle and you can do back coding Tom again here he he was saying he was agreeing with you about the analytics and that he says, you know, most websites don't even need any analytics. And that's what I've learned over the years. Like, you know, I remember working on. Used to be Web trends back in the 90 seconds. And I remember sitting around and so many meetings and people, you know, trying to look intelligent, figure out what the Web trends meant and when the bounce rate went up to or. Yeah, and basically most of the metrics are crap, you know, most of them not there, no meaning there. No, there's no useful meaning. It's not it's not like it tells you, oh, don't go out now because it's raining. It just doesn't really give you useful. It's just good. Well, it could mean death and it could mean that it could be raining, it could be snowing, it could be sunny. You know, actually, you know, a lot of you know, like I said, you got to you it's a pandemic. You know, health website is getting a lot of traffic. Whoa. You know, like what? Like, that's, you know, volume in many situations can be a negative indicator, you know, not a positive indicator. You know, if you've got a if you've got a shitty product with loads of bugs in there, then you've got loads of people coming to your website trying to figure out how to overcome an issue. You've got lots of traffic, you know, so you've got so in a huge number of situations that I was in, the organisations didn't need any analytics, maybe, maybe they could turn them on for two months in a year, but, but we didn't really make really much of a difference in, in, in anything other than analytics theatre, you know, of somehow proving that your little campaign actually did something, you know, when all it did was annoyed the hell out of people. But, you know, you got some analytics that showed whatever. But that again, I suppose this these analytics are they are a reflection of our our need are vanity for for metrics and our vanity for showing that we've created volume.

S2: I think that's a really that's a really good point. And I was just thinking back to some of my experiences when I was at the Environment Agency. So what, you know, ends up at a lot of board meetings and committees and things when I was at the Environment Agency and data was never the problem. So there's always plenty of data around water quality issues we had or what bathing waters was safe or whatever. The issue wasn't data per say, it was analysis, intelligent analysis that actually told you something. And that was always the pinch point, you know. So these senior executives would just get given pages upon pages of pages data and, you know, you can't make heads or tails of that data when you're in a meeting with with someone, it's it's the intelligent analysis that then tells you the cause of that data and what could be done about it. That's that's the intelligent part. That's the that's the path of value. And I think that's like, oh, well, the solution is just some software. Look, we, you know, we can solve your analytics headaches by giving you easy access to all the data, but it never solves the the fundamental problem of then understanding.

S1: It creates the even bigger problem that, you know, it reminds me a little bit of this analysis I've done of photography, you know, the amount of digital photographs. I mean, last year we took 1.4 trillion photos. We took more photos last year than in the entire 20th century. And what happens in that environment is that people there's downed professions in the US photo managers. And this woman was saying the average family takes 5000 photos. When you're taking five times in photos, you can't find a good one, you know. So when you're when you're collecting so much data, you get to a point where the the new data smothers any analytical ability to really find the useful data. So so we're in a situation now where we're constantly feeding and we can't stop feeding each other. And the more, the more we feed ourselves with data, the less we're able to analyze it. I've never seen I don't know if you've noticed and I've never seen less information architecture skills around like back in the nineties, I'd more conversations about how do you structure this, how do you classify this? It's like today people just feel like, well, you can't, so let's just give up a Google and figure it out. Let's, let's not even try. You know, you can't create an information architecture because we've just got too much data. So we won't create any information architecture or essentially or else we do it so quickly and then on such a whim, you know, in which so little. Expertise. It's a strange world. That is, as data explodes, actually, the skills to understand it become even rarer.

S2: Yeah, they do. They really do. I think that's really interesting. Yeah, I was thinking about the photo manager. I mean. So. So one of the things that I love doing in my free time is snowboarding. It's like my absolute favorite, favorite sport. And so you see so many people on the slopes with GoPros attached to their camera or attached to their chest, whatever. And my husband and I were like, Should we get a GoPro to attach to the dog? Because that would actually be quite funny because she comes, we'll go hiking, boating and she'll like come running with us and stuff. And I just lied to him and I said No, can we not? Because what that means then is that's less time for me snowboarding and more time in front of the blinking computer going through all the footage and deciding what to do with it. And I don't want that burden of that data in my life for the I don't want to have to be responsible for it.

S1: That's a key I think is something that I've you that we do far less thinking real we're constantly looking for something to do the thinking for us to be able to feel in fast, to do the living, to experience the holiday for us. We can't experience the holiday if we don't experience a true record, a GoPro or whatever, you know. But we actually can we can experience in a through our eyes, we can experience it to our nose and to our ears, you know, and we should use those things more rather than constantly looking to, you know, as much as we love technology for technology to do the living and the thinking for us.

S2: I think that's an absolutely excellent point. I really do. I mean, that's very much, very, very much where where I've I've ended up. Yeah. Just let me be just let me be, let me have time. That's the most precious thing that anybody can give me is time. And I think it's the most precious thing that you can give to any anything that you're working on. It is time.

S1: If you're interested in these sorts of ideas, please check out my book Worldwide Waste a Terry McAuliffe or dot com. To hear other interesting podcasts, please visit. This is H City Dotcom.

‍