September 14, 2025 • 29 mins
Ever wondered what coding actually is but felt too intimidated to ask? You're not alone. In this beginner-friendly exploration of programming basics, we break down complex technical concepts into digestible, relatable pieces.
Our Episode 1 pilot explores the world of coding fundamentals through a metaphor: baking a cake. Just as bakers follow recipes with specific steps, measurements, and repeated actions, programmers create instructions for computers to follow. We also dive into the world of programming languages, explaining why Python is perfect for beginners while still powering advanced AI applications, how JavaScript brings websites to life, and why knowing "ancient" languages like COBOL can surprisingly lead to lucrative career opportunities today.
We also unpack the differences between coding, programming, and software engineering while addressing the burning question: will AI replace human programmers? (Spoiler: it's more like power tools for carpenters than a replacement for human creativity and problem-solving.)
Whether you're tech-curious, contemplating a career change, or simply want to understand what your software engineer friends are talking about, this episode provides a foundation for understanding the digital world around us.
If you'd like to explore a couple of links, we recommend checking out:
- Programming for Everybody (Getting Started with Python) on Coursera. A course take by over 3 million people! https://www.coursera.org/learn/python
- Hugh co-founded the Aussie charity Code For Schools that provides free and open resources to teachers who want to teach coding. Check out: https://codeforschools.com
- The story of the Voyager space probes in pictures: https://www.pbs.org/the-farthest/mission/voyager-history-photos/
- A longer feature piece on Ada Lovelace: https://writings.stephenwolfram.com/2015/12/untangling-the-tale-of-ada-lovelace/
- The Grace Hopper Conference / Celebration: https://ghc.anitab.org/
Follow us on LinkedIn at Tech Overflow Podcast or visit https://techoverflowpodcast.com for additional resources, and tune in next time as we explore the world of product management!
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:04):
Hello world, welcome to the Tech Overflow podcast,
the podcast where we explaintechnical 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 (00:16):
I am great, Hannah.
How are you?
Speaker 1 (00:18):
I'm awesome yeah, excited to be here.
Speaker 2 (00:20):
I thought a great place to start would be to talk
about why we're doing TechOverflow.
Tell me the background story.
I thought a great place tostart would be to talk about why
we're doing Tech Overflow.
Speaker 1 (00:25):
Tell me the background story.
So, as Hugh knows, I work inthe tech strategy team for a
large tech company in London andwhen I joined the team, I was
immediately overwhelmed by thenumber of technical concepts
that were being talked aboutaround me that I didn't
understand.
Speaker 2 (00:40):
There's so much jargon and so many acronyms, and
I imagine that must have madeyour job a lot harder.
Speaker 1 (00:50):
Yeah, and I sought out some counsel from the
engineers around me, who werevery 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 topeople who haven't done a full
engineering degree.
There's got to be somethingthere.
Speaker 2 (01:01):
You've always been wonderful at asking questions,
so I think you make the perfectco-host, but hopefully I can
help with some of the answers.
I mean, as you know, mybackground has been half in
education.
A lot of that's been explainingtechnical concepts to
non-technical people,particularly in some of the MBA
programs here in Australia, andthe other half's been as a
software engineer and as anexecutive in US tech companies.
(01:22):
So hopefully I can bringsomething to the table that
answers your questions.
Speaker 1 (01:26):
Okay, so today we are going to get back to basics and
we're going to be talking alittle bit about coding.
Speaker 2 (01:32):
Awesome, let's do it.
I'm looking forward to thisepisode.
Speaker 1 (01:34):
Okay, but before we get into the details, I have
done my research and I've comeup with a few fun facts about
tech tech trivia, if you will.
So the first fun fact I havefor you which you may or may not
know, is that the firstcomputer programmer was actually
a woman, which was a fact Iloved, because we're already
(01:55):
debunking some of those mythsabout what an archetypal coder
is.
So Ada Lovelace was her nameand she wrote the first
algorithm for a mechanicalcomputer.
Wait for this.
Speaker 2 (02:05):
In the 1840s, I know a little bit about.
Ada Lovelace was her name andshe wrote the first algorithm
for a mechanical computer waitfor this in the 1840s.
I know a little bit about AdaLovelace, actually.
So Ada Lovelace was thisincredibly bright woman who
actually was Lord Byron'sdaughter, who obviously is a
very, very well-known poet.
So the most seminal thing thatshe did a lot of interesting
things was she translated apaper, a research paper that was
(02:26):
written in Italian, intoEnglish and extended the paper
enormously, and I think it'sgenerally agreed that in that
particular paper she reallyinvented the idea of programming
, or coding, if you like.
Did you know that there'sactually a programming language?
Speaker 1 (02:43):
called Ada.
Called Ada.
Okay, no, and so who's usingthat?
Speaker 2 (02:47):
It's used primarily by defense in the US.
The story basically goes in theearly 1970s.
Defense was using tens, if nothundreds, of different
programming languages, so it wasquite chaotic.
I mean, imagine working in abusiness where everybody spoke a
different language and theydecided to standardize on a
language and they actually ran acompetition.
I think it was to invent alanguage.
(03:09):
And they invented the perfectlanguage for defense and they
called it.
Ada named it after Ada Lovelace.
Speaker 1 (03:15):
Wow, okay.
So, hugh, can you walk me andthe listeners through the basics
of what code actually?
Speaker 2 (03:21):
is.
I think a good place to startis perhaps with an analogy.
I'm not much of a baker, but Ithink baking a cake is a pretty
good analogy for coding.
So if you think about baking acake and we'll just think about
a simple cake, it's really aboutcarrying out a number of steps.
First step is go get theingredients right.
(03:41):
So I think we're all used tosort of going to the pantry and
looking for the self-raisingflour, going to the fridge,
getting the butter, perhaps somemilk, some eggs, and bringing
all those things back to thebench.
So you could write that down asa series of steps right.
So you could say first of all,go to the pantry, locate the
self-raising flour, get theself-raising flour out and bring
it back to the bench, and wecould do the same for all of the
other ingredients.
Once we've got thoseingredients back on the bench,
(04:01):
we start to blend them togetherand form the basis of a cake
right.
So we might get out a big Pyrexmixing bowl and sit it on the
bench.
Then we might get a cup and wemight measure out some flour
let's say it's a cup of flourand 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 timesof moving the spoon around
(04:26):
before the cake's actuallyblended together.
And we look at it and we say,yeah, that looks like cake mix.
Then pour the cake mix into atin, put the tin in the oven,
wait a certain amount of time ata certain temperature.
Eventually out comes a cake andwe put the cake on the bench.
So if you think about it, what'shappened there is we've carried
out a series of steps and a fewthings happened along the way.
So we we had a loop, if youlike, where we tried to stir the
(04:46):
mix and then we looked at themix and we said not stirred
enough.
And we kept going around andaround and around until some
condition became true, and thecondition was we decided that
the cake was, was mixed.
We also did some measuring,some testing.
So different sorts ofactivities happened along the
way and the end result was theingredients became a cake and I.
I think that's a fair analogyfor coding.
I think coding is really reallysimilar.
(05:08):
It's about carrying outstep-by-step instructions with a
computer, checking ifconditions are true, looping
around until something happens,but really it's very analogous
to baking a cake in the kitchen.
Speaker 1 (05:20):
Okay, this is perfect because I am a big baker, so
you've happened upon anexcellent analogy.
So coding is basically a set ofspecific instructions to
achieve an outcome, and theoutcome in the example we've got
is a cake.
But I really like some of theways you brought that to life.
Somewhat rudimentary.
(05:45):
But how do you instruct acomputer Like it's just an
object?
It's not cognizant, so how doesit know how to do the things
that you're doing, or even thatyou're telling it to do
something?
Speaker 2 (05: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 theirelementary level, very
rudimentary pieces of equipmentand so really they will follow
very, very basic steps that youprovide them with.
But the really good news todayis that most people who write
code don't have to worry aboutthose very, very rudimentary
(06:12):
elementary steps that exist deepdown in the computer.
If we did, then maybe I'll goback to my baking analogy If we
did have to implement thosereally rudimentary steps, then
we wouldn't be able to saythings like get out a cup
measure, measure out a cup offlour and pour that into the
bowl.
Implement those reallyrudimentary steps.
Then we wouldn't be able to saythings like get out a cup
measure, measure out a cup offlour and pour that into the
bowl.
What we'd have to say is reallyreally fundamental things.
(06:32):
We'd have to invent what a cupis.
We'd have to invent holding acup or grabbing a cup, all these
kinds of things.
We'd have to do very, veryrudimentary things.
But today most people who writecode work in a much more what
I'd call abstracted way, sothey're able to express things
almost in an English-like way.
So if you look at modern codinglanguages, things like Python,
(06:53):
it's almost readable.
So, as a layperson, I thinkyou'd be able to almost
understand what the intention ofthe code is, because it's very
much at that high level, verymuch sort of written out in the
way that, again, you'd write outbaking a cake today.
We're not today talking aboutchopping down trees and
harvesting firewood and making afire and some way of figuring
(07:14):
out what the temperature is andthose kinds of things.
We're just saying look, you goup to the oven, set it to 180
degrees Celsius and wait tillit's warm, right, and so I think
coding today is a lot more likethat.
Speaker 1 (07: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 understoodcorrectly, I've heard the term
abstraction layer and otherconversations and you've used
that word, abstraction so therewill always be this layer of
translation that takes themodern day code and breaks it
down into the very, very simpleinstructions, but what you're
(07:48):
saying is that sort of sitsacross it all the time and so
you don't need to get down tothat level of detail.
Speaker 2 (07:56):
Exactly.
Have you heard of compilers?
No, no, no.
What a compiler is iseffectively and maybe this is
making it overly simplistic butwhat a compiler does is it takes
this sort of almostEnglish-like expression and it
compiles it into machine codeand that's the code that
actually literally runs insidethe computer.
(08:16):
So most folks who areprogramming or writing code,
they'll say you know, I'm goingto compile this now before I run
it, so they'll take the code,they'll compile it, turns it
into machine code, and then theyactually run the machine code.
So you'll often hear coderstalking about compiling things.
Speaker 1 (08:31):
Wow, okay.
And so if I'm a professionalsoftware coder or computer
programmer, I think at somepoint we'll need to talk about
the difference between those twoconcepts.
But do people need to startfrom the basics and learn how to
do what the compiler is doingin order to be able to use it,
or can they just sort of learnthat higher level way to speak
to the compiler and then they'llget the output they need?
Speaker 2 (08:53):
Yeah, I think most people today, most modern
software engineers, really don'tconcern themselves with the
details of what actually happensinside 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
(09:13):
we're building ChatGPT.
I mean, that is very, veryexpensive software to run.
I think we all know thatthere's an enormous thirst at
all the large tech companies fordata centers and computers in
those data centers and the powerfor those data centers.
And the reason is because theselarge language models, things
like ChatGPT, consume anenormous amount of computing
power and energy.
And so there's a small fractionof people who really, really
(09:35):
want to optimize what happensdeep inside the computer to try
and save fractions of a percentof computation time, because
that translates into millions ofdollars and enormous power
savings for those kinds ofcompanies.
So there's a set of people whoreally care, but I'd say 99
point something percent ofsoftware engineers today just
don't concern themselves withthe details.
They just express things inthese higher level languages,
(09:57):
these sort of abstractedlanguages, if you like, and you
know they let the computer worryabout how it actually executes
the details.
Speaker 1 (10:04):
Okay, so those 1% are basically the food scientists
understanding the fermentationof the sourdough starter, and
the rest of them are just youknow, home bakers, maybe even
using a cake mix to get whatthey 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 canlaugh at me, maybe they won't
all be actual languages.
So Python I've certainly heardof, and then C C, sharp, java.
I think that's probably theones that spring to mind, but I
know there's like maybe ahundred or something like that.
(10:42):
But yeah, can you tell me alittle bit more about them?
Speaker 2 (10:44):
Yeah, there's definitely a Pareto curve, right
.
So there's definitely a set oflanguages that are really
popular and then there'sprobably thousands of languages
around for doing all sorts ofthings and some of them are very
esoteric.
But maybe you've named someincredibly popular languages
that I'm sure many of ourlisteners have heard of.
Python is probably the mostpopular programming language
today.
It's popular in universitiesand it's really popular in
(11:07):
companies, and there's a fewreasons.
It's very forgiving.
It's easy to get started inPython.
So I would say to anybody whowants to get started learning to
code, learn Python.
It's a great place to start.
It's also really reallypowerful, which is amazing.
So it sort of brings twoincredible things together Easy
to get started and amazing fordoing really complex things.
It's really popular with datascientists, who are the folks
(11:28):
who use data and machinelearning and AI to create
software products.
You mentioned a few others.
Java is really popular inenterprise companies.
So those companies that sort ofare SaaS companies that build
software as a service.
You know that typically selltheir software to other
companies.
It's really sort of enterprisegrade popular, with sort of
serious engineers who they buildenterprise software.
(11:50):
I learned c when I first becamea software engineer, I love c.
What I love about c is that youcan build a really complex
program in a very small numberof characters.
So it's really really powerfuland it's a lot closer, I'd say,
to how the machine actually runsthe software than perhaps some
other languages.
And there's variants of it,things like C, sharp, c++.
(12:12):
There's a few.
One you didn't mention that'ssuper popular is JavaScript.
Javascript's super cool becauseit's the programming language,
one of a very few programminglanguages, that runs in your web
browser.
So when you've got aninteractive web page, a page
that actually does something,which could be, you know,
animation, or it could bevalidating your input as you
type input in, or whatever thepage is doing, some nice dynamic
(12:35):
menus that you hover over,these kinds of things, that's
almost certainly written inJavaScript.
Speaker 1 (12:41):
Awesome.
Okay, so I have a bunch morequestions about programming
languages, but before we get toointo it, it is time ding, ding,
ding for my second tech triviafact.
So did you know, hugh, that theinventor of the Python coding
language did not name it afterthe snake, as you might think,
but it's actually named afterMonty Python, monty Python's
(13:01):
Flying Circus, the Britishcomedy 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, butI 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 aboutPython, and I feel like I should
be going through and correctingeveryone.
Speaker 2 (13:26):
You know, there's a lot of different ways you can
endear yourself to a softwareengineer, and making Monty
Python jokes is typically one ofthem.
Speaker 1 (13:33):
Amazing.
Okay, so when you select yourprogramming language unlike an
actual language, where it'spretty clear the one you need to
use based on where in the worldyou are In computer programming
, you select the language basedon what you want to achieve and
therefore the language that'smost suited to that outcome.
Is that right, that's?
Speaker 2 (13:50):
right.
So if we go back to Ada wetalked about Ada at the very top
of the show Ada is a reallygreat language for building
applications in defense, whereyou need to have a lot of sort
of safety and care and controlaround what you do right.
So you're programming big bitsof hardware that are going to be
used in in defense, and so adais a very safe language for
(14:11):
doing those kinds of things.
Javascript we've we've talkedabout that's a language for you
know writing, typically writingthings in the web browser,
though the javascript crowd havenow got JavaScript working on
servers as well, because theythought it was pretty
inconvenient to have to use youknow JavaScript in the web
browser and then have to learnsome of the language that's
running in the cloud.
You know Java's really popularin enterprise companies.
(14:34):
We talked about that a littlebit earlier on.
I'd say the folks who reallywant to control the low-level
details of the computer reallylike C, and you know data
scientists love Python.
So I think it's very much kindof 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 morethan one coding language, or do
you tend to grow up on one andhave 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 softwareengineers speak one language, so
they're you know, they'rereally expert in a particular
language.
But you know, it's not unusualto find somebody who can code in
two languages or perhaps eventhree.
I think some companies get alittle bit out of control and
they let everybody who turns upchoose their own language.
(15:21):
But of course that makesmaintaining the code difficult
If that person leaves.
It makes it hard to add extrapeople to a project.
Might be difficult to findsomebody around the company who
can actually code in thatlanguage.
Most well-run companies, Ithink, will probably have a
single digit count on a handnumber 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 asanother engineer, is it very
objective, like there's only oneway 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 ofreally important things that
people really, really care aboutand they might strongly
disagree with other people whocare about those things in a
slightly different way.
So, no, no, there's a lot ofkind of maybe religion's too
strong a word, but there's a lotof sort of religion around
(16:15):
coding.
I'll give you an example.
We talked a little bit at thetop of the show about loops, so
the idea of doing something overand over again until something
happens.
So remember, we're mixing ourcake and we're waiting for the
batter to become batter.
When you want to do somethingin a loop in coding in most
languages you put the thingsthat you want to do over and
over again.
You put those inside bracketsor parentheses, and software
(16:37):
engineers really really carewhether those parentheses are on
a line by themselves or whetherthey're at the end of a
preceding line.
So a little bit like the Oxfordcomma or whatever else it is,
and different people will havereally strong different opinions
and so coders will argue aboutthis stuff, but typically you'll
get a prevalent style, if youlike, within a particular
(16:59):
company and the expectationgenerally 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 ofcode you can marvel at, written
by incredible experts in abeautiful style.
So people really, really careabout this stuff and they really
care about the elegance of thecode, 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 Igot as many free books as I
wanted from the publisher, so Icould ask for any book and
they'd send it to me.
And they'd just released onethat was sort of a coding kind
of style, sort of art book, ifyou like, almost a coffee table
(17:53):
book.
And I got a copy of that andsat down and looked at some
great code that people hadwritten 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 beupgrading 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 ofdifferent languages People might
be proficient in.
A few Companies will be veryspecific about what they want,
likely related to the outputthat's required from the code.
If you speak one language yousort of mentioned this, I think,
with C and C sharp, if I knowone language.
Are there like adjacentlanguages?
If we think about like Italianand Spanish and Portuguese, like
(18:31):
if you know one, it will beeasier to learn the next?
Does that exist in the world ofsoftware languages as well?
Speaker 2 (18:36):
That's a great analogy, hannah, absolutely so.
I think there are a set ofthings that feel like Spanish,
italian and French, and thenthere's some other languages
that probably feel like Finnish.
They couldn't be further awayin the tree of derivation.
So I think there's a lot oflanguages that owe their history
to C, the C programminglanguage, and so, as I mentioned
(18:57):
earlier, c is still my favoritelanguage and one I grew up
using, so I found it, forexample, pretty easy to figure
out Python, because it's got alot of C-like things about it.
But there's other languagesthat we haven't spoken about,
like Lisp and Prolog.
They're a little bit more likeFinnish and Lithuanian or
something to most of us Esoteric.
(19:18):
Yeah, yeah, designed for verydifferent purposes and you'd
rarely, rarely see them today ina modern company.
Speaker 1 (19:24):
And I was going to ask you what good code looks
like.
But it sounds like good code isin the eye of the beholder or
there's an element of preferenceand style as well.
Speaker 2 (19:33):
There's definitely an element of preference and style
, but what I would say is thatwhen you're a junior software
engineer, you tend to writethings that are a little bit
overly complex, a little sort ofverbose.
It's a little bit like maybebeing an undergraduate and
writing your first essay atuniversity.
Right, you're probably notgoing to be a published author
straight out of the gate, but ifyou do it for long enough,
(19:53):
perhaps you study that practicewriting for a long period of
time eventually you can become apublished author, and so I
think software engineering islike that.
You know, the junior folks arecompetent, but maybe their
code's a little overly complex,has some bugs, you know those
kinds of things, and as you getmore senior you write more
elegant, simple code that solvesthe problem in a way that
others look at and say, wow,that's a pretty cool solution to
(20:15):
that problem.
Speaker 1 (20:20):
And would someone ever, if I was a junior software
engineer, would someone red penmy code Like would they go
through it and say they would?
Okay, he's nodding forlisteners.
Speaker 2 (20:25):
Awesome question.
Yeah, we have a thing called acode review in most companies,
and what a code review is is youwrite your code and then you go
and see somebody else and theyreview your code.
So they walk through it andthey provide you with
suggestions and in a well-runcompany you're expected to
address those suggestions.
Speaker 1 (20:40):
Amazing.
One last question, which maywell be a teaser for a future
episode, but is coding the sameas programming, or am I actually
talking at cross-purposes aboutdifferent concepts here?
Speaker 2 (20:52):
I think it's a little sort of like Russian dolls.
So I think at the very, verycenter is coding, which is very
literally the activity where youput your fingers on the
keyboard, press the keys and outcomes code.
So that's very literally coding.
I think the Russian doll thatsurrounds that is programming,
and what I'd say programming isis at the center.
(21:14):
It's got coding, sure, but it'sa lot about sort of thinking
about what should the solutionbe and how should it be
formulated, and then developingthe solution.
And when the solution's beingdeveloped, testing the solution
to make sure that it works inall the real world scenarios and
then deploying that solution sothat people can use it, and
then the big Russian doll thatsits around.
(21:36):
All of those is softwareengineering, and I'd say
software engineering includesprogramming and includes coding
inside of that.
But what software engineeringis is sort of zooming way out
and saying, oh, what's theproblem I have to solve?
What are the possible solutionsand tools that I could use to
solve that?
So it could be differentprogramming languages, it could
(22:02):
be different types of hardware.
Think about where the datamight come from that might need
to be used in that particularactivity, and sort of really
engineering, if you like, asolution from the very beginning
, all the way to that point whenit's out in production and
being used by people.
Speaker 1 (22:14):
Okay, so with coding, the million, or probably
billion dollar question thatcomes to mind for me is what
about AI?
Isn't this stuff all just goingto 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 aco-pilot sitting next to you who
helps you.
So they help you create thingsfaster, get started more easily,
clean up your code, commentyour code.
But it really is a co-pilot.
I think.
A great analogy in this spaceto think of it like power tools
to carpenters.
So power tools don't replacecarpenters.
(22:47):
Power tools just allowcarpenters to work more
efficiently, build betterproducts 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 theneed 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'vemissed 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, veryliteral, you know, and you
mentioned this idea of sort ofbeing intelligent, and I'd say
they're kind of the oppositetoday.
They will only do exactly whatyou tell them to do.
So there is no, there's nointuition, no imagination, no
sort of interpretation.
(23:35):
They are very literal machines.
So you're really like a veryprecise baker, very, very
carefully describing all of thesteps, exactly how you want them
carried out, and then thecomputer will very, very
literally, and sometimesinfuriatingly, do exactly what
it's told.
Speaker 1 (23:52):
Okay, fair enough.
So, despite what people maythink and users of ChatGPT might
think, these are not cognizantbeings.
They're literally just feedingyou 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 intothe tech trivia.
(24:13):
What do you think?
Sounds good to get into the techtrivia.
What do you think Sounds good?
So next fun fact the firstcomputer bug was actually a real
bug.
So in 1947, so this is 100 oddyears after Ada Lovelace wrote
the first algorithm engineersfound an actual moth stuck
inside.
It says it was the Harvard MarkII computer.
(24:33):
I don't know what that means,maybe you will but this actual
moth was causing a malfunctionand that's where we got the
concept of bugs and debugging,like actually taking the moth
out of I don't know what itwould 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 Idid not know it was a moth.
And I've got a question is amoth actually a bug?
I'm not really sure, Maybe itis a bug.
But what I do know is that theperson who discovered the bug
was supposedly Grace Hopper, andGrace Hopper became Rear
(25:10):
Admiral Grace Hopper and she'sprobably the most famous female
computer scientist that there'sever been.
And in fact there's an annualconference called the Grace
Hopper Conference.
That's a women's conferencethat brings together all the
women, amazing women who work incomputer science together to
network.
And unfortunately, of course,women are the minority in
(25:30):
computer science today.
But the Grace Hopper Conferenceis a great way for those folks
to get together and celebratethe contributions of Grace
Hopper.
Speaker 1 (25:38):
I love that.
Big up the female computerscientists.
That's the second one of theday.
Okay, so I think I got half apoint.
The next one is that there is atradition that all programmers
the first code string that theywrite is and I'm going to read
the string now so it's printbrackets quotation mark hello,
(25:59):
capital H comma.
World.
Exclamation point.
Quotation mark, close bracket.
So I think it's just helloworld, and astute listeners will
realize that we introduced thepodcast up front with that.
But this tradition started in1978 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 myhouse, 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 inthe middle, exactly one space
between the comma and the W andthe exclamation mark at the end.
You will get criticized if youdo 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 usingcode that's 40 or 50 years old.
So there's spacecrafts stillrunning 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 bothstill 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 earthbefore they shut down the the
(27:18):
camera to conserve energy, andthe 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 ortwitter.
Um, you can see theinstructions that that are being
sent to them.
But they they wake them up,they get them to do various
routines and things, but theyhaven't got many apparatus still
running because they're almostout of energy.
But they're still out there andstill functioning.
They're still running code fromthe 1970s.
Speaker 1 (27:47):
And okay, who can actually write this code?
Are there people learning itstill, or are there a few sort
of more mature engineers, let'ssay towards the end of their
career, that can still writethis code?
Speaker 2 (27:58):
I don't know the answer, but certainly it's very
valuable to be really good atcoding languages that are
historic.
So, for example, there's acoding language called COBOL.
It was very popular in the1970s.
It's one of the most verbosecoding languages, so it takes
lots and lots of lines of codeto get anything done.
It's one of the most verbosecoding languages, so it takes
lots and lots of lines of codeto get anything done and you can
(28:19):
get paid an enormous amount ifyou are a COBOL programmer today
, because lots of big banks,insurance companies, these kinds
of folks, telecommunicationscompanies are still running
COBOL systems.
I said I was in Thailand lastweek.
I was talking to a bankexecutive and most of their
systems are still COBOL systemsrunning on giant mainframe
computers that they maintainthemselves, and so if you're
capable of writing code in COBOLyou can get paid very, very
(28:41):
well.
That's probably not true forVoyager 1 and Voyager 2, because
they're probably reallyexciting jobs to have.
They probably don't have tooverpay for those, but knowing
historic programming languagesturns 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 OverflowPodcast.
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 onboth Instagram and X, and we'll
pop some interesting links andresources for you in the show
notes as well, if you'reinterested in learning more.
Speaker 2 (29:21):
Next time, if you join us again for our second
episode, we're going to betalking about product management
.
So today we talked a lot abouthow software gets built.
Next time we'll come back andtalk about what software to
build.
Speaker 1 (29:28):
And I'm Hugh, I'm Hannah.
We'll see you next time.
Hello world, welcome to the Tech Overflow podcast,
the podcast where we explaintechnical 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 (00:16):
I am great, Hannah.
How are you?
Speaker 1 (00:18):
I'm awesome yeah, excited to be here.
Speaker 2 (00:20):
I thought a great place to start would be to talk
about why we're doing TechOverflow.
Tell me the background story.
I thought a great place tostart would be to talk about why
we're doing Tech Overflow.
Speaker 1 (00:25):
Tell me the background story.
So, as Hugh knows, I work inthe tech strategy team for a
large tech company in London andwhen I joined the team, I was
immediately overwhelmed by thenumber of technical concepts
that were being talked aboutaround me that I didn't
understand.
Speaker 2 (00:40):
There's so much jargon and so many acronyms, and
I imagine that must have madeyour job a lot harder.
Speaker 1 (00:50):
Yeah, and I sought out some counsel from the
engineers around me, who werevery 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 topeople who haven't done a full
engineering degree.
There's got to be somethingthere.
Speaker 2 (01:01):
You've always been wonderful at asking questions,
so I think you make the perfectco-host, but hopefully I can
help with some of the answers.
I mean, as you know, mybackground has been half in
education.
A lot of that's been explainingtechnical concepts to
non-technical people,particularly in some of the MBA
programs here in Australia, andthe other half's been as a
software engineer and as anexecutive in US tech companies.
(01:22):
So hopefully I can bringsomething to the table that
answers your questions.
Speaker 1 (01:26):
Okay, so today we are going to get back to basics and
we're going to be talking alittle bit about coding.
Speaker 2 (01:32):
Awesome, let's do it.
I'm looking forward to thisepisode.
Speaker 1 (01:34):
Okay, but before we get into the details, I have
done my research and I've comeup with a few fun facts about
tech tech trivia, if you will.
So the first fun fact I havefor you which you may or may not
know, is that the firstcomputer programmer was actually
a woman, which was a fact Iloved, because we're already
(01:55):
debunking some of those mythsabout what an archetypal coder
is.
So Ada Lovelace was her nameand she wrote the first
algorithm for a mechanicalcomputer.
Wait for this.
Speaker 2 (02:05):
In the 1840s, I know a little bit about.
Ada Lovelace was her name andshe wrote the first algorithm
for a mechanical computer waitfor this in the 1840s.
I know a little bit about AdaLovelace, actually.
So Ada Lovelace was thisincredibly bright woman who
actually was Lord Byron'sdaughter, who obviously is a
very, very well-known poet.
So the most seminal thing thatshe did a lot of interesting
things was she translated apaper, a research paper that was
(02:26):
written in Italian, intoEnglish and extended the paper
enormously, and I think it'sgenerally agreed that in that
particular paper she reallyinvented the idea of programming
, or coding, if you like.
Did you know that there'sactually a programming language?
Speaker 1 (02:43):
called Ada.
Called Ada.
Okay, no, and so who's usingthat?
Speaker 2 (02:47):
It's used primarily by defense in the US.
The story basically goes in theearly 1970s.
Defense was using tens, if nothundreds, of different
programming languages, so it wasquite chaotic.
I mean, imagine working in abusiness where everybody spoke a
different language and theydecided to standardize on a
language and they actually ran acompetition.
I think it was to invent alanguage.
(03:09):
And they invented the perfectlanguage for defense and they
called it.
Ada named it after Ada Lovelace.
Speaker 1 (03:15):
Wow, okay.
So, hugh, can you walk me andthe listeners through the basics
of what code actually?
Speaker 2 (03:21):
is.
I think a good place to startis perhaps with an analogy.
I'm not much of a baker, but Ithink baking a cake is a pretty
good analogy for coding.
So if you think about baking acake and we'll just think about
a simple cake, it's really aboutcarrying out a number of steps.
First step is go get theingredients right.
(03:41):
So I think we're all used tosort of going to the pantry and
looking for the self-raisingflour, going to the fridge,
getting the butter, perhaps somemilk, some eggs, and bringing
all those things back to thebench.
So you could write that down asa series of steps right.
So you could say first of all,go to the pantry, locate the
self-raising flour, get theself-raising flour out and bring
it back to the bench, and wecould do the same for all of the
other ingredients.
Once we've got thoseingredients back on the bench,
(04:01):
we start to blend them togetherand form the basis of a cake
right.
So we might get out a big Pyrexmixing bowl and sit it on the
bench.
Then we might get a cup and wemight measure out some flour
let's say it's a cup of flourand 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 timesof moving the spoon around
(04:26):
before the cake's actuallyblended together.
And we look at it and we say,yeah, that looks like cake mix.
Then pour the cake mix into atin, put the tin in the oven,
wait a certain amount of time ata certain temperature.
Eventually out comes a cake andwe put the cake on the bench.
So if you think about it, what'shappened there is we've carried
out a series of steps and a fewthings happened along the way.
So we we had a loop, if youlike, where we tried to stir the
(04:46):
mix and then we looked at themix and we said not stirred
enough.
And we kept going around andaround and around until some
condition became true, and thecondition was we decided that
the cake was, was mixed.
We also did some measuring,some testing.
So different sorts ofactivities happened along the
way and the end result was theingredients became a cake and I.
I think that's a fair analogyfor coding.
I think coding is really reallysimilar.
(05:08):
It's about carrying outstep-by-step instructions with a
computer, checking ifconditions are true, looping
around until something happens,but really it's very analogous
to baking a cake in the kitchen.
Speaker 1 (05:20):
Okay, this is perfect because I am a big baker, so
you've happened upon anexcellent analogy.
So coding is basically a set ofspecific instructions to
achieve an outcome, and theoutcome in the example we've got
is a cake.
But I really like some of theways you brought that to life.
Somewhat rudimentary.
(05:45):
But how do you instruct acomputer Like it's just an
object?
It's not cognizant, so how doesit know how to do the things
that you're doing, or even thatyou're telling it to do
something?
Speaker 2 (05: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 theirelementary level, very
rudimentary pieces of equipmentand so really they will follow
very, very basic steps that youprovide them with.
But the really good news todayis that most people who write
code don't have to worry aboutthose very, very rudimentary
(06:12):
elementary steps that exist deepdown in the computer.
If we did, then maybe I'll goback to my baking analogy If we
did have to implement thosereally rudimentary steps, then
we wouldn't be able to saythings like get out a cup
measure, measure out a cup offlour and pour that into the
bowl.
Implement those reallyrudimentary steps.
Then we wouldn't be able to saythings like get out a cup
measure, measure out a cup offlour and pour that into the
bowl.
What we'd have to say is reallyreally fundamental things.
(06:32):
We'd have to invent what a cupis.
We'd have to invent holding acup or grabbing a cup, all these
kinds of things.
We'd have to do very, veryrudimentary things.
But today most people who writecode work in a much more what
I'd call abstracted way, sothey're able to express things
almost in an English-like way.
So if you look at modern codinglanguages, things like Python,
(06:53):
it's almost readable.
So, as a layperson, I thinkyou'd be able to almost
understand what the intention ofthe code is, because it's very
much at that high level, verymuch sort of written out in the
way that, again, you'd write outbaking a cake today.
We're not today talking aboutchopping down trees and
harvesting firewood and making afire and some way of figuring
(07:14):
out what the temperature is andthose kinds of things.
We're just saying look, you goup to the oven, set it to 180
degrees Celsius and wait tillit's warm, right, and so I think
coding today is a lot more likethat.
Speaker 1 (07: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 understoodcorrectly, I've heard the term
abstraction layer and otherconversations and you've used
that word, abstraction so therewill always be this layer of
translation that takes themodern day code and breaks it
down into the very, very simpleinstructions, but what you're
(07:48):
saying is that sort of sitsacross it all the time and so
you don't need to get down tothat level of detail.
Speaker 2 (07:56):
Exactly.
Have you heard of compilers?
No, no, no.
What a compiler is iseffectively and maybe this is
making it overly simplistic butwhat a compiler does is it takes
this sort of almostEnglish-like expression and it
compiles it into machine codeand that's the code that
actually literally runs insidethe computer.
(08:16):
So most folks who areprogramming or writing code,
they'll say you know, I'm goingto compile this now before I run
it, so they'll take the code,they'll compile it, turns it
into machine code, and then theyactually run the machine code.
So you'll often hear coderstalking about compiling things.
Speaker 1 (08:31):
Wow, okay.
And so if I'm a professionalsoftware coder or computer
programmer, I think at somepoint we'll need to talk about
the difference between those twoconcepts.
But do people need to startfrom the basics and learn how to
do what the compiler is doingin order to be able to use it,
or can they just sort of learnthat higher level way to speak
to the compiler and then they'llget the output they need?
Speaker 2 (08:53):
Yeah, I think most people today, most modern
software engineers, really don'tconcern themselves with the
details of what actually happensinside 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
(09:13):
we're building ChatGPT.
I mean, that is very, veryexpensive software to run.
I think we all know thatthere's an enormous thirst at
all the large tech companies fordata centers and computers in
those data centers and the powerfor those data centers.
And the reason is because theselarge language models, things
like ChatGPT, consume anenormous amount of computing
power and energy.
And so there's a small fractionof people who really, really
(09:35):
want to optimize what happensdeep inside the computer to try
and save fractions of a percentof computation time, because
that translates into millions ofdollars and enormous power
savings for those kinds ofcompanies.
So there's a set of people whoreally care, but I'd say 99
point something percent ofsoftware engineers today just
don't concern themselves withthe details.
They just express things inthese higher level languages,
(09:57):
these sort of abstractedlanguages, if you like, and you
know they let the computer worryabout how it actually executes
the details.
Speaker 1 (10:04):
Okay, so those 1% are basically the food scientists
understanding the fermentationof the sourdough starter, and
the rest of them are just youknow, home bakers, maybe even
using a cake mix to get whatthey 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 canlaugh at me, maybe they won't
all be actual languages.
So Python I've certainly heardof, and then C C, sharp, java.
I think that's probably theones that spring to mind, but I
know there's like maybe ahundred or something like that.
(10:42):
But yeah, can you tell me alittle bit more about them?
Speaker 2 (10:44):
Yeah, there's definitely a Pareto curve, right
.
So there's definitely a set oflanguages that are really
popular and then there'sprobably thousands of languages
around for doing all sorts ofthings and some of them are very
esoteric.
But maybe you've named someincredibly popular languages
that I'm sure many of ourlisteners have heard of.
Python is probably the mostpopular programming language
today.
It's popular in universitiesand it's really popular in
(11:07):
companies, and there's a fewreasons.
It's very forgiving.
It's easy to get started inPython.
So I would say to anybody whowants to get started learning to
code, learn Python.
It's a great place to start.
It's also really reallypowerful, which is amazing.
So it sort of brings twoincredible things together Easy
to get started and amazing fordoing really complex things.
It's really popular with datascientists, who are the folks
(11:28):
who use data and machinelearning and AI to create
software products.
You mentioned a few others.
Java is really popular inenterprise companies.
So those companies that sort ofare SaaS companies that build
software as a service.
You know that typically selltheir software to other
companies.
It's really sort of enterprisegrade popular, with sort of
serious engineers who they buildenterprise software.
(11:50):
I learned c when I first becamea software engineer, I love c.
What I love about c is that youcan build a really complex
program in a very small numberof characters.
So it's really really powerfuland it's a lot closer, I'd say,
to how the machine actually runsthe software than perhaps some
other languages.
And there's variants of it,things like C, sharp, c++.
(12:12):
There's a few.
One you didn't mention that'ssuper popular is JavaScript.
Javascript's super cool becauseit's the programming language,
one of a very few programminglanguages, that runs in your web
browser.
So when you've got aninteractive web page, a page
that actually does something,which could be, you know,
animation, or it could bevalidating your input as you
type input in, or whatever thepage is doing, some nice dynamic
(12:35):
menus that you hover over,these kinds of things, that's
almost certainly written inJavaScript.
Speaker 1 (12:41):
Awesome.
Okay, so I have a bunch morequestions about programming
languages, but before we get toointo it, it is time ding, ding,
ding for my second tech triviafact.
So did you know, hugh, that theinventor of the Python coding
language did not name it afterthe snake, as you might think,
but it's actually named afterMonty Python, monty Python's
(13:01):
Flying Circus, the Britishcomedy 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, butI 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 aboutPython, and I feel like I should
be going through and correctingeveryone.
Speaker 2 (13:26):
You know, there's a lot of different ways you can
endear yourself to a softwareengineer, and making Monty
Python jokes is typically one ofthem.
Speaker 1 (13:33):
Amazing.
Okay, so when you select yourprogramming language unlike an
actual language, where it'spretty clear the one you need to
use based on where in the worldyou are In computer programming
, you select the language basedon what you want to achieve and
therefore the language that'smost suited to that outcome.
Is that right, that's?
Speaker 2 (13:50):
right.
So if we go back to Ada wetalked about Ada at the very top
of the show Ada is a reallygreat language for building
applications in defense, whereyou need to have a lot of sort
of safety and care and controlaround what you do right.
So you're programming big bitsof hardware that are going to be
used in in defense, and so adais a very safe language for
(14:11):
doing those kinds of things.
Javascript we've we've talkedabout that's a language for you
know writing, typically writingthings in the web browser,
though the javascript crowd havenow got JavaScript working on
servers as well, because theythought it was pretty
inconvenient to have to use youknow JavaScript in the web
browser and then have to learnsome of the language that's
running in the cloud.
You know Java's really popularin enterprise companies.
(14:34):
We talked about that a littlebit earlier on.
I'd say the folks who reallywant to control the low-level
details of the computer reallylike C, and you know data
scientists love Python.
So I think it's very much kindof 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 morethan one coding language, or do
you tend to grow up on one andhave 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 softwareengineers speak one language, so
they're you know, they'rereally expert in a particular
language.
But you know, it's not unusualto find somebody who can code in
two languages or perhaps eventhree.
I think some companies get alittle bit out of control and
they let everybody who turns upchoose their own language.
(15:21):
But of course that makesmaintaining the code difficult
If that person leaves.
It makes it hard to add extrapeople to a project.
Might be difficult to findsomebody around the company who
can actually code in thatlanguage.
Most well-run companies, Ithink, will probably have a
single digit count on a handnumber 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 asanother engineer, is it very
objective, like there's only oneway 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 ofreally important things that
people really, really care aboutand they might strongly
disagree with other people whocare about those things in a
slightly different way.
So, no, no, there's a lot ofkind of maybe religion's too
strong a word, but there's a lotof sort of religion around
(16:15):
coding.
I'll give you an example.
We talked a little bit at thetop of the show about loops, so
the idea of doing something overand over again until something
happens.
So remember, we're mixing ourcake and we're waiting for the
batter to become batter.
When you want to do somethingin a loop in coding in most
languages you put the thingsthat you want to do over and
over again.
You put those inside bracketsor parentheses, and software
(16:37):
engineers really really carewhether those parentheses are on
a line by themselves or whetherthey're at the end of a
preceding line.
So a little bit like the Oxfordcomma or whatever else it is,
and different people will havereally strong different opinions
and so coders will argue aboutthis stuff, but typically you'll
get a prevalent style, if youlike, within a particular
(16:59):
company and the expectationgenerally 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 ofcode you can marvel at, written
by incredible experts in abeautiful style.
So people really, really careabout this stuff and they really
care about the elegance of thecode, 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 Igot as many free books as I
wanted from the publisher, so Icould ask for any book and
they'd send it to me.
And they'd just released onethat was sort of a coding kind
of style, sort of art book, ifyou like, almost a coffee table
(17:53):
book.
And I got a copy of that andsat down and looked at some
great code that people hadwritten 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 beupgrading 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 ofdifferent languages People might
be proficient in.
A few Companies will be veryspecific about what they want,
likely related to the outputthat's required from the code.
If you speak one language yousort of mentioned this, I think,
with C and C sharp, if I knowone language.
Are there like adjacentlanguages?
If we think about like Italianand Spanish and Portuguese, like
(18:31):
if you know one, it will beeasier to learn the next?
Does that exist in the world ofsoftware languages as well?
Speaker 2 (18:36):
That's a great analogy, hannah, absolutely so.
I think there are a set ofthings that feel like Spanish,
italian and French, and thenthere's some other languages
that probably feel like Finnish.
They couldn't be further awayin the tree of derivation.
So I think there's a lot oflanguages that owe their history
to C, the C programminglanguage, and so, as I mentioned
(18:57):
earlier, c is still my favoritelanguage and one I grew up
using, so I found it, forexample, pretty easy to figure
out Python, because it's got alot of C-like things about it.
But there's other languagesthat we haven't spoken about,
like Lisp and Prolog.
They're a little bit more likeFinnish and Lithuanian or
something to most of us Esoteric.
(19:18):
Yeah, yeah, designed for verydifferent purposes and you'd
rarely, rarely see them today ina modern company.
Speaker 1 (19:24):
And I was going to ask you what good code looks
like.
But it sounds like good code isin the eye of the beholder or
there's an element of preferenceand style as well.
Speaker 2 (19:33):
There's definitely an element of preference and style
, but what I would say is thatwhen you're a junior software
engineer, you tend to writethings that are a little bit
overly complex, a little sort ofverbose.
It's a little bit like maybebeing an undergraduate and
writing your first essay atuniversity.
Right, you're probably notgoing to be a published author
straight out of the gate, but ifyou do it for long enough,
(19:53):
perhaps you study that practicewriting for a long period of
time eventually you can become apublished author, and so I
think software engineering islike that.
You know, the junior folks arecompetent, but maybe their
code's a little overly complex,has some bugs, you know those
kinds of things, and as you getmore senior you write more
elegant, simple code that solvesthe problem in a way that
others look at and say, wow,that's a pretty cool solution to
(20:15):
that problem.
Speaker 1 (20:20):
And would someone ever, if I was a junior software
engineer, would someone red penmy code Like would they go
through it and say they would?
Okay, he's nodding forlisteners.
Speaker 2 (20:25):
Awesome question.
Yeah, we have a thing called acode review in most companies,
and what a code review is is youwrite your code and then you go
and see somebody else and theyreview your code.
So they walk through it andthey provide you with
suggestions and in a well-runcompany you're expected to
address those suggestions.
Speaker 1 (20:40):
Amazing.
One last question, which maywell be a teaser for a future
episode, but is coding the sameas programming, or am I actually
talking at cross-purposes aboutdifferent concepts here?
Speaker 2 (20:52):
I think it's a little sort of like Russian dolls.
So I think at the very, verycenter is coding, which is very
literally the activity where youput your fingers on the
keyboard, press the keys and outcomes code.
So that's very literally coding.
I think the Russian doll thatsurrounds that is programming,
and what I'd say programming isis at the center.
(21:14):
It's got coding, sure, but it'sa lot about sort of thinking
about what should the solutionbe and how should it be
formulated, and then developingthe solution.
And when the solution's beingdeveloped, testing the solution
to make sure that it works inall the real world scenarios and
then deploying that solution sothat people can use it, and
then the big Russian doll thatsits around.
(21:36):
All of those is softwareengineering, and I'd say
software engineering includesprogramming and includes coding
inside of that.
But what software engineeringis is sort of zooming way out
and saying, oh, what's theproblem I have to solve?
What are the possible solutionsand tools that I could use to
solve that?
So it could be differentprogramming languages, it could
(22:02):
be different types of hardware.
Think about where the datamight come from that might need
to be used in that particularactivity, and sort of really
engineering, if you like, asolution from the very beginning
, all the way to that point whenit's out in production and
being used by people.
Speaker 1 (22:14):
Okay, so with coding, the million, or probably
billion dollar question thatcomes to mind for me is what
about AI?
Isn't this stuff all just goingto 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 aco-pilot sitting next to you who
helps you.
So they help you create thingsfaster, get started more easily,
clean up your code, commentyour code.
But it really is a co-pilot.
I think.
A great analogy in this spaceto think of it like power tools
to carpenters.
So power tools don't replacecarpenters.
(22:47):
Power tools just allowcarpenters to work more
efficiently, build betterproducts 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 theneed 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'vemissed 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, veryliteral, you know, and you
mentioned this idea of sort ofbeing intelligent, and I'd say
they're kind of the oppositetoday.
They will only do exactly whatyou tell them to do.
So there is no, there's nointuition, no imagination, no
sort of interpretation.
(23:35):
They are very literal machines.
So you're really like a veryprecise baker, very, very
carefully describing all of thesteps, exactly how you want them
carried out, and then thecomputer will very, very
literally, and sometimesinfuriatingly, do exactly what
it's told.
Speaker 1 (23:52):
Okay, fair enough.
So, despite what people maythink and users of ChatGPT might
think, these are not cognizantbeings.
They're literally just feedingyou 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 intothe tech trivia.
(24:13):
What do you think?
Sounds good to get into the techtrivia.
What do you think Sounds good?
So next fun fact the firstcomputer bug was actually a real
bug.
So in 1947, so this is 100 oddyears after Ada Lovelace wrote
the first algorithm engineersfound an actual moth stuck
inside.
It says it was the Harvard MarkII computer.
(24:33):
I don't know what that means,maybe you will but this actual
moth was causing a malfunctionand that's where we got the
concept of bugs and debugging,like actually taking the moth
out of I don't know what itwould 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 Idid not know it was a moth.
And I've got a question is amoth actually a bug?
I'm not really sure, Maybe itis a bug.
But what I do know is that theperson who discovered the bug
was supposedly Grace Hopper, andGrace Hopper became Rear
(25:10):
Admiral Grace Hopper and she'sprobably the most famous female
computer scientist that there'sever been.
And in fact there's an annualconference called the Grace
Hopper Conference.
That's a women's conferencethat brings together all the
women, amazing women who work incomputer science together to
network.
And unfortunately, of course,women are the minority in
(25:30):
computer science today.
But the Grace Hopper Conferenceis a great way for those folks
to get together and celebratethe contributions of Grace
Hopper.
Speaker 1 (25:38):
I love that.
Big up the female computerscientists.
That's the second one of theday.
Okay, so I think I got half apoint.
The next one is that there is atradition that all programmers
the first code string that theywrite is and I'm going to read
the string now so it's printbrackets quotation mark hello,
(25:59):
capital H comma.
World.
Exclamation point.
Quotation mark, close bracket.
So I think it's just helloworld, and astute listeners will
realize that we introduced thepodcast up front with that.
But this tradition started in1978 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 myhouse, 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 inthe middle, exactly one space
between the comma and the W andthe exclamation mark at the end.
You will get criticized if youdo 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 usingcode that's 40 or 50 years old.
So there's spacecrafts stillrunning 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 bothstill 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 earthbefore they shut down the the
(27:18):
camera to conserve energy, andthe 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 ortwitter.
Um, you can see theinstructions that that are being
sent to them.
But they they wake them up,they get them to do various
routines and things, but theyhaven't got many apparatus still
running because they're almostout of energy.
But they're still out there andstill functioning.
They're still running code fromthe 1970s.
Speaker 1 (27:47):
And okay, who can actually write this code?
Are there people learning itstill, or are there a few sort
of more mature engineers, let'ssay towards the end of their
career, that can still writethis code?
Speaker 2 (27:58):
I don't know the answer, but certainly it's very
valuable to be really good atcoding languages that are
historic.
So, for example, there's acoding language called COBOL.
It was very popular in the1970s.
It's one of the most verbosecoding languages, so it takes
lots and lots of lines of codeto get anything done.
It's one of the most verbosecoding languages, so it takes
lots and lots of lines of codeto get anything done and you can
(28:19):
get paid an enormous amount ifyou are a COBOL programmer today
, because lots of big banks,insurance companies, these kinds
of folks, telecommunicationscompanies are still running
COBOL systems.
I said I was in Thailand lastweek.
I was talking to a bankexecutive and most of their
systems are still COBOL systemsrunning on giant mainframe
computers that they maintainthemselves, and so if you're
capable of writing code in COBOLyou can get paid very, very
(28:41):
well.
That's probably not true forVoyager 1 and Voyager 2, because
they're probably reallyexciting jobs to have.
They probably don't have tooverpay for those, but knowing
historic programming languagesturns 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 OverflowPodcast.
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 onboth Instagram and X, and we'll
pop some interesting links andresources for you in the show
notes as well, if you'reinterested in learning more.
Speaker 2 (29:21):
Next time, if you join us again for our second
episode, we're going to betalking about product management
.
So today we talked a lot abouthow software gets built.
Next time we'll come back andtalk about what software to
build.
Speaker 1 (29:28):
And I'm Hugh, I'm Hannah.
We'll see you next time.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
New Heights with Jason & Travis Kelce
Football’s funniest family duo — Jason Kelce of the Philadelphia Eagles and Travis Kelce of the Kansas City Chiefs — team up to provide next-level access to life in the league as it unfolds. The two brothers and Super Bowl champions drop weekly insights about the weekly slate of games and share their INSIDE perspectives on trending NFL news and sports headlines. They also endlessly rag on each other as brothers do, chat the latest in pop culture and welcome some very popular and well-known friends to chat with them. Check out new episodes every Wednesday. Follow New Heights on the Wondery App, YouTube or wherever you get your podcasts. You can listen to new episodes early and ad-free, and get exclusive content on Wondery+. Join Wondery+ in the Wondery App, Apple Podcasts or Spotify. And join our new membership for a unique fan experience by going to the New Heights YouTube channel now!
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com