John Crickett (00:00):
But the AI is there as a coach, as a mentor, as a guide. So use it right, I think you're going to be fantastic. Use it long, you're just kidding yourself. You depriving yourself of any learning.

Nicky Pike (00:10):
This is Devolution, bringing development back to speed, back to focus, back to freedom. I'm Nicky Pike. Okay, so everyone's talking about how AI is going to write all the code. You type a sentence, you get an app. The machine does the building and the software engineer packs up and goes home. Here's what nobody wants to sit with. If code was the whole job, then sure, we're cooked. But what if writing code was never actually the job? What if it was the smallest, easiest part and we just told ourselves it was a whole thing? My guest today has spent 30 years in this field and two and a half years watching thousands of engineers try to level up. He's got a take on what AI is really exposing about the way that we've been working. And I don't think all of you are going to like it.

(00:54):
So let's go ahead and get into it. John Crickett is the founder of Coding Challenges where he's helped a huge community of software engineers get better by building real software instead of just reading about it. He's been building since the '90s. He shipped AI products since before it was cool, and he's got strong opinions about what actually makes someone an engineer. John, welcome to The Devolution.

John Crickett (01:16):
Thanks, Nicky. Thanks for having me on.

Nicky Pike (01:18):
Well, I'm going to go ahead and jump right into this. I want you to take us all back to 1995. You were in a university and you went to study artificial intelligence decades before any of this made the magazine cover. What pulled you towards AI back then and what did you actually end up doing with it, John?

John Crickett (01:35):
So my interest in AI started, I think, closest to 1991. I can't quite remember the exact year, but I was lucky enough to grow up living partly in Brazil. And I went to an American school there. That led to a lot of confusion being British with my parents trying to teach me English spellings of words. The teachers at the American school who were Brazilian and doing American as a foreign language, trying to teach me a mixture of what they though was right and what was American spellings. And so as a kid, I was very confused. I still struggle with color and meter and center. That tension led to me being sent back to a boarding school in the UK. And at that boarding school, I discovered what to me was heaven. The school had a library that as I now lived at the school, I had almost twenty four seven access to this library.

(02:21):
And I'd exhausted all the school library at my school in Brazil, which was basically the Hardy Boys and Nancy Drew. So walking into this library that had thousands of books was like absolute heaven to me. And at that point, I discovered Isa Kasimov and a few other science fiction likeers like FC Clark. And I was reading those books, of course, I was drawn to the idea of robotics and the intelligence there. And that sparked an interest in artificial intelligence. I also had access to a computer lab and I'd played with computers a little bit before then, but I now had access to a computer lab and I was living at school on the weekend. It learns a lot in England so there wasn't much outside to do. So into a computer lab, these ideas of robotics, programming books, I started programming. I started having these dreams of I was going to write a program and turn this computer into something intelligent.

(03:12):
Bear mind, I was nine at the time and we're talking about a BBC Micro, which I think has 16 kilobytes of RAM. Can you imagine I didn't get very far? Realistically, it was 10.00, 20 go to 10 and other silly kids things that you do like that. But that sparked an interesting software in AI and in trying to take that further. So from there it evolved and I started looking around and I started buying books about artificial intelligence around around 1992, I think. And I started reading more about it. And at that point I started having this idea of studying artificial intelligence. And I tried to do a degree entirely focused on that, fairly limited at the time in the UK. There was one degree. I looked at university for various reasons. It wasn't going to work for me. And the degree didn't really seem to focus on artificial intelligence as I wanted to pursue it.

(04:00):
It seemed to be more focusing on mathematics, which is really a reflection of my naivety at the time because a lot of AI is mathematics. It's linear algebra and matrix multiplication. But hey, I was young and naive at the time, didn't know any better. So I went to a university and did computer science, a university where I could do a lot of AI courses. And that's what I ended up doing from 1995 to 1998.

Nicky Pike (04:23):
So what piqued your interest was Asmnoff, right?

John Crickett (04:27):
Asmoff and Koch. Yeah.

Nicky Pike (04:28):
What was it that actually caught your interest? Was it the robotics part of it? Was it the fact of having this kind of Jarvis type intelligence that could answer all your questions for it? I mean, what really caught your attention there?

John Crickett (04:40):
That's 40 years ago, Nicky. I was nine years old. I

Nicky Pike (04:43):
Can't

John Crickett (04:43):
Remember all the details. I remember what

Nicky Pike (04:44):
Happened last week and then we're going back asking you to go back into the early '90s. Yep.

John Crickett (04:49):
I think it was just a combination of all of these as I was leading them. I've always loved leading. I've lived leading fiction and imagining all these different places. So I got a lot of Wilbur Smith books as a kid. So imagine people trekking through Africa in the late 19th century and all this adventure. After car, Kaiser, Nasmafia and exploring space or exploring futuristic worlds. All of that, it was just these amazing new worlds to imagine and explore. And the idea of these things that were going to be super intelligent and robotics that could interact with us. And I guess also I traveled a lot. The kind of appeal of some of those things I robot, longstanding, bicentennial man. The idea of this robot is a landfill of ages. By the time I went to that school at nine, I'd lived on four different continents, been to five different schools.

(05:38):
I was kind of fed up of not having a friend for more than a year before I ended up living on a different continent to them. So I think the idea of this robot that might be around constantly with me and a permanent friend seemed a bit appealing, which sounds kind of sad, but on the other hand, I was incredibly lucky to grow up and see the world and have that much traveling. And so yeah, can't complain.

Nicky Pike (05:59):
I think all of us at one point kind of dreamed about that. And on this topic, one of the things that I found very interesting was, and I'm not going to say this is where you actually cut your teeth, but it is where you kind of got your start, is with gaming. You wrote a lot of AI players for Quake. You had millions of people that downloaded those, but you also kind of took this long way around when we start talking about software development and everything else. You quit a good job, you built a bread and breakfast search engine before Airbnb existed, and you pitched food delivery to VCs who you said actually laughed you out of the room at the time. Now, when we were talking about this, you said that your businesses kept dying of, in your words, an imagination failure. Walk me through that stretch.

(06:44):
And what did those years teach you that you're still kind of using today?

