Navigating Through Programming's Greatest Mistakes • Mark Rendle & Hannes Lowette • GOTO 2023

Navigating Through Programming's Greatest Mistakes • Mark Rendle & Hannes Lowette • GOTO 2023

Show Video

Well, hello, my name is Hannes Lowette, I work  as head of learning and development for Axxes,   and I'm here today with Mark Rendle. And we're  here to talk about programming mistakes. Mark,   can you introduce yourself? So, hi, I am Mark Rendle and   I am a software engineer and speaker. I do  kind of lighthearted, funny talks such as   closing keynotes and lock notes and things.  I am also available for children's parties. So your talk that you're doing here at GOTO  Amsterdam is about Programming Mistakes.  Programming's Greatest Mistakes. Programming's Greatest Mistakes. Now,  

I can interpret that title in several ways, either  they could have been mistakes made by programmers,   or they could have been mistakes  in things like language designs,   or it could have been stuff that we used software  for that we maybe really shouldn't have, right? Yes. So which   angle are you attacking the mistakes from? It's mostly the first one. So it's mostly   mistakes that have been made either by  programmers or sort of someone involved   in the software development process. And for  most of them, there's a dollar value attached,   and then there's also a couple of things where  it's kind of...and then people do this when they   are programming or there is a tendency to do this,  and that is a mistake as well. And, you know,  

ending up with a particular programming  language, a script, and, yeah. But, no,   mostly it is just kind of like so they were doing  this and somebody got this wrong and this is what   happened, and this is how much money that costs. Right. Because we've all made mistakes, right?  Yes. And I put a couple of mine in there  actually because I don't wanna be kind of going,  

oh, look at all these idiots. And so  actually the first one that I talk about   is something very, very stupid that I did once. What was your own worst mistake, so to speak? I   mean, I have a couple from myself in mind, but... So the one that I talk about in the talk,   and I probably won't go into it too much here  because of bad language, but also it's gonna be   recorded so you can watch it on the GOTO channel  is about a piece of software. Someone said,   "Write this piece of software," and I gave  it a name with a very rude word in it,   and then somebody accidentally released that to  a customer with the rude words still in it. And I  

was just kinda like, yeah, okay. But that was  just a whole unprofessional kind of thing.  Right. It doesn't strike me as something  that has cost a business a lot of money   unless they lost a customer because of it. The one that I look back on and just kind of still   go, ah, was I think I was 17 very, very early  in my career. And we were at a customer's site,   and this was in the days of Unix, like pre-Linux,  '90, '91. And I had a laptop, when this is a huge   great thing with the old, sort of very slow LCD  and everything and there was no graphical user   interface. You had multiple consoles and you could  switch between the consoles by pressing ALT and  

F1, F2, F3, F4, F5 and so I had a console open, we  had a new version of the software on the laptop,   and we had the live customer system and I  was remote-shelled when it was just RSH,   there was no SSH, it was just RSH. And so I was  on the customer's actual production machine.  On one of your eight. On one of my eight consoles. And so I had   to copy the database file, and this is in the days  of CI SAM. So it was just a .dbs file that was it  

into the laptop so that we could do testing and  make sure that the new version of the software,   the database. I just kind of went, okay, so right.  I need to clear this one out. So rm -rf bin 3.dbs,   hang on. What console am I on? Who am I? Oh. So you dropped the entire database?  So I dropped the production database. This was at  about two o'clock in the afternoon. Which wouldn't   normally have been that bad, but they'd hired  four temps to do data entry, and so they'd had   four temps doing data entry for five hours solid.  So they lost 20 hours of people typing in all this   data. So that was fun, but, yeah, you know. It reminds me a little bit of where...I once  

worked for a company that made marketing software  and part of it there wasn't an online component   to it that we got from a third-party supplier was  my responsibility to set that up. I was setting   it up for a new customer and well, because we  had customers all over the world, I took a copy   of another customer that was using the same  language and a similar color design. It was   also his biggest competitor in the region where  he was located, right? Ah, so I took a copy of   the other customer to start my configuration and  part of it was a sync job that had to sync between   their on-prem system and the online one. And the  default used to be that the welcome emails to my  

