Elegant Code and How Things Work with Andrew Snare

Hi everyone, my name is Patrick Akio and if you're interested in how things work on a technical level as well as what does elegance mean when we're talking about programming, this episode is for you. Joining me today is Andrew Snare, Consultant and Software Engineer over here at Xivia and just an interesting, interesting mind and person to talk to. I'll put all his socials in the description below, check him out. And with that being said, enjoy the episode beyond. Coding.

Otherwise, I'm interested in how things work and. Through my career it's it's been useful to continuously make sure that you keep on top of how things work and that gives you a framework when you come across new things of hanging them accurately in relation to the things that you already know. Yeah. And the biggest challenge I see in our industry or when I'm working with colleagues and and people is that sometimes I can see a concept has been put in

the wrong spot. And and fixing that or not fixing is the wrong word, but trying to communicate when people have different ideas of how things work is is very, very difficult I I can imagine. That can be extremely challenging. It's a it's a difference in fundamental understanding. Then if I think the world revolves around X and you think it differently, than you have an interesting discussion. Well, it can also lead to misconceptions. The most common one I come

across is time. And in computers, how we deal with time zones, and time is completely independent of a time zone. It's this idea of an immutable clock that moves forward. Now is now, whether you're in Sydney or New York, how we describe it and represent that time as humans, that involves a time zone because I can say it's 9:00. In Sydney, 2:00 in the morning in New York or something like that. But that's where the time zone came in when I was trying to

describe the moment in time. But computers don't need that. And and what I often see is developers, for example, that's an example where they make mistakes of saying, well, what's the time zone? And I'm like, well, it doesn't matter because it's a time stamp and you don't always need a time zone attached to it until you log it or you need to display it, yeah, because then it's based on interpretation. You need to know which time zone you're at to see when it

happened. Well, you need to see. See, you don't actually, but you need a reference to describe it to someone and you don't always need to. So you don't actually, you don't always need a time stamp because you can just say, well, we're going to use seconds since 1979, nine, 70. I can describe a time to you in that way. There's no time zone involved. And you you both have the same idea.

But when it comes to. Interpreting it for a user, that's often where the time zone starts to become important. Up to that moment, it's actually entirely unimportant. And this is an example of where I see people have a different way of thinking about things, and often it can be difficult. Where that's where communication becomes challenging. I can imagine, yeah. For me, it's always I I I

described software engineering and it has depths in, in certain areas, right? Yep. And I always describe myself as someone that wants to know, let's say 70 or 80%. And for that last 20%, I rely on my team for that knowledge. Yeah, it's easy because I I like focusing on communication, making sure we do the right thing. All of the aspects around software engineering that is also needed when building a

product, for example. But I don't know if I'm doing myself a disjustice for not going in that depth that I feel like you do. How have you seen kind of different teams? So it depends because sometimes when I'm on a team, I'm the expert. So you need to go beyond that 70 or 80% and make sure that you're

at 99 point whatever. Because the the problem with this knowledge is that it doesn't accumulate by the 70% the the the bad things in software that we all the bad things that we often associate with. Quality control and technical debt and so forth, they normally come around about because of the the 5% that's been missed. So I normally make sure I've got, I go quite high. But more important than knowing that last gap is being able to detect someone else that does or doesn't know it.

So if I'm on a team and I don't have that 20 or 30%, I rely on what I do know to be able to, you know, have what I call the bullshit detector, yeah. Very important. And being able to detect that this person does know that 30% we're in good hands versus this person thinks they do, but they

don't. That's almost as important as knowing it yourself, knowing when you can actually trust your team around you to know it, and knowing when Hey, no, sorry, I've got to do the do the research myself and you can. A good proxy for that is I find as a software engineer is how well you feel you need to review other people's code during code

review. Okay. Because if you find yourself seeing code in you and you know instantly I don't need to go into all the details, this is solid, then that's that means you're trusting that teammate and you know that they're they've got the that gap all covered. If you find yourself saying, I've got to effectively pretend I'm rewriting this myself and going to every detail and then you know that you're that 99%. Yeah. Are you, have you found to be

comfortable in that position or over the years, how have you found kind of comfort there? Because I feel like for people starting out to be the sole expert to know that 99% and other people relying on you can be quite daunting there, Because if you make a mistake and no one else knows that last gap. It can be stressful sometimes. I mean, sometimes it's kind of cool. Yeah, it is awesome. Well, when it when it when it comes off, but at the end of the

day. We're never going to have the 100. So to a certain extent you got to say stay humble in those situations and recognize that there's going to be mistakes no matter what. The other thing that's important is how you communicate in that situation. And sometimes you have team members that recognize that gap and they just, they're like sponges. They want to learn. They've got the passion. They like that's fantastic. Hadn't thought of that. This is really great.

Occasionally you bump into the problem where so everyone thinks

