Build software that lasts! (Interview)

30:16and 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 that was 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 are like had very bad experience like 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.

31:12So 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, having 25 is 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. 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.

31:53And that's because you try to be clever. And like so many people came to me, they said, if I have 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. And of course, but if you have people that are changing in and out all the time, then you become very reliant on good documentation.

32:29And it's, of course, always good to have good documentation. By me, 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, but 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, so 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.

33:19And amazingly, almost everyone agreed with it. It was also 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 just, 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.

34:04These 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 scale. to build the kind of software that is has like safety of life consequences to a bunch of people that 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 uh dependencies you know 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 you know reinvented the 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 you're not crazy you're not i mean because many of these things are are obvious but also sort of old-fashioned but it's i think i i think it was worth restating also it has given it has strengthened the spine of a number of people um that that that it has reinforced them they say look let's let's work on keeping it simple uh 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.

35:44If we just focus on the simplicity part, let's return to dependencies and maybe talk about that in detail. But I don't think very many people set out to make a complicated solution. Like it's not, unless you're just malicious or like willfully ignorant or something, like 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. And like, 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 going to make a bunch of spaghetti code and it's going to be a terrible mess four years from now.

36:24And 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 would not actually agree that 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. 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.

37:12debugging 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.

37:52Right. 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. Because it's pretty easy to like write something, throw over the wall and walk away because, 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.

38:29And that means that there's a 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.

39:06Yeah, you never had the opportunity to find out. You may have even gotten a bonus because you delivered in such a time frame. 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 codes 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 sort of anticipatory thing.

39:41So for my parliamentary monitoring system, I have a very interesting situation that in parliament are like seven or eight different kind 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 where you could have thousands of different kinds of entities in there and but it would be quite complicated and 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.

40:33It 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 need 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.

41:13And 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? Because 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? 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.

41:54And 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's sort of, yeah, it cares about case. And usually you sort of end up then, and 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.

42:35So we're not going to do this big, 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.

43:09It turns out domain names only look like strings. They actually have more complicated semantics than that. So within PowerDNS, the big thing we did was 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 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.

43:54So were there pressures on the money side to like not do that? Yeah, there were. Yeah. But you have to sort of 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.

44:32They 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. It would have collapsed under its own complexity. but i've 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 could think of is snow leopard which was apple's version of mac os 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 oh well and it is to this day many people's favorite version of mac os going back like everyone's like yeah snow leopard was awesome yeah yeah well that i think as a concept is doing a spring cleaning uh yeah we do it for other things i mean in on equipment you do this kind of maintenance uh where you replace the the load bearing parts and and and take it out of service for a bit so yeah but but it's not very popular i mean mostly you see you see people just having the version two second system syndrome where they say look now the next version is going to be perfect they're 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 yeah i very much recommend it reminds me 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 um has the new vc started the monetization cycle yet and and the idea there was that look 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.

47:10It is PMCS. It stands for preventative maintenance checks and services. And legitimately, like 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, you know, 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. Yeah, I was in, And 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.

47:49And 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.

48:28I 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. And so I do enjoy that mindset where I say, look, we're still going to test it every time and do that.

49:02And you never know what happens behind your back. But there are people that are like, you know, 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, OK, here's a dependency. run the tests, everything passed, update it to 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. No, and it's magical. PowerDNS was, of course, very old.

49:36And 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.

50:33Well, 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.

51:08I 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.

51:47To 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. zero zero and as you may know message and data rates may apply see terms for details enjoy

52:25here'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 i struggle with this myself um because i i do a lot of reinventing the wheel um 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 would be different different again so i 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, there is, unless you are like a famous cryptographer, you should not be doing cryptography.

53:10You 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 that 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 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.

53:50So 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 dependencies. 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 or sort of, you have one huge dependency, which is called your library.

54:37And 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'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.

55:23And 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, five 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.

56:12How do you know? Because it tells you so. There is 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.

56:57And 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 sudden 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 have to 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.

57:32There 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 as 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.

58:18One 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 it 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 etc.

59:04it 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. 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. Yeah. And these are, I mean, these things all happen. So I have, I've worked with an impossible Python project that just requires two different versions of the same dependency.

59:43and they cannot do it. So there's now, and you also don't know how to recover from that. And, 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. Yeah, boom. And then I'm sort of this ascetic person that then needs to be really, 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.

1:00:24And 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 build your whole project on influx db uh 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 it is i think it's launching from from the past two weeks or something like that right and um which is why i tend to do almost everything with sqlite uh because we know sqlite is going to be around forever.

1:01:13And we know the people that run it and 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 mean, a hundred years from now, people will be able to read SQLite files. It's that abundant right now. So then I like, 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. It 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.

1:01:49You know, what does the tip 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 be indeed be very interesting to say, look, this software is actually funded by this foundation or something like that.

1:02:22And 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, and 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, 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.

1:03:01I 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 open just and then just opening a ticket and figuring out how do how do they respond and this is incredibly telling and but again this requires work this will will require you a few hours at least per dependency uh 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 very like i said with cryptography i mean the the cryptographers out there they have done a better job than 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 you probably remember the npm left path uh thing which where you could left a line in the string and someone removed that or made it malicious and then the whole tower of dependencies came falling down.

