[00:00:00] John Crickett: Welcome everybody. I'm really happy to have John Crickett here on the podcast. I'm very excited about this because John and I actually did record an episode a couple of months ago, but yours truly forgot to hit the record button.
[00:00:10] And so after we had a great conversation, I told John, you're gonna have to have another great conversation because I forgot to hit the record button. So this time, I've definitely hit the record button. So I'm not wasting John's time. And I'm very excited to have John here on the channel or on the podcast, because he's got it.
[00:00:21] John is one of those people who's deeply experienced and seasoned has been around long enough to actually have a proper sense of history and understand how things work, which is how John and I got to know each other on LinkedIn.
[00:00:31] Welcome to Easier Said Than Done with me, Zubin Pratap, where I share with you the tens of thousands of dollars worth of self development that I did on my journey from 37 year old lawyer to professional software engineer. The goal of this podcast is to show you how to actually do those things that are easier said than done
[00:00:50] John Crickett: John, thank you so much for taking the time out again to join me on the podcast.
[00:00:54] I really appreciate it. Thank you, Zubin. As a pleasure wasn't a waste of time last time. It was a very good conversation. I enjoyed it Yes, there was I thank god for saving grace at least in that and thank you for looking at the glass half full I was so mad at myself that I forgot to hit the record button and it was a long conversation, too you know very generous with your time.
[00:01:08] So I appreciate that. Thank you. You know let's dive into some of the things John because I know Both you and I have a certain style on linkedin which is very much a you know This is the reality of it You know stop beating around the bush kind of thing. This is the reality about it. And I really respect that about your style.
[00:01:22] So I think where we where I'd love to start off is, you're the creator of coding challenges. And it is a very popular and very powerful tool for people to level up their coding skills by building real world projects now in your point of view, or from your point of view, John, what is a meaningful Real world project and you know against the context of the obsession around DSA Data structures and algorithms and you know the portfolio obsession that people have now. In your view just taking a step back What is a meaningful project?
[00:01:49] There's got to be something that you can actually deploy You build the whole application. I say application in the broadest sense of the word, because it could be a game, could be a website, it could be a API system, but just use applications encompassing, but build everything, actually make it deployable.
[00:02:04] So in an ideal world, you've got some tests you've automated, maybe you've got some CI, you deploy it somewhere. Or maybe you can containerize it and create a Docker container. And it actually serves a useful purpose. So it's not a toy thing that you've built to demonstrate that I can write another TODO app.
[00:02:22] And in the ideal world, a real application will be solving a real problem. So you go, I want an application that lets me, I don't know, transcribe guitar music. And you build that. You build something like Guitar Pro. However, we don't all have real world problems that we can immediately solve. Or it's very easy to get lost in what's the problem?
[00:02:41] What am I going to do and spend ages thinking about that not actually coding something? So yeah coding challenges exist to provide that gap so you can get on with the learning from coding. Rather than spend ages trying to find that real world problem to solve yourself.
[00:02:53] I guess a lot of the people that I ended up speaking to are people like me who are career changing and really at the beginning of the journey. And a lot of your audience, I'd say are people, with engineering experience of one year or more, they're already engineers and looking to really level up their game.
[00:03:05] So I get that there's slightly different audiences. However, I still feel the principle of what you're saying is what's important here, which is. If you're going to invest your time learning and building something to your point, make it useful. It doesn't have to be production grade in the sense that it's commercially viable, but it does have to simulate some of the things you do in production.
[00:03:23] Would you agree with that? Yeah, absolutely. So take, you mentioned the DSA earlier, you're not going to walk into a job and go solve two-sum or, reverse a linked list. Where you are going to walk into the job and go, actually, we need a UI connecting to a database, can generate some report from it. We need a website where somebody can sign up and do something, so those things are going to be part of the real world job where a lot of this DSA stuff is not going to be.
[00:03:49] Hi, if you want a no BS insight into how to change your career, whether to code or something else and how to actually get job opportunities in tech, then please subscribe and like.
[00:03:57] It's no BS because I have zero incentive to mislead you. I just want to help you and give you tons of value so that you will consider working with me to get to your next career.
[00:04:07] Take a look at the
[00:04:08] description text below to learn more about the training I offer. But I do post content here regularly and by subscribing and liking and hitting that notification bell you will get to know when I post new industry insights for you. You'll also know within about three seconds if you want to learn more, but at least you won't miss out.
[00:04:23] Oh, and please follow me on LinkedIn too. I pretty much post there every single day. Just look for my name, Zubin Pratap. All right. So please like, and subscribe to this channel and let's get back to the episode.
[00:04:32] John Crickett: So I'm more interested in you learning and demonstrating the skills that you're going to need actually to do the job and build software that works. Yeah, we're gonna want to deploy in production to actually solve a real world business problem yeah,
[00:04:43] and it's really interesting you say that because the one thing that most people don't seem to fully understand is that Even though like when I was at google, yes We use DSA as a way to get in, that was how the interview process was structured in the big end of town.
[00:04:57] I didn't actually use a lot of it in my day to day life, I used almost none of it in my day to day life. And I'm, I've tried to explain to people that there's a difference between the job and the exam to get a job, which is no different from schooling. Even then there's a difference between the exam, as you put it, to get into Google and the exam to get into, Bob's software shop down the road that's building software for convenience stores.
[00:05:22] Absolutely. Google the other big tech companies have a unique problem in that they have thousands of people apply for every role they need a way of filtering out those people and dsa is It's a filter whether we like it or not. It's a great filter for that And again, they're not looking to hire the best people They're looking to hire good enough people and they're looking to filter out the ones that are definitely not good enough As early as possible so they can go through the list And hire the best people to get through there.
[00:05:47] So they are willing to accept that they will get a certain number of false Negatives, they will reject some very good people. Oh, it's expressly their hiring policy If they've got one of all in a thousand applicants, they can't find the best person. It takes too much time It may even be an impossible task But what they can do is filter out say 800 of the people that definitely aren't good enough And maybe five of the people that were great And then get down to a couple of hundred, they can go for the next stage, filter out those and get left with say five incredibly viable candidates that will be able to do the job.
[00:06:19] So that's what they're doing where, a lot of the same small companies or early stage startups that I work with. We'd be lucky if we get two candidates. We don't need DSA to filter out a thousand candidates. We've got two. It's perfectly viable to speak to both of them and establish whether either of them are actually able to do the job and advance with one from a conversation.
[00:06:36] So we're solving different problems with that. Very different problems. In fact, even after I left Google, about 50 percent of the roles that I, Applied for and interviewed with and just for the record for people out there I failed interviews even after google like people seem to think that once you get into a place like, oh, you'll never fail an interview again that's dumb It's really not true Like I failed a few interviews after google And there were lots of interviews not lots But about 50 of the interviews that I was going were for exactly as you say smaller companies or startups that didn't care about the DSA stuff.
[00:07:01] They wanted me to spend half a day or a day working with them, coding, pair coding with their engineers to show that I could actually get the job done, which is a completely different kind of filter because they're filtering for fit and the ability to get the job done rather than to rule out candidates, to reduce the administrative burden of finding who to employ.
[00:07:17] It's a completely different problem, exactly as you describe it. And I really hope that people out there. I think you, you're the one to popularize this concept on, on, on LinkedIn with, software engineering for the 99%, like 99 percent of the world is not going to need this fancy stuff. Brian Jenney, you, I, a few others have said this, that if you're spending all your time in DSA, you're probably not spending your time on things that are going to help you in 99 percent of the jobs that you need to try and get into.
[00:07:40] Yeah, absolutely. And I'm sure even within Google. That 1 percent or any of a big tech 99 percent of the time, you are not going to be writing code to do a linked list. Oh, no, that's inefficient. You're going to use the ones in the standard library for programming language. You're not going to implement a map.
[00:07:53] You're not going to additionally, you're not going to spend hash map or whatever. If you are going to use what's in your library and you need to understand. How to use them, how to apply them, not how to input from scratch. So in your experience and opinion, given you've been, around a few decades in the field, John, what would you say is the skill difference between just being able to bash out a few lines of code and actually building software applications?
[00:08:17] I think the biggest skill difference is taking that pause to say what is the problem we're trying to solve Why are we trying to solve it? And what does good look like? Yeah, because anybody can bash out a quick couple lines of code that especially these days with the ai. Yeah Yes, and that you know If you can describe the problem you can bash out some code quite quickly to do it And again, I see that with some of the solutions to coding challenges people quickly bashed out a solution that maybe passes the happy path You But they haven't thought about what if it goes wrong?
[00:08:45] What if something different comes in? And the great example is the first coding challenge I put out was WC. That's the emulator units command line tool. WC is fundamentally very simply fairly simple. Fundamentally it counts words. That's a basic use case. But it's really well implemented in the Unix source code that is 50 or 60 years old.
[00:09:05] And it scales incredibly well. You can put a couple hundred gigabyte file for you and it works quite fast. Most of the solutions I got for coding challenges, you put a 10 gigabyte file in, they will fail, they will crash. They might even take down the operating system depending on what platform you're on.
[00:09:22] They simply won't complete and produce a word count. Interesting. And that's because. People have thought about the happy path in solving it and they've gone. Word count, that's trivial. Read the entire file into memory, count the words or count the spaces or something. And they haven't thought about what if that file is big?
[00:09:37] What if that file is too big to fit into memory? And even with many of us having eight, 16, 32 gigabyte laptops these days, or desktops, there's still files that won't fit in memory. So I added a test case to that of a hundred gigabyte file. And it's not actually a file. It's just generated using the command line tools.
[00:09:53] Most of the solutions fail on that because people haven't thought what is the edge case? There you go Yeah, and so it's really sounds also Like the definition of problem solving in the world of software engineering is actually quite different from what the LinkedIn or the Instagram or the TikTok influencers say is where they say, oh, problem solving is reverse a linked list or, balancing a binary tree or whatever it is, right?
[00:10:15] Whereas actually in real world, in the real world, being a problem solver is understanding how various usage paths will interact with your code to produce results that may be undesirable and how do you get around. Would that be a fair summary? Yeah, problem solving in the real world is that your users can come along and say, I have this problem.
[00:10:31] I want your software to solve it. I want some software to solve it. Yeah, I'm designing telecommunications network. I've got 37, 000 IP flows for this network. How do I design my network to cover this capacity? How do I design it to cope for this growth that we're seeing that's at 50 percent year on year?
[00:10:47] That is a very different problem to the problem solving. As you say the first is linked list They might come on and say, i'm designing this network thing with MPLS So then you need to start understanding that it's how are you traffic engineering? What are you doing? they could be a Completely opposite end of spectrum somebody come on saying we're a charity We want to manage donations.
[00:11:03] We want to attract volunteers. We want to track these things You Then you have a very different set of what does that mean? What kind of roles do you have? What do these people do? How do you track that? So it's far more about actually speaking to a customer and understanding what's the problem they're trying to solve and what are the edge cases, what are the constraints and one of the rules that govern that interaction.
[00:11:21] Then goes back to one of my pet questions or comments or challenges that I post to people, especially those aspiring to become professional engineers is it's been self evident to me after I got into the industry that learning to code is not enough to build software professionally.
[00:11:33] It's just a starting point. What would you tell people happens after you learn to code and before you can actually meaningfully write professional grade software how do I describe that? So I was just thinking as you're talking that learning to code is a bit like A carpenter learning to use a saw you can't use a saw and go then build an item of furniture. You learn how to use a couple of different tools and you learn how to use those tools to create joints in the wood And then you use those tools Great knowledge try to create joints to put pieces of wood together and assemble something Then eventually when you can do all that you learn to go and talk to a customer and say What is it you want built??
[00:12:04] Like you want a bookcase. How big's the wall? Where's it going to go to floor the ceiling? How heavy the book's going to be how deep are the books going to be and you actually realize that Working with this example of a carpenter you There's a whole lot of questions, nothing to do with wood, nothing to do with chisels, saws, hammers, nails, screws, or whatever.
[00:12:20] They're all about you as the customers what are you trying to solve? How is this piece of furniture gonna solve something? What does it need to do? And you don't talk to the customer then about what kind of joint you're going to use and how are you going to do it and how are you going to saw it and what type of saw you're going to use or nails or screws, you talk to the customer about their problem, what are they going to put in those bookshelves, how are they going to use them.
[00:12:41] And I think we need to start thinking a bit more above the code. The code is, it's a tool set. It's a set of tools you can use. It's talking to the customer to understand their problem and then figure out how you apply that that's useful.
[00:12:53] Interesting. That's such a powerful metaphor because it's so true.
[00:12:56] Just knowing how to, how to operate a saw is not what it takes to build furniture. It's not what it takes to be an effective carpenter. And I think it's easy in 90 seconds to make software engineering appear to be about the code you write and the code you bang out. And movies like social media and stuff don't help.
[00:13:11] Sorry, there's just a siren going by, yeah so popular media doesn't make it easy with movies like the social media, whatever it is that show, weekend hacking hacking, that produces the next billion dollar company. That's really not how this profession or any profession actually works, it's, I used to tell my friends that, If they thought being a lawyer was like what they saw in suits the world has a lot of problems, you know It's just not it's just not so.
[00:13:31] Going further John because I know that you spend a lot of time You know on linkedin trying to educate people on the entire profession as do I , you bring a very senior software experienced software Professionals perspective I try to bring the well a lot of the things that we think are unique to software engineering Aren't unique to software engineering.
[00:13:45] These are unique to these are not unique Their Common metaskills across professions.
[00:13:49] So many people seem to be obsessed with learning to code, getting that first job, drinking kombucha and playing foosball and working from anywhere in the world, right?
[00:13:57] Instead of thinking about the coding career arc in your view, what are the stages of a coding career? Yeah. I think that's difficult to define because I've had quite a non traditional career I think that's a very The very simplest of I would think about it from your first role. You're going to be very much task taker You're going to take tasks and you're not really going to know what the next steps are So you're going to be very much taking those tasks off people and primarily focused on yes turning them into code making sure that code works.
[00:14:28] As you get a bit more experience, you're going to be focusing a bit more on helping to tease apart those tasks. So take a, as a whatever user, I want this thing to do this. And you're going to be assigned to ask so that you can do what and why, and how does that help? And what are the inputs?
[00:14:42] What are the outputs? What are the edge cases? So thinking a bit more about that, just above the task of, then as you get more senior, you're going to be into a bit more of. Okay. So above this task level, how do you want the system to work? And again, this kind of scope of what you think about is going to increase as you progress, and then the scope of your impact is also going to increase as you progress.
[00:15:00] So you're going to be starting to think instead of. My task think about this component then this system and then this set of problems or the business and how we pull that together So I guess in the broadest sense It's going to be about really the scope of what you think about and the scope of your influence increasing as you progress.
[00:15:15] Whether you choose to stay very technical whether you're going to pursue into more of a Specialism like SRE or data engineering or data science, right? And again, it's gonna vary a lot of whether or not you're going and say big tech Very focused on engineering whether you maybe go to a consulting company and have a very different career path to Yeah, big tech.
[00:15:31] Would you say that regardless of which path or which domain you end up being in, the evolution of the software engineer is no different from the evolution in any other careers. You keep stacking a certain set of skills that align with your goals and the goals of the company. Would that be a fair statement?
[00:15:45] Yeah, I think that is. I think, if we think back to the analogy of a carpenter, probably have the same. Somebody gets into carpentry because they enjoy doing woodworking and they enjoy that thing and they think they're going to spend all that time, but then as they work through the career, I'm sure they progress more and more to any of the front of the customer and talking about what the customer wants and talking about the scope and talking about jobs and.
[00:16:04] Estimating and all that other fun stuff that isn't doing the work Yeah, but so critical because you know that sets the direction for everybody else and you know it's a lot more it could be a lot more strategic and less task and tactical and you know There's a need for all that. So and i've seen a lot of your posts.
[00:16:17] Over the months and perhaps even the years about All the skills that people also need to be having in addition to coding.
[00:16:22] What are the other skills at the top of your head John that you think not enough software engineers emphasize. I think the key thing that we miss is that technical skills alone are About half the skills that we need software development.
[00:16:34] It's a team sport. We collaborate over software engineers. We collaborate with Other specialties within our companies and domain experts Product owners and so on ultimate we have to collaborate the customer or the users of the system as well and understand it So technical skills are at most 50% of our skill set The other side probably falls broadly under the term soft skills And I think again a lot of us really focus on we got in software because we like the technical stuff We like solving those problems of how do I code this up?
[00:17:03] How do I make this game or how do I? Do this interesting challenge, but we don't focus on the soft skills. We hope that hey computers are easy they're predictable. We put two plus two and it always give us four We put these lines of code in it's deterministic always do the same thing where
[00:17:18] certainly for myself, I like the idea of doing software and not having to deal with lots of people where the reality is It's mostly about people. So again as we talk about that scope increasing and it's all about your influence increasing There is a point which is fairly early in your career Normally in a mid to senior level where you need technical skills to get to that level And you need enough technical skills to maintain that level but you're not going any further without the soft skills Yeah, so there's a ceiling and those soft skills and that 50 soft skills becomes more important than your technical skills Yeah, yes the technical skills that were good enough, but the hygiene factor if they're good enough Your soft skills will take you further.
[00:17:54] Yeah. And what I've often seen, whether it's, at the big tech places, the smaller tech places, and even outside of tech, I've seen this in the law. I've seen this in, when I was in management, it's never always the, in fact, it's rarely the technically most sound person that makes it into the management leadership, strategic stuff.
[00:18:09] And there's a common trope to throw shade on them and say, Oh, they're not that smart and they got there by, doing X, Y, Z. The truth is a lot more nuanced than that, which is. That to get to the next level, the skills needed are different. And in fact, over time, a lot of them may not even have the technical skills they had 10 years ago.
[00:18:23] Like they'd get rusty on that. However, their impact on revenue, the business direction, team. Culture, allocation of resources, capability building, capacity planning are outsized compared to just the technical work, right? That's the different kind of impact that they're having. What is your view on that? I totally agree.
[00:18:42] As you progress up there, that influence and you say that ability to align resources, that ability to coordinate people, that ability to paint the vision and projection and, take your part of your background so you can pull me apart on this if I'm wrong, but. If you go into a court of law and you want to argue in front of a judge, being the most technically accurate lawyer, but without communication skills, you won't present a story, you won't present an argument, you'll just present a list of facts.
[00:19:09] I imagine another lawyer who can come and say okay, all your facts are great, but here's three or four facts, here's how they weave together in a cohesive argument, and this is why my case should win. I imagine the lawyer that has the communication skills that can sell that story, put those facts together with a compelling story and a compelling argument, will win over the one that quotes off 500 bits of case law.
[00:19:30] Oh, absolutely. All the right thoughts and isn't actually putting it together and creating that common thread that explains it. Absolutely. In fact, interesting you say this, we don't even have to talk in the abstract. This happened to Zubin. This, Zubin was a young up and coming lawyer who thought he was the bee's knees because, he spoke English really well and used technical jargon a lot and went to court in a smaller town in India.
[00:19:49] used exactly those strategies and then promptly got his butt handed to him by the judge who pointed out that there's no point you knowing all these fancy things and throwing all this terminology around if I don't understand you and the lesson that judge very kindly gave me which I've carried all my life is good communication is not what you say or how you say it's what gets understood.
[00:20:05] And what people take away, because if you're not taking people with you on the journey, you're not going to get anywhere quite simply, so now that's spot on, that's spot on John, and this is why I think, more and more people should really listen to what you're saying on LinkedIn, because I think your message is very powerful.
[00:20:17] And I noticed this in engineering , but even in law, the highly technical people prefer to stay in their zone of comfort. And in engineering, it's particularly tempting because the compiler is so much easier to deal with than people, so much easier, I think that's true for all of us, whether we're technical or not. It's always easier to stay in our comfort zone and not stretch ourselves, not challenge ourselves. Yeah. And people are inherently unpredictable, difficult. Ostensibly unreasonable and so on and so forth. Like it's challenging to deal with people, moods, time zones, all of that stuff.
[00:20:42] It's hard. So I sympathize with the aversion to having to deal with people, but exactly as you say, getting ahead Moving towards a result is generally a team sport. It's rarely solo. Like they say, if you, I think there's an old African problem. If you want to go fast, go alone.
[00:20:56] If you want to go far, go with others. And I think that's very true. That's very true.
[00:21:00] So let me ask you this. For aspiring coders, a lot of the folks that I end up speaking to, what do you wish they knew about the reality of software engineering that they probably don't know? I think it's that much more that they need to focus on dealing with people.
[00:21:16] Because let's take, you have a, You're new to the industry. You've maybe done some of my coding changes. Let's paint a kind of idealistic technical thing. You've learned your technology stack. You're competent in it. You've built some of my coding challenges. You've written a lovely CV talking about your university or bootcamp or whatever.
[00:21:32] You've listed some of the projects you rock up to be interviewed to me and. I ask you a question of how are you doing? What have you done? If you can't then have that conversation and you can't use your communication skills to talk about what you've done You won't get anywhere you'll still be stuck that again Just getting a job requires you interview it requires you use soft skills to talk to somebody to build some rapport To listen to their questions to really think about what they are asking To then structure a response that and again, I say this a lot software engineers should learn how to sell When you were interviewing you were selling yourself You are going in there and saying You know, what is the problem you were trying to solve when you interview me?
[00:22:10] Ah, okay So your problem is you need another bum on the seat. You can just talk about how you're the cheapest if that's the problem That's gonna solve. Yeah. Ah, your problem is You're trying to make your thing more reliable, and you need somebody that understands Python. I've built these projects in Python, blah, blah, blah, or your problem is you're doing low latency financial things and you care about that.
[00:22:27] Now, I'm really into C programming or C programming. I've really focused on cache coherence. I've learned a lot about multi threading and low latency. I've learned about what we keep you know So as you listen to those different issues, you can then talk about what you've done and how your experience relates If you can just look up and describe your cv And say I went to uni went to boot camp, whatever you're not Communicating your value.
[00:22:48] You're not listening to that person Establishing what problem they're trying to solve with this hire and telling them how you're going to solve it. Yeah very true. And I think I know I've been on the interviewing side more times than I'd cared to count where stock-standard question, John.
[00:23:02] So why would you like to work here? And the answer is because I need a job because I want a job because I want to earn this amount of money and that's the extent of the communication about their connection or their connection either the subject matter or the with the company and You always remember the people who bother to take the effort to know enough and then communicate Their own thinking analysis and feeling about the opportunity More than just well, i'm just looking for a job, But the ability to do that requires thinking and communication And that's just shows that you're going to be thoughtful on the job as well.
[00:23:30] You're going to be intentional as opposed to someone just going through the motions. You don't want that. You want someone who's highly intentional about where they allocate their time and their energy and are driven by a purpose or a sense of mission or a sense of belonging or wanting to do this over the other opportunities.
[00:23:43] Which I really wish more people would think about, not just coding across their careers, you're gonna enjoy your career so much and therefore be more successful if you're intentional about what you're doing, if you work to a plan.
[00:23:53] Fascinating. So let me ask you this as well John when should people Be investing in their skills with coding challenges, for example As part of their journey because I think a lot of people think just coding on the job is enough What is your view on that?
[00:24:05] I don't think just coding on the job is enough for most people to pursue the career that they want Again, a lot of us got into software engineering because we have some sort of interest in this. So It's crossing over some level of passion and interest with trying to earn a living and I don't like the way it's put that tech changes so often because It doesn't really we have a lot of noise very regularly and we have a lot of hype around new things But the fundamentals stay the same C was a common programming language when I started my career, it's still a common programming language.
[00:24:36] C was common, it's still common. A lot of more modern programming languages are building on C. We're still dealing with stacks, we're still dealing with heap memory. All the algorithms that we talk about in data structures have been around since the 50s or 60s mostly. Correct. Ignoring a few more modern machine learning things.
[00:24:54] Some of the concepts have been around for decades. 80 years. Yeah so it's a case of do it when you want to learn something new when you need a bit more of a challenge or I've used these coding challenges, a lot of them, for the last 25, 26 years to learn new programming languages. Oh, I really hope people are listening to that.
[00:25:13] Yes! Yeah I did some of the first ones in 1996 when I was learning C. I've redone them in several different programming languages since. I started liking the coding challenges newsletter when I was using them to learn Lust. I've since redone a bunch of them to learn Go. Because I wanted to, I thought it'd be fun to learn Go.
[00:25:29] And again, I'm doing that for my personal interest more than career. As far as when you should be doing for your career take them out when you need that challenge, when you need to bring back the excitement of writing code. Maybe if you want to write some code to practice for interviews, if you want to learn a new programming language, whatever's the appropriate time for learning.
[00:25:46] Yeah, so great, because ultimately, from what you're saying it's got to come from inside. There's got to be a curiosity, there's got to be a thrill on the inside. Doing it for the sake of it, doesn't have to be necessarily professionally goal oriented. That's a reward you reap but it has to be, it has to be something that you want to do because that's how you like to spend your time, to get better at your craft.
[00:26:08] Yeah, I think it's the same as going to the gym or training for any sport. If you don't actually enjoy being in the gym, doing your workout, it doesn't really matter what the end goal is. You're going to find it very difficult to follow through and be there. And particularly if you go to the gym for say a strength sport.
[00:26:24] It takes years to build up that if you just You're going to lose interest you're going to be disappointed. You need to enjoy the process as well. Yeah I see you've got all these guitars behind you as do I another great example, right and it never ends.
[00:26:36] I was watching a video I think it was John mayer explaining one of the licks from his songs and he said This is a guy who's been playing about as long as you've been coding, right? The quarter of a century, just to put it in perspective, that's a long time. And he said that the riff came from, the lick came from doing practice exercises.
[00:26:53] This is John Mayer, and my first thought is why is John Mayer doing practice exercises? And then I'm like, that's how he is John Mayer because he does practice exercises, because he pushes himself and it's funny. Cause there I was falling to, I knew better, but I fell into the same trap of saying, why does he need to do practice exercise?
[00:27:06] And I'm like, Actually, it's the other way around. He does practice exercises. That's why who he is. And that, that moment really came home to me. It was phenomenal, so look, one last question for you before I let you go. And I know I'm deliberately setting the cat among the pigeons, John.
[00:27:17] So I'm not doing this to, okay, let's be honest. I'm doing this to provoke you a little bit. That's true. So in a world of AI. My view on this and I'm not, I'm going to keep quiet cause I don't want to create an echo chamber, but in a world of AI, given all the buzz around AI at the moment, do the fundamentals matter or should we just focus on the productive boost, productivity boost of AI?
[00:27:38] So I think the fundamentals always matter. Yeah. AI is a tool and in its current state. It has some productivity benefits can be useful for that, but it doesn't have any fundamental understanding. There's no knowledge in AI at the moment. It's, and we're dumbing things down a bit here, but it's effectively a statistical engine.
[00:27:58] Yeah, it's a bunch of inputs predicting based on some probability that can be useful, you can, if it's something that it's seen before, you can put in a problem and get something out that might be useful. So if you, again. If you take a trivial version of, say, WC, you can go and ask some of the AI models to produce a solution, and they will produce a solution that works trivially.
[00:28:20] They won't produce a solution that works as well as the real WC does, that will generally tend not to scale. It'll make all the same mistakes that the beginner programmer will make, and they'll It will read the entire file into memory. To get you started, maybe to get you over that initial hurdle, it has some use for, or to do something very small, it has that benefit, but it's not solving the fundamental problem of understanding the issue, figuring out what the edge cases are, thinking it through, thinking about whatever questions you need to ask.
[00:28:45] And until it actually has any reasoning capability, it won't be able to do that. Sorry, go keep going. So AI can be a useful productivity tool for developer to look at something and say What else could I do or how's enough way this or how can I convert this code from say c to go or something? So things that it's seen before and things that look familiar the, in the training set effectively can be done and it can be useful for that.
[00:29:08] But it's never going to solve that by new things that you've, hasn't been solved yet. And we are going to want more things like that, not necessarily again, that we're going to invent new technology or solving, but business will evolve, take the legal profession again, as an example, the world doesn't stay still.
[00:29:25] We have new laws created every year in every country by our governments. And that changes everything. If you were applied AI to law, it would only work up to that training set. It would have no concept of any new laws beyond that. And again, it's predicting stuff. It's not reasoning about it.
[00:29:38] So it wouldn't be able to reason about how this new law impacts existing ones. They take new case law. It wouldn't be able to reason about the change. The next problem then with AI is it's predicting based on your input. So you need to give an input. You need the same for building software. You need to have a set of requirements.
[00:29:52] Also we give to an engineer and we, as humans suck at doing those requirements, that's always the weakest part of a whole process. Yeah. So let's say I was perfect to producing the code. You still got to sit in front of the AI. And put in a prompt, tell it what you want. Yeah, you've got to give it all the edge cases.
[00:30:09] And until we get better at that, it doesn't matter how good AI gets, we're still going to need somebody to sit and do that. And we still need to get vastly better at that as people. With our existing tool set. Yeah so Extending on from that. I guess the next question that I have for you is What about as a learning tool and just as a bit of context I see a lot of people commenting online and a lot of boot camps and other people saying that you know they're struggling getting students now because students are teaching themselves how to code on chat GPT and My perspective and that is No, they think they're learning to code in chat GPT because they wrote some code that worked again.
[00:30:45] It shows a fundamental misunderstanding. Okay, so you didn't use a hand-saw. So you'd use an electric-saw. And now you think you're a carpenter, that's not how the real world works.
[00:30:52] Other people have pointed out to me as a counterargument to my perspective that think of it more like a calculator. You don't need to do mental math anymore. Kids in schools use calculators because they don't need to worry about mental arithmetic anymore. And I actually find that argument interesting because I don't have an effective counter to it, but intuitively I feel it's not the same.
[00:31:07] I feel it's a reductionist argument, but I haven't yet evolved my counter argument to that. What's your perspective on that? So let's take the math. How do you find the area of the curve? Where's the button for that in a calculator? True. Yeah.
[00:31:20] So your perspective is, it'll take care of some of the lower level trivial stuff, but not actually in any applied sense be particularly useful. Yes. You need to better translate from the high level problem and figure out what buttons to push in the calculator, to use the calculator.
[00:31:36] Could a counter argument then be that a lot of people who use calculators these days are accountants and bookkeepers and, people in small stores and stuff, and they don't need more than that. They're not calculating the area of a curve. And that's actually what a lot of software engineering jobs are in the world.
[00:31:49] They're not needing to calculate the area of a curve in this metaphorical example. They just need to write some more front end or write, fix a server or identify a bug and, process a ticket. What would you say to that? Yeah, I think that's an issue that we get. It's very easy to overlook an arc gate, is that most of us, again, arcing back to the beginning of this.
[00:32:07] We don't need all that complex DSA. We don't need to solve all these high performance issues because most people are writing something that basically is getting some data from a user, storing it in a database, and at some other point pulling that data out and producing some report, some overview of it.
[00:32:24] And you could argue that Facebook is that, for example, or LinkedIn or any other social media. It's true. Typing data into a computer, it's stored in the database, produces a report. Now we call that report your timeline or your feed or whatever, but.
[00:32:35] Absolutely. Effectively, it's pulled relevant data out based on a query that you've given it, and it's summed it up for you. So an awful lot of what's happening is basically building CRUD applications From that point of view again, we could automate an off order that but even then you step back and say Let's say i'm building this credit application for a charity thinking about something that I did 28 years ago Fundamentally the charity wanted to record.
[00:32:57] What donations did we have? Who do they come from? What do we do? That sounds fairly generic sounds like we could just do it. And then the tax law changed in the UK . So there were little nuances that came in there and then there's a little complications of are you a higher layer although like taxpayer?
[00:33:12] Are you a uk based taxpayer? If you are the law now requires that you correct your name and address so that you can go back to the So what started off is a very trivial thing starts getting these little nuances that have been brought in from the real world You so again, it's never so much about the code.
[00:33:26] It's about capturing those little nuances and going away and talking to somebody and saying okay, what, in this case, how do we handle that? What are the requirements for that? Oh, we now need to produce another report for the tax plan. So we can claim this back. And that's value because we'll get 20 to 40 percent uplift on the charitable donations back from the tax plan.
[00:33:42] So all these little subtle things bring in more complexity that. Again, it's complexity from the world. It's not complexity from the code. Very rarely is the code, the complex bit, Facebook or LinkedIn or a lot of these other big tech companies, they're not particularly complex until you get to the fact that there are billions of users.
[00:33:59] And then we get the complexity because it's so much data. Yeah, no, that's, and I think that's absolutely the right perspective, whether it's, I know that people are worried across multiple industries, not just coding, like multiple industries, the impact of AI. And I think I can appreciate the concern.
[00:34:13] I have no doubt there's going to be considerable impact, but it's not an Armageddon situation by any means, because it's basically a new tool. And we're still trying to learn where it fits in our existing workflows and which bits we can safely delegate to it and which bits we can't. There's no mistake about the fact that there is a delegation piece that's involved and we still have to be in control.
[00:34:31] We still have to be in control and take some of the decisions there. Now, the other side of that is AI doesn't solve all the problems, just the same as Calculus, spreadsheet doesn't. Fundamentally, there are still Only a very small number of businesses are fully building software and have got all the software tools They need to digitize their business.
[00:34:48] There is a growing demand for software engineers. We are in a recession or difficult financial circumstances or whatever Technically correct term for your country at the moment, but we are in the similar effect to a recession We've had a lot of layoffs. We've had a Pull back on people and making investments in their businesses for the last year or two Yeah, and a preference among senior people across the board not just in engineering Just the way to keep your powder dry and keep your capital going.
[00:35:10] Yeah, totally Yeah, so we've had that restriction but fundamentally aside from the speed bump we've got at the moment More and more businesses are going to be doing more and more technology, needing more and more software. Yeah. That's got to come from somewhere. Yeah. So yes, speed bump at the moment, but I'm sure that in the next few years, it's estimated we have about 27 million software developers worldwide at the moment that was expected to grow to 40 million by 2030, if I remember right.
[00:35:34] We've hit a bit of a speed bump, but in the next few years that will get back on track. There'll be an demand for more and more software engineers and just like the calculator didn't put accountants out of business Exactly. Yeah, there will be a need for more people to do that Yeah, the job might change a little bit, but we'll need more people Yeah, I firmly believe that's true simply based on history like i've been through a few recessions too, and it's always There's no end in sight.
[00:35:56] There's no light at the end of the tunnel. And before you know it, people have forgotten. And then very quickly, they've forgotten that they even thought that there was no light at the end of the tunnel. And they even forgot there was a tunnel. And then they repeat the same mistakes. And we go into the next recession.
[00:36:05] And it just goes on and on. And, so I've just started to, I just realized you just got to wait for the storm to pass. Every storm runs out of rain. This is just another one of them, look, wonderful conversation as always, John, thank you so much for your time and for, for all the many perspectives.
[00:36:16] And I really hope that people listening to this just slow down for just a moment and listen to what you're saying, because what you're saying is based on proper, real experience, a real historical breadth of knowledge, and just practical wisdom that comes from having lived a bit of life in multiple contexts in multiple periods.
[00:36:32] And not just, Having grown up, which I think is part of the problem, is not just having grown up in the world of social media. I think a lot of people who have grown up in that world have a little bit of difficulty contextualizing what the world was like before. And going back to your point ultimately, regardless of the trend, the fundamentals of software engineering are Pretty much near constant.
[00:36:49] They change much less fast than people expect, and that's the same thing for job markets. That's the same thing for human nature. It's the same thing for what companies look for. It's not about the hot new trend. The principles haven't changed in hundreds of years when it comes to recruiting and job markets and how you know how making a living works.
[00:37:04] Human beings have been making a living in very difficult circumstances for a very long time now. The principles are the same. So for sharing that perspective any last words to those who are listening. Before we wind up I think firstly Thanks for having me on Zubin. I think for last words, it's that think about it don't take anything that any of us say as fact It's all we all view the world for our own lens our own perceptions and our own perception is our reality.
[00:37:27] So Question things don't just take what in social media as gospel. Think about it. Think about the pros cons try and incorporate it and Yeah, approach things with open eyes Very true, and I will say something else for those who are listening for those of you know Those of you out there who are listening who want to try coding challenges.
[00:37:43] I encourage you to not think of it as a tutorial I encourage you to not think of it as a this is a youtube course or something like that Coding challenges is a craftsman's way of learning. It is very much a do it, learn, research, hit the problem, solve the problem, iterative process. It is not, I don't trust courses that give you all the answers because all the actual decision making and challenges are hidden away from you and you've learned nothing but the end result.
[00:38:07] So those of you are trying coding challenges, Bring to it a craftsman's mentality, right? For those of you who learn to play music, you know that just watching someone else play a great lick on the guitar is not what makes you good. You've got to sit and practice it over and over again, and then you get the intonation wrong, and then you get the timing wrong.
[00:38:21] There's so much craftsmanship involved. It's the same thing with coding, right? It's never your first three attempts that are going to be great. It's going to take iteration after iteration, and that's the learning. So those of you who try John's coding challenges, Remember, there's a craftsman in you that wanted to be a software engineer.
[00:38:34] So give expression to that craftsman, regardless of what a 90 second TikTok says. Okay. Give yourself the time you need to succeed. Thank you again, John, for joining the show. I really appreciate it. And I hope you have a wonderful day. Cool. Zubin.
[00:38:44] Just subscribe, you know you gotta do it.
