Speaker 1: How'd you like to listen to dot NetRocks with no ads? Easy?
Speaker 1: Become a patron for just five dollars a month. You
Speaker 1: get access to a private RSS feed where all the
Speaker 1: shows have no ads. Twenty dollars a month, we'll get
Speaker 1: you that and a special dot NetRocks patron mug. Sign
Speaker 1: up now at Patreon dot dot NetRocks dot com. Hi,
Speaker 1: this is Carl Franklin.
Speaker 2: And this is Richard Campbell.
Speaker 1: We've got two special shows coming up soon, episode nineteen
Speaker 1: ninety nine and two thousand.
Speaker 2: For episode nineteen ninety nine, we're collecting people's y two
Speaker 2: k stories what did you do to help the Y
Speaker 2: two k event not actually happen?
Speaker 1: And for episode two thousand, we're going to be sharing
Speaker 1: stories about how dot net shaped your career.
Speaker 2: We have a special page at dot netroocks dot com
Speaker 2: slash voxpop where you can record messages for us that
Speaker 2: we can play on these special episodes.
Speaker 1: So tell us what you did for Y two k
Speaker 1: and what dot net means to you, and of course
Speaker 1: how long you've been listening to dot net rocks.
Speaker 2: So go to dot netroocks dot com slash vox pop
Speaker 2: now and leave us a message before the thought of
Speaker 2: operates like whiskey left in a glass overnight.
Speaker 3: Do it?
Speaker 1: Hey, and welcome back to dot net Rocks. I'm Carl
Speaker 1: Franklin and I'm Richard Campbell. Damian Brady is here with us.
Speaker 1: You'll probably hear him before I introduce him formally. But
Speaker 1: this being show nineteen ninety, we need to talk about
Speaker 1: what happened that year.
Speaker 4: Don't wait, you're big years, aren't they?
Speaker 3: They know? Oh yeah, big years.
Speaker 1: Yeah. So I remember nineteen ninety because that's the year
Speaker 1: I got married the first time, and my wife and
Speaker 1: I were watching television and you know, we heard about
Speaker 1: the Berlin Wall coming down and the reunification of Germany
Speaker 1: and that was just like it was a crazy, crazy cool.
Speaker 4: You think about how many pieces were involved in doing that, because,
Speaker 4: sure me it being broken up after World War Two,
Speaker 4: so you had to have the agreement of all of
Speaker 4: the states that were involved in that, which includes Russia,
Speaker 4: right or the Soviet Union at that time, and then
Speaker 4: unification of the currency, the complete dismantling of the eastern
Speaker 4: the Eastern Germany political system essentially to go over to
Speaker 4: the western one. I'm like it was huge, huge task.
Speaker 1: I went back to college that year, and so I
Speaker 1: remember my history teacher was a Cthiopian guy, and he
Speaker 1: was just like, just can you believe this is the garbageoff,
Speaker 1: just like you know, who saw that coming?
Speaker 3: And my.
Speaker 1: Economics teacher, a macroeconomics class that I had, she was
Speaker 1: like a protest hippie from the sixties, you know, and
Speaker 1: she said, we used to go around saying free Nelson Mandela,
Speaker 1: and now he's free. So that was yeah, February eleventh.
Speaker 4: That happened in nineteen ninety as well.
Speaker 1: Yeah, February eleventh.
Speaker 4: So and then she also saw what started in eighty
Speaker 4: nine with the dissolution of the Eastern Bloc. Now you
Speaker 4: start having elections in Poland and in Czechoslovakia and the
Speaker 4: former Yugoslavia.
Speaker 1: But it wasn't so good for Yugoslavia though, that was
Speaker 1: collapsing there, the communist regime.
Speaker 4: Yeah, and they separates nations that form from that and
Speaker 4: they are quite hostile to each other. So things are
Speaker 4: going to get ugly in that part of the world.
Speaker 1: And they would go to war in the next few years. Yeah.
Speaker 1: The beginning of the human genome projects. Not to steal
Speaker 1: your science, but it's good that's a good one.
Speaker 4: Yeah, and it take years and years, but look where
Speaker 4: we are today. I forgot. They spent what two and
Speaker 4: a half billion dollars to do that over a decade,
Speaker 4: and today you can get it for three hundred bucks. Yeah,
Speaker 4: so pretty amazing, you know, talk about transformation. Hey, before
Speaker 4: we go off of the whole Eastern Bloc thing. Most importantly,
Speaker 4: in nineteen ninety, Moscow gets its first McDonald's wow, and
Speaker 4: its first pizza Hut.
Speaker 1: That was the real reason they wanted to of the
Speaker 1: Soviet Union, right, so he could bring McDonald's and pizza
Speaker 1: Hut in there.
Speaker 4: I don't know the answer to that. By the way,
Speaker 4: they're also opening in China at the same time, so
Speaker 4: that was going on as well.
Speaker 3: Yeah, any others.
Speaker 1: Go ahead, No, that's enough. I mean I would go
Speaker 1: over the movies, but the best movies are in the eighties.
Speaker 4: We know that.
Speaker 3: So yeah, yeah, I think we've already had that wave.
Speaker 4: I will go one more geopolitical mention, which is the
Speaker 4: Iraqi invision of could wait that's right? Yeah, yeah, obviously
Speaker 4: we'll have more dire consequences, although it takes time for
Speaker 4: folks to really have that sink in.
Speaker 1: Yeah, absolutely. I know you're going to do science and tech,
Speaker 1: but I just want to apologize because last week I
Speaker 1: said nineteen eighty nine was the beginning of the world
Speaker 1: Wide Web. Tim berners lead didn't actually invent that until
Speaker 1: nineteen ninety. So he developed the first web server, laying
Speaker 1: the foundation.
Speaker 4: Yeah, he put the proposal in in nineteen eighty nine
Speaker 4: to Thurn in December. Yes, yeah, you know, and this
Speaker 4: is in March of eighty nine. He put the proposal
Speaker 4: in Oh okay, March and turned him down.
Speaker 3: We don't need that. That's not a good idea time on.
Speaker 1: What do you think the people that turned him down
Speaker 1: to sleep at night? Do you think they're just like, ah,
Speaker 1: that was done.
Speaker 4: Fortunately, he kind of just kept working on it, and
Speaker 4: his direct report, his boss was fine with him still
Speaker 4: working on it. And yeah, by nineteen ninety on his
Speaker 4: next computer. And you can go see this machine. It's
Speaker 4: at certain I've seen. It's got a big label on it. Yeah,
Speaker 4: it says server do not turn off. And that's really cool.
Speaker 4: First web server, the first browser, all of it.
Speaker 1: I gotta go see it.
Speaker 4: It's really a thing.
Speaker 1: So what else happened in science and tech and space?
Speaker 4: Let's do Internet first. I'll do space last. Although I
Speaker 4: think the computing stuff is huge, because the Internet obviously
Speaker 4: has a very big year. Was not only just tim
Speaker 4: getting the WWW working, but this is when the first
Speaker 4: search engine comes out. It's called Archie, written by team
Speaker 4: of three Allen Mtaje, Bill heal And and Mike Parker out
Speaker 4: of McGill, University of Montreal.
Speaker 1: There's a whole bunch of named things that were about
Speaker 1: Archie and Veronica and all that, that whole comic strip.
Speaker 4: Yeah, and it all happened now right like this expansion,
Speaker 4: Like really, what's happened is that we don't have the
Speaker 4: Internet yet. It's arpendet, but this is the year that
Speaker 4: arpaet goes away and it becomes nsf net or National
Speaker 4: Science Foundation Network. So they're understanding it isn't the Cold
Speaker 4: War tool anymore. It's not that that. It's it's something else.
Speaker 4: So besides Archie, you also get in Gopher this year
Speaker 4: out of Minnesota University of Minnesota, which was a search
Speaker 4: and retrieval tool.
Speaker 3: Yeah.
Speaker 4: Remember we're only at one hundred thousand or so machine,
Speaker 4: so it's still reasonable for your computer to search everything.
Speaker 1: Gopher was like file folders on the Internet. It was
Speaker 1: like a hierarchical file folders system and you can.
Speaker 4: Go fetch the files as you want, all right, so beyond.
Speaker 4: This is also the year that the Electronic Frontier.
Speaker 3: Foundation is formed.
Speaker 4: Ah, Mitch kpar Yeah, don't forget that.
Speaker 1: And John Perry Barlow who went to write songs with
Speaker 1: Bob We're for the Grateful Dead, Cassidy being one of
Speaker 1: my favorites.
Speaker 3: Nice. Yeah.
Speaker 4: This is the year that the first company in history
Speaker 4: ever makes more than a billion dollars in sales. And
Speaker 4: that company is Microsoft. And what are they selling in
Speaker 4: nineteen ninety Windows three, MS DOS and Windows Yeah. So
Speaker 4: this is when version three comes out. It's the first
Speaker 4: multitasking version of Windows, so if you have a three
Speaker 4: D six or better, you can have multiple apps running simultaneously.
Speaker 4: It's also the first version to include Solitaire, which is
Speaker 4: clearly worth a billion dollars. It's also the first edition
Speaker 4: of Microsoft Office. It was called the Microsoft Office for Windows,
Speaker 4: included Word one point one, Excel two point one D,
Speaker 4: and PowerPoint two point zero.
Speaker 1: Wow.
Speaker 4: It's also the year that Microsoft and IBM and their
Speaker 4: relationship on operating systems. That's the MMOs two And this
Speaker 4: is the beginning of NT and all those sorts of things.
Speaker 4: You have two other important pieces of software. This is
Speaker 4: the first version of Photoshop is in nineteen ninety only
Speaker 4: for the mac's the beginning of it. And one you
Speaker 4: know and love snagg It is in nineteen ninety.
Speaker 3: Yeah. All right.
Speaker 4: On the space side, I'll go down two stacks. There
Speaker 4: are six Shuttle flights this year. A lot of them
Speaker 4: are just satellite missions, but there are three I will
Speaker 4: talk about specifically.
Speaker 3: In April.
Speaker 4: Spatial Discovery deploys the Hubble space telescope.
Speaker 1: That's right.
Speaker 4: Originally supposed to launch in nineteen eighty three, delayed by
Speaker 4: the Challenger disaster and also budget. There's some evidence that
Speaker 4: it was actually based on the KH eleven spy satellite,
Speaker 4: which is still classified, so we don't really know for sure,
Speaker 4: but every image of it looks an awful lot like novel.
Speaker 4: Probably was a prototype that wasn't quite right for their application,
Speaker 4: so they gave it to NASA and they built the
Speaker 4: saddle the Hubble around it two point four meter mirror
Speaker 4: that was, of course, in ninety ninety discovered to a
Speaker 4: big ground incorrectly, and it'll be a few years before
Speaker 4: they figure out how to fix that. So it didn't
Speaker 4: work all like it.
Speaker 1: So I just got to say this, this is my
Speaker 1: favorite David Letterman top ten top ten Hubble space tell
Speaker 1: Us scope excuses, and the number one was bum with squeegee,
Speaker 1: smeared lens at stopped light.
Speaker 3: All right.
Speaker 4: Two more Shuttle missions. One is Discovery in October launching
Speaker 4: the Ulysses Solar probe. This there's been solar pros for this,
Speaker 4: but what Elysses did it was with the ESA that
Speaker 4: they did. This one is they actually did a slingshot
Speaker 4: maneuver off of Jupiter so that they could get imaging
Speaker 4: of the poles of the Moon that had never been
Speaker 4: done before. It meant that its orbit ran several years long.
Speaker 4: It was a very large elliptical orbit, but it means
Speaker 4: they've got the first images of the North and South
Speaker 4: poles of the Sun. And finally Colombia and December with
Speaker 4: the Space Labs with Astro one. So space Lab was
Speaker 4: this laboratory before the space station came along.
Speaker 3: It was in the.
Speaker 4: Cargo compartment of the space station, gave more pressurized space
Speaker 4: to work in, and in behind that was this non
Speaker 4: pressurized palate. There were a few different options for spacelab
Speaker 4: doping what're doing. This is the first time they flew
Speaker 4: with Astro one, which was four telescopes mounted on a
Speaker 4: pointing rig built by Darnier out the back of the
Speaker 4: shuttle and the four satellite. The four telescopes were the
Speaker 4: Hopkins ultra violet telescope, the Wisconsin Ultraviolet Photo Parimeter, the
Speaker 4: experiment the Ultravallet Imaging telescope, and the Broadband X ray telescope. Wow,
Speaker 4: so lots of science. And I promised that I'd be
Speaker 4: talking about Mirror going forward, And in nineteen ninety the
Speaker 4: Crystal Module is lifted for mir This was a experimental
Speaker 4: module that had materials processing furnaces on it, so they
Speaker 4: were attempting to make ultra puer versions silicon and a
Speaker 4: bunch of other experiments. They also had one of the
Speaker 4: very first androgynist docking ports, initially for the Brand Shuttle,
Speaker 4: which of course would only have flown once a few
Speaker 4: years ago, will never fly again, but that port would
Speaker 4: be used by Spatial Atlantis at nineteen ninety five at
Speaker 4: the first dockings of space to the Shuttle to Mirror.
Speaker 1: Okay, and that's what I got, all right, that's very
Speaker 1: good stuff. Yeah, and I think Damien's just kind of
Speaker 1: quiet because it's like seven o'clock in the morning where
Speaker 1: you are, right.
Speaker 3: It's it's not too bad. It's I but I mean
Speaker 3: I was listening to all this. It's fascinating. I was ten,
Speaker 3: so yeah. Yeah, although that's the first computer I ever
Speaker 3: got was that year nineteen ninety. Yeah, and I say
Speaker 3: I got dad hadn't have had some stay over it. Yeah. Yeah,
Speaker 3: he slowly lost control over it over the next few years.
Speaker 4: I suspect ten years old is one I got grabbed
Speaker 4: by computing too, dude, just a few years earlier than years.
Speaker 1: Well yeah, yeah, well let's keep going with better no
Speaker 1: framework roll the music got so I thought when I
Speaker 1: found you know, I look for trending GitHub repos right
Speaker 1: and I found this one. And when I saw it,
Speaker 1: I thought, I swore that we had done this before,
Speaker 1: but apparently not. Maybe it was I just don't know. Anyway.
Speaker 1: This is hardened Windows Security from hot Cake X. And
Speaker 1: it's not code really, it's documentation. It's hardened Window security,
Speaker 1: a new threat to malware, hardened Windows safely securely with
Speaker 1: only official Microsoft methods. So it's basically you know, documentation
Speaker 1: and all the things that you need to know to
Speaker 1: shore up your Windows security, which is really becoming more
Speaker 1: and more and more important for everyday people to do,
Speaker 1: especially you know, those who don't understand what the difference
Speaker 1: is between just plugging into your cable modem and using
Speaker 1: a router and using net addresses and private networks and
Speaker 1: allowing your friends to come over and access your Wi Fi.
Speaker 1: Can they access your machine? It's like, there's so many
Speaker 1: things people need to know about Windows security. And you
Speaker 1: may not think that, oh, well, I trust my friends,
Speaker 1: but you know what, somebody could be sitting outside your
Speaker 1: driveway and hacking your stuff. So all sorts of things
Speaker 1: to know here.
Speaker 4: I think it's important to remember that Windows is configured
Speaker 4: for maximum compatibility, not maximum security, right, and so often
Speaker 4: there's a whole lot of features that turned on that
Speaker 4: are very much edge cases. But you know, normal people
Speaker 4: that those things weren't turned on would return the machines
Speaker 4: that didn't work for them, and that's more expensive to
Speaker 4: Microsoft than leaving it somewhat unsecure. So it's well worth
Speaker 4: running on so many tools.
Speaker 1: As our friend Patrick Hines likes to say, convenience is
Speaker 1: the enemy of security and vice versa totally. So that's
Speaker 1: what I got. Richard, who's talking to us today?
Speaker 4: We grab a Colmin Hot Show fourteen twenty five.
Speaker 3: That's right, baby, going back to the way.
Speaker 4: Back we should good nine years ago. Wow, the show
Speaker 4: is called brown Field DevOps with one Damien Brady. Maybe
Speaker 4: you've heard of them. So it's just we actually shot
Speaker 4: this at NDC Lendon. You and I in a booth
Speaker 4: with Damien. Back in the day we were talking. You know,
Speaker 4: the demops movement was more mature than it is twenty seventeen.
Speaker 4: Asould I say, how do we take these practices and
Speaker 4: put them on to existing applications, sort of get them
Speaker 4: geared up to the way they ought to be and
Speaker 4: at least comments a few years old. Robert Mattingley says,
Speaker 4: thanks for the great show, guys. Legacy shows are always
Speaker 4: stock provoking. But the common trend seems to be defining
Speaker 4: the term quote legacy code. It's kind of subject discussed.
Speaker 4: It needs to be redefined for our current conversation. I
Speaker 4: think the big hairy problem is that we use the
Speaker 4: term legacy to define three separate categories of code. The
Speaker 4: first and best category code, which is battle tested, reliable
Speaker 4: makes the best use of the language features at the time,
Speaker 4: may be hard to improve with modern features. A lot
Speaker 4: of Cobol could fall into this category. It may see
Speaker 4: our cane, but it's reliable and it uses the platform well.
Speaker 4: The second category, code is functional and reliable uses conventions
Speaker 4: which are now considered outdated or harmful. I'm looking at
Speaker 4: you go to command. The code doesn't need a change,
Speaker 4: but could be improved by taking advantage of new features
Speaker 4: or conventions. And the final category is code the just
Speaker 4: plane sucks. It was bad when it was written, and
Speaker 4: it's bad now. We've all written it, so there's no
Speaker 4: use of pointing fingers. But it is an ugly baby.
Speaker 4: Ugly things like using a cascade of seventeen try catch
Speaker 4: blocks to handle a value assignment, or these SQL injectable
Speaker 4: storage procedures because hey, we need dynamic behavior, or checking
Speaker 4: if your user is authenticated or not checking if your
Speaker 4: user is authenticated anywhere but the log in page letting
Speaker 4: anyone who could play yes the URL to have full
Speaker 4: of mint access to your web app. If we call
Speaker 4: all these things legacy code, as if they all had
Speaker 4: the same value, it needed to be treated.
Speaker 3: The same way.
Speaker 4: They really don't, and it's important to recognize they need
Speaker 4: to be treated differently. Be nice to have a term
Speaker 4: for each of these categories so that we could differentiate them.
Speaker 4: They really don't, and it's important to recognize that they
Speaker 4: need to be treated differently.
Speaker 3: It would be.
Speaker 4: Nice to have a term for each of these categories
Speaker 4: so we could differentiate what should be preserved and what
Speaker 4: genuinely needs a rewrite.
Speaker 1: I consider legacy code any code that nobody on staff
Speaker 1: can read and understand. That's fair.
Speaker 4: We're no longer compilable. That's a good one.
Speaker 1: That's a good one. Yeah, that's pretty good.
Speaker 4: I don't know that I have much to add to
Speaker 4: Roberts's points here, because I think he's completely correct. That's
Speaker 4: one of the reasons I read it. There really is
Speaker 4: these different kinds of software, and yeah, it would be
Speaker 4: nice if we treated them with especially that old good code,
Speaker 4: with more respect. Right, And certainly, you know, we tend
Speaker 4: to package up those old reliable apps, like those Cobald
Speaker 4: apps in wrappers so that we can call to them
Speaker 4: with more modern things. But often that coach does not
Speaker 4: need to be replaced.
Speaker 3: It works.
Speaker 4: But we've all made some ugly Yeah, we'd all love
Speaker 4: to go back and clean up the ugly. It's usually,
Speaker 4: you know, no applications finished, it's just taken away from
Speaker 4: you and deployed. M HM, which you could do about that, Robert,
Speaker 4: thank you so much for your comment. And a copy
Speaker 4: of music co Buy is on its way to you.
Speaker 4: And if you'd like a copy of music go buy,
Speaker 4: write a comment on the website at dot net rocks
Speaker 4: dot com or on the Facebook and a couple whichever
Speaker 4: show there and you comment there and I reading the show,
Speaker 4: we'll send you copy bees to go buy.
Speaker 1: Yeah, music to code by dot net where you can
Speaker 1: get that if you don't win it yourself and you
Speaker 1: just want to buy it. We have the entire twenty
Speaker 1: two track collection in MP, three wave and FLACK versions.
Speaker 1: All right, So I guess it's time to introduce Damien.
Speaker 1: His bio has changed a little bit since the last
Speaker 1: time he's been on the show. Damian Brady is a developer,
Speaker 1: speaker and author specializing in DevOps, mL OPS, developer process
Speaker 1: and software architecture. He's a senior manager and the Developer
Speaker 1: advocac team at GitHub based in Brisbane, Australia. Formerly a
Speaker 1: cloud advocate, at Microsoft for four years and prior to
Speaker 1: that a dev at Octopus Deploy and a Microsoft MVP.
Speaker 1: Damien has over twenty years in software development and consulting
Speaker 1: in a broad range of industries. In Australia. He co
Speaker 1: organized the Brisbane dot Net User Group and launched the
Speaker 1: annual DDD Brisbane Conference. Welcome back, Damien.
Speaker 3: Thanks really good to be back.
Speaker 4: I think we've interviewed you in every one of your jobs.
Speaker 4: I'm sure we did a show when you were with
Speaker 4: Octavis Deploy.
Speaker 1: Definitely, yeah, yeah.
Speaker 4: And definitely when at Microsoft and our GitHub, although as
Speaker 4: I understand it now, the line between Microsoft and GitHub
Speaker 4: is very almost not existent these days, isn't it.
Speaker 3: Look it depends which part of GitHub and Microsoft you're in.
Speaker 3: But yes, yeah, exactly right. Yeah, there's some very interesting
Speaker 3: reporting chains going on at Microsoft and get ub at
Speaker 3: the moment. But the short version is that we're much
Speaker 3: closer than we used to be. So there's people on
Speaker 3: my team, like right next to me on my team
Speaker 3: who work for Microsoft and have the same manager as me,
Speaker 3: even though I'm employed by GitHub. So there's a lot
Speaker 3: of that kind of thing happening. Means that you know
Speaker 3: the stuff we're developing, particularly you know, co Pilot and
Speaker 3: all the dev tools. You know, we're working on them together.
Speaker 4: I guess sounds like our friend Martin Woodward has got
Speaker 4: a big, fat promotion.
Speaker 3: He is a VP of Devrell and very recently that
Speaker 3: includes a huge number of developer advocates or like your
Speaker 3: old job. Yeah, yeah, exactly, so half of the Microsoft
Speaker 3: Deverell team kind of reports up through him.
Speaker 4: Now, I've always been a big fan of Martin wood
Speaker 4: where I'm glad he's doing well.
Speaker 1: Me too, he is.
Speaker 3: I saw him just before NDC London that were we
Speaker 3: were both at Richard the other day.
Speaker 4: Yeah, you were really keyn order for that show.
Speaker 3: As I recall, I was, yeah, that was fun.
Speaker 1: I like the way Martin says bogs and to fix
Speaker 1: the bugs.
Speaker 3: I think I think the faith is naughty. I think
Speaker 3: we get to say naughty a lot, those naughty bogs right, love.
Speaker 4: Me and Irish Ac.
Speaker 1: So what are you thinking about these days in terms
Speaker 1: of software and the big picture? It seems to have
Speaker 1: changed a bit since you were last with us.
Speaker 3: Yeah, yes, well, yes, definitely, but in some respects No,
Speaker 3: it was interesting listening to that. You know the title
Speaker 3: of that that last last podcast I recorded with you guys,
Speaker 3: the you know, the brown Fields DevOps of stuff, and
Speaker 3: I remember that, remember that distinctly, and that was really
Speaker 3: all about taking code that did not have, you know, that,
Speaker 3: the safety nets around it and adding those safety nets in.
Speaker 3: And in that respect, I'm kind of talking about the
Speaker 3: same stuff these days. Sure, it's just instead of you know,
Speaker 3: legacy code that nobody understands, it has no tests around.
Speaker 4: It, written by a person that no longer at the company.
Speaker 4: Now it's just not written by a person at all.
Speaker 3: That's right. Yeah, We've we've evolved. We're not we're not
Speaker 3: using the people anymore. Yeah, So it's a similar kind
Speaker 3: of thing like where I mean that the way we
Speaker 3: write code largely has changed, where Like depending on how
Speaker 3: much of the code you're you're physically typing out yourself.
Speaker 3: And there's a huge area everything from you know, just
Speaker 3: using copilot or clawed or cursor or any of those things,
Speaker 3: to you know, to just auto complete the line you're
Speaker 3: on all the way through to hey, you give me
Speaker 3: an app that does this and then ship it to PROD.
Speaker 3: But either way, you know that code is not coming
Speaker 3: out of your fingers directly one could argue the things
Speaker 3: that run on the machine have not come out of
Speaker 3: your fingers directly for quite some time. But it's a
Speaker 3: little bit less deterministic now, you know.
Speaker 4: Yeah, so you said none of us has written a
Speaker 4: garbage collect or any time recently, or any cryptographic library.
Speaker 4: You know, we depend on code all the time.
Speaker 1: Yeah, exactly, And that's really it and software development encoding
Speaker 1: is really about expression. You want to express your intent
Speaker 1: to the computer to do something and have it do it,
Speaker 1: and you know, you express through code the instructions. But
Speaker 1: now we're at such a high level with you know,
Speaker 1: the agents and all of that that we're expressing to
Speaker 1: an agent in the English what to do, and it's
Speaker 1: just another higher level of programming if you think about it.
Speaker 3: There is I think there was, there's always been this
Speaker 3: level at which you don't quite understand what's happeningneth. I mean,
Speaker 3: you write your code, and if you understand what that
Speaker 3: code is supposed to do, then you can largely trust
Speaker 3: that the OS and the hardware and the platform and
Speaker 3: the framework and all the things you're using are going
Speaker 3: to do what you expect them to do. There was
Speaker 3: an interesting story told in this ynote as well. Actually
Speaker 3: about basically showed people some code and it was a
Speaker 3: you know, setting some variables and then a trycatch statement
Speaker 3: and then they catch you you know, would write some
Speaker 3: stuff out to the console, and you know, this is
Speaker 3: a dot Net you know, some c sharp. It took people,
Speaker 3: you know a few seconds, but everybody kind of said, okay, well, great,
Speaker 3: it writes this value out. And that's true. It absolutely does,
Speaker 3: unless you compiled it in September of nineteen ninety five
Speaker 3: or something like that, because there was a version of
Speaker 3: the dot net framework, not ninety ninety five, twenty fifteen,
Speaker 3: I think there was a version of the dot net
Speaker 3: four point six framework where they changed the just in
Speaker 3: time compiler. So if you compiled that in release mode
Speaker 3: with compiler optimizations on, sometimes it wiped out. It optimized
Speaker 3: out that catch statement.
Speaker 4: When that thing's more optimal than not running code. That's
Speaker 4: very optimal.
Speaker 3: That's true.
Speaker 1: Well, you know it's still deterministic though you just didn't
Speaker 1: know the rule.
Speaker 3: Yeah, right, right, And it's very very difficult to debug
Speaker 3: that if it only runs in an optimized release mode.
Speaker 3: But like to credit, they fixed it very quickly. However,
Speaker 3: you know, it did highlight that at some point you
Speaker 3: don't really know what's going to happen. I think the
Speaker 3: huge difference that we've got now is that all of
Speaker 3: that stuff is largely trustworthy. You know, if if that
Speaker 3: doesn't work for you, it's also not working for the
Speaker 3: banker around the corner that has all your money. You know,
Speaker 3: your inventory system is probably the least of your worries
Speaker 3: right now. But with AI driven stuff, where you are
Speaker 3: giving it the intent, you actually don't know what code
Speaker 3: is running underneath, and so there's a huge gap, much more,
Speaker 3: much more of a significant gap between your intent and
Speaker 3: what actually comes out of the other side. And that's
Speaker 3: that's something that we probably and then need to think.
Speaker 1: And the nondeterministic nature of these agents means that you know,
Speaker 1: you could express your intent once on a Monday and
Speaker 1: express that same intent on Tuesday, and you're two completely
Speaker 1: different results and one of them could be absolutely wrong.
Speaker 3: That's yeah, that's exactly right, all right.
Speaker 4: I've run two prompts simultaneously and gotten two different results
Speaker 4: back from the same prom Like, you don't have to
Speaker 4: wait milk, It'll give you something ever time.
Speaker 3: So if you show somebody a programmer a line of
Speaker 3: code and say what does this do? They will be
Speaker 3: able to tell you if you show them a prompt,
Speaker 3: a single line prompt and say what does this do?
Speaker 3: There's no to know. You can guess. You know, the
Speaker 3: tools are getting better and a little bit more deterministic,
Speaker 3: but at some point, you know, especially when you're asking
Speaker 3: for large pieces of work, at some point you really
Speaker 3: just don't know what's going to come out.
Speaker 4: Right, So is this all about testing?
Speaker 3: Then?
Speaker 4: Like, is that really the thing we've got to get
Speaker 4: better at.
Speaker 3: I mean, that's that's definitely a large part of it.
Speaker 3: But there's only so much you can really do with
Speaker 3: with tests, I mean, especially especially asking for large pieces
Speaker 3: of code, so that there's kind of a sliding scale
Speaker 3: of you know how much you're asking for, asking an
Speaker 3: LLM for, or asking a tool for, and the know
Speaker 3: how close to your desired outcome it's going to get.
Speaker 3: If you ask for a single line of code that
Speaker 3: does this, it's very very likely that that's going to
Speaker 3: be correct. If you ask for a function, depends on
Speaker 3: the function, but pretty likely that you're going to get
Speaker 3: a good result as long as you've defined it correctly
Speaker 3: and you've given it a good prompt and it's got
Speaker 3: some good context. But if you ask for an entire application,
Speaker 3: you know, even if it's a relatively small one, you're
Speaker 3: probably going to have to iterate on that a handful
Speaker 3: of time.
Speaker 1: So I'm much more comfortable iterating than I am just
Speaker 1: you know, giving. And I didn't used to think that,
Speaker 1: especially before I even started with this stuff, sitting down
Speaker 1: with Scott got three at a conference somewhere and we
Speaker 1: were both in agreement that just you know, use your imagination.
Speaker 1: It's so big, just think big and give it this great,
Speaker 1: big prompt, and you know, if it doesn't work, it
Speaker 1: doesn't work, you just try again. And I don't think
Speaker 1: that anymore. I think small iterations is much better, especially
Speaker 1: because you can kind of track the progress and test things,
Speaker 1: you know, and if something doesn't work, you can say no, no, no, no,
Speaker 1: that was wrong. Yeah that's not what I meant. Erase
Speaker 1: that and try again.
Speaker 3: Yeah. That's how I'm comfortable doing it. And that means
Speaker 3: that all of your existing testing strategies, you know, TDD
Speaker 3: and stuff like that, you can still kind of do
Speaker 3: that if you if you can give at an entry
Speaker 3: point and an expected result. So here is a function header,
Speaker 3: Go implement that function for me, and I can write
Speaker 3: some tests around that to proof that that works. I
Speaker 3: can even get, you know, get the tools to help
Speaker 3: me write those tests. I can get the tools to
Speaker 3: help you look for edge cases I hadn't thought of.
Speaker 3: But yeah, if you're asking for a web app to
Speaker 3: do it to do X thing, then you don't know
Speaker 3: what shape that code is going to take, and so
Speaker 3: it's a little hard to write tests around that. At least,
Speaker 3: you know, very specific tests. You could probably write some
Speaker 3: broad functional tests, I guess, but even then they've got
Speaker 3: to match the shape of the code that comes out.
Speaker 4: The token economy actually encourages practice. I mean the problem
Speaker 4: with ready the mother of all prompts. It thinks the
Speaker 4: mother of all tokens, and then it's wrong and you've
Speaker 4: got to do it again.
Speaker 3: Yeah a little bit. Yeah, I mean behind the scenes,
Speaker 3: and this is not how you're charged necessarily, but behind
Speaker 3: the scenes there's usually a lot of iteration going on anyway,
Speaker 3: because it's very difficult to give it the mother of
Speaker 3: all prompts and then say, okay, go implement those thirty
Speaker 3: five files in one in one cycle. I mean, the
Speaker 3: context window even if it's luge enough, it's you know,
Speaker 3: you lose fidelity. I guess once it.
Speaker 4: Gets reminds me of the guy who writes a giant
Speaker 4: stored procedure that I had to swat with a newspaper. Bad,
Speaker 4: don't it's not good? Like I feel like you're taking
Speaker 4: the architect's responsibility here to do a decomposition of the
Speaker 4: problem spaced, break it down a series of steps, and
Speaker 4: then feed it to the machine to execute each piece
Speaker 4: in turn.
Speaker 1: And there's there's a there's a danger here that you
Speaker 1: don't pay. You know, you're so eager to finish the
Speaker 1: feature and get it working and check it in that
Speaker 1: you don't check it out. You don't understand what it did.
Speaker 1: You didn't read the three through the code, and then
Speaker 1: so you're you're trying to figure it out because there's
Speaker 1: a bug or something like that that you have to fix,
Speaker 1: and you think, oh, I'll just look through the code
Speaker 1: and see what it is. What's that. Oh I didn't
Speaker 1: write that, Well, no, you didn't. Your agent wrote that. Oh,
Speaker 1: now I got to figure that out at the wrong time.
Speaker 1: You should. You should know what it does when it's.
Speaker 3: Written and if it if it appears correct, like it
Speaker 3: seems to be doing the right thing, then that's great,
Speaker 3: but how how correct is the code underneath? Anyway, you
Speaker 3: are probably not looking at all the educases when you're
Speaker 3: just clicking through. It's kind of the old school QA
Speaker 3: where somebody had a spreadsheet of you know, here are
Speaker 3: the things that it should do, and they just click
Speaker 3: on the buttons and say, yep, that's great, and then yeah.
Speaker 1: And I like to be engaged in the process, Like
Speaker 1: I like thinking about the architecture and what I need
Speaker 1: to do to implement a feature. Oh, this is going
Speaker 1: to have to go there, and then this guy's got
Speaker 1: to reference that, and then you're going to throw it
Speaker 1: over the wall to that guy and blah blah blah.
Speaker 1: You know, I kind of really like that because it
Speaker 1: keeps me engaged in the in the software itself. It'd
Speaker 1: be boring for me if I just handed all that
Speaker 1: over to an agent. So I like, there's a nice
Speaker 1: balance there that I've gotten myself into the works.
Speaker 3: Well, yeah, I agree. I work very similarly. So I
Speaker 3: have a right in front of me on the screen.
Speaker 3: Actually I have a little time zone help. I think
Speaker 3: I'm in Australia obviously, but a lot of the team,
Speaker 3: especially the team now that it's grown a bit scattered
Speaker 3: kind of close by time zone wise but not exactly right.
Speaker 3: And yes, there are some really good time zone tools
Speaker 3: on the internet, but I just wanted one where I
Speaker 3: could glance at it and say, for these time zones,
Speaker 3: this is what time is right now. That was largely
Speaker 3: a one shot using the Copilot CLI, but I still
Speaker 3: iterated on it four or five times to say, oh,
Speaker 3: this is great, but can you let me color code
Speaker 3: these things? And can you change it so these things
Speaker 3: line up instead? And so that's a relatively large piece
Speaker 3: to start off with. But then once I have that
Speaker 3: in front of me, I'm like, all right, here's the
Speaker 3: here are the new things that I want, And what
Speaker 3: did you actually do to implement that? Yeah, but this
Speaker 3: is also this is like a little toy that I
Speaker 3: have right in front of me. This is not a
Speaker 3: super personal piece of software, is what it is? You
Speaker 3: literally built a thing for you. Yeah.
Speaker 1: I have so many of those little tools that and
Speaker 1: I mentioned them from time to time, and I almost
Speaker 1: don't want to mention them because I don't want people
Speaker 1: to think I just sit around writing dumb tools all
Speaker 1: the time, Like I have a professionalist artware development trives me.
Speaker 3: Yeah, I have a friend who I'm not going to
Speaker 3: name them, but I have a friend who their daughter
Speaker 3: was going to look after their kid for a few days,
Speaker 3: and they rade it. They wrote a daughter as an adult.
Speaker 1: I got it.
Speaker 3: But they wrote a several page document about all the
Speaker 3: stuff in the house and what the kid does, and
Speaker 3: what the kid needs, and all the things that they
Speaker 3: need for school and all that, all that kind of stuff.
Speaker 3: But of course, you know this person is not going
Speaker 3: to read that document. So they vibe coded up a
Speaker 3: little like chat pot, and you can ask anything you
Speaker 3: want and it pulls the information just using a pretty
Speaker 3: basic rag and then we'll answer that questions. And it
Speaker 3: took half an hour. Right. It's a fun, little, very
Speaker 3: specific tool for that person to say, hey, here's here's
Speaker 3: a solution to the problem I'm inevitably going to have.
Speaker 3: That's great. Yeah, those little tools a fantastic to be
Speaker 3: able to do them even if you don't code. I
Speaker 3: mean that's a you know, if you if you can't
Speaker 3: look at that code and see exactly what it's doing.
Speaker 1: You know, we used to talk about expert systems back
Speaker 1: in the eighties, right, that was you know, a more
Speaker 1: linearly coded thing that you could ask questions and it
Speaker 1: had the knowledge of the business or the whatever, and
Speaker 1: you could ask it questions and would tell you. I
Speaker 1: mean that now this has sort of come to reality,
Speaker 1: and I like the fact that you could take all
Speaker 1: the business knowledge that you have. Or let's say let's
Speaker 1: say somebody starts a small business and it grows, right,
Speaker 1: and this person has all the knowledge and everybody's always
Speaker 1: coming to them for the advice, and then how does
Speaker 1: this work? And all that stuff, let's be perfect for
Speaker 1: a little RAG application.
Speaker 3: Yeah.
Speaker 1: Yeah, it's like a brain dump into a chat.
Speaker 3: But so the thing is these these little, you know,
Speaker 3: super personal little tools that you have. They're one thing
Speaker 3: and writing tests and having you know, CI around that
Speaker 3: it's not you know, super important. I mean, this is
Speaker 3: a little tool that you're running. But I've been around
Speaker 3: long enough to know that sometimes those little tools, you know,
Speaker 3: if you do them at work, get seen by a
Speaker 3: manager and then suddenly your machine is getting shipped to problem.
Speaker 3: So then like, if this has been vibe coded, you
Speaker 3: haven't seen any of the code. How do you get
Speaker 3: from that to something that other people can work on
Speaker 3: and that you can trust and that you know, you know,
Speaker 3: you've touched the edge cases. You know that you know
Speaker 3: it's it's secure, it's reliable, and that is It's not
Speaker 3: a new problem, but it is a problem. We can
Speaker 3: get to a lot faster than we used.
Speaker 4: To a much more of it. This used to be
Speaker 4: the access guy who got out of hand, right, and
Speaker 4: suddenly they want to deploy it to one thousand users.
Speaker 3: I mean one of the first jobs I had there
Speaker 3: was a four DL I don't know if you ever
Speaker 3: touched that. It was basically yeah, yeah, so a four
Speaker 3: DL system that was running in production.
Speaker 1: Very high level language.
Speaker 3: Yeah. One person knew how to use it to back
Speaker 3: them back to your on the legacy software. And when
Speaker 3: that person left, it's a black box, like you don't
Speaker 3: you don't know what's in this thing. Yeah. So it's
Speaker 3: not a new problem, but we can do it so
Speaker 3: much faster. Now we can get a running application, you know,
Speaker 3: in a minute or two. Yeah, really we can.
Speaker 4: And Gami and I we did RUP for one moment
Speaker 4: for these very important messages. Eric back, it's done a
Speaker 4: Rocks and Richard Campbell. That's Carl Franklin. Hey, Hey, Hey,
Speaker 4: hanging with our z buddy. Damn me and Brady talking
Speaker 4: a little bit about we'll trying to make good software
Speaker 4: out of all this. Like this sounds like the same
Speaker 4: thing that I did for access for apps dB STAPs
Speaker 4: are four that this sounds like a job for a
Speaker 4: consultant Like this is when you call in an expert
Speaker 4: to go through what you've got here and kind of
Speaker 4: make the assessments around security and reliability, all of those
Speaker 4: sorts of things.
Speaker 3: Yeah, I think so. I don't think there's a need
Speaker 3: to anything necessarily wrong with the code that comes out.
Speaker 3: It's just once it gets to a point where people
Speaker 3: trust it and need to run it in production and
Speaker 3: more people need to add to it, then suddenly you've
Speaker 3: got to start putting some rigor around that code again.
Speaker 3: So having you know, the pipelines that you used to
Speaker 3: have when you hand codeed everything that's super important. And
Speaker 3: then yeah, the testing around it, code coverage, things like that.
Speaker 3: The good news, I guess is that there's all these
Speaker 3: generative AI systems give us opportunities to help with that
Speaker 3: process as well. I was probably for a little while
Speaker 3: one of the few people who actually didn't mind hand
Speaker 3: coding GitHub Actions. You're it. You're the only one. Everybody
Speaker 3: else got a piece of Yeah, but I don't do
Speaker 3: that anymore. Really, I mean it's very very easy to
Speaker 3: ask any of these tools, hey, can you write a
Speaker 3: a action to do this and and check it? And
Speaker 3: you know, you don't have to write Yamel anymore if
Speaker 3: you don't really want to do you.
Speaker 1: Have to read it though what he wants to. That's
Speaker 1: my problem. I don't want to read it. I don't
Speaker 1: want to write it. I don't even want to see it.
Speaker 3: It's so readable though, Yeah, of all the of all
Speaker 3: the formats, of all the formats, Yeah, we're not reading
Speaker 3: at least so, but that means that, you know, if
Speaker 3: you do want to create a hey, I want to
Speaker 3: make sure I can build this and run the tests,
Speaker 3: that's a pretty quick prompt to say, get me a
Speaker 3: gi hub action workflow to do this.
Speaker 4: But if it's all about the prompt, I mean, don't
Speaker 4: you just have to say take this application, make it
Speaker 4: secure and maintainable.
Speaker 3: Does I mean you'd get something out? I'm sure I
Speaker 3: think what happen, what that actually would be is a
Speaker 3: bit of an issue. But I mean, even even within GitHub,
Speaker 3: if you don't don't actively do that work. We've been
Speaker 3: using gen Ai inside get Up to do a bunch
Speaker 3: of things like dependent but so that's been around for
Speaker 3: a while. It just looks at your dependencies and tells
Speaker 3: you whether there's any that have security vulnerabilities and it
Speaker 3: will alert you to right. But now we'll also give
Speaker 3: you a pr to change that. It's kind of got
Speaker 3: a little bit better in that now because because sometimes
Speaker 3: upgrading the dependency doesn't isn't just a one for one replacement.
Speaker 3: You've got to actually code. Sure, go and find the
Speaker 3: code that you need to change and make suggestions to say,
Speaker 3: here is your here's a suggested code change that goes
Speaker 3: with that, you know, dependency update.
Speaker 1: Sometimes those dependencies are interdependent, so changing one requires that
Speaker 1: you change others.
Speaker 3: And even I mean there's other things in the whole
Speaker 3: get Up Advanced Security Suite where it all look for
Speaker 3: potential issues in code and give you code suggestions to
Speaker 3: update them. And that's using Jennet in the back. So
Speaker 3: that's using copilot and that kind of gives you a
Speaker 3: little bit more rigor around that code that you're putting
Speaker 3: in to product code reviews is another one, so you know,
Speaker 3: assign a PR to Copilot and it will do a
Speaker 3: code review for you. And there's there's plenty of other
Speaker 3: tools that do that as well. We'll look at get
Speaker 3: up prs and yeah, and do that work as well,
Speaker 3: like third third party tools.
Speaker 4: I have to wonder how far away we are from
Speaker 4: having a really good code review bot like that is
Speaker 4: more thorough than any human.
Speaker 3: Yeah, it's interesting. There's there's I mean that's also dependent
Speaker 3: on your company's standards and what you care about with
Speaker 3: a code review as well, so it is a little
Speaker 3: bit personal. I know with Copilot code review, you can
Speaker 3: set you can give it custom instructions to say, hey,
Speaker 3: when you're doing a code review, here is some additional
Speaker 3: context I want to give you. And pretty recently I
Speaker 3: think we change that so you can give custom instructions
Speaker 3: that are different for when you're writing code and when
Speaker 3: you're reviewing code, and when you're you know, doing the
Speaker 3: hands off coding agent. So you can be a little
Speaker 3: bit more specific about what stuff you care about. So
Speaker 3: you could have some custom instructions in there to say,
Speaker 3: every time you do a code review, make sure that
Speaker 3: all of the code has testing around it in the
Speaker 3: code coveration.
Speaker 4: And all criticism wrapped in a compliment sandwich.
Speaker 3: I mean you're absolutely good? Yeah, I mean you really?
Speaker 4: You talk about the challenge for me is someone who's
Speaker 4: done a lot of code review bit around a cloud.
Speaker 4: Code reviewers, like the best reviewers, often are kind of
Speaker 4: a difficult personality because they're very detail oriented, right, and
Speaker 4: so actually having to present the results in a form
Speaker 4: that is palatable to the reviewee is important too. Like
Speaker 4: somewhere's the LM with its own wavering obsequiousness like this
Speaker 4: might be meticulous and report like yeah, like what more
Speaker 4: could you ask for a code review?
Speaker 1: Yeah, you're talking about like the code review people. I
Speaker 1: imagine Olton Brown watching you cook, you know, and giving commentary.
Speaker 1: Why didn't you do that?
Speaker 4: I would I would wet myself that now was standing
Speaker 4: on my shoulder.
Speaker 3: I was cooking, like, there's no way, no way.
Speaker 1: Why didn't you temper those eggs?
Speaker 3: I mean, it's the matter with you, I asked. I
Speaker 3: asked GIPT the other day. This was a comedy thing.
Speaker 3: I asked PT the other day to abuse me when
Speaker 3: I gave it an error or something and it refused.
Speaker 3: It wouldn't it wouldn't do it. Yeah, we did a
Speaker 3: kind of a middle ground where it told me the
Speaker 3: code was terrible, but it wouldn't it wouldn't abuse me.
Speaker 3: So I don't know, you might get.
Speaker 4: Billy Hollis in there because people abuse the software, all
Speaker 4: of them.
Speaker 1: Yeah, it's like I have Billy Hollis program that model.
Speaker 3: You must suck as a coder. Yeah, I guess he
Speaker 3: could do that. You could even like have a look
Speaker 3: at who committed that and then look them up in
Speaker 3: a database to see how they prefer their feedback.
Speaker 4: Yeah, it could be tailored.
Speaker 1: I have a tangent here speaking of non secuiturs. Do
Speaker 1: you ever see a possible day when GitHub co pilot cli,
Speaker 1: for example, could work against a local inference engine like
Speaker 1: or Lama.
Speaker 3: So I think you can do that with other tools
Speaker 3: in VS code at the moment, I don't. I mean, yes,
Speaker 3: it's the short answer. I can see that possibility for sure.
Speaker 3: One of the things that I know GitHub has been
Speaker 3: doing lately is trying to give you a bit more choice,
Speaker 3: even if it's not inside the gitub ecosystem. So your
Speaker 3: Copilot subscription can now include you know, Claude and Codex,
Speaker 3: And I think that's another one.
Speaker 1: Great And so if you can reach out to CLAW,
Speaker 1: it could reach out to a LAMA just as easily.
Speaker 1: I mean, the real secret sauce there is knowing about
Speaker 1: your local repo and you know, I can do my
Speaker 1: own check ins and all that stuff.
Speaker 3: But yeah, I mean you can. You can definitely call
Speaker 3: out to your own lms that are hosted in Azure,
Speaker 3: so you can say, I am I want to you know,
Speaker 3: host a five three you know, language model in foundry
Speaker 3: and then use that as my cop.
Speaker 1: It's got to be it's got to be a Microsoft URL,
Speaker 1: not a local r L. Yeah, because obviously it's a
Speaker 1: Microsoft thing.
Speaker 3: And yeah, I also I'm not one hundred percent sure
Speaker 3: when the show goes out, and I don't know everything
Speaker 3: about what's going on in engineering.
Speaker 4: So I guess just like moving. So it's coming out
Speaker 4: next week, we're pretty close to It's basically, if you're
Speaker 4: invoking into a foundry, you have access to everything there,
Speaker 4: deep seeks there, like you name it right.
Speaker 3: Yeah, absolutely, Well.
Speaker 1: The issue I'm getting at is that we see a
Speaker 1: future where companies want my customers won't allow me to
Speaker 1: use a tool that shares its data across the internet
Speaker 1: in any way because they're so concerned about privacy and
Speaker 1: digital rights and all that stuff that they don't want
Speaker 1: their database schemas and their code, all that stuff going out.
Speaker 1: So we're going to have to use I'm going to
Speaker 1: have to use In one case, I have a customer
Speaker 1: coming up here that's going to demand it. It's already
Speaker 1: in the contract. So unless I have access to a
Speaker 1: local LLM, I can't use an agent.
Speaker 3: I can. Yeah, I can absolutely understand that that as
Speaker 3: a requirement for organizations I think, and I'm biased because
Speaker 3: I speak to GitHub customers, but I often get the
Speaker 3: question about I need to run my LM locally because
Speaker 3: I don't want to stand to copilot. And I asked
Speaker 3: them where their code is stored. It's on GitHub, Like, well,
Speaker 3: then we have your code already, like we're I mean,
Speaker 3: if you're worried about that that boundary, it's already there.
Speaker 3: But I can understand, Yeah, definitely, if there's some parts
Speaker 3: of your code that you you do not want to
Speaker 3: expose outside at all, then running local models definitely works.
Speaker 3: I think that part of the issue is that the
Speaker 3: models that we tend to use by default, so the
Speaker 3: claudes and the code exits and the you know, the
Speaker 3: rest of those. They are huge things that run on
Speaker 3: a ones you know, in the cloud, and you know
Speaker 3: this show is very successful, but you don't have the
Speaker 3: money to run one of those in your basement.
Speaker 1: I don't think, oh yeah, well, you know, the machine
Speaker 1: that I have running Olama is very fast and it
Speaker 1: produces results instantly, in fact, even quicker than I can
Speaker 1: get out of cloud. Yes, because I'm the only one
Speaker 1: using it.
Speaker 3: It definitely is no longer the case that you have
Speaker 3: to use the cloud ones to get a good result.
Speaker 3: I mean, for a while, you know, you could run
Speaker 3: these medium language models I guess, or small language models
Speaker 3: on your machine and get results. But they went very good.
Speaker 3: These days, they're pretty good, Like you get to.
Speaker 1: Around a thirty billion model and it's fast. Yeah, they
Speaker 1: do it because they got.
Speaker 3: Nasty, stinky fast the boring part, without a doubt.
Speaker 4: But yeah, it does speak to a future of a
Speaker 4: programming team, you know, ten fifteen people working together with
Speaker 4: a rack of their own compute just from the token
Speaker 4: expense perspective, like if you're really going to go grind
Speaker 4: it on this stuff. This whole excuse of I didn't
Speaker 4: get my future finished because I ran out of tokens.
Speaker 3: That's got to end. There's got to be our solution
Speaker 3: to that one, right, Yeah, and that that is actually
Speaker 3: one of the selling points of of these tools that
Speaker 3: GitHub as well as Microsoft as well as a bunch
Speaker 3: of other companies have been trying to push. Is this
Speaker 3: idea of abundance where you can you can fire off
Speaker 3: a problem to ten different agents and then see what
Speaker 3: the best result is. But you're right, that does cost tokens. Yeah,
Speaker 3: and yeah, I mentioned before that you don't necessarily get
Speaker 3: built by the number of you know, cycles that you
Speaker 3: go through, and that's true, but you're still using those
Speaker 3: those tokens behind the Somebody is still using those those
Speaker 3: cycles behind the scenes.
Speaker 4: You remind me, and I think I said it's the
Speaker 4: last show too. Like I come from the ol app
Speaker 4: world where we used to build these huge cubes and
Speaker 4: do an ounce on them. And back then there were
Speaker 4: several different data mining strategies, but all of them are competationly
Speaker 4: bit complex enough that you would literally spend weeks figure
Speaker 4: out which one to run, and then at some point
Speaker 4: in that when the cloud came along, it's like, you
Speaker 4: know what an easy answer is run them all and
Speaker 4: then have another another test to figure out which one
Speaker 4: was best. Yeah, you know, there was only like I
Speaker 4: think at one point we test there was like twenty
Speaker 4: two different strategies of data mining on this data sets.
Speaker 4: So just and you can get there with the software
Speaker 4: developments that I too, where it's like, yeah, there's a
Speaker 4: bunch of different ways to try and solve this particular problem.
Speaker 1: Just try them all, try them all, especially getting an
Speaker 1: agent to help you with that.
Speaker 3: Yeah, the fan out model of kind of like get
Speaker 3: five agents to try and solve it and then come
Speaker 3: back and see which one is the best. Yeah.
Speaker 4: Yeah, that's crazy, man, And we're I mean right now
Speaker 4: where there's all this conversation about GPU constraints and COVID
Speaker 4: clasts and so forth, like that's clearly not what we're
Speaker 4: going to do at the moment, but you can see
Speaker 4: a world like that.
Speaker 3: The irony is though, that to get the best results
Speaker 3: sometimes you have to break things down in just the
Speaker 3: smaller part. So I think we've mentioned this before, but
Speaker 3: breaking it down into the smaller tasks and then firing
Speaker 3: those tasks off. So the idea of you know, how
Speaker 3: you implement this grand feature that just use one you know,
Speaker 3: agent and one like back and forth cycle that's not feasible.
Speaker 3: You're not going to get a good result. So there's
Speaker 3: probably a happy medium here where you can break it
Speaker 3: down at a level that's going to give you a
Speaker 3: good result and then fire that work off and maybe
Speaker 3: use smaller model to do those initial pieces of work local.
Speaker 3: So I know that there's definitely work behind the scenes
Speaker 3: to do things that give you a bit more control
Speaker 3: over what models are used for different pieces of work.
Speaker 3: So you know, if you want to create a specification document,
Speaker 3: maybe you don't need the gigantic, huge thinking model. Maybe
Speaker 3: you just need a smaller one that you can cost
Speaker 3: a lot less money, that's quicker and iterate a bit more.
Speaker 1: That seems like something that could be a preprocessor, right
Speaker 1: that could look at your prompt and determine which model
Speaker 1: to send it to.
Speaker 3: Yeah, well, honestly, that's what happens these days. When you
Speaker 3: send something to Gemini or Claude or chat GPT. The
Speaker 3: first iteration really is what does this person want to
Speaker 3: do and where do I send that information? So when
Speaker 3: you're like MCP for example, which has become really really popular,
Speaker 3: that kind of first initial what does this person asked for?
Speaker 3: It's a Hey, here are the tools that you've got
Speaker 3: available to you, and here's what they do. And here's
Speaker 3: the question that the person asked, what tools do I
Speaker 3: need to solve that problem? And the skills Yeah, the
Speaker 3: skills or the whatever whatever else you want to call it.
Speaker 3: I guess, yeah, winning around. But yeah, that that first
Speaker 3: iteration can be done with quite a small model. And
Speaker 3: I think there's some of that that happens locally in
Speaker 3: VS code. So if you have a look to the
Speaker 3: folder structure. I think I did this a little while ago.
Speaker 3: There is a like a small model that sits there
Speaker 3: that does some of that work up front, so you
Speaker 3: don't necessarily have to send send that information and you
Speaker 3: can literally.
Speaker 4: Do this with confidence. You know expressions too, right, It's
Speaker 4: like I run it through a small model, but it's
Speaker 4: such a known it may be a complicated request, but
Speaker 4: it's such a known function. It's back back a chunk
Speaker 4: of code with a ninety something percentile. Confiden, It's like,
Speaker 4: do not continue, but if you come back in sixty percent,
Speaker 4: all right, kick it up into a higher model and
Speaker 4: see if we can get to a higher a percentage.
Speaker 4: So you're only confusing as much computis absolutely need recognizing
Speaker 4: all those small models are far cheaper than by the
Speaker 4: time you get to the big one. And if you
Speaker 4: needed that one time, you know the time is worth it.
Speaker 3: And they don't necessarily need to be language models. They
Speaker 3: can be a bit more specific, you know, the old
Speaker 3: school what we used to do with machine learning before
Speaker 3: we just threw everything at an l M, where you
Speaker 3: know it's a little bit more specific to the task. Yeah,
Speaker 3: this person ask this question, here are the tools? What
Speaker 3: should you know? What do you need to do? You
Speaker 3: don't need to absorb to have absorbed the entire Internet
Speaker 3: text to in that question. Yeah, I keep waiting.
Speaker 1: We were just talking about this last week.
Speaker 4: Yeah, sure, I keep waiting for a completely software development
Speaker 4: centric model to be built. It's it's not good in
Speaker 4: anything else except software, and even then you'd probably want
Speaker 4: to tailor down. Hey, I only need one that's good
Speaker 4: at C share of javascripted SQL.
Speaker 3: Yeah. I think the sticking point at the moment of
Speaker 3: those is that if you're asking for things in natural language,
Speaker 3: you get a huge shortcut just by absorbing the world's
Speaker 3: natural language. And then the pattern matching means that it
Speaker 3: kind of can interpret that really well, and then there's
Speaker 3: the coding pit. But yeah, I mean you could break
Speaker 3: that up into two pieces. One that's really good at
Speaker 3: interpreting what's required, another one that's really good at writing code.
Speaker 3: I'm not deep enough into the engineering side of co
Speaker 3: Pilot to, you know, to know what they're doing along
Speaker 3: those lines, but that sounds total.
Speaker 4: I know from some of the papers that I've read,
Speaker 4: there's lots of conversation about specialist models and an orchestrator
Speaker 4: is in front of it that says that makes that
Speaker 4: assessment and then sends to various orchestrator the specific models
Speaker 4: and in order. It's almost like a map reduced, break
Speaker 4: it up, fire it after multiple enities, roll it back together.
Speaker 3: Yeah. I suspect that's the future for sure. Yeah.
Speaker 4: Yes, it's back to that thing you said we couldn't do,
Speaker 4: which was sending other of all prompts. Like the fact is,
Speaker 4: if this architecture works what it is, you'll send them
Speaker 4: other role prompts out and it'll carve it up for you.
Speaker 3: Yep. So there's some really good projects that kind of
Speaker 3: that help you do that. I mean, the problem with
Speaker 3: sending them other orble prompts is we have never been
Speaker 3: wonderful at defining exactly what we want to people. Even
Speaker 3: so by the time you get the requirements document and
Speaker 3: then the specification document and then the you know, the
Speaker 3: functional spec list. To a programmer, there's something has been lost.
Speaker 4: And the English language especially is you know, almost intentionally vague. Yes,
Speaker 4: so often it's tough to be clear of what you
Speaker 4: intend once you get past the first paragraph.
Speaker 3: Yeah. Like we say, the lms are non deterministic, but
Speaker 3: I mean really human language is nondeterministic. So even if
Speaker 3: you could send that mother of all prompts and get
Speaker 3: you know, exactly what you've asked for back, there's going
Speaker 3: to be some assumptions made along the way, and then
Speaker 3: you've probably got some things wrong. So there's projects like
Speaker 3: spec kit or just that technique I guess which which
Speaker 3: kind of walk you through that process of Okay, so
Speaker 3: what are the requirements that you have. Here's a big
Speaker 3: markdown document, look through that make some changes however you want,
Speaker 3: either directly yourself or just asking the agent to do
Speaker 3: that work for you. That's also in plan mode in
Speaker 3: viscode as well. And the idea is, you know, you
Speaker 3: are defining it as accurately as you can, and you're
Speaker 3: working kind of with the agents to do that, and
Speaker 3: then you move on to the specification of this is
Speaker 3: what technical implementation we need, and it's still using large
Speaker 3: language models and coding tools to do that work or
Speaker 3: to help you do that work. But ultimately what you
Speaker 3: end up with is these quite well defined individual tasks
Speaker 3: that then you can get good results from when you
Speaker 3: send them to a coding agent. They're small pieces of work.
Speaker 3: You can put tests around them, you can examine what
Speaker 3: comes back from each of those pieces, and then you
Speaker 3: know that gives you a little bit more rigor around
Speaker 3: what code ends up coming out. Then even if you
Speaker 3: send a mother of all prompts to something like the
Speaker 3: like the Copilot coding agent, or if you send an
Speaker 3: issue to that agent, that's kind of what it's doing
Speaker 3: in the background as well. It says, right, i've got
Speaker 3: this issue, I've got this description that the person's given me.
Speaker 3: Let's break that down into requirements, let's break it down
Speaker 3: into its specification. Let's define a bunch of tasks to do,
Speaker 3: and then let's do those tasks. And I think we've
Speaker 3: found that you get a much better result doing it
Speaker 3: that way than you would otherwise.
Speaker 4: I certainly seen a lot of folks now starting to
Speaker 4: use the tools to write the prompts before running the prompts,
Speaker 4: and I do you know, I wonder if we shouldn't
Speaker 4: be making more of this confidence equation visible as you
Speaker 4: go along. It's like, Hey, I don't want to actually
Speaker 4: attempt to execute this prompt until it's in the ninetieth
Speaker 4: percent pile of confidence. So let's keep iterating on it
Speaker 4: until we can clear up the vagaries that will probably
Speaker 4: you know, send the tools down the wrong path until
Speaker 4: you're really competent. This is an awesome prompt as a
Speaker 4: very good chance of producing code that's useful. It's interesting, right,
Speaker 4: like it is. That's the whole can of worms. We
Speaker 4: go back and forth. But it's something I think I'd
Speaker 4: done as a PM anyway, where you know, the customer
Speaker 4: gam theset requirements is like, wow, these look like requirements,
Speaker 4: except that you didn't actually clarify anything here. Let's go
Speaker 4: work through the yeah, And.
Speaker 3: That kind of gets to the core of the problem
Speaker 3: is if if the people doing the work don't actually
Speaker 3: care a lot about the quality of what's coming out,
Speaker 3: then you can't make them care. And that's again not
Speaker 3: a new problem. It's just you can get a lot
Speaker 3: further without caring these days, I think a lot faster.
Speaker 3: And so yeah, and again that's kind of why, that's
Speaker 3: kind of where you can put some rigorin. So if
Speaker 3: you have these CI builds and these quality checks and gates,
Speaker 3: you can even do gates like with AI in them
Speaker 3: to say, hey, can you just make sure that this
Speaker 3: has been looked at? And this has been looked at
Speaker 3: and it's vague enough that the large language model will
Speaker 3: be how to interpret you know, yeah, it doesn't look
Speaker 3: like they've looked at accessibility on this page at all.
Speaker 3: Those things can be used as well. So having that
Speaker 3: that pipeline that we've always had, even if it's kind
Speaker 3: of AI enhanced, can can mean that if you do
Speaker 3: have people who don't really care about the quality of
Speaker 3: what comes out, you still have those those checks and
Speaker 3: balances in the way.
Speaker 4: I appreciate that. And you're again leveraging the strength of
Speaker 4: these tools to be meticulous and good at going down
Speaker 4: checklists and catch all those details so that you can
Speaker 4: be sure of things when the tool gets to avolved.
Speaker 4: The checklists and they're all red you know checks or
Speaker 4: green checks you've done something good.
Speaker 3: Yeah, Yeah, that's exactly right. Yeah. I mean they're powerful tools.
Speaker 3: Using them for the right reasons in the right way
Speaker 3: is you know, the way we should be doing it.
Speaker 3: Just like you know, one sentence prompt it looks okay,
Speaker 3: you'll lower it into PROD. That's not really the right
Speaker 3: right way to use them.
Speaker 4: You're going to find out in a hurry you were wrong.
Speaker 1: That's right, damnian. Is there anything we missed that we're
Speaker 1: we should bring up before we sign?
Speaker 4: That?
Speaker 3: Nothing huge? I just I just wanted to jump on
Speaker 3: that that comment about the confidence intervals that Richard had.
Speaker 3: I feel like that's something you could absolutely add into
Speaker 3: your custom instructions or your agent's MD file or whatever
Speaker 3: it is that you use to say, each time I
Speaker 3: ask you to help me define something, can you give
Speaker 3: me a confidence interval at the end to tell me
Speaker 3: how how accurate you think you are? And that being
Speaker 3: a you know, standing order would mean just imprompt Yeah,
Speaker 3: that kind of sits in there.
Speaker 4: It's instead of looking at the developer and seeing if
Speaker 4: they look confused or not as your prompt isn't that good?
Speaker 3: You know?
Speaker 4: Now you have the software giving you a number. Although
Speaker 4: if you're smart, you just make it into a set
Speaker 4: of faces too, right, He goes, oh, well that's the
Speaker 4: sixty percent. Look confused. You could yeah, think about how
Speaker 4: much we already do this when you're trying to pass
Speaker 4: instructions along and just like do you get this? Do
Speaker 4: you are you on board? Like, don't what we need
Speaker 4: to do this to the software too.
Speaker 1: I still wish these things would say I don't know
Speaker 1: the answer when they don't instead of making stuff up.
Speaker 3: Yeah, you can be a little explicit about that. And again,
Speaker 3: custom instructions agents MD that kind of thing to say. Look,
Speaker 3: if if you know you're not absolutely sure about something
Speaker 3: I've asked, then please prompt me to define that a
Speaker 3: bit more clarifying or something to clarify. Yeah. But then
Speaker 3: I mean you sometimes end up in a loop where
Speaker 3: it tries to be far too helpful and you're constantly
Speaker 3: field questions yeah, and you almost have to interrupt and
Speaker 3: say no, I think I think you've got it. Just
Speaker 3: just go.
Speaker 4: You've had enough detail, Now go work. But you know what,
Speaker 4: you've also had that employee that you know, rather do
Speaker 4: the work, would like to just keep asking questions.
Speaker 1: I've had to press control C a couple of times,
Speaker 1: you know, when you know Claude in GitHub co pilots
Speaker 1: Cli says, ah, I know the I see the problem
Speaker 1: and it's completely wrong, you know, and then it goes
Speaker 1: off trying to fix these control see break ye, no
Speaker 1: you're wrong about that. And then it comes back with
Speaker 1: of course you're exactly right. Yeah, yeah, you're right.
Speaker 4: Turn the shining is down.
Speaker 1: It's been great talking to you, Damien, and come back
Speaker 1: again soon.
Speaker 3: Absolutely, I won't wait until the next job this time.
Speaker 1: I think definitely. We have a lot to talk about,
Speaker 1: all right, and we'll talk to you.
Speaker 5: Next time on dot net rocks.
Speaker 1: Dot net Rocks is brought to you by Franklin's Net
Speaker 1: and produced by Pop Studios, a full service audio, video
Speaker 1: and post production facility located physically in New London, Connecticut,
Speaker 1: and of course in the cloud line at pwop dot com.
Speaker 1: Visit our website at d O T N E, t
Speaker 1: R O c k S dot com for RSS feeds, downloads,
Speaker 1: mobile apps, comments, and access to the full archives going
Speaker 1: back to show number one, recorded in September two thousand
Speaker 1: and two. And make sure you check out our sponsors.
Speaker 1: They keep us in business. Now go write some code.
Speaker 1: See you next time you got jam bands
Speaker 4: And