John Crickett (06:48):
That's two very good questions. You might have to remind me to come back to what it taught me. I graduated in 1998, kind of the beginning of the dot-com boom as it was really at least kind of getting notesable over here in the UK. Everyone's doing a startup. I joined a very traditional engineering company and I learned a lot of great things there. It was a really good goal with some great people. And I'm really glad I had that opportunity to learn in that environment for a year or two. But I got itchy feet. I'd done these quake bots and I'd experienced people all over the world downloading them, seeing millions of followers. And now I was building software that was going to power a charity doing mail-outs to people. It wasn't as exciting as gaming. It wasn't as exciting as these dot coms that you hear going to the moon where I'm sat there on a fairly modest sally and reading about success of Silicon Valley and this contrast.

(07:41):
And some of the startups that were kicking off in London a well at the same time. So I got itchy feet and I'd always had this plan I was going to start my own business. But yeah, a year or two into that, I decided that I had to pursue my own business and would go and do that. So I quit the job that I had, decided to go and do that. Decided that actually I needed a bit of money for this. Credit cards are like to buy a laptop and led you to a company which was somewhat expensive back then. So I did a bit of contracting, used that to kind of bootstrap things, started a few ideas, built this Ben & Blitz search engine. Didn't really have the imagination to think of something like Airbnb. Built that, made it successful. It was turning over a few tens of thousands of pounds.

(08:23):
I'd say hadn't had the imagination to go much further, but it did get successfully and considerably more successful later because somebody else reached out to us and said, "Hey, I want to buy that." And we were like, "You want to buy this? How much for?" And they were like, "I don't know, six, seven figures." And we're like, "What the hell? What are we missing here?" So imagination failure. Somebody else saw the opportunity in this thing that we'd built that we weren't seeing at the time. So great person. We went and had lunch and a few beers with them and became friends for a while. Didn't sell it to them, instead built it up ourselves and made it moderately successful. But along the way, we explored these other ideas that we were thinking, well, this is good. We can build it up. We're now doing a reasonable seven-figure turnover, but it's in travel, so most of your money is actually then being paid onto the hotels or other things that you're booking.

(09:17):
It's not a high margin. So we started thinking about other areas, where can we expand this? Whatever opportunities would there be? How is the internet going to transform society? And being that, I'm not saying we, it's my brother and I, that building the business together by this stage. Well, we're young guys doing a startup. We have a lot of takeaways. Wouldn't it be so much easier if we could order our takeaway on the internet? So we've put together a pitch for this, tried to work out how we'd do it, tried to work out what the fulfillment was because in those days, most takeaways didn't have an internet connection. We asked around and we found that many of them had a fax machine. They had the ability to accept orders by fax. So we started looking at what would the infrastructure be? You took an order on a website, you take payment, and you fax the order to these places.

(10:01):
And we went and pitched that, called it takeaways online, pitched it to VCs and got laughed out the building. I think this was in 2002, 2003 of people saying nobody's ever going to order food online. It's not going to happen. So we were a bit ahead of the curve there and maybe didn't believe in it enough because obviously we've got DoorDash now, Uber Eats, many of us are all doing it online just eat in the UK that are all exactly doing that business as we imagined, but 20 years later.

Nicky Pike (10:30):
Well, so you got into, you wrote these applications, you wrote these business plans. Do you think you were just too early? Because like you said, the internet wasn't a huge presence like it is now. Were you just ahead of your time or was there other aspects that you thought kind of led to that not being the right move for you guys and the reason the VCs laughed you out? I

John Crickett (10:50):
Think we just didn't have that, and I guess it's a fine line between confidence and arrogance. There's an incredible confidence or arrogance depending on how you view it from a lot of the really successful entrepreneurs. They just won't take no for an answer. They believe so firmly in it that they keep pursuing it long after so many people have said no. I think partly there's a culture in the UK that we don't really follow that if enough people have said no. And then also that bit of culture of go to university, get a good job, way at the clear ladder. So I think some of those cultural issues were kind of held us back a little bit. After you've had so many nos, it's like, okay, maybe we should just do the same thing everyone else is doing, get a good job, build it up, or at least build a safer business and do the consulting, build that up, build up the thing that's already working a little bit and pursue that.

(11:44):
So yeah, I think a lot of cultural stuff. And fortunately I think that's changing. I think that 20 years later we've got a lot better entrepreneurship here in the UK. We've got a lot better funding environment. There's far more VCs. And again, there's still a massive difference between Silicon Valley and the UK. So back at the time you'd read about a seed round in Silicon Valley being 500K. A seed round over here, you'd be lucky if you got 50K. Now again, there's still that disparity. People are now talking about seed lounge over here of one or two million, maybe 20 million. If they're doing well, you see crazy numbers in Silicon Valley that are, again, 10 times as high.

Nicky Pike (12:25):
Well, and I think you had the expertise to go in and build these applications. You had these ideas, but you had the knowledge, you had the schooling to go in and start building these. And I think this kind of leads us into what we're talking about with the challenge now. So when we're talking about AI where AI is helping basically anybody build, that is the challenge that I want to talk about because basically everybody's building right now with AI. The technical barrier to that is gone. We can go on, we can get with AI, we can describe an app and we can watch it appear. So that leads me to think that we'd be drowning in new software. And I think we are going to see a huge plethora of software coming out, but at this moment we're not. And in 2025, the share of companies that walked away from most of their AI projects, John, before they ever reached production, that jumped 42% up from 17% the year before.

(13:16):
That's from the 451 Research's Voice of the Enterprise Subway that was published by S&P Global Market. That was more than a thousand companies, and we saw more than double in a single year. The building got easier, the finishing the building got harder. Now that companies are scrapping their own projects, you're getting to watch the same thing, but from one floor down with the individuals. People are generating thousands of lines of code, but there's still no product at the end of it. So John, I guess the same question in your world, if it's never been easier to make software, why is it getting harder for people to actually ship the product at the end?

John Crickett (13:51):
Maybe it's just down to the semantics and the words we choose, but building hasn't got easier. That's the myth that I think a lot of people have fooling themselves. Building software has not got any easier. Turning out code and generating code has got a lot easier, but building software is much more than just checking out code. It's what are you going to build? How are you going to build it? How are you going to deploy it? How are you doing it's going to be the right thing? How are you going to ensure that it works? That mostly isn't coding to my mind. Let's take the bed and breakfast search engine. Sure. There were, I don't know, 15, 20,000 lines of code from memory of that. Write in the code was never the hard part there. I mean, it was built in PHP. Myself and my brother did it.