they're the world's best programmer. Everyone. I don't think so. Every no, I don't think that's a no no. Everyone thinks they are. And often when people don't recognize that they've made a mistake or they're not used to it, then it can be challenging because it can sort of confront. It can be quite confronting. We've got that challenge. I've had that challenge in the past, I can imagine. And that communication can be really, really difficult.

Yeah, I mean it, it drills down into kind of that humbleness that you already mentioned. We're never at 100%, right? So if you realize that the knowledge, you're never going to be at 100%, then there will be mistakes in there. So you will be kind of that sponge person and be like hot. Is that truly the case? And you're open for a discussion there without judgment, right? Because as soon as there's judgment, no, you're wrong. I'm right. Then the discussion becomes very, very hard.

Yeah and yeah, so indeed, definitely. There's one department in particular where I where I worked for a while and that was fantastic because we'd make mistakes and. There'd be people around you that would point things out. And I was like, I don't need to know all this stuff. And when I didn't, or if I made a mistake, it was just like this is going to be it. And everyone just moved on straight away. There was no discussion about it. Everyone just recognized instantly this is the problem.

This is how we're going to deal with it. We're not going to sit and discuss back and forth about. Why This is right or wrong, it was. It was actually quite liberating. I really enjoyed that time. What what about that department

made it that environment that you described where it was kind of that openness and and allowing for mistakes in that way? It was partly openness. They were also, I think, the the, the, the best quality people I've had the pleasure of working with. It was no. It was really, really good. Actually, I'm just going to leave it so I've got to be a bit careful here about names I can't identify too closely, but you

know, it was it was. There was definitely a lack of ego, and it was people recognized how you can use it to build up, and not all teams realize that. Interesting. Not all teams realize how to build up on each other. Did it come through? Cuz I'm still trying to figure out what ingredients were in there to make it that environment. Was it a certain level of expertise? Discipline. Like, I mean, humbleness is definitely there. Definitely.

It was also a recognition that with software, especially if you wanna have good quality software and reliable software, time is a bit fuzzy. Yeah, in terms of how long it takes to do something. Everyone recognized that. So in some ways it was a slow team, but when they did things that were sold and they stayed good for much longer and it was. And and the reason for that is I think they also recognized that

when you combine components, they all need to be bug free. If you've got something which is 99% or 98%, yeah, 1 component, 98% is OK, that's fine. But when I've got two or three. Then suddenly it's 90%. Once you accumulate those two percents of what accumulates not the 98.

And these people at all had been in situations where they'd seen teams that are spending all their time on operational issues, dealing with bugs and with no time to move the product forward because of these issues, these two percents that are that accumulate. And so they recognized and spent a lot of effort on making sure that things are 99.9 or whatever. And that that was wonderful to

see, I can imagine. But then you have to fully align with your business and the business needs to be aware that this is kind of the way we're going, right to at least try for that quality. And this was a business that operated at scale and at scale. These things matter. And maybe that was what was different between this and a lot

of other teams. These world people with experience operating at scale, whereas if it's if you're building an application that's only going to be used by, you know, 30 people in the back office or something like that, then that's a different, sadly, that's a different conversation. Yeah. Yeah. It's, it's interesting to me because at some point you will need to balance kind of speed of delivery versus the quality of

your output, right. Ideally you want the highest level of quality, but the business and probably versus the competitors, you want the quickest kind of time to market, time to deliver. Yes, and that's a huge challenge finding that balance there. But it's also the one thing where we've got that hockey stick curve of scale. Once you go over that elbow, it has to that conversation. Doesn't become a conversation because it all falls in a heap.

Yeah, if you if you haven't prioritized the quality at that point or making having it scale reliably.

Exactly. That's the that's the interesting part, though, because everyone, everyone foresees kind of the hockey stick curve probably in in what they're doing. But a lot of people don't reach it. No, exactly. That's the challenge I have exactly. But even to build in your software or your product with that hockey stick curve in mind, to get to that point, you also need to kind of have kind of that flatter line in time basically. You do, and so someone with

experience. So people with experience will recognize things. The low hanging fruit. So during that flat bit where you're not scaling yet, there are often obvious things that you can do which will prevent you from unnecessarily making things bad. And that can be a difficult conversation because of the people without experience don't recognize that always. And it's sometimes hard to get alignment there because they'll be like, why does this matter? I'm like, well, it can matter.

And that's just outside their experience, Yeah. So that can be a bit of a challenge. But it's not just so the hockey stick can also. It doesn't always have to be people and users and stuff. Sometimes it can be revenue and money.

So for example I worked on an application which was being used by traders and we only had 30 users but it had to. This was being used by traders and when I arrived on that team I can talk about this because it was a bit longer ago end to end for the information to arrive on their screens.

There were 13 components between the data source and it arriving on their their screen and every one of those 13 components had to be working for it to end up. And when you look at that 99% sort of SLA, all of these components were fairly reliable, but none of them were 99.9 or whatever. They were all sort of 9899. And when you accumulate that over 13 components, it drops down super quickly. I don't. No, the curves off the top of my

