Hey, Ben.

Hey, Matt.

We are reaching new levels of complacency when it comes to recording an episode here because we haven't got a clue at all about what we're doing today.

No.

No.

But that's never really stopped us before.

No, it hasn't.

And it's not stopping us today.

I'm going to ask, how are you doing, my friend?

It's been a little while.

It's been, it's been a busy few weeks.

It's been a busy few years.

Last week was a busy year.

Uh, the, uh, just, just lots of new things happening, new stuff happening, new things being built.

Hopefully exciting and interesting new things.

Yeah.

Yeah.

It, it, um, you know, I have the privileged position of working in new projects, which most programmers will tell you is a much better alternative than many other things.

Right.

And as the listeners of this podcast are well aware, I have many strong opinions on the right way to do things.

And, uh, being, ah working in a new project allows me to...

..work in the manner and to which I am accustomed, which means i am being very productive, right?

Like I'm able to get a lot of things done because, I don't have to relitigate all of the development practices and tools and things.

It's just like, Nope, we're just gonna do the stuff and we're going to do it right.

And we know how it all works and it's all pretty straightforward and simple.

And and the whole point here is just to do it as fast as you responsibly can.

And so that ah is fun and rewarding, but it's also a bit tiring.

Right.

Right.

But that's, as you say, having the ability to set a project up the way that you would like it to be is powerful.

huh

And potentially as you say, potentially gets you to go very fast, lets you go fast.

You're not limited by...

Yeah.

..I mean, I guess other people, other people and their choices that maybe you disagree with, or what do you think is it?

Is it, is it, I mean, obviously I don't think you are so big headed to say that your way is perfect and everyone should do your way.

Although, you know, I agree with most of the things that you say, so maybe it is, but what, what is the, is it monoculture?

Yeah.

Yeah.

Is that the...

You know, i I really like the exploration versus exploitation and dichotomy that some people talk about.

Yeah.

Yeah.

you know It's like, should we continue evaluating options or should we move forward with the option, the best option of the set of options that we've considered so far?

right

Right.

And you know I think one of the advantages of experience is that you have made a lot of mistakes and you have evaluated a lot of options and you have determined which ones tend to pan out and which ones don't.

And therefore, ah you you wind up with ah some thing.

There's sort of like the old bit of like, if an old engineer tells you that something can't be done, you can look at them with a little bit of skepticism, right?

They probably know some things, but you can look at them with a little bit of skepticism and kind of ask the question like, are you sure?

Yep.

But if an old engineer tells you something *can* be done, because they've done it before.

Well, that's a very different claim, right?

Yeah.

that's That's a really interesting difference, actually.

Yeah, I see that..

Yeah.

yeah

Yeah.

But yeah, so you're you're sort of sort of drawing from experience and saying that these things have worked for me.

I have explored the space because I've been doing this for 30 years and I have a pretty good idea.

Doesn't mean to say that it's a perfect idea or there aren't better ideas, but these ones have been shown to work.

Right.

And now I am choosing in the sort of 80-20 theory of ah ah explore 20% of the time and 80% of time take advantage of the things that have proven to be well.

You're in that 80% section at the moment.

Yeah.

Which, yeah, the restaurant ordering dilemma is how I think of this, right?

Yeah.

I go to my favorite restaurant and I look down the menu and there's that thing I like.

And I'm like, I really like this thing on the menu and I will enjoy it every time I come here.

huh Yeah.

Yep.

But there are some other things on this menu too.

Should I take the risk that it's not as good as the thing I know I like?

Yeah, yeah, yeah.

And think another interesting dimension to this problem is that, um you know, I'm being paid to do this and I'm being paid to deliver results.

And what I'm not being paid to do necessarily is learn a bunch of cool stuff, right?

Like, you know, it's fun to learn a bunch of cool stuff and it is sometimes very productive and useful to your employers to learn a bunch of cool stuff.

And then yeah, right.

Indirectly through you and through your proselytization and sharing of experiences and setting the...

Yeah, right.

Yeah, yeah.

But ultimately, it's an investment in your yourself, independent of your employer.

And sometimes that can be purely for yourself.

