Two's Complement - Not Invented, Hear?

Episode Date: January 17, 2023

Matt and Ben explore their mutual tendency to favor build over buy. Instead of using open source software that may be free-as-in-puppy, our hosts have sometimes built their own solutions, occasionally with hilariously regrettable results.

I'm Matt Godbolt. And I'm Ben Rady. And this is Two's Compliment, a programming podcast. Hey, Ben. Hey, Matt. How are you? You should leave that in. Oh, no. All right. How are you you should leave that in i know all right how are you doing i will leave it in won't i now because i'm too lazy to edit sorry listener you're gonna have to listen to that that's awful

uh i'm doing good i'm doing good i'm glad to hear it yeah i'm glad to hear it oh my gosh well um yesterday you and i were chatting with a colleague, and he made a very astute observation. He did. About the way that we develop software, and in fact, the way the sort of group of individuals that we've surrounded ourselves with over the years, over the last decade that we've been kind of vaguely

hanging out at the same company, about the way that we develop or we at least approach software development. And so I thought, let's talk about that today. Yeah, that sounds good. I'm trying to remember what his exact phrase was. I'm going to paraphrase him a little bit here, but it's something like, the previous companies that I had worked at, if someone came along and said, hey, I built a message queue, they would be instantly fired. And I think he was kind of talking about our both, what's the opposite of reluctance?

Not aptitude, not enjoyment. There's some... Eagerness, maybe? Eagerness. Eagerness. Perfect word. Our eagerness to go and build solutions for problems that are problems that other people have attempted to solve, perhaps even in a similar way, but not similar enough for our tastes a lot of

the time. And I know you have done this and I have done this, and you could very easily categorize this as not invented here syndrome. And I don't reject that characterization at all. Like that's very fair. No, I think that's a character flaw that we all suffer from. Very fair that this is a little bit of non-invented here but i think that we do have some rational reasons for doing these things and maybe we can take this episode to sort of explain some of those

absolutely so i think the motivating or one of the motivating examples that we came up with was a uh package management system that our previous company had developed called Fig, which was effectively before its time a Conan or a Conda or a insert your like development package needs here system which would allow you to describe your project's dependencies, go and grab them and unpack them and solve like well this needs this version of that and give you errors when they weren't and of course there are thousands

of those around i mean most notably your operating system almost certainly has a variant of some kind of package management system so you know you can have debian packages or you can have um uh snap snap well nowadays you can have snap obviously this, nowadays you can have Snap. Obviously, this was like 12 odd years ago. So I don't know that those things were necessarily around. Of course, nowadays people will do Docker builds and things like that. But I'm certain that there were solutions.

I mean, effectively, most, at least script languages, have their own homegrown solution. I mean, Python has had pip forever and i think the the overwhelming problem that we were trying to overwhelming problem the problem that we were trying to solve here was that there is a community based at least at the time sort of somewhat lackadaisical attitude towards um the exact versions of packages that came down and so you pip install and at least back then you just sort of said give me the version of this and it just installed that version with if it needed other packages it would bring them in

but it would make no effort to make sure that everything worked together well nor did it guarantee that if i were to then check in some code that it pip installed some stuff that would my CI would get the same versions of that. And so we had this problem where floating versions would move around. And that was not a good look when you're trying to explain that, well, it worked on my machine, then we built it on CI, and then we deployed it to a trading system, and it did the wrong thing. Right, right. So that's where that was the sort of motivation behind it at least the beginnings of the motivation of it um and i think our colleague was like

no one else would do that that's that's crazy talk you would just make something else work well enough for you and get on with your life and i think you know the queue example he said you know that we someone would get fired if you came up with a message queue. Whereas, you know, again, we developed an internal message queue based off of like some of the papers that we'd read. But we didn't use anyone else's code for it. And again, that could be not invented here. But I don't know if. So from my point of view, I was doing a lot of native code at this company and i would now retrospectively justify a lot of my decisions based on how hard it is to share code you know it's not as straightforward as just like pip

