What does it mean to be a software engineer today?
I think it's a very different landscape to what it was even
two years ago. You.
Can't even hire other people unless you can justify how AI
couldn't actually help you with that extra resource, right?
But what do we do about our junior engineers?
It's going to be harder to break into the industry harder than it
was say three years ago. I think we're trading off that
short term speed increase and what we perceive to be
productivity gains, which they are, but at what cost.
That speed really is very seductive and fun, but fragility
and complexity is very expensive.
One of the main questions that I'm asking as part of my
research is how does the introduction of AI coding
assistance shift the perceived focus across various development
tasks such as like designing and writing, refactoring, testing,
debugging, reviewing? If we've just taken a technology
that can speed up one of those phases by a lot, well, where's
the next bottleneck? We'll come up with the
requirements and then the other end as well, who will do the
review and testing and all that. One might ask themselves, well,
where is that extra time going then because we're saving all
this time? Or are we just writing more code
faster? I would suggest to start
thinking of these AI tools as not just mere tools, but as team
members. I do wonder if we might head to
a place where we each have our own AI that knows us intimate.
What if it could also connect to a model that is yours?
Is your personal one that knows the way that you think?
Hello everyone, welcome back to the new episode of the
Technician podcast. Today I have with me a repeat
guest, Annie Vella. So I think the previous episode
that we did is episode 30 like 4 years ago.
It's been quite a long while. The reason I reach out to Annie
is because I saw her quite active on social media, on
LinkedIn and also on her research, right, talking about
AI assisted development or AI in general, right, generative AI in
software engineering. So today I hope we have a good
discussion to talk about, you know, Dehype about AI, maybe
some fears that some people have and try to maybe demystify and
give us some better guidance. So any welcome to the show.
Thank you, Henry. It's so good to be back after,
yeah, just over 4 years I think. And boy, has a bit changed in
the world in that time, hasn't it?
Yeah. So any, I think we know about AI
usage these days, right? Everyone is talking about it
over social media. There are new technologies even
being invented recently, right. And the term vibe coding is kind
of like very, very popular these days.
So maybe tell us a little bit more four years apart, right.
What do you see have changed, maybe in your day-to-day work
with software engineering, Or what do you see other people
doing in software engineering? Well, four years in a time when
things have changed as much. So personally I've changed roles
since the last time we spoke. So I think when we spoke last
time I was about to start a senior engineering manager role
and since then I've actually moved into a on the staff plus
engineering career track. I'm a distinguished engineer and
so my own role has changed in that time.
And so the things that I spend time doing have also changed.
But more importantly, I would say end of 2022 or November
2022, I think it was when ChatGPT was released.
I think that caught the world by surprise.
And what's been so interesting is to see how quickly it's been
adopted. I was watching a video just
yesterday, Sam Altman said that there's 500 million active users
using ChatGPT. That's just a huge number that
it's hard to wrap your head around, right?
But then starting to see where it's being applied.
Not just ChatGPT, but the underlying technology, LLMS,
obviously very, very useful in software engineering.
And hence, as you said, you know, vibe coding, all of these
sorts of terms are starting to come out.
And I was lucky enough to be in a position where I could
entertain the idea of going back to university to do the masters
that I always told myself I would do when I graduated over
20 years ago. I thought, oh, I'll go back to
university one day and do that further study, but I had to find
the thing that was going to pull me in and, you know, encourage
me to spend my free time thinking about it.
So yeah, early 2024, I decided to do a masters of Engineering,
focusing on the impact of AI on software engineering because, I
mean, it just feels like the most natural topic for me to
focus on. I love software engineering so
much. I've done it since I was such a
young. I think we covered this probably
when we spoke last time. But you know, since the age of
6, I have been fascinated at what you can accomplish by
instructing a computer to do something.
But there's always been limitations, right?
It can't think for itself. You have to be so specific in
your instructions. But this technology starts to
allow us to be a little more fuzzy with our instructions that
non determinism that we didn't really have before or was very
hard to achieve. And so, yeah, how does that
impact the way that we write software, the type of software
that we build, but also how we build software?
And that's what I focused my part time masters on.
So I'm about halfway through. And that's why you will have
seen that I'm one of the reasons I'm so active on social media
now about this is because I find it fascinating.
I think a lot of people do, but particularly the impact on
software engineering and the software engineer themselves.
You know, what does it mean to be a software engineer today?
I think it's a very different landscape to what it was even
two years ago or four years ago when we spoke.
The sorts of skills that you need to build up, you know,
that's all changing. So, OK, I wish I had a crystal
ball. But as I do not, the best I can
do is try and research what's happening today so that we might
project and predict what happens tomorrow, and so we can prepare
ourselves for a brave new world. Yeah, So I think it's really
interesting the, you know, you just saw a video, you know, the
active users using ChatGPT, right?
I guess these days it's not just ChatGPT.
There are even more, right? You have like perplexity Gemini,
you know Claude and I don't know God, what, you know, like other
AI software. So I think also interestingly,
just a few days ago as well, there was a announcement by
Shopify CEO, right, Toby Lucas saying that everyone now is
expected to use AI, the term reflexive AI.
I'm not sure what that means, but basically saying that you
can't even hire other people unless and justify how AI
couldn't actually help you with that extra resource, right?
So I think that's a very, very new thing in my opinion, right?
So asking people to try to use AI as much as possible.
So I think in your paper you mentioned about this future of
AI driven software engineering or I think let's just focus on
this topic for today. What do you see changing?
You know, software development is still kind of like, you know,
a large kind of a work body, right?
So that there's so many activities, people try to use it
so much, you know, building applications, building programs
and things like that. But what do you see actually
changing in terms of software engineering in general?
Yeah. So that paper was an attempt to
look into the future and see what of all of the different
types of activities that are involved in the software
development life cycle, which of those would be impacted and in
what ways. My own research for my masters
is focusing more on like the things that software engineers
do themselves today. And this is something that I've
been reflecting on so much as a part of all of this.
You know, when I went to university over 20 years ago, I
was taught the full software development life cycle.
You know, I, of course we learnt how to code, but we also learnt
how to analyse the requirements, you know, and discuss with the
customer what the problem they were trying to solve and
encourage them to not give us the solution, but instead just
really focus on the problem and let us as of the team who are
going to solve all their problems, come up with the right
solutions for them. You know, right through to
modelling use cases, UML, you know, back then when we used to
do a lot more of that kind of stuff upfront on the design of
the software and then the build and thinking through all the
test scenarios and then obviously the deployment and the
maintenance of it. And what I've noticed throughout
the years is that probably due to the fact that there's such a
massive demand for software engineers, but not enough
supply, we have created specializations, you know, and,
and try to kind of reduce or narrow down what a software
engineer should focus on to the things that we perceive only
they can do with the skills that they have.
And that is the writing of the code.
What I find really fascinating about this shift is if you you
read what people like the CEO of GitHub have to say, you know,
they proudly announced that now with these tools, software
engineers will be able to do a lot more of that higher level
thinking, critical thinking, you know, all the other tasks that
were always meant to be a part of software engineering.
But the truth of the matter is that many software engineers
have specialized on the coding aspect of it.
I used to work many years ago when I was in the Netherlands.
I worked with a team who were based in the UK and I remember
one of their engineers there was just really, really smart, but
focused all of his energy and his skill building and becoming
like the best React developer. He knew React inside out.
That was his area of interest and his domain, you know, and we
had frequent discussions because I was trying to encourage him to
think more about the product that he was building as well.
Like what is the problem you're trying to solve with this
technology that you've become very good at?
And he just didn't have much interest in understanding the
domain we were working in. You know, he felt his area of
expertise should be the technology and others could
think about the product. Well, I fear for people who have
gone down that path because I think that the tools that we
have today and, and of course, it's only going to get better.
They're very good at writing the code.
They can generate code way faster than any of us can hope
to ever type. So that shifts things, right?
But where does it shift it to? So one of the main questions
that I'm asking as part of my research is how does the
introduction of AI coding assistance shift the perceived
focus across various development tasks such as like designing and
writing, refactoring, testing, debugging, reviewing.
You know, like I have a hypothesis that developers may
spend less time writing code and perhaps more time reviewing.
Well, so far the data is showing that yes, developers feel that
they will spend or that they already are spending less time
writing code, this time refactoring code as well, and
this time testing because they can generate tests.
That all makes sense. But what we're not seeing is
really like an equal and opposite increase in the
reviewing. The time spent reviewing.
There is a slight increase there, but not equivalent,
right? So one might ask themselves,
well, where is that extra time going then because you know,
we're saving all this time or are we just writing more code
faster? And what does that mean into the
future, right? What are the 2nd order or
lagging indicators that we should start looking for?
Well, thankfully we don't need to look too far because Dora and
the Get Clear report, I came across that one a couple of
weeks ago and you know, they're analyzing the impacts of this
technological shift and we are already seeing some of those
second order or lagging indicators.
And it's not really a great picture to be honest, Henry.
It's like I think we're trading off that short term speed
increase and what we perceive to be productivity gains, which
they are, but at what cost, you know, and I think that's going
to become quite interesting. So software developers right
now, they're generating code faster.
They're also feeling like some of the code that gets generated
isn't great. You know, sometimes it
hallucinates for all the tools that are available, some are
better than others, but you still need to be vigilant and
manually adjust and carefully verify that the code that it's
generated is doing what you hope it is, which is where vibe
coding comes in and tells you actually, maybe you don't need
to worry too much about that. So that's another topic.
And another thing that's quite interesting that I'm seeing in
my research is software engineers are trading the more
traditional sort of search tools for AI coding assistance.
So previously you would have gone to Stack Overflow, you
would have gone to Google, maybe even opened up the documentation
for a particular library or framework that you're working
with. That actually seems to be
shifting as well. So we can already see a decline
in the use of Stack Overflow. You know, it had its day and it
seems like now it's just easier to stay in the IDE.
Why would you pop out of it into a browser if you can just ask
the AI coding assistant to help you with that?
So are we moving towards being more like orchestrators of AI
coding assistants, Like just being able to describe what it
is that you want or getting really good at prompting?
Is prompt engineering becoming a new core competency, and does it
potentially replace the ability to recall all of the syntax that
we used to have to learn? So these are the big questions
I'm asking, and I'm, yeah, still super fascinated about.
It's an evolving picture, absolutely.
Yeah. So as you were mentioning all
those, I kind of like reflect back to what my recent
experience as well. So I could definitely relate
with some of these things. These are changing especially
for me, right. So uniquely enough, right, I was
also into management now back kind of like semi management,
semi hands on. So I think I could see that
so-called the dichotomy, you know, being a hands on developer
and also as a manager, right? So trying to think of how we can
use AI more effectively and being more productive and also
not forgetting about the second level or maybe third level order
of thinking, right? So I think 1 aspect that you
mentioned very interesting is about the role of software
engineering. You know, traditionally we were
trained with so many different things like requirements and
things like that. But over the time as maybe like
what you mentioned, like so many solver developers specializing
into different roles, some even specializing in different
technologies. Maybe it's a React, maybe it's a
cloud thing, maybe it's DevOps, SRE, whatever that is, right?
And now it seems like these kind of specialization is blurring a
little bit, I would say. So for example, if I'm not a if
I'm not a good front end engineer, but I do understand a
little bit about front end technology, right?
I could now come up with some kind of maybe decent good
looking UI and also complimenting myself with other
skills like back end engineer or maybe cloud.
I can build much better application with more coverage
in terms of, you know, technology thing, right?
So do you, do you think these days software engineers have to
think of becoming a generalist more and more, especially now
that AI can help actually to maybe provide shortcuts, you
know, finding the answers quickly, but also upscaling
themselves in those skills? So what do you think about this?
Yes, I very much agree with that.
And you know, I think as time goes on, different phases will
come and go. You know, maybe we had to go
through a phase where there were so many new technologies coming
up. I lost count of the number of
front end frameworks that, you know, went through the hype
phase. You know, I think I stopped
playing around with and I say playing because I was never
officially a front end developer, but as a sort of full
stack developer, I did have to work in front ends and I was
never very good at it. But I think the last time I did
anything decent in front end was angular days.
And you imagine how far, like, how long ago that feels now.
But, yeah, we've gone through a phase where we've introduced so
many new frameworks and technologies, cloud and mobile
itself, you know, And people chose to specialize because
there was a demand for it. But now, as you say, like, these
tools do in many ways democratize the access to
becoming a developer, somebody who can contribute to
development. In fact, I read something by
Andre Carpathy. I hope I'm saying his name
right. Apparently Twitter has articles
on it now. I, I didn't and it's not called
Twitter. It takes, but he wrote an X
article on the diffusion of this technology, which previously
like big technological changes like this might have started in
government or big companies 1st and then trickled down to the
average individual at home. You know, but this technology
seems to have been released out to the general public 1st.
And although I'm sure that there are, you know, more advanced
models that the companies are using internally and maybe even
the government, the perception is that it's out in the public
much earlier than it would normally have been with other
technologies. And that means that, you know,
the general public, you and I and everybody else can use these
technologies to sort of supercharge themselves.
So as you say, like I too have found myself, I've had to write
a bunch of R scripts to analyse the data that I've collected as
part of my research. And I'm not an art developer,
but with the help of, I'm using Windsurf connecting to clawed
Sonnet 3.5, it's a huge help. It just shortcuts the amount of
time I would have had to spend. And now I feel like I could
probably write something in any language with just a little bit
of help. What I love about that, Henry,
is, you know, last time we spoke, I was right in the middle
of trying to be the best engineering manager and
technical leader that I could be.
I really focused so much of my energy on how do I give other
engineers enough confidence to try things and fail sometimes,
but safely, you know, because you learn through your failures
and your mistakes, probably better lessons than you'll ever
learn any other way. How do you create an environment
in which people lean into that and then are able to discover
for themselves some new path, some new way of some creative
way of solving a problem and be able to feel really proud about
that? And I think like we spend so
much time working, so much of our lives are spent at work,
that if you can take joy in your work and be proud of the work
that you do, it makes a time fly by.
And that's, I think part of my passion for software engineering
is I've never really seen it as work.
It's always been an enjoyable thing for me.
So I wonder if these tools can help give perhaps the more
introverted, quieter members of our teams like a quiet assistant
just sitting there privately on their computer.
You know, now, those who might previously have not had the
courage to put their hand up and admit to the rest of their team
that they don't know how to do something, that they need a bit
of help. Because, you know, it's can be
hard to admit that, you know, not everybody has the courage to
do that. And some, you know, over time
might find that courage, but some might never.
But this tool, if you can just chat with it about some idea
that you have before you get to the point of, OK, I think I
really need to ask for help, You might be able to solve a lot
more of your own insecurities about trying some technical
solution for something. And I love the idea of that.
I think that can really help allow developers.
Yeah, more freedom in that sense.
And to that end, as you said, like now previously you thought
of yourself as not a very good front end developer, so you
probably never. Going to put your hand up to do
that piece of work or for that job.
Well, now you might actually really consider actually going
for that. And that's got to be a good
thing, you know, but beneath it, it still needs to be backed by a
deeper understanding of what it is that you're doing because you
do need to think about how long is this going to last?
If it's just a prototype, then go for it.
You know, if it's just going to be thrown away and just proving
something. These tools are amazing and I
see that shine through and some of the open-ended answers that I
got in my research. But if it's a production code
that needs to be maintained over time, you still need to probably
be a little careful about the complexity of the code, the
duplication that you're that you might be stumbling into.
But that's maybe where we see introduction of new tools.
Well, you know, layering of agents that can help you
identify those mistakes as well. Gosh, Pandora's box has been
opened. And, you know, who knows where
this evolution will take us, But it's very interesting.
Yeah, myself, I'm afraid I couldn't keep up with so many
different changes, new technologies, new inventions,
new tools being popped up. And sometimes it's not just one
aspect of software engineering, it could be other things like
testing, generating UI, generating app, things like
bold, lovable and all that, right?
So I think definitely this is something that everyone at least
needs to follow a little bit, I guess.
Otherwise you will be fallen behind like by a lot, right?
Especially from people who leverage these tools everyday.
I think you make a great points about, you know, people who are
maybe a little bit more introverted or shy or maybe some
imposter syndrome as well, right?
They are scared, you know, asking questions with others.
So now I think everyone has some kind of assistant, although you
still need to Fact Check, you still need to try to understand
why it suggests certain things that way, right?
So I think at least now we have some partners that we can just
ask, you know, the partners that never get tired and always seem
to be resourceful, always trying to help us the best they can.
Yeah. You mentioned the time spent for
engineers now has becoming less about writing code because, you
know, writing code is not the bottleneck anymore that everyone
seems to be able to churn out maybe features fast, right?
But all other aspects of software development maybe gets
impacted, right? So to speak, right.
So now if let's say you can write a lot of more features,
that means who will come up with the requirements and then the
other end as well, who will do the review and testing and all
that. So do you see some kind of
problems that could happen because like what you mentioned
the Dora research base saying like there's an increased
productivity there is, right? Definitely.
But the impact of software delivery performance is actually
going down. And maybe the Get Clear report
that you mentioned as well, mentioning that there are a lot
of churns in terms of code they are being produced from, meaning
that you write this code today and you keep changing them over
time, right? And the churn is pretty high.
So what do you see the impact now if let's say code writing is
not the bottleneck anymore? What would other aspects that we
need to be concerned about? That's a really interesting
question. And honestly I think that's if I
could work that out, my research would be complete.
I think you're right to mention like software development life
cycle is a system, right? Over the years we have
identified different phases things work from sort of left to
right. And then we decided maybe we
should have iterations in there because if Waterfall didn't work
out super well for everyone, and if we've just taken a technology
that can speed up one of those phases by a lot, well, where's
the next bottleneck? Like now you don't have enough
requirements coming in or there's not enough UX work
happening up front. And so the developers are sort
of waiting around for where's my next piece of work coming from
because I've done my bit. Now you, it's like every team's
dream, I suppose. You know, like, oh wow, how
developers have nothing to do. It's been a long time since I've
heard anyone say that. And on the other end of the
scale, so you know, we're churning out code much faster.
Who's reviewing it all because if you've played around with
these tools from a code generation perspective, you will
be aware of how much faster it can generate large pull
requests. And I think the Dora report
talks about that, right as they are wondering, they hypothesize
whether some of that delivery stability decrease that they've
started to see might be in part at least related to much larger
PRS that are being generated. And I've felt that myself, to be
honest. That's actually I saw the other
day. Patrick, the plan, the godfather
or grandfather, wife of dev OPS, you know, fabulous man.
He commented on LinkedIn that I think he said it was windsurf or
cursor have introduced this new feature where it makes a sound
when it's completed doing the task that you've given to it.
And I thought, oh, here we go. It's an important feature
because we are already getting used to asking it to do so much
more for us that it can actually take a bit of time.
And I've found myself also sort of waiting there patiently
watching it, thinking, hurry up already, why are you taking so
long? Maybe I need to spin up another
instance of windsurf to get it to do more in parallel.
It's taking too long, so then you get distracted and you go
and do something else. You start reading e-mail or
answering a message. And so you don't know when to
come back unless it makes a little sound.
But that just goes to show that we're moving into this phase now
where it's just generating so much code.
Are you really going to go and have a look at all of the code
it's generated? Like we say we should.
We say it's important, but it will just over time.
Vigilance. We're going to.
Yeah, vigilance decrement is a problem because, well, honestly,
there's vigilance fatigue. You know that when you're
writing it, you're going at the pace of like you're thinking
about it, you're writing the code, you're looking at what
you've written, you're maybe writing a unit test and testing
that what you've written works the way it should.
And there's a sort of a natural pace to it.
But now, if you can generate so much more code, so much quicker,
when do you go and check or that you know what it's done?
And how does the person who now needs to review your code deal
with a much, much larger PR? So I think there will probably
be some new tooling that comes out that helps us with that, you
know, that helps identify what maybe what the areas to focus
our review on might be. And I think this is possibly
part of the brave new world that we're stepping into.
We don't yet know what tooling, what extra phases within the
software development life cycle may need to be introduced or
augmented, you know, to deal with the removal of a bottleneck
that has existed for, I want to say about 50 years, you know, 50
odd years that the software industry has been trying to find
ways to reduce the time it takes to build software by, you know,
little things like the libraries and frameworks that we use today
that abstract away as much of the heavy lifting or the
thinking that we previously would have had to have done.
Like we can't even think about what it must have been like to
do all of this on punch cards, you know, or, or even writing
assembly code directly, how much slower that must have been,
right? So we take for granted what we
have today. And even today we feel like it
could be faster, it could be faster.
So we have a need for speed, right?
Like this speed is exciting, it's fun, but then we need to,
you know, move on to the next. OK, So if that's true now, then
what's the next thing to think about?
So I reckon developers will end up spending more time thinking
about how you verify that the work that you've, the code
that's been written does what it's supposed to do.
And I'm not talking about unit tests or even test automation,
they're a part of it. But we're starting to see, I
only learnt last week, this concept of product managers
building what they call evals. So apparently in 2025, evals are
the new thing that product managers are starting to think
about to evaluate whether the product that they're building
that has AI embedded in it does what it's supposed to do safely
and, and all of that. And it's not quite the same as
the test automation that we've as coders we've traditionally
built and relied on, but it's broader than that.
And it's super interesting. Like already like that didn't
exist two years ago, you know, So I think new things like that
will come up and we'll have to find innovative ways to automate
that and stitch it into our pipelines and anything and
everything around that. Yet even just figuring out when
to trust an AI coding assistant, that in itself, that probably
requires a huge amount of research.
How do you know? Trust is a big topic and it's
not one that we typically talk about in software engineering.
I would say, I'm sure it might come up, but almost like as a
side effect of something else. But trust is kind of a very
heavy psychological thing. You know, you have the person
that trusts or, and the trustee, I guess.
So you have to try and work out, you know, when I say I trust a
tool, what's my belief in its ability, you know, and versus
the other side of the equation. So, so maybe we can find ways to
systematize that trust so that it results in a better
calibrated trust so that we don't end up almost washing
ethics, you know, like ethic washing, where we think we've
trusted, it's trustworthy. But are we just overlooking
something deeper? There will be a whole bunch of
new jobs that arise out of all of this, like specialties, I
suppose. But for now, I think
generalizing your knowledge is to, to get through this near
term phase. I would say that becoming,
moving back towards being a bit more of a generalist, certainly
less specialising on the libraries or the syntax, because
the bots can do that rather well, is a good idea.
And in future we might find new specialist roles that crop up.
The world's our oyster. I think we're creating these
paths, so I think that's an important aspect to consider.
Yeah. So I think the need for speed is
in everyone's mind these days, right?
So they think with AI we can be more productive, we can work on
more, we can deliver faster. And I think the temptation is
there. So when I say like, I'm becoming
much more hands on, right? I become a developer, right?
So supercharged with disability, we would like to think that we
want to be faster as well. Like, you know, churning out
code sometimes even if the requirements is a little bit
vague, we can speed up just by taking our assumptions and
deliver things, at least get something done, right?
So I think the temptation is there.
And you mentioned about vigilance, right?
So every time when you write a code and you ask AI so many
times, right, I would assume that everyone will start to
build some kind of trust simply because it becomes like a close
friend of yours, right? And I remember back then when we
Googled as well, right? Anything that is top ranked,
we'll just assume that it's true, right?
It's more accurate. So I think these days especially
people will just easily trust AI and especially with coding, it
becomes much more. The feedback loop is very short,
right? When you ask question, it gives
back and then you continue and build features on top of that.
So I think you remind us a very good point about vigilance and
trust, right? So try not to assume everything
that AI gives us is actually true.
Which comes to the next discussion that I want to bring
up. It's about over reliance on AII
can actually feel it myself as well.
So every time I need to do something, be big or small, I
would need to ask AI, you know, some as a like giving me a fresh
pair of perspectives or maybe even criticize, summarise and
all those things. So what do you think is the
danger of this over reliance on AI?
Well, that's a great question. It's one of the things I think
about a lot because like you, I also feel it in myself like it.
It's too appealing. You know, you've got this tool
that is never tired. It's always available as long as
you, you know, pay for it or the free one or and don't exhaust
your obtaining limits. But it's just so helpful to have
this sort of second pair of eyes there that's there as your
helper. But I'm a firm believer that we
learn through experience, hands on experience.
You know, you can read, watch all the YouTube videos about
something that you can find. But at the end of the day, if
you don't have a variety of experiences, and I think we
spoke about this four years ago, I think I talked about the
Dreyfus model and how you go through from novice to expert
over 10 years apparently of skills acquisition.
And that skills acquisition is built through experience through
10 years of experiencing a variety of at the different
angles of the same skill, right? You can't just practice the
same, the same song on a guitar and become a, you know, the best
guitar player in on the world. So from that perspective, if you
are outsourcing or delegating a lot of what you do to this bot,
then you yourself are not experiencing it.
You're not experiencing the friction, the frustration, the
pain, the resolution that you come up with through your own
critical thinking. You're kind of offloading that
to something else. And what does that mean for our
ability to gain those skills? Now, I'm really not sure because
research will tell you that deliberate practice is indeed
the best way to learn something. Yes, simply reviewing something
else is you'll get a feel for it, but you're not going to have
that confidence to go and do it yourself.
So I am quite sure that if we keep going down the path that
we're going, which I can't see us not, and we all become super
reliant on this, these new tools that over time we'll all become
quite rusty at the thing that we used to do by hand.
And we'll become very dependent on these tools.
And to some degree it's a bit like the calculator, you know,
like how many of us even, to sum up a pretty simple, you know,
additional subtraction, we pull out the calculator just in case,
you know, or GPS, right? It's quite funny, but my husband
is not good with directions and fully relies on GPS.
Without GPS, he's just not confident about getting where he
needs to go. There's plenty of other skills,
but directions and following them, you know, has to be the
GPS. And that's something that
previously you would have figured out himself, you know,
and he would have learnt the way to a place and then never
forgotten it. But now he never needs to learn
it because the GPS will take him there every time until his phone
runs out of battery and then he just can't get there.
It's OK, I'm not going there today because I can't.
You solve the right. In that case, you would solve
the problem of putting giving your battery a bit more juice so
that you can then use GPS to then get to the place that
you're going to, right? So I wonder if at some point
we're all going to become so dependent on these tools, not
just for coding, but for a lot of aspects of our lives that
we're going to have this like virtual assistant in our back
pocket that is just always on and ready to help us.
And I do wonder if we might head to a place where we each have
our own AI that knows us intimately, you know, and that
we can kind of bring to work almost, you know, so we're
already seeing it to some degree with the GitHub copilot.
Like it's allows you to connect to a number of different models,
but what if it could also connect to a model that is
yours, is your personal one that knows the way that you think,
your interests, you know, the way that you tend to think about
things and is more tuned to you. I suspect Open AI and Sam
Altman, they're going in that direction from what I heard in
the video that I watched yesterday.
Like he really sees a world in which everyone has their own
personalized ChatGPT in terms of raw skills, maybe the skill that
we'll learn really. And actually that's a good point
because there's the World Economic Forum produced a report
on the future of jobs. And in that it's like a 290 page
PDF. So without getting an AI to
summarize it for me, I don't know if we're actually sit down
and read the whole thing into it.
I don't have enough time. But there's some really nice
visualizations and one in particular, they show the skills
that are becoming more important, that are already
important and they project will become more important are things
like resilience, agility, flexibility, you know, basically
embracing change. These not skills that we really
learn as a subject at school or at university, you know, they're
kind of just life skills that you build up as you mature.
So how, how do we teach people these things earlier on in their
lives? How do we kind of leapfrog
experience and all of that that life gives you naturally and
sort of try and instill that type of thinking in the next
generation? There's some really big problems
to solve, you know, to fully understand how we can leverage
these tools without giving away everything that, you know, as
humans, we've been used to doing ourselves, which is what makes
this very exciting and scary at the same time.
Yeah. So I think, yeah, open AI is
releasing this thing called memories probably right in maybe
in your ChatGPT. And also the trend seems to be
like the larger and the larger context that AI model is able to
use, right? Yeah, I think maybe one day,
like what you said, we can have a personal clone of us maybe
that can think of feel just like us feel is probably a bit too
far. But I guess the thinking, you
know, the kind of rationale, the kind of styles that we use in
terms of our output, right? Bit writing code, it's something
that AI can learn as well. So definitely it's something
maybe exciting but also scary at the same time.
And you mentioned that we human would love to learn by doing,
you know, like the experiential aspect, right.
And I think also software engineering is like a
craftsmanship thing, right? You cannot just, you know, learn
software by reading book type hello world and you know, you
become a software engineer. So there's so many different
aspects like design, you know, maybe non functional
requirements, maybe be it the deployment network, things like
that. So in your blocks, actually you
mentioned about this trend of software engineering or software
engineer now has this kind of identity crisis this day, right?
Like what you mentioned, right? So many things now is available
to us. Maybe our roles have become much
more, I would say changing a lot, like demanding.
At the same time, everyone is scared of their job because the
news always say, OK, we can reduce the number of of
engineers. Junior engineers will not be
needed anymore. So tell us about this identity
crisis. I'm sure everyone is feeling it.
I'm feeling it myself as well. What is your take about this
identity crisis? Well, it's funny you should
mention that particular blog post.
It's the the last one that I published and it's by far the
most popular blog post I have ever, ever written or even could
have conceivably imagined writing.
Just so you know, to be completely transparent, I've had
a blog in the past which went nowhere.
I was just yelling into the wind.
Nobody cared. And I started off a blog again a
couple of years ago, maybe a year and a half ago, figured, Oh
well, at least it'll get me writing.
You know, I have a lot of thoughts about things and I've
aside from. Filling my poor husband's ears
with all of my thoughts. I thought maybe I can just pour
it into my writing and put it in.
But for the most part, my blog doesn't get all that much
traffic. But this particular blog post
I've had, I think at the last count, 43,000 views of it in
less than a month. And yeah, I couldn't have
imagined such a response. And also people reaching out to
me about it as well. They're wanting to either thank
me for writing it because it resonated for them or, you know,
sharing it with their own, their own networks because it meant
something to them. And other people are commenting
on it. So it's clearly hit a nerve,
which is quite interesting. But what does that mean?
See, I wrote that from, it was a very heartfelt blog post from my
perspective because like I said, I started coding when, well,
started coding. I started playing with code when
I was six years old, and it was BASIC at the time, right?
But the feeling that I got when I saw my work turn into
something on the computer was probably, you know, it was
certainly at that age, the best feeling I'd ever had, you know,
to see this. It was a smiling bounce a :)
that bounced around the screen, a Sprite.
And it was just one of the examples in the BASIC manual
that came with the Commodore 64. And ever since then, you know,
I've really held onto that. The craft itself, the knowledge
that you've written some words that have turned into this cool
thing. It's like it's more than just
solving a puzzle, right? And there's a beauty behind it.
And I think a lot of software engineers feel that way about
their code. There's a reason that things
like lead code websites exist because we like to solve
existing problems in new and imaginative ways using a
slightly different technique that is that much faster, more
efficient or more memory efficient.
Or, you know, and we like to you know, some of us might even, we
certainly feel some a level of pride.
We might boast about our, you know, being top of the
leaderboard on leet code. I wish like I've never been good
enough to make it anywhere near that.
But, you know, a lot of software engineers tie their at least
their professional identity into their work and into the quality
of the code that they're producing.
And so if that is now kind of not the point because these
tools can generate the code for you.
So really the point becomes more about solving the customer's
problem. But as we spoke about earlier,
over the last 10-15 years, you know, we've even had to
introduce new titles like product engineer to refer to a
software engineer who actually cares about the whole problem
that's being solved, the product that's being built and the
customer at the end of the value chain that, you know, actually
makes use of the solution that you're building.
Because somehow we've lost the sight of perhaps why we were
building that code. Because it just the act of
building the coding and using different libraries and
frameworks and new and interesting ways became, you
know, so interesting for so many people.
So in that regard, how do we take that passion and apply it a
little bit more broadly? Some people might still be able
to spend their energy and their passion building things at the
code level, but maybe even the type of things they build might
change, you know? So maybe if that's the area that
really brings you the most joy, then maybe start looking at
things like Agent Development Kit and these new frameworks
that are coming up that allow you to build solutions that have
AI embedded in them. You know, so there's, we're
still forging new paths around that like MCP great.
But you know, already we're finding some new vulnerabilities
that might creep in. So, you know, get good at
building the tools that protect us from things like that.
There's going to have to be some sort of AI version of SRE, you
know, so when you have AI embedded in your systems, then
how do you do observability and monitoring and resilience and
all of that? So, you know, there will be
things that are maybe closer to the what we would consider
coding today in future for these new solutions we might build.
But for anybody who was already at a point in their career where
they were thinking maybe it's time to consider a management
role because you know, I don't find coding the hard part
anymore. You know, maybe their start
thinking about how best to leverage these tools, how to
manage that calibrated trust and automate some of that eval
verification. How do you layer the kind of a
distributed cognitive support where you end up with layers of
AI agents that check each other's homework?
You know, and I think we see that already in some tools and
that's likely, and Sam Altman said this in his talk that I
listened to yesterday as well. Like he's, we can see that the
current version of LLM's have already revolutionize software
engineering in particular and starting to revolutionize many
other things, but software engineering for sure.
The next thing he's very interested in is agentic AI.
And I completely agree. You know, so LLMS are kind of
like 1 component. That's fine and we're all using
them in our own different ways. But the power will come when you
create a system that is made-up of many components, some of
which might be LLMS and then potentially controlled by an
orchestrator that is an LLM itself.
And that's where you get that kind of extreme non determinism
because you just give the system a task and it figures out for
itself which agent it's going to call, which tool it's going to
use. It may just not go down the path
you expected at all. So those will be very
interesting systems to create, to test, to maintain, to reason
about, you know, so there will be work in that area.
But so that's, yeah, becoming slightly more generalist,
becomes really good at using these tools, building these
tools and also managing these tools, wrangling these tools.
Like how do you fix the system when it stops working?
How do you improve it? These will become some new
interesting jobs in the future. But what do we do about our
junior engineers like the me of, you know, 20-30 years ago who
wanted to be a software engineer?
That's a tough one. It's going to be hard, I think,
for some to break into the industry harder than it was,
say, three years ago. Yeah.
So I think everyone is feeling this kind of identity crisis in
their role, right? Funny enough, probably it hits a
lot of nurse simply because we are feeling it, especially for
people who are using it. But for those people who are not
using it, maybe they don't know yet, but I think it's very, very
concerning if they don't start picking up, you know, at least
understanding what these two is capable of, right.
And I think you mentioned about, you know, juniors, I think the
other day I went into like a meet up, you know, small meet up
within, you know, my area, some managers, some leaders even
saying that, oh, I've tried vibe coding on certain aspect and it
seemed to be doing it's job. And it's cheap.
You just spend a few, you know, maybe 100 of bucks a month just
to use these tools. And compared to hiring a junior,
maybe a fresh grad who just graduated, the economy seems
like very, very, you know, lopsided, right?
So it seems like leaders probably will start to think
more, OK, how can we leverage AI more?
Just like what I mentioned about a Shopify experience, right?
So I think for juniors out there, maybe looking back at
you, you know, maybe 30 years back, what would you say to
them? Is software engineering still a
good career for them? Because it just to breakthrough
and get a first job probably is a little bit tough and
especially now in the very difficult situations globally,
you know, with all this happening in the US and some
parts of the world. So is there anything that you
would want to say maybe to the younger junior engineers of US?
I reckon if it's a path that you, you know, I would encourage
anyone to follow their dreams. Life is there to be lived.
Don't choose a career that you don't think you're going to
enjoy because you're going to spend a lot of your life doing
it. So make sure that whatever it is
that you pick, you know that it's something that you enjoy
doing. And if software engineering is
the path that you had your mind set on, and by all means follow
your heart, but understand that, say, talking to somebody who is
five years into their career, like you won't be able to follow
in their same footsteps. I think it's just going to be
different. So I would encourage them to
simultaneously try and educate themselves on all of the
fundamentals. You know, I'm pretty sure that
universities are still teaching all of that, the basics around
SOLID principles and yeah, like naming conventions and
algorithms and sorting algorithms and all of that.
Familiarize yourself with that, but then get really good at
using these tools to generate code that reflects that
foundational learning. Because I think if you showed up
to a job interview and you said, sure, I'm a junior, I, you know,
I haven't had much experience or really any at writing code, but
I am a master at using all of these other tools, cursor and
lovable, and this tool's good for that.
And then I port it over here and then I open it here.
And then I, you know, I look at it through this and I know it's
important to verify because these are the sorts of mistakes
it tends to make. And, you know, with all of that
knowledge, probably find yourself being quite in demand
actually. And, you know, maybe they're in
a perfect position to really adopt these new technologies at
a time that they're coming in, you know, those further on in
their career. I have a feeling that in my
research, what I'm seeing is people who are well into their
career, they might not have been writing that much code anymore
anyway. So to them, it's kind of like,
oh, yeah, it's nice. But, you know, I might just use
it to play around with a bit. So they almost feel like it's
not that big a deal. But the people kind of part way
through their career, like Mid Korea, I think they're
struggling with it, right? Because they're sort of, OK, So
do I now need to become really good at using this thing?
Like what I've known to be true over the last 10 years is now
changing? That's probably harder than
somebody who's entering the market at this point where, you
know, where the tools are already.
They've landed. They're here to stay.
They're only going to get better.
And the types of systems we're building are changing, how we
build them are changing. So it's done settling.
But they, you know, juniors probably have a unique
opportunity to help create the roles that they want, but
they're probably going to need to have a lot of imagination.
You know, I think that the moment, if you can imagine it,
you can create it. So imagination becomes a really
important skill. But again, we probably don't
teach it at school all that much.
I don't know, I, I never felt like I had much imagination, but
these tools help you be a little bit more, you know, imaginative
if you're struggling in that domain.
But yeah, imagination, creativity, you know, the
confidence to try it, use a tool to help you have the confidence
to, you know, it's very circular in a way like that.
So I wouldn't say all hope is lost for junior engineers, just
that the type of work they're going to be doing will be
different. So they probably won't have as
much guidance as perhaps the last 10-15 years worth of new
engineers have had. But yeah, as leaders, we need to
be able to systematize what that looks like as well, like
potentially change our career ladders and the sorts of skills
we expect people to build up and how we measure their
performance. You know, maybe it becomes a
measurement of how well are you using these tools, which is
quite different to how well do you understand the SOLID
principles, you know? Yeah, we all have to adjust.
Yeah, very interesting that you mentioned about, you know, the
juniors now have the time to actually learn these tools, you
know, from the get go, right. So I was having another
conversation, another episode as well.
We have a term about it like AI native, you know, AI native
developers just like, you know, social media aspect, right?
The youngsters these days are much more savvy than maybe I
would say me, you know, using social media.
They have even different interaction patterns and maybe
the way to leverage social media.
So some of us maybe it's generational thing, right?
Like we were not trained using that and now we have to adapt in
the middle of what we used to believe.
And now adopting these new techniques, these new tools,
they seem a little bit icky for some of us there because, like,
what do you mean? I used to do this.
Now I have to change, you know, all my habits, all my techniques
and all that. Yeah.
So I think juniors have this opportunity.
I would say that they can learn this tool natively, you know,
like the first thing that they can leverage on in their job.
So you mentioned about the aspects of management as well,
right. And management maybe needs to
tweak their, I don't know, performance appraisal, maybe
hiring, maybe giving tasks to, you know, their team.
What do you see will change a lot by for managers?
And what's the danger? And now that everyone is using
AI, right, as a manager, at the end of the day, you're kind of
like responsible for the delivery of your team, you know,
the organization. What aspects do you think
management will need to consider these days?
I think the most important aspect is not to focus on at
that speed, right? Like, as if that's all we care
about is are we moving faster, Then you'll probably find that
you have a big price to pay later on.
You know, like, it will hit you in the face at a later stage
when you're not prepared for it. So really I would say leaders
today should be thinking about how to leverage these tools for
optimizing quality as much as possible, as counterintuitive as
that feels, because the speed is so seductive, right?
Use it to leverage the quality of the systems that you're
building because that will in turn create sustainable
productivity gains into the future, right?
That's probably somewhere where engineering managers need to
really reflect on how they perceive good performance,
right? How do you even measure building
high quality systems? Well, we have some tools
available like Sonar cube can help you with, you know, it's
was that latest PR increasing or decreasing Cyclomatic complexity
or you know, code smells or things like that.
But I would urge people to look at that angle of it more than
ever because of the speed at which we can erode.
Like how these reports that we see Dora and the get clear one
are pretty clear indicators that things are not moving in the
right direction in that sense. And I don't know if we keep
going down the path that we're going, we're probably just going
to create the next phase will be a clean up phase where we pay
the price of the speed gains that we all experimented with in
2024 or 2025, you know. But if we want to avoid doing
that, then I think we can already maybe start to give a
little bit more attention to the quality aspect of things.
And then through that, I suppose is where you shift the needle on
what it is that you're expecting your teams to really focus on.
And it has to be adaptive as well, right?
Because these tools are evolving so much that maybe today the
sort of code that it generates is hallucinates and qualities a
bit random. But maybe in a year's time, a
lot of that will be resolved. And actually what what we then
need to focus on is how do these LLMS reason about distributed
systems? You know, because right now
they're pretty good at staying within the one repository, you
know, and they can reason about the logic and the workspace
there, some more than others. But you know, most of our
systems are far bigger than just one repo these days, you know.
So how do you reason about bigger systems?
That's where your human software engineer has an edge today.
So being able to reason about systems like that and frame
problems correctly, those are the sorts of skills that
software engineers, you know, those who can do that well will
be at an advantage. And therefore, maybe that's the
type of the direction that engineering managers need to be
meeting their teams towards. Because as you say, like every
individual is still very much responsible for the code they
commit. Irrespective of whether the bot
wrote it or you wrote it or you kind of collaborated on it, at
the end of the day, you're committing it.
Your name is behind that, at least for now, till we have
fully automated agents that are spinning off and writing code
for us while we sleep. But for now, it's still your
code, right? Which means it's your
responsibility. And then it's your manager's
responsibility. And so, yeah, work back from OK,
if that's still my responsibility, what needs to be
true for me to be proud of that work and for it to be good
quality and focus on the skills that would help people move in
that direction. So I think a very good reminder
you just said, right, as tempting as it is, right, don't
focus solely on speed and productivity, right, Because
everyone seems to be still focusing a lot of these aspects,
right? Productivity gain, you know,
less the number of people, speed off delivery and things like
that. So I think there will be time
probably where this becomes unsustainable, right?
Maybe your software becomes unmaintainable.
Nobody can reason about simply because nobody has that
cognitive load to actually understand what AI is suggesting
to your code, especially if nobody's reviewing it properly,
right? So I think there will come a
time that probably, you know, your software is unmaintainable,
right? And maybe you can try to
leverage AI more, but I don't know where it will go to, right?
And putting in guard rails like what you mentioned, I think this
is also important, right? Because when you turn out code,
you need to have the guard rails, right?
Be it, you know, the design, you know, cyclomatic complexity,
security issues as well, right? Especially if you are not
knowledgeable about it and you adopt, you know, insecure code.
Probably it's also one thing that we need to think about.
And I think another thing that I would say for managers out
there, leaders, right, try to be hands on leveraging this tool,
right? Because especially for people
like me, you know, we are in the 40s sometimes, you know, we are
into management a lot, right? And we forget our hands on
experience. So at least adapting, trying to
learn what these two is capable of that kind of gives you the
first effect is like, you know what these two is capable of.
But the other aspect is like, how can you think about the
impact of using these tools? You know, what are the effect to
your maybe your team, maybe to your process, right?
And I think the most important thing as well now becomes like
first principle thinking and systems thinking.
I think you also mentioned it in your block, right?
So I think manager will have a tougher job, I would say,
especially trying to keep up with the AI changes and putting
guardrails and make sure that the team is as productive as
they can be. So we have talked a lot about
all these aspects. Is there any, maybe one thing
that you think you would still want to convey for people who
listen to this conversation? I think I would, yes.
I would say that you know you're not alone if you are.
If you're listening to this and you've been wondering what's
going to happen to your own job or whether you you have a path
forward from wherever you are today, you're certainly not
alone. There's many, many of us.
There's something like 27,000,000 developers around the
world. So there's a lot of software
engineers who are in one way, shape or form currently
wondering what's going to happen.
Be curious to learn to use these tools, right?
Like, get good at them and imagine, use your imagination to
work out how you'd like to see it go and see if you can make it
happen that way. Right.
But play. It doesn't all need to be doom
and gloom. There's a lot of excitement
around. But yeah, just know that you're
not alone. I think is probably a good myth.
Yeah, that's a good thing. So Annie, it's been a pleasant
conversation. So I have one last question for
you. I asked this last time as well.
So what I call the tree technical leadership wisdom.
So just think like an advice that you want to give to the
listeners. Maybe is there anything
different for this episode? Maybe can you share with us?
Yeah, so I reflected a bit on this and it's funny to think
back four years ago, but time has changed.
Well a lot has changed in the time in between.
And so I think this time my advice would be or the take lead
wisdom would be more around AI is what we've just spoken about.
So the first point would be for our software engineering
community to really embrace the full role.
Again. You know, there was a time when
you specialized on the code, as we spoke about before on the
syntax on all of that minor, minor detail.
Keep that in your back pocket, but start looking for
opportunities to expand your horizons and you know, have
opportunities to experience and practice requirements gathering,
you know, software design. Think about that systems
thinking that higher level thinking that we keep being told
is, you know, where we will now go and spend more of our time.
We'll start looking for opportunities to use that skill
because it's the muscle that you have to build up.
So I think it's important for everyone to start looking for
those opportunities. So basically move back towards
more generalist than specialist for the time being.
And #2 is repeating what we have spoken about a fair bit.
But that speed really is very seductive and fun.
But fragility and complexity is very expensive.
And it may not be obvious immediately, but we are starting
to see signs of that. So temper your enthusiasm for
that huge productivity gain that you're reading about in social
media and in academic papers. It's there to be gained, but
it's a trade off between that and the potential cost of trying
to maintain this software later on.
So find your balance. It'll be different for everyone.
At a startup you might be able to take more risks, but in more
institutionalized large code bases, you have to take that
into account a lot I would say. And the third one is an
interesting one, and there might be opinions around this, but I
would suggest to start thinking of these AI tools as not just
mere tools, but as team members. I feel like that's the way that
it's going. You know, we are already seeing
people talking about human AI teams and what that means.
You know, there's research out there about some papers say that
a human plus an AI can be more productive or perform better
than two humans together, and others find the opposite.
So it's an evolving landscape at the moment.
But if you think about it, the way that you interact with these
tools is more similar to how you would interact with a team
member perhaps. You know, some people describe
them as it's like working with a very eager junior engineer who
might make a lot of mistakes but is eager to please.
You know, others actually describe it as having like a
principal engineer on demand. And it all depends on the
perspective of the person in the equation, right?
But for both software engineers and software engineering leaders
alike, there may well come a time when your team will be
made-up of some humans and some AI.
Start thinking about how that changes things for you.
If you're not treating it just like a tool, but instead you're
actually treating it a bit more like a team member, then how
does that collaboration work? What roles would they fill and
how do you manage their performance?
You know, and maybe maybe there's some rubrics around that
that we need to start thinking about.
So that's sort of the futuristic thinking.
Food for thought. A very interesting wisdom.
So I would say maybe it's like a tech leadership wisdom in the
age of AI. So I think I like the last one
that you mentioned. We have to now think that AI is
part of the team, right? So it's a members of the team
because if everyone is using it right and they kind of like take
a lot of part in the delivery aspect of the team, so they
should be treated as a member as well.
So I think that's a very intriguing thoughts for people
to think about South, for people who would love to maybe continue
this discussion, asking you more questions, follow you online, is
that the best place for them to reach out?
Sure, probably LinkedIn is the one that I seem to gravitate
towards the most, but I'm also on Blue Sky these days and I'm
probably less active on X. But yeah, those other two or
just through my website, you should be able to track me down
to any of those others. Annie valor.com, that's my blog.
Right, so I would say for people who are intrigued by the
software identity thing, read Annie's blog post as well.
I think it's a very good food for thought, especially in this
era where everyone seems to be concerned about their role.
So thank you so much again Annie for your time.
So yeah, thank you and wish you good luck with all the research
for this AI related stuff. Thank you so much, Henry.
And maybe let's not leave it four years until we speak again,
but thank you very much for the opportunity to be a repeat guest
on your podcast. And yeah, I guess we'll catch
you around. Yeah, looking forward for that.
Thank you.