Like, you know, we've all we've all seen this.

Right.

I think we've talked about it before.

It's like, hey, some cool new programming language has come out and some programmer goes off in a corner and says, I'm just going to write this new little tool that we needed.

And we're going to write it in Haskell because I've just read a book on Haskell.

Right.

And you're like, that's, I don't know that this is in the best interest of the business.

Right.

Mm-hmm.

Uh, there's a, I guess, you know, you roll your D20 and if it's a 20, somehow now Haskell is the best thing in the world and everyone moves to Haskell and the whole company levels up, right?

That's a possibility.

But very often what happens is that that piece of code gets orphaned and becomes the haunted graveyard of "we don't use that tool anymore."

Yeah.

Right.

But you know, your friend has been and learned Haskell and has gone off to do something else or whatever.

right Right.

Right.

They got that job in Haskell that they wanted to get, right?

But, you know, you have to have an understanding employer to let you do those kinds of things or, you know, or be in-between jobs.

that

And then you get the choice of doing it any way you like.

I was just going to say, this is like your every day right now, isn't it?

At the moment, I get to choose pretty much what I want to do.

Yeah.

And yeah, that that's a whole different story.

That's perhaps one for later.

Yeah.

But yeah, so where were we?

We were talking, you were you were saying, yeah, I've distracted myself.

Oh, yeah.

No, I mean, I just sort of like, I really like the model of sort of exploration versus exploitation and being, ah you know, or exploration versus execution.

I don't know what the better way is to describe that, but

Yeah.

But it's either like, you know, are we are we evaluating different ways to do things or are we doing things, right?

And I think being responsible with that gives you, um you know, sort of like the freedom that comes with authority, right?

Like, I'm going to be responsible for making this decision and doing it in the best interest of the company and ah because of that, I'm going to expect people to trust me to make the right decisions.

And then that means when I decide like, yep, we're doing this in Java and with tests and we're going to do continuous deployment and we're going to do all these things.

Like, it so long as the result of that is that I deliver working software that benefits the people who are paying me, then no one's gonna ask any questions.

They're gonna like, great, thanks for doing that.

And if it's like, you know, why is this taking so long?

Or why do you continue to have problems?

And my answer is, well, our continuous deployment system has some bugs and I haven't quite worked out all the ways in which this integrates with Google Cloud yet.

And like, they're gonna be like, okay, but why?

Why are we doing this, right?

Why didn't we just do this in Python like everything else is or whatever the equivalent is?

Yes, exactly.

Right.

Right.

Yeah.

Or whatever it is, right?

So this is absolutely the kind of thing where, yeah, you have chosen to sort of stake and spend some of your "reputation points", ah your goodwill budget with the rest of the organization say, "I believe this strongly is the right way to do something." And you know you've got your evidence to back it up.

Yeah, but I'm doing that I'm doing that anyway, though.

it Just by embarking on this ah this ah responsibility to build this thing, I am staking my reputation.

And the only question is, what outcome am I going to get, right?

So like you know if I say equally, if I say...

There's not really a nobody got fired for buying IBM effect.

Right.

Really?

Right.

It's like, ultimately, ah in some ways it's worse.

It's sort of like, okay, well, if you're going to do, if you're not going to have any strong opinions about how to do things and you're just going to do things the way that, you know, the more senior people around you maybe say to do, or sort of like the, you know, the, the, the sort of default path of the, of the company, like, you know, people going to also still...

...correctly expect you to get things done.

And if you aren't effective at getting things done that way, it doesn't really matter.

true

Right?

So like the thing that really matters is like actual running, working software and production and how you get there can be a matter of opinion and can be, you know, a matter of even experience, but the, the proof is in the pudding.

So like just doing it this the standard way does not absolve you of the responsibility of doing it.

Right?

Right, but it does meaningfully change the way that it's perceived, I think.

Like if you were just to do it the "obvious" way that everything else is being done, then as you say, it's like the IBM, no one that got fired for it, right?

You could, there's a defense in not delivering that it was just like, okay, this was just a difficult thing to do.

