Episode 378 of CppCast with Gail Ollis, recorded 8th March 2024 This episode is sponsored by Sonar, the Home of Clean Code. In this episode we talk about the Contracts MVP, the new Cang release, Safety & C++ and the Spring Conference season. Then we're joined by Gail Ollis. Gail talks to us about getting started on a career in C++. Welcome to Episode 378 of CppCast, the first podcast for C++ developers by C++ developers.
I'm your host Phil Nash, joined by my guest co-host Matt Godbolt. How are you doing today? I'm doing really well, thanks. Why am I here? Where's Timur? I'm glad you asked that. Timur is travelling again at the moment. He was in London just last week and now as we record this on Saturday, he is in Tokyo, I believe. He's actually there for the Standards Committee meeting, which is, as we record this in just over a week's
time, but he went a bit early with the family to have a bit of a break there. He's going to be out of the picture for a little while, at least for this episode and maybe for the next one as well. We've pulled this together really at the last minute because I haven't really had a lot of time either. Just recently, so literally just yesterday, I asked both Matt and Gail if they were able to join us here today. Everything's a little bit last
minute. That's why we're running a little bit late as well. We really want to say how much I appreciate both Matt and Gail coming here on such short notice. It's no problem. This is what just in time feels like, right? Just in time podcasting within a couple of hours of asking that you've got two people in a chat room and here we are recording. Glad to be here. Thanks for asking me. Thank you.
At the top of every method, we'd like to read a piece of feedback. This one's from Paul Luckner who wrote, first of all, I'd like to express my gratitude for carrying forward the legacy left by Robin Jason. Your episode added delightful touch to my daily post-clench walks. Thank you for that, Paul. It does go on to suggest some future episodes on some of the open source libraries that you can find on CPP reference, particularly singles out Quantlib, which I think will be.
I thought when he said this, that we'd been in episode and quantitative before, but I couldn't find it in the previous episodes. I know it's been mentioned a few times. In fact, I got me thinking as well that it would be good to be able to more easily search the previous episodes. Paul had the same idea he pointed out that it's harder than it can be. One of the things I did do with the new website was to at least put all the episodes
on one page. You can search the titles and the opening paragraphs, but it could be better than the meantime. You can do a Google site search. If you do want to search it, at some point, I may get around to doing a site search built-in, but don't hold your breath in the short term. You're a busy man. Yes, you could say that. But thanks for all your comments and suggestions, Paul, and everyone else that's been sending
in feedback. We do like to hear your thoughts about the show. You can reach out to us on xmastodon.com or email us at feedback at cvbcast.com. Joining us today is Gail Oles. After two decades as a software developer, Gail eventually became obsessed with human aspects of the job that she began talking about the Metek conferences. She left the day job for a psychology degree, followed by a PhD research in the psychology of software development. Sharing knowledge
is the new day job in an accidental second career as an academic. Gail has taught programming and cyber psychology. A research, cybersecurity for software developers, and now has fun teaching problem solving and software engineering to finally students at the University of Portsmouth. Gail, welcome to the show. Thank you. It's real pleasure to be here.
I'm fascinated. Cyber psychology sounds like, is this like where I get my large language model, my chat GBT on a couch and ask questions about its mother or what on earth is that? Oh, that would be so cool to do. I want to do that now. So, you know, you hear people saying humans are the weakest link. I have no truck with that. Humans are, you know, humans have been here through like, you know, just years and
years of evolution and we're not built to operate in this environment. But if you understand us and you take the troubles to understand people and do things right for them, then you can avoid them being the weakest link. So the people who say humans are the weakest link are the weakest link. So, it's over. But yeah, Robinson was wrong. Yeah. Yeah. Yeah. You're not, you're not the weakest link. There are so many things where things are written
such that it's easy to make mistakes and it's harder to do the right thing. And the responsibility lies with the organizations and the developers. And, you know, a little bit of stuff remains there. But with the individuals with the users, but most of it is, you know, there's issues about security by design, including user interfaces in that. And just saying humans are the weakest link is lazy and failing to understand them. And that's where I come from with the
cyber psychology, you know, actually look at how are we exploited? What's perfectly natural normal and evolution or, or can't say evolutionarily, which, which, which characteristics we've developed through the years have actually been successful in getting us to hear can be
abused by people to get the better of us. But actually, once you understand that, it's much easier to avoid them and also the whole load of things like best, my, my, my pet example, looking at emails on my, on my phone and trying to scroll through and look through the mail. And I can't, have you had to find a way where I can go see where a link goes to in an email on my phone. I've occasionally almost clicked on it just in the act of scrolling.
So yeah, is that my fault if I click on that evil link? Yes. Well, I think, I think, yeah, we, it sounds like for the wheel, we'll be asking more about it in a very shortly. Yeah. That is a strong link to what we're going to come into. So we're going to get in a promise. So we're going to get more into that in just a few minutes. But first, we've got a couple of news articles to talk about. So
feel free to comment on any of these. Okay. First of all, contracts MVP. And we talked about this a few times on the, on the show before there was a post on Reddit from, from Steve Downey, contracts MVP shipped should point out that the word ship there might be a little bit misleading. Have it also of air quotes around that just to read the first paragraph. Just to clarify that a little bit. So the WG 21 study group for contracts announced
that they have shipped an MVP to the other review study groups. So there's still a long way to go. But the longest journey begins with a single step. No, come on. That is an interesting definition of shit. Next steps will be criticism review by the language and library evolution groups. But it is a big milestone because it has been many years coming with lots of very broad differences of opinion that have managed to come together for consensus to
get to this point. So I think that's definitely worth celebrating. As it happens, Tim actually did a talk when he was in London, just this week, which I didn't get to because I was busy, but it was recorded. So I'm going to put a link to that in the, in the show notes to that sort of captures the almost the current state that the contract is in at least at the point that stayed down as post was written. Apparently there's been some issues that
have come up since. So there's still more steps to go. That talk, by the way, does have some technical difficulties with the recording. So it's not the not the best recording. Tim said that he will do a better one at ACCU this year. So if you can wait, wait for that one. But if you want to see what the current state is, we'll put a link to that talk in the show notes. So the next use item, LLVM18 and therefore clang has been released
just recently to the reasonably big features that are dropped in this one. The biggest one from C++23 deducing this, the explicit object syntax finally supported in clang. So we're going to look forward to that. That's in some cases, that could be a real game changer for the way you write code in C++. The other one may be a smaller thing, but a nice little touch. And that's the the placeholder identifier underscore. This is actually not even in C++
yet. It's still proposed for C++26 or C++2C, as we're calling it. But the idea of this is that if you don't care about referring to somebody when it captures in a variable, you can use the underscore identifier, like some other languages like Python, for example. And you can use it multiple times, so you can reassign it to things which you can't do in Python. That always catches me out there and upstart. I like make up more and more
stupid things I don't care about. Yeah, so it seems like a little thing, but it does make the language more expressive, having to define these throwaway names and then get the compiler or a static analysis tool to warn you that you're not actually using those names. It's a bit of a pain. So a little fix, but an interesting one. Yeah, I wonder how that'll play into a lot of like testing libraries tend to also use
this as the match is anything kind of indicator. So you can write mocks and fakes that say, hey, I want to sing, but I just wanted to be called with anything here. Maybe they'll maybe that'd be compatible. What really this obviously makes me think or hearing this makes me realize I need to go and update a website I'm involved in to actually have a LL of clang 18.1. So maybe I shouldn't be doing that right now.
Okay, we weren't holding it. No, should be live by the time anyone's listening to this. Anything that lets you quiet and down your warnings without switching warnings off has got to be a good step, right? Yeah, some of the works in the static analysis, so I can definitely get behind that sentiment. Yeah, oh, the phrase just a warning is such a red flag for me. Yeah, no such thing. So our next news item is our sort of a blighitry news
item in the world of AI, but with a C++ bent. So Gemini was launched this recently. And there was a post on how can use that Gemini refuses to talk about C++ 20 concepts to somebody under the age of 18 on the basis and it's an advanced language feature that is too dangerous for people not of that age to be talked about, which is obviously quite ridiculous, but it does show we've got some way to go in the plain. Save templates, you know, is what I don't quite understand, where is even coming from
on this front? But show the microphone, can't pick up facial expressions here. No, right. The incredulity. You can probably imagine. Yeah, I mean, do you now have to have a license when you're older? Because I've known an awful lot of people write any language, frankly, at the age of 40 something that looks like they might be 13. So I saw for some guardrail going to write, but just to read the opening of that hack and use item. So personally, I could have been up on Gemini, is it seems
to have been centered to the point of uselessness. I asked it yesterday about C++ 20 concepts, and it refused to give me actual code because I'm under 18. I just checked again in the Gova similar answer when I tried check GBT 3.5, it did give an answer, although it was a little confused and the code wasn't completely correct. So whichever way we go, usually. Oh, and then it says that concepts for an advanced feature of C++ that introduce potential risks. I know what to prioritize your safety.
Now, so much. No. I'll put the link to the hack and use item. But I'm also going to put the link to a YouTube video of a Twitch streamers reaction to this news as well, because I think that probably captures from Gaill's facial expressions as well and maybe even a little bit more. Talking of safety in C++, there's been another article, but with this time, it's actually from the White House. So technically, this is coming from Joe Biden, but obviously
not in person. I don't think he's going to see plus plus yet. But from his administration, we're now urging developers to drop C and C++ in favor of memory safe languages. This is not a new thing. We've been talking about this for a couple of years now, but it's gone to the next level now. This is now got the stamp of the Biden administration. So maybe that will have more consequences, but it's I think it's also raised it to even
more of the mainstream that are picking this up now as well. So we're going to hear more about it. A couple of highlights from that. It says this new 19 page report from ONCD, that's the office of National Cyber Director, which is quite an interesting title. Gaill's C and C++ has two examples of programming languages with memory safety vulnerabilities and named Rust as an example of the programming language it considers safe.
I thought Rust was coming here. Yeah, yeah. Also says about 22% of all software programmers used to C++, which is an interesting statistic. 19% used to see as of 2023, according to statistic, making them less popular than JavaScript, Python, Java and a few others. But the Taiobi programming community index ranks only Python as more popular, followed by C, C++ and Java. So yeah, quite interesting that that doesn't quite match my experience of
it. No, I mean, I don't know how one could get a decent understanding of who's using what, though, without like literally surveying every single person and most people don't participate. So gosh, gosh knows where they're getting these things from. And that sounds like it also excludes all the stuff that's already out there that's been being
maintained. So what we have to now go replace all of that, maybe? Yeah, I wonder if it's because when it says used C++, maybe not programmed in C++, but maybe these are C++ library under the hood. So like all the ML developers using Python, what are using C++ as well? That'll be my guess. But who knows? Yeah. And what was it? 19% for C? That's what it says. I can't. I can't run a last or C in the world. Actually, I know I do remember
a last or C in the world. And it was before I went off to do my degree. So that's a long time now. Yeah, yeah. The report seems to make all the earlier mistakes of like lumping C and C++ together as if they're effectively the single language. So because it's not quite as bad, but because there was a report recently that did seem to acknowledge that actually they are different languages and they have different
trade-offs. But this one seems to take a step back in that respect, unfortunately, which is particularly unfortunate given that this has gone a bit more mainstream. So yeah, I'm already hearing reports from people. I wouldn't normally be hearing from about this and asking about it. So we prepared. Okay, then finally just wrap this up. We are kicking
off the spring season for conferences. So C++ on C, early bird tickets are open and the call for speakers is open, but that's going to close pretty soon as this goes out, I think. So maybe maybe another week or so. But that, so if you've not got a submission in, do that. It's going to run third to fifth July. It's going to be two day workshops
for the first time. And something that we're calling the early bird option. So you've always been able to buy early bird tickets for the main conference, but there have been other, have a ticket type. So we have the complete conference package, which includes a workshop and some other other benefits, the dinner and that sort of thing. But they don't get released until the workshops are known by which time the early bird is over.
So the only bird option to the borough this term from finance is going to say the sales on my day job. So the spark a recognition from Matt there. The idea is you put a small amount down now. And then you have the option to buy a ticket early bird price later once all the details are known. So I'll post a link to all the details. Is that an American style option or European style option? When do you get the choice? How long do you
never mind? Don't worry. It's a good shop futures or something. Yeah. Yeah. Yeah. Yeah, we might expose some other derivatives in the future. All the things will be in the show notes. I won't say anymore. Now we're getting that going again. Yeah. And there are so many puns waiting there to be had that we really. Exactly. No, not an option. Using a stud C++. The conference that runs in Madrid is coming up in April. And I'm actually going
to be speaking to this one. I'm quite excited about because I've not been there before. So I'm going to give my rewiring the brain with test driven thinking talk, which we might talk about more today actually because it's an element of psychology to that. So there we go on topic. That's on the 24th. I think 24th I've got 24th to 25th but it's over three days. So I think I've got one of the days wrong there. It's around that time
end of April, but check out the page just to be sure. And there's this pre conference workshops as well. C++ now is coming up 29th of April to the 3rd of May. It's the first time I've seen it starting in April actually. Possibly because previous years they've had problems with the Apple being closed. They may have changed the timing around a bit. I think the call for speakers for that one is closed now. And the ACCU schedule is out.
ACCU is going to run 17th to 20th of April. There are two day workshops, all the details and the link that I'm going to put in the show notes. I'm speaking there as well as is Gail who also has a workshop and we're going to talk about that in a minute. So that was our link to. So yes, Gail, you're doing a workshop at ACCU. But before we get to that, go back to your bio earlier. Says you're a software developer for quite a long time.
Before you went back and did a degree in psychology. So what led to that change in direction? Well, like a lot of people, I was spending a lot of my time as a developer working on existing code. And I was fascinated by the fact that sometimes that was really straightforward. Occasionally I was lucky. There was something that was just so easy. And I thought it would be a few days working it turned out. It just set up so well. Just seeing the
stick out there and seeing exactly what I needed to do. Make those changes and it was beautiful. And I could keep it beautiful in the process. And on the other hand, and probably rather more of the time going in there and going, why on earth did they do that? And I basically went, why on earth did they do that? One time too many started looking at psychology and
software development. And wasn't really finding very much at all. Most of what I was finding to searching online without access to academic papers or anything was all about an even actually, well, I had access to academic papers, but it was more about end users and you know, HCI and all that stuff. And nothing that I found really, still, and still nothing actually noticed significantly about how about other developers as users and readers of
the source code. You know, there's a bit of stuff about readability. But ultimately, all devs are users of other devs source code and build environments and tests and automation and office behavior. I mean, you know, the whole breadth of things, you know, it's, they make a difference. So what peers do makes a difference on it. And the people I was working with were smart people. It was a place with, used to be a sort of research kind of oriented
organization commercial, but nonetheless, sort of researchy. And they still had that. And there are people that who really cared about their craft, but not, but that did not mean they were able to make things easy for others to work with and give the amount of time we spend working on existing stuff. And the moment anyone's written something, you've got some kind of legacy because it constrained to work by what they've already
done. I use legacy to me, oh, stuff, written by other people ages ago. But yeah, it's one of the things I found out my PhD research, my best quote, I think from it, I saw him write a legacy system in three weeks. I'm guilty of having done that at least once in my career, I'm certain. Yeah, I like it. Yeah, I'm also being, I think one of the other things that kind of drove me away was the sort of the time pressure to do that. So if you get in
there and you find a mess, there is not time to sort out the mess. Nobody wants you to sort out the mess. There is no appreciation for sorting out the mess. So it's, it's basically get on and bolt on another bit of mess. So it's voice scout principle goes out the window. I can't, you know, well, I can leave it as much mess. No, I don't, you know, it means leaving it messier than you found it if you don't actually improve it, right? So you
just bolt on another lump of mess. And the voice girlfriend is the fact that you should leave the count, count ground cleaner than when you found it, right? And that is, yeah, yeah, yeah, yeah. But it's the first thing to go when you're up against the deadline and then it becomes compounding, right? Yeah, absolutely. Honestly, I could make a fortune if I could
figure out a reliable way to measure the cost to the future of doing that now. You know, I mean, I know instinctively it's costing a fortune because other people are having to read through that stuff. We don't throw it away, right? We put a lot of brainpower into it. And, you know, don't waste it. Don't want to start it from scratch every time. All I sometimes have wonder if it might actually be better. Although, though, that is a, I think that's
the, that can happen. You know, you get into a pattern where everyone, there's a learned response where it's like, well, we just, we've reached this point where it's so awful no one can deal with it. So we make version two of it. And then within three years, you're back in, you know, looking at version three and like, there's going to be a better way. Yeah, absolutely. And that's kind of what I felt. I thought, you know, some of that better
way is about just understanding how we would make it a better way. Some of it is about the, um, the organisation and the willingness to let people do that. But actually, if you write less of a mess in the first place, yeah, it's not like it's going to take more time. Uh, I've actually really linking back almost seamlessly back to the security thing. I've done some work with, um, colleagues, uh, the University of Portsmouth looking at blending
security into software development processes because it tends to be an us and them. And it shouldn't be, we've looked at ways to bring that together. And I'll give you a link to attach about some papers we published on that. But yeah, it's, if you do it right from the start, it's not an imposition of extra. But what does doing it right from the start
mean and how do you make that happen? So that's, so yeah, I got kind of frustrated with writing, I don't know, revisiting the same old code with the same old kinds of problems under massive time pressure, not being able to do a good job. And increasingly curious about even when, when people did have time to do things, why would they do them a particular way? And one particular colleague who had a real love for state machines, and they're
great when the thing naturally lends itself to that. And when they don't, it's, uh, why and ask did they do that? And he's, yeah, he's my favourite one to cite. But that's amazing because I was thinking so far, everything you said sounds like sort of the sort of archetypical consultancy or management consultancy kind of thing that would come in and fix
the organisational problem that means that that those, those things happen. But then when you cited that example, it's like, no, that's definitely some one individual's particular way of looking at software that, that leads them in that particular direction. And then if you have a bag of like 10 people or 50 people or 100 people in an organisation all doing that, then of course there's, you're creating mess. So how do you, yeah, deal with
the problem in each individual's? Oh my gosh. Exactly. Yeah. And it's not, yeah, they need to understand it's not their code. It's like everybody's code. Wow. We also had one person there who was the only person who would, you know, they had some mathematical skills to do something complex. So he was the only one who had the faintest idea about
how any of that worked. So I mean, truck number on that code was, was one. Yeah. So lots of, yeah, lots of some of it organisational, some of it, you know, the expediency we get from those things done, but some of it, yeah, actually people who cared about how to do things and had chosen, and there was another one, I can't remember what his pet thing was, but it was something he'd learnt some years ago that was a good way to do things. And he
was sticking with that regardless of how much things changed over the years. So yeah, I got really curious about that. A bit burnt out with doing, doing the same old, same old with the same, same mess and yeah, and leaving all these campgrounds in a mess. So in the end, I just cracked and went, well, you know, I'm not finding the answers online anywhere for this. Let's go study psychology and find out a bit more about it.
Very interesting. It sounds like there's a lot more in common with my two areas of interest, which is testing and CDD and static analysis. It's interesting to correspond to a lot of what you said there. One thing that I thought of when you were saying about getting start with this mess and it gets worse and worse over time, but if you just use that voice out principle, you can actually be cleaning things up. That's saying we talk about it
at Sona, just a bit Sona, right? There I swung through the show. Thank you so much. We've got this this Finkel Cleaners E code, which is exactly that idea. Have you heard of the the get of feces? No, I haven't. You've heard of the ship of feces. So it's just like an amazing take on that. And there's a statistic that has been wrapped up in this that every five years for any non-trivial code base that's under active development, you
will touch about half of the code. So if you're applying this clean as your code principle, you know, leave every bit of code that you touch, clean as you started, then over five years, you will have cleaned up half the code base. And it's the half of the code base that you touch the most by diminishing. The other half you didn't touch for five years. So it's probably okay to some extent. So I think there's a lot of interest in this idea
of how come I get these things under control. But maybe more so recently, because we do see so many big code bases spiraling out of control and we need to train them in somehow. So I think the time is really ripe for somebody to come in with some good ideas on this. Yeah, well, if anyone wants to be large bucks for consultancy, I'd like to be arranged.
That's one of the kind of sign up. I haven't had this career change. I still hang around with, you know, sort of primarily, you know, primarily a C++ conference, or other conferences. You know, I just how I stay in touch with people, but also doesn't matter what the language is, right? Whether or not I'm not in that with that, because there's all this other stuff around it, which actually I'll come back to when we talk about one teaching now. But yeah,
yeah. Okay. Everything's linked to everything's linked. I mean, so I mean, certainly, I, you know, you just told a couple of stories of folks who like to write code in a particular way. And I can't help while you two are talking just sort of allowed sort of turning a mirror on myself. And I'm wondering what, what can we as software developers learn about maybe ourselves?
Maybe that's a difficult question for a number of reasons. But you know, what can we learn to try and overcome or maybe treat the code, as as you say, like it's a combined organizational own thing. But I can't help it. It's mine. And that's a human thing, right? To want to know, but what psychology tricks can I learn to help me with that? Yeah, I think that sort of, you know, there's a good slide to that as well, right? There's the
caring about it. So the caring about it is important too. So, I think it probably comes from there. One of the things I found with my research, so what I ended up doing going, I can't be, but when I, after I'd done my psychology degree, don't know, that was okay. Now I've got a whole lot of interest, put the software engineering aside for a few years while I did that. Okay, I've got all this psychology now. I've the, the each to apply software engineering hasn't gone away. So that's where
the PhD started. I've, okay, you can't do a PhD on the basis of things that have annoyed you in your job, right? You can't account, but you have to go ask other people and find out that it's annoyed them too. So I did some interviews where the whole load of very experienced develops. I think
it added up to some of that 500 years experience. Good. Wow. And basically a minute, a minute or five years per person, because anything you do that you have problems with what other people are doing in the, you know, I think I've got a couple of papers to back it up anywhere between so like three and five, but you can be let loose with stuff. Anything before that might be because you knew. Yeah. If you're still having problems with this after five years and more with people
doing it, chances are it's not a you problem. I don't mind if you get enough asking of people. So I wanted to, I wanted to talk to them about what other people do that help or hinder in them. Yeah, that those situations I was talking about earlier about you come along to do something, thinking it's going to be an easy job and it takes you all week because it's such a dreadful
mess or you think it's going to be a dreadful mess. And it turns out to be just beautifully, easily grokable and you're in there and dumb and thinking, wow, and you've left it just as beautiful as you found it. Yeah, yeah, but it happens. Yeah. I was going to say the fact that it's so rare, I think it's telling the fact that we all lit up when you said that, you know, we've all had that experience where you have gone in and gone like, wow, it was just a three line change and it took
me five minutes and I wrote a test and everything's happy. And now I can move on to my things. So rare, but how do we capture that more often? Right. Yeah, that, yeah, that is sad, doesn't it? So I wanted to get that overall picture from other people about what things annoyed them. And they were wanting to include everything, not just sort of down in the details of the code. So I asked about,
I asked a whole load of questions. I did it with a sort of card sort style of thing and asked them about, oh, builds and automation and asking questions and willingness to answer questions and things. And about half my cards, but little, I had 52 of these, that's probably the proper deck of cards. And little nitpicky things about indentation and brackets and long indecent-indented loops and things.
And one in there about comments and one in there about identifiers. And all of my, so all these little nitpicky things that, you know, I remember having annoyed me, I included them, but also the wider things of the nitpicky cards. I'm calling them nitpicky now because they turned out to be this thing with a PhD. It seems obvious afterwards. It seems obvious afterwards.
You've probably done it right, but it's at the time it's not. And it's so, yeah, the two that came out with any kind of response, you know, of significant, because I was asking me, does this make no difference to you? If someone does this, it makes a little bit of difference, makes it stay a bit better. Great deal of difference. It's that day where you thought it was going to take ages and it's
just beautiful. And then the dark side of that, you know, you sort of, you trip over it, but then you get on with it or the, this is an absolute nightmare that you're plowing through and you, you know, we all remember those ones. And none of, yeah, none of the things about the details of the code mattered much. Apart from comments, and they went, yeah, let's not go there with this PhD, because they ranged everywhere from, I sent them to be white on white so I don't see them to,
even if they're a little bit wrong, they're still a bit of a clue. So no consensus. And I was looking for consensus, right? We're not going to get consensus. I mean, I could have told you beforehand, we wouldn't get consensus about comments. So that one was, yeah, okay, no consensus there, put that on to one side. The other one that was interesting and the one that he pulled out was about identifiers. That's basically it. So people telling me they had vegetable themes,
people using these, there was a spot, spot characters. Just be clear, we're talking about like the names of variables. Oh, yeah. I see. Just making sure. I mean, okay. Yeah. Yeah. So we had fun. People traveling trouble thinking up variable names, right? So they just go with the theme. So there was a Star Trek theme of, you know, Spock and Kirk and stuff. There were vegetables. There were fish, like, you know, got a variable called Habuk. And then there were the cutesy ones
as well, like, Iql for something that was little. And it was it moon. Yeah, moon. So moon was a status flag and something should only happen when moon was set blue. I mean, it's mean, like, this is a sign of of intelligent people who have got clearly like a creative part of them that has to be scratched. And they've tried to find a way to use it. But as a person coming in public, but as the person coming in afterwards going like, what the heck is moon equals blue?
You got to do exactly. Exactly. So that's the one thing they agreed on. And I think about this one afterwards. I figured actually some of the things I was talking about in the code with the indentation stuff. Ultimately, that's grammar, right? And you can figure it out. It has rules. You can follow it. It may take you a little bit longer to follow it. They can also be automated. If you really care about it too much and say, well, okay, I'm going to reformat it my way.
And then follow it. That kind of stuff. Right. But so yeah, the names you can't, yeah, so there's this. Well, that's yeah, but you have to have to really do that yourself. Right. The system can't go for you. Yeah. Yeah. When you hit it. Anything in the theme. Oh, no. Then we get, does we get vegetables and wiggle and spot again? Yeah. And the wiggle was popular. But yeah, so if there's this phrase, by, from comes from nomadski, I think, colorless, green ideas sleep furiously.
Perfectly grammatically correct. You can now recognise every single grammatical element of that utterly meaningless because the, um, semantically, it's useless. So I think that's what the difference is with the why it's ultimately all, we all know the syntax and, you know, you can use it for slightly for better or worse, same as English grammar, but you can still figure out where it's, um, where it's headed. So all the other stuff was about the bigger things and the what, yeah, this,
so this brings me back to your question, Matt, which I have remarkably under what I have. You've remembered. Yeah. I'm glad you can. One of it. So you ask, how can we make people better at this? One of the things that came out big on the, on the sort of behavioural things was, um, is willing to talk to others. So rather than going off and coding in a corner, I thought, you know, that was maybe a mixed one because willing to, no, he's willing to ask
questions. That was it. He's willing to ask questions because, you know, you might think of, there's somebody who's always coming and asking questions and it's their RTFM, forget the saying, you can't you do it, but actually, that's socialising those ideas. So you haven't got somebody off working in a corner coming up with something weird that's hard to follow. It's, you know, it's,
it's kind of, it's like code review, but even sooner. Really? Well, you know, if you're pairing, you get it at that stage, but rather than just go and do a thing or go find out how to do something, go ask some questions and someone says, oh yeah, you could do it that way, but actually, we've already got this thing in the code base or yes, that's cool and it's new, but, you know, nobody's familiar with it. So, you know, maybe we'll use that in a future project, but we'll talk about it
beforehand. Or yeah, actually, that's a really great idea. Wish we thought of that sooner. Go ahead and do it. But those conversations have happened. So I'm afraid, yeah, one of my students last year, bless him, said my module, realized my modules came well down to it's all about communication. Yeah, yeah, yeah, yeah, four words. And that is it. Yeah, if you, if you get that, frankly, don't need the rest of my, the rest of my, that's the rules. But yeah, that's, that's the thing.
It's, you know, it's not even if you know how to do something, still socialising that idea, not, oh, yeah. So I've more anecdotes. So we have the person who decided, you know, literally, they were going to change our wiki platform from our partner, which way around it was, which, my, my, and um, wiki media, I think it was media wiki, whatever it was called. So whichever rule do those happened in it would have been that we were using one quite happily as a team.
And suddenly one day he spent all morning migrating it to a new one. And I'm asked for, I'm asked for, yeah. And now the entire team apart from this guy who will remain unnamed. And we have quite a rude name for him normally. Um, is, um, yeah, well, he's the only one who's familiar with it. And the rest of us having now having to learn new platform, mid project, which was, yeah, just completely stupid. I mean, it's also the same guy who started using a folding editor back in
the days when this was a rare thing. And it had special markup in it. So he started using that and checking it in, complete with this markup. So of course, it was complete mess for everybody else. Yeah. So I mean, I don't think it's more like an lack of empathy that is anything else, right? Well, yes, indeed. Yeah. But it was also shiny new toys. You know, we do feel, so it's not, yeah, he's an extreme case. Yeah, not not going to name him. I'm going to resist that temptation.
But yeah, it's, um, he's an extreme case. But there are lots of other less egregious cases of people putting in a shiny new toy. Like, oh, there's a new framework. Let's, yeah, let's use this fantastic framework, which will do exactly what they want for this one tiny thing out of the thousands and thousands and things it can do. Um, yeah, don't cost it. Stop me on frameworks. Um, anyway, so yeah, but that's, that's, uh, that's a cost to the team of having
to understand what's going on there. So conversate is not just about making the code work. All right, you can go download stuff and make it work. If you haven't, if you're going to done something different to what's there in some way and you've not socialized that idea with the team, then you're going to write something that's, it's going to be hard even for your current colleagues to understand. Let alone somebody else who comes along later and they've got used to
how the rest of the code base is. And then suddenly there's this weird bit in a corner that does it all differently. That's, that's, that's different. Yeah, that's the, uh, friend of mine says that like a team is where everyone succeeds and fails together. But if you're off in a corner, like, in your, your own personal successes, can I play with cool things? That's not necessarily good for the, the team. Yeah, exactly. There's the idea in systems theory and local optimizations,
often a bad thing. Yeah, you're, you know, optimizing your workflow and everything's great. If that's going to slow the rest of the thing down, it's the net negative. Yeah. And you're missing some much bigger optimizations that somewhere else in the landscape that you haven't looked for. Yeah. Yeah. Yeah. So actually, last, last code base I ever worked on, yeah, it was somebody looked through that one time and found five different implementations of linked lists, none of them a library.
Right. So yeah, this is, yeah, this is, that's got partly a lack of clarity about, you know, what we've got and what we're using and partly people going and sort of, yeah, just writing a thing that works and because you wouldn't think, right, you don't, you know, if you need a linked list, you can probably all write a linked list still even though we shouldn't, but, you know, we could, we could do it, right. But yeah, so you're not, you're not going to ask someone to help without that.
It's not talking to people is not about asking, just about asking for help, right? No. If I ask you to help, generally, you're involved, see other person not saying anything while you explain the problem to you. No, you're the rubber ducking. Yeah, absolutely. So yeah, man, did that answer your question? Absolutely. That was, that's, that's great. I think I've got a lot
to learn on that front. And yeah, it's, it's really interesting to hear that, you know, like most of the problems that we face really are not technical because we're all reasonably good at what we do. We like to think we are. We can learn how to become technically better, but social problems are really the heart of how we interact when there's more than one of us involved. Yeah, it's a people problem. Yeah, and there's always more than one of us involved. Even if it's you from yesterday,
you're big. Yeah. You're like, you're the day before. Oh, gosh. Yeah. This is why I do add comments, because I cannot figure out anything out like the following week or yeah, indeed, the following day. So there's some correspondences as well with, we think like BDD, they're talking about a TDD earlier, but BDD, the focus is ready again on communication, communication with other team members, but also people outside the team, and using the concept of
ubiquitous language. So establishing what, you know, terms you're going to use that front to mean things and instruction, things in a way that everyone can agree, this is how we write things. So there is that commonality of understanding. Yeah. So some ideas. I'm going to pick up that outside the team as well, because I have some brilliant and lovely and insightful students, but when it comes to giving them some requirements and saying, ask any questions you like,
the other week they just went away and sat at their tables and figured out for themselves what this very, very requirement meant and didn't, I've well, one pair of them came and asked questions, and honestly, you're right, if you're listening to this, I've never been so disappointed in you, because you're normally so insightful. I like that there's an entire module of of what problem are you trying to solve, and yeah, they didn't go, and actually I'm not doing
interviews. It is very common though, and this kind of fact is the psychology, but doesn't it, that we feel like, well, you know, we're the smart ones, we're paid for being smart, we should figure out this problem for ourselves, and if we can't, then we're going to look bad. So we do take it on things for longer than we should. Yeah, we are the victim of our own problem-solving skills as well, because we need those problem-solving skills, right? We've got two sort of
orthogonal demands there. We've got to be able to solve this complex problem where we're interacting with the computer to make it do something, and that's not a trivial task, but also completely unrelated to that. We've got to be able to talk to people and understand what's going on, and getting both of those at a good level is quite hard, and one of them's
really, really hard to teach. Yeah. So the point where I've got a friend who, on one occasion, told me he had two, and I was like pretty much equally good candidates overall, but one was better on those humaning skills, and one on the relevant computing skills, and he opted for the candidate with the humaning skills, because computing skills, he was going to be able to teach them, whereas trying to take the one with the good computing skills and improve their humaning skills,
was, you know, it's a tough call, that one. Yeah. But there is stuff to you here, there's a skill stuff you can do by the practices you follow. Yeah. Well, I don't want to dig into more about what you do with your students, but we need to take a break for our sponsor read. Dimension earlier, that we asked once about Sonar, the home of clean code. So Sonar Lin, as a free plug-in for your IDE, helps you to find fix and even learn about bugs and security issues for the moment you start
writing code. Adding Sonar, Cue, or Sonar, Cloud to your CI, CD pipeline, your whole team can deliver clean code consistently and efficiently on every check-in or poor request. Sonar, Cloud is completely free for open source projects, integrates with all the main Cloud dev-out platforms, and is usually zero config. So back to our interview, and I mentioned we wanted to get back to your students because you're teaching this workshop at ACCU, which sort of builds on this work.
Do you want to tell us a little bit about that? Yeah, it's my idea. I came up with a few years back when we were saying, well, we love all these old faces that we see, yeah, same people year after year, and it's great to get me up with them, but it would be nice to have some younger people coming in and sort of get just get new people and fresh faces in, because that really refreshes things.
And I was looking at thinking about it from the point of view of somebody writing at the beginning of their career, and it's a lot of money to ask your employer to pay if you don't really know what you're going to get from it. And it might be a bit intimidated because you might think you might look at previous years and think, well, that's all going to go massively over my head. I don't understand a word a bit. Just like the fact that actually ACCU has got a lovely breadth of things.
I mean, I haven't been, don't tell anyone about how much you've been to receive this plus talk. I ACCU for years, absolutely years and years, I mean, over and over and over again. It's time that you've come. It's time that you've come, yeah, because there are other tracks and interesting things to, yeah, it's like, I'd say it stopped writing it so long ago that I'm now massively out of date, but it's there's still other things to talk about. Loads of other things to talk about,
there's way more than just the courage. But nonetheless, if you look at that and you go, oh gosh, that's really complicated and it all feels like very intermediate or advanced stuff sometimes. And also, you don't even know that that stage in your career, probably what a conference is, necessarily. Certainly my current final year, so I've introduced the idea to the minutes, kind of, it kind of comes to us news to most of them because where would they have learned about
what a conference is? So I thought about that. I thought, well, yeah, it'd be nice if they had that kind of their own little mini conferences that was sort of designed for them. I've been to quite a lot of talks over the years by really good speakers who've done a kind of, well, it's a back to basics on things. So for example, I am from Ravenna Dunne, lovely one on code reviews, and Giovanni Asperini, a Dunne, lovely one on architecture, and Roger Rall had done a beautiful one
on debugging. And it's one of those sorts of talks, you know, when you sit there and you mostly know it all, but there will be some nuggets in there where you go, oh, that's a good idea, I haven't thought of that. And they sat down nodding a lot, which makes you feel really good and sort of smug and, you know, but with it all nicely organized as well. So all the stuff you kind of knew, but you couldn't put it
so eloquently because you haven't sat down and written a talk about it. They've done that, so it's putting all the little ducks in a row nicely, organising the knowledge that you do have. I think some nuggets to it, and those are actually really nice ones to attend. But actually talks like that,
are ideal for people who are at the beginning of their careers. Let's tell teachers on these good things we know, and good habits and best practices in a more in-depth version than some headline, because a headline best practices no good without the principles behind it, you end up with all sorts of weird things happening because of that. So I proposed that, got together my dream team of speakers from a bunch of people who's talk site seen and really liked. Who have I missed out from there?
Jess Higgins is with us now being a software grandpa, keeping the young and some falling down the mind shaft. And Jo, we've got John Skeet talking about testing, nicely balanced with what I just talk about debugging. And there is, to wrap it, it's kind of covering your entire life cycle really, because we've also got Chris Oldwood talking about deployment. So gone right through from sort of what we're thinking about with the architecture and our coding practices, testing and debugging
all the way through to deployment. Plus, because it's at a tech conference, there's a section on presenting for geeks, because I've been to some, I've just recently acquired some new photos for my presentation on that, which we've completely unreadable code from, you can't read from the front row, let her in from the back. So, yeah, if we're going to start encouraging them to come to conferences, we'd also like to encourage them to speak. And when they do, we'd like them really to have their
slides legible, please, or their live coding legible. That's where most often goes wrong, they've seen it run on slides too. So it's a, like it's a perfect, mini conference for, I'd be like, finally, I'll undergraduates and people in their first few years in the job, you're maybe
up to, maybe up to the first five years to match my PhD research cut off. And we go through, basically in order of, in the order that things would happen in a software development with the, with the presenting bit, shoved in this and where, then at the end of the day, we have a little
lightning talk session where they can have a go at standing up and speaking, but just in a small room rather than in the front of the whole of the Bristol suite, which is, well, fairly intimidating place to stand, with a microphone in hand, especially for, you know, for the first time ever, if you're standing up with a microphone to speak, that, well, you don't want to be doing it there. Friendly though it is, you don't know that until you've done it, right? So, so we do a nice little
lightning talk session and we always have enough of them volunteering to do that. And last time we did this, we had, oh, at least two of them, I think, did stand up and do lightning talks in the Bristol suite, one of the later evenings. Yeah, it's, it's beautiful. So, yeah, it's, you know, it's small, so they get, you know, a lot of attention. They go, they get to ask a lot of questions. They've got some really good people to ask questions of there. So, yeah, and it's
really good value as well. It's sort of designed to sort of give the taste of without it being too massive of a commitment to, you know, just come try out the idea of a bit of conference. And then some people who book that do actually stay on for the rest of it, but if they don't, they've still got a feeling of what it's about and learnt some really good stuff. So, I think those of us who do it
really enjoy doing it. And in fact, I got Jeff Higgins in there because he really wanted to attend it because it's a great program of talks, you know, it's that those lovely, yeah, this kind of makes sense and all sort of ties it up neatly in a bow for you, but actually, you know, any of us would be quite happy to attend and do that sort of nodding along and oh, hang on, I learned something there. So, yeah, Jeff managed to get his way in just by being added to the dream team. No, no,
I'm not going to let you in until attend. You're going to be in your first years of your career, but if you want to come and speak, yeah, you can come that way. So, that's how it works. Well, I like the idea that it's like a conference within a conference. And I was wondering whether like you can even have a section in there that's a conference within the conference within a conference. I'm just going to give it some of the things. A recursive workshop. Yeah. That sounds brilliant. Yeah,
teaching workshops in a workshop. Yeah, maybe, maybe, maybe all the lightning talks could be a mini conference. There you go. Yes. Maybe I'll do that. Yeah. If nobody, yeah, if nobody wants here, sometimes some of the rest of us all have lightning talks ready to go as well. So, you know, we can get the ball rolling or filling a bit if they're, yeah, so if they aren't enough volunteering or it takes them a while to get the north to do it sometimes. So, yeah, I can do that.
So, um, so that's on the Tuesday, but then on the Wednesday, um, that I've got a session where I'm Wednesday afternoon, I will be bringing five of my, maybe best, from my best for some definition of best students. Because what I'm doing, I've got a module in this semester called Software Engineering Culture, which is basically everything but the programming. It's kind of like all those
other things that I asked about in my research interviews. So, we're looking at, we're looking at some history, we're looking at security, we're looking at culture and behavior and social impact and development approaches. I'm not going to go anywhere near the M word. Right. The approach is the one that's the future. Yeah. So, in fact, Kevin and Henry is coming in, this coming week to talk about what agile really is in the wild as opposed to the textbook version,
which will be absolutely super. You came into that for us last year. Yeah. Really good session. And we've got, uh, we've got a bit about, you know, got a bit about architecture as well, but none of it go away and do a thing because by this stage, if I can't go away and do a thing by going and watching a tutorial, there's nothing I can achieve by standing up in front of a classroom telling them exactly what the tutorial will tell them.
So, instead, what we've got is, um, three of us now with industry experience, sort of getting them to think about these things, watch some great conference videos, read some, read some interesting things like bits from the Phoenix project and bits from Cathedral and the Bazaar things, all sorts, you know, real mix of stuff to just give them that feeling of the bigger picture rather than just
sit down right at thing on your own. Um, and they've also got lab tasks to do in which I'm getting them to to pair or to mob or to work remotely with people or do some code review of each other's code or learn and learn a language together, all sorts of things, but please be working together. You know, go ask questions about the people, teach something, somebody something, learn something from someone just like you would do. You know, like sort of, you know, Phil, I'm stuck with this.
How on earth do you do this? And you know, you have a quick sort of live tutorial of it. And that, that's the lab tasks rather than go and create yourself an instance on this cloud service and run a thing on it. I think I can go do that without me interfering. I'm more, I want them to talk to each other basically. Here's all, here's all about communication. Oh, why did I go from there? Oh, yes. So yeah, so the assessment for that is basically a sort of mini conference thing. So
their first assessment, they have to submit three talk proposals. So to do this, I have to, I did, yeah, I last year I made the mistake of referring to it as conference proposals and some of them took that to mean, I was just doing an entire conference. And okay, no, talk proposals for conference. Yeah, well, yeah, and we know what we mean, right? It's like, you know, like, it's like parameters and arguments. We know which is which really, but do we actually worry about it?
And I don't, I don't, I, I, I, I only ever say arguments when I think someone's going to be checking, you know, don't go into a parameter about that. Oh, oh, dear. Um, that's throwing me. What was I saying? I was wishing that. Oh, yes. So we have them doing three talk proposals and a buyer, a speaker buyer. And they're, I've encouraged them not to make that look like a CV. And I've given
them various examples of people and shown them where to go and look for speaker buyers. So it's quietly introducing them to go, go look at some conference websites, go learn what's out there, you know, just subtly. And some of them have written really good ones straight. They've got the, they've got, they found their voice in them and some good, really good proposals. Then second part the assessment, they do peer reviews on those proposals. So they each of them review, let's see,
four other students proposals, each, each one having done three. So they review 12 proposals. And they give each of those a score. And then we process all of those schools. And for each student, the one proposal, get the highest score is the one they present in phase three. We're going to have a lot of mini conference just at start of the exam period where they present their talks. So 10 minute talks. And if there's a tie between them, we'll either go to the student say, which is
your preferred one or all adjust it to keep a nice balanced program. If you've got a whole load of stuff talking about AI, we'll drop some of the AI samples. They're quite a lot of AI ones in their environment. And so this is where the link to ACCU comes in very kindly given us a slot for them to come along and speak. And so five of them will be basically from that peer review process, we'll give us the short list. And then we'll pick a sensible collection of five that will
fit nicely at the conference and be a sort of complimentary set of things in there. So again, we wouldn't have five on the same topic there, even if they were if they were the top five. And also, you know, some students can't make it as well. So it's not necessarily exactly the top five, but from the cream of the crop as it were, we will pick a little again, also it's almost a little conference within a conference again, right? This is yeah. This is getting decidedly recursive.
Maybe I should run that within the, yeah. That was pressing. Yeah, maybe should run that within the workshop. Oh my goodness. And then we can do a really careers day. And now, no, no, no careers. Yeah, stop it. The reason they wouldn't work is if I've got this right, the first day, the workshop is experienced developers teaching the students, whereas your talk is more about the students give talks to the experienced developers.
Yeah, yeah, absolutely. I've called it. Yeah, I can't have it both at once. I'm going to gather recursive works. I like. Yeah, as well as you know, silly, keep me out. But yeah, it was, it was really, really nice. Did it? We did it for the first time last year. And they were really,
really good. They bring sort of a fresh voice to things and they tackled some really interesting questions about about the ethics of making software addictive and the impact of all the changes with games on making hardware obsolete by depending on the latest hardware and not having a sort of any compatibility with them that would work tolerably well with other kits. So it's, it's, there's an affordability thing there as one talking about how hidden illness has affected
them in two different software workplaces. An older student who's who's worked, who worked before he started and has worked during his degree. And I apologise to the others because I can't remember what those were. I've been more relaxed going into a 90 minute talk because we'd rehearsed the week before and they'd all done a nice job. And I was really pleased with them. I give them a couple of, you know, you could polish it up here and there. But absolutely no causes for concern
with any of them. So when I actually walked into the room ready for the presentations, all I had to do was introduce them. Then I knew they had it and they were nervous. But I was going, this is easy. I've got five speakers here. This one, yes, one of one of the most, how could I forget, how could I forget the one who dressed up as a minion halfway through his, what presentation? His thesis was that minions because of the sort of culture they've got, I began to get it wrong
and ask questions, find things out, were a pretty good example of an agility. And yeah, kind of supportive environment and stuff. And so yeah, he was explaining this, but the bit that will have all, for ever stuck in my memory is him sort of playing a little video partway through. And or during which he changed into a minion onesie. And so there was one about our responsibilities. Yeah, so there wasn't AI one in there as well. I can watch our responsibility to as, as developers,
to, to education in this particular case, that made sense for them. Not teaching C++ concepts, apparently. No, apparently not. No, well, they're pretty old enough to be allowed C++ concepts.
Yeah, so that's, but that's, you know, it's a, it's a cunning plan sort of with a similar agenda, I suppose, sort of like a better word to the workshop of just getting the, the younger developers coming into the industry to understand that there's more to it than sitting there at a keyboard in stereotypical hunched pose, turning out code in a darkened room. And sometimes you need to do that is what you need to do, right? But there's more to it than that.
And it always involves other people, which are awful lot of assignment stuff, doesn't it? Right. Well, that's what I can say. We have this cliche that, yeah, even if you study computer science, it doesn't really prepare you for working in software development, those other things you need to learn. So given them the opportunity to actually learn some of those things and be a bit more prepared,
is it an excellent idea? But I think frankly also, particularly the talk, it's going to be a different experience for the other people at the conference as well, not just going to the same old talk on, I don't know, C++ concepts, right? Yeah, absolutely. Yeah, it's different people with different ideas and yeah, it's, yeah, absolutely fresh perspective. So it's, yeah, it went, it went really, really well last year and they all presented beautifully. So yeah, I was very,
very proud of. Right. Well, I think we are coming up to to the end. We're going to have to start wrapping up traditionally. Now, final question is something on the lines of, is there anything else in the world of C++? You find particularly interesting. I know you said you've been a little bit out of the C++ world in terms of the latest developments for a while. So if there's anything else in the world of software development then that we haven't really talked about that you find particularly
interesting. I think because like I said, I was a developer for a long time. So you can imagine, I saw a lot of hype come and go. So I'm pretty skeptical about everything that people get excited about. I also see quite a lot of things come along with a name. I go, what's that? I have no idea what that is. Dependency injection was one. I went on earth and said, and then I went and found out, I went, oh, is that all? Yes. There's a lot of people sticking fancy names on things, trying to
look clever for stuff that we know for years. Those who don't study the past have doomed to forget it. Right. So it's, what do you say? I'll do them to the point where I don't know if some of the mistakes of the past. So yeah, there's this awful prejudice against older papers in life. Well, you mustn't, you mustn't include anything in your student work that's older than, or anything you publish, that's older than five years or 10 years. Maybe if you're lucky.
And you know, actually, if it's become obsolete, fair enough, you shouldn't be ignoring it more recent work, but there's an awful lot of very important old work that's just kind of, yeah, been forgotten. And it's not become out of date or be replaced. It's just languishing there because there's this fetish about the new. That's really, really good work out there being ignored, except possibly by people who are going away, I think you like, put a name to that
and write a book and that's. So AI obviously comes into this one. And I looked at that and yeah, I looked at that. Okay, yeah, that's this one feels qualitatively different to all these other advances and great ideas. Something has shifted in the technology there that is big, but we haven't yet learned how to use it. I think there's some really interesting work to be done about how it becomes a properly useful tool, not just the writing code, but for maintaining
code and working together in a team on the code. That's sort of where does that fit in to that bigger picture that isn't just hacking something out. And then next time you want something, you've got to write it all again. Where's that fit in with the testing of it and the working with things that
you've already got? It's I think there's a lot of very interesting work to be done there. So I think it's I think the hype is a lot of it is over the top, but I think with the right brains on it, there's also a fantastic new tool to be had in there, but it needs to not be down that all that's hope you know, we can do this and this and all this also know it can't and it needs not to be one of those things.
So that's that's might possibly my next area of writing. All right, interesting. Yeah, there's a bit of a wild west at the moment, like a new frontier, so exciting opportunities, but also a lot going wrong at the same time. And a lot of snake oil being sold by a lot of people, which I think well, it roads, you know, people's confidence in the idea itself, but I think you're right, girl, there's an in qualitatively different about this that will will leave a bit of a marker.
Yeah, if yeah, there would be a shame for it to be thrown away with the snake oil, wouldn't that? I mean, snake oil is the one thing that seems never to go out of fashion, right? But yeah, we have the wild west and we now we have the wonderful San Francisco, so I'm hoping we can pull off a similar trick with AI. All right, well, thank you very much for your comments on that and for coming on the show today.
Before we let you go, is there anything else you want to tell us like where people can reach you if they want to find out more? I'm there on LinkedIn, I think I may be the only girl, Alice. Right, okay, well, we'll put links to your social media links anyway. Okay, well, again, thank you very much for coming on the show today, especially at short notice and uh, well, giving us a tour of a really fascinating topic that we've not really discussed before.
Thank you also Matt for again joining at short notice and being an excellent co-host, and thanks for you listening for putting up with us being a day or two late, so hopefully we back to the usual schedule next time. See you then. Thanks so much for listening in as we chat about T++. We'd love to hear what you think of the podcast. Please let us know if we are discussing this stuff you're interested in, or if you have a suggestion for a guest or topic,
we'd love to hear about that too. We can email all your thoughts to feedback at tbpcast.com. We'd also appreciate it if you can follow CBPcast on Twitter or Mastodon. You can also follow me and Phil individually on Twitter or Mastodon. All those links as well as the show notes can be found on the podcast website at cppcast.com. The theme music for this episode was provided by podcastthemes.com.