(14:35):
Mostly he did it actually, and he was six months into learning to be a software engineer at the time. He'd just finished a degree in accounting and I taught him to write code. So the coding wasn't the hard part of that. The hard part was what should it be? How do we position this? How do we build something that's useful to customers and that in our market, the Ben & Breakfast would pay to be on there? How do we make it attractive to both of those? And that took months of refinement and iteration and figuring out and talking to people, talking to the Ben & Breakfast owners, talking to people that are going to use it. And even then we got horrendously wrong. We put about 60% of our effort into this really complex search engine so that me as a contractor who was contracting in London to fund this development, I was like, "Well, I want to search by Ben & Breakfast near the local tube station or near a mainline train station or near Junction seven of the M4." So we built all these complex search facilities and nobody, not even me actually used them in the end.

(15:41):
We built all that effort. And I know from the stats that absolutely nobody used it because people realistically just went on Google and went Bed & Breakfast and then a place name. So Bed & Breakfast Coventry or Bed and Breakfast Wells or something like that. And that's how people do it. They landed on a page from Google. They booked what was on that page. They didn't go and explore these complex things and say, "I want a bed and breakfast that's five minutes from this tube station or 10 minutes from this mainline layway station or this motorway junction." So what should we build? And who are we building it for? And how do we make it useful to them? How to make it beeling? That's building software. That's building the right thing for the right people in the right way. That's still damn hard. And that's something that I think increasingly people that call themselves software engineers haven't been doing for one reason or another.

(16:34):
We've been over-focused on learning react, learning list, learning go, learning gin, learning this framework or that framework or that stack or hey, we've got to be able to stand up Kubernetes pods and stuff. Or we've regressed from the things that I remember at uni of software engineering is talking to a customer, understanding the requirements, doing the analysis, figuring out what the problem we're trying to solve is and what a good solution looks like. Solving it and then verifying that solution. And instead we've reduced it all to this coding. And yeah, AR makes the coding easy. Doesn't fix the rest of that. Doesn't take away all that other stuff, which was always the hard bit.

Nicky Pike (17:13):
All right, so I'm going to break this down and I get what you're saying and it makes perfect sense to me. It's like building a house. Framing the house isn't necessarily the hard part. It's the architecture, the blueprints. Where am I going to put the electrics and the plumbing? But what would you say to people that say, okay, you're not wrong, John, but I can use AI for all of those things as well. AI can help me build the spec. It can help me build the blueprint. I just got to know what questions to ask.

John Crickett (17:38):
Try it. So AI can help you build a spec. Absolutely. AI can help you with those things, but we're still back to you sit in front of your favorite AI, whoever that's Claude, ChatGPT, Claude Code, Codex, Junie, Kilo, pick one, whichever you want. It's entirely passive until you say to it what you want to do. So you speak to it or you type in. I want to build a to-do app, something. Great. It'll go off and build your to-do app, but it'll fill in all the blanks about what it does. You need to have thought of, I want to build a to-do app and these are the features it should have. And I want it to be a mobile app or I want it to be a web app, or I want it to be a desktop app, or I want an operating system. All those things actually, choices that you've got to have gone out and figured out.

(18:25):
Either A, what do you want? Or you've got to have gone and talked to your customer or your users and figure out what they want. Now you can go away and you can come back to the AI and say, I'm going to build a desktop app for Mac that's going to do my to-do thing and these are the features and it should be able to export and save it in a database that's online so I can swap between computers and I'm going to have a mobile app and I'm going to support iOS and Android. But you've got to have gone and done all that analysis and figure out what it is to ask it. Otherwise, you say, billmed to do app. Yeah, it'll build you one. Won't necessarily be what you want. It won't be any different to anyone else's. It won't be interesting. Won't necessarily have solved your problem.

Nicky Pike (19:05):
No. I do think that makes sense. Is that what got you into coding challenges? Because I mean, you run coding challenges right now, so you have that front row seat to what engineers are actually wanting to learn. And you said that within the last six months you've seen something shift that fewer people are actually wanting to sit down and get good at the craft. So John just pulled the rug out from under the thing everybody keeps saying the building got easier. No, it didn't. Cranking out code got easier. Building the actual software, figuring out what to make, who's it for, and what good even looks like. That's exactly as hard as it ever was. And he would know. He once poured 60% of his effort into a search feature that not one single human has ever used. Coming up after the break, he gets practical.

(19:51):
How to turn AI into a coach that makes you smarter instead of a vending machine that makes you lazy. Why he calls you the CEO of a company a one and the spicy one? The prediction where John looks at the biggest names in AI and calls out who's still standing in five years. You're not going to see that answer coming. Stay with us. What are you actually seeing there? Is it the blueprinting, the architecture that people are wanting to bypass? Is it the actual coding and using AI? What are you seeing and what do you think that's costing them in the long run?

John Crickett (20:25):
So there's several questions there. I made notes, so I'll try and cover them all. Go back to coding challenges. Coding challenges was all about learning how to build a software better. It's very much on the coding and the architecture. And it came about from, I was learning lists and was looking to start a new business, accepting I'm terrible at ideas. So I was trying to build an audience and be audience led, product led, whichever phrase you want to go for that. And coding challenges was one of these things that I have always learned a new program language by building little applications. So I'd grab a book, learn just enough to be able to do Hello World, and then I'd start wanting to build something more real. I don't want to just write another factorial function. I don't want to write another class that represents a chair in the Halo language.

(21:12):
I want to build something that actually learns and doesn't use force of a tool. Again, not very good on the imagination. So I typically picked things that already existed and gone and reproduced them and figured out how to do interesting challenges with them. Sometimes it was, I'm going to clone this tool and figure out how do I build it faster for a very specific bit because I want to learn about optimizing code perhaps, or I want to learn this faster programming language. So I'd done several of these projects time and time again over the last 30 years to learn either Visual Basic or PHP or C or C++ or Java or C, August or Go. So that's what it was about. It's about helping with that very specific bit of learning a program on the average of a real project and then learning some programming techniques within the framework of a real project and actually finishing a project.