customers' customers didn't go out by default. So  what we would do is we would enable the sync and   then send out the welcome emails after everything  had been set up properly. And our supplier had   changed that default, and I didn't bother to check  with them. So I enabled the sync, and the sync  

had finished by the time that we noticed that the  welcome emails had gone out in the email template   of his biggest competitor with the brand of his  biggest competitor in the emails, 60,000 emails.  Yeah. That's bad. That's worse. So that's my biggest fuck up.  That's worse than mine. That's worse than mine. Yeah. Sounds like it.  But even that sort of pales into  insignificance when you look at some   of the things where a programmer at NASA,  or the European Space Agency, or Boeing,   or whatever when they make a mistake or... There are lives at stake, and there's, like,   very expensive equipment that can burn up and... Because the talk is kind of lighthearted and it's  

just me making jokes and taking the mickey out of  people I specifically don't talk about airplanes,   medical equipment, or any time that a  programming mistake has killed people.   But when I was researching the talk, there have  been a lot of times when programming and I didn't   think I would want to write software that had  the potential to hurt people. So, you know,   like guidance systems for autopilot systems for  airplanes, there was a particular I think it was   a medical scanner which gave, like, thousands  of people a lethal dose of radiation before   they realized it was happening because it was  lethal, but it was kind of, in three months you   are going to develop tumors, right? And so in  three months, you can see a lot of people. So,   yeah, I don't talk about those because  I don't want to depress or upset people. How about like, let's take a more lighthearted  angle on that. How about we calculate like   time wasted in lifetimes? So if you do  something that wastes a lot of people's   time because of a decision that you made  in software, that also has a price tag.  

It's not a dollar amount, but it's like... That could be quite interesting if you...  I know that Tim Berners-Lee, always regretted  the http://www URL prefix because, it's like,   it doesn't need to be there. Yes. Because that's the thing   about the internet that wastes people's time. Well, at least, like, just me saying that to you.  Yes. Certainly, I mean, the... I mean, all those little bits,  

all over the world, it adds up. The http://, the www always annoyed   me because for some reason they decided that the  letter W was going to have three syllables. So   it's easier to say world... World worldwide web.  It's quicker to say worldwide web than it is to  say www. But no, I would like to know how much  

time has been lost because Windows decided it  was going to reboot itself to update and people   haven't saved their work because I think if you  added all that up, that's probably hundreds of   thousands of hours that's been wasted. A couple of lifetimes at least. Yeah. But no, the talk, it's kind of this  spacecraft blew up and it cost this much and   this building collapsed and it cost this much to  fix it. And this hedge fund lost an eye-watering   amount of money in... Because of trading?  Mark Rendle:...three hours Yeah. Automatic  trading. Yeah. And it's interesting there because   this was the error in programming that caused  the problem, but you can also discuss whether,   like you mentioned earlier, the thing that they  are doing, is that a thing that should be done. 

Exactly. Because,  these days   there are entirely autonomous little algorithms  running inside servers, inside the data centers   of the New York Stock Exchange, of the London  Stock Exchange, and so forth. Just executing   trades milliseconds apart to try and cream off  .0001% of a cent which because it all adds up   over a day, they can do hundreds of millions  of dollars of trades and so those fractions   of a percent of a cent all add up to real money. I don't know if it's an actual thing, but somebody   was explaining to me that if you wanna go into  day trading one of the things that you can take   advantage of is when the algorithms overreact  to a certain evolution in the stock price,   you can take advantage of that because you know  that like all the algorithms are selling right   now. So it's for me, the time to buy and when it  corrects itself and goes back up, you sell when   it goes back up and you make money on that. Yes. Although I have to come down sort of on  

the side of the whole trading  thing now, it's gone rotten.  The very concept of trading because, you  know, stock markets was originally a way   for people to raise money... Raise money for companies,   and invest in other companies. ...and build ships. And that sort of thing. And   now it's become, like, an autonomous algorithm. A virtual thing to make money for people  