install or conda install nowadays of something there's normally some kind of um dance you have to do to make sure you get the right version of the code and its dependencies and get the source and check it out and build it and all that kind of stuff which to to a greater extent actually things like vc package and conan have now solved but only fairly recently but back then it was like well it's almost as much effort to download this package work through its readme of how its its particular brand of makefile or scon scripts or whatever to build the package that I want and then find where it installs its headers to to copy them to oh sorry I'm just going to do it myself

so that's my retrospective justification but you weren't in native land how did this manifest for you uh well I've definitely had a few instances of this some of which I would do over again and some of which were, I would say, a mistake. You know, the ones where I really feel like we did the right thing were

probably more along the lines of avoiding unnecessary... It's a little smaller in scope than building a whole package manager. It's more along the lines of avoiding pulling in some large tree of dependencies to solve a particular problem than just like, you know what, I'm just going to write this myself, right? Or I'm going to use what the platform gives me and I'm going to enhance that in some way,

I'm going to build some additional code around that in some way. And I had an experience with this very recently, We were talking about this using some AWS services that almost did what I wanted. And I spent a couple of days digging through the documentation, trying to figure out how to get them to do exactly what I wanted. And after a couple of days, I'm like, all right, I'm just going to build this myself. And I built a reasonable implementation in about a day and a half. Like I'm actually working on that a little bit today, but it's like a day or two, right? So I spent a couple of days reading documentation, couldn't figure out how to do what I wanted. And now I've spent a couple of days basically re-implementing that thing, right? The trade-offs of that decision are something that you could definitely debate

on either side, right? Should I have kept trying to figure out how to get what I want through configuring the service? Should I have tried to build the minimal set of things? Like another way to approach this problem is, all right, all right, this service has its capabilities. I'm going to change something upstream or downstream of that to accommodate what it's capable of doing so I can use it as is and as designed.

And that's going to make other parts of my system more complex, but I'll be able to reuse this thing. That's a completely reasonable way to do it. That's not what I did. What I did was I built the exact thing that I wanted and it doesn't do anything else. It doesn't do all the things that that service does. It only does what I need it to do.

And it does it in exactly the way that I want it done. And it's very testable. And all of those properties for me are exactly what I want. I now have that code in my system and I have to deploy that code and I have to test that code and I have to maintain that code and I have to carry those costs.

But in my mind, those costs are lower than the cost of either adding complexity to other parts of the system in order to accommodate the way that this service works out of the box, or continuing to bang my head against, can I ever get this to work, right? Right. I mean, in particular, things like testability, when you're talking about something that's a service, if it doesn't provide a kind of run locally or a stubbed version, or it's not straightforward to do that, then you are definitely giving up some testability or else you're spinning up things in the real world and integration testing things. Whereas if you make it yourself, you can put the points in where you need them the test points yeah and it's exactly that it's it's okay if we use this service we're going to forever more have this future integration test cost where the only way to be confident that we've we haven't broken something we make changes to the system is to run very expensive and potentially unreliable integration tests and we will pay those costs basically forever, as long as this project runs.

Whereas I can have a very fixed cost of writing a bit of code and testing it and using it the way that I want, building out all the stubs that I need. And then those tests will instead be unit tests that will run quickly and reliably. And yes, I do have the ongoing cost of maintaining that code if I need to change it.

But that's also a bit of a feature in that, like, okay, I have something new that I need to be able to do. Oh, the service doesn't support that. That doesn't matter. I've built my own thing. I can change it however I like. So, you know, it's hard, and it's hard to quantify these things, and it's hard to measure them objectively and say, like, my decision was good and here's the spreadsheet that shows it. A lot of it is based on intuition about what future changes will come. And that's really hard to make predictions, especially about the future.

