Speaker 1: 0:04

Hello world, welcome to the Tech Overflow podcast, the podcast where we explain technical concepts to non-technical people. I'm Hannah Clayton Langton, joined today by my co-host, hugh Williams. Hugh, how's it going?

Speaker 2: 0:16

I am great, Hannah. How are you?

Speaker 1: 0:18

I'm awesome yeah, excited to be here.

Speaker 2: 0:20

I thought a great place to start would be to talk about why we're doing Tech Overflow. Tell me the background story. I thought a great place to start would be to talk about why we're doing Tech Overflow.

Speaker 1: 0:25

Tell me the background story. So, as Hugh knows, I work in the tech strategy team for a large tech company in London and when I joined the team, I was immediately overwhelmed by the number of technical concepts that were being talked about around me that I didn't understand.

Speaker 2: 0:40

There's so much jargon and so many acronyms, and I imagine that must have made your job a lot harder.

Speaker 1: 0:50

Yeah, and I sought out some counsel from the engineers around me, who were very helpful, but I sort of left with this thought in my head, which was we've got to be able to teach and talk about tech to people who haven't done a full engineering degree. There's got to be something there.

Speaker 2: 1:01

You've always been wonderful at asking questions, so I think you make the perfect co-host, but hopefully I can help with some of the answers. I mean, as you know, my background has been half in education. A lot of that's been explaining technical concepts to non-technical people, particularly in some of the MBA programs here in Australia, and the other half's been as a software engineer and as an executive in US tech companies. So hopefully I can bring something to the table that answers your questions.

Speaker 1: 1:26

Okay, so today we are going to get back to basics and we're going to be talking a little bit about coding.

Speaker 2: 1:32

Awesome, let's do it. I'm looking forward to this episode.

Speaker 1: 1:34

Okay, but before we get into the details, I have done my research and I've come up with a few fun facts about tech tech trivia, if you will. So the first fun fact I have for you which you may or may not know, is that the first computer programmer was actually a woman, which was a fact I loved, because we're already debunking some of those myths about what an archetypal coder is. So Ada Lovelace was her name and she wrote the first algorithm for a mechanical computer. Wait for this.

Speaker 2: 2:05

In the 1840s, I know a little bit about. Ada Lovelace was her name and she wrote the first algorithm for a mechanical computer wait for this in the 1840s. I know a little bit about Ada Lovelace, actually. So Ada Lovelace was this incredibly bright woman who actually was Lord Byron's daughter, who obviously is a very, very well-known poet. So the most seminal thing that she did a lot of interesting things was she translated a paper, a research paper that was written in Italian, into English and extended the paper enormously, and I think it's generally agreed that in that particular paper she really invented the idea of programming, or coding, if you like. Did you know that there's actually a programming language?

Speaker 1: 2:43

called Ada. Called Ada. Okay, no, and so who's using that?

Speaker 2: 2:47

It's used primarily by defense in the US. The story basically goes in the early 1970s. Defense was using tens, if not hundreds, of different programming languages, so it was quite chaotic. I mean, imagine working in a business where everybody spoke a different language and they decided to standardize on a language and they actually ran a competition. I think it was to invent a language. And they invented the perfect language for defense and they called it. Ada named it after Ada Lovelace.

Speaker 1: 3:15

Wow, okay. So, hugh, can you walk me and the listeners through the basics of what code actually?

Speaker 2: 3:21

is. I think a good place to start is perhaps with an analogy. I'm not much of a baker, but I think baking a cake is a pretty good analogy for coding. So if you think about baking a cake and we'll just think about a simple cake, it's really about carrying out a number of steps. First step is go get the ingredients right. So I think we're all used to sort of going to the pantry and looking for the self-raising flour, going to the fridge, getting the butter, perhaps some milk, some eggs, and bringing all those things back to the bench. So you could write that down as a series of steps right.

Speaker 2: 3:50

So you could say first of all, go to the pantry, locate the self-raising flour, get the self-raising flour out and bring it back to the bench, and we could do the same for all of the other ingredients. Once we've got those ingredients back on the bench, we start to blend them together and form the basis of a cake right. So we might get out a big Pyrex mixing bowl and sit it on the bench. Then we might get a cup and we might measure out some flour let's say it's a cup of flour and then we crack an egg, melt some butter in the microwave, mix that in stir, stir, stir. We keep on doing that. Maybe it takes 10, 20, 30 times of moving the spoon around before the cake's actually blended together. And we look at it and we say, yeah, that looks like cake mix. Then pour the cake mix into a tin, put the tin in the oven, wait a certain amount of time at a certain temperature. Eventually out comes a cake and we put the cake on the bench.