1:04:37And when I tell that these days to people, I say, look, I worry about left path. Then many people go like, what is left path? Although that should be part of our engineering lore 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, relatively. 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.

1:05:20And of course, we have to die hard to do embedded software or really the safety of life stuff. but we are in a very, we're going to, 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, so I did a talk on this and that actually for Dutch networking community, NL Nook, which is great. and the the thing i tried to come get across there was you have these 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 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 orc uh because you get stuck with yeah this worked for me in 1997 and it will work for me in 2029 as well right um you have to strike this balance to say i i enjoy the new and shiny but not too much and you should also let go at some point of pearl or or whatever specifically pearl yeah it's high time it's high time it's high time yeah but uh and and i i talked i for myself i also sort of i'm a bit ambivalent about this because on one hand i i love the new things and and i think everyone should be so i do a lot of javascript for example uh but i've also been doing c plus plus since like 30 years and people are you could on the one hand say that c plus plus is yeah it's 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 plus plus and i'm getting the stuff done so and i know there are issues with it but hey it works for me uh but on the other hand i have no problems with doing all kinds of newfangled JavaScript things.

1:07:16And that was sort of the upshot of my talk. 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.

1:08:11and and 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 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 uh so you you can end up in some kind of insurance place or a government tax agency and work with 25 year old technology writing cobalt 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 uh i have only so many years left in my career and i'm going to spend them in a basement uh 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 thing like, I think, well, am I leaving the industry behind?

1:09:37Am I just old now? I'm just sort of a sad person that sits there and says, 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 like 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.

1:10:12So how many languages have you invested in, seriously? Yeah, so this is a terrible story. So I'm terrible at Python. So I write a lot of Python. I'm mostly for making graphs in Modplotlib and Jupyter. But my Python is really terrible. And it has been terrible 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 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.

1:10:55And 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 in a sort of diet version of C++ where I'm like, look, I know the good parts now.

1:11:38I'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. But 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, 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. And I thought these Perl weenies, I can do this better in C. And then I found out that these Perl weenies, they do know a lot of stuff about parsing files.

1:12:20And 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 data handling framework. And 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. one stray one stray carriage return and then it's done sure 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 the 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.

1:13:23So 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 series 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.

1:14:17And 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.

1:15:01And if we'd ever developed that, we would get so much more robust sign-up 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. I 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.

1:15:43I 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 at the 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 bespoke yeah it does the one thing so i have this this 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.

1:16:35But 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 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 you gotta like you've said you gotta pay attention to it but not so much that you're like 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 i had this in this talk on dealing with change, I also mentioned AI.

1:17:27And then 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 planning planet so so there is actually really good ai and and then of course there are things where we still have to worry what good is a model that just hallucinates stuff and and we could be yeah 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.

1:18:23It 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.

1:19:00I 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 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 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 yeah we've had enough of you yeah well i think that this decision tree that you've got listed, which is, you know, rudimentary.

1:19:40It'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, you know, 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 it can do an analysis of a code base and say well what does good look like and then the the model obviously depicts some of that stuff who writes it that's a pretty easy one to just automate but that through databasing but you know there's a lot of ai you can do here with this decision tree to to make choosing dependencies slightly faster and easier yeah i have to admit i i had not thought of that yet but um people did mention it they say look, I have 1600 dependencies and I'm going to make the AI look at them.

1:20:39Yeah. 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. So, yeah, no, it's actually, as a layer, it is probably an interesting thing to do. Well, I mean, just if you've got that many dependencies, is 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, Bert, what else? Anything else you have on your mind that we haven't talked about yet? No, no, I think we touched on the, yeah, we spoke a lot about dependencies, of course.

1:21:19Of 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 making more of a conscious decision on these kinds of things.

1:22:00But we covered that already. Yeah, I 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 what we find. Yeah, one of the things I stressed in my talk also on selecting these technologies, You can use your coworkers or 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.

1:22:38And 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 co-workers 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 with your findings and also use them as a a way to keep yourself honest and if you don't have any co-workers around you can write a blog or a vlog or go in a podcast or whatever but whatever forces you to take a serious look at something and work on how, how would I present that to someone else?

1:23:18I think if you do any of those things, I would recommend going to changelog.com slash community. That's a good place to hang. You know, share your findings there, share your thoughts there. There's a thriving Zulip 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 or strange sort of regression, many people are now running mailing lists again and sending out updates and newsletters and stuff.

1:24:05And I found it to be a bit pompous to write updates on what Bert has been doing. But apparently there is demand for that. So I'm 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 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. Yeah. And the other way around, and there are many people there that follow me for the Dutch politics stuff. And they're sort of confused. They are massively confused to suddenly see C++ and then they go like, what is this?

1:24:49So 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 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. Gotta love RSS. Here's a name you can name your new newsletter.

1:25:30You can call it Bert's Pompous Update. Just go right in there. Bert's self-important things that you actually all asked for. Yeah, just tongue in cheek that sucker. You know, 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.

1:25:54Keep 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 Zulip 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 DeleteMe, head to joindeleteme.com to get started.

1:26:37And 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 Changelogin' Friends on Friday.

1:27:10Thank you.

1:27:47Game on.