# AI Amplifies Software Engineering Fundamentals and Soft Skills

**Podcast:** Thoughtworks Technology Podcast
**Published:** 2026-04-02

## Transcript

Hello everybody.
Welcome to another edition of the ThoughtWorks Technology Podcast.
Uh my name is Ken McGrage.
I'm one of your regular hosts.
I'd like to introduce to you Nate Shooter.
Nate.
Thanks, Ken.
Hi, I'm Nate Shooter.
I'm a I'm a cloud solution architect.
I guess probably the best way to describe me.
Although my my general way of saying what I do is architect as a service.
Yeah, go places, talk to people about architecture and all that kind of fun stuff.
I I do admit the first time someone called me that, I did sound the acronym out in my head and realized it may not have actually been intended as a positive thing, right?
It may not have been a compliment.
So I I I do understand where that comes from.
So it's great to have you.
And uh being a little modest there, you also had a book that just came out recently.
Tell us about that briefly.
I did, I did.
So along with a good friend of mine, Dan Vega, we wrote the fundamentals of software engineering.
Uh this actually grew out of me sitting on the couch one day and thinking of all these little tidbits that you pick up as a software engineer over your career.
You know, like I remember worked with this guy who had like a binder clip attached to his wall, and you'd go ask him something and he'd kind of think about it, and he'd grab his binder clip and flip it, like, ah, yeah, here's the command right here.
And and so, you know, you pick up all these things.
And so I I started jotting them down in a note on my phone, kind of thinking, well, maybe I'll get to like nine.
Like maybe there's a listical talk here, you know, like nine tips on being a better software engineer.
You'll never guess what number seven is or something like that.
And and I very deliberately stopped typing when I got to 42.
And I realized, okay, there's a there there.
And so I reached out to my good friends at O'Reilly and and started talking about it.
Started doing it as actually an online training kind of a thing.
We did a three software engineering fundamentals in three weeks and realized, okay, I've got like 15, 16 hours of material here and ran it and workshopped and they're like, yeah, let's turn it into a book.
And and so, you know, the the rest is mostly history.
And yeah, finally came out here last fall.
So Dan and I have been out touring, trying to get people as interested as possible in it.
And you know, having a lot of success with that.
Well, it's certainly an important time for fundamentals, despite appearances.
Uh, and I must say, in a lighter note, those of us of a certain age are gonna latch onto that 42 number um quite a bit.
Dan and Nate have apparently found the answer to the life, the universe, and everything.
Exactly.
You know what's funny is is we were talking a little bit earlier and uh like in my career, I used to write code for a living, but I haven't in many years.
Um, although I have produced more applications in the last several months than in the previous 10 years.
I I won't say I written any code, but I've produced applications.
So you know, we're in a moment where people are saying, hey, I can build software without knowing how to code.
What's that feel like from where you're coming from?
What's what's your take on that?
The ironic thing to me about this era that we're living through is that I would argue that the fundamentals are more important today because we are generating more code, and so there's more for us to deal with handle, et cetera.
And you know, I I think the interesting part of this is we're probably reading even more code than we did before.
And I think for a lot of us, regardless of what your sort of career arc is, we rarely teach people how to read code.
We just expect you to figure it out.
And and I I I know certainly coming out of university, I thought, well, obviously as a software developer, I just, you know, bang on the keyboard for eight hours a day, and then you get on a real project and realize that most of my work is reading through someone else's code and going, what the heck were they trying to do here?
And why does it do this?
You know, it's like loading that problem into your brain as is 80, 90% of the job.
You know, the typing is the easy part, right?
And so now, you know, we have the situation where our our tools have given us even more capacity to generate code.
I don't think that always generates good software.
And so Dan coined this phrase earlier this year where he said that code is cheap, software is expensive.
And I still feel like that's one of these missing pieces.
You know, he he likes to show this this example where someone says, dude, I just created an app, you know, you're you're out of work.
And he said, Great, can I see?
And he says, Yeah, and it's a link to his C drive.
You know, you go, ah, okay.
So you you know there's more to it than just generating code.
You've got to get that to production.
You've got to make sure it's secure, you've got to make sure that it can scale, that it's reliable, that you can maintain it.
You know, there's a lot more to being a software engineer than typing.
You know, I I I think to me that's one of those ironies.
We focus so much on the writing part of it.
You know, when I don't know about you, but I've never once been asked in an interview.
So, Nate, what's your typing speed?
You know, how many words a minute do you type?
Because because that's what we care about.
You know, I mean, typing has never been the bottleneck in software.
That's not the hard part.
You know, so I I feel like we've we've got some added capacity.
And I think that opens up some interesting avenues that we didn't have before.
You know, sort of that thing about this this morning, that that floor for software got a lot lower.
You know, I I think throughout my career about how often you might have had this team ask for something, like, hey, we need this widget, we need this tool.
And our answer to them is, well, sure, you can have it, but it's going to be 18 months and it's going to be $7 million.
And they're like, oh, yeah, I don't have enough budget for that.
I don't, I don't have that kind of time.
And so you couldn't build this for them.
Whereas now, with these tools, we actually could build them this custom lightsaber that they need that might only be for these five or six people, but it isn't a multi-month, multi-million dollar project involving 45 engineers and everybody else.
I mean, this is something that now all of a sudden it becomes more economical to meet some of these more sort of niche kind of needs than it would have been in the past.
And I think that's kind of exciting.
I'm really interested to see what that opens up for us.
As an example, Dan created this like custom content moderation system for himself.
You know, he'd been kind of stitching a few tools together, you know, as he creates a new video or or you know, he's he's writing a new blog post or putting together a newsletter.
And so he created what for him is exactly what fits his hand.
You know, he creates a video, gives him, you know, here's a transcript, here's a summary, and just simplifies his life.
He could have written that before, but it would have been months and months and months.
And he'd been like, ah, it's not worth the effort.
I'll just stitch these three things together.
Well, now with today's tools, he can put that together in a couple weeks, a couple days.
And now he's got that custom thing just for him.
Now he's not gonna try to sell that, you know, and there's a huge jump from that to enterprise class.
I'm running billions of dollars through this every single day.
But I do think that's a really interesting aspect of this that I don't feel like we've explored enough is what are all these little niche tools that we're gonna be able to build because it's now economically viable, that in the past we'd have been like, ah, nah, not worth it, not worth it.
Yeah, you know, it's funny you say that because um like the apps I've written are mostly for me to use and and that sort of thing.
And what we see a lot of people that are even more on the business side, CEOs and marketing people and sales people going, why did this always take a year?
This is easy.
And they're not thinking about, oh, but is it secure?
Right.
Yeah.
Um, so you know, you've been through a few hype cycles, right?
You're active in the in the spring ecosystem and watching cloud and stuff like that.
Where where's this hype curve compared to those?
It feels like it's accelerated, like it just has happened so quickly.
And maybe that's not really the case.
Maybe they're all this fast, and you know, you just sort of forget over time.
It it is going to be very interesting to see how this all plays out.
And I do feel like maybe there's a bit of an oversimplification of what it means to create an app, right?
And so I think there's a lot of folks who are like, oh, this is so easy.
I just I've seen this commercial my my grad students and I were watching this earlier right after the Super Bowl, and and he's like, Oh, do I just create an app?
Like, yeah, you know, and I'm like, I mean, kinda, you know, you you you put something together, that's cool.
But again, you're missing all the illities.
You're missing all the architectural things.
You're missing all of them.
Yeah.
We've all learned a lot through making our own mistakes.
You know, I I think every software engineer at one point or another has written a script that deleted part or all of their hard drive.
Yeah.
And so you just think about some of those kind of things where yes you may have put something together and it may work in in these these cases, but did you think of the edge cases and what happens when you know month end falls on the you know the proverbial you know super blue blood moon eclipse or some other weird thing.
It's always time related, right?
And and so I I feel like that's still missing from that equation all the other things that we've learned through trial and error and and often in great pain.
And so we'll learn those lessons again, which seems to be pretty obvious.
But I I am curious to see kind of how that plays out.
You know, it does seem like there's you hear different stories.
You hear like oh a hundred percent of our code's now generated by AI.
And then in other instances where well actually it's had no effect or 95% of these projects have failed.
And you know so there's a lot of of FUD here in in my experience.
So do you think it's the same lessons but a new cohort?
Yeah that that does seem to be the the answer.
I I read something where every five years basically half of our industry is kind of turned over as we bring new people in.
And and so it's like that you're kind of constantly dealing with folks who have not experienced that pain.
And and that was part of the impetus for us to write the book was to help folks, you know, maybe skip some of those potholes, you know, because Dan and I fell into most of them.
So here's our you know, roadmap, avoid our mistakes.
You know, I I I have a son who's just started college, and I remember telling him when he was younger, you know, you can learn from my mistakes.
You don't have to remake all of them.
Although he did say to me one day, he's like, Leo Dad, sometimes I just need to make my own mistakes.
I'm like, okay, I get that.
I get that.
You can also though, you know, take advantage of my experience.
And I feel like that's part of what what we we kind of owe the next generation is to help them avoid the mistakes that we made.
Now, I I will admit sometimes when you make your own mistake, it sticks a lot more in your brain, and you're like, I'm never gonna do that again.
You know, so sometimes just reading it or hearing, you know, you and I or something like that, you know, wax poetic doesn't make it as real as, oh, I just lopped off my finger.
I I guess I shouldn't make that mistake again.
Yeah.
But mine's 28.
I urge you to keep fighting the good fight, but not have too high of expectations.
Uh I don't know if it was if it was you or Dan or the I'm not even sure the quote's accurate, but we heard that uh the provocative claim of the universities and boot camps teach you to code, but not to engineer.
Yes.
What's what's the gap?
Yeah, so I I think that, you know, I mean, as a graduate of a computer science undergraduate program, I I understand some of the limitations of what we are trying to do over the course of a four-year program.
Mostly as an undergraduate, you're being taught to go to grad school.
Like, here's the things you need to go get a master's or PhD on boot camp, or mostly just trying to stuff a bunch of stuff into your brain as quickly as possible and get you out the door and be employable in you know some number of weeks.
But we miss a lot of the I think bigger picture, right?
So we have this tendency to focus on kind of the typing bits and you know, here's a framework and here's a language and here's how you talk to a database, and not the bigger picture of well, how do you make code software?
And and how do you turn that into something that is robust and resilient and scalable again, kind of all these ill-dies that we think about as as architects, you know, and so what does it take to kind of move to that next level?
And so instead of being tactical around the code compiled, ergo it must work, to well, no, I've got to write some tests, and then I've got to, you know, work with maybe my QA people, and then I've got to work with my my BA or my product owner to understand what the business actually needs.
And I've got to know how to communicate with other human beings.
You know, I I think that's been one of the biggest shifts I've seen.
You know, there was this stereotype, certainly when when I was first coming up, that software engineering was just like lone wolves, you know, and and just the the cowboy coder banging away.
And boy, I don't think I have ever in my entire career worked on an application that was just one person.
You know, they're they're just they're all team sports and team event.
And and I think that surprises some folks to understand how important communication is.
You know, that you've got to be able to communicate with other technical people, but also people who aren't as technical.
And so, how do I translate that?
How do I work with my stakeholder to understand what do you really need the system to do?
How do I get beyond them trying to solution me to what is your actual requirement here?
And then how do I help them think through the edge cases?
Humans are really good at happy path, but we all know that that that's not the hard part.
You know, I I I feel like software, we we can get the first 80% done relatively quickly for some value of quickly.
It's that last 20% of, oh yeah, what do we do here?
What about when this happens?
And, you know, it's it's all that weird stuff that that only occurs when sort of contact with real users happens and and they do things we never anticipate.
You know, now you'd like to think some of those are easy to anticipate.
I I don't know if you remember earlier this year, I think it was this year, there was a power outage in San Francisco, and all the Waymo's were like, uh oh, we don't know what to do when the stoplights are blinking.
Like that nobody bothered to program that in.
And and I understand that there's a lot of edge cases that, you know, you and I could sit down for a week straight and think we thought through them and we'd still miss a whole bunch.
I would have thought a power outage where the stoplights are blinking would have been something that would have occurred at some point that, oh yeah, that that's gonna happen, right?
And and so there are those kinds of things that that if you're not thinking about, if you don't work through that, it's gonna crop up, it's gonna bite you.
And so hopefully we're a little more proactive about it.
So to me, that's the difference from just churning out code and building software of actually doing the engineering that goes into building robust systems.
Yeah, you know, it's it's funny that you bring that up because we had an event that we hosted a couple months ago, the future of software engineering, I think it was.
Um, you know, uh, and one of the topics was things about what is what has to be true for self-heating healing code.
And somebody made the comparison of using software as a for retros not for retrospectives, but for disaster analysis or failure analysis or that sort of thing.
That you know, a human often will say they'll hear a story and they'll be like, Oh, that reminds me of a thing that happened two years ago.
Uh let me go, let me go look up that email or you know, what have you.
And AIs just don't have that context.
And so they may be able to go line by line through the code.
Um, but it's funny because like personally, one of the biggest tricks that I've uh started using with Claude Code is tell it I'm frustrated.
Like actually say, you keep getting this wrong, stop guessing.
And it will say, you know what, you're right.
Let me go research this.
Sure.
You know, and so it it's funny because at that event we were talking about context, but another thing that came up, and I'm really curious about your take on this.
Um, there was somebody there, and it was mostly pretty experienced people, and one of them was a senior manager.
It's Chatham House Rules, so I'm not gonna say who or what company, but they were a pretty senior manager, and they said they would have engineers come to them and they would say, Oh, the AI doesn't work for that.
And their response was, Well, did you help it?
And the engineer would get this weird look on their face, and it's like, if it was a grad student or something like that, you would say, Well, have you tried this or have you tried that?
Or have you did you do that with your AI agent?
And the guy's like, Well, no, of course not.
So, well, then you failed, not the AI.
Um, so I mean, what's your take on that?
Are developers now managers?
Ooh.
Boy, that's that's a good question.
And I mean, I think it's possible, right?
I I think it's it's the one constant in my career, and and I I I certainly am not unique here, has been change.
You know, I I had a dear friend of mine, we were playing golf one day, we're walking off the the 15th T at my golf course, and and he said to me, you know, Nate, don't you think it's time for you to get into management?
I'm like, whoa, dude, like that's fighting words.
Like, what do you why are you saying this to me?
He's like, Well, you know, when I was about your age, I was getting kind of bored, and I could do my job in my sleep, and you know, then I got into management and I became, you know, I got to be a force multiplier and help people grow, and you know, you're you're kind of about that age when I did that.
Don't you think you should be making that transition?
I looked at my said, well, John, I think the big difference is my job's never been the same for more than about two years.
And so I don't feel like I've ever been able to just, you know, do it in my sleep.
It's constantly evolving.
And so to me, that's what I look at here is this is just another evolution.
And we don't quite know how it's all gonna play out yet.
It's still pretty early in that.
You know, and so I do think we're we're still struggling to find the best way to work with these tools.
It's clear that good prompting helps, giving it good guardrails helps, but it does feel somewhat like that.
And maybe maybe the right analogy is you've got an intern and the intern is taking direction from you.
And so I think back to a summer intern I had, who's still very good friend of mine, is one of these folks who, you know, you you dole out little tasks at first, right?
Little simple things where it's obvious and contained, and maybe you give him real direct guidance at first, but eventually I started giving him more nebulous tasks.
And I remember the first time I gave him something where I didn't have a preconceived notion of how he should fix this.
I didn't even necessarily have a fix yet.
I'm just like, hey, go try this, go figure it out.
And a couple of days later, he came back with this super clever, unique solution.
And I just started laughing.
I went straight over to our boss and I was laughing and I told him what happened.
I said, if you don't give this kid a job offer, like you fail.
Like you got to get this kid on staff.
And we hired him, you know, and and he's had an excellent career ever since.
He's a great guy.
I mean, so maybe it is part of that.
Maybe it's us learning how to work with these tools effectively and understanding then what our role is.
You know, I do have some concern that some developers are just gonna be like that bobbing chicken and just be like, you know, looks good to me, looks good to me, looks good to me, without understanding, you're still responsible for that code.
You're still responsible for what that does in the system.
And as as my my co-author Dan likes to say, you know, you're not a passenger, you're the pilot.
And so you you have an active relationship here that you have to entail.
And so to me, I think that is part of it is how do we work together to to generate, you know, this this code potentially faster than we did in the past, and then understand how do I shape that into a full software system.
Then how do I make sure that can get to production in a reliable way?
Yeah.
So, you know, it's funny because you touched on it in a couple different answers, but um, you know, like you said, for example, that you know, typing's the easy part.
Uh inside in the book, I believe there's things like soft skills, communications, stakeholder management.
How do those belong in a fundamentals of engineering book?
Because we don't teach them to you.
I mean, I again I I had an undergraduate degree in computer science.
We never talked about working effectively with other people, how to communicate, how to write up your ideas, how to present.
Yeah, I I'm often asked for book recommendations, you know, especially around architecture.
And and so I'll I'll typically recommend one of Neil and Mark's books, you know, either fundamentals of of software architecture, software architecture, the hard parts.
Uh, but the other one I recommend, and I've made my grad students read this now for several years, is Dale Carnegie's How to Win Friends and Influence People.
And I was actually at an event, made that recommendation year later, same event, someone came up to me and said, You recommended that book to me, and it changed my career.
I'm like, outstanding.
I'd love to hear that.
I I don't know when the first edition of that book came out, Ken, but I know it's older than you and I.
And you and I've been around the sun a few times, you know, and that book is evergreen.
And and I I do think that's another really important part of this.
And so I I had a good friend of mine explained this to me once.
And we have this tendency in software to focus on on very short-lived skills.
You know, I mean, skills have a lifespan.
You know, so you think about something very tactical in many cases, like a JavaScript framework.
You know, those tend to come and go pretty quickly.
I mean, I'm not even sure what the today's, you know, hip modern, you know, UI framework is.
I mean, I live that space for a long time, but haven't been there in a while.
But those tended to be fairly transitory, right?
You know, a new one comes along every every few weeks or something to that effect.
No, I guess we'd say kind of coding agents seem to be that way.
You know, every time I turn around, somebody's got a new model that's faster and better, or new, you know, open claw and all these other fun things.
But there's other skills that are gonna last you your whole career, and that how to work effectively with other people, how to communicate, you know, that stuff really matters.
And and I've seen a lot of engineers get really frustrated because they look around and go, Well, why'd that guy get promoted?
I'm a better engineer than they are.
It's like, well, are you?
You know, I mean, let's take a step back.
Let's let's look at what is it that they can do that you can't do.
And as much as we love to focus on the hard engineering things, those soft skills really matter and they're evergreen.
You're constantly going to be working with other people, you're constantly going to be communicating, whether that's over email or over Slack or building a presentation.
And in general, if you look at the people who are still moving up the rungs, if you're not, it's because they're better at some of those other skills that you might be ignoring.
I I ignored those early in my career because I thought the only thing that mattered is a software engineer was well, I know more about databases or I know more about Java, and didn't fully appreciate how important some of these other things were, you know, and and understanding that yeah, we don't like politics, but it happens.
Anytime you got two people in a room, you got politics.
So you gotta learn how to work with it.
You gotta learn how to use it to your advantage.
You gotta learn how to manage your manager.
You know, and so these are those kind of things that really inspired us to write the book is we learned that the hard way.
We learned that through trial and error.
And this is the book that I wish I'd had when I first started.
This is the book that I would hand to someone, you know, if they just started on my team.
Like, here's the things I need you to know.
You know, here's the bigger picture of what it means to be a software engineer, not just a person banging out code.
I've been thinking about a lot about it, and and again, you and I, of course, were chatting beforehand, where and uh this is what AI changes the stakes, but not the rules.
And so, like Nathan Harvey from Google's Dora project uh uses an example and he sells it way better than I do.
But the basic idea is you know, if you put an amplifier on a bad band, it's just a bad band louder.
Yep.
You know, it doesn't make it better.
And so AI is an amplifier, it either makes more people enjoy your music or run away from it, one or the other.
And so, in that vein, like think about like testing strategy and that kind of stuff.
And I and I and uh you make a comparison.
I think the testing strategy versus writing tests.
What's the difference?
Yeah.
Well, so so to to jump off on your thought there a little bit about making a bad band.
I'm not a particularly handy individual.
Like if there's a video and it's literally like unplug this and plug this in, I can probably do it, maybe.
But by and large, if if there's a project around the house, I'm gonna try to find someone to do that that's a professional that knows how to do it.
And and so the analogy that I would make is giving me a nail gun does not mean I can go build a deck.
That would end badly for me, for the deck, for anyone that stood on the deck, like well, I'll interrupt to you and say that would end badly because you're supposed to use screws on a deck.
Well, there you go.
See, exactly.
And and so, you know, I think these these tools, without the proper training, knowing how to apply them, knowing the bigger picture of, oh yeah, no, that's that's the naive way to solve that problem.
But I know from experience that actually this is the better way to solve it.
So don't use that construct, use this construct.
And there's countless examples of that, you know, we've already seen where, yes, an AI tool will generate code that works, but not as good as it could.
It's not the ideal way, not the platonic way to do it, not the best way.
I mean, although I will say in software, there really is no best way, right?
There's just like least worst in many cases.
But this is a suboptimal solution to that problem.
A naive solution that will work, but but you know, could be better.
So I I do feel like like that's part of the equation.
Now now back to your actual question, because you know, this is the joy of these things, right?
We take the question we want.
Writing tests is important, but understanding like what do we need to cover?
How much do we need to cover?
You know, I mean, I've I've had debates with people about code coverage numbers.
And you know, I I think when I was younger, I was very dogmatic that everything must be 100% across the board, no ifs, ands, or buts, test everything.
And I think with age, you learn pragmatism.
And I'm very much of the opinion that you need to be ruthlessly pragmatic about any of these things, that dogmatism is dangerous.
And so what are we testing?
What are the important things to test?
What could we maybe we don't have to worry so much about that?
You know, and and understanding, you know, like that there may be a point where to get another percentage point of coverage, the level of effort required to do that might not be worth it.
So, you know, we need to make a judgment call there and and understand that well, but this part's really critical.
We've got to make sure we're testing that.
I think with AI, that becomes incredibly important.
You know, I've had various discussions with folks, I know you have too, around is code going to be a durable asset in the future, or is it just going to be specs?
You know, and and I'm I'm I'm not sure where to land on this yet.
I mean, I I I I cling to code, but I I sometimes take a step back and say, well, is that just because that's what I've always done, that's how I've always done it.
You know, you know.
So do I need to think about this differently?
And, you know, I can certainly see a space where the spec becomes the thing and we just constantly regenerate the code.
I do have some concerns about that.
I mean, not the least of which the cost of how to, you know, what's it take in terms of time, tokens, money, energy, et cetera, to actually regenerate a non-trivial code base on a regular basis.
But then there's also the verification side of it.
So if I do have a robust test suite around this code, then it isn't as important that it's non-deterministic.
So I don't really care if I get the the same code as long as I get the same results.
That's all our customers care about.
You know, if if I give you these two inputs, do I get the same output every single time?
That's what matters.
But I I had this conversation actually last week with with someone, and he made a really good point.
He said, Listen, I can write the tests that show you that the system does these 10 things, but I can't write tests that prove it doesn't also do these other five things.
I thought, oh man, like so we're gonna have the That's deep.
Right?
I'm just gonna lop off a few pennies and put it in this this other account.
You know, and and I'm thinking to myself, boy, that's a really interesting attack surface area that I hadn't fully considered.
I can't prove that the software does things in addition to that.
And if you and I are working on a project together and somebody sneaks in some code that throws money into an account, let's just say, you know, let's use the Superman example.
Okay, we're gonna see that.
And so somebody is gonna notice it.
Somebody's gonna be like, hey, what are you doing here, Nate?
You know, or we all gotta be in on the meal, right?
But if I'm not looking at the code, if I'm treating the generated code like Java bytecode, like I've don't think I've well, I have looked at Java bytecode, but but very, very, very rarely.
And and so I can understand that conceptually we may get to a point where we are writing in more natural language, and then it's generating maybe straight down to machine code.
I don't know, maybe we don't we don't even need Java code if it's just gonna be obliterated all the time anyway.
So maybe it can write straight to bytecode.
I don't know.
I mean, there's all sorts of different ways it could get to the result.
But then I I also lose the visibility of is it doing some other stuff?
Has it has it done some things maybe that I I don't want it to do or didn't intend it to do?
And how do we close that gap?
Because you can't write infinity tests.
So I don't quite know how we'd ever fix that.
And that's a really interesting thing, because uh, you know, again, some of us of a certain age.
Uh you're talking about you know, bytecode and what have you.
I mean 30 years ago, but you know, when using compilers, we were very careful about checking did the compiler do what I expected it to do.
Right.
Uh, and now we just trust them.
So I mean, do you think AI's gonna well, I mean, I think eventually all we, you know, but what are your thoughts on how close are we to saying it's a compiler, I'm just trusting it.
I think we're further away than maybe some people would say, and and I'm I'm always cautious when when you hear bold proclamations, well, I need I need proof that goes along with that, right?
We can't you know the the bigger that that you know proclamation, the more proof I want to see.
It's also important to understand that where are these bold proclamations coming from?
And in many cases, they're coming from folks that have a huge financial interest in it being true, that they're trying to raise a lot of money based on very, very high, stratospherically high valuations that require this to be true in order to justify those valuations.
So I think it's always good to be a little skeptical, a couple grains of salt.
I I suspect at some point, and I I don't know if this is six months from now or 15 years from now or somewhere in between, we probably will get to a point where we have an awful lot of faith in what these agents are doing.
And and over time, you know, as they improve and as they they get better, and we get better validation and verification pieces to this equation, we probably will start treating it as just I don't know, I haven't looked at that in years.
It reminds me a lot of when Hibernate first came out.
I had a good friend of mine who was really, really good at SQL.
And and I'll admit I was terrible at SQL.
I I could do like select star, you know, kind of stuff.
But once we got into like inner joins and outer joins, uh my mind just didn't map to that for some reason.
But but Mark was great at it.
And so he was telling me when Hibernate first came out, he was super skeptical.
And he would look at the SQL regenerator, he's like, mm, that's garbage.
It shouldn't do it that way.
And then eventually he just realized it's got a good reason.
I'm gonna trust it, because it's better than what I did.
And so even me trying to write optimized SQL, it was more performant.
So okay, you know, you've you've proven it to me.
And so I suspect we'll go through a similar sort of phase where you know, gradually over time our our cynicism maybe will start to fall away.
And we'll go, okay, you you've proven to me time and time again.
Just like with that intern, right?
So when when Joe first started, again, I gave him very easy tasks, very straightforward, almost told him exactly what to do.
By the end of the summer, I'm like, go get it.
You got it.
Good, go solve this problem.
You know, call me if you need help.
Right.
And and so I I suspect we'll see a similar trajectory here over some period of time.
So you mentioned at the top that reading code, you know, is a fundamental skill.
Uh, and there's no question AI can generate code faster than we can read it.
Absolutely.
Um, is that still a fundamental skill?
I mean, how do you what's what's the bottleneck?
How do you contain the you know the throughput that those investors want?
Yeah, I I certainly think it is, at least in this interim period, until we potentially get to the point where we are just writing specs and and not worrying about what comes out the other end, per se, as long as again the tests all pass.
So I in the meantime, I think it's even more critical.
I think it's more likely that we're gonna read even more code than we did in the past because it it does allow us to generate things much more rapidly.
And your level of investment there may change and there may be part parts of the app where you know I don't really care.
Like I'm probably not going to go look at the CSS.
As long as it looks right, that's fine.
You know, but if this if if I'm using AI to generate our pricing algorithm or to make a change to our pricing angle algorithm or something that is really critical I I would argue you're going to want to give that a pretty good look.
You know you're not just going to want to YOLO that and and see what happens.
You know and so I I do think it's still going to be important for us to to be able to look into that.
And I mean I am absolutely of the opinion that we're going to experience an uptick in kind of the shadow IT.
And I I think every every engineer who's been doing this for more than about five minutes has had that experience where in the past it was always a spreadsheet.
Somebody swizzled together a spreadsheet just for their own needs, shared with a few other people and before you know it, this whole team uses this spreadsheet and a billion dollars a day is going through it.
And then on Tuesday, there's a problem.
And then it lands in our lab.
I'm like, okay, IT people fix this problem.
And you're like, I don't even know this exists.
Where did this come from?
Who wrote it?
Oh, I don't know, some guy who used to work here five years ago.
Great.
You know, and you have no idea what it is, and it's a bunch of stored procs and a bunch of weird stuff merged together, and there's bailing tape and duct twine all around, or duct tape and bailing twine, I guess however you want to phrase it.
And then now we got to disentangle all that, figure out what's going on, figure out what the requirements are, what's it supposed to do?
Is it actually has it ever done it right?
You know?
And so I am very much of the opinion that that's gonna land hard soon for some value of soon.
And we're gonna have one of these drop in our laps, and guess what?
You are gonna have to kind of peel it apart, and you're gonna have to kind of well, what is it doing?
Like, all right, well, is this right?
Is this wrong?
You know, and so I I think for the foreseeable future, reading code is is definitely gonna still be in our our wheelhouse, whether we like it or not.
And I know how frustrating is I know most of us hate reading code.
Yeah, certainly certainly we hate reading other people's code.
You know, like what idiot wrote this?
You know, it's like, oh wait, that was me from a couple of months ago.
You know, again, another very common experience for all of us to have had.
Yeah, I I worked on a project many years ago where we finally had to put a rule in that said, you know, don't put in curse words because people would put in the comment, I can't get this to blank and work.
It was like, would you please not do that?
It's not gonna get taken out.
You think it's gonna, but it's not, it's gonna live.
But anyhow.
To do fix later.
Yeah, exactly.
Um and so um I I used the AI overlords to help me do some of the show notes for this, and it it put this question in here, and usually I rewrite eighty percent of it.
But this I thought was unfair and a little funny that it thinks you should be able to answer this.
So I'm gonna ask it to you anyway.
Excellent.
What does a software engineer role look like in three to five years?
Wow, that's a great question.
I suspect we're gonna do even more people stuff, right?
And then I know a lot of people got into software because I don't want to deal with people.
People are messy.
My my wife sent me uh like an Instagram thing where this this guy said, you know, I'm just not a big fan of people.
And then I got into a career that's basically a hundred percent of me working with people.
Uh that's my bad, you know, and and so I do feel like some people got into software thinking that it was an escape from messy people things, only to realize that that's all this is.
Yeah, I've been on a lot of projects, been around a lot of companies, and I don't honestly think I've ever seen a project fail because of a technology decision.
Projects, the problems we encounter are ninety-nine percent of the time they're people problems.
They're these two people aren't getting along, these two people aren't talking, you know, th there's there's just a divergence here, or we're not all on the same page.
You know, you think about a lot of the the ceremonies and and and things that we do from from an agile software perspective, and a lot of what that boils down to is trying to get us all on the same page, getting us working together more effectively and that tear down those walls, you know, get rid of the, you know, the uh the trenches between different departments.
I mean, I think you and I are old enough to remember the phrase, you know, throw it over the wall to QA, throw it over all the wall to production, you know.
And and ironically, beginning in my career, I did have a QA person sitting right next to me.
So I could literally say, I'm gonna throw it over the wall to Brenda and and you know she was gonna test the stuff I was working on.
So, you know, that kind of worked, right?
So I I think it's gonna be even more of the people stuff and more of the, so what should the software do in this situation?
And tell me more about that.
And, you know, I I joke sometimes that our job is is almost like psychologist, you know.
So so how did that make you feel?
And you know, okay, what well, what can we do more about that?
How do we fix that?
You know, and it isn't as much, wow, you know, this is taking too long.
How do we optimize this algorithm?
And and there are pockets of that, but few and far and in between.
You know, so much of this really is okay, you and I need to have a conversation, we need to figure this out, we need to work through this.
We we need to do that trade-off analysis to say, all right, we you you can't you can't turn every knob to 11.
So how do we get this balanced in the way that's least worst for for this particular outcome?
So someone's listening to this episode, you know, they come out on Thursdays just through standard distribution.
Most of the listeners are Thursdays and Fridays.
Uh Monday morning when they go into work, what do they do?
What's the action they should the first thing they should take to reset, restart this journey?
I I think it's having an open mind.
And I think it's software engineering is this constant game of learning new things and picking up new tools, new languages, new frameworks.
And I I look at this as not being really any different than that.
It it may have a profound effect.
It may fundamentally change some of the things we do day in, day out.
But I would say that's kind of first and foremost is have an open mind, try these things out and explore and see what works and doesn't work for you.
And you know, again, I think so often we get stuck in this.
I have to follow this recipe or I have to follow this path.
And it's like, but you can shape that to your needs and what works best for you in the same way that you know I encourage people to change your font.
You know, there are a bunch of different really good monospaced fonts out there.
Try a different one.
It might it might help.
Your eyes might like that one better.
Try dark mode, try light mode, tweak your environment.
You know, you you absolutely have control of that.
And so you should make it your own.
I think so often we get stuck in the well, no, I just have to sit in the chair like this.
Well, it adjusts, so move it up, move it down, you know, try different things.
So try different things.
And what I think is so amazing right now is all of these different models, they some do things better than others.
And so try it out, see what happens if you ask Gemini this question and Chat GPT, you know, and Claude, which one gives you the answer you like best?
And and you should, at least this has been my experience.
Oh, I really like Gemini for this, I really like Claude for that.
I really like, you know, and and so take advantage of that and and use those tools where you can.
I think the worst thing you can do is just say, you know, put your hand up like nope, nope, not for me.
Uh, this isn't gonna change anything.
It it is.
We don't quite know how yet, but it's better, I think, to be playing with these things, exploring these things, seeing how it fits in your world, how does it mold to your hand, and and then start start exploring that.
Yeah, and I think if you put up your hand and you say nope, this isn't for me, the thing that's going to change is going to be your employment status.
I agree.
Absolutely agree.
Uh so I want to thank Nate Shooter for all your time.
Um where can people find the book?
Hear more from you.
What's going on in your life to steal from hot ones?
Uh beyond beyond my day job here at Thoughtworks.
So I I get to go to a handful of events here and there.
Uh Dan and I will actually be at Ark of AI here shortly.
I believe we're gonna end up doing Ben Cat's conference in the fall as well, Dev2 next.
Uh we've certainly pitched some other events as well.
We've we've I've been just overwhelmed with the reception that we've had when we present this as workshops and as talks.
We've had a bunch of staying or molys, which is really really gratifying as as a presenter.
You know, there's nothing quite as fun as as that, honestly.
Uh we're on the socials, you know.
Dan and I do periodically podcasts.
We we had a bit of a lull there as we got really, really busy between travel and other things.
So we we actually owe people some new new episodes, but we do have a companion podcast that we've been trying to spit out there as well.
I mean, we're I guess that's the rule, right?
You know, that everybody's gotta have at least one podcast these days.
Um, but yeah, we're on we're on all the socials and LinkedIn and all that fun stuff.
So, you know, please engage, you can find the book on O'Reilly, you can find the book on Amazon.
If you've got an O'Reilly subscription, feel free to read it there.
It is print on demand if you want a dead tree.
I got some dead tree copies over my shoulder.
We do try to give dead tree copies away when we're out in the wild as well.
So track us down.
We're always happy to do that.
All right.
Thank you again for your time.
Thank you.
Thanks for having me.