who already have money. Exactly. And it doesn't   contribute anything to society. No. Well, no. Probably not.  And when I talk to people who disagree with me,  they just kind of go, "Well, what does Xbox or   Facebook contribute to society?" Or Bitcoin?  And I have to kind of go, oh... Well,  certainly Bitcoin. Yeah. I mean,   Bitcoin there's a version of the slide deck  somewhere that just has a single slide that says,   "Bitcoin" and the idea was I was just going to do  it and then just stand there and not say anything,   and then just move on to the next one because,  yeah, that's just a ridiculous mistake...  Would have been funny though.  It is one of  the things that I have mixed feelings about   is not Bitcoin, but blockchain technology.  I think it's a beautiful solution to a  

problem that... Doesn't exist. That nobody has. It's like technically  and theoretically, it's blockchain and the   distributed ledger and all of that. It's like,  okay, this is a great solution. And whenever I   have seen it applied, my thought has been,  this could have been done so much simpler. 

The issue with you can do a distributed  ledger where you don't need millions of   GPUs trying to guess. That is the proof of  work. I mean, you can still do proof of stake   and it takes the compute factor out of it. But even proof of stake, I mean, proof of   stake is I have enough money to take over this  thing. And there was that thing quite recently,   a guy gained the system on a particular blockchain  that gave him more than 50% of the voting rights   then voted to give himself all the money. And  then I think he borrowed money from people on this  

thing where you can borrow like cryptocurrency for  five minutes and then it automatically reverts to   the people. So there is no risk for them to  lend you the money. And so he borrowed this   enormous amount of money, used it to vote, to  give himself all the money in this blockchain,   and then it reverted and he just had all this  Ether or whatever it was. And then all the   other people who have got that sort of in that  organization, that's suddenly the point at which   they want the FBI, or Interpol, or whatever  to get involved and regulate the unregulated   currency because it turns out when code is  law, you can do some horrendous things. Yeah. 

It's one of the things that I've always found  suspicious about the whole NFT scene as well   because we're artificially inflating the  value of a digital proof of ownership,   literally. And, like, whatever it's  worth is what anybody pays for it.   But you can sell an NFT to another account made  by yourself, so you'll buy it for 200 euros and   you'll sell it to yourself for 75,000 euros. I think they call it washing or something.  Yeah. So that 75k goes from your pocket  to your pocket, so you don't really care,   but, now, you have artificially inflated  the value, the perceived value of your   digital proof of ownership. And then  you'll sell it for sheep for 30k or   whatever and there was no regulation at all. No. And I think we've pretty much established  

at this point that whether the Bored of  Ape Yacht Club knew it or not, the main   reason people were buying and selling pictures of  monkeys was that they were laundering drug money.  Probably. So you're not the pioneers of a new era of   digital creativity, you are Jason Bateman in Ozark  or Ozark or wherever that's pronounced. And so,   yeah. But no Bitcoin, that's a mistake. Yeah.  JavaScript: A Game-Changer   or a Programming Mistake? And then I have JavaScript in there. 

Sure. I mean, you don't have to preach that to me. Well, yeah. And the thing with JavaScript though,   I don't think JavaScript itself is a mistake.  And what I say in the talk is that if you know   that sort of, if you had a time machine and you  could go back and fix one thing, and I would go   to Netscape six months before.. JavaScript was released.  ...they told to Brendan Eich to create JavaScript  and just, you know, in about six months,   Mark Rendle's gonna come and ask you to create  a scripting language to put it into the browser. 

And build it properly. So I'm giving you a start   working on it now and design it properly. Also,  they're gonna ask you to make it look like Java,   don't, stick to scheme. Then just come  back and see what the internet looks like. 