head. I have them saved as an image on my desktop as well because I refer to these all the time. But it drops down to like 70% or something like that very very quickly. And the team was really confused because all the individual components were fairly reliable, but they were having, you know, hours per week, hours sometimes days per week where the system was down, and the easiest thing.

To do in that circumstance was actually to remove components because you can say, well, I need to make all of them more reliable, but then I've got to make 13 components 1% more reliable. That's hard, but it's an instant win by removing four of them. And so these are things which come with experience, I can imagine. Yeah, to have that as an option, right?

Because probably the first option, the option that everyone talks about, is to make every component or the component with the biggest bottleneck make it more reliable. Yeah, right. But to have that outside perspective and be like, listen, this chain of components is not doing us any favors, basically. Yep, we need to make that chain smaller, right? Get from the source to where it needs to be faster and then reduce kind of that risk in

between. Yeah, and we were also having problems with latency and things like that. So this was. One of those times where you see there's a solution that solves multiple, multiple problems at once, and to be honest there that they would, they're the most fun. Yeah, right. I mean that was the complexity. Well, yeah, because people say what do you look for? And elegance is what you look for. And that's an example of elegance, where something simple solves multiple problems all at

once. Yeah, I want to get into

elegance. But before we do, you mentioned kind of having those discussions where people think they're an expert, right? And I I I don't think everyone thinks that. But I do see kind of I recognize those situations where people just disagree because of their fundamental understanding, which is different, right? Huge. Challenge and even when there are multiple options on the table, right, with the 13 components, we can either tackle the biggest issue or reduce the

components right? Those are always options on the table and no one's gonna tell you which option is right versus what is wrong, right? It's always gonna be a decision, a discussion. Then we commit and we try it out and we reflect and we see if it's right or wrong. How do you handle those discussions right? Do you have like a tool for that? So they are the most difficult ones because these are people

problems. Yeah, the technical stuff's easy and these are people problems, which is often a huge often in modern. Engineering the biggest problems that you're solving are actually people problems and so that is a big issue. So first of all we so I'm very technically minded, so I will bring technical tools to the table whereby identify where is the problem coming from because unless you identify the problem it's hard to fix.

It's often in that situation very difficult to tease apart which factors exactly are contributing to it? But often indeed, it's a fundamental outlook on how thing not not so much how things work, but what you value. It's a difference in value systems. So some people will value the hyper fast, get things working

today and fix them tomorrow. Other people value well, once it's working, I just want it to work on autopilot for the next 10 years, recognizing that there's these different value systems driving their points of view. It's super important. Aligning them can be quite difficult, And I mean we want to avoid a monoculture of everyone just having the same opinion at the same time. I yeah, so diversity is useful in the discussion.

You can bring in extra perspectives and so forth, but there's a bit of a false equivalence at play because.

This is going to be a bit political, but not all, not all opinions are equal. Not all, not all opinions are actually grounded in the same evidence or the same fundamental truth behind them. And at the moment what you often see is everyone thinks, well, my opinions just as important as yours. And from a point of, from a emotional point of view, and from a people point of view, that may be that may be true, but not always from a. Accuracy or making a decision point of view.

Now in a very hierarchical sort of culture where you've got a boss that says their opinion is obviously more important than the people that work for them. Here in the Netherlands we often have very flat structures and also people working for a manager of boss are normally quite open to telling them, telling their boss their opinion, the real opinion. Which is refreshing to see. But sometimes people don't realize that, you know, not all the opinions on the table are

actually equal. And that's I know that's going to be, that's to be controversial to say, I mean. Because how do you decide which ones are and which ones aren't? That's a whole different problem. But yeah, it's difficult. I understand what you're saying, but I don't think everyone thinks their opinion matters as much when it comes to kind of those technical decisions,

right? Because I've also been in teams where we had to decide and for example, someone was new or someone thought they had less experience than other people and they said I I don't feel comfortable to make that decision. Like this is my input. Yeah, like I want it on the table. This is what I think and that and that discussion.

And that's good to see because to be honest, I mean, you don't want to be browbeating them or just just overriding opinions with power or whatever the case may be. Yeah. And that's why I say it's a bit controversial, but sometimes some of the opinions will be. Better informed and higher quality than others. And not everyone around the table will recognize that, Yeah, and that that's normally what leads to tension.

Because if you're right, if someone says, you know, I I happen to think this, what do you think that's different to? I don't. My way or the highway well or I don't see why we don't just, which is a bit as similar to my way or the highway, but a bit more passive aggressive. Exactly. Yeah.

Yeah. I I. Those are really hard discussions. Yeah they are. And they and they're people problems and and they they're the hardest ones and they're the they're the hardest ones to solve. In many ways these people problems we think they're new but they're not. And you know in our, in our industry, one of the, I'm not going to say bibles, but one of the books that people often refer to is the book The Mythical Man Month which is a collection of essays.