Speaker 2: 4:36

So if you think about it, what's happened there is we've carried out a series of steps and a few things happened along the way. So we we had a loop, if you like, where we tried to stir the mix and then we looked at the mix and we said not stirred enough. And we kept going around and around and around until some condition became true, and the condition was we decided that the cake was, was mixed. We also did some measuring, some testing. So different sorts of activities happened along the way and the end result was the ingredients became a cake and I. I think that's a fair analogy for coding. I think coding is really really similar. It's about carrying out step-by-step instructions with a computer, checking if conditions are true, looping around until something happens, but really it's very analogous to baking a cake in the kitchen.

Speaker 1: 5:20

Okay, this is perfect because I am a big baker, so you've happened upon an excellent analogy. So coding is basically a set of specific instructions to achieve an outcome, and the outcome in the example we've got is a cake. But I really like some of the ways you brought that to life. Somewhat rudimentary. But how do you instruct a computer Like it's just an object? It's not cognizant, so how does it know how to do the things that you're doing, or even that you're telling it to do something?

Speaker 2: 5:50

That's a great question. So it's certainly not cognizant. We're a long way from that. I'd say computers are, at their elementary level, very rudimentary pieces of equipment and so really they will follow very, very basic steps that you provide them with. But the really good news today is that most people who write code don't have to worry about those very, very rudimentary elementary steps that exist deep down in the computer. If we did, then maybe I'll go back to my baking analogy If we did have to implement those really rudimentary steps, then we wouldn't be able to say things like get out a cup measure, measure out a cup of flour and pour that into the bowl.

Speaker 2: 6:23

Implement those really rudimentary steps. Then we wouldn't be able to say things like get out a cup measure, measure out a cup of flour and pour that into the bowl. What we'd have to say is really really fundamental things. We'd have to invent what a cup is. We'd have to invent holding a cup or grabbing a cup, all these kinds of things. We'd have to do very, very rudimentary things.

Speaker 2: 6:40

But today most people who write code work in a much more what I'd call abstracted way, so they're able to express things almost in an English-like way. So if you look at modern coding languages, things like Python, it's almost readable. So, as a layperson, I think you'd be able to almost understand what the intention of the code is, because it's very much at that high level, very much sort of written out in the way that, again, you'd write out baking a cake today. We're not today talking about chopping down trees and harvesting firewood and making a fire and some way of figuring out what the temperature is and those kinds of things. We're just saying look, you go up to the oven, set it to 180 degrees Celsius and wait till it's warm, right, and so I think coding today is a lot more like that.

Speaker 1: 7:26

Okay, so we're not in milling our own flour territory, we're modern home bakers, let's say, to follow the analogy through and if I've understood correctly, I've heard the term abstraction layer and other conversations and you've used that word, abstraction so there will always be this layer of translation that takes the modern day code and breaks it down into the very, very simple instructions, but what you're saying is that sort of sits across it all the time and so you don't need to get down to that level of detail.

Speaker 2: 7:56

Exactly. Have you heard of compilers? No, no, no. What a compiler is is effectively and maybe this is making it overly simplistic but what a compiler does is it takes this sort of almost English-like expression and it compiles it into machine code and that's the code that actually literally runs inside the computer. So most folks who are programming or writing code, they'll say you know, I'm going to compile this now before I run it, so they'll take the code, they'll compile it, turns it into machine code, and then they actually run the machine code. So you'll often hear coders talking about compiling things.

Speaker 1: 8:31

Wow, okay. And so if I'm a professional software coder or computer programmer, I think at some point we'll need to talk about the difference between those two concepts. But do people need to start from the basics and learn how to do what the compiler is doing in order to be able to use it, or can they just sort of learn that higher level way to speak to the compiler and then they'll get the output they need?

Speaker 2: 8:53