I mean, it is a similar story  to VHS versus Betamax. Like,   you have a technically superior solution, but  something becoming ubiquitous in the market   dictates what everybody is going to use. And  JavaScript is a perfect example. We use it for   everything and kinda runs everywhere as well.  And we even have a song about that, don't we?  We do. We do. We'll play it tonight at GOTO,   but you as the watcher of the video, you're not  gonna see that. And it's all in jest because it's   probably one of the most used and most popular  programming languages at the moment. JavaScript  

is in no way still the language that was in  the beginning as it was released in Netscape.  Oh. It has evolved to be something   much more powerful and much more workable, but  some of the remnants are still there, right?  Yes. But I remember, you know, that  photo of [removed] The Definitive Guide   and [removed] The Good Parts... Next to The Good Parts. ... I took that photo and tweeted it back in  2010, 2011, and it went viral with 45,000 likes,   and I went from like 100 followers to 1,500  followers overnight. But, yes, JavaScript today,  

there are two good things about it. One, we now  have evergreen browsers and so apart from Safari,   there's much less weight, this is the new standard  and now it works in Edge, Chrome, Firefox,   and Safari. But, you know, so now we can use arrow  functions just natively. We don't have to worry   about running it through Babel, or TypeScript,  or whatever and there's a whole bunch of stuff   in there that we can use and make work. But I  think the thing with JavaScript at the moment   is the ecosystem around it, particularly the front  end. So React, and Vue, and Svelte, and Astro, and   NZXT, and Next, and all these different things.  Whether each of those individual technologies is   good or bad, and whether, you know, React is at  a large download size and can use Preact instead,   does Svelte have better performance and a  nicer developer experience, and all that   sort of thing. But I mean, the fact... Every one of those frameworks has been  

invented to scratch a particular itch  that has an alter head. So I would argue   that they all have a reason for being, I mean, React is interesting because they   invented it to scratch an itch, found out  it didn't scratch that itch and reverted to   a different way of doing that thing, but React  lives on, but, no, it is just the NPM and the   number of .files, and .editorconfig,  and .tsconfig.json, and package.json,   and eslint.config.json. It's just mad. It's like  COBOL and, you know, and an angular, of course.  And then the whole left bed thing that happened,  that hasn't been fixed in the entire ecosystem. 

No. It hasn't. It could happen again. If   somebody decides to pull their package, that  is a dependency for a whole bunch of things,   and there are probably thousands of packages out  there that could break a significant part of the   JavaScript ecosystem. And it's all being  compiled, well, it's not being compiled,   it's all being pulled in as a source from  NPM. So potentially we can have that again. 

If you were an immoral person, you could write a  really useful, very simple thing, put it on NPM,   and then you don't even have to figure out how to  do a bad thing yourself, you don't even actually   have to commit a crime yourself. You can just  give control of that package and that GitHub   repo to somebody who doesn't want to do a bad  thing. And so you enable them to commit a crime,   and then they can use that to install Bitcoin  mining or there's whatever it's they want to do.  Well, yeah. And there's very   little comeback on you for that. This is not a  how-to, do not do that. Okay. Please. Thank you.  Well, Bitcoin mining is stealing CPU cycles,  but JavaScript is often running on both... 

That's what JavaScript does anyway, ...front and backend. It can sniff authentication   tokens, it can get access to database connection  strings. I mean, if you have a package like that,   the impact that you can have on certain businesses  is way bigger than running some Bitcoin miners.  And this is the big thing and, you know,  to be fair, this is not just a JavaScript   thing. This is a pip Python thing. This is a  Gradle Maven thing, it's a new get thing. It's   a cargo thing, you know, even Rust with all  its guarantees. So, yeah, it's the problem.

Are you arguing that package managers are a  big mistake in the programming world as well?  Yes. I have this sort of thought that landed in my  head one day, and it's never really gone away. As   a society, as a world, there is an enormous amount  of time, energy, and money that goes into things   that we wouldn't have to do if people were just  fundamentally honest. You know, if everybody just   went, "This is my Gmail account," and all I should  have to tell the computer when I want to log into   my Gmail, "hi, it's me." And it shouldn't need  a password, because other people shouldn't want  