Especially about the future. So, you know, it's a judgment call at the end of the day but it's one that i that i definitely feel comfortable making and i think that's one of those experiential things that you just have to draw on your experience of like i have seen this before or something that looks a bit like this before in my experience um it would be worthwhile doing it this way like choosing to write it myself, taking on that complexity with open eyes of the understanding of how much work that might actually pan out to be.

But yeah, again, that sort of feeds into the not invented here kind of stuff. And like, you know, sometimes you have to ask yourself the question, am I answering this truthfully? Like, is this something that I do need or is it cool to write it? And would I be excited about working on it?

Which sometimes maybe that is enough to justify it because, you know, we're humans. We love what we do. We're lucky to know to have this job where we do actually enjoy what we do. And maybe motivating it and doing it yourself is enough of a cost. If it's a day or two like you've done, right?

Maybe that's fine. If it's a six-month like you've done. Maybe that's fine. If it's a six-month project, maybe we should talk. Yeah, right. Exactly. And, yeah, and we were kind of talking about this yesterday where it's – I think you can too easily discount, you know, engineers who are trying to be hyper-rational and, you know, take their emotions out of everything. I think discount the value of having somebody that wakes up every day emotionally invested and motivated in a project to make sure that it works and works correctly. That's an extraordinarily powerful effect.

And you shouldn't dismiss it because it's like, oh, well, why did you rebuild this thing when there's this off-the-shelf thing that does exactly that? It's like, well, if I use the off-the-shelf thing, I'm not going to give a f**k about it. I'm going to have it do what it does and I'm not really going to care too much if it's testable or if it's easy to maintain or if it works.

It's just sort of this thing and I don't really care, right? And there are lots of places where that's exactly what you want. They're like, I don't really want to care about this problem. I'm not interested in this problem. This is not important or germane enough to my product to care. Or, yeah. I mean, I have a sort of counter to that. I'm working with an open source vendor library that I'm sort of mandated to use for a particular thing that I'm doing.

And it doesn't quite work the way that i want to do it and the uh the underlying thing that it does i could like i say reverse engineer i have the source code so it's not really reverse engineering but it's not documented the sort of underlying thing that it's doing but i could work it out and then write my own but i have no no wish no desire to do that. That sounds like an awful lot of work to reproduce what this vendor is providing us. The scope of what the vendor's code does is much, much, much broader than what we need. So I'm picking up this giant library

with all of these dependencies that it brings only to get access a tiny part of the feature. So it definitely feels like the pendulum could swing back towards just wrap this tiny part of it. But instead, I decided to go in and go like the thing that I actually needed to do that it doesn't do. I'm going to do a surgical change to their open source project, fork it, and then we're going to use that ourself. And now we can sort of take it out of the mix. And that was mainly for that testability and reproducibility reasons.

That's like a binary underlying protocol that I had to either consume directly from a TCP stream or go home. And I'm like, I don't want to have to consume this. I want to write a test that doesn't need a TCP server in order to do its work. That seems silly. So, you know, there's,

but I could have chosen to kind of roll my sleeves up and say, I will spend two months re-implementing this protocol but i didn't make the call that way um yeah yeah but i mean i definitely have also had instances where i've done this and regretted it um right it was not the right choice um one project in particular at at prevco which i know you are actually a user of, the monitoring system. Oh, yes. We started out in that system using MongoDB as our database.

And we had some problems with Mongo. And that was the early, it was like Mongo 1.0 or something. It was very early days. And, you know, I don't even know if those problems are still a problem or whatever but we definitely had some some pretty significant problems and so at one point as a team we were like we're just going to build our own database and that was a mistake i think if those words leave your mouth you should seriously seriously consider what you just said yep yep and we're like it's

fine we're not the whole point here is that we don't need a relational database this is mostly for i mean the the messages that we were we were basically uh we needed a database to store messages that were coming off of a message queue they weren't really relational in any way right we chose mongo because it was like a document database and we thought it would be a good fit right sound it sounds like on paper but yeah and and and i don't doubt that we needed some kind of non-relational you know no sql document type database whatever we just should have tried something else after mongo before immediately jumping to we're going to write our own database but presumably you in your defense you've just been burned quite badly by whatever things you discovered in this nascent early version of mongo yes and so you were kind of like uh you know you're on the rebound as it were from