Yeah, I think most people today, most modern software engineers, really don't concern themselves with the details of what actually happens inside the computer. I'd say there's a fraction, there's probably less than 1% who really care. So let's imagine, for example, that we're working at OpenAI and we're building ChatGPT. I mean, that is very, very expensive software to run. I think we all know that there's an enormous thirst at all the large tech companies for data centers and computers in those data centers and the power for those data centers. And the reason is because these large language models, things like ChatGPT, consume an enormous amount of computing power and energy. And so there's a small fraction of people who really, really want to optimize what happens deep inside the computer to try and save fractions of a percent of computation time, because that translates into millions of dollars and enormous power savings for those kinds of companies. So there's a set of people who really care, but I'd say 99 point something percent of software engineers today just don't concern themselves with the details. They just express things in these higher level languages, these sort of abstracted languages, if you like, and you know they let the computer worry about how it actually executes the details.

Speaker 1: 10:04

Okay, so those 1% are basically the food scientists understanding the fermentation of the sourdough starter, and the rest of them are just you know, home bakers, maybe even using a cake mix to get what they want.

Speaker 2: 10:18

Great analogy, love it.

Speaker 1: 10:20

So we talked a little bit about programming languages. I've heard of a few. I'll name them and you can laugh at me, maybe they won't all be actual languages. So Python I've certainly heard of, and then C C, sharp, java. I think that's probably the ones that spring to mind, but I know there's like maybe a hundred or something like that. But yeah, can you tell me a little bit more about them?

Speaker 2: 10:44

Yeah, there's definitely a Pareto curve, right. So there's definitely a set of languages that are really popular and then there's probably thousands of languages around for doing all sorts of things and some of them are very esoteric. But maybe you've named some incredibly popular languages that I'm sure many of our listeners have heard of. Python is probably the most popular programming language today. It's popular in universities and it's really popular in companies, and there's a few reasons. It's very forgiving. It's easy to get started in Python. So I would say to anybody who wants to get started learning to code, learn Python. It's a great place to start. It's also really really powerful, which is amazing. So it sort of brings two incredible things together Easy to get started and amazing for doing really complex things. It's really popular with data scientists, who are the folks who use data and machine learning and AI to create software products. You mentioned a few others. Java is really popular in enterprise companies. So those companies that sort of are SaaS companies that build software as a service. You know that typically sell their software to other companies. It's really sort of enterprise grade popular, with sort of serious engineers who they build enterprise software.

Speaker 2: 11:50

I learned c when I first became a software engineer, I love c. What I love about c is that you can build a really complex program in a very small number of characters. So it's really really powerful and it's a lot closer, I'd say, to how the machine actually runs the software than perhaps some other languages. And there's variants of it, things like C, sharp, c++. There's a few. One you didn't mention that's super popular is JavaScript. Javascript's super cool because it's the programming language, one of a very few programming languages, that runs in your web browser. So when you've got an interactive web page, a page that actually does something, which could be, you know, animation, or it could be validating your input as you type input in, or whatever the page is doing, some nice dynamic menus that you hover over, these kinds of things, that's almost certainly written in JavaScript.

Speaker 1: 12:41

Awesome. Okay, so I have a bunch more questions about programming languages, but before we get too into it, it is time ding, ding, ding for my second tech trivia fact. So did you know, hugh, that the inventor of the Python coding language did not name it after the snake, as you might think, but it's actually named after Monty Python, monty Python's Flying Circus, the British comedy show? Did you know that?

Speaker 2: 13:06

I think I'm supposed to pretend I didn't know that, so that our scores won one, but I did know that.

Speaker 1: 13:12

No, no, no. I want the true scores.

Speaker 2: 13:14

Yeah, yeah, no, I did know it was named after Monty Python's Flying Circus.

Speaker 1: 13:18

I did not, and we often use the snake emoji at work when people talk about Python, and I feel like I should be going through and correcting everyone.

Speaker 2: 13:26

You know, there's a lot of different ways you can endear yourself to a software engineer, and making Monty Python jokes is typically one of them.

Speaker 1: 13:33

Amazing. Okay, so when you select your programming language unlike an actual language, where it's pretty clear the one you need to use based on where in the world you are In computer programming, you select the language based on what you want to achieve and therefore the language that's most suited to that outcome. Is that right, that's?

Speaker 2: 13:50

right. So if we go back to Ada we talked about Ada at the very top of the show Ada is a really great language for building applications in defense, where you need to have a lot of sort of safety and care and control around what you do right. So you're programming big bits of hardware that are going to be used in in defense, and so ada is a very safe language for doing those kinds of things.

Speaker 2: 14:13