But if you, if you read it, a lot of those essays are about how you organize people to work together on software. And in in many ways they're a reflection of how Fred Brooks in the 70s was trying to solve these problems. So they're not. They're not new, but. They're still, they're still there. And I wonder, I think we're, we've gotten a bit better. So when you go back and you read it, you think OK with modernize, how many of his ideas do you agree with versus disagree?

How much of it stood the test of time And some of the some of the ideas in there, I still think, OK, there's still potential there. We haven't quite exploited that.

Yeah. I feel like as long as we have patience in those discussions and kind of that that openness and willingness to learn because for me, one it might be my core value is I have to understand, right? If I disagree with you, then at least I wanna understand that why your option is better or why we think that that difference is there. And the way to do that is to have patience and to have that discussion in understanding. Yeah, and that is from my point of view.

From the other point of view, there might not be time or I might not be able to understand Even so this is definitely true. It's also about respect. So sometimes I will say decisions being made and I don't understand them, but I respect the person and how they've made decisions in the past. So often those two go in hand in hand is respected something that you build up over time or so there's an issue, you start the door with respect, sometimes you lose it, but often times, yeah.

So I need to be able to respect the decision, yeah. Is what I often find and that's often what you see in the in the in the smaller close up situations. It is actually a lack of respect that people have for each other that's leading to the tensions and the problems.

That's a shame. If you if you allow that other person without understanding to make that decision by virtue of trusting them and and respect. If that decision turns out to be wrong, do you then lose trust and respect or but? Obviously it depends, but it it does kind of contribute to that. I think it might not after one, right? Because often it's something that's that's built up and accumulated over time and everyone makes mistakes.

To be honest, what would make me more concerned about it being wrong was if the lack of reflection. If it's a decision that was made and it was wrong and I didn't care, yeah, that would be a. That's painful. That would that would be painful. But if they're like, yeah, I for example, I had to choose a, you know, I had to choose a color for the bike shed. I didn't know that the blue paint's all wrong. Yeah, you know, that's fine. That's where maybe understanding helps. I can imagine.

Have you found yourself in in those positions as well? Where you were the one to make that decision, which in the end turned out to be maybe not the best one, maybe an incorrect one. And how did you handle that? Definitely. And it's, it's difficult. That's what, That's very humbling. Yeah. Because you instantly start thinking, well, at least I instantly go back and think about all the cases where I've had other people do that.

And I think, okay, there was a lot more going on that maybe we didn't understand at the time behind these decisions being made. And you're right, Absolutely, absolutely, constantly. I've got a current stupid example. I've got a current project where it's a legacy code base. It was developed three or four half lives ago in terms of people on the team, and back then the coding style and linting tools and stuff that we

used were very different. And so I thought, the first thing I'm going to do is I'm just going to bring it up to date, and that's been a colossal waste of time. I've done that before as well, actually. Colossal waste of time and I shouldn't have done it. Yeah, but you know sometime in the moment you think, yeah, this is the right thing to do, but know that so constantly mistakes. Yeah, happens. How do you did you communicate it in that way to your team as

well? Like this was my intent and now I realized because of XY&Z that it was a waste. I'll I'll let you know tomorrow. Stuff to do it or or maybe when they watch this. It'll be out next week actually. OK then I better tell them before then. That's really funny because I I really love what you said in the

way that people reflect, right? That shows me that they understand what had happened and that they learn and grow from it. Because I don't want someone to not learn and grow from whatever they're doing right? There's a wasted opportunity in my opinion, yeah, definitely, yeah. Definitely.

If you make mistakes, then reflect and even communicate that you are aware and you're growing from this and we're learning from this and it also shows to others that obviously everyone makes mistakes because it's always going to happen. I feel like, Yep indeed, very frustrating. Very, very frustrating. Obviously, absolutely 100%.

I want to get into. Kind of or back to rather how things work, because I feel like the knowledge you have kind of compounds, right. If you drill deep down into how things work over and over and over again, I feel like you have kind of this compounded knowledge which is very valuable in understanding the next thing that comes up, you're right indeed. So the bigger, the bigger or it's basically your own little private knowledge graph.

And the larger it is or the more diversity is, the easier it is to hang new ideas and concepts on it. And that means that picking up new technologies becomes in some ways easier because you've seen it before or you've seen something similar. But in addition to having the knowledge that the real trick is the pattern recognition.

When you see something new or when you see a concept here recognizing that it's a parallel to something over there and taking something from one domain and knowing that it's the same in a different domain and that that actually always that sort of multi that cross discipline, that's what that's I find that super interesting. Yeah, right. Because there's just so much we can learn from how other people

do something. An example, I've spent my last few years in the adjacent to machine learning and AI where we where we build models and things. And I had a client a few years ago where we were dealing with weather data and some of the things that weather data and forecasting in particular is one of the original computational use cases for modeling and basically doing inference weather forecasting, that's what it is. And they've been doing it since 50s or 60s.