to read my Gmail. And I shouldn't need to keep  iterating on things, and we shouldn't need TLS,   and SSL, and HTTPS, and all these sorts of  things, we're spending vast quantities of   energy that could help us in something else. And you were talking about the stock exchange   a while ago, right? Yes. 

So, I mean, that dishonesty or, well, I wouldn't  say that stock trading is dishonest, but, like,   this trying to get ahead by exploiting whatever  people can in the system, it's something that is   probably rooted into human nature for a bit. And, you know, sometimes it is dishonest.   The 2008 thing, the big short and  the mortgage crisis and everything,   that was... That was dishonest. Mark Rendle:...fundamentally dishonest.  If you take the bottom 5% of 20 things and  

then put it together in one, that's just now  100% bad things. But then you can still say,   "Oh, this is the top 5%." Yes. But it was the  bottom five. So, yeah. But, yeah, you know,   the amount of programming time and effort and  energy that's gone into just stopping people   from being dicks or lulz, and these people... People learned the Dutch word for dick yesterday   evening while we were throwing darts because  my nickname became Lul on the dart system.  But, yeah, and it just occurred to me  how much further along would we be as   a species if all the smart people  who've had to spend their time... 

Could focus on useful stuff. Mark Rendle:...fighting human nature, had just   been able to go, "Actually, what can I do to make  the world a better place?" So, yeah, basically if   you've ever, ever done anything bad, or told a  lie, or just anything, if you are not completely   innocent and virtuous, then you've killed us all,  and I hope you're pleased with yourself. Yeah.  Wow, that took a turn for the… I should do a whole talk. Now, there are other mistakes that we  haven't talked about, but you also have   a nice talk about those mistakes. Are mistakes in  programming language design that make the job of   the programmer, let's say, less enjoyable? Yes. The worst programming language ever,   my most successful talk ever, I think added up  it's had like 5 million views total on YouTube   in various forms or something. That's very nice. 

It is. It's insane. If you haven't seen it,   look it up. It's hilarious talk. It is. I'm very, very proud of that talk. And   people think it's going to be mean. People think  it's going to be me deciding which is the worst   programming language ever, which it isn't. It  starts with a programming language that I don't   like, it's a lot better than it used to be, but  I still don't like it. But then progressively   make it worse by adding just the weirdest,  worst features of other programming languages. 

I mean, one that you made up, but that I liked  because of how evil it is, is the prime numbered   line numbers that needed to be in. Yes. Sequential primes.  Sequential primes. And as soon as  you like, want to add lime somewhere.  Yes. So that was particularly evil, but you also pulled  

stuff from other programming languages, stuff  that has already been done, but that was horrible.  Unless from Ruby which just, no, throws an  exception unless something isn't false, and he   just kind of like, "That's the wrong way round."  Yeah. And, there's a linguist, I can't remember   his name, but said, "Unless is responsible for so  much stress because you do, you say, 'bad thing,   unless...' Condition," so there's that. So you're pleading here that we should all  

be going, if this isn't true, then do that. If a bad thing has happened, then raise an   exception. Not raise an exception unless a bad  thing hasn't happened. That's just the wrong way   around. But, no, it takes date formatting from  Go, which I only learned about quite recently,   and I won't spoil it for you, but Go's date  formatting is just weird. It is weird. And   it's quite fun finding out sort of where various,  like, so it takes a vowel from fourth, I believe,   is where that came from, macros which it sort of  takes from C and C++, but then it kind of goes,   but, you know, to make macros properly powerful,  we should do them as regular expressions. And   the idea of having the compiler just run a  bunch of regular expressions over your code   as part of the build process just tickled me. But the nice thing is I've done the talk a few  

times and I always leave 10 minutes in the  end. I open it up to the room because, yeah,   I've used quite a lot of programming languages  over the last 30 years, but people have used   stuff I haven't used as, and so what would you  suggest from programming languages that you use   and you get people who've used, there's a sys  language that was used for building healthcare   software and it was called MUMPS. One of the  features of MUMPS was that you could shorten   any keyword to the minimum amount of letters  before it became unique. And so, of course,   because you could do that, everybody did  do that. So MUMPS code is unreadable. 

