Build Software To Get Good As Software - Interview With John Crickett

Maybe maybe the idea is that if we get good enough at all the other parts of software engineering, we can just have AI do all the embedded stuff for us and then we'll never have to worry about that. Why do we treat software development differently? If you wanted to get good in the gym, you want to get bigger and stronger. Do you just watch YouTube videos about it, read articles, and follow the celebrities that seem to be big and strong, and then by virtue of that, you become big and strong? No. You have to put time in the gym, into your nutrition, into your recovery. All of those things need time and effort. So, why is software development different? Hi, my name is Nick Cantino and I'm a principal software engineering manager at Microsoft. In this video, I have a super awesome guest. His name is John Cricut and he is the creator of coding challenges. It's an awesome newsletter. John puts out tons of great content and one of the major focuses that he relays to people is that you need to be building software to get better at it. This is one of my two primary messages that I try to share a lot. One of them is building software to get better at it and the other is the importance of communication as a software engineer. So, I thought this was an awesome chat with John. He's got a lot of experience and a lot of really cool insight. So, I think that you're really going to enjoy it. So, stick around, check it out, and I'll see you next time. Well, I I've had it quite easy till now cuz up until the last year, my wife has done all the teaching and they've done a lot of online courses. It's only now as they move or the eldest has moved to Alevel stuff that okay, it's at a higher level and she doesn't feel confident doing that. She didn't study math and computer science to that kind of level. So, um I've taken over a bit. So, it's still quite new to me. >> Okay. It's worked quite well. Um, again, we've we get a lot of online courses and there's online support. So, he's got some online tutors for the math to help with that. Um, the computer science is the only one I'm doing entirely by myself. Uh, and it does a lot of self-study at the end of the day. For me, that was the real benefit of the home education is that they really learn how to study and structure it on the loan and they get also not being in schools, they're quite focused. they can quite often get through their educational material in two or three hours in a day because you don't have changing lessons. You don't have that context switching. You don't have I mean it's a bit like when we want to do focused work, you get far more done if you've got 2hour block of focus time. >> So instead of doing a a 40-minute lesson on computer science, then a 40-minute lesson on math, then a 40 minute lesson on something else, they might sit down and say like this morning is computer science and do it for two hours in a focus block. and they get a lot of it done and and get far more uh work done. So, it works quite well, don't we? >> That's uh that's interesting. Um the the focus part, right? I I can imagine for some people like I'm even thinking about people working from home right now. Like I work from home. I have employees that work from obviously tons of people work from home after COVID and everything. And the the focus thing I think for a lot of people is extremely difficult. So, it's really cool to hear that. Uh, you're saying for, you know, for your children kind of doing their schoolwork, they actually are able to sit down, focus, get through it. Like, that's awesome. Um, I don't know if like if I was when I was growing up if that would have been a thing. Like, I probably would have been like, "Mom, I'm not doing this. Like, I probably want to take a break like every two seconds." So, uh, very cool focused. Some of them are like that >> through it cuz ultimately >> my my my eldest is is totally focused. He will sit down and do it. >> Um >> my youngest is completely the opposite. Give him take your eyes off him for 5 seconds. He'll have gone and grabbed the guitar and he'll start playing. I was curious because with especially with homeschooling and kind of you you have a a teaching approach that you're going to have at home and I know that when you're helping guide software engineers online a lot of the focus that you put out there is like building things and actually practicing putting software together is a great way to learn and one might argue the best way to learn maybe I don't know if I can say that for everyone but I kind of feel like It's probably one of the best ways for everyone. So, I was curious like when you approach teaching in general, like how do you is there a way that you navigate that where you have a more generalized approach for everyone and then you drill in a little bit for more specific like tailoring it to to people's needs to accommodate how they learn >> on the best way. I don't know that it's the best way either, but I think it's an essential way. You know there are many different ways say to learn to swim or to learn to paint but ultimately to learn to swim or to paint you have to get in the water and swim. You have to pick up a paintbrush and paint. So yes, you can get a lot of knowledge in my book. You can watch a video. You can go to swimming lessons and have somebody tell you what to do. But ultimately you will never learn swim if you don't get in the water and swim. So yeah, we can debate whether it's the best way, but I think it's an essential way and you you're not going to become a software engineer if you don't build software, right? The I think that's a really good way to put it, right? It's not that it's not that the other, you know, um sources of information don't have value, right? saying saying something like uh practicing programming or building software is valuable for learning or a very effective way of learning or even if you were to say it is the best way of learning that does not suggest that the other ways have zero value right that's I think sometimes people might hear that and go well hold on like I actually find watching tutorials is useful and it's like yeah it is like it's not it's not saying that it's not >> yeah but again you go away and watch 200 hours of tutorials without putting your hands on a keyboard, grab a coffee, then sit down to light some software, you will not be able to do it. You will need to have done something with that 200 hours to >> to be able to apply it. And that step is to, you know, take small baby steps and begin applying it and begin building real software, >> right? >> You can't just go and watch 200 hours of YouTube and then build lettuce. You have to watch a couple of hours of YouTube or read a book or whatever is your your stepping stone to get enough skills. Then you write a function or you write a test. Then you maybe watch a bit more tutorial, read the next couple chapters of the book, apply a bit more of it until you get to the point where you can build some real software. And it's that point when you start building a little software, you go, "Ah, actually, I don't know how to do this. I don't know how to test my software." Okay, cool. I've seen all this stuff about data structured algorithms, but I don't know how to actually use one, >> right? >> What about design patterns? >> Where do I use them? Do I use them? Do I care? Do I not? >> You know, should I be using them? And >> right, >> all those things you you you need that actually apply it to help it sink in and to gain the experience and to also have the experience of getting to the blockers and asking the questions that causes you to go, actually, this book was great. It's awesome. I learned all about the syntax language, I learned all about how to use for loops, while loops, declare variables. But actually, if I want to create a data structure that composes of three different types, how do I do that? How do I create class or structure or le type or whatever it is? And you're only going to come against those blockers and and find that bits of knowledge you have to acquire by, you know, jumping in the pool and trying to swim, grabbing the keyboard and trying to build something, >> right? So yeah, >> it's interesting. Like >> I I do think back to I'm trying to think about my own learning process over the course of my life and how that's probably changed. And if I rewind really far in my life, I I feel like when I was a lot younger, learning stuff like I I want to say like, oh, I didn't have to practice, but I think I was practicing and not even realizing it. So even like in elementary school, high school, if it was math problems and stuff, math seemed to come pretty easy. And I remember thinking like, "Oh, I don't even have to practice this." But the reality is probably how the teacher was going through it in class. I was probably practicing at that time. And then homework, I was like, "Oh, I don't I don't have to spend as much time. It's so simple." But in in university, the the learning or the teaching approach was very different. And I struggled a lot in university going from high marks in high school, not having to try to university feeling like I can barely pass. And I think I'm trying to tie this together here, but I think what was happening was that I just truly wasn't practicing. And it was like I'd hear these advanced concepts and I'm so used to thinking, oh, like, you know, I hear it or I see it and it's just going to it's going to stick. Then it doesn't like I had to I had to spend time. It took me my entire university career, especially with math, which used to be a strong subject, being like I have to go do these problems. It's the only way that I'm going to get better at them. >> Yeah, absolutely. I think my experience with math was very similar. It was very easy up to kind of university level. It just seemed obvious someone explained it and you're like, well, yeah, that's that's obvious. And then get to the university. >> Yeah, I actually do need to go and practice this and apply it to understand it and have it stick. when you were speaking there it just occurred to me it's quite interesting that when I started learning to code which was somewhere around 82 83 um I kind of didn't have any other option than learn by doing because I had the book that came with the computer that explained basically >> and assembler in the back of it in like I don't know 20 or 30 pages of this lingb band manual that came with the computer and that was it. So you know I could read what statements were available in the basic and what assembly instructions were but nothing else. There was no YouTube. There was no way to go and get online. And there was you went to the average bookshop. There were no computer books about programming. You know, went to the average library. There were no books in the library about programming. So, kind of had the manual with a brief introduction to the language. And then it was like, >> right, >> well, I've seen this computer game. I want to do something like that. So, it was just almost stumbling about blindly just trying to figure out. It's like, what what if I do this? What if I do that? I want to put thing on the screen now. I'll put something on the screen there. How do I make it move? >> Right. >> So, you kind of had no choice to learn by doing, which is I think also why I've fallen into this pattern and it's become a habit over the last 40 years. >> That's very interesting. It's it's like uh I'm not sure a good way to phrase this. It's almost like the lack, if I can say this, like the lack of resources that were available instead of just saying like I'm I'm trying to think about when you have so many resources available. It's e it's like the easy path is picking a resource that you can watch, listen, read, right? You're just like, I can click a button and have information. Like truly, like the amount of effort that goes into that is very simple. It takes time. You might have to watch, listen, or read. So there's time, but to to do the thing is so simple because you press a button, you're on a new page with new information and you try to absorb it. So I feel like when it comes to learning that feels like a path of least resistance probably for a lot of people but the reality is like a path of least resistance to like accessing information does not mean that it's an effective way that you will uh retain it number one and then be able to like leverage it when it comes time to to coding. Yeah, absolutely. To to take another analogy, you know, you can watch all the videos you want on YouTube about deadlift and squat and bench press form, but you ain't going to get stronger if you don't get in the gym and actually lift the weights yourself. >> Yep. Absolutely. That one really resonates cuz I'm really big into the gym like outside of software engineering. So, um I've I've used an analogy like that somewhere before, but uh I I love that when it comes to I Okay, so when you use like an analogy that is something physical, right? Like uh it could be a sport, it could be the gym, it could be anything like that. It seems so obvious if you were to say like, "Look, you want to get good at playing basketball? Like do you just go watch every video about basketball, read all the basketball books, you know, follow all the basketball celebrities and then all of a sudden you're like I am good at basketball like that. It just doesn't happen and it sounds ridiculous to say it. So I kind of feel like why do we why do we expect that for coding and software engineering? Is it because we think and when I say we I mean probably a large a large amount of people probably approach it this way. Is it just because it seems like it's such an intellectual thing that as long as I can read about it, I must be able to, you know, have it come out of my fingertips easily. >> Yeah. And maybe it's also partly all the boot camps that have started to persuade people that you can just, you know, pick this up in 12 weeks. Um, I mean, there's so many analogies as, you know, we can there's guitars on the wall behind me. Again, you can't learn to play guitar without picking one up and and playing it, >> right? And it's unavoidable. It will take you hours and hours of practice to to get good and develop the muscle memory and to find that >> your style. You just can't avoid doing that. But we have that image I think from boot camps creator that suggests that you you can just watch a video, go on to the boot camp for 12 weeks and tada, you're a fullyfledged developer. >> Right. That's um the boot camp one is interesting because I do feel like I'm pretty divided personally like just in general the concept of boot camps. It irks me a little bit but I think it's not because the the just the concept of a boot camp. I think a lot of it's the implementation and the the advertising of boot camps. I feel like um like if you wanted to have a good advertisement for a boot camp like what what are you trying to drive home? It's like look like it's not that expensive and we can minimize the time and you'll be so good. But you have to keep doubling down on that messaging to like be better than the other boot camps. But at the end of the day, like there is some amount of time as a human being writing and practicing writing software that you need to do to get good at it. So um a boot camp that promises something like, "Hey, it'll only take 12 weeks and you'll be awesome." It's the same thing even for courses. I put out courses and I don't want to be in a position where like, hey, just watch my video course and after 5 hours you'll be an expert. Like that would be an absolute lie to say you'll have any expertise or mastery after something. Will you have more information to use? Absolutely. But it's not going to solve the building of expertise as you said with a guitar. That's literally going to take time. It's no different with all these other skills we're talking about. >> Yeah. And I think the trouble with boot camps is there is such a vast range of them. There are some that I think as we both talked about Cali before she talked about Pa some people take five years to go through that process, >> right? And then there the ones at the other end that are maybe get l quick schemes for the loaners that are very much focused on you know in a couple weeks you can do this so then you'll land a high paying job but they haven't got a track record to demonstrate that and they're very much focused on the easy to learn and quick to learn skills where that's not likely to be true and you're not going to replace the kind of level of knowledge that you get maybe on a degree program combined with somebody's passionate interest and it's doing people a disservice. service. I think it's I wrote a post on LinkedIn the other day saying there were too many software engineers and not enough software engineers and I think we have the same thing then a lot of boot camps have focused on how to become a web developer learn JavaScript learn HTML learn CSS you can build front end stuff away you go you're a software engineer so we've got loads of people coming into industry with boot camps chucking them out after 12 weeks but we don't have people that are >> say learning more backend development or learning cyber security or learning data engineering or systems environment. And I've never yet seen a boot camp or anyone going, "Hey, become an embedded developer." Yeah, it's really cool. I can see or that's a device driver. We still need them. We still need all those software engineers. >> Yeah, that's interesting. That it's such a good point about the embedded part. Uh like, yeah, I see boot camps coming up all the time, but truly I've never seen an embedded one. Um maybe maybe the idea is that if we get good enough at all the other parts of software engineering, we can just have AI do all the embedded stuff for us and then we'll never have to worry about that. Um but yeah, I I definitely see the uh there's a lot more front-end stuff for sure. Um I think, you know, I think kind of uh it's back to doubling down on this like I'm not trying to say front end is just strictly easier. I'm certainly not good at anything front end, so it's different set of skills, but I think the amount of learning Yeah, it's easier to sell on the boot camp because you can see something. You can create a portfolio and you go, "Look at all our students. They've built these things." So, it's >> it's not necessarily easy as a thing, but it's easier to sell the results and sell the outcome. Where if you say, "Hey, look at our students and here's this little Raspberry Pi Pico and they've done some software and they're honest." >> Yeah. And it makes LED flash, it doesn't have the same pitch and excitement as it. So, >> yeah. But anything that you can't see like that is going to it's going to have a a penalty against it in terms of like the sexiness of the boot camp and how appealing it is to go learn it. It could be extremely valuable, but like it just doesn't have that appeal, especially for people that are like trying to get into the industry. If you were like, "Hey, look, I could uh in this boot camp you're going to learn how to orchestrate all these distributed systems together." Like that could be very valuable, but people are going to be like like what do I see at the end of that? like >> nothing. >> Absolutely. >> Very interesting. I had a I I feel like you will have a very good answer to this and I was really curious because I think it comes up a lot when when people are working on projects or they they're like okay I keep hearing people saying I need to to work on projects to become better at at software development. They go like where do I start? Right? I know and and I know you have an awesome newsletter with lots of projects in it, but do you find that people struggle even with a list of projects to go like like great I have a list like I still don't know how to start like there's a list where like which one's number one that's easiest for me or best suited like people seem to get paralyzed by it. >> Yes, that's definitely something I'm noticing now. So, one of the things I'm going to do on coding challenge is start to put together some load maps to help with that because I've had quite a number of questions. >> Where do I start? So, again, I'm quite focused on being, you know, led by my customers, my leaders here. >> Um, I encourage people to try and think about that as what is the goal for your learning? What are you trying to learn now? And what is your goal for your career? Where do you want to go? You know, if you're trying to learn a new programming language, I suggest you start with a CLI program and work through till eventually you build. For my interests and for what I can help you with, well, I end up suggesting something like lettuce or memcache and build something that's server because then you're dealing with concurrency, you're dealing with networking, you're dealing with protocols, you're dealing with data um data structures. So, you touch on a lot of things and that gets you a lot of different languages and elements that you can learn in a language. And again, if you've built a CLI program, then you've built a server, you've learned a good chunk of the language. Um, if you're more focused on say you're learning data structures and algorithms, there are other things you can do. I might suggest that you you focus on things like how do I implement git myself because there's some fun stuff there that you can learn how git works under the hood and learn some data structure algorithms that use there. You could build your own diff tool. Again, building your own diff teaches you a lot about some dynamic programming algorithms. >> And you can then take that diff component you've built and put it into a git client because it's part of that. >> So again, that's a good way of, you know, picking a learning path of figuring out what it is you want to learn. What do you want to focus on? >> I know maybe if you want to focus on design patterns, you know, you want to pick a bigger project like say building a a lettuce clone. If you want to focus on how, you know, I'm maybe a what I used to think of as a CIS admin and I want to understand kind of how infrastructure or maybe a network operator. Want to understand how the infrastructure on the internet works. Then maybe go away and pick some of the projects that get you understanding low level protocols. So build your own trace loop, build your own NTP server, build your own DNS resolver and start understanding those protocols because that will make you go through and how does this work? What happens here? dig into things like BGP and and you know really get an understanding of so focus on what what's the goal of the learning and then what projects will help you achieve that. >> That's um I mean to me that makes a lot of sense. I've I think when I hear people asking this and sometimes it's not even about which project should I start with. Sometimes it's even more like before that it's like what's the best programming language like hi I've shown up and like someone just tell me like what the the best thing to program is like I just want to be a good software developer tell me what to do and it's like the problem with that question I mean obviously you know this is like there's it's just so open-ended and there's not going to be a a best right you said it very well like what's what's your goal if if there's no goal that's given like how can anyone possibly even start to say what a best is? If someone said to me like, "What's the best programming language?" I'm going to say, "Well, C is obviously the best programming language." It's not the best programming language. It's the one that I like to use. Like, so you get all that you get is like a 100% bias when there's no end goal. There's no there's no analysis put into like, you know, what do you need to do to work in that direction? It's purely just opinion. So uh I I struggle trying to give answers to people. >> Maybe the answer there is your your goal right now is to figure out what do you want to do. So go away and build a project in JavaScript on the front end. Then after that build a project on the back end say with C. Then after that build some system level code with Go or Rust. And then after that build a CLI tool with C. And then once you've done all that, go, I enjoyed that project. That sucked. Then maybe try a bit more felt you enjoyed. And and figure that out from there. >> And it changes over time. I mean, I I started off on basic because basic and assembled came with my computer when I was seven, whenever I started many years ago. Assemble was a bit too much for me at that age. So I started off on basic and that was fine. You did that for years. Uh and then as I kind of became a teenager, I started to get exposed and thinking a bit more about career and realized I was not going to make it to fighter pilot. Um which is probably a good thing, but never mind. Um I started to want to learn a serious programming language. I was starting to look down on basic. It's like nobody's going to use this professionally. I want to learn C. So when I did my work experience, I had a week with a company doing work experience in a six form. So that's at 17 years old. And they said, "Well, I don't really know what to do with you for a week of work experience. What do you want to do?" So I said, "I want to learn a proper programming language. I want to learn C." So they sat down. Here's a great big manual, big manual like that of C on vax VMS and here's a terminal and you can have a go on that and there's a C compiler. So I had a great week learning C um with a chat there. Thought this is great. I spent time through university studying C. University made us do Pascal apart from C course which I ended up kind of taking over a bit because the instructor couldn't make his C compile and I've been studying it so I had to step in and help out. and they mostly use Pascal. So you it's not really their fault. Graduated and thought this is great. Of course, my first job. Can you like some code in Visual Basic for the next six months? >> Visual Basic. Yep. >> So yeah, I was delighted at the end of that project when I got a chance to work on C. But then I also in the year before that I joined what was the association of C and C++ users and I started to become exposed in C++ and I was then looking at C++ going hey I want some of that. >> Why do I have to keep why do I have to keep writing a link list? This is waste of time keep doing this every single time right >> C++ has a list in the data structure. Why do I want a hash table? You know I've done it enough times now. Ling it for each new project and each new customer is crazy. I just want a map out of it. So I moved to that. So I think you you you know the part of that is when I was at university doing Pascal, we built CLI tools. Um when I moved into my professional career and started doing Visual Basic, it was very much gooey based stuff. >> And that was quite satisfying. Then you you know you actually got a UI up and you can push buttons and click and see stuff. And uh the first bit of software that I had that you know would play a video it was quite awesome to actually put something up and have a video play you know it seemed like really futuristic and powerful >> right >> then I moved that so you know taste changed over that time you know you can evolve and you can move and you can take those skills and um you know as I say by the time I got to C six months into my career I'd worked in Pearl I'd worked in C and Pascal Delelfy Visual Basic Um, and then started doing some C++. So, I'd already touched about six different languages and had exposure to all sorts of different things. The Visual Basic project, ended up getting into some embedded coding for a smart card reader. >> Oh, cool. >> It, you know, it it exposed me to all sorts of different things. And again, the early days of the internet, so throughout university, I'd had a one holiday working at ISP and learned Pearl and built CGI scripts and some HTML and CSS. No, not CSS didn't exist back then. So again, that that that try lots of different things and figure out what you like. And you know, our careers are quite long. There's plenty of chance to do something for a bit and then pivot. I mean, some people are changing careers into it. Those of us that are in IT, you could be a front-end developer for a bit, then pivot to a back end. You could be a backend developer, pivot to data engineering, >> right? >> You can pivot into management and back out. Yeah. And that happens all the time. Like there's lots of people that do that. And especially because again, different skills, different things that you might enjoy or not, and you try it out and you go, "Hey, I'm in this for a little bit." Like, do I prefer this or am I missing things? Are there things that are too challenging? Like, is your expectation of what you went into, you know, matching what you thought? And if you preferred something else that you've done already, you might go back. Or you might say, "I don't like what I'm doing now, and it might be better than what I did before, so maybe I'll try the next thing." But being like curious and not like I think people I I I shouldn't generalize like everyone obviously, but I think there's a lot of people that see it like once I get into something, it's like a it's almost like wasted effort if I need to switch. So let's take you know a programming language because I think this happens a lot with people just starting out. They're like tell me the best programming language and it's like because I need to hyper optimize the amount of time I invest into this to become good at it and if I ever have to pivot from that then like I'm just wasting my effectiveness like my whole career is going to be shot. And it's like no like you you can change and you you listed off from like your own career all of these opportunities where you were like I tried this then I went here a lot of that is so different you know different programming languages different domains I just feel like a lot of people feel perhaps like either trapped or it's a it's a waste like but all all these skills are transferable right >> they are but as an industry we're really really bad at showing that. You know, we put out job specs that are shopping list of you must have C#, you must have ASP.NET, you must have SQL Server, you must have uh IAS or whatever and and 20 different things and say you must have this. Well, we don't actually recognize that. You know, if you like Java and you're familiar with that or C++, you can come along and start learning C and it's not going to be like >> it is a different programming language, but it's not like you're switching from >> speaking English to speaking Chinese. It's not as hard a transition. It still has the same constructs. It still has the same approach. It's still >> It's more like a different dialect than switching a completely different language with a very different structure. >> It's a very good way to put it. Yeah. like a dialect change. >> Yeah. And the same with data structures and algorithms. It's not like C has different data structures and algorithms. Yeah. We all fundamentally have hash tables, link lists, arrays and so on. Yeah, there's different implementations of it and different approaches to it and maybe different names and different emphasis, but fundamentally the data structures and algorithms of computer science are the same across everything. So we don't do a very good job of recognizing that in recruitment and how we treat people. So I think that forces people then to become I am a Java developer, I am a C# developer rather than I am a software developer >> and I'm happy working in any of these things. And I know I've seen that you know when I've needed to look for jobs I've seen that and that sometimes people look at my CV and go well what are you John? I'm like well I'm a software developer. I don't care what language I'm working in. >> Right. >> Right now, I really like Python and Go. I've really enjoyed list. I used to be massively a fan of C++. Quite enjoyed Pearl when I was doing it. Um, you know, and I don't really care what I do. I will pick up and use whatever tool the team's using or whatever seems the most appropriate. Yeah, they're just tools, but they become part of our identities. That's a I think a good reminder for people, right, is like the programming languages truly are just tools. Like um like I I'm guilty of this myself like I do like a lot of C development. I gravitate towards it because in my own experiences like when I've encountered different domains and stuff, different challenges, I'm like I know that based on how much C# I know I can make C work for this. So, is it this is a a weird way to put it, but like is it the best tool for the job? Like in general, maybe not. Like depending on what the job is, it might not be the best thing, but if I'm developing it and it's just me, if it's just me, then I might go, "Yeah, it's the best tool for me to use because I can be most effective with it." But that fundamentally changes in a software company or a team because if the team is most effective at using some other language and it happens to be better suited for whatever the domain is like yeah like I'm not going to come in and say hey everyone here is using Python but I've just joined the team and I really like C so I'm using C guys sorry like it doesn't work that way right you you use the tool that's best suited for the job and best suited for the job can change depending on the context itself, whether it's the domain, the team composition, like all sorts of things. So, uh truly like I think you're in an awesome spot where you're like you you you come out and say like I'm a software developer. I am not like a a specific language developer. That's awesome. >> Yeah. And I think the the the thing that people forget too much about that is that the most important part of that context is what does the team know? What's the team going to be effective in? Because the most expensive part of software development is the people and that that you know our time. So maybe C++ is the best language or rest is the best language what you're doing. But if your team all know C that might be a better choice for your project because they're familiar with it. they're going to be put to it and maybe we'd get two, three, four, five% better performance out of the alternate language. We can buy a bigger faster server or a second server or a second computer for a few thousand few thousand of a software engineer's time or team's time. It it it's measured in minutes, you know, across the whole team. It is just it's not where the focus is. I know another pet peeve on that is that performance fairly lowly boils down to the language. I mean, yes, if you're doing high frequency trading or something that needs ultra low latency, you need to be in a compiled language, right? C++ or >> without garbage collection or with very carefully managed garbage collection. 99.9% of us are just not building HFT solutions or computer games. For most visit doesn't matter. the architecture is going to matter more and the programming language is a fairly small part of that and again right pick for the productivity of the team and the ability of the team to deliver the business value. >> I wanted to come back to something else you said earlier about you know trying things out and moving careers and I think the other aspect to that is sometimes external factors also you know play into it. So in 2018 I moved away from management and moved back to being an uh individual contributor and that was purely because my eldest son is dyslexic. He was coming up to his exams as a manager in a company. Um I was traveling a lot. I think I went on 26 different trips overseas in a 12-month period and it's a lot. >> Yeah, it was cool. I love traveling. It was great. and I I was going to see some great people, but when I wasn't traveling, I didn't want to go to the office and commute as well. I was like, >> right, >> I got a new boss at the time who went, "No, everyone's got to be in the office." >> So, it was a case of, "Well, >> I don't mind the traveling, but I can't do the traveling and go to the office." >> The office became non-negotiable. So I left management and went back to contracting and pursued an IC career because I found a contract that was remote and I could support my my son's education. >> Right? >> So again, you know, life uh life events, should we say, you know, can change that context and change what we want to do and change what our priorities. So again, it's there's always options to change. And you know, I've been back and forth between being an IC and a manager. I've been back and forth between permanent and contract on my own business. Um, and that's that's I guess the joy about this. You can be fairly flexible, >> right? I think that's a it's really good to hear that. Like I think it's a valuable thing to hear from someone in their career that has switched between things. Not even like you've talked about technologies before like programming languages which I think especially for people just starting out that's so critical to hear like yes you can and probably will learn more than one programming language it's not a waste of time but even like how you're describing going from individual contributor to manager and back like and maybe like maybe I'll get you to say like do you feel that going into management and then pivoting back like was that a waste of time in terms of do you feel like, oh my goodness, I'm so behind in my my software development because I pivoted and then came back. >> No, not at all. The I think there are three distinct skills that I I I value and I think are quite crucial. And from the experiences I've described, I've I've built up my technical skills and I've done a lot of stuff that's given me a good technical grounding. Right. >> I've started my own business which has given me more of a commercial awareness and I've been in small startups. So that commercial awareness has been very very useful because we don't build software in a vacuum. We're trying to do something for the business and it gives me more of that focus of like why are we doing this? What's the business value >> right? >> Or what's the organizational goals we're delivering? So it helps me ask better questions about why we're doing it and think not just hey it'd be really cool to do this in Python C# or whatever but hey the business value is that we're trying to do this we're going to integrate with a team who are working in C. So we need to think about how we're going to do that. Not just kind of hope it works out because we've picked whatever's our favorite cool language. And then the other side is having worked as an IC and as manager you know kind of get a bit more context. You understand why things have got to happen. You understand more of how to deal with people. You get more of that experience of understanding that you people are all unique. We're all different. Dealing with people is messy. You know, with a computer, you put in 2 plus two. As long as we're doing ins, not votes, you're always going to get the answer for. It's consistent. It's always going to be the same. They they're logical. You say something to somebody one day and they'll be delighted. Say the same thing the next day to them if they're having a bad day, but they could be extremely peeved off with you, >> right? >> And all that's changed is their mood on that day, which maybe you don't know. You don't have that context. >> Sure. >> Yeah. But it gives you that appreciation by having gone to management that you know everybody's kind of like baggage everybody's dealing with their own things and it gives you that bit better chance to step back and go hey you know got to be a bit more aware of this got to think about things and we're not just in our team there's a surrounding team over here there's another team over here and there's you know requirements coming in from a different part of the business and oh actually >> you know it's not just that somebody's awkward and wants to put this data in that format. Maybe it's required by legal ed uh legal requirements with compliance that we've got to do. So, gives you that broader scope and vision and and understanding that there is a big picture. >> Maybe other parts of the business aren't utterly incompetent. They just have a different priority than you. You know, marketing aren't normally out to get you. They're just really focused on what they're doing. >> It gives you that concept as well that, you know, we all hate estimating software. We know estimating is a a pain in the neck and whatever estimates we do but it gives you an understanding that and I use the example recently I've worked at several telco companies and a lot of telco companies they launch their new projects uh products at things like MWC now MWC is a major conference for people that don't know and it's at a fixed date so if they're launching at that date that date's hard so now you start needing estimates because marketing has got to put collateral Somebody's got to update your website. Somebody's got to print brochers. Somebody's got to print t-shirts or >> whatever merch you're going to give away the thing. Somebody's got to put prepare a talk. Somebody's got to go and book stand. All these things have to be done months in advance. So yes, it's a pain in the neck custom make software and it's it's highly inaccurate, but you're trying to work out if there's a plan that's at all possible that somebody can do that before somebody spends all this money and books these things months in advance where they haven't got a choice. If you haven't booked your stand 6 months in advance, you won't get it >> right. Yeah. >> So it gives you that big picture and understand, yeah, estimates suck, but we still got to do them because the other people that >> Right. >> and they probably hate them, too. you know, that's >> I don't think anyone like loves it, right? And it's funny like I think that's such good context. It's not like, >> oh, it's my manager trying to just like, I don't know, like make sure that we're, you know, we're always working and like it's, you know, it's the system. It's like, no, it's literally you're helping other teams and trying to get on the same page. and they probably don't love it either, but they're like you might not feel like you have a deadline for whatever reason. But if they do, there's something not movable for whatever reason in the business. Like if you don't have that context, it's going to feel frustrating. It's going to feel like why do we have to do this? you might start inventing reasons like I said like oh it's just my manager trying to you know micromanage us or something like but yeah understanding I I think you said something really valuable there aside from just the um the context as a manager right like and seeing these other parts of you know other teams and things like that but the business value this the perspective of the business is something that and I I wanted to ask you one more question about uh but programming projects tying it into this because this is a part I feel like is missing a little bit still even when I keep pushing the narrative like please be building software and coming back to business value because this I feel like gets missed a lot. So if I go all the way to one end of the spectrum here of saying like lead code problems, right? Lead code problems I'm not a huge fan of. I've made this pretty public, but I don't think that there's zero value. I just don't think they translate well into software engineering like practically. But one of the reasons why one of the reasons why is is business value. And then when we go into programming projects, I end up saying like like kind of like you've been saying a lot like it's very valuable to be building software because you're practicing it, you're getting exposed to things. And my question to you is like how do we start bridging that gap of like you know you're building software like uh say the coding projects right you're getting this exposure how do we start bringing in like the concept that when you're in a company you're working for a business like there are going to be timelines there are going to be tradeoffs that come up right some of the constraints might be like yeah you do have a deadline yeah we do need to get this done you don't have infinite time to go find the best solution. Do you have you thought through like interesting ways or have you been incorporating this or noticing it even where it's like that seems to be a gap? I'm just curious your thoughts on the business value part. So, if I've understood the question correctly, um my my approach, my answer to that has always been that we need to push information down. So when I've led teams and when I've been part of management at whatever level, I've always tried to tell people this is what we need to do and this is why we need to do it given that that important context of why >> and to to share as much information as I've got. Um that's that sometimes has its challenges because you can overload people and I've certainly met some software engineers that push back and say I don't care just give me a geo ticket and sure I want to get on with it >> which I I think is a shame because they are capping where their career can ever get to by doing that they they're limiting how far they can get. Um the other context of that is that sometimes you don't always have that information. So I've certainly in big organizations I've hit the same frustration where I'm going well I want to tell my team why this is important, why we're doing this. I want to give them the full context. But you don't necessarily get that because we have we have an industry that's played with bad managers, bad leaders. Um so there have been plenty of times when I've had a manager that's not able to provide that context and isn't in a position to So I've always worked as way possible to try and circumvent that and deal with that and get that information and share it with the team because I think that helps and that helps give the bigger picture context to people and I've always encouraged the engineers that work from a team to push back and ask why. >> Yeah, absolutely. Um and again sometimes I found and this is a particular problem with some of the agile organizations. I found that too many people and I don't want to pigeon hole because this just from my experience but I've experienced in the last few years a number of people who've been bought into organizations as agile specialists and they've got nice certificates and so on and they've been doing a cargo call for scrum or agile or safe or something. So, here's the ceremonies we've got to have. And um I have to be blunt. I upset one not that long ago saying, "But why are we doing this?" They said, "We need to get better at retrospectives." And my question was, "Well, why?" >> Yeah. Like fun. Like that's an important thing to understand is is why are we doing anything that we're doing, right? >> Yeah. And and you know, I'm a big advocate of retrospectives. I think everybody should do them whether you're doing agile or not. Um >> Sure. But their answer was because it's part of scrum. >> I was like, well, why is it part of scrum? Well, cuz it's in a scrum manual and I'm certified scrum master. Am I hired to make sure we do scrum? It's like, okay, but why why are we doing it? What's the outcome that we hope from this, >> right? >> We've got 10 people in this two-hour meeting every fortnight. Yeah, that's that's 20 hours of effort that, you know, it's half a man week of effort. what what what outcome are we hoping from this? Like, well, you know, it's important part of scrum. So, okay. Yeah. So, I had to go back and and say, well, okay. But the point of this is that we're we're looking at what went well, what went badly, what lessons do we learn from this? And then we need to pick something that that went well. Let's keep doing it. It should be easy. And that didn't go well. That sucked. We hated it. We don't want to do this as a team. and then figure out some actionable steps that we can take to improve that. And um that was for fallen to them. So I'm a great believer in retrospectives because everybody should be looking back and you know I've I've recently left my job to work on coding challenges full-time you know and the businesses me and my wife we still have a weekly retrospective planned. >> That's awesome. you know I look back and you know and it's we're not doing scrum we're not doing agile process it's a simple point of got half an hour half an hour in the calendar every week to go well what did we do last week >> did it work do we want to do more of that >> what didn't work what are we going to change what are we going to improve what's going to be the focus going forward and can it's that self-reflection and that what are the lessons learned and a lot of you know say scrum safe whatever has become It's become a cargo cult forgetting that all these things exist for a reason, >> right? >> And you know, everything in scrum is there for a good reason and has a good if you don't get dogmatic about it, but as you look at it, fast feedback loops incredibly valuable. You know, that retrospective looking back and some reflection and how do we get better? What do we keep doing? It's incredibly valuable. And the sprint or the iteration is incredibly valuable because we get that short feedback loop, right? So >> what's what's not valuable is subscribing to a very specific implementation for all of those things across everything you do because then you miss the why you're doing it in the first place. So >> yeah, >> uh I >> and the why, not the ceremony. >> Yeah, I like that that resonates a lot with me. like I I I talk with another like a a friend and a former colleague about management things all the time and we have to get you on that podcast. Um, but when when we talk about like agile, when we both talk about it, we're talking about like not like forget the like forget scrum, forget can, forget any other agile flavor, agile, but we like just talking about like honestly continuous improvement things because at at the core of it, I feel like what agile is trying to do is continuous improvement. So, we we talk a lot about the why and if it means like you don't need a standup meeting, then like don't do it. Like if you don't need a like a very specific retrospective meeting that's like structured in a certain way, like don't do it. But why do you want a retro? Well, it's so that you can figure out what's working, what's not, and try something. That's why. how you implement that could look vastly different from some other team could look different from your own teams that you've been on but you need to understand why so that you can do these things um and on on the note of retrospectives I was thinking about this conversation and one of the things that was super valuable for me that I want to take away when trying trying to help people navigate this kind of stuff getting into software is like I think your your anecdote about your career and how things have changed. I think that's such a good like note that I want to make to share with people. Maybe not your specific journey all the time, but just uh like being able to reference like hey look like you can be going through your career learning different programming languages, different domains. That's probably going to happen and it's totally cool too to be able to pivot between the types of roles. I know you talked about being an IC going to manager. That could even look like going to being a project or uh or product manager. Like you might have that kind of pivot and you might try it and go maybe that's not for me and coming back. It's not a waste because you get so many other experiences. >> Yeah. And absolutely a final point to that when I started there was programmer and at least in the UK we had programmer analyst programmer and senior analyst programmer whatever but there was programmer devops as a role or concept didn't exist. It still shouldn't exist as a job because that's just a perversion of what it means but it exists. There were no data scientists. There were no data engineers. They hadn't been invented as goals or separate jobs yet. There were no ses. There were no estets. There was testers, programmers. There were no product owners. There were no, you know, product managers. All these roles have evolved over the last 30 years. You know, yes, somebody was doing various bits of them, but as actually separate roles and career options, they've evolved, >> right? you know, more recently we've got, you know, AI programmer or AI developer, researchers has evolved more as a goal and people have been doing AI for 80 years or something like that in some >> but it's brand new. It's brand new now. >> But but now it's become so widespread that it's a whole separate role and you could pursue a career just in that. I'm sure in the next 40 years or however long most of us have got our careers left, not 40 years for me hopefully. I hope to retire for then. But somebody new to the industry now that's maybe in their 20s might be thinking they've got 20, 30, 40. There could be roles and jobs that exist in 10 years time that aren't here now. They probably will be. So don't get pigeonholed. Be flexible. Keep learning new stuff and see where it takes you. Enjoy the journey. >> Yeah, I think that's awesome. like and yeah and enjoy the journey because like at the end of the day if you're going into software engineering in general and you're like I'm just doing this because someone said it paid well and I hate every day of my life like there's going to be better things out there for you. So make sure that you enjoy it. Um there's a lot to do. Um so John, I'm going to get links and stuff from you after but if you want to tell people watching where can they find you because I know you post a lot on different platforms. You got a lot going on. So, where's the best spot for people to find you? >> So, I'm on LinkedIn as John Cricut. Very easy to find. On Twitter, John Cricut. Coding challenges. FYI if you want to see the coding challenges and the projects. Um, on YouTube is coding challenges. Uh, and podcast launching soon. It's coding chats also on YouTube and all suitable podcast programs. >> Awesome. Sorry. >> Yeah. Yeah. Yeah. And like you said too, right? like uh your focus is is general, right? It's not like I'm just talking about one specific thing on your platforms. You talk about software engineering in general. You have a lot of experience from your career to share with people. So, um yeah, I think lots of insights to learn from you, which is uh which is great. So, >> I I follow my passion and I enjoy the journey. >> Absolutely. Okay, John. Well, thanks so much. This was super helpful. I I think a lot of people are going to have uh you know some solid takeaways from this. Uh I think we definitely touched on stuff that I keep hearing from people. I try to give some answers to and like my takeaways like I said I'm going to have some a little bit more uh context and a few more variations to give to people. So hopefully that helps. So cool. Thanks again. >> Been a pleasure.