And you can tell when you work on it that it's a very mature. In some ways it feels like a different world. But there are certain things and concepts that they used to describe things where I think hang on a moment, we need that as well. Or I need that. I've got that idea and problem, the words that we used to describe things over here, they've got them over there and I think okay, that's super useful. And this happens all the time. Yeah.

When you, when you're starting out with programming, people often say you should learn several different languages of different styles. And that's partly to sort of fertilize this ground of how people do things in the idioms in one language teach you, and inform you better about how to do things in a different in another language. Do you agree with that kind of train of thought that to go kind of wide and deep at the same time?

Yeah, yeah, definitely. Sometimes it's really frustrating because you'll arrive on a on a project with a bunch of people that haven't seen this other language and you start typing things out and they're like, what what planet is this guy from everyone's seen? Or often you'll see π thing being written by C++ academics.

It's very different style, the idioms are different and so forth, so it's not always good, but at the same time there will be concepts and ideas that they bring over and the transfer which enrich the field. Interesting. Yeah. For me, it was kind of going back to that compound knowledge that you have in in understanding how things work. Because I didn't have a computer

science background. I I did kind of it's called business. What was it called? What would I study again? I I know it in Dutch, I guess. What's it in Dutch? Informaticunda, which is kind of information studies or information science. It's the art of information. And in there we had like business theory. Yep. On certain business cases, as well as partly computer science, but it was more so data science. Yep. So we did a lot with Python, had to build a web shop as well.

So that was like HTML, CSS, but it was more so teach yourself how to do it with Python. We got more guided lessons in that way. So then I came out of you and I went into operations. Because I was like, OK, this is a broad field for me, kind of in the tech domain. I can pick and choose what I want to learn and I still had no clue what I wanted to do. And from there I grew into the development team over at next to where we had CBS consultants.

Even so their job was to teach me, which is amazing basically because it was obvious I had never written production code before. And for them it was like, OK, well this is git, Have you ever used it? Well, no. This is how it works. And. Just go on the back end and view on the front end and that was kind of where my journey started. And because of that I felt effective, right, because I was guided pair programming, I could see what I had to do and I could do it even.

But at some point where I had to do it more so on my own or later throughout time, I would think it would be easier or quicker. But then I would fail in kind of delivery speed to myself because it was my own expectations. But then I reflected and I was like, why is that? And I realized that. Because of that trajectory, because of the on the job learning, the practical experience, I had maybe more so a lack of fundamental understanding on a lot of core

concepts. And because of that I had to backtrack or I had to Google a lot more. I had to ask more questions because I kind of didn't have that solid foundation that maybe a computer science degree would have or maybe that some like other theoretical background would kind of give you. Or just my path was different than others, maybe even my interests? But I feel like in understanding how things work. That's where it starts, right? A solid foundation and then you

build up from there. Yes, definitely. And it's hard. And I believe that in education

this is a big debate top down versus bottom up. Do we start off with the high level concepts and then drill down as necessary, or do we start with the low level concepts and build up? And my own experience there is that the bottom up is incredibly frustrating because when you're doing that, you don't understand where the destination is. Why am I learning all these pointless things? I see that with my kids today in math, they're like, why do I

need to learn all these things? Because they don't yet know that these are like the building blocks for later on. Math is a great example, yeah. And so you you see some degrees where indeed they start at the high level and then drill down and others that go from the bottom up. And I don't know which is better because when you start at the bottom up, you'll lose a lot of people because they don't find

it interesting. Whereas if you start at the top, maybe it's more interesting and engaging and therefore you end up with a bigger group of people. And not all of them will want to drill down, but some of them will and which ends up being better. I don't know it it's yeah, I wish I didn't know that. I don't think there's a right way in any case, because some people will find kind of that lower level, that deeper level, maybe even as a starting point, I'm not sure.

But it is fascinating how things work to start off from kind of bottom up and to build that and kind of compound that into what you see kind of on a higher level. Yeah. So what I will say is that when you're doing the high level stuff, you can sort of get into a mindset where you think I don't need to know these details and I'll drill down when I need them. That sounds like me sometimes. Well, sometimes. So it's sort of like on demand learning, and that can be

useful. But I sometimes find myself in that mode, especially when I'm in there, in a domain where I don't fully understand what's going on. And what I always find is that there reaches a point where I have to say I need to stop this. I need to spend some time where instead of just doing this ad hoc, I need to actually step back and learn the base, what's underneath so that I can then come back to the top level. And that often happens with.

So at the moment, when you're dealing with machine learning and the AI stuff, that happens to me a lot because I don't have the modern background in a lot of the machine learning and data science fields. And so often I find myself working on something and I'm like, do I need to know this? Not yet, but I can feel it coming. And then at some point, something breaks or it's not

working properly. And then I've got to step back and okay what's it doing and then spend a fair amount of time doing that, going a layer deeper. And sometimes it's perfectly fine with that ad hoc learning because often you don't need to. Sometimes you can make it through and you're like, OK, that move on to the next thing. Yeah. But yes, recognizing when it's not quite cutting it right now that that's also that that's