(22:01):
Because again, you just write a factorial function or whatever little toy examples in your book. You haven't learned how to build a program end-to-end. You haven't learned how to debug something that's up and running. You've just learned how to build a function in the least most minimalistic way possible. So coding challenge that exists is that it's around the coding. It's focused on the coding and the role of a design. Again, it's coding challenges. It's not software engineering challenges because all of software engineering is much, much bigger. As I said, it's like, what do we build for who? How do we build it? What problem are we solving? How do we solve the problem? What does good look like? All those things. So coding challenges fits more in that craft of coding. And you're right, I have seen a big change over the last couple of years as AI increasingly fits into that coding.

(22:47):
Less and less people are focused on a learning list or Go or Python or drilling deep on their programming language because they're now either delegating it to AI or they're thinking that it's a waste of their time to learn because they're being told by all the people pushing AI that AI is going to kill software engineers. And AI will write all the code six months ago, I think it was. And then software engineering is solved and all these other things that are not true. Yes, AI can produce a lot of code. Directed work can produce some pretty good code. That's not the place in software engineers. Still needs a software engineer to do that. And it still needs a software engineer to be able to get good results from that. So that's the change I'm seeing. And I think in some ways it's a shame because I actually enjoyed writing the code.

(23:35):
It's something that I think a lot of us found great satisfaction in. It's the kind of part of the job we enjoyed most. And also, if you go back to writers and thinkers and scientists, a lot of people say that writing is thinking. I don't mean the physical act of writing. They mean the act of putting down your thoughts on paper, editing them and structuring them. And again, the code for us wasn't really that the coding was necessarily hard. It was that by putting it into that structured, algorithmic, procedural and perative, whatever element you want to throw one way, we were editing our thoughts, we're putting them together, we're organizing them. So again, the code itself isn't really that important, but the process of getting them down and organizing our thoughts was what mattered and we've lost something in taking that away. Now, yeah, I'm sure you've seen there's lots of debates of whether or not test-driven development works, whether or not it's a good idea and so on.

(24:34):
I think that a lot of those missed a point because you can write really good software with TDD. You can write really good software without TDD. If you are, I don't know, Stephen King, you can probably write really good stories with a pen and paper or with a typewriter or with a word processor. And you find the right process that works you. And I don't know what his process is. He's probably documented it in his unwriting book. But for me, TDD was like that. If it fits your process, it's a great way for you to work. If it doesn't fit your process, build your software another way. So long as you build high quality software, that's what should matter. I like TDD because it gave me that structure to my thinking of what should this do? Which also felt like the natural way of building software to me.

(25:19):
What should the software do? How do I know when it works? Now done. Now that I've got those two things clear, I can write the software. So to me, TDD is figuring out what the requirements are and how I verify them and then doing the thing to satisfy those two. So it makes sense to me. For other people, they want to do that and write the test last. I think that kind of misses the point in that it focuses on it being testing rather than a workflow. Like I said, there are many different workflows we can take.

Nicky Pike (25:52):
You went through, you were talking, you got coding challenges, which by your own statement, that focuses on the coding. You went through books to build applications. There's a number that kind of backs up what you're saying here, which is that roughly half of developers used to use, I think it was in 2024, roughly half of the developers used eight or more resources to learn things. Now that we're in 2026, that number has dropped down to 7% per stack overflow. And they're using AI to learn. And that has jumped up 64%. This how do I get better habit is starting to collapse. And one of the things that worries me about this is if when we go in and we look at development and we look at strong developers, again, we're going to focus on the code side here. There's almost an art to it. There's a fingerprint.

(26:39):
You can tell how somebody did that. But are we going to lose the art of development because AI has taken place and people are starting to focus and rely on AI, bring that in? I don't know, man. Am I just the old man yelling at the cloud here? Is there something that you think we're going to lose on this?

John Crickett (26:56):
I think there's several questions wrapped up in there. So to narrow in on the coding to start with, like I said, the value wasn't the code. The value was the writing. writing is thinking. If we have AI write all the code, there's that risk that we've lost that thinking process that we've gone through thinking, actually, do I want to do it this way? Or now that I've come to think about that problem and the steps that would be required to validate this data, does this make sense? What if we just said to AI, the data's got to go through this transformation, this transformation, this transformation, then I'll put in that format. We just regurgitate the requirements to it. We've lost that step of thinking. So there's a risk that we miss some of those nuances and we don't understand things as well. That doesn't have to be a problem if we do that thinking a little bit earlier and spend a bit more time figuring out requirements with the customer, with the user and working them out.

(27:47):
That can balance. I think what worries me more with what you said was that this idea of people using AI as the owner of the resource to learn. Again, I don't think it's a problem to use AI to learn. I think it's a great tool. Go back to calculators and mathematics as everyone likes the analogy. Calculators are not inherently good or bad. What's bad is I still see people occasionally getting a calculator out to do one plus one or one plus four or simple calculations where it's slower by them actually getting out and doing that simple mathematics, but they've just never developed the habit of finding that balance is something that they can do very quickly in the head, finding a balance of when they should get it out. So you want to go and calculate a differential equation or an integral. Yeah, get that graphical calculator out, go for it.

(28:38):
You'll sat working out your change. You've bought a cup of coffee for 2.99, you've given them $5. You shouldn't need to pull a calculator out for that. It's slower than you should be able to do it in your head. You should almost be a pan match that, not even have to calculate it. So I think if you just go to AI and always align it and say, "I want to do thing," and it does the thing and you let it, you're not really learning, you're fooling yourself. It's a bit like watching a YouTube video. You're not learning by watching YouTube video. I've mentioned I've learned from, we're old, we've both got the gray hair. I learned programming from reading books. But as soon as possible, I wanted to put the book down and build real software with it. Because just reading the book, and I know because I did this, read the book cover to cover, went, "Hey, I know C." Sat down to write code after one you can get.

(29:28):
And then went, "How do I actually like program?" And to own the book again and go like, "Okay. Ah yeah, hash include angle bracket, the standardio.h thing." And I went, "What the hell does that do?" And I've read the whole book, but it didn't really sink in from just reading this book cover to cover. So when I then sat down and typed in the Hello World and typed in the code and then went, "All right, cool. I says Hello World. How do I get it to say Hello World, John? I've got to read something from the keyboard. Was this get you think?" I I had to start figuring things out by actually doing it. So AI could be a great tool for learning. If you go and say to it, work through this exercise with me, I want to do this. And I've just done a coding challenge in this actually where you build an AI that is sat there to say, take you for one of the coding challenges.