Oh, so instead of, while you  can maybe get away with wh?  Yes, exactly. Stuff like that.  Yes. Okay. Wow.  And so that's fun. And then now they go  on YouTube and they go viral now and then,  

and I suddenly start getting emails and things,  and the YouTube comments is just people going,   "Oh, you think that's bad, you should try  this." And it's thousands of comments.  So that's how you wrote part of that talk? I sort of pick things out that I like and I   iterate on the talk and I add stuff into  it. But no, it's great fun. And I don't   think it's mean, people worry that it's  mean, and it's kinda like, no, just...  It's a good laugh. ...if it'd picked on one language, then  

it would be mean. But saying, "I don't like that  feature of that language," and explaining why. There are a lot of mistakes in programming  language design that were meant well and have   caused us all a lot of pain. Null.  Null, for instance, yes. Like, null is  not a good way to represent nothingness. 

No. Because it can   mean a whole bunch of different things, right? Then you get JavaScript which picks up null and   just runs with it because, yeah, undefined, which  is not the same as null because if it's null,   that means somebody set it  to null. If it's undefined...  Nobody knows who set it to anything. ...then nobody set it to anything. So,   yeah, it's like a three-state Boeing or something. Well, I would argue that those are indeed two very  

different things. It's like, I have set this  to be nothing or nobody has set it to anything.   They're different. And the clean solution, in my  opinion to this is you can see it in a bunch of   functional languages where you have discriminated  unions where you can say like, if I have a person,   it could be that it is no person and you can  define that as part of a union where you have   even different types of classes that can still  be approached as one concept, which is something   that we still don't have in C#, for instance. And  it's one of the things that would make steering  

away from null as the catchall concept for  nothing would make it a whole lot more bearable.  Yes. Option, or maybe, or whatever, and being  unable to just... Or you can still... It's like   Rust has its result and you can call unwrap which  says, "Just get me the result out and if it's not   there and an error has occurred, then just dump  the process and exit out." So you can always do   that. And not having null doesn't mean you  can't do that, and having null... You know,   C# is now very good at throwing up warnings  going, "You know, that could be null where   you are doing that," and so you can at  least put some guards around it instead. 

But they're in the limbo where it is a compiler  feature and it's not baked into the runtime yet,   right? So you see all the things in your ID and  it's giving you very, very nice warnings. I think   that the evolution to be more strict about all  of this while we're programming is a good idea,   but we could do with a few more features to make  it better so that we have viable alternatives.  Yes. I sometimes wonder if it's time for kind  of C# Next and .NET Next drop a bunch of the   stuff. I think they try to do it with .NET Core. I have to say that, like, the language changes   from let's say Core 1 2016, last seven years,  right? The language has evolved tremendously and   I would say for the better, we now have almost  effortless immutability for objects which is   great, which is something that makes programming  against immutable glasses so much easier and it   makes it easier to also achieve things like  item potency and so on. Because if, you know,   it's like, I'm never gonna change the contents of  this object anymore, like why not enforce it? But   there's a whole bunch of innovations coming from  the functional ways of thinking making their way   into C# which makes it a very, very usable  language. But I don't think we're there yet. 

No. I mean there's a bunch of stuff coming in  .NET 8 with frozen dictionaries, frozen hash   sets, and frozen arrays. That's quite cool. And  like you say, discriminated, I mean, discriminated   unions would be lovely, structural typing on  interfaces. So you don't say it has to implement  