that going like well i'll never date again i'm just gonna have to do this by myself yes lonely me i'm never gonna find love love so i'm right i should write my own database yeah yeah and i mean in fairness it was one of those things and we've talked about we talked about this yesterday where it's sort of like one of the advantages of doing this yourself is that you do set your path yourself on a path to incremental success right like i know if i just put in enough time and effort eventually i will create a solution that will solve this problem right i don't know how long it's going to take but there's no chance that i'm going to basically wedge and have to start over from zero

right or the chances that are very very low unless you discover it's np hard along the way and that's why no one else can do it right but there you know yeah you can make forward progress at every step and you can set yourself a goal you can you can guess how long it's going to take you and you'll still be wrong but you will be able to get there whereas if you're reading the documentation of a system and you're playing around with the system there is no guarantee that you won't discover towards the end oh it just doesn't do the thing i need it to do or if it does it doesn't do it in the way that I need it or it's not performant enough or whatever. Some other hard constraint that basically devolves down to,

well, I could fork this and do it myself. But at that point, I am just kind of like building my own thing. Right? Right. So, yeah. And I mean, in our case, we had this situation where we had deployed the system, we were using it, it was being used in production, and Mongo was basically falling over. And we sort of had this thing of like, okay, we could try another database, but we might just be back where we are right now in two months.

So let's write our own. Again, this was still a mistake. We should have tried a few other databases. I think you mean it was a learning opportunity it was an opportunity for yes it was the classic example of good judgment comes from experience and experience comes from bad judgment um but uh it was it is definitely not something that i would do over again right um but i mean in fairness we did eventually build a database that was a solution to our problem it's just that the ongoing costs of that and the time that it took to really get it into a state where we were happy with it, the trade-off just wasn't there.

It wasn't the right trade-off. We should have tried some other. We should have done like, honestly, if I were to do this over again, I would do more of a set-based approach where I would say, all right, we've got four people on this team. For the next two weeks, we're going to explore four different databases. So everybody pick one and go try it. Oh, that's an interesting approach. And share your results as you go along. There's no reason to wait to the end.

But we need to parallelize this effort and we need to try as many things as we can and hopefully we'll find one that works. And if we don't find one after two weeks, then we'll do another two weeks. Or maybe we'll build on our own. Or who knows? Maybe we'll find one that works and if we don't find one after two weeks then we'll do another two week you know or or maybe we'll build in our own or who knows maybe we'll fork one yeah take one and fork you'll have some information information gathering i think yeah speaking as my for myself really um i find that stuff really hard to do i get so invested so quickly into something or i get very quickly like this is rubbish i'm not going to be able to

use it kind of thing and then i'll go away so so I two weeks sounds like a long time to do that but I think you're you're right you know that the approach is sound going multiple ways at the same time so that you know everyone could meet back up at the table and sort of say well I hit this snag that's when I was gonna say oh I hit that snag too maybe this is actually intractable maybe this thing can't be done the way that we want to do it in any reasonable database. And that might inform your decision to say, well, let's see if we can do it ourselves.

Yep, yep, yep. So, you know, these kind of decisions that we make and this preference that we have, it's definitely not obviously the right thing to do. I think that I can pretty easily justify some of the decisions that I've made. They've turned out pretty well. Some of them are maybe a little bit more borderline and some of them, as we were just talking about, are clearly not the right thing. But it does have a number of benefits. It has this benefit we were talking about of you definitely tend to be more invested you become an expert in the solution that you create um in a way that i'm not going to say