also important. I was going to say for me personally, that's very challenging because I feel like I'm effective and then at some point there's a point where I'm I might not be or. I get a different perspective. And they're like, well, fundamentally we can do this differently. So the thing we've been compounding on kind of radically needs to change. And then I'm like, OK, yeah, so this understanding, it makes a

lot of sense. So I liken this to the parallel that I'm gonna draw from another area is this is like unit tests and automated testing. It costs a lot of time up front, yeah, but every time it pays for itself. And when you start, when you work on a code base, if there's not the tests there, you're like okay. I can, I can adjust it here and there and I'm pretty sure it's going to work. But then at some point, those changes you're making, you have to test them manually.

And then at some point you're going to say no, I need to sit, I need to step back, spend some time doing the fundamentals so that I can go faster. And with this knowledge, it's a it's a similar thing recognizing early enough. Okay, I'm going to be spending some time here. I do need to go and figure it out. Figure it out. Yeah, you can imagine with a new

concept, right? And I think it's hard to imagine because of kind of this compounding knowledge, but with a new concept, how would you start kind of figuring things out? That's a really tough question. Yeah, I don't know because it sort of feels automatic and organic. You start off and it depends on the field. So for example, if it's a framework, what you're going to do is you're going to look at the examples and you're going to look at the, you're going to

read the documentation. If it's a language, you're going to go through the intro guide. But before you go too far, I'm going to go and read the reference. So that's for those things. If it's more academic, it can be quite hard because you don't know the depths of the ocean you need to explore and I don't have a good answer there. Colleagues are useful though, because hopefully they'll be an expert in in the field and that's luckily something that which we've got enough of here. Yeah.

And it's been quite normally I can find someone, I can say, hey, I don't quite get this, explain it to me like I'm a 5 year old. Yeah. And then and then we go from there. Very helpful. Yep. Yeah. Is it from your perspective? I think this is a personal opinion when you have to go deep. Is it? Also, is it an I want to or sometimes also like I have to like? Is it discipline? I'm looking for the excuse. That's me. No, I I enjoy that stuff and I enjoy the low level details.

So for me it's normally not. Not a huge challenge except for anything to do with JavaScript, so I don't. That's the must, that's definitely a must. But no, I I like, I enjoyed learning about new things. So for me it's not a challenge. The challenge is finding the time. But you know, normally what I find is that most people are understanding if you take the time because things afterwards go so much faster. Yeah, exactly. And getting getting the creating

the room. To do that, sometimes you've got to be a bit, you know, forgiveness is better than permission. But until now, it hasn't been a challenge. Yeah, at least that least, not that I've heard from. No, Yeah, I can imagine. I mean that's that goes down into kind of how much do you

take time to research? Instead of making the decision and kind of doing the thing right, executing it that way and delivering. And I think it's it's very much having to do with the business that you're in kind of the phase there as well and what needs to be done. And if you understand, kind of if you're if your own a lot, if your own interests align with the business interests as well, that's where you kind of find a stride. But where it conflicts is also where you have conflict.

Yeah, deadlines and competing priorities. Yeah, Massive Challenge is an industry. We haven't dealt with it. No. Are we going to think? I don't know. I mean, we're a fairly immature discipline compared to a lot of the engineering disciplines in particular. They've got a much longer history, some of them longer than others. You could argue that the nuclear industry, for example, is not much older than the software, but also spotty record as far as safety goes.

So I don't know a lot of the problems that we deal with, the people problems and in what's interesting is if you look at some of the industries where they have solved, where they have solved a lot of problems in a very short amount of time. Recognizing the people problems has been a fundamental part of the journey. In particular, if I look at the airline industry and safety, yeah, that's I'm going to say roughly twice as old as software engineering.

But if you look at how they approach problem solving and dealing with issues, I mean it's about life and safety. So that's that tends to focus minds. A lot of what they do is about recognizing that people are human and how to cope with that. Yeah, whereas in software we haven't quite gotten that far. The other thing that makes our

industry a little bit different is that a lot of the time when we're building something, the reason we're building it is because it hasn't been done before. If it's been done before, someone's turned it into a product or a library and we're buying it most of the time.

And so that means that solving the problems of how long things are going to take and all of these people issues, I don't know how easy it is to solve even in, I mean if you're building houses or something, right, not every house is the same, but a lot of them are very similar. But if you look at the effort that goes into planning a house that's architected, that's a lot more than that goes into something which is just being copied over and over again.

That's as close as I can get to sort of examples where people may have solved these issues in other other areas. I love that example. Yeah, because in software we do build kind of similar things, some well more well architected than others. In that way, yeah. And and and it's, it's tricky. So most of the projects that we're working on should be closer to an architected building, which is a one off versus a cookie cutter bought off a plan or something like that.