And there's not like an approach that I pulled out of left field that might be scapegoated, perhaps, as to why it wasn't, the software wasn't achieved, right?

I could imagine, for example, you know, like the Haskell thing here is like, you know, if you succeed and you did it in Haskell, maybe you get the free pass and then everything's better.

But if you if you screw up because it wasn't possible to achieve it, people will latch onto the fact that you wrote it all in Haskell rather than you did it the same way that everyone everyone else is doing.

Is that...

Yeah, I mean, I can.

Am I too pessimistic?

I suppose I am seeing here, and I'll be honest with you, some parallels with decisions that I made a few years back in in the way that I chose to develop some software.

And they that did come back to sort of sort of haunt me in terms of like I staked quite a lot on something.

And that was ultimately not the right way to go forward.

And I agree with that.

But it did I did have to bear those consequences, as you do when you take responsibility.

Right.

That's that's just what happens, right?

Yeah.

So I suppose I'm a little bit like, "ooh".

Yeah.

I mean, if if things don't work out for the best, there's you're definitely going to be able to find a reason why.

Right.

and that And that reason why can easily be because you decided to do things your own way and not the standard way.

I'm not saying that's not possible.

Of course, yeah.

But the i feel you know i've I've used the metaphor many times of running across a lake.

And, you know, software development is like...

but Like the Jesus lizard, yeah?

Have you seen this that lizard?

i I don't know that I've seen that particular lizard, but I know that there are lizards that run across...

It's called the Jesus lizard.