it's not possible for something that you pull off the shelf but it's just certainly for me personally it's significantly more difficult and i feel like most people who are who are like think of themselves as software engineers you know people who build software for a living their brains just click in better when they have built something it's the same it's the same reason that you like in school are like we're gonna implement this algorithm right and in the real world you will never implement this algorithm please do not implement this algorithm there are untold number of libraries that people much smarter than you have implemented this algorithm with all the different corner cases and you should use their solutions and not your own but just to make sure you actually understand how it works we are going

to implement this algorithm right and i think that effect is a very powerful effect and so when you build these things for yourself, it's less likely you're going to get stuck in the sort of like, yeah, this is broken and I don't understand why. Right. How well does that translate, though, for new members of the team? Because that works if it was you literally oneself building the project or the people that were involved in that feature but

then to somebody coming onto the team who hasn't seen it before you've got a sort of double problem of like it's not a standard solution so there's no chance in heck that they would have had any experience with it and they have to learn it as if it was a new system now so i i'd not i don't know if that's um no i mean it's it definitely is a concern. But one of the things that I would say is, so imagine that you instead chose to use some open source tool, right? And that tool is a really important part of your system, right? It's critical. You depend on it, right? Immediately, you start asking questions like, can we hire the maintainer? Are they available? And if you build it yourself, you've done that by default. That is true. Right? You have the person right there that you're

working with every day that knows the system top to bottom, and you can just ask them questions. And so as a new person on the team, you have that sort of baked in expert now that expert might have a lot of constraints on their time and not might not be able to share and that's when you start you know writing a bunch of documentation maybe and then you're wondering like why am i doing this so there's there's definitely reasons or situations in which that can fall down but i do think one of the strengths of that um is that you you you have that person that is like can just off the top of their head be like oh yeah you need to go look at this file this is where that's controlled

and you can configure it like this or these are your options and if you try that that won't work right because they wrote the code they know it yeah so i guess you have a domain expert who is also again invested we hope in the product and the project and is hopefully, if you've employed the right kind of people, is excited to tell people about it and effusive rather than like, oh, it's just, yeah, Postgres just does it that way.

Sorry, can't do anything about it. It's just the way it is kind of thing. Yeah, yeah. And I mean, there are definitely dysfunctional forms of that where people will build these systems and then like be very reluctant to share their knowledge or write documentation the job security uh dysfunction of like yeah hey yeah i'm just the expert in blah now everyone needs blah so uh i'm i'm set for life now yes and and there's you know less less um pathological forms of that too where it's just like i'm i'm set for life now yes and and there's you know less less um pathological forms of that too where it's just like i'm just really busy i can't i can't do this right i have

a lot of other responsibilities i can't spend all my time explaining to people how the system works right like i wrote some docs maybe you should read the doc well that's that's another thing as well you know obviously you can help yourself by documenting stuff, but like certainly typically in organizations that I've been involved in, documentation is at best out of date and at worst actively harmfully wrong. Right. Which is, I mean, I believe that to be the natural state of documentation, which is why I heavily discount it myself. So that's why I don't tend to read other people's documentation,

which is sometimes is problematic because they'll say well did you read the docs i'm like no because the docs are just wrong by they're definitionally wrong as far as i can tell and they're like no these ones are actually up to date like oh now i feel terrible yeah no i'm i'm mostly with you they're the best docs of the code like right you know it's it's like you should have a read me that explains some basic concepts and if it's any more than about three or four pages or three or four screens worth what's a page i don't know pages anymore yeah three or four screens worth of text like it's there's probably some lies in there yeah um i will say i've had some good success with executable documentation where i've used like like uh pydoc style tests and it's like yeah you know my documentation is up to date because at least the bits that mention code they still work and they pass the test which is a good way

but anyway that's we digress yeah we don't yeah yeah so one thing that came up when we were chatting yesterday was the the sort of like there are different mentalities towards making reusable components so what we're talking about here are reusable components we've mentioned sort of like system level things really in most of this type of stuff you know you mentioned a database which feels like a system even though it could be implemented as more of a library but um and well the vendor solution i was talking about was a big library, but it's an ecosystem of lots of libraries, and they do lots of things. There's a huge amount of things that they do that I don't need them to do, which gives me complexity I don't want. But there's definitely

