Latest / ContraMinds Podcast - Unlocking Personal Growth and Professional Excellence / Annie Vella on Why AI Can Write Code, Engineers Need to Solve Business Problems (#072)

Transcript

Annie Vella on Why AI Can Write Code, Engineers Need to Solve Business Problems (#072) · ContraMinds Podcast - Unlocking Personal Growth and Professional Excellence

• 0:02
  SPEAKER_00: I think it's a mistake to expect that the software development lifecycle of the future is just going to be a subtly different version of what we've got today.
• 0:12
  SPEAKER_00: I think it's time to rethink it entirely because perhaps what we're doing now is in building these harnesses, we're building the machine that builds the machine.
• 0:20
  SPEAKER_00: And so we have to look for different signals using things like formal verification in one case, but when you start to think about it like this, it starts to feel more like a control system.
• 0:32
  SPEAKER_00: You can use generative AI to write code or to write the requirements or to write the tests or to write the deployment pipeline or to learn about all of these things.
• 0:42
  SPEAKER_00: It's more like electricity than, say, a calculator or a GPS.
• 0:47
  SPEAKER_00: But generative AI has the potential to take some of the more core cognitive capabilities as well.
• 0:56
  SPEAKER_00: The thinking, the reasoning, the critical thinking, right?
• 1:00
  SPEAKER_00: The judgment.
• 1:01
  SPEAKER_00: There are skills that we're happy to delegate to technology because they save us time and they were kind of toil, but we can't afford to be delegating all of our critical thinking and judgment as well.
• 1:21
  SPEAKER_01: In this episode, I'm talking to Annie Weller.
• 1:24
  SPEAKER_01: Annie Weller is an engineering leader, passionate software programmer, and a researcher.
• 1:30
  SPEAKER_01: She has got over 20 years of work experience across four countries and over 12 industry verticals.
• 1:38
  SPEAKER_01: She is today a researcher and her advisory work is at the intersection of AI's Impact on software engineering and agentic governance.
• 1:49
  SPEAKER_01: She is a thought leader and runs a very successful blog and speaks at various international conferences.
• 1:57
  SPEAKER_01: Over to my conversation with Annie Weller.
• 2:03
  SPEAKER_01: Today's episode is proudly brought to you by Effortless.
• 2:08
  SPEAKER_01: Effortless is the ultimate solution for startups and SMBs seeking seamless money management and compliance handling.
• 2:16
  SPEAKER_01: Effortless wasn't just created by anyone, it was crafted by chartered accountants and entrepreneurs who understand the pulse of startups and SMBs.
• 2:26
  SPEAKER_01: Visit www.goeffortless.ai and embark on a journey that will redefine the way you do business.
• 3:14
  SPEAKER_00: You're right.
• 3:15
  SPEAKER_00: It has changed a lot over the decades.
• 3:17
  SPEAKER_00: What is software?
• 3:19
  SPEAKER_00: At the end of the day, it's a lot of code.
• 3:21
  SPEAKER_00: Code is syntax, it's words, it's language.
• 3:25
  SPEAKER_00: It's a very well-defined, precise language that we use to very specifically define how something should work.
• 3:34
  SPEAKER_00: So you add these two together and it's almost a perfect match, right?
• 3:38
  SPEAKER_00: You've got this new technology that can generate language.
• 3:42
  SPEAKER_00: And if you give it some constraints and train it on programming languages and well-written code, it can generate well-written code as well.
• 3:53
  SPEAKER_00: And when we build software, we run it through a number of deterministic processes, right?
• 4:00
  SPEAKER_00: We've got that's what pipelines are there for these days, but you you compile it, you build it, you run some automated tests on it, you run it through static analysis, linters, and a whole host of things.
• 4:13
  SPEAKER_00: Those are our verifiable loops as well.
• 4:16
  SPEAKER_00: I know the there's a lot of conversation around how uh you'll see this either in um you know social media or or people like to say software engineering was never just about the code.
• 4:28
  SPEAKER_00: And they're right.
• 4:29
  SPEAKER_00: It should not, it was never meant to be just about the code.
• 4:34
  SPEAKER_00: But a lot of what we did was in service of the code being produced.
• 4:39
  SPEAKER_00: Um and and now with this technology, the writing of the code is almost entirely automatable.
• 4:46
  SPEAKER_00: Um it's not perfect, but we didn't write perfect code as humans either.
• 4:50
  SPEAKER_00: That's why we had all those verifiable loops to help us catch the problems.
• 4:55
  SPEAKER_00: And many engineers got into this career because they loved mentally solving the problem and then turning it into code through hard work, through effort, through um a a form of creativity.
• 5:09
  SPEAKER_00: And I think for them, the people who got joy from that type of work, they're really seeing the shift as something that's not pleasant.
• 5:17
  SPEAKER_00: That makes me sad because I I've enjoyed my career so much and I recognize it's changing, but I kind of hope that maybe we can start to define what it may look like.
• 5:26
  SPEAKER_00: It just looks different, I think.
• 5:32
  SPEAKER_01: So I I want to uh dive in on a couple of points that you made, and I've kind of uh you know noted them down.
• 5:40
  SPEAKER_01: Uh see one of the points uh that you said was uh the role of the software engineer is changing.
• 5:49
  SPEAKER_01: Uh so how is the role of the software engineer changing?
• 5:53
  SPEAKER_01: Can you define it by a framework?
• 5:56
  SPEAKER_01: Because I really loved your framework of the middle loop, right?
• 6:00
  SPEAKER_01: So uh so uh so how is it changing?
• 6:04
  SPEAKER_01: And was there no middle loop before AI?
• 6:08
  SPEAKER_01: And is the middle loop the new in-between uh between the inner loop and the outer loop?
• 6:15
  SPEAKER_01: So can you walk me through how it's changing the software engineer's role?
• 6:19
  SPEAKER_00: Just the the process of building software generally requires some form of solution design, uh writing code, reviewing code, testing it, refactoring it, debugging it.
• 6:32
  SPEAKER_00: And I asked software engineers um if they felt they were spending more or less time on these six core competent uh core tasks.
• 6:42
  SPEAKER_00: Um so that meant I ran two questionnaires six months apart with the same participants.
• 6:47
  SPEAKER_00: So I could see how their own perceptions were changing in that period of time.
• 6:52
  SPEAKER_00: And so that was between the end of 2024 and beginning of 2025, and of course, with everything changing so fast, things will be different today as compared to what I captured then.
• 7:02
  SPEAKER_00: Eighty-two percent of participants in my study felt that they were spending less time writing code.
• 7:09
  SPEAKER_00: And the only one of those six tasks where they felt they were spending maybe a little bit more time, just slightly above neutral, was reviewing code.
• 7:19
  SPEAKER_00: All of the other tasks they felt they were spending less time on, but not quite as as many as thought they were spending less time on writing code.
• 7:28
  SPEAKER_00: So how is it that this technology is, on the one hand, it feels like we're spending less time on all the things we used to spend time on, and somehow we're filling our time with something else.
• 7:38
  SPEAKER_00: So the qualitative data that I captured through some open questions, um I did some thematic analysis on, and inadvertently I saw in there, I started to see some in those in those responses, I started to see evidence of people spending their time on essentially a new category of work, something that wasn't well captured by those six sort of core tasks that I um asked about more specifically.
• 8:07
  SPEAKER_00: And I felt that this was maybe representative of a um something that I've given a name to, supervisory engineering work, because what they were describing was spending more time directing AI through prompts and iterations and sometimes quite a bit of frustration, you know, and then um evaluating its output to check for correctness and you know, how does this fit into the existing code base, and um and then correcting it when it's not right.
• 8:41
  SPEAKER_00: And I think that takes a different type of skill.
• 8:43
  SPEAKER_00: What happens to comprehension of the code, right?
• 8:46
  SPEAKER_00: So previously, when you did it by hand, you spent a lot more effort doing that, and you really you might not have understood the entire code base, but you understand the changes you made.
• 8:57
  SPEAKER_00: Whereas now businesses still demand that their engineers are accountable for the code that they are generating and committing, that's becoming harder and harder, especially when we're asking them to go faster and faster with this technologies.
• 9:10
  SPEAKER_00: Where we spend our time as they're the skills we practice deliberately.
• 9:14
  SPEAKER_00: And if we're not practicing those skills anymore, instead we're spending our time on something else, then those become the skills that we we will gain.
• 9:22
  SPEAKER_00: Interesting.
• 9:26
  SPEAKER_01: So uh there was the other point uh that uh you know you talked about in the outer loop, which is deploying, reviewing, monitoring, which was something that you once you deploy the uh code and the application, then you're kind of doing that.
• 9:42
  SPEAKER_01: Uh but that also today agents are taking over and running it, which means that you are actually having a middle loop that uh you know, from what I understood, where I'm neither rating the code nor doing the DevOps and the monitoring, which means that what am I doing, and therefore what skills as a software engineer do I need to build?
• 10:05
  SPEAKER_01: Uh, is really the question that you were asking.
• 10:08
  SPEAKER_01: So, can you explain that a little bit more?
• 10:11
  SPEAKER_00: Good point.
• 10:12
  SPEAKER_00: Thanks for mentioning the middle loop again.
• 10:14
  SPEAKER_00: Um so what's quite interesting is that as a professional software engineer, I I have heard the terms inner and outer loop for some time now.
• 10:26
  SPEAKER_00: And the inner loop was more, think of it as what happens on your local machine.
• 10:30
  SPEAKER_00: So if you're a software engineer and you're building code, you're in your integrated development environment, you're writing the code, you're building it locally, so that means compiling it.
• 10:40
  SPEAKER_00: But it's running your build locally and testing it locally if you can run your test locally.
• 10:45
  SPEAKER_00: Um, and then the outer loop was more about like once you're done with your it's sort of individual piece of work, you you might push a PR up, a pull request for somebody else to review and then merge it into a pipeline takes over, and then your product owner or the the person in the team that's more responsible for getting it released, maybe putting out some some comms about it, you know, and so that that's more of the outer loop.
• 11:13
  SPEAKER_00: But like you just said, the this this type of supervisory work, it's not really inner loop work where you are doing the work yourself and manually building it and feeling those individual little issues yourself.
• 11:27
  SPEAKER_00: Um and it's not outer loop work either, because that that's like when it's almost left your local machine and it's it's being integrated into the bigger code base.
• 11:36
  SPEAKER_00: Because I feel like it's a new category of work, maybe it's actually an entirely new loop that sits in between these other two loops.
• 11:43
  SPEAKER_00: Maybe it's a new middle loop.
• 11:44
  SPEAKER_00: Maybe it's that's where supervisory work happens.
• 11:48
  SPEAKER_00: Um and then I think maybe around the same time or a couple of weeks later, people started talking about harness engineering.
• 11:57
  SPEAKER_00: And by the time I finished the masters, nobody was even talking about prompt engineering anymore.
• 12:02
  SPEAKER_00: That's how fast this is all moving, right?
• 12:03
  SPEAKER_00: It went from prompt engineering to context engineering to harness engineering.
• 12:08
  SPEAKER_00: Now it's loop engineering or graph engineering.
• 12:11
  SPEAKER_00: And I guess I contributed to the problem myself by coming up with the supervisory engineering work.
• 12:17
  SPEAKER_00: And the sorts of skills that you need for that, well, that all is, I think, still changing and evolving almost daily at this point because it still feels like it's very important to have fundamental foundational software engineering skills, because otherwise, how do you apply that judgment to know?
• 12:36
  SPEAKER_00: How do you value evaluate and verify that the code itself is correct?
• 12:42
  SPEAKER_00: If you don't know what good looks like, you know, looks like without having done that, um gaining those skills in some way.
• 12:50
  SPEAKER_00: And that's a bit of a concern because a lot of the way that we gain those skills is by doing the job.
• 12:56
  SPEAKER_00: Especially in those first formative years, you know, we we learn by doing.
• 13:00
  SPEAKER_00: And if now the agents are doing it for us, how do you how do we gain that experience?
• 13:06
  SPEAKER_00: I have a feeling that we need to learn how to develop a and like a sixth sense on how systems are performing after they've been written by AI, because we are definitely moving in in that direction where we're letting AI write more and more of the code, and we're letting AI review the code that is written by another AI.
• 13:26
  SPEAKER_00: And so we need to be able to observe the system and see through like observability, right?
• 13:32
  SPEAKER_00: Looking at the signals that the system gives us to get a uh like a sense of whether it's doing what it's supposed to do.
• 13:43
  SPEAKER_00: You know, that's one way of looking at it.
• 13:45
  SPEAKER_00: Another way is to think about things like formal verification that might help us have a more confidence in the correctness of the code.
• 13:56
  SPEAKER_00: Perhaps not whether the code is doing what the intent of it was, because I think that's that's still where human judgment should should be utilized, right?
• 14:08
  SPEAKER_00: If you have a problem that you are trying to solve with software, I don't think that there's any mathematical style formal verification that will be able to judge that for you.
• 14:18
  SPEAKER_00: That's that's the human role now.
• 14:20
  SPEAKER_00: But how do you teach that?
• 14:22
  SPEAKER_00: Judgment and taste are not easy to teach.
• 14:25
  SPEAKER_00: It's almost like a trait, a human trait.
• 14:28
  SPEAKER_00: So we're in a very this is this is precisely why I felt like I need to step out of any loop at the moment and try and see uh observe the loops from outside of them to see, um, you know, and dive in every now and then to see what's really happening here.
• 14:45
  SPEAKER_01: Beautiful, beautiful.
• 14:50
  SPEAKER_01: So if I'm a say a 20-year-old or a 10-year-old engineer, software engineer, and I've already I I've built the knack of writing code.
• 15:03
  SPEAKER_01: Now that if the machine is writing it, uh the challenge that I have is that's a skill that's atrophies, right?
• 15:12
  SPEAKER_01: Because you know it's just going out of me.
• 15:14
  SPEAKER_01: That's one problem.
• 15:16
  SPEAKER_01: Uh it's great because then uh you know code is being generated at speed, and therefore uh that's great.
• 15:22
  SPEAKER_01: I think businesses will be very happy about it, but uh it's a skill that uh is decaying.
• 15:28
  SPEAKER_01: At the other end, uh if I really do not know how to review the code basis why it is writing it, uh then the challenge is my knowing doing gap starts to really uh you know increase.
• 15:47
  SPEAKER_01: So therefore, how do I prepare?
• 15:49
  SPEAKER_01: Because the challenge that I see is that uh if you do software testing, the nature of software testing itself is changing because you will have a set of use cases, you go there and you uh you know you test it out and then say it's done, now it's ready for deployment.
• 16:04
  SPEAKER_01: But now that the code has been written by uh you know an agent, uh the challenge is even the way you need to do verification uh has to be automated, and therefore the scale of verification uh is also reaching a certain velocity that probably uh there are going to be new uh, I would say, careers, new roles that are going to come up.
• 16:29
  SPEAKER_01: Is that the way software engineering is changing?
• 16:33
  SPEAKER_00: I think so, but there are elements of the production of software that can and should be abstracted away and centralized or standardized and done automatically for us.
• 16:45
  SPEAKER_00: And that's what platform engineers have been doing for some time now.
• 16:49
  SPEAKER_00: And and I think when we talk about harness engineering and building these harnesses, uh the the thing that your agents run within that keep it safe and put the right controls in place and governance and identity, and uh I think that's just kind of the next generation of platform engineering.
• 17:08
  SPEAKER_00: And then so then humans become more and more responsible for verifying the output of that.
• 17:13
  SPEAKER_00: And as you say, like with a huge increase in the throughput of the ability to create code, there is no way we can just ask engineers to r review it all by hand.
• 17:27
  SPEAKER_00: So formal verification was is the the it's part of this concept of formal methods of computer science where um you can prove pr given a precondition and a post-condition and an invariant, something that you feel must remain true, um, that a certain line of code, or used maths or code, uh is correct for an entire class of problems.
• 17:53
  SPEAKER_00: So for all natural numbers, this function will return true or will terminate or something like that.
• 17:59
  SPEAKER_00: And um it's more efficient in some ways than testing, because testing is almost like sampling, right?
• 18:06
  SPEAKER_00: If you've thought of all of the potential edge cases, uh then hopefully you've caught them all, but chances are you haven't because the problem space is too wide, right?
• 18:17
  SPEAKER_00: Whereas with formal verification, if you can capture entire classes of problem, then you can literally prove the correctness of some function.
• 18:28
  SPEAKER_00: But it is becoming easier to do because there's better tooling to do it now than when I was learning this 23 years ago.
• 18:36
  SPEAKER_00: And AI can help with it as well.
• 18:39
  SPEAKER_00: So um there's sort of two sides to it.
• 18:41
  SPEAKER_00: You need to be able to formally specify um your requirements in a in a formal specify specification language, and then um actually write the proofs that prove that this is true.
• 18:55
  SPEAKER_00: And and so perhaps we don't apply that to every piece of software that we build.
• 19:01
  SPEAKER_00: But if you're working for a financial institution or a healthcare provider, um where actually it really it does matter if if there's a subtle problem with the code that is now generated by an AI, that humans can't be expected to continue to just verify by eye, by sight, by hand.
• 19:22
  SPEAKER_00: Maybe in those cases, formal verification has a role to play.
• 19:28
  SPEAKER_00: I think it's a mistake to expect that the software development lifecycle of the future is just going to be a subtly different version of what we've got today.
• 19:38
  SPEAKER_00: I think it's time to rethink it entirely because perhaps what we're doing now is in building these harnesses, we're building the machine that builds the machine.
• 19:48
  SPEAKER_00: And so we have to look for different signals using things like formal verification in one case, but when you start to think about it like this, it starts to feel more like a control system.
• 19:59
  SPEAKER_00: We need sensors that tell us that the software that the agents are building is off slightly.
• 20:06
  SPEAKER_00: It's not it's not adhering to the requirements well enough, or it's not adhering to our coding standards and best practices.
• 20:14
  SPEAKER_00: So we must tweak something about the machine for it to do better on the next loop.
• 20:20
  SPEAKER_00: And that's exciting.
• 20:21
  SPEAKER_00: I think that's that's true engineering work.
• 20:23
  SPEAKER_00: Other engineering fields have used control systems and control theory for decades.
• 20:28
  SPEAKER_00: Maybe it's time that as software engineers we maybe we mature and graduate a bit to to thinking like other engineering disciplines and and think of our life cycle as more of a control system that we manage from the outside.
• 20:43
  SPEAKER_01: Maybe that's a very, very uh relevant point that you're making, Annie, because uh uh your articles uh made me reflect on uh a few of the points that you were just making.
• 21:02
  SPEAKER_01: And uh I was just going back.
• 21:04
  SPEAKER_01: Uh it's almost like uh somewhere you mentioned that uh, you know, uh Deming saying that uh you know you don't uh do quality check on a finished product, right?
• 21:15
  SPEAKER_01: So uh I thought it was a very, very telling statement that you had written in that article.
• 21:20
  SPEAKER_01: And uh then I went back and started saying, okay, how did this happen during the industrial era?
• 21:28
  SPEAKER_01: Right?
• 21:28
  SPEAKER_01: So for example, I was a tailor, I was a cobbler, uh, you know, I was a carpenter, and uh machines were not there, I was doing by hand.
• 21:39
  SPEAKER_01: Uh suddenly the machines came in.
• 21:41
  SPEAKER_01: So what happened to these people?
• 21:44
  SPEAKER_01: Okay, I think there's a lot of learning that you can pick up from uh that era of change where you s you had machines uh building uh you know your trousers, your apparels, and suddenly the tailor.
• 22:00
  SPEAKER_01: Uh skill set was gone, right?
• 22:02
  SPEAKER_01: But what it did was you basically started having apparel designers, okay.
• 22:09
  SPEAKER_01: You started having uh you know merchandisers, okay.
• 22:13
  SPEAKER_01: Uh you had a whole new category of people interested to design uh the apparel, and uh earlier they were actually designing it, building it, maybe selling it, uh servicing it, maybe the everything was being done by hand.
• 22:33
  SPEAKER_01: Suddenly you had a whole set of uh you know new roles that came in, and to me, that analogy uh in say uh say if I look back and say, okay, if I was a uh cobbler, uh what I did was it's not that uh you know shoemaking when it was being done by machines, then we had a whole category of people who are shoe designers.
• 22:57
  SPEAKER_01: So you had basketball shoes, running shoes, uh, you know, uh you had uh you know cricket shoes, so you had a whole host of new methods of uh you know wearing these shoes, and you had designers coming in looking at a need and solving a problem because the machine could anyway build it.
• 23:15
  SPEAKER_01: So the definition of the problem and the designing of that need, uh, maybe the role that software engineers have to start playing rather than actually doing the code.
• 23:27
  SPEAKER_01: Maybe that's really where probably the industry is moving, and therefore, this the shift is something that people have to be ready for.
• 23:36
  SPEAKER_01: Does that make sense to you?
• 23:37
  SPEAKER_01: Does that resonate with you?
• 23:39
  SPEAKER_00: Yes, and I I think there's a nuance to it.
• 23:42
  SPEAKER_00: There's a couple of nuances.
• 23:44
  SPEAKER_00: I think there will be um a subset of engineers who gravitate towards building that harness, right?
• 23:51
  SPEAKER_00: Like that really putting in place the tool that other engineers and and maybe non-engineers use to produce software, working software.
• 24:01
  SPEAKER_00: And there's some really, really interesting engineering work, like building the rigor into that.
• 24:08
  SPEAKER_00: And then I think that there's a whole other subset of engineers who uh may be more attracted to becoming domain engineer.
• 24:19
  SPEAKER_00: But what I mean by a domain engineer is someone who understands the domain they're working in and has an interest in it, yeah, potentially even a passion in it, and they talk to customers, they talk to the stakeholders, they directly as well, not through various other roles that you know, by the time the engineer's hearing about a problem, it's it's been translated 15 times and it's hard for the engineer to even get a sense of what the real problem is.
• 24:47
  SPEAKER_00: And then they can, using the tools that the harnesses and the agents and all of that, um they will be so much faster and and better equipped to solve those problems for customers.
• 25:01
  SPEAKER_00: You know, somebody who works, I don't know, they're processing claims for an insurance company, they are claims specialists.
• 25:09
  SPEAKER_00: Bring an engineer, invite an engineer, in like a more of that's domain-focused engineer, into your your team to observe how you work and work out how and where software might be able to improve the efficiency, the effectiveness of the work that that team does.
• 25:28
  SPEAKER_00: I also think though, that there's a subtle difference between the examples that you gave in that AI is such a this version, generative AI, is so general purpose.
• 25:44
  SPEAKER_00: You can use generative AI to write code or to write the requirements or to write the tests or to write the deployment pipeline or to learn about all of these things.
• 26:00
  SPEAKER_00: And the difference that matters there is when we introduced things like a calculator or or perhaps a specific tool to make trousers or something, that was that eroded a very um sort of surface implementation skill.
• 26:18
  SPEAKER_00: But generative AI has the potential to take some of the more core cognitive capabilities as well.
• 26:28
  SPEAKER_00: The thinking, the reasoning, the critical thinking, right, the judgment.
• 26:34
  SPEAKER_00: There are skills that we're happy to delegate to technology because they save us time and they were kind of toil.
• 26:41
  SPEAKER_00: But we can't afford to be delegating all of our critical thinking and judgment as well.
• 26:50
  SPEAKER_01: But I I I just uh think uh it will evolve because the fact is uh just imagine if I'm building a car today, there are guys who are uh product designers, right?
• 27:03
  SPEAKER_01: There are uh you know guys who are uh maybe uh internal combustion engine engineers, right?
• 27:11
  SPEAKER_01: People who are specialists in thermodynamics, okay.
• 27:14
  SPEAKER_01: Now then there is this whole set of guys who are into plastic material engineering.
• 27:20
  SPEAKER_01: Now, if you really go and roll back the car, actually, so many engineers have contributed to the final car, right?
• 27:30
  SPEAKER_01: Similarly, I think we are at a stage where uh if you look at AI, uh the way I see it is uh if you go to a shop floor, the shaping machine is there, the lathe is there.
• 27:42
  SPEAKER_01: Okay, uh all these machines are general purpose machines, right?
• 27:47
  SPEAKER_01: So the important thing is what do you make out of the product in that shop floor uh is really what I think the analogy to take.
• 27:55
  SPEAKER_01: And therefore, if you are a software engineer, the word that you use, you being a domain engineer, uh uh you can actually be a uh uh you know a claims uh specialist engineer, or you can be uh uh you know a customer service engineer, and then you basically have to use the uh the cognitive side and the process side, and you have to bring them together.
• 28:22
  SPEAKER_01: The cognitive side is what probably AI will uh you know help you enhance uh uh uh the uh the development side, which is the process, where maybe 80% uh AI will help you, but your ability to coexist in this environment is the skill that probably you need to build, and that's really where I think you've used the interesting word where you said reviews the new bottleneck.
• 28:49
  SPEAKER_01: It's not the code which is the bottleneck, it's review, it's really review which is the uh you know biggest bottleneck, and therefore, how are you going to build that skill of uh building and looking at these agents uh working at uh you know either collaboratively or or a cross purposes, and your ability to kind of look at it from a cockpit and then say, you know, how do I solve it is really the skill that you need to have, which means that you just can't be a uh you know a single lens uh software engineer that you wear.
• 29:22
  SPEAKER_01: Uh you are now going to actually look at it from the cockpit, and your cockpit may not be the enterprise cockpit, your cockpit might be the uh probably the two gauges that you're probably looking at, but that gauge you should know uh is really affecting the larger system, and therefore you talked about systems thinking.
• 29:42
  SPEAKER_01: So the engineer, the software engineer of tomorrow will become a systems engineer.
• 29:48
  SPEAKER_01: Is that the way you're thinking of uh software engineering of tomorrow?
• 29:52
  SPEAKER_00: I think so, and I am still very much at the beginnings of a journey to learn about systems engineering.
• 29:59
  SPEAKER_00: I think we have a lot to learn from them to help the next generation of software engineers move in a in a direction that is um needed, that has um skills that they can build in it, that will help us build reliable software that actually solves problems and and is fun to do.
• 30:22
  SPEAKER_00: Like if you you might become an acclaimed specialist engineer, and you will be able to contribute great value to that domain by having an understanding of how those people do that job, what that process looks like.
• 30:36
  SPEAKER_00: So we're lifting up and out of the minute detail, you know, those semicolons that used to trip us up, um, and you know, the syntax.
• 30:47
  SPEAKER_00: That we're not great as humans, that that's never been a huge strength for us, which is why you had to be incredibly smart to be able to get a job at somewhere like Google where to to pass the interview you had to do these elite code exercises and write a recursive function that uses the least amount of memory, and and people study so hard to get that type of thinking into their mind for those interviews because it's almost like passing an exam.
• 31:17
  SPEAKER_00: Um nowadays, well, AI can do that pretty well, right?
• 31:22
  SPEAKER_00: And and that's maybe not where a software engineer needs to be spending their cognitive effort.
• 31:30
  SPEAKER_00: Um, and instead it should be applied sort of up and out of that to to help deliver functioning software for teams that actually need it.
• 31:39
  SPEAKER_00: I think we need to find a way to make the reviewing code part simpler for us, um more with more assurance using other techniques.
• 31:49
  SPEAKER_00: Um, there's a whole bunch of different testing approaches, like property-based testing and differential random testing.
• 31:56
  SPEAKER_00: Perhaps we've got to broaden our thinking on the the ways to assure that the software that's generated by AI does what it's supposed to do so that we free ourselves up to do more of that higher level thinking.
• 32:08
  SPEAKER_01: And I I totally agree with you, let me tell you that because uh I just read this quote out of your blog, and I think uh it just got me into a rabbit hole.
• 32:17
  SPEAKER_01: And one quote that I read, uh I think uh uh where uh you know he'd given us links, you've given me links to go to different people.
• 32:26
  SPEAKER_01: Uh, there was one quote by Peter Drucker.
• 32:29
  SPEAKER_01: Drucker says when a worker knows more about the work than the manager, you manage by objective, not by method.
• 32:38
  SPEAKER_01: Okay, so the software engineer of tomorrow, you are not going to be saying, Do you know C?
• 32:44
  SPEAKER_01: Do you know Java?
• 32:45
  SPEAKER_01: But you are actually going to say that that's the method, right?
• 32:47
  SPEAKER_01: And suddenly your ability to look at the big picture with connected systems is really what the big change in the software engineer's mindset is really what I thought you were talking about.
• 32:59
  SPEAKER_00: Yeah, yeah, and and it is significantly different to the role that most software engineers have played through to now, which is why I think it's it's it's being felt as such a a big significant change.
• 33:16
  SPEAKER_00: And I yeah, I I don't think software engineering is dead, like you see so many bold statements out there.
• 33:24
  SPEAKER_00: I just think it looks so different that we might not even recognize it anymore.
• 33:27
  SPEAKER_00: But we we need to be be comfortable in the um uncertainty and also be comfortable in in knowing that we need to adapt.
• 33:38
  SPEAKER_00: Um, and I think we do it better when we share with one another what we're seeing and um learn from one another.
• 33:46
  SPEAKER_01: Fantastic.
• 33:47
  SPEAKER_01: Fantastic.
• 33:52
  SPEAKER_01: On that note, uh I just want to uh digress on two points that you made and not related to software engineering, but I think uh uh I'm deeply interested in that area, therefore I'm going to ask you a couple of questions.
• 34:06
  SPEAKER_01: So you said uh you were working uh in software engineering and you never felt it like work, right?
• 34:14
  SPEAKER_01: Uh all these years.
• 34:16
  SPEAKER_01: So tell me a little bit about that and uh how does one reach that state?
• 34:23
  SPEAKER_01: Because uh it's a flow state that people talk about, there are books which are written, but what made you say that?
• 34:29
  SPEAKER_01: And uh if you can unpeel it for me, saying that you know, why did you feel that?
• 34:35
  SPEAKER_01: Uh, because that's a very important state, because that then allows you to deeply engage with your work.
• 34:41
  SPEAKER_01: So uh can you talk to me about that in a in a little bit of a detail, maybe a couple of minutes?
• 34:48
  SPEAKER_00: Sure.
• 34:49
  SPEAKER_00: Um well I credit that with my my interest in solving puzzles, and I think for me, on a very personal level, uh solving well building software felt like solving puzzles just with a a different tool than a jigsaw puzzle, for example.
• 35:10
  SPEAKER_00: Uh I I remember once, um, I'll give you a solid example.
• 35:15
  SPEAKER_00: So when I was working for a company in the Netherlands, they were a uh a photo book printing company.
• 35:21
  SPEAKER_00: I didn't even know photo books were a thing.
• 35:23
  SPEAKER_00: And this is the the beautiful thing about software is that we use it in every corner of our world, right?
• 35:29
  SPEAKER_00: So if you are a software engineer, you will have such a wide variety of choices of places to work.
• 35:37
  SPEAKER_00: It doesn't have to be banking or healthcare, it could be just any vague corner of the universe.
• 35:43
  SPEAKER_00: And so photo books was where I ended up.
• 35:46
  SPEAKER_00: And um, my manager wanted uh he needed a new piece of software built to solve a particular problem.
• 35:54
  SPEAKER_00: And rather than sort of do it top down and say, I'm gonna pull out these three people and you're gonna work on this now, he he put it to the team as a bit of a like a competition.
• 36:06
  SPEAKER_00: He said, We need this thing built.
• 36:08
  SPEAKER_00: Put your hand up if you would like to lead that piece of work, if you have any ideas.
• 36:13
  SPEAKER_00: Um I give you one day to do a prototype and then sell it to me, and uh then I will choose who I think is best placed to build this.
• 36:22
  SPEAKER_00: And uh I thought I I can do that.
• 36:24
  SPEAKER_00: I got I I understood the problem well enough, and I had some thoughts on how I might build it.
• 36:29
  SPEAKER_00: And I wasn't the only one.
• 36:30
  SPEAKER_00: There were at least two others I remember who um set about trying to do the same.
• 36:36
  SPEAKER_00: And uh I built a little prototype, and well, long story short, I I won the competition and I won the right to lead this piece of work.
• 36:44
  SPEAKER_00: And it felt mine, it felt like I was like I owned it.
• 36:48
  SPEAKER_00: I owned the not the problem nor the necessarily the idea to solve it, but I owned the the way in which I thought it should be solved.
• 36:58
  SPEAKER_00: Um, and software has so many layers to it that you can think about the the overarching architecture as well as every component, how they will be designed down to the code architecture level, right?
• 37:13
  SPEAKER_00: So that it be it's easy to fix in the future or to modify in the future, it can be extended, it can be flipped inside out because that's often what we need to do with software.
• 37:23
  SPEAKER_00: So there was always a mental challenge there for me, and that's I enjoy doing that whether I am working or not working.
• 37:32
  SPEAKER_00: I do jigsaw puzzles in my spare time.
• 37:35
  SPEAKER_00: Yeah, it just feels like I was being paid good money to do what I enjoyed doing anyway, and hopefully deliver something that actually made a significant difference to the business I was working for.
• 37:50
  SPEAKER_00: And, you know, I got so much joy from solving the problem from the journey of that problem-solving process and everything I learned, you know, and at the end of it, if I get it right and I produce something that is useful, the satisfaction, the reward of knowing that that was your work that you can be proud of.
• 38:12
  SPEAKER_00: Like it's it's this beautiful loop of you know, challenge, effort, earning the reward, and then doing it all over again.
• 38:22
  SPEAKER_00: So I I just can't imagine having done anything else with my career.
• 38:26
  SPEAKER_00: I that I'm so glad that my parents bought me that Commodore 64 when I was so young because it it put me on a path.
• 38:32
  SPEAKER_00: You know, if I hadn't had that experience, I wonder if I would have ended up in the same place.
• 38:38
  SPEAKER_00: I don't know.
• 38:39
  SPEAKER_01: So, therefore, what you're saying is uh deeply understand what you like, uh or explore or discover what you like, and then start doing more of that.
• 38:50
  SPEAKER_01: Make it your work, do more of that by challenging yourself, and once you start doing that, you end up in a state where you will, of course, earn money, but you will not feel that it's work.
• 39:05
  SPEAKER_01: You have to go through this loop, is really what you're talking about.
• 39:08
  SPEAKER_01: Am I summarizing it well?
• 39:10
  SPEAKER_00: Yes, I think so.
• 39:11
  SPEAKER_00: And there's an element of earning it as well, which which AI somewhat threatens, as we were talking before, because it's just so easy to delegate all the thinking and all the doing.
• 39:21
  SPEAKER_00: Um, but if if you I was just yesterday having a conversation with someone about how, you know, I I used to do some long distance running.
• 39:30
  SPEAKER_00: And to do that, I I don't at the moment because I spent too much time in front of a computer and I'm not as fit as I was before.
• 39:36
  SPEAKER_00: But um when you put the effort in, you just you set yourself a challenge, I'm going to run a half marathon one day.
• 39:43
  SPEAKER_00: And you can't just get up tomorrow and do it with no training.
• 39:46
  SPEAKER_00: So you earn the right to be able to do that and be healthy afterwards.
• 39:52
  SPEAKER_00: And that hard work, it it feels like the the satisfaction of having gone through with it is I for some of us at least is what drives the next step.
• 40:01
  SPEAKER_00: You know, I've done I've conquered that now.
• 40:04
  SPEAKER_00: What do I conquer next?
• 40:05
  SPEAKER_00: And if you can do that on a topic that you are already interested in and want to understand at a deeper level, those two things marry up so nicely together and hopefully there's work in that area, and that then it just doesn't feel like work.
• 40:20
  SPEAKER_01: Fantastic.
• 40:21
  SPEAKER_00: And that's also like can't be a there's two sides to that, you know, there's a little bit of a double-edged sword.
• 40:27
  SPEAKER_00: If it doesn't feel like work, you're tempted to do it 24-7.
• 40:31
  SPEAKER_00: Sometimes you've got to take a break as well.
• 40:34
  SPEAKER_00: But um, if it doesn't feel like work, it's it's much better than feeling like it's a chore, right?
• 40:39
  SPEAKER_01: So which really means that I'm connecting where we started to where we will end.
• 40:44
  SPEAKER_01: Uh therefore, in software engineering, as more and more gets code gets automated, more and more code gets automated, uh the fact that you need to do a lot of side projects where you are still building your craft, uh as the machine codes, let it code.
• 41:04
  SPEAKER_01: Uh but the fact that you have to keep your skill uh and your hands uh you know agile or your mind agile, uh, because it may still do it, but the fact is you've got to build a lot of side projects, and you will do side projects only if you are interested in that particular job.
• 41:24
  SPEAKER_01: Otherwise, you will never do your uh side job.
• 41:27
  SPEAKER_01: So, therefore, the fact that you do more of those side jobs, then you build the natural capability to uh look at the supervisor supervisory engineering that you're talking about, which is supervision engineering that you were talking about.
• 41:42
  SPEAKER_01: So, which means that you're building this side project, then you know what you are supervising, therefore, you are able to understand it a lot better and therefore direct it a lot better across the systems.
• 41:54
  SPEAKER_01: That's the way probably this whole world of software engineering is going to change, and that's what software engineers need to be ready for, right?
• 42:02
  SPEAKER_00: I believe so.
• 42:03
  SPEAKER_00: Yes, you've summarized it really nicely.
• 42:05
  SPEAKER_00: Yes, and absolutely.
• 42:07
  SPEAKER_00: If if it's something you enjoy doing, it won't feel like a chore, so you're more likely to do it, you'll gain more experience doing it, you'll have that salience around just a sixth sense of it's working as it should.
• 42:22
  SPEAKER_00: It's produced good code and it works like it should.
• 42:26
  SPEAKER_00: That will happen naturally.
• 42:27
  SPEAKER_00: It if you try and force that because you want to work in this domain, it it will only last so long, and you may never reach those levels of flow that feel good, allow you to take pride enjoying your work and produce good outcomes.
• 42:44
  SPEAKER_00: And it takes time in you know to to gain that those that intuition.
• 42:50
  SPEAKER_00: Um but now the intuition we gain has to be gained through a different filter.
• 42:55
  SPEAKER_00: It's it's not by manually doing so much anymore, but it is still through experience of directing, evaluating, correcting through that supervision.
• 43:06
  SPEAKER_01: Fantastic.
• 43:07
  SPEAKER_01: Uh, on that note, Annie, thanks a lot for talking to me.
• 43:11
  SPEAKER_01: I could see the deep thought that has gone in in your search for how this field of software engineering is changing.
• 43:19
  SPEAKER_01: And uh I could pick up a lot of nuggets uh of how you need to look at it, how you need to transform.
• 43:28
  SPEAKER_01: And nothing is still cast in stone, but the fact that you've got to be ready for this change is really what I think I'm taking out of this conversation.
• 43:38
  SPEAKER_01: It's a set of beautiful, I would say, uh paintings that were there.
• 43:43
  SPEAKER_01: You know, you got to figure out what the meaning of that is, and that's really how I found this conversation.
• 43:50
  SPEAKER_01: Thanks a lot.
• 43:51
  SPEAKER_01: Thanks for your time.
• 43:53
  SPEAKER_00: Thank you for the conversation and for um allowing us to observe those paintings and and and extract some meaning together from them.
• 44:02
  SPEAKER_00: Thank you.
• 44:03
  SPEAKER_01: Thanks.