(Editor's note: it's really called the "Common basilisk" https://en.wikipedia.org/wiki/Common_basilisk)

Really?

It's amazing.

It runs across water.

And I just...

I love that someone was so blasphemously naming things that they were like, this is...

this is I mean, it's like, as soon as I said it, you knew what it was.

Yeah, right.

That paints a picture, I'll tell you.

um

But anyway, yeah, so you're a software engineer, you're running fast and you're not falling into the lake because you're just keeping going.

yeah Right.

Right.

And, and there's, I think, I think there's a lot of value in kind of, um, and this was a ah lesson that I, I learned, uh, relatively like halfway through my career when I was, we have an episode about, you know, bad business models and starting a ah company.

Yeah.

And you, you may, I may be told the story in that podcast, but for, forgive me, listener, if you've heard this before, But I remember having a conversation.

We had formed a small company within the consulting organization I was working at.

And i um we had all these plans for taking this open source project that we have and closing it and then selling it.

And I had come to like the first or maybe the second board meeting with a long list of things to do if it doesn't all work out.

And it's like, OK, well, we can reopen the software and then we can do this and we can you know release this thing.

We do this.

And the a person that that was the CEO of the consulting firm and was on the board of this little internal company was like, Ben, stop.

Whoa, whoa, whoa.

If you figure out all the ways in which this is going to fail, you're never going to have time to succeed, right?

Ha ha ha ha ha!

Like you you have to focus on how you're going to make this work, right?

And so the kind of analogy that I have in software development is like – Like planning for like as engineers, we think about failure all the time.

and We think about failure modes all the time.

But I don't think that that type of mentality works as well when you sort of go up a level and you're like, OK, how am I going to organize this effort?

Right.

um You have to think about like, how are we going to succeed?

And so, like, you know, the analogy of running across a lake is the way you run across a lake is you go real fast.

That's how you do it.

And you don't stop for anyone.

You don't stop for doing it.

So you don't want the life preserver and the signal flare and the tool belt.

Like all you really need is shoes - maybe - right?

Like just go real fast.

Right.

And so I grant you that in those situations where you fall in the lake and things have not gone well, if you should, you're right.

Everyone says, well, you should have had ah life preserver.

You should have been where, why the hell did you not have your tool belt with you?

Exactly, exactly.

And your, yeah, yeah, yeah, yeah.

It's like this didn't work because you used Haskell.

It's like, no, this didn't work because we didn't go fast enough because apparently I didn't understand this as well as I thought I did.

Right.

Right.

So I don't know.

And that I grant that that is a very that in itself is kind of like an opinionated view on how to do these things.

It, it certainly is.

Right.

Like and and there are lots of situations in which even I would not apply those principles.

But those are sort of my default principles.

Right.

So, you know, i I don't know.

I, I can, I can see a world in which, uh, I don't want to call playing it safe.

Cause I really don't think that it's playing it safe, but sort of like playing it safe and just doing what everyone else is doing around you is not a wrong strategy.

Um, but I think, you know, at the end of the day, so long as you build things that, that people want and you build them at a reasonable pace and you like, think a lot of this also is just not, uh, putting yourself in a situation where you're just slowing yourself down.

Right?

Like creating a lot of mess and cruft and cruft actually literally cruft that, that is borrowing from your future productivity in the name of, of doing something today.

Literally.

I think a lot of it is also, also that and knowing when you need to fight for that.

So I don't know, i'm kind of off on a tangent here, but.

No, that's good.

No, I mean, certainly, Cruft is top of mind for me as I've been spending the last few weeks you know doing Compiler Explorer things and spending a lot of time regretting decisions that were made 10 years ago that were made...

...And some of those decisions, are it was it seemed like the best idea at the time, and they're fine.

It's just you know they need to be updated.

That's cool.

but many, many of them are like, I didn't really, it wasn't thought through.

And, you know, you regret them.

But then some of the other things are like, well, if this had never scaled to four terabytes of compilers, then we wouldn't have this.

This is a new problem, right?

No one would have thought this, you know, who yeah who I mean, when I speak to people about some of the issues we face,

Right.

right

Oftentimes they're like, oh gosh, I'd never even considered that would be a problem.

And you're like, yeah, no, neither did we.

And now it's a big focal point for us.

It's like, how do you deploy this?

Oh, well, you just copy the bits around.

Well, there's four terabytes of it and nothing in Amazon works like that.

Oh, yeah.

Yeah.

Yeah.

Yeah.

yeah

Yeah.

I don't know that I would argue that those decisions that you made 10 years ago were wrong.

I think, I think the cruft comes in when you are, you don't feel ah safe changing them.

Right.

Like,

Yeah.

And that that is also true.

You know, a lot of this stuff is specifically for Compiler Explorer.

Yeah.

you know, we're a shoestring budget thing.

yeah

We don't have a copy.

We don't have a second deploy that I can play around with, with the sort of big infrastructural changes, especially stuff like, you know, let's just copy all the compilers somewhere else and then poke around with them.

Right.

Right.

I don't, even if I did have, I mean, we have some staging and stuff, but if, even if I did have like a full copy, I could run somewhere else...

My confidence in being able to say this categorically still works, now I've you know moved everything around.

I've changed the file systems.

I've done whatever I choose to do.

My confidence is not very high.

You know I can curl a few things.

right

I can look at...

Yeah, it's it's not straightforward.

You know to and some extent, my own personal usage pattern of the site does not comprehensively enough...

cover all the things it *can* do.

And because we don't have the tests for most of the user interface or even most many of the compiler type things that we do, I'm not confident in making changes.

We just kind of have to wing it and hope, which is not good, right?

Yeah.

you know I'm talking to Ben Rady here.

Yeah.

And it doesn't feel good.

And so some of the things that I'm doing right now, you know like a lot the this with with this is going off on a tangent to your tangent now, but like the things that I'm trying to do now are set myself up for further success by...

Yeah.

Going back and adding types to a lot of the things that were untyped and have horrible casts in the TypeScript.

You know, we moved from JavaScript to TypeScript and there was a ton of stuff along the way that just has, you know, `as any` or `as unknown` because we didn't know what type things were.

And now I'm actually spending the time to go back and put the types in and uncovering all sorts of weird cases where it's like, hey, sometimes we return an object.

Sometimes we return false.

Right.

That doesn't seem like anyone would choose to do that, but that's what happened.

Yeah.

yeah

And then you go and, you know, you pull on the threads.

And so I feel like that helps to make it easier to make changes.

And while I'm doing it, I'm adding tests and even adding test frameworks.

I made a big change recently to move a whole bunch of stuff out of the front end into a place where I can run the test for it, independent of a browser being involved, because most of the code is like, doesn't care about the DOM.

So, you know, you want to test whether this string is a valid descriptor or an identifier, well, then that can be tested outside...

stuff like that.

All of these things, like well ah hopefully, en masse will make it faster for us to go forward in the future.

Oh, yeah.

Yeah, so that is a very tangent to your tangent.

Yeah, yeah.

But yeah, that's top of mind for me is how do I make myself more productive?

How do I get myself into the world where the the the environment gives me the protections I want?

And I think to circle all the way back to the beginning, the thing that you said at the beginning of this was like you're in a greenfield environment where you set it up the way that you think it should be done.

And I think you and I both like that.

You know, I have a C++ template project, which is like, this is all my rules or my Lint rules are set up or my pre-commit hooks are done this way.

Mm-hmm.

You can't, if you make a change to my project and you get it past CI and you get it past the PR, then it should be a good change, right?

There should be no way that you can get it past.

Yeah.

And if it's not, that's on on me.

That's a bug in the infrastructure that let you put a bad code into my project.

Yeah.

Compile Explorer is not there yet, but it will be, I hope,

Right.

Yeah.

Yeah.

And it's sort of getting there.

Yeah.

Yeah.

Yeah, no...

cars have brakes you can drive faster.

Those kinds of things that reduce fear, reduce risk, and let you you know take a run across the lake because you know you're a good swimmer will absolutely speed you up, right?

And I feel like the unfortunate truth is that a lot of those things kind of have to be built in from the beginning.

I actually remembered the thing that I was thinking about earlier with the topic that I wanted to talk about

Oh, good.

I was able to talk long enough for your brain to recover.

Yes.

All that actually, no, you're, but you actually reminded me of it with all the automation stuff.

Oh, good.

So just this week working with a new intern on my team, I figured out how we figured out how to completely automate in user mode or in user space Docker building and running.

So for the longest time, one of the big, bugaboos for me has been, if I want to build a Docker container, I can't use my, you know, `make download` the the tools that I want and stick them into the tools folder approach because you have to have some `sudo` installed or some, yeah, all of these terrible, terrible, terrible things.

setuid root thing, yeah..

I using a combination of the standard Docker client, which is cool and and actually pretty easy to install that way, a library called Colima.

And another thing that it depends on called Lima, which also can be installed this way.

I was able to build a Docker container and run it and have all of the tools entirely installed just in the home directory of the user with no special permissions.

So some, yeah, just magical, I could `git clone` your repo and type `make`, and as long as I'm on ah ah but an a supported operating system, should we say, which should be, you know, ah it will get the tools that it needs to do this and build this stuff without some deus ex machina kind of like process that you're like, ah, first you must `sudo apt install` all this stuff, the stuff that you and I dislike.

A supported operating system, yes, exactly.

Yes, you have to download this DMG file and double click on it and do all these other terrible things.

Oh, that's awesome.

Yes, yes.

and and And that kind of automation, I think, to an outside person would seem like, why are you spending all of this time to do this?

Because I think it took us about a day to do it.

Why are you spending all of this time to do it?

And it is so that, and this is especially true of this particular type of project that we're working on because it sort of gets worked on in fits and starts, right?

Like you work on it for a while and then you come back to it and then you just think.

So it's like, it is so that six months from now when something is broken and I need to fix it right now, the way that I set up that development environment is I `git clone`, `make`, done, figure out what's going on, push it and not like `git clone`...oh...

Right.

None of this works and, and it will take me six hours to make it work because these versions are no longer up to date and this package doesn't exist anymore.

And I can't find the download link for that.

And these docs are wrong.

And that is, that is like a classic example of like the kind of thing where I feel like you get very opinionated about it.

You have strong...

Well-reasoned arguments for for why you do it.

And so long as you can successfully achieve the outcomes that you think you're supposed to be able to achieve while using these approaches, no one's going to care because it just works.

If it doesn't work, then all the blame comes out.

And then all of the second guessing and the Monday morning quarterbacking comes out and says like, okay, why did you do it like this?

Yeah.

Yeah.

But, but also to your point, you know, like the whole, you know, we, you and I have, have talked about this before.

We, we both love this idea of like a sort of more hermetic build or whatever you need environment.

Yeah.

And I think that, you know, there are stuff more modern things along have come along since then, you know, dev containers and some stuff that uses Docker trickery to actually like make that.

I don't, you know,

Mm-hmm.

I have opinions about that.

But the reason that *I* went for this from my previous point of view was that some people at Google had set up their development environment like this, and I saw that it was possible.

So that does dovetail back into your original thing.

yeah

This is like a senior developer telling you, oh, yeah, you can do this.

It is possible to make it so that you can just have a directory...

There's nothing magic about compilers.

They aren't system software.

they they They like to masquerade and pretend they are.

But if you need GCC 1.2.3 to run your code, you can download and install it, or you can build it so that it can be downloaded and installed, or you can do all this stuff.

You can spend a bunch of time.

You now learn how to do that, and now you can take that on to the next thing.

And then, you know...

The frustration specifically in this case was like ah the very first company you and I both worked at together, where we were stuck for a very long time on the version of GCC that came with the operating system that our production machines had, which was also you know an ancient version of Red Hat.

Yeah.

You're like, why are we using a 10-year-old GCC 10 years ago?

Right.

Yeah.

oh because of this.

Oh, it's hard do.

No, no.

We can make it.

We can solve this problem.

Yeah.

We can build our own compilers.

We can make them work.

And then we can make it so that that is an easy thing to do.

And it's part of, was it "Fig"?

I think was the name of the funny little thing that we started installing stuff in.

Oh, yeah.

And i you know.

I think that sounds about right.

There was a package management system, whatever.

Anyway, and it was a lot of effort and lot of work, but we got it working.

Yes.

And it was so beneficial because then we could upgrade our compiler, upgrade everything.

And it just worked.

And it was.

Anyway, we didn't do it because of that.

That just is side effect.

Yeah.

You know, the funny thing about these practices is I feel like they spread like viruses, but that is they only spread through contact.

Right.

It's like it's it's like because there's a lot of things.

Ha ha ha.

There's a lot of things that I've seen like this where it's like I have explained these things till I'm blue in the face.

And I made the arguments that I'm making on this podcast right now about why they're beneficial.

Right.

do And I get a lot of people with like blank stares and it's like, okay, sure, fine, whatever, and nodding heads and whatever.

And they just walk away and they ignore it.

But the second that I work with somebody for like, you know, it's not a second, but when I work with somebody for like a reasonable period of time and they actually see how this stuff works, it would becomes impossible for me to convince them *not* to do it.

Right, right.

Right?

Like they see the value of it firsthand and they sort of experience it like viscerally.

And it just like, now they can't imagine doing it any other way.

Right?

Why would you do it any other way?

Right.

Yeah, just it's like, yeah, you have to get over the hump there.

Right.

There's some kind of...

ah function where the, you know, you got to get over the hump or quantum tunnel through the hump.

Yeah.

Right.

I was going to say like,

I guess, you know, you, you either, you go up the, up the, ah you know, you spend the 30 years climbing the hill, you know, and then falling down into a, into a better place, the other side of the hill.

yeah

And you go Hey, this is better than than it was the other side of the hill or through contact with someone, you allow them to quantum tunnel through experience hill and come to the better place without actually having to make all the mistakes along the way.

Yeah.

Right, right.

Yes.

Wow, that's ah I love that.

There's an image.

That is a great analogy.

I love that, quantum tunneling through the hill.

There's an image.

Experience.

Yeah.

ah that's what That's what mentorship is, is letting other people quantum tunnel to a better place without having to go through as much of the pain that you did.

Yeah.

Right.

Let me show you the secret passage through the mountain.

Yeah.

Yeah.

I don't know.

Well, that was, that was a surprising amount of talking for no idea at all.

No idea.

i mean, I guess I did eventually remember the thing that I was talking about before, but, and maybe that would have led us to this topic anyway, but yeah.

um suppose I suppose so.

Yeah.

Yeah, but no, I think your your your starting point of like having ah a good project and a nice setup and whatever is certainly top of mind for me now as I'm sort of retrofitting it into Compiler Explorer at some level.

Yeah.

I mean, we've always had some level of this, but it's improving it and shoring it up.

Yeah.

And then, you know, you and I have been discussing, ah this seems like a complete left tack and late on in the podcast, but it's worth mentioning, I think, is that like um the things that make it easy to dip in and dip out of projects like this, or be it because it's easy to set up, be it because there's clear documentation, there's no surprises, be it because the lint rules make it obvious when you're doing something the way that you're not supposed to be doing it or whatever.

Mm-hmm.

So you kind of put people on the on the good path.

Yeah.

be it like decent documentation that says this is how we do stuff here.

Yeah.

All of this is useful for an intern coming onto to a project coming off.

And that intern could be an LLM in today's climate.

Right.

And that seems to work fairly well too.

Yeah, yeah.

And so I'm sort of mindful that that is out there and, and it's certainly, um, a decent subset, like a good 80% of the things that are useful to make life easier for this amnesiac junior programmer to come in and try and make a small change so on ADD meds to come in and, uh, make a change.

Yeah.

to ah my project, but that also helps the actual intern that's going to come on and hopefully will mature into ah full featured junior developer and then a senior developer and go on to do great things, right?

Yeah.

Yeah.

Yeah.

But that's it's an on-ramp for everybody.

And so that's sort of like top of mind.

And yeah, I don't think we have time to talk about the full ins and outs of that.

But it's it was an interesting thought that like that this this nice setup is also conducive to that.

yeah Oh, it totally is.

And then you know there's there's this some like industrial design and like tool design thing of like trying to design for the edges, right?

like And and like a lot of um things that people started to discover when they started building um both like devices and also like buildings and sidewalks and things like that for disabled people is that it actually winds up helping everyone a lot more than they wouldn't have expected

able bodied folk.

Yeah.

Because when you kind of design for those extremes of like, well, what happens when somebody is like 75 pounds and can't lift this?

Or what happens when somebody is, you know, seven feet tall?

Or what happens when somebody is in a wheelchair?

What happens when somebody can't see?

You wind up creating these things that are just easier for everyone, right?

Right.

And I think that there's a lot of that when it comes to both designing for, ah you know, junior developers and LLMs and me six months from now after I've slept a bunch of times and don't remember how this all works.

Like all of those people kind of have the same problem.

Right.

Which is they don't understand what's going on and they need some guardrails to make sure that they don't make any stupid mistakes.

Yeah.

So like designing for this stuff has tons of value.

And I think just like with some of the, you know, ADA accessible things, it's like you don't really discover that and maybe this is why I'm tying it back to the whole like it spreads like a virus and I can't seem to convince people maybe this is the problem it's like until you walked on the sidewalk that is like gently sloping up to the thing instead of like the stairs where you're huffing and puffing ah you're like yeah this is better like I didn't think about it but it really is better right

Yeah, that is it.

Yeah.

No, I think so.

Well, that seems like a decent place to park the conversation, because otherwise I think we're going to start off with the whole other thing.

We're going to do a whole other second podcast on top of this podcast.

Yeah, which we don't have time for today.

Yes.

Yeah, now that's true.

But yeah, I mean...

Yeah.

I think that's a great analogy.

Yeah.

The, whole idea of helping one set of people helps everybody ah in the, in the context, both in the real world in, and you know, like screen readers and things like that, that's helps, you know, and and yeah, yeah but better documentation.

Yeah.

You're like, well why do you need documentation?

It's like, well, helps new people, but it also helps you, you know, down the line.

Yeah.

Yes, it does.

Yeah.

Yeah.

Yes, it does.

Well, friend, I think we should probably leave it there for this week.

Wonderful as always.

This month, I suppose.

Yeah.

Yeah, true.

As you know, you and I talk about this, but we, yeah, the timing these things come out on is different from the time we record them, which confuses both you and me and now the listeners as well.

So nevermind.

Right.

But yeah, um have yourself a great summer.

If I don't, so if we don't talk before then, as I think that will, will be the case.

Mm-hmm.

And until next time.

Until next time.