Subscribe
Share
Share
Embed
The development world is cluttered with buzzwords and distractions. Speed, focus, and freedom? Gone.
I’m Nicky Pike. And it’s time for a reset.
[Dev]olution is here to help you get back to what matters: creating, solving, and making an impact. No trend chasing, just asking better questions.
What do devs really want?
How can platform teams drive flow, not friction?
How does AI actually help?
Join me every two weeks for straight talk with the people shaping the future of dev.
This is the [Dev]olution.
Dan Vega (00:00):
The idea of vibe coding, that you can just basically take natural language and turn it into a working product. I love it for the fact that you have someone who's really good at creating these ideas and has this vision of something and can now turn that into a reality without having to hire teams of developers and tens of thousands of dollars. Just to get an MVP out there, this is great. This is allowing us to do this.
Nicky Pike (00:25):
This is [Dev]olution: Bringing development back to speed, back to focus, back to freedom. I'm Nicky Pike. Okay, so everyone's talking about AI making developers more productive. Satya Nadella says it lowers the floor and it raises the ceiling. It's easier to get started, but it's more powerful for experts. Sounds great, right? But here's what nobody wants to say out loud. The US programmer employment dropped 27% between 2023 and 2025, not just junior developers, all developers. That floor that Satya is talking about lowering it's collapsing into a basement. We've got developers losing months of work because nobody taught them get clicking except on AI generated code that they can't explain an entire generation learning to code who have never debugged without a copilot. The fundamentals of software engineering have never mattered more and we're actively abandoning them. With me today is Dan Vega. He's a spring developer advocate at Broadcom and the co-author of a brand new O'Reilly book called The Fundamentals of Software Engineering.
(01:25):
Dan spent 25 years in this industry. He started at a seven person startup. He's worked his way through enterprise architecture. He's built bootcamp curriculum that has turned career changers into engineers in less than three months, and now he's one of the most recognized voices in the Java community. His new book isn't about Java, though. It's for anyone who's learned to code and realize that there's a massive gap between what education teaches and what the job actually requires. Here's the challenge on the table. Stanford researchers found that employment for young software developers has dropped nearly 20% since AI coding tools went mainstream at the same time, 85% of developers are using AI daily. So we're all adopting these tools while entry level pipeline is collapsing. How do we build the next generation of developers when the learning curve that trained every senior engineer out there is being automated away?
(02:12):
Dan, welcome to the [Dev]olution.
Dan Vega (02:14):
What an introduction, Nicky. That is probably one of the best intros I've ever gotten, so thank you very much. Good to see you, my friend.
Nicky Pike (02:21):
Same here. Well, we've got the infamous the great Dan Vega on here. Anything less than a great introduction would just not do you justice, my friend.
Dan Vega (02:29):
I love it. I appreciate you. Thank you.
Nicky Pike (02:31):
Oh, no worries. So before we jump into the questions, man, anything you want to kick off or get started or you just want to jump right into it?
Dan Vega (02:38):
Yeah, we'll talk about the book today. We'll talk about whatever we can get into. If you want to learn more fundamentals of sw.com, you can find out more about the book and the podcast there. You can find out more about me@danvega.dev, but let's get into it.
Nicky Pike (02:51):
All right, we'll make sure we get all those links in the show notes below. But yeah, let's go ahead and jump into it. So you titled this book The Fundamentals of Software Engineering, and you released it right as AI is supposedly making fundamentals obsolete. This kind of feels deliberate. Was it? Or was it just coincidence?
Dan Vega (03:08):
I think it was a little bit coincidence, but as we started writing it, it became more deliberate. So again, I am one half of the dynamic duo on this book. My good friend Nate Schutta is the co-author, really the originator behind the idea of this book, and the title is from Coded Engineer. And the idea behind this was we all get into this industry on a different path. All of our paths are different. No two are usually the same. So some people go to a four year college, some people go to maybe a two year technical school or a bootcamp or no matter which path we've taken, there are certain things that we learned in that kind of role. Maybe in a four year college you learn more theory and algorithms and a whole bunch of that kind of stuff. Maybe in a bootcamp you had three months, so you were compressed on time, so everything was thrown at you really quickly.
(04:01):
When you're self-taught, you kind of learn what you want to learn. So no matter what we did to get into this industry, there's a gap between that and what you need to know on the job. So from coder to engineer, what we try to do is fill that gap. Now, the book's only 400 pages. There's a chapter on something like automated testing, entire books and courses written on automated testing. We could not go exhaustive into each of these things, but what we're hoping to do is in the first role or two that you're on, fill some of those gaps to give you a little bit more confidence in the position that you're in. And also, I say that as we went through the book, I also found that even someone with five, 10 years experience can get something out of this book. You may not read a cover to cover, but there are really, I think some good takeaways in certain chapters.
(04:55):
So I think this book is for everyone, but that was kind of our mindset going in. And as you said, as we started writing the book, we started thinking of, okay, when we go talk about this places, what does this look like? And so we've already given a bunch of workshops and keynotes on this book, but the title is The Fundamentals of Software Engineering in the Age of ai, because that's really what it is. I started seeing people, oh, I wish I never went to school for four years because now I have these tools at my disposal and I don't need the fundamentals. And I thought the exact opposite. I say these are more important than ever. So yes, there's a combination of both of those things there.
Nicky Pike (05:36):
And I'm remiss not to mention Nate, I mean, correct me if I'm wrong, but Nate's been in the industry like 45 years. I mean, between the two of you guys, you got 70, 80 years worth of experience here. Did y'all kind of build this to be the OJT of books?
Dan Vega (05:47):
I got to stick up for my buddy Nate. It's not 45 years, he's around 25 years. I'm around 25 years. I think if you put us together, we got about 50 years of experience packed into 400 pages.
Nicky Pike (05:59):
Nate, you can yell at me for making you older than you were the next time we see each other. I apologize for that. Yep. Did y'all kind of create this to be the OJT manual for people that are starting out?
Dan Vega (06:10):
Well, it wasn't really that. It was just like, I remember being in a position where I was new to the workforce and I was, okay, I learned this stuff in school, but now I'm supposed to produce and be a contributor, and how do I do that? And so we started thinking about a lot of the things that, again, you may have learned how to build an algorithm in college, but did you get extensive knowledge on Git or reading code or working with existing code? And so we started thinking about these things and said, what are those things that again, can just give you a little bit more confidence? So I'll point out one thing that we're taught, however, we're taught self-taught bootcamp college, Hey, you need to build this program and to build this program, you need to write code. We're often taught how to write code right out of the gate.
(07:06):
A fundamental skill that software engineers to have is reading code. We probably read 10 times more code than we write, but yet we're taught to write code first instead of read it. So we have a whole chapter on reading code, like some tips on how you can understand code better. And we also have a chapter on exploring on unfamiliar code bases. So I don't know about you, but I had a lot of anxiety early on and shoot even 10 years in when I was on a new job and I got thrown into some huge project and I was like, where do I start? The documentation's not up to date. These tests are not up to date. I don't know where to start. And all of these other engineers are here that have been here five years, they know how to contribute right away, and I'm just dumbfounded. Where do I get started here? So I think just some kind of tips like that, helping engineers gain a little bit more confidence.
Nicky Pike (08:00):
Yeah. Well, and you mentioned reading code is probably one of those skills that you absolutely need to learn, and I believe that to be true just from a software development, but definitely in the IH because we're looking, 41% of code now is being written by ai, so you've got to be able to read it and
Dan Vega (08:15):
Understand it. I'm called on that number. I don't buy that at all.
Nicky Pike (08:18):
Well, I mean there's studies out there, Dan, right? There's studies out there, but
Dan Vega (08:22):
Anybody can shape a study to say, who are these studying? One particular firm. Yeah, sure. But it's 41% of enterprise code. I don't think so.
Nicky Pike (08:31):
Well, I think we probably need to define that, right? Yes.
Dan Vega (08:33):
So
Nicky Pike (08:34):
When we say that 41% of code is written by ai, I don't think that means completely generated by ai. I mean, it means that AI is typing it, but it doesn't necessarily mean that somebody just said, Hey, build me an application and AI wrote the whole thing. There could be a lot of work to win behind that, but maybe AI did the typing.
Dan Vega (08:53):
So we could go down a rabbit hole with this. We could say a hundred percent of this is if you count like IDEs IntelliSense, right? We were all told 10 years ago that because of the rise of IntelliJ or these coding tools that had IntelliSense, that had auto complete, that was going to make us obsolete, and that never really happened. And so yeah, I pushed back against those kinds of numbers and some of the things I pushed back against is, you got to remember who's saying this, right? I kind of referenced Dario from Anthropic said early last year that in six months, AI is going to be ready 90% of our code. That was what? Nine months ago? Now that's not happening. You have to remember who's saying this. He has a vested interest in that happening. When CEOs say we can slash 25% of our engineering, they have a vested interest in that. It doesn't mean that any of this is true, it's just that, hey, if that happens, their stock prices will go up and there'll be more of a billionaire than there already are right now. So I tend to take it with a grain of salt.
Nicky Pike (09:58):
I think maybe you're conflating me throwing that out there means that I think that we're going to replace developers. I don't believe that at
Dan Vega (10:05):
All. I know we're on the same page. I got you.
Nicky Pike (10:07):
I don't believe that. And you bring up IntelliSense. I mean, that was one of the things, again, when that came out, people said, no, this is horrible. Nobody should use it. Now there's not a developer out there that doesn't use IntelliSense, right? So I think that we're looking at something brand new that's starting out, and there is a lot of hesitancy around it because it is a way more powerful than anything else we've ever seen. What that's going to mean to us in the future, we'll have to wait and see, but there is a fact that AI is making its way into every company. Developers are looking into it for ways to increase productivity, and I think that's a byproduct of companies saying, Hey, I want everybody to do more with less. And so people are looking for ways to increase their outputs.
Dan Vega (10:47):
I just want to bring it back to Intelli though. 10 years ago when that started getting really good, that was a way that I used to learn how to do things. I would write some code and IntelliJ would say, oh, you don't need to use a for loop here. You could iterate over this using the streams API or whatever function or feature that I wasn't using. So I learned to write a lot more functional code just because the ID was suggesting these kind of refactors. I know it's not true, but I hope that this is what we're kind of using AI for these days too. Just like that refactor and like, Hey, I wrote this function. Is there a better way to write this? What is the complexity of this algorithm? It's such a great learning tool, and I'm such a nerd. I love to learn, but I think that's what really excites me about all of this.
Nicky Pike (11:34):
And I'm with you as someone who is, and this I'm a self-described, I am not a developer. AI is one of those things that I do enjoy. I know just enough code to make me truly dangerous, but AI is Google and YouTube all in one for me. It not only helps me answer questions and looks up stuff, but it also gives me examples. Now, I'll take those examples, modify 'em to my own needs and tweak them how I see fit. And it even causes me to go out and look more things up because of what I see it on the screen. And hopefully a lot of people are doing that now. I think you're going to see a split. There's some people we know, there's people out there that are just blindly accepting what AI gives them. We see it every day in LinkedIn posts just with the content that's being put out there. But you've got the other side that are real engineers, the developers that are really looking at this to increase their output that I think are using it in the way that you say.
Dan Vega (12:22):
Yeah, and I think just from my own experience, when I use AI to create Java or spring applications, I know how to guide it. So the end result ends up being pretty good. Now, if I were to go write some PHP Laravel application, I've done this long enough that I could probably get something to work, but I probably don't know the best practices of PHP and the best way to set up architectures in that framework or this framework. I could probably get something working, but it's not going to be as good as if I had some experience. But on the flip side of that, man, it's just so exciting to me that I'm in the iOS world. I have an iPhone, a MacBook. I've never written an app for the iOS store. I feel a hundred percent confident to tell you that if I wanted to sit down this week and put together an iOS app and publish it to the app store, barring that gatekeeping that happens over there, that I could do that.
(13:18):
And that's just so exciting for me because five years ago, sure, I have some level of confidence that I could do that. I could pick up a book, I can watch a course, I can follow some people, I can read some articles. But man, that would take me a long time. It would not be a week. It would probably be a month or two month endeavor. And time is money, and I don't have two months to devote to some tiny little side project that is not going to do anything for me. And now that just excites me that no matter what I want to do, I have the tools to do it
Nicky Pike (13:51):
Well, and I mean that's a great lenient. You opened the AI chapter in your book talking about the Jacquard loom and how pattern leaders in 1801 thought automated, you wanted destroy 'em, but it ended up making a more valuable than ever. So I'm guessing that you're saying that even 200 years later, this analogy is still holding, or is there something different this time?
Dan Vega (14:08):
Yeah, I mean, somehow I'm getting a lot of pushback on that analogy from the book, but I believe it to be, so we've seen some patterns of this throughout history when it comes to technology, even something like bank tellers. Once we got ATMs, we thought, okay, well, we don't need bank tellers anymore. Well, no, we just don't need people handing out money and standing there all day waiting for customers to come in. Now we can be proactive and talk to them about financial security and be able to help them obtain other things like houses and loans and things like that. So what bank tellers did was adapt to what happened in their industry. We had an automation in place to replace one side of their job, but they saw it as a way to adapt to this scenario. And this is what I tell developers all the time, is that things are going to change over your career. They've certainly changed over 25 years for me, but I've been willing to adapt to things. And if you can do that, I think you'll be here and you'll stay relevant.
Nicky Pike (15:07):
Well, I mean, every technology change has came through, has had that same impact of people saying, well, this is going to destroy us. Public cloud's going to destroy the data center, robotics are going to destroy manufacturing. None of that's happened to come to fruition. It's changed the way the people that were in those jobs had to react. And I'm going to throw this out there and see how you react. Your book, the softwares of software engineering, I think is something because as we see citizen developers are becoming a thing. They've got these great ideas, but they don't have the technical skills. I see something like your book being able to help those guys, people that aren't going to get into true engineering, but they want to know the fundamentals so that they can come out with an MVP and going back to your people need to adapt. I think this opens up more jobs for the truly talented engineers to come in and help rectify and polish some of these ideas that come
Dan Vega (15:53):
Out. Yeah, it's funny with vibe coding, the idea of vibe coding that you can just basically take natural language and turn it into a working product. I love it for the fact that you get, like you said, you have someone who's really good at creating these ideas and has this vision of something and can now turn that into a reality without having to hire teams of developers and tens of thousands of dollars just to get an MVP out there.
(16:19):
This is great. This is allowing us to do this. That is the one group that I'm really behind right now. There's another group out there that I think that these tools that came out think that this is a cheat code, that they can just skip everything that we've done for 20 years and become rich like, oh, I copied this vibe, coded this app that makes 10 billion a year. No, you didn't. You copied a screen. There's much more to a 10 billion app than copying the screen. And so there's kind of two camps in this, and the one I'm really behind, the other one is the one I have a problem with. You can't cheat learning this trade or this craft. You can accelerate it. Now, this is really great. You, like you said, start to build things right away, but as you're building them, you're going to run into problems.
(17:09):
You need to understand when things go wrong. And the biggest thing I see is people can't get these things into production and they don't understand architecture and scale and security and those things that we've all been deeply invested in as software engineers. So I'm all for it. But yes, as you're starting to build these things, learn some of the fundamentals, learn what GI is, learn how to write tests so that the next time you push something into production, it's not going to break. Learn the fundamentals and learn as you're going. And if you do, that's great. I think this is again, a way to kind of accelerate learning, not to cheat it because not going to happen.
Nicky Pike (17:50):
Well, and I think this is all about perception, Dan. I mean, yes, this happens with everything. This is not a new story. There's always going to be those chasers out there. It's the loudest voices that are getting noises. I don't think that a majority of citizen developers out there are looking to make enterprise apps. They're looking to make something that helps them out, that helps their family out, or they've got an idea that they want to do, and that's where I think a majority sits. But yes, you're going to have that subset of people that are out there claiming their point to things like Base 44 and look, this guy vibe coded this and it was worth $80 million. Well, yeah, but he was also a professional developer before, and you're leaving that part of the story out. I do think that there's an immense amount of productivity. There's immense amount of capability there with AI that allows people like me, right? I'm not a developer. It's the same thing in the DIY industry. I can rewire my life socket. I don't need to call it an electrician to do that, but I'm not out building a subdivision or wiring a skyscraper on the weekends. No, I'm not doing that. But it helps me not have to get charged a $200 trip tree for somebody to come out and do something that I could do myself, and only I'm going to use,
Dan Vega (18:55):
I'm going to have to call you next time. I don't know how to do that.
Nicky Pike (18:57):
Yeah. Well, we often refer to our house that we're in now, the house that YouTube built. So we built this ourselves doing exactly what we're talking about. My carpentry is what I did, man. That's
Dan Vega (19:07):
Awesome.
Nicky Pike (19:08):
All right. Well, when you worked at Tech Elevator, going back to training people, you took people from all walks of life and you turned them into software engineer in three months. What were some of the non-negotiable fundamentals that you drilled into those, did you think, and you believe still matter today?
Dan Vega (19:22):
Well, there are two sides to this. So in three months they learned a lot of technical skills, but they also learned a lot of soft skills from the technical side. We were an in-person bootcamp. This was before COVID happened actually. I was still there when COVID kind of hit, and that kind of killed the bootcamp at the time. But we were an in-person bootcamp. So the fundamentals for me were from a technical side, just learning how to use things, get that was important. We taught the command line and get week one. So understanding that if you're going to build web apps, getting the foundations of HTML and CSS once you got into backend, if you were doing Java, learning the fundamentals of that. So learning the core technical skills that you needed, but also building real things. So at the end of each week, we had kind of a capstone and it's like let's take what we've learned and build something with it. And not only did we do that in solo by yourself sometimes, but we'd put you in groups to learn how to work with others because that is such a fundamental skill of being in the workforce. You could be the smartest person in the world, but if you are not easy to work with, nobody wants to work with you.
Dan Vega (20:33):
We want to work with people that are awesome. And so putting people in groups and building these projects together, understanding how to collaborate with something like gi, those were important things. And then from a soft skills point, we did a lot of technical interview prep because everybody gets scared about those. What is going to be thrown at me? Am I going to have to do a whiteboard or a lead code style interview question? So we put them through a lot of those. We'd even bring in outside interviewers from companies that they might actually interview with and go through some practice interviews. So it's all about building that confidence again in three months is not a lot of time. So you got to give them as much as you can and get 'em out in the real world, because ultimately they're looking to change careers in that settings. So we want to make sure we give 'em all the skills that we have. So that was a lot of fun. It was infectious. I had a lot of fun
Nicky Pike (21:23):
There. Well, I mean, you are a great teacher. You got spring office hours. I mean, you're teaching people every week about Java. On that note, when we kind of call back to this audio quote about the floor that he was talking about, do you still think the bootcamps have a purpose?
Dan Vega (21:35):
It's so weird that this, we don't even think about this COVID era. I forget about it sometimes. I don't know about you, but there was this era where we just didn't leave our houses, and I think that changed so many things. One meetup groups. We have a Java user group here in Cleveland. They used to be really well attended, and then COVID happened, and then everybody started working from home and suddenly nobody was going downtown. So they didn't want to drive downtown for a user group meeting. And we've all kind of been subjected to Zoom calls everywhere and remote meetings and such. And so the bootcamp kind of did the same thing. It had to go into kind of a remote world, and by the time it came out of that, it couldn't stand that anymore. It got acquired and then I think it officially shut down maybe a year ago or something. So I don't know, because conferences don't even do really well here in the US as opposed to something like Europe.
(22:32):
So conferences aren't even well attended. I don't know what the answer is. There is a place for trying to get into this industry without having to take a four year degree. Not everybody needs a four year degree. Now, I will say there are some brilliant people going to Stanford and MIT and working on mission critical things. That is not what I work on. I work on silly web apps, so there's still a place for that. But there is a place for educating people who want to change careers, who want to get into this industry and not spend four years of their life trying to do that. I don't know what the answer to that is, but yeah, there's still a place for it.
Nicky Pike (23:15):
I agree. And that's where I think something like the software or the fundamentals of software engineering gives people that good base. Is this something they want to change into? If they get into that and it totally burns their brain, maybe it's not for them, but if they get into it and interest them and they find themselves searching stuff on the web, then maybe you've done the world a favor by getting people that might not have thought about it into something that they weren't sure about. So you're arguing right now that fundamentals are, they matter more than ever, but everyone's using AI tools and this includes you. So let's dig into that a little bit. You said something in our prep that really stuck with me and you said you fear that we're building a platform of masters with no apprentices. What do you actually mean by that and what does that mean for the industry here in five
Dan Vega (23:54):
Years? I don't have any data to back this up. This is just kind of my feel for the network that I'm in, the communities that I'm in, the people that I talk to. But I feel like as AI started really coming on in the last couple of years, we started to realize that, oh, okay, the ceiling is raised as we talked about before. So these senior engineers who really know what they're doing, they could take on more work, they could be way more productive.
(24:22):
So maybe we don't need as many junior engineers, so maybe we're not hiring as many junior engineers. Maybe we've let some go. And the problem with that is what happens when these senior engineers go away and there's no more junior engineers left to become these senior engineers. So we have all these masters with no apprentice. I learned from everybody that these great teams that I've been on, that's one of the great joys of my career, is being able to learn from all these people that I've worked with. And if those people are no longer around to learn from these masters, then where does that leave our industry in 20 years? So I fear for that, but I'm also out trying to make sure that doesn't happen. One of the ways that we can do that is make sure that if you're a senior engineer at a company and somebody's telling you this, like, Hey, we are letting three people go.
(25:17):
We're giving you a raise. We're throwing more on your plate. My pushback to that would be I can't do the work of three times more of three engineers that you let go. I can be more productive and take some of these mundane tasks off my plate and start to solve some of the real problems that have been lingering around here for a while. I still need those junior engineers, and I still need to be able to teach them that if I get hit by a bus or I'm gone one day, they'll be able to replace me here and you need them too. So I think part of this starts at the top from leadership to senior engineers to make sure that we're not making this mistake of just, Hey, we have these tools, now let's get rid of all the junior engineers and just let the senior engineers do more work.
Nicky Pike (26:04):
Yeah, I believe that this is all part of the hype cycle. You've got
(26:08):
Large companies that are pressing this because again, look at who's talking and what they're wanting to push. But yeah, it's very shortsighted. I think it's more PR than reality because going back to the DIY scenario, we can't say just because we got copper wire and sockets in Home Depot, now we don't need electricians anymore. If we were to actually do that, the world would burn, and it is not going to be 10 years, it's going to be three or four or five years. Because a lot of those seniors are getting to the age where they're going to start rounding out, they're looking at retirement. And if you don't have anybody to fill 'em up, and let's especially look at this in the AI lens to say, Hey, there's this AI code written out there that's not perfect. It's not good. Yes, AI is going to improve, but there's going to be a lot of tech debt that's created by this, and you're going to have to have somebody take that on.
Dan Vega (26:54):
I saw an article from just last week Salesforce saying We regret laying off 4,000 people in favor of ai.
(27:02):
Of course you do. Again, it always comes back to money. You thought you could just get rid of a bunch of people, put some tools in place, and everything's just going to continue to run the same or even better. And that isn't the case. And I don't know, man. For me, it always comes back to every enterprise job that I've been at. We've never had enough good developers to work on the products that we're trying to build. And so now you're telling me like, oh, what? We're just going to get rid of people. We always have this backlog of things that we're trying to build and we never have enough people to do it. And so for me, again, this brings in productivity, shove some of those things that I don't want to do off my plate, allow me to focus in on the big problems and let's make our products better.
Nicky Pike (27:47):
Well, and it's counterintuitive when you think about it, Dan, because when you look at the data, it's the junior developers that are using AI tools more, and it's a fact. It is a fact that AI is going to be coming into companies. There's no real stop in it unless something catastrophic happens. But it's the junior developers that are using these tools, but they're the ones being cut. That doesn't seem to make sense to me.
Dan Vega (28:09):
I will put everybody into this bucket. We are definitely at a fork in the road with these tools in place. You can continue to learn and continue to master your craft and go down this road and have a long career, or you can blindly accept everything that our machine overlords are giving you, and eventually you're going to run out of luck. I think you need to understand this stuff. And so from the title of the book, the title of the book was from coder to engineer. Somebody asked me a good question. They said, when do you think somebody is a coder? When do you think they get to be an engineer? And I think for me, it falls into the software development life cycle. You can today pick up a tool, natural language, turn it into code, put it out on the web. Cool. For me, especially in the enterprise, we have this whole development life cycle where, oh, guess what?
(29:03):
We're going to build something. We're just not going to start building it today. We're going to talk to stakeholders and figure out the requirements and put together planning documents. We're going to put a plan together before we write any code. We're going to talk with different resources like our architects, our database administrators. Let's have a plan for this thing that we're going to build. Then we start to build it out. Then we understand when goes into production, who's going to fix it, when it's broke, who's on call? What are the security implementations? What are the performance things that we got to look at? We understand all of these things because building good software is not about writing code. It's about this process of building software. And so I think that's when you move from a coder to an engineer, when you understand the process of building software that kind of moves you from, Hey, I've just hacked some code to being a software engineer.
Nicky Pike (29:59):
Well, I mean, let's look at this objectively and let's just say, let's take the hype out of it, but is there really any objective difference between what we've seen in the past? I mean, we used to call exactly what you said, the coders script kitties. They were guys that went in, they just copied code from other people. They went on to stack overflow to answer their questions without trying whatever Stack Overflow told them. It's kind of the same thing. Is it really just a hype cycle that makes the difference here, or is it really the capabilities that we're seeing coming out of AI that makes the difference?
Dan Vega (30:28):
So you say hype cycle, and I hear a lot of people say that AI is under hyped or overhyped. I don't think it's being hyped enough. I am all in on some of the capabilities of it. I love being able to see the value in something. I think it's just going to keep getting better, but it doesn't replace me. I'm still in control of all this. One thing I love to say is you are the pilot, not the passenger. So we are not on this ride to just accept where we're going. You get to control, you are flying this plane, and you have to remember that anytime you're using these tools.
Nicky Pike (31:01):
And I think that's the key point is it's about perception and what your expectation is. So AI is another tool, and it is an extremely powerful tool, but if you treat it as a sage, you're going to fail. You're probably going to have a lot of problems. But if you treat it as a tool and you use it to augment and amplify what you do today, it's incredibly powerful. But we're seeing the loudest voices on both sides of that spectrum are the older ones communicating, which is really why we created this channel, was to talk to all the people that are out there that are just trying to make sense of this shit without having to listen to the extremes of both ends of debate. So that's one of the reasons we're glad you're here. It's
Dan Vega (31:36):
Good to be here. Yeah, it's interesting times. Again, I think I've always just been a half glass full kind of guy. So that's the way I look at it these days.
Nicky Pike (31:44):
Well, when we were in prep, you told me this story about how you watch somebody vibe code an entire app on Kubernetes, and you said your reaction was, well, that's using a sledgehammer for a nail. What else are you thinking that developers are overcomplicating? Because AI makes it feel easy?
Dan Vega (31:58):
I think we all just get caught up in buzzwords and technologies and things that we don't really need to. Like I said, somebody vibe quoted an app and they were telling somebody that they were going to throw this on Kubernetes. I'm like, how many users do you have? He said, five. I'm like, nowhere near ready for that problem. I saw this early on in my career too. People were like, well, Twitter's using this kind of document database. I'm going to use that. I'm like, well, how many users do you have? You have a thousand or a hundred thousand. That is not a problem. Well, I'm trying to kind of future proof this. I'm like, no, when you get to the scale of Twitter, that is a good problem to have and you'll be able to solve that problem you get to it.
(32:40):
But yeah, I think the things that I see, especially without understanding things, it's like getting things to production. How do I do that? So I think we need more education around, okay, you vibe coded this app. What type of app is it? How do you get this thing into production? What are some things you should be worrying about? Especially security. Don't be leaking credentials or putting credentials in code. How do I scale this thing when I do need to get to that point? But those aren't things that scale isn't something you need to worry about right away.
Nicky Pike (33:12):
Alright, so I mean you bring that up because use the sledgehammer for the nail and we've all heard their horror stories. We've got citizen developers that lose all their work. They weren't taught version control or you've got developers that accepting code that they can't explain. You often talk about failure is one of the best teachers. It taught you a lot of things. Now when you're looking at the person that's saying, Hey, I'm going to throw this on Kubernetes, is that not one of those examples? Let 'em go in and experience the pain and figure out that they don't. Maybe that'll improve them. Or is that something that you think is going to frustrate and maybe convince people that this isn't the right line for 'em?
Dan Vega (33:47):
Yeah, that could definitely be a deterrent. Like, Hey, I just want to push this thing in a production, but you're giving me the world of Kubernetes and all of this configuration that I have to do just to see this in production.
(34:00):
I'm thinking back to when I got started writing websites. That's really what got me into programming was this. First off, the problem solving the creativity. There's no one path to do this, but I used to love the web. I would write something in HTML back then we had ft p. I'd ftp it up to a server, but a push of a button and there it is on the web, I could send it to my mom, I could send it to anyone and they could see it. And that really excited me. And so I'm thinking back to if I spent days and days trying to get this simple thing out on the web for other peoples to see, yeah, that probably would've frustrated me a lot. Maybe I would've learned Kubernetes, but why would I need to know Kubernetes is another question. I don't need to know that as someone who has just a simple application out there. So yes, the simplest path to production I think is probably the best. But yeah, you don't know what you don't know too, which is part of the book. Part of the book was, Hey, you don't know what you don't know. Let's try and teach you some of these things that you may come across.
Nicky Pike (35:07):
Well, so I mean we're talking about, okay, here's some of the pitfalls. Here are the things you can get into. But your book is trying to prepare people for all of this. So we've talked about AI and we've said that AI experienced developers, this is something that AI is absolutely a force multiplier because they know what to look for, they know what they're doing.
(35:25):
But what about the people that are just starting up? AI is out there, it's something that people are being told that they need or have to use. Their companies are saying this is something that we're bringing in. What about those people that are just starting out that haven't the same instincts that Dan Vega has?
Dan Vega (35:39):
Yeah, I'd say use it as a learning tool. So just as you mentioned, if I was trying to solve some problem, maybe I write a class, maybe I write some methods and I couldn't figure it out. I would scour the internet for what am I doing wrong? What is the best way to do this? 20 years ago, there wasn't YouTube, so I couldn't watch a video. I had to find some article on this. And after all of this kind of trial and error and failure, I got that aha moment and I fixed it. And you know what? That kind of failure leading to that aha moment, I didn't do that same thing the next time. And so I would say, you've got to take the same approach with ai. It's just going to accelerate that, Hey, I got to solve this problem. Let me write this method.
(36:22):
Instead of asking AI to do it, try it yourself. Go through and try to write this method. If you fail on it, guess what? Now you have a pair program, you got to buddy to help you out. Hey, what I'm trying to write this method to accomplish this, it's not working. What am I doing wrong? See the result, but don't copy and paste the result. Write that result out. So you get that kind of mental, the mechanics behind doing that. And as long as you can use that as a tool to do this same thing, the fail and get that success feeling, then I think you'll be in a really good position. And then one thing I always did was I always route code to get it to work first. Now it works. Now I want to improve that, but I didn't have the institutional knowledge 20 years ago to go, how do I improve this?
(37:09):
Maybe I go into a code review and ask some team members, how do I improve this code? Is there anything you would do different? Now you have somebody to pair a program with like, Hey, this thing works, but do you have any suggestions for it? And maybe the large language metal comes back and goes, Hey, you're doing a bunch of business logic in a controller. That's not where that goes. That should be separated out into a service layer or a repository. So you can really get this back and forth and just accelerate that learning instead of the five to 10 hours I was scouring the corners of the internet. So it's still the same process. You just have different tools that enable this to go a little bit faster.
Nicky Pike (37:49):
I think that is sage advice. And if nobody takes anything else from this episode, I hope they take that part right there, which is, you just described the difference between using it as a tool versus an easy button. If you use it as a tool, you're going to learn you're going to get better outcomes. If you use it as an easy button, it may work, but you're possibly setting yourself up for lots of problems down the road.
Dan Vega (38:09):
And again, I think there's a crowd out there, and this is the ones you're going to hear from on social media that think they can just cheat learning how to become a software developer. You cannot can produce some code. You can produce some things at work. 1% of you may produce some things that make a ton of money, but for the bulk of us, you cannot cheat learning this craft
Nicky Pike (38:31):
Well, and that brings to mind, again, we see this in different industries and technologies. I was reading just the other day that the guy had a problem with his motorcycle. One of his sprockets went out and they wanted like $1,700 to replace this sprocket. And he's like, I've 3D printed this and it only cost me 17 bucks. And I'm like, I can't wait. I hope you post video of you putting that in and actually going down the street the first time on it.
Dan Vega (38:54):
Oh yeah, yeah, yeah, that's true. But that would be cool. Hopefully we get to that point. I mean, I asked Chad GBT how to fix my hot water tank this morning. So that worked out.
Nicky Pike (39:06):
Yeah. Well, let's go back and let's define terms. I think this is something that we differ on. So let's define for everybody that's listening, vibe coding in your take, because you go back to the original idea of it. I've got a little bit different idea and we can discuss that. But what is your take on what vibe coding actually is?
Dan Vega (39:24):
Yeah, this came from a tweet from Andrej who's one of the founders of OpenAI. He worked at Tesla and X, and he basically went through and said, this is a way to take natural language and turn it into code fun for throwaway weekend projects, but nothing serious.
(39:42):
And I'm on that camp, I'm in that camp because I think there are different terms we could talk about for other things that we do with AI tools, but for vibe coding, it's, Hey, I have an idea and I want to turn it into code. I want to turn it into something that works. And I think a good analogy of this is, alright, if you're at your house and you want to build an application to budget your finances for your household, this is cool. This is an idea that you have that you want to do. You don't want to pay for some monthly software. God knows we have too many monthly subscriptions that we all have to pay for these days. So I want to get rid of that. I'm going to build my own budgeting software the way I see fit, and you can go off and do that.
(40:24):
But let's say that you work in an enterprise and you want it to vibe code some software that runs the entire payroll for the entire company. They could not be more extreme consequences on that side of the house. If you screw something up over there, people don't get paid. The whole company goes down. If you screw something up in your monthly budgeting app for your family, not a big deal. You can fix it. So for me, vibe coding is just that lowering the floor, allowing somebody to take an idea, turn it into an MVP, some of those MVPs might even turn into real products. But really just giving someone that has that idea, the ability to get in and then as you said, hopefully build on that and start to learn some of the fundamentals and build on that application.
Nicky Pike (41:12):
Yeah, I see it a little bit differently, and I'm not going to argue because the original definition was the original definition, but I see vibe coding as the non-technical creating software building. They're creators of something that they don't fully understand. Now that can be through conversational language or it can be through other methods. We actually, our community manager, Marco, created bot to help him with Discord and being able to manage Discord messages. And he started out with conversational language. I introduced him to how to write A PRG and how to spec this thing out. And I'm going to get into that. This is something that I think you believe in, but to me that's still vibe coding because yes, he's learning, he's going to get more educated on what the process is and how to do it better, but he's never going to be a software engineer, nor does he aspire to be. And on your enterprise scenario, I do think that you kind of took that to the far extreme scenario. I don't think that a lot of people in the enterprise, we do have customers. That's one of their priorities. We want to take domain experts and allow them the ability to create things that work for them. I think they're not creating payment systems, they're creating bots. They're creating automations to go and do things. And I think that's still vibe coding, but I think it's a vibe coding that does have purpose in the enterprise.
Dan Vega (42:22):
I think we're on the same page. I'm not arguing with that. And yet, I think product managers probably make some of the best vibe coders, right? Because they have institutional knowledge of things and how things are working. And they probably had ideas for projects that they just couldn't get off the ground because they don't have enough engineers in the company, or it
Nicky Pike (42:41):
Sits in the backlog for six months and they get
Dan Vega (42:43):
Exactly.
(42:44):
Yeah, no, I think we're on the same page there. I think the difference that I would say is that when it comes to experienced engineers or even any engineer, I guess, and again, engineers can vibe code too. I think when it comes to experienced engineers, I look at it as not vibe coding as more as contextual coding, being able to augment an LLM with the knowledge that it needs to solve that particular problem. There's a term out there called context engineering now, and I think that's the equivalent of it on the engineering side, because we have that institutional knowledge. We don't just go in and start vibe coding, asking it to build something. We have a process for doing that. And that's that engineering mindset, that's that software development lifecycle. And again, I am no gatekeeper of anything. I'm just trying to say these are the kind of buckets that I think of when it comes to these things.
Nicky Pike (43:44):
And I think we agree on that because I do think it's a natural progression. I started out vibe coding. I started out, Hey, conversational the same way I started out writing BS scripts before I got into other types of technologies and doing things. I'm now getting into where my first thing that I create when I want to do a new project is going to be specs. I'm creating all these specs and steps of how I want it to do it. Does that make me a software engineer? Absolutely not, right? I do not have the same skills that Dan Vega or Deshaun Carter or others out there have, but it's a progression step. And that's maybe as far as I ever need to take it.
Dan Vega (44:18):
You sound like an engineer to me, Nicky.
Nicky Pike (44:21):
No, no. It all falls apart. When we jump in and we start talking complex problems, that's where I come and ask you and say, okay, Dan, I have done this and you have witnessed this. I've done this to you. I've gotten this as far as I could take it. Where am I screwing up? And that's where I need the real engineers to come in and help me out.
Dan Vega (44:38):
But what you're doing there, like I said, is part of that software development lifecycle. When we build software in the enterprise, we don't just go start writing it. There are many meetings that take place with stakeholders. We come up with a plan. When we have that plan, then we can start writing code. So I think that anybody, whether you're an engineer, a vibe, coder, whatever you want to call yourself, it doesn't matter to me. If you're building software with large language models, one of the best tips that I have is come up with a plan first. It doesn't always need to be exhaustive. You don't need to spend a week writing a PRD or even know what A PRD is, but come up with a plan. And one of the things that we do as software engineers is we take big problems and we break them down into smaller problems.
(45:27):
If you can gain that ability, that skill, now I can create a plan that says, here's the thing I'm trying to build, but I'm not going to ask you to build this entire financial HR payment system in one swoop, right? I'm going to break it down into these smaller steps. And if you put that into some kind of document and hand it off to an lm, now you have tasks that you can go off and build. And oh, by the way, that comes back to when we're building software, we want to build something that's incremental. So we create GI branches and we say, Hey, this is the feature I'm working on. Once that feature is done, now I can start on a new feature. So this is part of the lifecycle. If you can take some of those things that we do, especially in the enterprise into your solo project, I think that will really help out
Nicky Pike (46:15):
Well, and staying on the same lines of progression, one of the things that we talked about in prep that kind of made me laugh is that there's a section of the book that you wrote on career management. You said it was one section that you were absolutely dreading to write, but when you got done, it became your favorite section. It really was. What was the one piece of advice that coming out of that you wish somebody would've told? 25-year-old Dan?
Dan Vega (46:38):
I think when I got started, it was, Hey, I'm going to learn how to code. I'm going to code, code code until I'm either done and retired or I'm going to turn into a manager. And that's my career. And I've since learned that, okay, that's not the case. There are many cool and exciting paths in software. If you really enjoy the craft of writing code and problem solving, you could become like a senior engineer and lead teams. You could become an architect. You could become a project manager to help deliver these products. You can get into developer advocacy if you enjoy teaching and inspiring others. You can get into entrepreneurship if you want to learn how to code to build your own products. There's so many paths that we can take in this industry. I didn't know that I thought it was code or be a manager.
(47:23):
I never wanted to be a manager. I'm not a good manager. I enjoy writing code and problem solving. So I wish that somebody would've told me that early on because once you understand the different paths out there, now you can start to line up your career. If you don't know any past, you're just going to keep working, right? And learn whatever somebody tells you to learn. But if you know that, hey, in seven years my buddy Nate, I want to be an architect. Well, how do I get to that point? So we walk backwards from that goal and say, in seven years, that's what I need to be doing. What do I need to do in year one through three, three to five, five to seven? And then part of that is, okay, if that's my goal, now I can start to deliberately acquire skills instead of all these shiny toys that everybody's telling me that I need to learn. I want to be an architect. These are the things I need to learn.
(48:16):
Because I think one of the things in our, especially now, man, there is just so much out there. And once you come to grips with, you cannot learn everything. And I'm telling you this, I cannot learn everything. Nicky cannot, nobody can. It is just the reality. And once you understand that, you'll feel a little bit better about yourself. I have a deliberate skill acquisition. These are the things that I need to be focused on if I want to get to that goal of being an architect in five to seven years. I really enjoyed putting that together because those are things nobody told me. It was just keep learning code and whatever comes up, whatever framework comes out, learn that thing. Right? And that's not the case. You got to be very deliberate with
Nicky Pike (48:56):
This. Well, and that's the whole premise of the book because no matter which fields you take in this industry, there's still those fundamentals that you've got to have. And I'm going to quote you, I remember a talk one time you said you wouldn't write an indexed HTML file without having a get repo done on that. What else are out there? What are the obvious things that you think some of the new guys are forgetting or they're just not doing because AI makes it easier or they make 'em feel
Dan Vega (49:21):
Optional? Yeah, I mean understanding some of the fundamentals of Git, I would say. We talked about reading code, the ability to read code and understand unfamiliar code bases are really important documentation. So being able to write documentation so we're not just writers of code. I think one of the easiest ways you can be helpful and contribute on day one at your job is by giving your perspective on certain applications. And what I mean by that is everybody's been there for five or 10 years and everybody's seen all the documentation and all the tests, but you have a fresh perspective on this. You can go through the docs and say, this really doesn't make sense anymore. Or I look through the tests and we're missing a bunch of tests for this part of the code base. Giving your fresh perspective on that and being able to write documentation and heck, you can use AI for some of this.
(50:15):
Writing documentation, writing tests, giving that fresh perspective. I dunno about you, but I always wanted to be contribute early on when I get to a job. I don't want to sit through two weeks of onboarding and then two weeks of training on this. I want to help out. You hired me to help, I'm here to help. And so I think those are ways that you can get started right away. And then when it comes to code, just kind of understanding, I mentioned being able to work in a team environment. It's really nice hacking on side projects on your own. You get to pick whatever technology you want. You don't have to deal with merge conflicts. It's all fun and games. But when you get into a team environment, those things are much different. There are already languages and frameworks that have been decided. Don't throw up arms in that they have been decided on for reason.
(51:01):
Be okay with that. Understand how to work in a team environment, understand that process for getting an issue, working on an issue, submitting a pr, understand what the code review process is. All of these things become much more important, especially like the code review process. Hey, I don't care how we are getting code into production. If you wrote one line and your machine wrote your LLM wrote 10,000 lines, fine, it doesn't bother me. But when you get into a code review, you better be able to explain some of those decisions whether you made them or not. If I ask you why did you make the decision to do this here? You can't come at me with, well the large language model wrote that. No, you need to be okay with it. You need to understand it as long as you do, then we're good. And one thing large language models are not good at is deleting code. If you can delete code even better.
Nicky Pike (51:54):
Well, and that's a key portion right there is even if you use AI to help write the code, it doesn't remove the accountability for it. And I love the way you're bringing up the pr. You got to be able to explain why it happened because ultimately it's still your code, right? Whether the LLM wrote it or not, it's still yours. You own it.
Dan Vega (52:10):
Your name's probably on it in Git. So,
Nicky Pike (52:13):
Alright. So one more question before we get into, we're coming up on time. So one more question before we get into the predictions here. So for a team that's just starting out in this, they're getting their AI journey, maybe they're being impressed by their leadership to start adopting it. What do you think they should try first? What are the traps that they absolutely need to keep an eye out for?
Dan Vega (52:32):
Man, it's so tough of a question to answer because everybody, it's asking a team of 20 different developers, which IDE should you use, right? Everybody kind of has their own preferences.
(52:45):
And I often say in my YouTube videos, I'm like, Hey, I'm going to use IntelliJ here, but you should use whatever IDE you are most efficient in because that's the best ID, the best I ID is not intelligent. It is for me, but the best ID is the one that makes you most productive. Maybe it's a command line and that's what you should be using. So I don't know what level of productivity you're at now and where you're trying to get to, but if I would say don't jump in the deep end, you probably are not opening up five different terminal tabs using cloud code and GI work trees that I'm using right now. Maybe it's just what do you use now if you use VS code or IntelliJ, maybe you're just adding some intelligence, some auto completions, maybe adding some like, Hey, write this method for me or explain this for me.
(53:35):
That's kind of one progression. It really depends on what you're trying to do. I would say don't try and jump into the deep end. Andrej Karpathy we were talking about before, I had another really great tweet last week and he's really smart. He said, I've never felt more behind as a programmer. And I was like, wait, why are you saying that? And he said, because I hear all of these things out here are supposed to make me a 30 times more productive, but there's so many things to learn. I can't learn all of these things. If you look at Claude code, there's, oh, we have MCP and skills and custom commands and slash command. There's all these things that you're being told that you need to learn. You don't need to learn all of these things. You got to pick one and incrementally improve on that if you want to keep getting better at it.
(54:19):
And I agree with him. Again, it comes back to don't let social media influence you into needing to understand all of these things. Pick the tools that work for you that are where you are on your journey. And I think one of the things I do in my videos all the time is if I can just learn one more thing, one more thing every time I make a video, if every project that you're on or every week or every sprint or whatever that cadence that is, pick one more thing that you want to learn that week to improve your skills. And I think you'll get to where you need to be.
Nicky Pike (54:52):
Well, and maybe it's not even code generation, think about the other things. To your point, it's documentation that thing that everybody needs to do, but nobody likes to do. Right? Except for maybe Dan Vega, but
Dan Vega (55:03):
I love writing docs.
Nicky Pike (55:05):
But look at the smaller things that can help you and try to cut out the mundane that may give you the productivity while still allowing you to do the code that you want to do
Dan Vega (55:13):
And tests. I know we probably all have like, okay, go ahead and write some tests for me. One thing I've seen a lot of lately is, okay, go look at my code base. Yes, my code coverage is 80%, but are there any edge cases that I'm missing? A lot of the time, the things that we miss, we write our tests and we write 'em for the happy path. Everything's pixel, dust and roses, right? Everything's going to work out okay, but can you look into the future and see any edge cases that I'm missing? And so that's a really good way to kind of contribute right away too, is kind of catching those edge cases.
Nicky Pike (55:49):
Excellent. Excellent advice. Alright, so first the prediction. We end every episode with a prediction, so we're going to jump into that. It's not the far future, it's actually happening now, but we see AI in every IDE, it's in every pipeline and we're starting to see it in code reviews. Paint me a picture of what you think. What does the day-to-day look like for developer who knows their fundamentals that follows along with your book versus the ones that skipped them?
Dan Vega (56:13):
What is the day-to-day? The day-to-day is that you have a job still
Nicky Pike (56:18):
Fair
Dan Vega (56:19):
And that really you understand what building software entails. So you've been in some type of position, you understand the software development lifecycle. You understand that building good software is not cloning some screen or simply asking some large language model to build some functionality. There are really great ideas that come from teams. Teams build software organizations, build software. And I think as long as you can continuously learn, you'll be in a good position. I think if you just blindly hit accept one, it's going to be much harder to get new jobs. If you get interviewed and people are asking you questions, if you don't know the answer to those, you're not going to get a job. So to kind of combat that, you've got to continuously be learning. I love this industry that I got into because I love to learn. So I feel grateful for that.
(57:11):
Not everybody feels that way, but if you are in this industry, you better be prepared to continuously be learning. You don't have to sacrifice your entire life for it, but it is something that you'll continually need to do. So I hope for that fact, whether you're using AI or not heavily using AI that you continuously learn. And I think in that case you'll be okay. You'll be in probably the same position we are now. I just think these tools are going to get better, but a lot of the day-to-day stuff is just going to be the same.
Nicky Pike (57:43):
All I heard right there was if you're not following the fundamentals of software engineering, you should probably use your AI skills to start polishing your resume.
Dan Vega (57:51):
Yes. And that's probably not going to get you far.
Nicky Pike (57:54):
Yep. Alright, last question. This is the hot seat question. You've spent 25 years building expertise, you're teaching other people how to do things the right way. You walk into a job and someone hands you eight fresh computer science grads who have never written code without AI assistance. What does week one look like with software drill instructor, Dan?
Dan Vega (58:15):
They're computer science grads
Nicky Pike (58:18):
And they've only used AI to write code.
Dan Vega (58:20):
Oh. And they've only used AI to write code. Yeah. I'm going back to the bootcamp. I'm making sure we have the fundamentals down of command line of learning, GI of learning some of the different workflows within Git because everything kind of builds on that base layer. So I'm making sure they know that. And then whatever language we're in, if we're in Java, I'm making sure they understand the fundamentals of the building blocks of the Java language.
Nicky Pike (58:44):
Perfect answer. I love it. Alright, well tell everybody, you got the O'Reilly book out. They can get it out on Amazon, correct?
Dan Vega (58:50):
Yeah, you can get it on Amazon, you can get it on the O'Reilly platform. So if you sign up for O'Reilly, you can get our book and you can get many other books, which is really great. You can learn more about the book and the podcast at fundamentals of sw.com. And if you want to learn more about me, Dan vega.dev, my socials are on there. Feel free to reach out.
Nicky Pike (59:10):
All right. Well everybody go out there. Check out Dan, make sure you get the book, learn the fundamentals. And as always, if you like what you see, hit the like and subscribe button and we'll see you next time. Oh, I did forget one thing there. Dan, can we consider you a full fledge member of the [Dev]olution?
Dan Vega (59:26):
Yes, absolutely. Nicky, you are a good friend. I appreciate you having me on the show and I enjoyed talking with you.
Nicky Pike (59:33):
Alright, same here. Well, we'll talk to everybody soon. Thank you much.
(59:37):
Thank you for listening to [Dev]olution. If you've got something for us to decode, let me know. You can message me, Nicky Pike on LinkedIn or join our Discord community and drop it there. And seriously, don't forget to subscribe. You do not want to miss what's next.