Yeah. Well, So what I wanted to mention is that what also makes software different is that we haven't yet figured out the integration complexity. So when I look at these other industries, they've got standard solutions for how you combine the components and things. So if you're if you're a builder, the way you, the way joints are made and the way the different independent systems interact is standardized. We don't have that in software.

And sometimes you work on a project where you're building from scratch doesn't actually exist anymore. But let's say we've got one end of the extreme where you're building from scratch another way you're taking five or ten existing things and plunk, basically mashing them together. Pure integration versus development. Often in our industry at the moment, the complexity of that integration can exceed building it yourself and that complexity of integration is a is a huge challenge.

Most all the big software projects that we hear about failing are typically integration related efforts. Interesting. They're not building, they're not building these systems from scratch. And we brings the loop kind of around because is it a people problem that led to this integration failure? But that's something that struck me and I don't know what the solution is. No, I'm not sure if I've realized that actually. That those are kind of two extreme ends, but they are kind of.

I do recognize them in previous projects, so nothing, nothing is from scratch in isolation anymore. I mean Once Upon a time you could wire wrap a CPU together that's from scratch, close. Whereas these days everything is using existing components and libraries.

What you get these days, Sorry, even 15 or 20 years ago with the Java runtime library, that was a massive step forward compared to what everyone had in the, I'm going to say in the 90s where people would build their own hash tables and things because that didn't exist. Whereas these days, who thinks about that? Yeah, So, yeah. In that way, we do have kind of standardized like like it's a combination, I guess. Yeah, some stuff is standardized

and some stuff is so custom. And if we integrate that, that is where the complexity is, yes. Yeah, yeah, definitely. So the challenge, I mean we're seeing this play out again now with the modern microservices based architectures and that's sort of replacing everyone trying to do it in one big monolith. But it's still it's still an integration challenge. Yeah, exactly. I want to, because that's kind of a final topic.

You mentioned elegance before in this conversation and in previous conversations as well. To start off, kind of. What defines elegance to you? Because I feel like the people I've talked to, they make it very subjective, and it's sometimes very hard to pinpoint them what it means as kind of an overarching topic. I can describe some of its properties, yeah, but that's not necessarily fully descriptive. But that makes it easier, I think, Yeah.

So some of the properties, when you say something that's elegant, it's something that's obvious once you've seen it, but before you saw it may not have occurred to you. So there's an asymmetry to when you've seen it versus when you haven't. It also tends to be something which solves multiple competing concerns at the same time, and it tends to be simpler than the problem it was solving.

So that removes the complexity. Something that in one step eliminates complexity and solves multiple competing constraints. So the way I'm a fairly visual person, but the way I visualize a lot of these constraints is you're trying to find a path around the boundaries of what the constraints impose. And sometimes you'll end up with lots of things all sort of converging on a single point, and that point is where the

elegant solution might lie. That's a very abstract way of putting it, but for example, there's a snippet of code which someone once posted to do with how I think it was. A Google engineer came up with persistent hashing algorithm and it was only three or four terms. It was certainly less than a line, but it solved so many problems to do with persistent

hashing. So persistent hashing is where you need to divide data up over roughly equal compartments, and that equal compartments has to remain equal irrespective of the distribution of your data. So it tends to be hashing of some sort. And one of the challenges, what happens when I want to change the size and number of compartments and a property that you want is that things don't move unnecessarily between compartment between

compartments. And this algorithm had the property that it solved that problem. And it's it's it's elegant because it takes an area of math and it applies it to this problem and people had spent all sorts of time trying to figure out other ways of solving this and you just think in one fell in one fell swoop they've solved it. There's also a similar. There was also a Python example where I think it was in 10 or 20 lines of code. You had the essence of Google

search or something. Yeah, similar idea where you think someone's managed to find something that's very simple. That just solves all a very wide range of problems.

Would you say those solutions are like, would you call them clever or smart? Because sometimes I see a solution I have to drill very deep into kind of how it works and I'm like, OK, this is smart, but this could still be simpler. Like this is the smarter solution. Let's say it's the same as if I, especially with Python code, if I do everything in a one line versus kind of writing it out

and making it more readable. That's a whole different topic, but I will say it needs to be understandable. I think that's where I stand on that, because occasionally you'll see very dense solutions and they appear compact, but they're not necessarily elegant because I think you need to recognize it. And that's annoying because it means I can't make something elegant. Other people have to judge it as elegant. And yeah, so yeah, I don't really, yeah, it's it's hard to

describe. I can imagine, yeah, sorry.

And in in kind of your day-to-day work, right. How much of it would you say it's kind of that is? Elegant code or elegant output in what you're creating? How much of it is kind of less than I'd like? Less than you'd like. Well, so the thing about elegance is that it doesn't always come to you in a light bulb moment. You've often got to spend some time exploring the space, and you don't always have time to do that. So I'd like things to end up elegant, but I don't always have the time.