Javascript we've we've talked about that's a language for you know writing, typically writing things in the web browser, though the javascript crowd have now got JavaScript working on servers as well, because they thought it was pretty inconvenient to have to use you know JavaScript in the web browser and then have to learn some of the language that's running in the cloud. You know Java's really popular in enterprise companies. We talked about that a little bit earlier on. I'd say the folks who really want to control the low-level details of the computer really like C, and you know data scientists love Python. So I think it's very much kind of what best suits the problem that you are trying to solve.

Speaker 1: 14:49

Does every coder in a company use the same language, and do people tend to speak more than one coding language, or do you tend to grow up on one and have to find a job that uses that one?

Speaker 2: 15:01

I think it's a little bit analogous to languages that humans speak. I'd say a lot of software engineers speak one language, so they're you know, they're really expert in a particular language. But you know, it's not unusual to find somebody who can code in two languages or perhaps even three. I think some companies get a little bit out of control and they let everybody who turns up choose their own language. But of course that makes maintaining the code difficult If that person leaves. It makes it hard to add extra people to a project. Might be difficult to find somebody around the company who can actually code in that language. Most well-run companies, I think, will probably have a single digit count on a hand number of programming languages for really, really good reasons.

Speaker 1: 15:42

Okay, and if you are speaking the same or writing in the same coding language as another engineer, is it very objective, like there's only one way of saying the thing, or is that up for debate?

Speaker 2: 15:55

No, I think it's like making pizza or something. You know, there's all sorts of really important things that people really, really care about and they might strongly disagree with other people who care about those things in a slightly different way. So, no, no, there's a lot of kind of maybe religion's too strong a word, but there's a lot of sort of religion around coding. I'll give you an example.

Speaker 2: 16:18

We talked a little bit at the top of the show about loops, so the idea of doing something over and over again until something happens. So remember, we're mixing our cake and we're waiting for the batter to become batter. When you want to do something in a loop in coding in most languages you put the things that you want to do over and over again. You put those inside brackets or parentheses, and software engineers really really care whether those parentheses are on a line by themselves or whether they're at the end of a preceding line. So a little bit like the Oxford comma or whatever else it is, and different people will have really strong different opinions and so coders will argue about this stuff, but typically you'll get a prevalent style, if you like, within a particular company and the expectation generally is that people will stick to that style.

Speaker 1: 17:04

Okay, so there's a craft expertise to it. Let's say yeah, absolutely.

Speaker 2: 17:09

And there's books about beautiful code. There's books about sort of code you can marvel at, written by incredible experts in a beautiful style. So people really, really care about this stuff and they really care about the elegance of the code, the style of the code and then actually how it's laid out.

Speaker 1: 17:26

Okay, have you ever read or do you own any of these books about code?

Speaker 2: 17:30

Yeah, actually I do. I do. I probably never told you this, but 25 years ago I wrote a book. It's a coding book. Amazing, as part of the deal I got as many free books as I wanted from the publisher, so I could ask for any book and they'd send it to me. And they'd just released one that was sort of a coding kind of style, sort of art book, if you like, almost a coffee table book. And I got a copy of that and sat down and looked at some great code that people had written and put it on my coffee table.

Speaker 1: 17:59

So our latest coffee table book is about the trees of London, but we really should be upgrading it to be a coffee table book about beautiful code.

Speaker 2: 18:07

I'll find one and send it to you.

Speaker 1: 18:09

Awesome. Okay, so there's a bunch of different languages People might be proficient in. A few Companies will be very specific about what they want, likely related to the output that's required from the code. If you speak one language you sort of mentioned this, I think, with C and C sharp, if I know one language. Are there like adjacent languages? If we think about like Italian and Spanish and Portuguese, like if you know one, it will be easier to learn the next? Does that exist in the world of software languages as well?

Speaker 2: 18:36

That's a great analogy, hannah, absolutely so. I think there are a set of things that feel like Spanish, italian and French, and then there's some other languages that probably feel like Finnish. They couldn't be further away in the tree of derivation. So I think there's a lot of languages that owe their history to C, the C programming language, and so, as I mentioned earlier, c is still my favorite language and one I grew up using, so I found it, for example, pretty easy to figure out Python, because it's got a lot of C-like things about it. But there's other languages that we haven't spoken about, like Lisp and Prolog. They're a little bit more like Finnish and Lithuanian or something to most of us Esoteric.

Speaker 2: 19:18

Yeah, yeah, designed for very different purposes and you'd rarely, rarely see them today in a modern company.

Speaker 1: 19:24

And I was going to ask you what good code looks like. But it sounds like good code is in the eye of the beholder or there's an element of preference and style as well.

Speaker 2: 19:33