(30:17):
And you say, show me how to implement the network protocol for Redis. And the AI will go, no, I'm not doing it for you. What you want to do is build a parser. Here's some resources and a parser. Here's a short micro lesson on building a protocol parser. Have a go at it. If you get stuck, show me your code. Now you've got something incredibly powerful with AI because you are still actually going and doing it and solving the problem. But the AI is there as a coach, as a mentor, as a guide. So again, you can use a calculator to check your maths while you develop the pathways and develop the understanding yourself, or you can just delegate all your thinking to it and do one plus one in your calculator. Same with AI. So use it right. I think you're going to be fantastic.

(30:58):
Use it long. You're just kidding yourself. You depriving yourself of any learning.

Nicky Pike (31:03):
Well, you said you can't learn from a YouTube video. I mean, I disagree, but I think the reason I disagree, it actually goes along with your thought process here. I built a house. I didn't know anything about building a house. And we call our house the house that YouTube built because that gave me the frame of reference, the concepts to get started. It gave me a starting point and then I went in and figured that, figured out the rest of it. And I think that's your point here is you've got to use it like a tool. You're not anti-AI. You use AI every day. But where you're coming in is you had made this statement that nobody expects an unskilled person with a power tool to beat a skilled person with the same tool. And I think that's where you're going with this is that you have to go in, you have to know how to use the tools.

(31:47):
The tools will amplify what you're doing. But when we talk about things like AI, John, how does an engineer go in and build the skills? How do they get good with the tool if the tool can actually kind of do a lot of the work for them?

John Crickett (32:00):
So let's go back and pull up the house first because that sounds fun. Not literally pull at the house. But I bet you didn't watch one YouTube video on how to build a house. Then lish out there with your bucket space, cement mixer, saw power tools and just build a house. I bet you watched one that had the high level concepts. Hours. Hours

Nicky Pike (32:21):
Of

John Crickett (32:21):
YouTube videos.

(32:22):
But then maybe you did some sketches and maybe you got that checked and then went and watched a bit more. And then when you came back to, I don't know, when your foundations, you went on a more detailed video and then maybe had a go at a little bit of it. And when you came to, and let's say, I don't know, well, you built it up, maybe wooden frame, you probably then went, how do I actually cut this joint? What sort of saw do I use? And then you probably had a practice and you probably screwed up some of the bits of sawing wood. And you probably learned the hard way with why would carpet and say measure twice cut once. And you actually did all those things. So you absolutely epitomized what I'm saying. You can't learn to build a house by watching YouTube.

(33:04):
You learn by watching just enough to take the next step. You took the next step, you did it, you made the mistakes. Then you went back and went, maybe there's another video or maybe I didn't watch that video well enough. And you re-watched it presumably. So was it like that or did you watch one video and just build the house?

Nicky Pike (33:20):
Oh, no. I watched every step of the way I would watch hours of videos to get the concepts in my head. And then like you said, I'd go out and I would try those concepts out and see where they worked and they didn't. And I think that's the point here. The way of learning is changing, John. I was the same way. We came up reading books because that was what was available to us. Now we've got YouTube videos and stars out there like Dan Vega and Josh Long that will teach you concepts for Java. You got Eric Meyer that will teach you concepts on software development. We've got coding challenges that will walk you through real world implementations. The ability and our way of learning is changing. We're a society that is very much becoming more instant gratification. I think things like YouTube video do that.

(34:05):
AI is probably a pinnacle of that. It's instant in the fact that I can ask it a question and it'll give me an answer. Now, how I use that answer to your point is another thing entirely, but it is a shift. I'm imagining that you're seeing this with coding challenges and people that are coming in asking those questions. Well, can I just ask AI to do this?

John Crickett (34:25):
I am. And back to my earlier point, when they're saying to AI, can you build me a Redis clone or something? They're not learning anything. If they go back to AI and say, I want to build a Redis clone, how do I build a protocol parser? Don't give me the code. Give me the hint and the lesson and then review my code. It's better than anything else because you can get that equivalent to the book. It can give you the two or three, the sort of relevant two or three pages, if you will, of the book. So it can take you straight there and you couldn't have searched a book. You had to read the whole, not leave the whole, you had to flip through the table contents, find the right books and figure that out. Where now AI can kind of give you a summary of the two or three pages that would be relevant.

(35:09):
You can then say, well, okay, right, I'm going to implement LESP as a protocol. Summarize a protocol that I need, and it can go and do the web search and put it in fees. So all of that information can be bought to you a lot quicker. But as I say, if you then have it just like the buzzer for me, you don't learn anything you don't get from that. If you say to it like, okay, I'm going to have a go at this, check my code, critique my code. Oh, I'm stuck. I don't know how to handle bulk strings. I don't know how I'm going to handle allays. What would be the normal thing for that? And then the AI can say, well, give me your code. Olivia, okay, cool. So you've handled arrays, you've handled integers like arrays. You can do that sort of a recursive descent parser.

(35:50):
Here's 500 words introduction tutorial and how to build a cursive parser. That and you're learning. You've got a coach that's kind of leading forward. And I think AI is incredibly powerful for that. Now, if you've got the time and money to come onto one of my courses and pay me to sit and do that with you, that's great. You can do that. But a lot of people that want to do that in America, I'm in the UK, I'm a better sleep when some of them want to learn in the evening. So time zones, costs, a lot of reasons that's difficult. Where the AI is there twenty four seven. Oh, I've got 10 minutes now. How do I do the next bit? You can pick up with it. Then you can pause, go off, do your day job, come back. I used to commute a lot by train.

(36:33):
You could have done 20 minutes on the train, got to where I'm going, get off. Yeah, come in, have my dinner. I've got 20 minutes now after I haven't put the kids to bed. I can do a little bit more. So AI is incredibly powerful for that. It's in a way the greatest tool that I think we've ever had for you being able to learn that. If you use it as that interactive coach, if you use it to help you learn rather than having it do things for you. And I think that applies whether you want to get it to teach you how to like literature, whether you want to get it to help you understand mathematical context, whether it's to build software, anything that you want to pick up.