something to be said for the kind of manicured, very well-developed and well-thought-about domain expert library. When you actually pick up a library that's like that you're like i know i can trust the folks behind this to have thought about everything extremely um thoroughly and so i don't need to know this the the product well enough maybe i don't have this these particular needs um that i would develop it myself but i'm actually almost i guess this is like one could argue this argue this is the way you might choose to vote, right? I vote not because I want to choose everything myself, but I'm picking somebody who is smarter than me

to make the decisions, like the delegation type thing, delegation theory of why you vote. And maybe I'm like, well, I need a library that does X. I don't have a strong belief about how X should be done. So I'm going to pick someone else's X because it will come with their sensible choices for everything about X that are on the periphery. Yeah. And so that's maybe one argument against the inventing yourself where you have to make hundreds of somewhat arbitrary decisions for things you don't necessarily care about and you aren't maybe not as invested uh in coming up with the right balance of like should we use threading or thread pools or different processes or i don't

know but someone else has thought about this maybe it's configurable maybe it isn't um yeah so there's a value there exactly a value that's no absolutely and i think the thing to consider with those with making those choices is very similar to what we've talked about with programming languages on a different episode of the podcast, which is, you know, we said before, it's like when you adopt it, when you start using a programming language,

you implicitly have to adopt the values and principles of the community behind that language. Yes. And those are almost more important than the language features. If that community values testability, you will be forced to value testability by using the platform and the APIs and the language and all the things that are built around it.

If they value thread safety, if they value terse syntax, if they value a functional style, whatever it is, you're going, like, you're either going to be fighting against the current the whole time you're using it, or you're going to have to adopt those ideas. And I think that you get that same effect sort of in a slightly smaller form when you're using somebody's library. And I think that you've experienced this in your day job with this library, this vendor library that you're using, where the ideas and principles that they put into that library are not necessarily the ones that you would choose. And there's a cost, there's a tension that is created because of that. And now you're sort of forced to make a choice of like, well, I don't really want to care about

this problem, but man, I wouldn't have solved it this way if i did it so that's that's creating tension and the sort of sweet spot the the wonderful uh situation that we're all aiming for is when you can successfully delegate the creation of a solution to somebody and their values and principles align enough with your values and principles to where you can be like, yeah, I probably would have done it in a very similar way. This library is great. But that's sort of the trade-off. And I think

that's obviously a little bit of a gradient. It's not a binary thing, pun intended. But the choices that I think we tend to make is is would lean us a little bit more toward the side of like you didn't solve this the way that i would want to solve it so i'm just not going to use it right yeah i mean that's definitely a symptom and i wonder sometimes

whether or am i just using this library wrong have i come at it from the wrong axis you know and then that's when if you know somebody who has used a library or a feature before and they go oh yeah you're thinking about the problem wrong you know you can solve the you can solve the thing that you need to be solved but you're thinking about it wrong if you rephrase it this way then it just falls naturally out of this library like brilliant i needed that i was i was going against the grain not because um i fundamentally disagree with some way that the system is designed to be used or whatever but because i didn't know and i couldn't find out how to rephrase my uh my problem in the right way but sometimes you're like i am going

against the grain and i'm just fighting and fighting and fighting and fighting because it's not actually possible to use it the way that I want it to be used. And there is no better solution. That's just like, well, sorry, it's not really designed to do the thing that you want it to do, which is a bit more like my most recent experiences. They're like, well, sorry, that's just not how it works. And like, wow. Oh, OK. I guess I guess I'm stuck then. Right.

I've made a i can't make another choice in this particular example but um yeah and it's not wrong right you know everyone has different values of course you know that's they're not necessarily wrong it's just not the way that one would choose to do it absolutely i mean everything is a bit of a portfolio optimization where you're choosing from different trade-offs. And the things that you value are going to be a function of your strengths and your weaknesses, and it's going to be different for everybody.