i.e. dictionary of string object. You can just say  it needs a string indexer that returns an object.   And then the compiler goes, "Yes, this does have  that," and that sort of thing, shapes, I think   they call it. Funnily enough, had something like  that when you do comm program and you see this   kind of I things, but there's also S things which  is sort of coercing it at runtime and saying,   "It will have this method if it doesn't then  blue screen." But, yes, so I think this...  That's something we still have, is we can  define an interface, but unless the actual   class implements that interface... The class has to... can not just make a class that has those  members or you cannot define an interface that   maps to members of a class that was written  by somebody else and then use that interface. You just think, you know, because C#'s  23 years old now. And so you kind of go,   right? So I have this thing that I think would  be beneficial for a lot of software projects,   which is building it as fast as you can,  as slapdash as you can, and then build it   again from scratch and take everything you  learn, building it the first time, but, now,   write it out as clean code effectively. Don't  copy and paste anything, so, yeah, build it in   three months and then build it again in a month,  but just do it right. And I think we would end  

up with much better, more maintainable purposes. I argue that that could be a practice for a lot   of enterprises as well. Absolutely.   If I would get the authority... I've had this  one customer once where we would have a deal,   we were building everything as vertical slices and  we could ship features quickly and dirty, but it   had an expiration date. So if four weeks from  now you still want to keep this as a business,   you're gonna have to invest 10 times the amount  of time to ride it properly. But in the meantime,  

we can ship quick and dirty and you can be very  responsive. And the moment that that model failed   was like, most of the time those features are  okay, we're gonna want to keep them from now.   And it's like, no, we can longer do this because  we're effectively shipping crap to protect crap.   But the advantage of that system is if you can  do it quick and dirty 1/10 of the time for the   price of two features, you can try 10 and keep 1.  And if you are in a fast-moving industry, that is  

tremendously valuable. And it surprises me that  not a lot of teams are doing that in the world.  I think the problem is that from an enterprise  point of view, from a cost center point of view,   it's nice clean, maintainable code, but doesn't  have recognizable business value. It's kind of,   well you've done it, it's working. Why am I  going to pay you to do it again? And you go,   so it's still working in 10 years. Or so we can keep maintaining it or  

whatever. And that's mainly us... But the CFO honestly doesn't care   about 10 years because he's probably  gonna have moved on by then, so, yeah.  But that's mainly us failing to communicate the  true cost of technical debt to business people.  Yeah. But it is also, I mean, sometimes it's  us, you know, just don't tell 'em it's finished,   just build it. Don't tell them it's done. Everybody has done that, right?  I worked at one place where we weren't  supposed to write automated tests,   so we wrote them and didn't  tell people. Then went, oh, no,  

those aren't automated. We have to run them  manually. But, yes, so I think if I wanted   to spend the next 20 years of my career  doing talks about programming mistakes...  There's enough of them. ...I'm pretty sure I'm never   gonna run outta material, put it that  way. So maybe I will. That'd be fun. 

Thanks so much for joining me here today.  Is there, like, a key takeaway that you   want people to have? A mistake you would like to  save them from by giving them a bit of advice.  Probably, I would say the primary mistake  that just kept popping up over and over again,   was just not sufficient testing. People build  things and they go, "Oh, it's impossible to do   testing on that." And you're kinda like, "No,  it's not. You just need to apply yourself and  

figure out how," don't assume that something is  incredibly simple and it will just work. You know,   just test. That's the biggest takeaway. The people  who can sort of go, "Well, you know, testing is   difficult," is the people who are sending robots  to Mars because It's very difficult to test   whether a robot is going to work on Mars. They do  the best they can, and so if we do the best we can   to do proper testing then we can avoid a lot... That was the opening keynote yesterday.  Yes. Somebody hit   the landing mechanism out of curiosity. I know. And then we build hydrogen-based  

airplanes, which is just... Amazing.  I love the way can you build the landing system  for the next miles rover, now I've done that,   I'm bored. Come on. Yes. I have a feeling that   you can relate to that sentiment. Oh, yeah. The ADHD is strong with this one.  And I love the fact that she went, "Well, I'm  gonna apply myself to try and improve emissions   in the airline industry and I'm gonna start  doing that and nobody's ever done it before,   but I'm gonna make it work." So if that talk's available online,   you should watch that one as well. It's amazing. And, Anita,  

we really hope that you succeed. Yes, please. Okay. Cool. Thank you.

2023-12-27 14:30

Show Video

Other news