Nicky Pike (37:10):
So give some practical advice on that because I do think I 100% agree with you. I do think AI is a good teacher. But when we look at most people's chat interactions out there, they're going to go out and say, "Hey, I need something that does this. AI is going to build it. It works. I don't think people are looking further beyond that." What are some practical ways that people can actually use AI? Is this a prompt in saying, "Hey, Mr. AI, be a teacher. Don't solve problems for me." Is it a process that you go through of reviewing code after the AI is generated for you? You work with developers every day. What are your recommendations and practical advice for how they should use AI to be that mentor, coach, pair programmer?

John Crickett (37:49):
It's really fundamentally like everything else, is giving that AI the right context. There's a couple of different ways you can approach this. If you want to say love with ChatGPT or Cord, just give it a prompt at the beginning. Say, I want in this session for you to act as my coach, do these things. That works moderately well, and you can use the chat interfaces for that. If you've got an API key for one of these and you can work through them, and I've used Gemini quite a lot for this because it's just been quite easy to set up and it's fairly low cost to play with and go wild with. You can then put the system prompt in if you build your own thing on AI. The system prompted sticks to a lot better. And I've had a lot of success putting in a system prompt saying you're going to act quite often for my examples.

(38:33):
I tend to act as me. Mentoring a developer. Don't ever give the answer. And Gemini again is very, very good at sticking to the system prompt. So I can say, don't ever give the answer thing. Just reveal the next bit of information. Probe to find out why the user is stuck. So I then built a chatbot. AI chatbots are really simple. It's basically a wire loop that's getting your input, passing it into the LLM to do influence, passing the answer back, keeping log of all that, which is what we call context window and passing that back to influence next time. And then yeah, maybe you want to support some tools for compaction. You build that yourself, you can give it a strong system prompt and have it come back to you and just ask that coach revealing just enough information to get you past the next bit be stuck.

(39:20):
I used to describe my style of learning as I read just enough of a book to get started, work till I get learn by doing, work till I get stuck, and then go back to the book and learn just enough to get unstuck. That's quite time-consuming. So you haven't got the right book, you've got to figure out what the right book is and get it. Then you've got the details content. Where is it on page?

Nicky Pike (39:37):
What chapter? Yeah.

John Crickett (39:39):
But it's what we had 40 years ago. When we got Google and stack overflow, some of that you could go and Google and search for it and get unstuck that way. Now LLMs are so much quicker. They even know the answer or they can go and do some of the searching for you. But it's like you say, having it do just enough to get you unstuck, give you that next hint. You still have to do the thinking. That's where you learn. A lot of the complaint I see from people saying is, "We don't have time to learn. My boss just wants me to build." Okay, fine. But there's two elements here. There's one, what you do in your day job and what your boss wants. And if you are being paid to deliver, then that's your focus. Fine. Focus on just delivering. Don't worry about the learning.

(40:20):
That's choice that your boss has made for your career and for your progression or for something that you want to learn as your hobby for fun. Then don't deprive yourself of the learning. Take this process. Get it to act as that coach or mentor. Get it to ask you questions. Get it to reveal just enough to help you get unstuck. And if your boss doesn't support learning, maybe it's not the right environment long-term because if people aren't learning this industry, you're stagnating and your company's going to suffer and your employability's going to suffer. So while I don't advocate resume-driven development, if your company isn't allowing chance for learning, they are going to stagnate. You are going to stagnate. It's going to damage your employability and do so. You have to be responsible and accountable to your employer. But you're accountable and responsible first and foremost to yourself.

(41:10):
You are the CEO of U Inc. You are responsible for making sure that you are still a viable operation. And that means that you have the skills to be employable. If your current company is not providing that, I've got to change it as quickly as possible. And you do sometimes have to invest in your skills outside of work.

Nicky Pike (41:29):
The CEO of U Inc. I'm still in that, John, because I love that so much. Well, okay.

John Crickett (41:35):
Not my phrase. Somebody else said it years ago. All

Nicky Pike (41:39):
Right, then we're just going to plagiarize from everybody on this one. But I do love that phrase because it's right. But I want to go back to something else when we first started talking and you were talking about some of the businesses that you tried to build that you thought that they were lacks of imagination. And that's got to be coming into this development right now in the fact that the blank page problem. How do I even get started on a project? How do I start breaking things down when I've got no concept? This is where I think things like coding challenges are very beneficial because they give you a starting point. Here's something we're going to work on. But this is what you call engineering is. That blank page is what engineering is. We've got to start with an idea. We've got to build the idea up.

(42:21):
Why do you think that there's so many people out there that are hitting the wall the second that there's nothing to copy? How do they get past that blank page problem and figure out what they want to learn on?

John Crickett (42:32):
So I think there's a couple of elements to this. One is we've had a focus in the industry for the last 15, 20 years of dragging lots of people in, getting as many people in. And this obsession with learn react or learn Java or learn Spring or pick your favorite framework or Kubernetes or whatever stack. And we've had this obsession with shopping lists of technology and frameworks, which are all superficial. They are things built on the fundamentals. And that's meant we've sucked in lots of people from bootcamps, we've sucked in a lot of people from non-traditional and non-software engineering, non-computer science degrees. That means that they don't necessarily have the fundamentals. Early in my career, I didn't really value that highly my computer science degree. I didn't see that it was that relevant to a lot of what we do because I have never implemented quick sort in a job.

(43:25):
I've never done a merge sort or any of these other things. I've never implemented a hash table or a hash map. Never implemented a binary tree in a job. So a lot of it didn't seem relevant. But actually I'm starting to realize that we've gone too far the other way now that a lot of people never learn those things or they only learn them to pass LeetCode to pass a job interview. So they don't really learn them. They learn the mechanics of repeating them and regurgitating them and recognizing that this problem on LeetCode requires you to build a tree, but they haven't really learned what a tree is and why we did it and what problem it solves. And part of the problem with that is they haven't then learned that this is actually the concept of divide and conquer. This is how we're breaking down the bigger problem into a smaller problem and solving that.