So, yeah. But one of the things on that that I definitely, I have done and I have also seen you do, is you will ask people that you know and trust, perhaps in a Discord channel or a Slack channel, hey, does anyone have a good library for X? And what you're asking when you ask that question is not, can you Google this for me?

Right. What you're asking is, hey, people that I know and trust and have similar, but not necessarily even the same sort of strengths, weaknesses, values, principles that I have, but I know what yours are.

And if you tell me that library X worked for you to solve a problem, I will be able to interpolate whether it will work for me, right? So like, I know that you, for example, value performance and, you know, native fast execution. And therefore, if you say, hey, this is a great library for X, I can be like, well, if my concerns are, is it going to be fast enough? The answer will yes right right right right or i can ask you and say like hey was it fast enough and you're like absolutely and i'll be like yeah and i know if i ask you about something then it almost certainly will be testable right or have some kind of yeah affordance to to to testing right and you'll be able to pre-populate and say like

yeah it's great for this but watch out for this thing and this will burn you and this is a problem to testing. Right. And you'll be able to pre-populate and say like, yeah, it's great for this, but watch out for this thing and this will burn you and this is a problem, but otherwise it's cool, right? So it's like, you know, when we ask those kinds of questions to the people

that we've worked with before, it's not about like, hey, can you do a survey of all the possible tools for this for me? It's like, can you relate your successful experience

with this thing that I have confidence that it'll work for me it's like can you relate your successful experience with this or even that i have confidence that it'll work for or even like say oh uh i don't have a good suggestion but i have tried x and it was a catastrophe for these reasons which sometimes is as valuable in fact it's more valuable right don't go down these blind alleys they they are they look like they will be they will bear fruit but they almost certainly won't. Now, of course, sometimes, again, that person has done things wrong. There have been times before now where I've told people, no, that system doesn't work that way. And then they've turned around and said, well, actually, I took a look and it does. And you're like, oh, well, today I learned.

Yeah, that's sort of the bit about if you ask an old gray beard engineer if something doesn't work and they say, yeah, no, it doesn't work. You can sometimes discount what they say. Like, that's fine. But if they say that it works, it almost certainly works, right? Like, unless they're just straight up lying to you. Yeah, it's hard to misinterpret success. Whereas defeat can sometimes be well again if you rotate it 90 degrees it fits in through just perfectly actually just rephrase your problem exactly exactly well i mean it was an interesting discussion yesterday and it has been an interesting discussion today um i certainly had never really thought about it it For you and I, I think it was such a sharp observation for us both. It took us kind of by surprise that it was just offhand handed to us as like, hey, I've noticed this thing about you, Matt and Ben and the folks that we've worked with from the previous company, that you all have this really low threshold for reinventing things or making things yourself things yourself you know you don't seem to be

dissuaded by how difficult it might be and it was presented to us as almost neutral a neutral observation i don't think uh i don't think it was meant as either a slight or uh uh blowing smoke towards us it was like hey i've just noticed this really unusual thing i've never seen it in companies i've been at before and so it makes for a perfect conversation topic for a podcast and i wonder what other people listening feel so we'll be interested to hear what uh what observations our listener has about when when you should build yourself when you should investigate and when you should uh just i don't know what the other solutions are when you should build yourself, when you should investigate, and when you should just, I don't know,

what the other solutions are, when you should just go home. Yeah. Which seems like a perfect time to go home ourselves and call it a day. Sounds good. All right, I will see you another time.

Yep. Bye for now. Bye. You've been listening to Two's Compliment a programming podcast by Ben Rady and Matt Godbolt find the show transcript and notes at www.twoscompliment.org contact us on Mastodon we are

at twoscompliment at hackyderm.io our theme music is by Inverse Phase find out more at inversephase.com.