There's definitely an element of preference and style, but what I would say is that when you're a junior software engineer, you tend to write things that are a little bit overly complex, a little sort of verbose. It's a little bit like maybe being an undergraduate and writing your first essay at university. Right, you're probably not going to be a published author straight out of the gate, but if you do it for long enough, perhaps you study that practice writing for a long period of time eventually you can become a published author, and so I think software engineering is like that. You know, the junior folks are competent, but maybe their code's a little overly complex, has some bugs, you know those kinds of things, and as you get more senior you write more elegant, simple code that solves the problem in a way that others look at and say, wow, that's a pretty cool solution to that problem.

Speaker 1: 20:20

And would someone ever, if I was a junior software engineer, would someone red pen my code Like would they go through it and say they would? Okay, he's nodding for listeners.

Speaker 2: 20:25

Awesome question. Yeah, we have a thing called a code review in most companies, and what a code review is is you write your code and then you go and see somebody else and they review your code. So they walk through it and they provide you with suggestions and in a well-run company you're expected to address those suggestions.

Speaker 1: 20:40

Amazing. One last question, which may well be a teaser for a future episode, but is coding the same as programming, or am I actually talking at cross-purposes about different concepts here?

Speaker 2: 20:52

I think it's a little sort of like Russian dolls. So I think at the very, very center is coding, which is very literally the activity where you put your fingers on the keyboard, press the keys and out comes code. So that's very literally coding. I think the Russian doll that surrounds that is programming, and what I'd say programming is is at the center. It's got coding, sure, but it's a lot about sort of thinking about what should the solution be and how should it be formulated, and then developing the solution. And when the solution's being developed, testing the solution to make sure that it works in all the real world scenarios and then deploying that solution so that people can use it, and then the big Russian doll that sits around.

Speaker 2: 21:36

All of those is software engineering, and I'd say software engineering includes programming and includes coding inside of that. But what software engineering is is sort of zooming way out and saying, oh, what's the problem I have to solve? What are the possible solutions and tools that I could use to solve that? So it could be different programming languages, it could be different types of hardware. Think about where the data might come from that might need to be used in that particular activity, and sort of really engineering, if you like, a solution from the very beginning, all the way to that point when it's out in production and being used by people.

Speaker 1: 22:14

Okay, so with coding, the million, or probably billion dollar question that comes to mind for me is what about AI? Isn't this stuff all just going to be replaced soon, anyway, by AI tools?

Speaker 2: 22:26

I think the AI tools are incredible for software engineers. So it's really like having a co-pilot sitting next to you who helps you. So they help you create things faster, get started more easily, clean up your code, comment your code. But it really is a co-pilot. I think. A great analogy in this space to think of it like power tools to carpenters. So power tools don't replace carpenters. Power tools just allow carpenters to work more efficiently, build better products and be better at their craft.

Speaker 1: 22:55

Okay, so it will change the landscape, for sure, but it's not going to remove the need for people to be doing these types of jobs.

Speaker 2: 23:02

No, I don't see that happening in the next three to five years.

Speaker 1: 23:06

Okay, before I move us along, is there anything I've not asked you or anything I've missed that you feel is sort of fundamental to these concepts?

Speaker 2: 23:14

Probably the only thing that I'd throw in would be that computers are very, very literal, you know, and you mentioned this idea of sort of being intelligent, and I'd say they're kind of the opposite today. They will only do exactly what you tell them to do. So there is no, there's no intuition, no imagination, no sort of interpretation. They are very literal machines. So you're really like a very precise baker, very, very carefully describing all of the steps, exactly how you want them carried out, and then the computer will very, very literally, and sometimes infuriatingly, do exactly what it's told.

Speaker 1: 23:52

Okay, fair enough. So, despite what people may think and users of ChatGPT might think, these are not cognizant beings. They're literally just feeding you output based on very literal set of instructions 100%. Great. So I have many more questions, but I think we'll save them for future episodes. I think it's time to get into the tech trivia. What do you think?

Speaker 1: 24:13

Sounds good to get into the tech trivia. What do you think Sounds good? So next fun fact the first computer bug was actually a real bug. So in 1947, so this is 100 odd years after Ada Lovelace wrote the first algorithm engineers found an actual moth stuck inside. It says it was the Harvard Mark II computer. I don't know what that means, maybe you will but this actual moth was causing a malfunction and that's where we got the concept of bugs and debugging, like actually taking the moth out of I don't know what it would have been a transistor or something.