(44:11):
And then we're breaking down that problem into small problems and solving that. And so I think a lot of that has then missed people being able to then apply that third bank page of like, well, actually what's the problem we're trying to solve? So people then sat there, and again, partly that an awful lot of software engineers do maintenance. That's the reality is everyone talks about this greenfield development and how great it would be, but I think 90% of our time is spent as software engineers doing maintenance. So you very rarely come into a project and get starting from scratch and build a greenfield. There's something there already. And that means that a lot of people have never in their careers sat down and built something from scratch. So they don't googly know where to start. And because they haven't maybe done a computer science or software engineering degree, they haven't been through those fundamental problem solving steps to be able to then figure out for themselves.

(45:03):
That's something I learned from my CS degree, which I didn't give enough credit to earn my career. And also by going away and starting my own business, which meant that I've started from an empty laptop, empty checkbook thing going, I've got to build something here. How am I going to build it? How do I deploy it? What's the first step? That gave me a lot of chances to, again, learn by doing. I've failed and messed up things, but I had to put food on the table at the end of the day. I had to pay my bills. So that gives you quite a strong motivation for iterating fast and finding out, how do we start? How do we do these things? And again, one of the problems is it's quite daunting starting as well. A lot of people just keep paying that off. Find a way to avoid it or go and watch another tutorial, an example where sometimes you just have to start and then be prepared to iterate.

(45:51):
And again, that's why I like the agile approach and I sort of like test-driven development I think works really well in here in that if you're used to doing test-driven development, you're used to putting on a test, building something that sort of works, and then refactoring it mercilessly as you go through. So you're quite happy flying away code. Whereas a lot of people that I find don't take that approach, feel that they shouldn't write code until they know what they're writing. So they've got to have it all figured out in advance. And again, particularly when you're citing from a blank page, you don't have it all figured out in advance, but back to that coding is thinking the code isn't the hard bit. The hard bit is when you sit down to write and go, ah, I though I knew what they're supposed to do, but actually when the customer said that they wanted to count words, what do they mean by a word?

(46:36):
It's a hyphenated word. Is that one word or two words? If it's hyphenated across lines, you see suddenly as you start doing the coding, the hard bit isn't how do I increment the character and the next character in the text? It's, oh, what's this edge case? No, that's the process that I think is hard. And if you can start, you start discovering those things. So then you start getting more answers and you get more understanding of what you're building and it gets easier. And I think going back to what you said about half an hour ago about seeing more of these AI projects, that's something that we're missing. If you are in there doing the code yourself, you start have to answering all these little questions of like, well, actually, what did you mean by that? Well, if you just say to the AI, building me this app, it makes a lot of assumptions along the way.

(47:24):
So it answers a lot of those questions with whatever is the most common pattern in its dataset, which might work perfectly, which is why some people are so enamored and go, "Hey, I wrote one line prompt and it built me the whole app and it was perfect." Yeah, if you want just another to-do app, it probably will be. You want to build something that's a bit different. All those assumptions, all those answer and those questions on a way. If you were doing the code yourself, you'd be coming up with those. If you're just letting AI build it all you went. Again, I don't think that's a reason not to use AI. I think that's a reason to be intentional about the AI. And I think a reason to think a bit more about spectrum development and to put a bit more effort maybe if you're building with AI into like, okay, how am I going to test this?

(48:05):
What are testing it? And how do I, back to one of the extreme programming ideals that I really value is how do we get the customer closer? And again, I think AI, if you can get the customer and an engineer together and now pairing with an AI, you can actually create value a hell of a lot quicker, I think, because your AI can do the code a lot quicker. You can now have the engineer working with the customer saying, "All right, cool. AI's going to have that and we'll try it in 30 seconds. What do you want to try with it? What do we do?" And then, "All right, cool. We tied that and actually that feature sucks." So now you could potentially iterate a lot quicker, but I think we're going a long way with AI as well. Most engineers I talk to, they're now working alone asynchronously, chatting over Slack, having less of that human interaction.

(48:49):
And the AI is churning out code, but they're not going back to a customer or user going, "Hey, cool. I've got the feature. It took 20 seconds to build. Do you like it?" And the user then going, "Actually, no, that wasn't what I wanted. I know I said I wanted it to be a black door, but actually now I've seen it. I want it to be." Well, and I think

Nicky Pike (49:06):
In the industry, John, is backing up what you're saying. The World Economic Forum came out and said that 65% of developers are going to expect their role to be redefined, moving away from, like you said, the routine coding. That was never the hard part. It was the architecture, the integration and the design. And that's kind of your pivot there. I mean, what does this mean to coding challenges? Are y'all changing the way that you teach? Are you teaching things that you didn't teach two years ago?

John Crickett (49:33):
I'm changing what I focus on. I'm changing and focusing more on how do we learn with AI? How do we build up those problem solving skills? I'm going to be putting more of a focus over next year on taking people from that blank page to how do we figure it out. I almost think in a way, what I want to be teaching people is how to build their own coding challenge rather than how to build the code. Oh,

Nicky Pike (49:59):
That's awesome.

John Crickett (50:00):
How to implement the coding challenge. Because one of the biggest questions I get from people is, how do you write one of these every week? How do you figure out what the steps are? How do you break it down? And I'm seeing more and more that that's the thing that most people are stuck with. And it's probably becoming even more valuable with AI.

Nicky Pike (50:16):
I agree with that one. I think that's a wonderful idea. It goes back to teach Amanda Fish type of concept there, and I love that. All right, buddy, we're going to jump into the rapid fire stuff. These are just going to be questions. I want you to answer them without thinking too much about it. Just kind of answer the question as it comes out. So the first one, one skill every engineer should learn by hand, no AI, no exceptions.

John Crickett (50:39):
I think that's really been a breakdown of problem into small steps. So whether it's figure out and break down quick sort in small steps or figure out how you're going to build this gooey or how you're going to implement something there. Breaking it down in steps, figure out solving a problem.

Nicky Pike (50:53):
All right. So stop trying to eat the elephant, just do it one bite at a time.

John Crickett (50:57):
Yes, exactly.

Nicky Pike (50:58):
Yep. Yep. Are we in an AI bubble? Yes or no?

John Crickett (51:02):
100%, yes.

Nicky Pike (51:04):
Okay. That bubble pops. Does the technology still matter the morning after?

