The Changelog: Software Development, Open Source
Build software that lasts! (Interview)
Wed, 05 Feb 2025
After 30+ years in the software industry, Bert Hubert has experienced a lot. He founded PowerDNS, published articles for places like IETF / IEEE, and built his own parliament monitoring system. That just scratches the surface. Recently, Bert wrote about what it takes to build software for the long term. Let's dig in.
I'm Jared Santo, and you're listening to The Change Log, where each and every week we have conversations with the hackers, the leaders, and the innovators of the software world. We pick their brains, we learn from their mistakes, we get inspired by their accomplishments, and we have a lot of fun along the way. Today we are joined by Barrett Huber.
After over 30 years in the software industry, Barrett has experienced a lot. He founded PowerDNS, published articles for places like IETF and IEEE, and built his own parliament monitoring system. That just scratches the surface. But recently, Bert wrote about what it takes to build software for the long term. We dig in.
But first, a quick mention of our partners at Fly.io, the public cloud built for developers who ship just like us. Yes, Fly is the home of changelog.com. Check them out at fly.io and tell them changelog sent you. Okay, Bert Hubert on the changelog. Let's do this.
Well, friends before the show, I'm here with my good friend, David Shu over at Retool. Now, David, I've known about Retool for a very long time. You've been working with us for many, many years. And speaking of many, many years, Brex is one of your oldest customers. You've been in business almost seven years.
I think they've been a customer of yours for almost all those seven years to my knowledge, but share the story.
do you do for brex how does brex leverage retool and why have they stayed with you all these years so what's really interesting about brex is that they are a extremely operational heavy company and so for them the quality of the internal tools is so important because you can imagine they have to deal with fraud they have to deal with underwriting they have to deal with so many problems basically they have a giant team internally basically just using internal tools day in and day out so they have a very high bar for internal tools
And when they first started, we were in the same YC batch, actually. We were both at Winter 17. And they were, yeah, I think maybe customer number five or something like that for us. I think DoorDash was a little bit before them, but they were pretty early.
And the problem they had was they had so many internal tools they needed to go and build, but not enough time or engineers to go build all of them. And even if they did have the timer engineers, they wanted their engineers focused on building external facing software, because that is what would drive the business forward. The Brex mobile app, for example, is awesome.
The Brex website, for example, is awesome. The Brex expense flow, all really, you know, really great external facing software. So they wanted their engineers focused on that as opposed to building internal CRUD UIs. And so that's why they came to us. And it was awesome. Honestly, a wonderful partnership. It has been for seven, eight years now.
Today, I think Brex has probably around a thousand Retool apps they use in production. I want to say every week, which is awesome. And their whole business effectively runs now on Retool. And we are so, so privileged to be a part of their journey. And to me, I think what's really cool about all this is that we've managed to allow them to move so fast.
So whether it's launching new product lines, whether it's responding to customers faster, whatever it is, if they need an app for that, they can get an app for it in a day, which is a lot better than, you know, in six months or a year, for example, having to schlep through spreadsheets, et cetera. So I'm really, really proud of our partnership with Brex.
Retool is the best way to build, maintain, and deploy internal software, seamlessly connect to databases, build with elegant components, and customize with code. Accelerate mundane tasks and free up time for the work that really matters for you and your team. Learn more at retool.com. Start for free. Book a demo. Again, retool.com.
We are here with Bert Hubert, a geeky entrepreneur from the Netherlands with a 30-year track record in commercial and open source software. Bert, welcome to The Change Log. Thank you for having me. Happy to have you. Excited to talk about what you're up to these days and what you've been up to historically. 30 years, that's a long time.
I read that you landed your first job hacking a cable internet provider. Do you want to tell that story?
It was a fun story. So we lived in this university town and we were quite late to get the cable modem. And it may be interesting to know that in Europe, in many places, if you had dial-up internet, it was actually charged by the hour. So we had no local free calls as in other places. So it was a very big deal to get a cable modem.
And when I got it, it was very much delayed and the cable company had issues with it. And when they had it going, I started scanning their infrastructure. And I found out that while they had finished setting up their internet, they had not finished setting up their security. So I could sort of waltz right into their servers and stuff.
And so I sent a message to the system administrators using the famous wall command. I said, hello, I'm here. And they said, well, if you're so good with security, then come over. And so I got on my bicycle, this being the Netherlands. So I drove to the cable company. And on my way there, I was like, yeah, this could end up like really well. Or I could end up being arrested.
So I just waltzed into their systems and it ended up really well. A little bit too well because that was the dot-com boom times when there was such a shortage of staff that I came in, they gave me a chair and they said, sit down. And that actually ruined my studies of physics because then I had this job over there. But it was quite cool.
It was very nice to scale an internet service provider from like 50 users to 50,000 users. I mean, everyone should maybe one day scale a company by three orders of magnitude. It's very educational. So I had a great time there. And it was a wonderful way of sort of learning how to run an internet service provider. Yeah, from scratch, which is very educational.
Because if you mess it up at that stage, it's not so bad. But if you mess it up by this time, like Comcast scale, it is pretty bad.
You can't mess around at that stage. You got to have the uptime, right?
All the nines. So what were some of your learnings as you scaled up? These are kind of like the first time things are scaling up. So you can't exactly go read a book about it, right?
Yeah, I actually wondered if anyone had written a book about it. But I don't think we've had that rate of scaling that we had in 2001, like where you would like double every month or something like that. Right. One of the main things I learned there is that it was quite amateur stuff. So you need to professionalize and figure it out.
Yeah.
And on my bicycle back home again, I got already, I was barely out of the building before they called me and said, what did you do? And so I had to rush back in. And that was, I think I learned a lot there in the sense that you really need to, it's nice to hack yourself around these bugs and then feel really good.
But it's also maybe really good that once you fix the thing, then to also sit down and really tighten things up again and not just shut down your laptop and shut down the whole internet service provider.
Well, unintended consequences, right? You just don't know what's going to happen. Shut that laptop, think you're done for the day.
One really interesting thing that I learned there, and I've been passing on this message since forever, and I'm also going to pass it on to your listeners. So we had a redundant email setup. And we thought it was good, it was redundant. So there was this guy in charge there, and he said, well, are you sure this is redundant? I said, yeah, it's all redundant.
And then he pulled the plug on one of our servers. And then everything broke because it turned out that it was sort of, yeah, we felt that it was redundant, but we had not actually had someone pull the plug on us and see if it actually was redundant. And then it turned out that it was not redundant.
And since then, every time someone says, hey, we built this redundant system, I say, can I just go in there and start shutting down some random servers now? Is it going to fly? And they say, no, no, no, no, don't actually be doing that.
I'm like, well, maybe you have to work a little bit more on your redundancy until you can live with me going in there and just shutting down some random stuff to see what happens. So that has always stayed with me. If someone says it's redundant, I'm going to ask you, can I just shut down some stuff for you then?
Yeah.
That's not a good thing.
You know, pull the plug.
Yeah.
Things fall over.
Yeah, yeah. Well, it's a good thing. I mean, if people say, look, it's sort of redundant in the sense that we can make it work again. Okay, that's fine. That's fine. That's my level of expectation that something could fail over and you could rapidly make it good again.
But if it's not like, but if you're telling me that, look, this is going to be automatically redundant and it's going to work anyhow, then I should feel free to just unplug some stuff and see what happens.
We all learn those lessons to some degree, right? Like whenever you think something is safe and secure or redundant or whatever you might want to call it. And then chaos engineering happens essentially. Yeah.
And then you only learn that. You only learn that. So recently I've been, I mean, we might come to that recently. I've now, I'm now running some actual services again that people depend on. 24-7. And everyone has to sort of live through that for a bit. Like experience being on the line. Like, you know, yeah, people are relying on this stuff and I should be doing a good job here.
And that's a whole new level of thinking that you get, which is very different from a programmer that just programs and never get those 3 a.m. phone calls.
This is why I've been trying to convince Adam to run our Zulip community from his home office. Just host it for us. Self-host that sucker. We only got a few hundred people using it, but they're using it all throughout the day. For the learnings? Yeah, and for that upgrade of yourself, just what it feels like to have people depending on your service. It just changes you.
I'm not against it necessarily.
It's just I prefer not to.
Yeah. I mean, I get that feeling. I really understand because it really sucks because once you have that stuff running in your house, you have to start planning around things because you cannot just have an electrician come over and redo your wiring and like, yeah, we're going to be down for three hours. I mean, it does make you think.
Yeah, for sure. So straight out of university, I ran some mail servers on a Linux network for a company, maybe a few hundred people. And there were two servers and they worked in conjunction and there was spam assassin and it's all kinds of stuff. It was post fix.
And when we had issues, it would just queue up, you know, like as long as the servers were online, even if a mail server is offline, it comes back on. you know, that delivering server, they're going to try again a little bit later. And so it would just queue up. And so there were times where I would come into work and I would look at the mail queues and people are thinking it's a quiet morning.
I don't have any, I don't have any email this morning. It's like, Oh, you do. I just haven't been putting them in your inbox. And then I just, I just love just watching that queue just work its way down back to zero, but definitely know the feeling of like other people relying on your, on your network services. It, It can be stressful.
It can be. It can be.
Yeah.
Unnecessarily, if it's unnecessary. You know, unnecessary. Right. If you got someone else to do it for you, why do it, right? Bert, what are you running these days? You said you're running some stuff now?
Yeah. So I built a sort of parliamentary monitoring system. So we have a Also an upper chamber and a lower chamber and politics house here. And they have a pretty competent website. So it's not that it's bad, but like half a year ago, at one point there was a new law here in the Netherlands, which is quite impactful for the internet community. And we hadn't noticed.
So the law was about to enter into force and we didn't know about it. Luckily, the law was not so bad, but we only had a few days to look at it. And we knew that if it was bad, we would not have been able to do anything in those few days. So back then I said, we can never have this happen again.
And on the Dutch parliamentary website, you can put some search terms and it will send you messages if any new documents match those search terms. It's a bit clunky. It's not that great. So I thought, let's make some kind of advanced warning monitor that we on the internet can put up just searches and say, like, the moment you have a meeting about internet censorship, I want to know about it.
And not only do I want to know when it actually happens, I want to know as many months in advance as possible. And from that, I built this monitoring website and it grew and grew and grew. And actually the sort of fun thing is if you are outside the government, you can innovate rather quickly. And the Dutch parliament is completely open data.
So everything they do, you can effectively monitor the state of the parliamentary documentation system to your house, which I do. And that grew and grew and is now quite popular in the sense that even many politicians are using it and many civil organizations are using it. And the most interesting thing and which I find most important, it turns out that
My simple parliamentary information website, and it's like really straightforward, it's plain HTML, almost no JavaScript, works really well with software for blind people. And it turns out there are some government workers that have to work with these parliamentary documents. And they found out that their screen reader software just has a lot of fun with my site.
Easier to read on your site than the official site.
So I now have a few low vision government workers that are actually relying on my site to do their job. And that has added to my sense of that is not just a hobby anymore. It's just that people actually need this stuff. And, um, so yeah, this is an, and there from that, I learned all these very interesting things that you only learn when you go live with services, with things that you don't know.
For one thing that, for example, that I learned is that if you have an iPhone and someone enters a search term in your form and you do that within a quotes, because you want to search for, for a sentence and the iPhone will turn it into smart quotes. And that is not something your search engine is ready for. Your search engine doesn't recognize these smart quotes as smart quotes.
Well, it just puts them in the smart. So I had this weird situation that iPhone users couldn't find anything. And this is the kind of thing that you only learn in production. And the other thing I learned, I have these signup emails where you can, and passwordless login emails. So you can just log in with your email address, which is quite popular these days. And for some people, it didn't work.
And it turned out that Microsoft now runs a security scanner. that will actually attempt to log in for you.
We know this very well. We were just talking about this topic on the previous episode with somebody, but you have new information now because we have the same thing, passwordless logins on our website.
And what my trick to fix that was, was I switched the actual request from a get to a post and you get, but I read on your website that that's not gonna even work anymore because Microsoft is now executing JavaScript in their,
They're posting to your website.
They're now posting.
And they're posting. And the weird thing is, so the strange thing is they do the post, which is already, I think, violating many people's assumptions. Yeah. You should not be posting on behalf of anyone else. But the other thing is when they do that post, my site actually used to return a cookie, a session cookie.
Which means that Microsoft, with this security measure, so the reason they do this is they want to see, is there malware on this site? And might that malware only pop up after a post? Okay, well, I see where they're coming from. But when they send that post to you, my site would use to respond with a session cookie. It says, well, welcome, you're logged in now.
Which means that Microsoft is receiving tons and tons of these session cookies right now.
Cookie monsters.
Yeah, but you could actually do. These cookies are very valuable. Because these are the session cookies that allow you to do stuff. Well, it now appears that the new barrier is they will execute your JavaScript. Okay. They will execute your posts. Okay. But they will not, for now, click on a button. So you must have a button in there right now. And that button then does the post.
Okay. So you are actually, you're adding a step for the real people because now they have to click on the link in their email and then come to your site and then click on a button to sign in.
Yeah. And, but, but, but there's no, no one, no Microsoft did not announce that they would be doing this. And they have also not announced that they're not going to click on buttons. So maybe one day they will click on buttons.
Well, you need a monitoring website where you can monitor Microsoft's changes.
100%.
And I've since heard many people, they told me that Trends Micro also does this. And actually, I ordered some hardware stuff from a store today, and they have a link that is vulnerable to this. And when you have to click, it says, I'm going to collect my hardware now. And that is already useless for them because Microsoft is doing all the clicking right now.
Because Microsoft's already registering everyone's hardware for them. Yeah. Yeah, it's a crying shame. It's tough out there in the real world of the internet, isn't it? I'm going back to your monitoring site. What formats does the government put stuff out? Are you like diffing HTML, or is it better than that?
Oh, this is a story. This is a story. So on the one hand, they have a glorious API. And actually, I didn't read the manual. They use this thing called OpenSync or something like that. And that is apparently a sort of weakly determined standard by which you can replicate a relational database to somewhere else. as a series of XML changes.
And you can pull these, you can say, I'd want to get all your changes since marker such and such. And that's actually pretty nice. So it is quite convoluted because I think it would have been easier if they just said, look, this is our SQL database and you can query it. But now you get this stream of XML messages and that is actually quite glorious and good. Now, now is where the problem comes.
Governments, when they send you documents, they love PDF. PDF has a lot going for them. You have PDF slash A, which is an archival form of PDF, which is actually nice because that's the sort of PDF variant where you can say, I'm sure I'll be able to read this PDF 50 years from now. So it only uses built-in fonts. It has no language. It doesn't do anything.
So governments really love their PDF files. The thing is web users do not love their PDF files. Web users want to see web pages. They want to see HTML. They just want to click. And the thing is, when the Dutch government gets a document, it starts life as a Word document, a DocX document. which is easily processed. Then they convert it to XML, which is also easily processed.
And then finally they convert it to PDF, which is not so nice to process. So in order to make all this stuff work, I found out that there is a sort of official government archive of government documents. And there they also publish the XML. So in the course of this trajectory, I retrieved the document like four times.
And to save it, I have to retrieve it from some kind of official government archival site where there is XML. And that XML actually is glorious. So when someone speaks in Dutch parliament, they make a note at the exact timestamps when they speak. And this is so they can match it up with the video.
But it also allowed me to make these statistics and say, who are our sort of Congress people that talk the most? or that talk least, or that have the longest sentences. And because they log it all so well, I could also, who are the fastest talkers of our Congress and who are the slowest talkers? And this is of course not very necessary, but it is a lot of fun.
But yeah, I never used to be a fan of XML, but it does actually get the job done in this case. It's actually not so bad.
Yeah, relative to PDF, it's better, right?
Yeah, everything is better than the PDF. I mean, people, I understand that people sort of love it because it feels like it's a standard format and you have everything in there that you need. But to process it, it's nasty. I mean, for example, if you have a two column PDF file, it's actually not easy to figure out that it is a two column PDF file.
Because if you look at the postscript, it's just a sentence and a bunch of spaces and then another sentence, which is the next column. So it's all not that great.
So do you all have the filibuster over there?
Actually, no, we don't. And I try telling people that our government, our politics are also becoming wilder and less useful. But we haven't yet sunk to the level that we need a filibuster kind of thing. So for now, if you have a simple majority, you can actually get stuff done in Dutch government. But I worry where it's going.
I always thought the filibuster was just the dumbest thing. It's like, if we can just talk long enough, we can run the clock out. It's so silly. But I ask that because then do you have any blowhards? Like, do you have a ranking of like, here's our most wordy politicians versus not?
Yeah, yeah, we do. And we have these people that actually, well, they will talk your ears off. Uh, and actually it's not always who you think it is. It is, it is sort of funny to, when you run these numbers, you find out that it's actually, uh, quite often that it's different reference from what you thought it would be.
Well, we all need in government is a HACA.
Oh, excuse me.
A HACA. What's this? I may or may not be pronouncing that properly. Have y'all seen this in New Zealand? This last, like till into last year.
Yeah, no, that was very impressive. And they should do more of that.
Oh, my gosh. I'm not sure the context of the protest, but very much a spectacle. And I think we all need versions of that in ours. Describe it, Bert. Describe it in your best words.
Well, that is in New Zealand. That's what you're referring to, probably. Yes. Yeah. So they had a law that was passed, which was not good for the indigenous people in New Zealand. And then they got really upset. And then the indigenous people or the people affiliated with them in parliament actually performed the whole song.
a protest song in government, which is really a very important thing in New Zealand. But it was, I think, a great way of making a point. And I have not, I cannot imagine US Congress breaking out into a song. Oh, goodness gracious. Please, no.
I don't think, I'm not, this may be song, but I would not describe it necessarily as song. It doesn't sound very nice? It's more like a screaming song and like a dance and a performance. Like a chant, yeah. It's probably more akin to a chant. Right. Very performative. One person began it. Great demonstration. I think it's turned into a meme in terms of how to protest.
She tears up whatever it is they're protesting, and then many people that are in the parliament space begin to join in with this dance that turns into song and dance. Wow. And so it's very... it demonstrates very well. So if you feel very strongly against something, clearly it's got a very visual and a visceral process to like make you pay attention, you know? So it's interesting.
So you should check it out, Jared. I will. I'll go check that out. Well, friends, you can now build invincible application thanks to Temporal, today's sponsor. You can manage failures, network outages, flaky endpoints, long-running processes, and so much more, ensuring your workflows and your applications never fail. Temporal allows you to build business logic, not plumbing.
They deliver durable execution and abstracts away the complexity of building scalable distributed systems and lets you focus on what matters, delivering reliable systems that are faster. An example of this is Masari. They are the Bloomberg for crypto.
They provide market intelligence products to help investors navigate digital assets, and they recently turned to Temporal to help them improve the reliability of their data ingestion pipeline. This pipeline collects massive amounts of data from various sources, and then they enrich it with AI.
This process previously relied heavily on cron jobs and background jobs and cues, and the design worked well. However, these jobs were difficult to debug at scale because they needed more controls and more observability. And as they looked to rethink this ingestion flow, they wanted to avoid cron jobs, background jobs, cues.
They didn't want to create a custom orchestration system to oversee and to ensure these jobs and work was being done reliably. Here's a quote. Before temporal, we had to code for dead letter cues, circuit breakers, et cetera, to ensure we were resilient to potential system failures. Now we eliminate these complexities.
The headache of maintaining custom retry logic has vanished by using temporal end quote. So if you're ready to build invincible applications and you're ready to learn why companies like Netflix, DoorDash, and Stripe trust Temporal as their secure and scalable way to build and innovate, go to Temporal.io. Once again, Temporal.io. You can try their cloud for free or get started with open source.
Once again, Temporal.io.
Well, one thing about governments, it seems, is they... As they go on, they either incline or decline, and many of them decline. And this is a very poor way of segueing into the topic of long-term software development, which is something you've been interested in, Bert, and I'm also interested in, as we have systems that exist for decades and become quite crucial.
Software has never been more crucial in the life of everybody out there in the world than it is today. And a lot of these systems are not built to last or they weren't built to last or they thought they were building it to last, but they actually weren't. And you've done a lot of thinking and even writing and talks about long-term software development.
And I think we would all benefit from hearing your learnings and what you've been talking to other folks who've been experienced or believe about this. We all have thoughts about how you actually write for the long-term. I'm curious what you have found.
Yeah, so it was invited. So I'm a very part-time technical advisor to the Dutch government also, to what you would call the FEC, the electoral board. And they built this software for tabulating the national elections. And they are revamping it. And they said, look, would you take a look at our code? Can you tell us what you think about it?
And I looked into it and I found that they were doing sort of more or less standard 2025 software development. And then I wondered, and that means having like 1600 dependencies. Because if you have a Node.js built project these days and you install it, it will, for starters, pull in like a thousand dependencies. And then you haven't done anything yet even.
And so I looked into that and I thought, well, this is not going to be something that's viable for the next 10 years. because these dependencies change all the time and NPM might go away for the next 10 years. So I turned that into a study. What would you do these days if you had a like 10 year software project?
And I went to Mastodon, that is really good social network to ask these kinds of questions because they're like full of nerds. And they're my people. And so I asked them, I said, look, what are your thoughts for anyone doing long-term software development? And we had people weigh in that have a software with an 80, and not 18, 80-year horizon. Wow.
And these are people that study and have to measure the radioactive decay of nuclear waste. And they are tasked with measuring and supporting that for the next 80 years. And so they spent quite some time thinking about this stuff. And it turns out that actually it's sort of modern software development.
It's like sort of the complete opposite of what you would do if you want to have software that works 10 years from now. And in the sense that we have these huge, that's even building software is fragile right now.
So if you just, not even that it does the same thing, but if you want to build a sort of standard 2025 software project, you need a working internet connection and like hundreds of servers around the world that supply you with data even before your software runs. And that is not something that is a healthy thing to have if you want to promise people that it will work 10 years from now.
So I got a bunch of very strident feedback from people. They said, well, if you look at the problems that people have with old software, something goes wrong with the software. There is a problem. Something always goes wrong, of course. And then in your mature software project, you need to figure out what is actually going wrong. And the most, what almost everyone said is keep it simpler.
Of course, we all know that we should not write software that is as complicated as we can make it because that's not going to end well. But everyone said, look, we had very bad experience. We need to figure out seven years ago why this clever code, what it actually does. And then often you find that this clever code, there was no need to make it clever.
So if you have like 10 political parties or in the Netherlands, maybe fun, we have like 25 active political parties. So that's, I mean, you have two. Yeah. But can we borrow some? Yeah. Well, yeah, you could. Well, there's no, having 25 is not, not an optimum. I can tell you that.
But even if you have 25, there is no need to set up a complicated data structure to hold 25 political affiliation names. Okay. But one day you might sit there and say, hey, wouldn't it be useful? Wouldn't it be fun if we had a complicated red-black tree so that we could make really rapid searches of our 25 political parties?
And then you sit there and maybe in 2032 trying to debug why it doesn't work. And that's because you try to be clever. And like so many people came to me, they said, if I had one regret, it's that we built things too complicated. And then seven years later, no one understands the code anymore. And the other thing that people came up with is that people change jobs a lot for a number of reasons.
But if you want to do long-term software development, the easiest way to do that is with long-term employees. Because they build up knowledge, they know how the stuff works. But if you have people that are changing in and out all the time, then you become very reliant on good documentation. And it's, of course, always good to have good documentation. I mean, by me in all means, do it.
But it's very hard to compensate for all that knowledge walking out of the door. after two years. So they also, people said, look, you really need to, I mean, it's old fashioned and it's almost crazy talk these days, whether you really need to just invest in keeping your developers happy And wanting them to stay for like maybe seven years or eight years or something like that.
But again, this is also not how many places work these days anymore because they have contractors and they zoom in and they zoom out. And it's very... So it's actually... As a result, so I wrote the article based on my presentation to the Dutch electoral board and it hit Hacker News and other people. And amazingly, almost everyone agreed with it. It was very rare that it happens.
But like 30,000 or 50,000 people read it. And based on that, I got a lot more feedback. from people that said, look, we are doing nothing like this here. We are following sort of the Facebook model of software development where we deploy all the time and most days of the week it actually works. And sometimes we go through a bad patch.
But then there are all these kinds of people that have to make software that opens and closes bridges and doors and MRI scanners that could physically tear themselves apart or pacemakers or robots that actually do surgery. These people are like no one understands us anymore.
Because if we do the regular software development thing, they start with stuff that is so fragile that we would never entrust that to open or close a bridge or launch a rocket or whatever.
So it's actually becoming quite a rare skill to build the kind of software that has like safety of life consequences to a bunch of people that will start with downloading the latest JavaScript framework, even though that might be very nice for your website.
A lot of great stuff in here. Dependencies, choosing those wisely, keeping it simple, obviously. These are all, I suppose, like tried and true, kind of to some degree well-known. So it's not like you've reinvented the simplistic wheel. You just sort of collected what might be a good zeitgeist for folks to follow.
Yeah, I collected very, it is a list of extremely obvious things. But once sufficient people have sort of forgotten about the obvious things, it starts becoming worth your while to just restate the obvious things and say, look, you're not crazy. You're not, I mean, because many of these things are obvious, but also sort of old fashioned. I think it was worth restating.
Also, it has strengthened the spine of a number of people. It has reinforced them. They say, look, let's work on keeping it simple. let's refactor this stuff and let us not optimize these things before they need to be optimized.
Right. That's a big one. It's easy to get nerd sniped into premature optimizations. If we just focus on the simplicity part, let's return to dependencies and maybe talk about that in detail. But yeah, I don't think very many people set out to make a complicated solution. Unless you're just malicious or willfully ignorant or something.
You're not like, I'm going to make the worst possible solution ever. We all want to make it simple and straightforward and repeatable and reusable. These are all things that engineers, software developers strive for.
and yet it seems like we all end up making things that are too complicated anyways right like nobody's like i'm gonna make a bunch of spaghetti code and it's gonna be a terrible mess four years from now and yet we end up there and so do you have did people come up with ways that you could actually like deploy a strategy or a tactic towards simplicity yeah so i i would not actually agree that that we we all say we like simplicity this is true
But there are, for example, people that take a language standard and see it as a personal challenge to use all of it.
Because maybe that demonstrates proficiency.
Yeah. It's like, look, I'm really good at this stuff. And see how complicated this code is. And I think the only people that do this correctly are the people that feel it in their bones. That when they're typing in something complicated, they worry already about the 3 a.m. debugging session that's going to ensue five years from now because they've been through it.
They've been burnt before.
Yeah. And so I think there are actually a bunch of people that really, maybe it's controversial, but for example, programming in Rust is all the hype these days and it has many things going for it. But when I tell people, say, look, it's quite a complicated programming language, they actually like it that way. It's a challenge to write in there.
And some people actually sort of enjoy writing challenging code. And so I think the best way of writing simple code is having been on call.
Right.
That is like the one way of keeping yourself pure because you know, if I mess this up, if I write this too complicated... it's going to cost me my sleep one day. Basically deal with the mess.
You know, you do that in product. You say, Hey, do support for a bit. Hey, if you're an engineer, be on call, you know, deal with the mess that you create. Cause it's pretty easy to like write something, throw over the wall and walk away. Cause you know,
You're not on call. And in many organizations, there is actually a physical wall. It's just the people that write the code will never, they will only indirectly hear about it if there are any problems with it. And that means that the natural tendency to keep it simple because you know you're going to be stuck with the mess.
If you put an organizational barrier between dealing with the mess and writing the mess, then it maybe becomes a lot more attractive to try this new style of programming that is like impenetrable.
And that goes back to your churn mention as well. Like if you're only going to work somewhere for 12 to 18 months, unlikely that you're even going to deal with the mess that you're creating because you moved on to the next organization by the time the mess rears its ugly head. And so you actually may be thinking that you didn't make a mess because you're gone.
You never had the opportunity to find out.
You may have even gotten a bonus because you delivered in such a timeframe. Very complicated. Yeah. It's so hard. Solutions out there solving the problem. But meanwhile, there's something percolating behind the scenes. So ego kind of gets in the way. Like we want to be clever.
Yeah. And sometimes I write code that is so embarrassingly simple. And I'm like, it cannot possibly be enough. And then like five years later, you go like, well, apparently it was simple enough. Apparently it was good enough. And there's also this anticipatory thing.
So for my parliamentary monitoring system, I have a very interesting situation that in parliament are like seven or eight different kinds of important entities. There are meetings, there are documents, there are appointments. And seven or eight is that the tricky thing about that is, can you write a useful abstraction that is useful even when you only have seven sort of different things?
And you could write this lovely generic solution where you could have thousands of different kinds of entities in there. But it would be quite complicated. But because there are only seven or eight entities, it is not always necessary to build this sort of generic solution. But it does feel a little bit bad if you have a switch statement with eight kinds of categories in there.
It feels a little bit like, no, I should have built an object and inherit from that and made it all generic. And that's also the one thing I see that people are sort of anticipating huge complexity later on, but that might never happen. You might never get to that point where you needed a generic customer service class handler factory.
Right. Yeah, Agni just rears its ugly head. So I've had this, have you had this before, Barrett, where it's like, I want to create a simple solution. I go ahead and do that. I put it out in the world, and it's too simple because the world's actually more complicated than my software will handle.
And then as it kind of grows in order to handle these different edge or corner cases that I didn't consider when I was building Simply, it ends up all hairy at the end because it's like, well, it has to deal with 17 different things that might happen. And it's like, well, was there ever a simple thing that would have solved this? The real world is complicated sometimes.
And then I throw up my hands and think, I don't know. How am I actually going to do this?
Yeah, so there's one sort of telling story. So I also wrote PowerDNS, which is a name server. And we started PowerDNS in 1999. And DNS evolved over time and it added cryptography to it in DNSSEC. And initially, PowerDNS started out like really simple. And then the world turned out to be complicated and we added more and more complexity to support this cryptography in there.
And it was very difficult because DNS itself, for example, is highly case insensitive. Case really doesn't matter until you start doing hashing and encryption because that sort of, yeah, it cares about case. And usually you sort of end up then, as you described, you end up with a situation that it's just a mess.
And it's very tricky as an organization to allow yourself to say, no, we're going to clean up the mess. So we're not going to do this big, hairy, we're not going to do version two syndrome where we say, no, we're going to make the best version ever that will be so generic that it deals with everything because it doesn't work.
But what does work is actually sitting still and say, look, we're going from version two of the software to version three, and we're going to give ourselves a whole year to just do spring cleaning, house cleaning. And we're going to make the things that were too complicated, we're going to make them simple again.
And back when we used, for example, in PowerDNS, we used simple strings to deal with domain names. It turns out domain names only look like strings. They actually have more complicated semantics than that. So within PowerDNS, the big thing we did, we said, look, we're going to rip out all the strings.
And we're going to move to a dedicated DNS name class that's going to deal with all these weird DNS things. And the only way this could happen is by allowing ourselves like a year to do a cleanup. I can very much recommend doing that.
Did this turn into a business? Like was this making money at the time?
Yes, it turned into a good business. And it actually, PowerDNS is a rare example of a fully open source piece of software that actually turned into a commercial success while still remaining mostly open source.
So were there pressures on the money side to like not do that?
Yeah, there were. Yeah. But you have to have a little holistic view on that because it turns out that we could have focused on where we were making all the money. But it turns out that the reason we got paying customers was that the technical community liked what we were doing. They would recommend us everywhere.
So if we had focused on purely the technical, purely the financial bits, we would probably have had great business for a few more years. But eventually, we would not have been able to do proper DNSSEC. No one in business cares about DNSSEC. They really do not care about that. However, the nerds, the technical people that work there, they really do care about that. And we also cared about that.
So it was, in the end, a solid business decision for us to say, we're going to give ourselves a year to clean this stuff up. And I dare say that if we had not done that, the company would have gone bust later on because it would have collapsed under its own complexity.
But I do not find a lot of other examples where people gave themselves like a year, put the old software in maintenance mode, and we're going to just do cleanup for a solid year. and then come back better. That is actually a very rare thing.
That's rare.
The only one I can think of is Snow Leopard, which was Apple's version of macOS that was touted as having no new features, even though there were a few features in there, but it was an entire release cycle all focused on stability, refactoring, performance. And it is to this day many people's favorite version of macOS. Going back, everyone's like, yeah, Snow Leopard was awesome.
Yeah, well, I think as a concept, just doing a spring cleaning, yeah, we do it for other things. I mean, on equipment, you do this kind of maintenance where you replace the load-bearing parts. And take it out of service for a bit. So, yeah, but it's not very popular.
I mean, mostly you see people just having version two, second system syndrome, where they say, look, now the next version is going to be perfect. I'm going to redo everything from scratch. And then they forgot what made the old version great. That's also a thing. But just doing incremental cleanup, I very much recommend it.
Reminds me of something mechanics say that I learned recently. They say, if you don't schedule your maintenance, then your car will schedule it for you.
Yeah, exactly. That's actually also part of the blog post I wrote on the software.
Oh, is that where I read it? Okay.
That's probably where you read it. The thing I put it in there, I got it from an Australian guy. And he said, if you have dependencies in your software, schedule some time. maybe every quarter, just to take a look at all your dependencies. How are they doing? Are they still being maintained? Are the security releases coming out? Has the new VC started the monetization cycle yet?
And the idea there was that if you do this on your time schedule, you find out ahead of time that things are not going well. And the other way is that you figure it out because the stuff doesn't compile anymore.
Yeah. Right. When I was in the military, we had this really awesome term that I still live by. It is PMCS. It stands for preventative maintenance checks and services. And legitimately, every time I got into a vehicle, I could not just get into it and just drive.
I had to do this series of checklists every single time because if you don't, eventually you get bitten by this non-preventative maintenance checks and services. I had this thing called a Humvee. It was a very big vehicle. I carted around a lot of diesel fuel. In the military, we called it JP8, but it was diesel basically.
It was 2,500 gallons of very expensive fuel that I had to transport safely, securely. And if my vehicle wasn't capable of getting to and from, or there was something wrong with the tank or just anything, catastrophe could have been right around the corner. So we had this PMCS. mindset just ingrained in us from emptying out connexes to just confirm what was in there last week is still in there.
Even though everyone knew it never got opened and it never got used. We had to pull it all out, confirm it's there and put it back. It's just like the boring stuff. You have to do that mundane checks, boring stuff to make sure that what's on the rails stays on the rails.
But interestingly, it's a very interesting, good concept. I sometimes get that reaction when I tell people about unit tests and regression tests. They say, well, look, the software worked the last time I used it, so it's still going to be working.
And I'm like, well, just write some unit tests and see what happens, which is basically the sort of same thing where you just ask the computer to add two and two and you check – If it's still four. But still, so often unit tests will find that you broke stuff, even though you thought it impossible that something got broken.
So I do enjoy that mindset where I say, look, we're still going to test it every time and do that. Because you never know what happens behind your back. But there are people that are like, oh, I'm not going to write unit tests because my software worked the last time.
Right. That test suite becomes such an asset down the road. I was just updating our dependencies today and just having test coverage where I could say, okay, here's a dependency, run the tests, everything passed, update the latest, run the tests again, everything passed. It just has a peace of mind that you're like, okay, updating that dependency did not break everything.
And it's magical. PowerDNS was, of course, very old. And in 2001, we made the first regression tests and unit tests. And that was like an amazing feeling that your tests discovered that you made a mistake and they told you before you shipped. I mean, it's still a good feeling. And I sometimes give training to scientists on programming.
And when I show them the power of unit tests, they go like, wow, that's just awesome that you get an email message that you made a mistake instead of getting a complaint later on.
Yeah, it's like if you don't run your unit tests, then your customers will for you just to reapply the statement.
Yeah, that's the same kind of concept, yeah.
Well, friends, I have a question for you. How much of your personal information, your private data, how much of that is out there on the internet right now for anyone to see? I think it's more than you think. Your name, your contact info, maybe even your social security number, your home address, potentially even information about your family.
It's all being compiled by data brokers and it's being sold online. And these data brokers, they make a profit off your data. They sell it as a commodity. They don't care. Anyone on the web can buy your private details. And this can lead to identity theft, phishing attempts, harassment, unwanted spam calls. I get those so much. But now you're able to protect your privacy with Delete.me.
That's today's sponsor. I recently found delete me and they sponsor the podcast and they offer a subscription service that removes your personal info from hundreds of data sources online. Here's how it works. You sign up and you provide delete me with exactly the information you want deleted and their experts go and take it from there.
They send you regular personalized privacy reports showing you what information they found, where they found it and what they've removed. And it's not just a one time service. Delete me is always working for you. constantly monitoring and removing the personal information that you don't want on the internet.
To put it simply, delete me does all the hard work of wiping your data, your family's data from data broker websites. So take control of your data and keep your private life private by signing up for delete me today. Now at a special discount for our listeners today, you get 20% off your delete me plan by texting changelog to 64000. Once again, text changelog to 64000. 6 4 0 0 0.
And as you may know, message and data rates may apply. See terms for details. Enjoy.
Here's a question for you, Bert. How do you know how many dependencies is too many dependencies? Like, is there a heuristic? Where do I know that I've just jumped the shark?
I struggle with this myself because I do a lot of reinventing the wheel often because I know that I could spend the time learning about your dependency and then I would still be disappointed because like two years from now, the dependency will be different again. So I do often spend more time than is wise probably re-implementing some simple things.
I draw a very hard line at cryptography, for example. I mean, unless you are like a famous cryptographer, you should not be doing cryptography. You should leave that to someone else. But even then, if you look at the state of many cryptographic libraries, OpenSSL has been a sort of disaster zone for years now. But I draw a very strong line there. You do not build your own cryptography.
But on the other hand, if someone asks me to be responsible for a piece of software, and it's an important piece of software, it's not a birthday calendar. It's something that people rely on. I need to know what is in there. I need to know what I'm shipping. And if I run a modern piece of software development and I end up with like 300 dependencies, which are also included dynamically,
So at one point, I was in a situation where we said, we have to audit this software. I said, okay. And then it turned out that if you would build the software three weeks apart and you didn't change anything, it still would have changed. Because by that time, the dependencies had moved around and shifted their own dependency.
So I'm actually sort of hardcore in the sense that I don't think you can ship software with like... 300 dynamic dependencies. And people are still doing it, of course. But I do wonder what they're doing. And people have said, look, you C++ people or C people, you have one huge dependency, which is called your library. And you rely on your operating system for a lot.
And that's also like millions of lines of code. But there you have a little bit of safety blanket that everyone relies on the C library. And so there are a lot of eyes on it. And it also doesn't change that much. And we all rely on the operating system. And lots of people are looking at that. So I... I'm sort of maybe on the low end of rebuilding my own wheels too often.
But on the other hand, I still cannot understand shipping software where you say, look, I honestly do not know what is in there because it gets determined at build time. what is in there. And maybe you could audit 300 dependencies if you would have enough, but it requires a lot of work to actually sort of even figure out who is writing all these dependencies, who owns them.
So, yeah, I struggle with this because when I tell people that I simply cannot believe that you run npm install get, I counted it, 5 million lines of code come out when you do that for the most basic product. How can you ever know what is in those 5 million lines? But apparently I'm old, apparently. And it is now considered very normal. And I know for a fact that my car has NPM in there.
And I find that worrying. How do you know? Because it tells you so. There's this screen that says the copyright and the licenses and stuff. And it says, look, React is in there and NPM is in there. And I hope it's not in the driving parts of the car. I hope this is just a radio or something like that.
The entertainment sections of it, yeah.
I hope that is the case. I hope that is the case.
Yeah, the tough thing about dependencies, even when you can audit, if you can and have audited and checked out the owners and the code and the whole do your due diligence, is that what we're learning over the course of years and decades is even if you do that, if you're loading your dependencies from the network, you can't trust the network and you can trust what you think you can trust today.
You can't actually trust a year from now because the network changes. And so even if you're doing some due diligence, like you can still get bit, these so-called supply chain attacks are happening more and more often where all of a what you thought was your dependency is replaced with code that is not the same code. And that's incredibly troubling for me.
Yeah, it is. And I come from a world where people also have to develop on networks with no internet connection. And it's just basically impossible for many people to function there anymore because you try to do something and yeah, there is no internet. There is no network.
And the people that are in national security software or encryption software or that kind of stuff, intelligence agencies, they are actually in trouble because the art of developing without a fully functioning network connection That's dying out because there are lots of people that they need a runtime connected to the internet to get anything going.
And even then, your software might be relying on third-party services, CDNs somewhere. And if you're running this nuclear power plant where people say, look, we're not going to connect you to the internet, it's becoming a vanishingly rare skill of being able to build software that runs without a network connection.
One thing I appreciate about this part of your post on dependencies was just the ways that you enumerated over what might happen over time with dependencies. I'm going to read them if you don't mind. You said just basically, you know, scrutinize and limit your dependencies because all of them might over time, and here's a list, drift away.
leading to adjustments in your code or worse, silent changes within behavior. Jared, you kind of mentioned this. Shift to a new major version with cemented changes requires rewrites on your part. They might get abandoned or simply disappear or start to decay. It might get hijacked by a nation state. We've seen this happen in recent past by nation state actors, think NPM, PiPi, et cetera.
They might start to get monetized by the new VC owner who's, I guess, acquired the open source or the dependency in some way, shape, or form. And it might develop conflicting dependency requirements of their own. I think just enumerating those different things, because you think, okay, obviously the simple answer is just simple software, linear dependencies. But why?
And that's the why of those things. And it's not all the whys, but it's several versions of the why that might help you understand why you shouldn't.
Yeah. And these are, I mean, these things all happen. So I've worked with an impossible Python project that just requires two different versions of the same dependency. And they cannot do it. And you also don't know how to recover from that. But on the other hand, it is, of course, sometimes great fun that someone just moves ahead so quickly. because they embed all of Chrome in their project.
They say, yeah, boom. And then I'm sort of this ascetic person that then needs to be really, yeah, I need to work really hard to display something that looks like a webpage. And someone else has no qualms at all about embedding an entire electron copy. So it is always a bit of tension. It says, look, I'm telling you about these things that will be bad like five years from now.
And these people, hey, but I'm shipping today. So I do really feel that stuff. But especially lately we had InfluxDB, I think, which all of a sudden, which is a time series database. And I think that they have now limited you to 500 metrics or so because they want to make money. And of course, I respect that they want to make money.
But if you built your whole project on InfluxDB, yeah, you have an issue right now because your business model might not support their business model. Is this a recent change that happened, or is it something that's... Yeah, I think it's launching from the past two weeks or something like that. Is that right?
Which is why I tend to do almost everything with SQLite, because we know SQLite is going to be around forever.
and um and and we know the people that run it and um they're not going to do anything like that they don't want to do anything like that so there you know that like i can i can really i mean 100 years from now people will be able to read sqlite files it's that abundant right now so then i like i i try to stick with these things that way you be sure that look
25 years from now, they will have this software around. And so it's not going to bite me.
Kind of leans into some of the things you mentioned too down the line, which is more of a decision tree of sorts, which is how to scrutinize these dependencies. You know, what does it look like? Who else uses it? Who writes it? What are their goals? I'm kind of wondering if there's something out there that a piece of software we can sort of throw a dependency at it and it spits back
you know, some versions of all these answers, you know.
Actually, that would be good. So we, of course, have these sort of S-bombs right now, the software bill of materials. But that is only like, yeah, it's this piece of software and it's that version. But it would indeed be very interesting to say, look, this software is actually funded by this company Foundation or something like that. And it's well-funded and they'll be around forever.
Or you find that, yeah, this is actually one guy in Nebraska, the famous one guy in Nebraska. Yeah. That would be very good. But I do want to share one other technique I use to figure out how my dependencies are doing is I just use a dependency for a bit in an isolated fashion. And then I will always run into some kind of issue. There's always something.
And then engage with the project, see what happens. So you go to the project and say, hey, I just put, I did it with SQLite, for example. SQLite had a new feature for database replication and it's really cool. I really recommend it. It was very new. And I was wondering, can I build on this? Is this solid enough?
And I tried it and there was an issue and I filed an issue with the SQLite project and they fixed it in 25 minutes. And they immediately believed me that there was an issue and they were on it and it was just done. And when you do this with a dependency, you will often find out that no one responds to your worries. Because they're not paying attention.
So actually trying something and then just opening a ticket and figuring out how do they respond. And this is incredibly telling. But again, this requires work. This will require you a few hours at least per dependency to figure that out. And then people say, look, I have a thousand dependencies and I won't have time to figure that out.
And my response would then be, then you should not be shipping a thousand dependencies.
If you select a dependency wisely, it can save you hundreds of hours of effort. So maybe one or two hours spent putting the work in is worthwhile, right?
And I think it is. And there are things that, I mean, like I said with cryptography, I mean, the cryptographers out there, they have done a better job than you would ever do. Or otherwise you would be a cryptographer.
But it is, yeah, but I think it's somewhat of a lost, I mean, I tell people, you probably remember the NPM left pad thing, which was where you could left align the string and someone removed that or made it malicious. And then the whole tower of dependencies came falling down. And when I tell that these days to people, they say, look, I worry about left pad.
Then many people go like, what is left pad? Although that should be part of our sort of engineering lore, right? That says, look, do not go around depending on single line files that could be taken over by any random internet person someday.
Are these youngsters you're talking to?
Yeah, well, relatively speaking. I mean, there are many people that are like 30. And I'm starting to find people that are 30 to be a bit on the young side, but that's just me.
There you go. It's all relative.
It's all relative. But yeah, this is something... I mean, this is just the way modern software gets developed. And of course, we have the diehard to do embedded software or really the safety of life stuff. But we are in a very... in a small minority and the minority is getting smaller.
There's also new tech coming out all the time and you've been around long enough, 30 plus years in the business to know that not all that new tech is going to be additive or useful or last.
Yeah, so I did a talk on this and that actually for Dutch networking community, NLNOC, which is great. And the thing I tried to get across there was you have these new things coming along all the time, the new and shiny. And there are the people that are just always attracted to the new and shiny. And they have a glorious time discovering all kinds of new things and fun.
And there are, of course, people that are still, as I call it, rocking it with Ork. because you get stuck with, yeah, this worked for me in 1997 and it will work for me in 2029 as well. Right. You have to strike this balance to say, I enjoy the new and shiny, but not too much. And you should also let go at some point of Perl. Or org or whatever.
Specifically Perl.
Yeah. It's high time. It's high time. It's high time. Yeah. And I talked, for myself, I also sort of, I'm a bit ambivalent about this because on one hand, I love the new things and I think everyone should be. So I do a lot of JavaScript, for example, but I've also been doing C++ since like 30 years.
And people are, you could on the one hand say that C++ is starting to get old and maybe you should move on to something new. But there I decide, no, look, I'm like really good with C++ and I'm getting this stuff done. So, and I know there are issues with it, but hey, it works for me. But on the other hand, I have no problems with doing all kinds of newfangled JavaScript things.
And that was sort of the upshot of my talk where I said, look, Enjoy the new Shiny and do study it, do look into it, but don't just shift whole frameworks every few years because they are just, yeah, the bee's knees right now. But also do not get attached to your extremely old frameworks. And I think that is actually, that's why I wrote this post and did the presentation.
I think this is one of the most, biggest determinants of your technical career. If you would take a look at the technical development over like 20 or 30 years, how you look at new things really determines if you're going to be in technology for the long haul and continue to be relevant and effective, or if you have to bow out and become some kind of manager because you're no longer with it.
And managing that is, I think, a very important part of a programmer's career also.
Yeah, we're certainly in a career where you can't just learn everything you need to know at university and be done. I mean, if you're not interested in change and adaptation and learning new technologies, this isn't really the space for you. You're not going to last.
No. And, but there are, it turns out there are many employers that actually also do not believe in change. Sure. So you, you can end up in some kind of insurance place or a government tax agency and work with 25 year old technology. Right.
And COBOL on a mainframe.
Yeah, they're still rocking it over there. So it's not necessarily, you could come at a point in your life where you say, look, I don't need all these new things anymore. And I have only so many years left in my career and I'm going to spend them in a basement in some kind of insurance place. So it's not all bad, but it is something that I think you would have to just ponder for yourself.
Say, am I going to invest also? Because there comes a point in your life And I think we touched on this in this presentation also where I'm just saying, hey, these 2,000 dependencies, they're all bad. And there is a risk that at some point in your career, you go like, look, things used to be better and all this newfangled stuff is just wrong.
And when you hit that point, you have to have a real good think. Am I leaving the industry behind? Am I just old now? I'm just sort of a sad person that sits there and say, well, in my time. And you should at least when it happens, it should be a conscious decision where you say, okay, I love this old stuff more and I'm not going to pretend that my old stuff is better.
I'm just going to admit that I'm really good with this old stuff and I enjoy doing this old stuff and I'm not going to tell you that Rust is wrong or that Swift is wrong or that whatever new thing is wrong, I'm just going to enjoy my old stuff. But it's really sad to see some people see new things happening and they just get stuck in telling you how great their old stuff is.
So how many languages have you invested in seriously?
Yeah, so this is a terrible story. So I'm like, so I'm terrible at Python. So I write a lot of Python, mostly for making graphs in Matplotlib and Jupyter. But my Python is like really terrible and has been terrible for like for the past 20 years because I've never written anything. I only write scripts in Python and I've never invested in really learning that stuff.
So in Python, I'm like really the copy paste engineer. And JavaScript, I actually sort of, And made a weird decision. At one point, PowerDNS was like really not going well, my first company. And then I decided I wanted to invest some time in this new web stuff. And every serious programmer hated JavaScript with a passion. And I was like, well, that probably is the future. That was a good call.
That was a good call. I'm not going to say that. I probably just got lucky at that time. So JavaScript, I'm sort of reasonably proficient in. And C++, that's a weird thing. That's my workhorse. And the thing is I use like 20% of C++. Because over the years I've learned there is a good core in C++. It's like a really solid language and it's good stuff. And then there is a lot more stuff.
And I'm sort of a diet version of C++ where I'm like, look, I know the good parts now. I'm not leaving the good parts. I'm just staying there. So that's the other thing. And lately, I've had to admit that I'm sort of skilled at HTML now, which I never saw coming. Apparently, I got a little bit of that going. But that's really it.
I got my start with Perl, which was also sort of, I found that people were sort of, didn't take Perl seriously. And I also did not take Perl seriously. And at one point, I had to do a lot of data crunching, like millions and millions of lines crunching.
And I thought these Perlweenies, I can do this better in C. And then I found out that these Perlweenies, they do know a lot of stuff about parsing files. And so that was a humbling experience. But these days I sort of have a trifecta going of C++ and JavaScript and mostly SQLite in the backend, because I've invested a lot of time in understanding its quirks and its stuff.
And it's actually really sort of solid stuff. uh, data handling framework. And, uh, to the point that I now sort of trust SQLite files more than text files, because it's quite easy to mess up a text file. Uh, once tray, once tray carriage return, and then it's done. Sure. Uh, SQLite will not, not disappoint you on that front.
So how do you see promising technology coming?
I've actually been sort of not that happy with, for example, programming languages. If you look at the development of programming languages, you see that in the past years we've not gotten closer to the ideal programming language. So there is something wrong with every programming language right now.
So some of them, they're like really safe and some of them are really fast and some of them are really simple until you try to do complicated things. And I'm still hoping that someone someday will square that circle and have the programming language that is sort of simple and fast and safe and maybe fun, but we're not really getting there.
And the other thing I, of course, worry about, we have all these frameworks for website development, and these are also not improving. They're just changing. And one thing that I have a serious... Yeah, one thing I would love to build. If you look at any kind of software, it involves interactions.
So you have to do things with the software and you might have to sign up for a website and then you get assets that are yours and you can configure these assets. And that is a whole workflow kind of system. And I would love for us to move into developing workflows. instead of developing web pages.
Because if you look at most interactive websites, they're still like, well, we built this page for you and that page is full of conditions. It says, well, you have to fill in this, you have to fill in that, and then you can press send and then it happens.
But I would love for us to move to a higher level description where you say, look, this is a website where you can sign up for college or whatever. And this is in a domain specific programming language where we say, look, you can only move from this state to that state once you have filled out the following things.
And if we'd ever developed that, we would get so much more robust signup flows because the system is just aware of what can happen and what cannot happen. And I would love one day for someone to develop this higher level way of interaction developing. And I'm sure that it has been done in some places. But I would love to have the kind of this as infrastructure.
He would say no one has to write a transition handler anymore that decides if you filled in the right zip code or whatever. I just want a library that already knows what the zip code is as a primitive. But I don't see any of that happening. I see new iterations of ways of creating HTML pages.
And every five years you get a new sort of wave of these new frameworks, but I don't see any of that high level stuff happening.
I do see it happening as a super high level, almost no code. If you look at like form builders, you know, which we give to people and they can put in their conditionals and they can say, you know, give me a zip code widget and put it on the screen. But you know, that that's like, Not ad hoc, what's it called? When it's just like specific use for that one particular... A spoke.
A spoke, yeah, it does the one thing. So I also do presentations and you can hire me as a speaker. And my speaker agency wrote a whole low-code solution system just to do the logistics of that. And it's sort of wonderful in a way because I'm really impressed that they managed to build that mostly themselves.
But on the other hand, every time I do something with the system, it takes like three seconds to go to the next page. And I'm wondering what is it doing in the background, but it's sort of, it is impressive because it is built on this concept where you click this stuff together without having to be a real programmer.
But the thing is, I would love to be a real programmer and have the primitives that make me do this safely and at a higher level.
It's hard to resist the future, really. Like you've said, you've got to pay attention to it, but not so much that you're engulfed by it. You have to weigh it against what you know, where you've been, and where it may go. And hopefully the wisdom you've gained gives you the ability to discern that future and how it applies to your present. Otherwise, you get left.
Yeah. So I had this in this talk on dealing with change. I also mentioned AI. And then a part of the audience goes like, yeah, AI. I want to do everything with AI. And part of the audience goes like, no, it's unethical. It's bad. It's not as good. It's not reliable. And of course, it's tricky to find the middle ground in there.
When you say the AI is just astoundingly good at transcribing spoken text. It is actually super human. So there is this whisper system from open AI. It does 99 languages and even does languages where they didn't know that it could do it. And it is super human because it's better than any human being on the planet. So there is actually really good AI.
And then, of course, there are things where we still have to worry, what good is a model that just hallucinates stuff? And we could find that really bad. But it is extremely tricky for people right now to understand that, look, we could do some wonderful things with AI. It really could be good, even though there are some stupendously bad things you could do with it.
But I would love for AI to also come into our universe as serious programmers to say, hey, we have this tool for you. And it can recognize if a user enters something, the AI could say, well, this is probably not what they meant. Something like that, that looks over your shoulder.
Or something that deals with, that you have a system that has to deal with user complaints and you have an AI system that automatically does the triage and says, look, this user has a real problem and this looks like only a feature request. I would love to have those kinds of primitives.
But there are people out there that are just once so in love with AI that they're like, we're not going to need programmers anymore. And there are programmers that hate AI so much that they say we're not ever going to touch it.
And Adam, as you said, navigating that, we cannot hold back the future, but it's tricky to sort of navigate the stuff that is like good and that we should have more of while staying away from the areas where we say we're going to just replace the whole thing by an AI chatbot.
Get out of here, AI chatbots. We've had enough of you. Well, I think that this decision tree that you've got listed, which is rudimentary, it's not fully featured in terms of every possible way you would decide against choosing a dependency in this post.
I think that's a great example of where you'd throw AI at it or automation, let's just say, like the basis of automation and AI where necessary to sort of investigate a dependency and whether or not it checks against your balance. You know, does a tech look good? I mean, maybe you could, that would be a great example of throwing AI at it.
Like it can do an analysis of a code base and say, well, what does good look like? And then the model obviously depicts some of that stuff. Who writes it? That's a pretty easy one to just automate, but through databasing. But, you know, there's a lot of AI you can do here with this decision tree to make choosing dependencies slightly faster and easier.
Yeah, I have to admit, I had not thought of that yet, but people did mention it. They say, look, I have 1600 dependencies and I'm going to make the AI look at them. Yeah. It's not necessarily the worst thing to do because the AI might, in fact, very well just figure out that, look, this is just wrong or this code is already in North Korea.
um so uh yeah no it's actually as a layer as a layer it's it is probably an interesting thing to do yeah well i mean just if you've got that many dependencies it's literally impossible to investigate your own dependency tree it's better than nothing it's one of those like what do you got to lose besides maybe a few cents well what else anything else we have you have on your mind that we haven't talked about yet
No, no, I think we touched on the, yeah, we've spoken a lot about dependencies, of course. Of course. And yeah, the thing I keep harping on about, about how do you select the new things that you like, that you don't like, that's something that I would really recommend people to spend a bit more time on because it's really strange.
If you look at how we choose what technology to use, it's actually quite often a sort of random thing. It's like, hey, I found this stuff on Hacker News and I liked it and I tried it for a bit. I liked it as well. And then accidentally we pick the future direction of our career or of our software project.
So I would really recommend people sort of make more of a conscious decision on these kinds of things. But we covered that already.
yeah i don't think that's a really good point i think we do tend to overvalue social proof you know what everybody else is doing and undervalue our own ability to dig in and make a decision based on yeah one of the things i stressed in my talk also on on selecting these technologies you can use your co-workers or your the people that work with you on the project and just tell people look i'm going to present on this new thing
I found this new magical database and it does 300 million lookups per second. And these are my experiences. These are the graphs that I made. And then your own coworkers could be the filter because they might not be impressed by your story, for example.
Or you might find because you actually have to get down with it to actually make the graphs to present to your coworkers that you find that the graphs are actually not that great. And so in this way, you can both entertain the people around you with your findings and also use them as a way to keep yourself honest.
And if you don't have any coworkers around, you can write a blog or a vlog or go on a podcast or whatever, but whatever forces you to take a serious look at something and work on how would I present that to someone else?
I think if you do any of those things, I would recommend going to changelog.com slash community. That's a good place to hang. Share your findings there. Share your thoughts there. There's a thriving Zulu up there waiting for you to thread and be a part of. And it's free too.
Bert, what's the best place for folks to connect with you on the internet?
Yeah, so that's an interesting one. So I've been pretty enjoying my time on Mastodon. I think it's really a geek heaven. So that works really well. But interestingly, people ask me that question quite a lot. And I found, and I think it's very weird, a strange sort of regression. Many people are now running mailing lists again and sending out updates and newsletters and stuff.
And I found it to be a bit pompous. to write the mail updates on what Bert has been doing. But apparently there is demand for that. So I am probably going to restart a small newsletter, that kind of stuff. I also used to tell people that just follow me on LinkedIn.
But the problem there is that I'm on the one hand, I'm sort of active in Dutch politics things, which are entirely not interesting to the rest of the world. To a lot of people, sure. And the other way around, and there are many people there that follow me for the Dutch politics stuff. And they are sort of confused. They are massively confused.
And to suddenly see C++ and then they go like, what is this? So actually for the newsletter thing I'm building now, it's actually going to have like four newsletters. It's going to be one for people that like Dutch news, that like news in English, that like stuff about politics and that like stuff about technology. And you can pick your own quadrant there.
in that to see which updates you want to receive. But for now, if you go to my website, and I'm sure it will be in show notes or whatever, or you can just Google or search Bert Hubert, and then I have a website which is RSS feeds and stuff.
Nice. Yeah. Gotta love RSS. Here's a name you can name your new newsletter. You can call it Bert's Pompous Update.
Just put it right in there. Self-important things that you actually all asked for.
Yeah, just tongue-in-cheek that sucker. It always works. Cool. Love it. Appreciate you coming on the show. Nice meeting you. Adam, anything else you wanted to talk about or ask? Keep that software simple. Yeah, that's the goal.
That's the goal.
Keep that software simple. It sounds so easy, so achievable. Well, it ain't easy, that's for sure, but it is achievable if you follow some of the advice that Barrett shared with us on this episode. We'd also love to know your thoughts on building software that lasts.
Let us have them in the discussion thread, which you'll find in our Zulu community, which you can join for $0 at changelog.com slash community. Let's give one more shout out to our sponsors of this awesome conversation. Thank you to Fly. at fly.io, to Retool, retool.com slash changelog, to Temporal, find them at temporal.io, and of course to Delete.me, head to joindeleteme.com to get started.
And thanks to our Beatmaster in residence, it's the Beatfreak, Breakmaster Cylinder, we love you BMC. Oh, and we have a little bonus for our favorite kind of listener, that's a changelog++ listener of course. Stay tuned, friends. We explore what a dependency-focused AI might look like for 10 more minutes or so. All right, that's it.
This one's done, but we'll talk to you again on Change Logging, friends, on Friday.