Speaker 2: 24:46

So I didn't know it was the Harvard Mark II computer and, embarrassingly, perhaps I did not know it was a moth. And I've got a question is a moth actually a bug? I'm not really sure, Maybe it is a bug. But what I do know is that the person who discovered the bug was supposedly Grace Hopper, and Grace Hopper became Rear Admiral Grace Hopper and she's probably the most famous female computer scientist that there's ever been. And in fact there's an annual conference called the Grace Hopper Conference. That's a women's conference that brings together all the women, amazing women who work in computer science together to network. And unfortunately, of course, women are the minority in computer science today. But the Grace Hopper Conference is a great way for those folks to get together and celebrate the contributions of Grace Hopper.

Speaker 1: 25:38

I love that. Big up the female computer scientists. That's the second one of the day. Okay, so I think I got half a point. The next one is that there is a tradition that all programmers the first code string that they write is and I'm going to read the string now so it's print brackets quotation mark hello, capital H comma. World. Exclamation point. Quotation mark, close bracket. So I think it's just hello world, and astute listeners will realize that we introduced the podcast up front with that. But this tradition started in 1978 in a book on C programming.

Speaker 2: 26:16

Yep, Yep, the C programming language by Koenig and Ritchie. Got that on my shelf in my house, and I think most computer scientists. When learning a new language, the first thing they'll do is just get hello world working. I will say, though, it's very, very important to have a capital H, a capital W, the comma in the middle, exactly one space between the comma and the W and the exclamation mark at the end. You will get criticized if you do it differently.

Speaker 1: 26:39

Amazing, so I did know that you knew that, but I loved that fact. Okay, next fact NASA is using code that's 40 or 50 years old. So there's spacecrafts still running on programming from the 1970s because it's still working, so they don't need to change it yeah, that's right.

Speaker 2: 26:57

Um, have you heard of the voyager 1 and voyager 2 space probes? That I have heard of so they um, two incredible pieces of engineering, um, they're both still functioning. They both left the solar system. I think the last famous thing, if you like, that voyager 1 did was it took a photo of the earth before they shut down the the camera to conserve energy, and the photo is famously known as pale blue dot.

Speaker 1: 27:23

So it's a pale blue dot, oh wow yeah and uh.

Speaker 2: 27:27

Yeah, they're still. They're still functioning. Um, you can follow them on x or twitter. Um, you can see the instructions that that are being sent to them. But they they wake them up, they get them to do various routines and things, but they haven't got many apparatus still running because they're almost out of energy. But they're still out there and still functioning. They're still running code from the 1970s.

Speaker 1: 27:47

And okay, who can actually write this code? Are there people learning it still, or are there a few sort of more mature engineers, let's say towards the end of their career, that can still write this code?

Speaker 2: 27:58

I don't know the answer, but certainly it's very valuable to be really good at coding languages that are historic. So, for example, there's a coding language called COBOL. It was very popular in the 1970s. It's one of the most verbose coding languages, so it takes lots and lots of lines of code to get anything done. It's one of the most verbose coding languages, so it takes lots and lots of lines of code to get anything done and you can get paid an enormous amount if you are a COBOL programmer today, because lots of big banks, insurance companies, these kinds of folks, telecommunications companies are still running COBOL systems. I said I was in Thailand last week. I was talking to a bank executive and most of their systems are still COBOL systems running on giant mainframe computers that they maintain themselves, and so if you're capable of writing code in COBOL you can get paid very, very well. That's probably not true for Voyager 1 and Voyager 2, because they're probably really exciting jobs to have. They probably don't have to overpay for those, but knowing historic programming languages turns out to be valuable.

Speaker 1: 28:51

Wow, okay, I have a million questions, but we'll save them for a future episode. Well, thanks so much, hugh. This has been the Tech Overflow Podcast.

Speaker 2: 28:58

And, if you've enjoyed it, follow us on LinkedIn. We're Tech Overflow Podcast.

Speaker 1: 29:02

We've also got a website, techoverflowpodcastcom, and not too hard to find on both Instagram and X, and we'll pop some interesting links and resources for you in the show notes as well, if you're interested in learning more.

Speaker 2: 29:21

Next time, if you join us again for our second episode, we're going to be talking about product management. So today we talked a lot about how software gets built. Next time we'll come back and talk about what software to build.

Speaker 1: 29:28

And I'm Hugh, I'm Hannah. We'll see you next time.