John Crickett (51:10):
Yes, absolutely. Just like the previous two AI bubbles that led to the winters, technology still mats. It's still fundamental. It's not going anywhere. It's just once it works, we stop calling it AI. I think that's going to happen when this bubble pops, which I'm 100% sure it will, but the technology will still be here. We'll still iterate on it and it'll be useful.

Nicky Pike (51:31):
Coding challenges, subscription, newsletters, bookcamps, or training courses. What's the best place for somebody to get started today?

John Crickett (51:39):
I think it's building something real. Learn by doing. Now you can do that with all of those. You can do that with an LLM, as we said. So it's go and apply that. Watch YouTube video and start building. Ask LLM for hints and start building and use it as a coach. But you've got to actually do the thinking yourself.

Nicky Pike (51:59):
I agree with you. I'm going to add one more thing to that. Get into the community of whatever you're interested in. Community is the place that I find I get most aspects, most of my learning done because bouncing ideas off of people beats anything. Yes, you can use AI to do it, but I think with community, you get a little bit more original thought there.

John Crickett (52:17):
Yeah, absolutely. And go back to your house building example. Pick a community. Your AI can't come out and show you how to hold the saw. Can't come out and show you a little trick for dropping a plumb line here or whatever. Yeah, that still needs a physical human being to do some of those things.

Nicky Pike (52:32):
All right, fill in the blank for me. The engineers who thrive over the next couple of years are the ones that refuse to stop doing what?

John Crickett (52:40):
Talking to the customer.

Nicky Pike (52:41):
Talking to the customer. And that customer could be themselves. I mean, let's be honest. In the world of AI, maybe you want to vibe code an app to help your household, but you are your own customer.

John Crickett (52:53):
Yeah, absolutely. And again, use AI for that. I mean, sometimes when I'm preparing some of the coding challenges, I will put into an AI say, "I'm building a coding challenge about this. These are the features I want to cover. Is there any growing gaps?" And again, use it to bounce some ideas off. Challenge my thinking.

Nicky Pike (53:11):
Great idea. All right. On your back wall, I see a couple of guitars. Which one's your favorite and why?

John Crickett (53:19):
My favorite is on the front over there. It's a POS wood library, and it's just such a beautiful instrument.

Nicky Pike (53:25):
It's the one we can't see. That's the one that you're going to call your favorite. Well, I guess you arranged it so that you could look at it all day long. That's how much you like it.

John Crickett (53:34):
Something like that. It's more case of it was down and being played because it is the nicest guitar I've got. And it's also just such a beautiful piece of Flame Maple. It's a work of art as well as being a great instrument.

Nicky Pike (53:45):
So, all right, let's get into a spicy take on this one. You called AI a bubble. When we were talking, you actually said that you thought this was a financial bubble, not a technology one. Kind of in the same way that we saw the dot-com boom go happen. When the correction comes, who do you think standing who's gone? And what does the industry look like on the other side of this?

John Crickett (54:07):
I don't see how OpenAI or Anthropic survive. They're claiming massive revenue. Don't know how much I believe that, but they're spending almost as much money. There's questionable circular finance going, "Yeah, fundamentally, how do they differ to the Chinese models or the open source models? How much are they really ahead versus the massive amount of capital they're spending? How are they ever with a $20 subscription? Yeah, they're doing all right with the API pricing, but a lot of companies are now saying they've exhausted their butchers. How do they ever turn a big enough profit to justify their valuations? So I see them going. Google owned far more of the stack. They've got data centers, TPUs, they've got the distribution. I think they'll be around. They'll probably acquire one or ever of those two. Apple seems to be amazingly good at getting things right. Maybe they'll acquire the other.

(54:57):
So I think the technology will be around. We'll still be using them, but I think that we'll see a correction. I mean, take Google, as I've just mentioned, they were the 22nd search engine, I think. Most people can't name the 20 that came before Google that failed, that disappeared because they spent a lot of VC money, they built distribution, but they didn't have a way of actually monetizing it and becoming profitable.

Nicky Pike (55:22):
John, I asked that spicy question on a lot of interviews. I've seen somebody come out just full swinging at the big dogs on that one and saying, "No, the people that everybody relies on, I don't think are going to make it." And then you temper that by saying Apple, which let's be honest, a lot of people out there think that Apple is probably doing the worst in the AI space, but that kind of leads credence to your points. Maybe they'll acquire somebody else that does it well and make it right.

John Crickett (55:48):
Yeah. I mean, Apple have acquired other people in the past or have bought in the technology when they've figured it out and then found a good way of making it usable, making it something that people become fans of.

Nicky Pike (56:01):
I love the fact that you came out swinging for the fences on that one. I can't wait to talk to you in a year or two and see how close you were to that. All right, buddy, last question. And this is the one that we ask everybody. So you started out in the 1990s chasing AI before it was cool. You took the long way around through games and startups and building your own businesses, and now you're spending your days trying to help other people get good at this craft. After all of this, what does it mean to John Crickett to be a coder?

John Crickett (56:28):
I think it means solving a problem with code. I would differentiate code from a software engineer. So I think a coder, you still have to write and read the code yourself by all means leverage an LLM for some of that. But if you want to call yourself a coder, you've got to be able to build that code by hand. As a software engineer working professionally, I think you probably should be leveraging the LLMs to get a lot of the legwork done. So I think that are two different goals.

Nicky Pike (56:51):
I love everything about that. And for those that are out there that are watching that maybe you're a citizen developer, you're getting started, maybe you're a junior, go check out Coding Challenges and see what's out there and see how John can help you with that. And come back and tell us in the comments what it looks like for you to use AI as a teacher and mentor. John, I want to thank you for coming on the episode. Thank you very much for your insights and some of the interesting stories you had. Is there anything you want to leave us with before we call it off?

John Crickett (57:17):
Thanks, Nicky. It's been a pleasure. Again, I invite anyone to reach out to me. I'm easy enough to find a quite unique name, criticize it, debate it, argue it. That's how I learn. I share these ideas on my opinions so people can challenge the ideas and opinions, and that's how I learn and get better myself.

Nicky Pike (57:34):
Excellent. Well, we'll make sure we put a link out there to both your LinkedIn as well as coding challenges so people can get to it. And once again, thanks, John. We'll talk again soon.

John Crickett (57:43):
All right. Thanks, Nicky. Take care.

Nicky Pike (57:46):
Thank you for listening to Devolution. 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.