How is accepting that actually that sound was the perfect description? That's how it is. That's how it is. No, indeed, it's. You just have to accept it because we don't always at the time. And it also takes a while to accept that not a messy problem doesn't always have a clean solution. Sometimes the solution to a messy problem is a messy solution and you just can't get

around that. Yeah, we used to in high school when we're doing math, they make the examples that you have to do. They make them so that the working out is nice and easy to follow and you end up with a simple answer. Yeah, the real world's not always like that. Absolutely not. And recognizing that, I'm not always going to get a clean answer from when I have to solve a math problem. So it's the same in this area and and sometimes you just go to say well. That's it.

That's it. Yeah, I get that in in kind of visualizing you mentioned that. Kind of.

You were drawing out for me at least multiple lines, and when there was a converging point, that might also be where most complexity would be and where an elegant solution might be most effective. Do you take time in kind of being like, OK, these are critical decision points.

We have to make these decisions and kind of the solution for that might need to be more elegant than let's say, the messy solutions we have elsewhere, just because of the factors involved, the risk there or the value to be had, even don't know. Those are abstract, I know. No, it is. But I haven't really thought about it and that's a tough one. Yeah. I I don't. No, I don't. I don't really have an opinion on that yet.

What I what I will say though, is that sometimes it sounds counterintuitive, but sometimes you would do want to back off from the oversimplified and elegant solution. Sometimes that can make things harder for yourself just because of other people being able to understand it and follow it and change it and modify it. That's just a. That's a. That's a hard thing to explain, but. No, I understand, because for me, especially at those points right where I feel like this is

a crucial decision. I don't want any unnecessary complexity in solution we're creating. I want things simple. I want it to be able to be understood by the team basically. Because if we don't understand this crucial part, I see it as kind of a foundation in knowledge in the thing we're going to build on top of. So in that particular situation indeed you're talking about, I've got a solution to a

problem. It needs to be understandable to me, but more importantly, it needs to be understandable to the team. And the third thing is that it needs to be resistant to changes in the wrong way. That's the thing. So you want to make sure that whoever comes along next, you want to make it easy for them to modify in the right ways. And that's hard, because what's the right way? You don't know that yet.

But you do want to make sure that they're not going to accidentally make a change that breaks it. And sometimes that means your small, simple solution needs to become a little bit more elaborate, with checks and defensive mechanisms around it and tests and things, just to forego the possibility that someone will accidentally break it. And that in some ways is less

elegant. But it's a practical sort of thing that you need to do because, yeah, I mean, if something looks innocent, you might It's very easy to accidentally break it. Yeah, done that many times. That's I think that's a great perspective to have one I hadn't thought about. As much yet, but I do see that

also we joke when we're writing code about who's the audience, right? And there's several audiences. The 1st is obviously the compiler, it has to be correct for that we focus on that. We also talk about our teammates and reviewers. If you've that these days is often the bottleneck and code going to production, the review and process of your teammates also understanding it. So the second audience is your teammates, but there's also a

third one and that is future. You or teammates need to also be to be able to understand it, understand what you were concerned about versus what you were not concerned about, so that they can safely make changes without breaking everything. And those additional audiences? When you're writing code, they're not always obvious at first. You're mostly focused on making

it work. Yeah, I mean more and more as I've grown, let's say, more senior in into kind of this role in creating software, that last audience for me has gotten significantly more important because I try and fit in as much context with my commit messages. Yeah, specifically, they have a format, they have a convention. Even the references to whatever JIRA and context that was in there is also going to be in there. The pool requests are in there. I try and pay more attention to that.

Like, way more attention to that than very early on code. Because I know that I'm gonna look at this, other people are gonna look at this and I might not even be there anymore. And even when they are gone, more people are gonna look at this. So as much context as I can give them to kind of help them along the way, I think that's very important. It's kind of the longevity of the system and the changes that are gonna iterate and compound over time. Yeah, you can judge it.

You can see it instantly when you look at code, by how many comments there are and what this style is. At some point you'll start seeing and creating little essays all over the place that explained I was here, these are these are what I found. The code assumes this. I chose this because of this, this and this.

That's why it works this way. You end up with these little essays sprinkled through the code at some point, and then, you know, two years later you come back and you're like, okay, thank you past me. Yeah, I got this now. On that note, this was a blast, Andrew.

This was a lot of fun indeed. Thank you very much. Thank you as well and kind of laying out how things work as well as elegance. Is there anything that was missing that you still wanted to add before we round off? Not really. I mean, so I mean, we've covered, we've covered quite a bit. So I don't think anything springs to mind. You've led me through the various things. You've helped me a lot, fairly, fairly well. There are lots of little anecdotes where I think I missed

that anecdote. I missed that little anecdote, but I'm perfectly fine with. That Awesome. Cool. Then I'm going to round it off here. Everyone, thank you so much for listening. I'm going to put all Andrew's socials in the description below. Reach out to him, let him know you came from our show. And with that being said, thank you for listening. We'll see you on the next one.