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