#178 - Leveling Up Through Coding Challenges, Real-World Projects, and Personal Brand - John Crickett

 

   

“99% of us aren’t working in big tech. There’s this impression that everybody works in big tech. There’s a huge world of software development out there that almost gets forgotten about in social media."

John Crickett is the creator of “Coding Challenges” and a seasoned software engineer with over 30 years of experience. In this episode, John shares his diverse career path, including transitioning between individual contributor roles and management, founding his own business, and his passion for coding challenges.

John explains the benefits of building real-world applications over algorithm-based ones, emphasizing the importance of learning by doing. John also shares practical tips on time management for continuous learning and debunks the myth that most software engineers work in big tech.

We also explore the role of personal branding in today’s competitive job market. John provides tips on building a personal brand and leveraging social media to stay ahead in your tech career.

Finally, John shares his perspective on the impact of AI on software engineering and how we can leverage AI in our day-to-day tasks.

Whether you’re an aspiring developer or a seasoned professional, this episode provides practical advice and inspiration to help you level up in your tech career.  

Listen out for:

  • Career Journey - [00:01:51]
  • John’s Multiple Roles Transition - [00:03:51]
  • IC-Management Transition - [00:06:44]
  • Importance of a Vision - [00:09:39]
  • Lifestyle Business - [00:11:55]
  • Coding Challenges - [00:13:30]
  • Building Real-World Projects - [00:16:37]
  • CodingChallenges.fyi - [00:18:39]
  • Learning the Non-Functional Aspects - [00:21:17]
  • Allocating Time to Learn - [00:24:04]
  • Working for Non-Big Tech Companies - [00:27:15]
  • Relevant Skills for Non-Big Tech - [00:30:39]
  • AI Impact on Software Engineering Role - [00:34:44]
  • AI for Coding Challenges - [00:38:21]
  • Building Personal Brand - [00:39:54]
  • How to Build Personal Brand - [00:44:28]
  • 3 Tech Lead Wisdom - [00:49:25]

_____

John Crickett’s Bio
John Crickett is a software engineer and sometimes a manager of software engineers. He has worked as both a senior individual contributor (Staff+) and a senior manager (VP Engineering, Head of Software Development).

John writes about software engineering daily on LinkedIn and Twitter. He’s the founder of the popular “Coding Challenges” newsletter. Each week, John offers practical coding challenges to help software engineers enhance their skills through building real-world applications.

Follow John:

Mentions & Links:

 

Our Sponsor - JetBrains
Enjoy an exceptional developer experience with JetBrains. Whatever programming language and technology you use, JetBrains IDEs provide the tools you need to go beyond simple code editing and excel as a developer.

Check out FREE coding software options and special offers on jetbrains.com/store/#discounts.
Make it happen. With code.
Our Sponsor - Manning
Manning Publications is a premier publisher of technical books on computer and software development topics for both experienced developers and new learners alike. Manning prides itself on being independently owned and operated, and for paving the way for innovative initiatives, such as early access book content and protection-free PDF formats that are now industry standard.

Get a 40% discount for Tech Lead Journal listeners by using the code techlead24 for all products in all formats.
Our Sponsor - Tech Lead Journal Shop
Are you looking for a new cool swag?

Tech Lead Journal now offers you some swags that you can purchase online. These swags are printed on-demand based on your preference, and will be delivered safely to you all over the world where shipping is available.

Check out all the cool swags available by visiting techleadjournal.dev/shop. And don't forget to brag yourself once you receive any of those swags.

 

Like this episode?
Follow @techleadjournal on LinkedIn, Twitter, Instagram.
Buy me a coffee or become a patron.

 

Quotes

IC-Management Transition

  • If you’ve never experienced both, and you think you might enjoy becoming a manager, you should try and take the opportunity to do that. And you should try and get that experience, because even if you don’t enjoy it, it would have given you that insight into what the role involves. It’ll give you more empathy with what a manager is trying to achieve, with what they need to do. It’ll give you that broader commercial awareness, so when you do go back to being an IC, you’re better positioned to use that knowledge to advance your career as an IC.

  • That awareness, the kind of awareness of the big impact, the awareness of how to influence people, the awareness of how to drive change, the awareness of what the commercial realities are and how you have to network outside of tech, are incredibly useful and will help you have more impact and progress your career.

  • I would advise anyone who thinks they might be interested to try it, because if you find it’s a career for you, great! If you don’t, there are transferable skills you can bring back to being a software engineer.

  • Going back the 30 years, when I started, your career was: you get to senior software engineer then you move to manager if you want to progress and you want to get higher pay. There was no dual career track. And that’s a mistake because not everyone’s cut out for it. It’s a different skill set.

  • There are increasingly, and I would say about a third of the companies I see in the UK, now have this dual career track. So if you’re stuck in a management role, and you’re stuck there because it’s better benefits, it’s better pay, and you feel that it’s valuable but you hate it, start upskilling. Do some of the coding challenges, practice your LeetCode, whatever it takes. Find a company that has that dual career track and look to move as soon as possible. You’ll be more productive, you’ll get more out of it, you’ll be more satisfied. And there’s nothing more soul destroying than being stuck in a job you don’t like.

Importance of a Vision

  • There’s two sides to that. The importance of the vision is if you want to build something like Airbnb, you need to be thinking bigger. You need to be thinking about executing much bigger than I ever did.

  • Also, it strengthens a point that I’ve made several times that ideas are worthless. I’ve thought about and did Airbnb solution long before Airbnb was conceived. I didn’t have the vision. I didn’t have the drive. I didn’t have the–whatever word you want to use–to actually execute that. So ideas aren’t worth anything. It’s how you execute them, that is. Airbnb has executed way better than I did.

  • For the smaller business, it helps to have the vision to know what you want, to know what you’re trying to achieve. Do you want to build the next Airbnb? And the massive work that takes and the commitment that takes? And do you have a big enough vision? Or to be honest, for more like myself, I would rather build what many people would call a lifestyle business now.

  • I would rather now build a business where I can comfortably make, hopefully, a little bit more than I would make as a salary, but I can make the lifestyle and the choice I want. If I’m not inspired and I want to work half an hour a day and pop off and do something else until that inspiration hits me, I’ve got that flexibility.

  • Whereas if you want to build something that’s maybe a mid-tier 10-20 million company, that vision and clear idea of what you want and why you’re going there, I think that really helps.

Lifestyle Business

  • It’s always been about understanding what lifestyle you want first and then don’t get distracted by other people’s vision. Don’t get distracted by whatever people aiming for.

  • It’s very easy if you look on social media and see people talking about a lifestyle business where they’re making four or five, six million. That’s not going to be the reality for most people. They’re probably the exception. Figure out for you more what’s comfortable, what do you want? Do you want to be chasing that kind of money which is going to be a lot of work?

  • Are you happy making the equivalent of 60,000 a year? Because that will cover all your bills and you can spend time with your family, your kids, dog, whatever floats your boat. And then aim for that. Don’t get distracted by other people. Just focus on what your goals are. The comparison takes a lot of joy from these things. And if you’re going for lifestyle business, it should be about what motivates you and getting joy from it.

  • Also, one thing very important is to find the niche, what kind of specialty or professional things that you can help people, so that they actually look out for you.

  • Lifestyle also means that sometimes you have to understand what things that you want to do. It’s not like consulting where you take all the opportunities, and that in the end, probably, is not a lifestyle business. Having a selling value proposition that you enjoy doing. I think that’s also very important.

Coding Challenges

  • I got made redundant a couple of years ago. When I have my own businesses, I’ve never been made redundant. I’ve never been let go. I’ve actually had a more stable role in the businesses I’ve run than when I’ve worked with other people.

  • Again, I was having that problem with I didn’t have a vision. I didn’t have any idea of what to pursue. So I was starting to think about how do I find an idea? How do I find something that’s going to inspire me, that’s going to excite me? And the answer has got to be something that I’m interested in. I’m interested in computers and software engineering. I’ve been doing this for years.

  • But if you’ve experienced entrepreneurship before, you’ve learned quite quickly that actually it’s not just the idea. It’s the execution that matters. And a big chunk of the execution is that distribution. How do you have people or companies or organizations or whoever your customer is going to be to sell to? How are you going to get your product or service in their hands?

  • I see a lot of people talking about social media and personal brands. I should do that. Build up a following. Build up a bigger network in software engineers. Create the distribution and then figure out what of all the problems that software engineers have can I solve? What am I interested in solving? So I started doing that.

  • So I built my personal brand, started building and posting on LinkedIn regularly and trying to create that. And as part of that, I also talked to a few other people at startups. And then I decided actually I was going to illustrate my point about MVPs of how quickly and easily you could validate and test an idea.

  • One of those ideas is software engineers want to level up. They need something to do that. They’re always looking for projects. Could I create something in that area? And ever since I started programming professionally in 1995, I have built real-world projects to learn. I don’t like picking up a book and just implementing a function. I want to build some actual software. And I have done that and I’ve got a collection of these projects that I’ve done over the years. Some of which I no longer do. Some of which I do repeatedly.

  • And I thought, fine, I’ll just put together a newsletter. I’ll share one of these each week. I’ll share the projects I’ve got. I’ll share new ones. And I’ll see if I can build an audience for a thousand people by Christmas 2023. If I can build an audience for that, maybe there’s something that I’ll find as the right business idea for me.

  • So I announced the newsletter, bought a domain name. And I was surprised to get 1,500 people subscribed on the first weekend. So at that point, I thought there’s something here so I could keep building this. This will lead somehow to the business idea and what I’m going to pursue. And eventually, it has. I’ve been selling a few courses off the back of coding challenges that help people do some of the more technical challenges.

Building Real-World Projects

  • Algorithm-based projects are great if you want to go and learn that algorithm, learn that data structure, understand how to implement it, test out and understand the time and space complexity, so you get that basic knowledge. But very few of us actually write an implementation of a linked list or reverse a linked list in a real world job. It’s not what we do. And if you do want to do it, it’s built into the standard library of your programming language.

  • The normal challenges we face is how do we build something bigger? How do we actually build a full application? How do we capture requirements? How do we understand a network protocol? How do we implement a network protocol? How are we going to store data? What logging do we need? How are we going to make the system observable?

  • All these things, you’re only going to do if you’re actually building something real, not a toy application, not a little toy function.

  • If you want to practice building a network protocol and a server and exploring async versus multi threading for a high performance server, you actually need to build a high performance server. You need to implement the network code. You need to build a protocol handler. So I would choose to do that and actually build those applications and experience it. And if you take it far enough, you then implement things like a CI/CD. Maybe if you’re doing like a Dropbox clone, you might implement some infrastructure-as-code. You might actually go as far as actually deploying it.

  • When you build a real application, you face the challenges that you will face in the job. You come across issues like, oh, this dependency is complex or this dependency’s documentation is out of date. How do I use this? And you have to start solving the problems you will in the job, which when you’re writing a 10 line solution for LeetCode, you’re not facing those same challenges.

CodingChallenges.fyi

  • The obvious tip is to go to codingchallenges.fyi. I have 60 odd projects there where I’ve explained what you’re going to build. The projects that I put together don’t tell you how to do it. They tell you these are the kind of things you need to know.

  • Without that, the way I approach it is I go and read about the technology. I look for the documentation. I read the documentation. And I apply some of the experience I’ve got over the years. If you want to learn about data structures, that’s a different data strategy you don’t find in most books. It’s something interesting you can learn about. So I can point you towards that.

  • And also you get a chance to apply tools and techniques like TDD. One of my approaches is to think about what functionalities is this going to do? How can I build a little test? And perhaps when doing the startup sort of things, I’ve always thought of how can I break things down into a walking skeleton. So what’s the smallest vertical slice of functionality I can pull out and identify? And then it’s just layering stuff on top of that, figuring out what the next little incremental step is.

Learning the Non-Functional Aspects

  • It’s all about learning by doing. When I write the challenges, I quite often leave little bits out. So that learning by doing, that being curious and digging into it.

  • If you aren’t building something real and having to go through all these steps, you’re not getting that experience that you will in a job of somebody’s going to give vague requirements. We all know how important it is to give good requirements, but the reality is you don’t get them. You will have to get your requirements and you’ll have to read them and go, but what about this? What about this edge case? Have we thought about this?

  • And a common objection to TDD is we can’t do TDD, because we don’t have good requirements. Well, whether you like TDD or not, you very rarely get good requirements. Part of the job is going to go, ah, these things are missing. How do I get them? How do I get them for myself? By either asking somebody. How do I work them out? How do I find the documentation or the protocol?

  • Let’s learn by doing. Let’s go and experiment. Be curious. And go and take the steps that you will have to do on the job.

Allocating Time to Learn

  • We all struggle for time, don’t we? And that’s a choice we’ve all got to make and how we do it. For me, it’s quite easy nowadays. This exploration is my passion.

  • In the past, I’ve approached it by looking at where there was a dead time in my day. So I’ve commuted to London a number of times on the train, which is generally a pretty horrific two-hour journey each way, but that could be four hours. Sit with a laptop, sit with a book and learn something new. At other times, I’ve had jobs where scheduling is inefficient, people are often late for meetings. I haven’t been opposed to carrying a book or carrying my laptop around with some learning on it. If I get to a meeting room in time for a meeting, and no one else is there, sit and read and go through a blog post, go through some documentation, make use of that time.

  • And I just look for ways of fitting it in throughout my day. I’ve worked at a company where quite often it took 10 minutes to do a build and then a test. That 10 minutes, you couldn’t do anything else. Every time I did a build, click the build off, read an article.

  • So just looking for little bits of time you can find in your day that you can make use of things. More recently, I was working at the UK Met office. Over lunch, I’d stick a podcast on and walk laps of the campus. I was getting a bit of exercise, getting some fresh air and listening to a podcast.

  • There are little times when most of us can find time during our day if we want. Just looking at how do you use that? How do you fit things in? How can you claw that back? And if you look, there are quite a lot of bits of wasted time during your day now. They won’t be as efficient as if you sat down and had now a focus time to do it. But if you’re really struggling for time, it gets you something. It gets you moving.

  • And then, I’ve always been quite lucky to work with teams where we’ve had an emphasis on CPD or when I’ve been a manager, I’ve done that. So we’ve normally set aside one or two hours a week to be able to do that quite often with a team member doing a presentation or bringing along a YouTube video that they thought was interesting on a conference talk or a podcast. Sticking it on for half an hour as a team, watching it and then discussing it.

Working for Non-Big Tech Companies

  • I did the numbers on that about six, seven months ago, because social media is flooded with people telling you how to do LeetCode, do system design and pass the interview to get into Google, Facebook or big tech company of choice. And when I did the numbers, the number of engineers they’ve all got, it’s less than 1% of the people who work in software engineers. So 99% of us aren’t working in big tech. And some of us probably never will.

  • Until fairly recently, most big tech in the UK was based in London. I spent most of my career trying not to work in London. So, whether or not big tech wanted me, I didn’t want to work in London in their offices. I didn’t want that commute. I wasn’t prepared to move there. I may never have got accepted.

  • There’s a few more now that you can work remotely and now that things have evolved. But there’s probably a lot of smarter people than me that are better suited to fit themselves and want that kind of lifestyle.

  • But for most of us is not going to be. And if you look at social media, there’s this impression that everybody works in big tech, everybody builds websites, everybody does data engineering in the way that Airbnb does. But there’s not. There’s a massive world out there.

  • There are people who are building software that fits in the microphone we’re using today or in the webcam that we’re using today, in the audio interface that’s in front of me. There are software in guitars these days, there are software in the guitar amplifiers these days. There is software in the lights around me. There’s software in your washing machine, your fridge, the medical devices that are in our hospitals, the aircraft, the air traffic control, the ships we have. Everything. And people are building all this software.

  • And there’s a whole world of software outside of web development that almost gets forgotten about in social media. And a lot of it’s very interesting. There’s some really fun engineering challenges. And we forget about all of those, and there’s a huge world of software development out there.

Relevant Skills for Non-Big Tech

  • One key thing there is system design. Be aware there are systems outside of these big websites.

  • The key skills you want to have is that curiosity that awareness that there are more things out there. The awareness that everything is not a website. The awareness that some things have very different constraints.

  • The key skill is to be curious, be interested. Be adaptable. Be aware that there are different technologies out there, different approaches, and be willing to go and look for the different experiences and different approaches that people have got.

  • Because, particularly, when you do that kind of engineering, it’s less talked about. There aren’t necessarily the books about it. There aren’t necessarily, this is how Google does railway signaling systems, or this is how Google does avionics. You have to hunt down and track down people with expertise and dig into it a bit more and have that curiosity.

AI Impact on Software Engineering Role

  • Right from the late 80s, all the way through my career, there’s been “in the next five years AI is going to put software engineers out of a job”. I think one day it might happen, but I think it’s a lot further away than we think. The current LLMs are amazing. You can do some great things with them. But they don’t reason, and you can see plenty of examples of this, if you genuinely look. They are effectively statistically picking what’s likely to be the next text in response to the text that you’ve put in.

  • That can be incredibly powerful if you want some evolution, or something maybe translate a report a little bit, look at what code would be next, something that’s been done before. But it’s missing that reasoning. So I don’t see it being a big threat to software engineer’s jobs anytime soon.

  • I do see it as potentially quite an interesting tool, and one that we can leverage in many different ways. Probably more for us to say that translating data, how do we take something and present it in a different way? Which could be incredibly useful for learning as well as reporting and analysis, because one of the things I’ve done a lot when I wanted to learn something new is find multiple different sources, find multiple different blogs and multiple different books, because every author presents things in a different way.

  • I’ve maybe found that with a subject, I might learn 10% from one book, 20% from a different book, 15% from a video. Because they all presented things with a different slant, a different viewpoint, used different terminology. Some would use longer, fancier words and I’d have no idea what they’re about. And some would talk to me like a five-year-old.

  • AI is potentially incredibly useful for us to take these things and say, will you present this to me as though I’m a five-year-old or present this to me as if I haven’t heard of these technologies? I think it’d be very useful for learning for that, but I don’t see it replacing software engineers anytime soon. And the final reason for that is what we touched on earlier, is the hard bit is good requirements. You replace a coder with AI, you’ve still got to tell it what the requirements are. If you can’t do that, it’s going to give you just as bad software as a coder will. It’s going to struggle just like we will.

AI for Coding Challenges

  • I haven’t seen anyone solve them with coding of AI yet, and the few that I’ve tried and experimented with the AIs haven’t been very good at. They can, without hoping not to get sued by Stack Overflow, but when you’ve asked them how do you implement this, they’ve given an answer that’s incredibly like what was on Stack Overflow.

  • So the kind of dumbed-down version that doesn’t meet all the requirements, and it almost looks like it’s regurgitating information from a Stack Overflow answer. And we all know that’s not software engineering. You can’t just copy and paste simply Stack Overflow. You need to actually understand the code. Build a reason about it. Better add the requirements in the edge cases. So it’s falling short on that side, from what I’ve seen.

Building Personal Brand

  • We’ve seen all the layoffs that have occurred recently. We’ve seen the job market change from hyper demand. The market’s changed. There’s been a lot of layoffs. The demand is a lot calmer now. So as people want to differentiate themselves and people want to stand out, a personal brand is a way to do that.

  • A lot more recruitment these days is coming through your network. It’s always come a lot through your network, but a lot more is coming through who your network is and what you’re known for.

  • If you’ve got good AI experience and you’re known in AI, I’m sure you’ve got people knocking down your door at the moment trying to offer you jobs. And if you’re the Chief Scientist of OpenAI, if you were to look for another job, you could put a one line resume up there “Chief Scientist for OpenAI”. You wouldn’t need anything else on your CV to get. That would be enough of a brand for you to create. And that’s why we see people put ex-Facebook, ex-Google on their CVs, because they’re trading off that brand.

  • For the rest of us, the 99% of us that don’t work in big tech, that brand has got to be what are we known for? What is our expertise? What have we done that’s unique and different? And for an awful lot of us, we can’t talk about we built Google, or we scaled AWS, or we designed their data centers.

  • Most of us have been part of 99%. We’ve maybe built a few CRUD apps, maybe we’ve scaled them to something interesting, vaguely. So we need to find different ways of standing out, and different ways of differentiating ourselves from everyone else.

  • And that makes it easier for recruiters to come and get you. If you stand out as a personal brand, they might have seen your post, they might recognize your name. They might find you in a search on LinkedIn. Basically, it makes you findable, makes you attractive to somebody.

  • If you’re showing that thought leadership and you’ve built a personal brand, maybe if I’m a hiring manager looking for somebody and thinking, I really want somebody that knows about AI. If they’ve been following your posts, maybe they’ll reach out to you. Maybe when you put open to work on your LinkedIn profile, they’ll think, oh hell, I’ve got to talk to that guy because they’re an expert on AI.

  • If you’re a junior developer without experience and you can’t stand out from someone. But maybe you can get known for having built some interesting little bit of open source. Linus built Linux when he was a student at Helsinki Uni. He wasn’t even a junior developer. He was still a student. He never actually, as far as I’m aware, became a junior developer, because Linux took off before he graduated. And he’s just worked building that open source software, since that has become his career.

  • If you’re a junior developer with no experience, and you’re not known, you don’t stand out against a lot of CVs, you’ve got nothing in your CV, you can’t show any impact, you can’t show what you’ve done. If you’ve built an open source project that maybe 10 companies are using and getting value from, you’ve now built some real world software. You’ve got something published, people are getting value from it, you can talk about some impact. Even though you’ve never had a job, you’ve not got any experience. You have got some experience to talk about. If you’ve got 10 people using it that are finding it valuable, that’s going to put you head-and-shoulders above 99.9% of the other junior developers that you’re competing with.

  • You don’t have to be Linus, you can just find that few users that are delighted with your software.

How to Build Personal Brand

  • The right answer is pick a niche and be curious. Take Linus for example. He was interested in operating systems. He wanted to implement something. So he did, and he went deep, deep into that niche. And you can’t mention Linux without thinking of him now. So he absolutely owned that niche. And that is the best way.

  • I’ve epically failed at that because I have many different interests. I’m quite curious. So I’ve completely failed at a niche.

  • When I started my first business, I was a very typical software engineer. Sales is a dirty word. And marketing, they’re just those annoying people that promise the customers lots of things that we’re never going to do. When I started the business, you suddenly realize, actually, I’ve got to go and sell to somebody. I need some customers. So I have to learn about sales and marketing.

  • I found that actually, sales isn’t bad. It’s just talking to people and being interested in them. Being curious.

  • Somebody’s told you what their pain is. They’ve told you what is worth solving for them. If you can solve it for a cost effective value, you sell. And actually when you take that, it’s a transferable skill as well, if you go back to employment and working for people. Sales is incredibly valuable and you get those transferable skills.

  • Niching is a better approach. I’m not very good at it because I’m too curious and follow my curiosity. But that eclectic mixture of curiosity and experience that we’ve all got actually makes us unique, so there is probably no one else in the world, though there are many better software engineers, there’s no one else in the world that’s had that experience in me of building a railway signaling system, building a CRUD app for McDonald’s, working on meteorological data, working on voice biometrics, and now building coding challenges. So I’m unique and there are some unique lessons from that that will help somebody.

  • We’ve all had a unique journey. And even if you are that junior developer with a year’s experience, there’s a person that’s just graduating that hasn’t had that experience that can learn from you. And the year behind them is the person that’s in their second year at university, and they can learn from the person that’s in their third year.

  • There’s always somebody further behind you that can learn from your journey and benefit from that.

  • Think of yourself two or three years ago. What kind of problem did you encounter? And what would you expect some kind of resources that are available to help you solve those kinds of problems? Maybe you can provide that now to help people who are also struggling with the same kind of challenges.

  • And the other thing, learning in public can also be a way of building your personal brand.

3 Tech Lead Wisdom

  1. Be curious. Be interested, be curious about the world. That willingness to learn and ask questions will make it a lot easier to lead in every single way.

  2. The other thing that I think a lot of leaders miss is to be careful.

    • If you are in a leadership and a management role, when you come and ask what seems to you like an innocent question, if you’re in a position of authority over someone else, it seems like an order to them. When you say, can we add this feature to the software? They don’t hear, is it possible? They hear, “Go and do it.”

    • As a leader, be careful what you ask for. Your questions will be turned into or heard as orders and instructions.

  3. Good leadership is about being a good follower.

    • No matter where you are in your leadership journey, you will have somebody else above you, somebody you’re following.

    • Leadership is as much about following the people that you should be following, and being a good follower, and setting a good example for people that are following you.

Transcript

[00:01:11] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have with me John Crickett. So some of you maybe would have known him on LinkedIn, maybe on coding challenges that you’ve seen over the internet. So John today is going to share some of his learning, some of his coding challenges. And also I believe we can learn a lot from him because he has almost like 30 years of coding experience. So welcome, John, to the show. Looking forward to our conversation.

John Crickett: Thank you, Henry. Thank you for inviting me on the show. And thank you for reminding me I’m getting gray. I’ve been doing this for nearly 30 years.

Henry Suryawirawan: Right. So the reason I invite you because some of my listeners actually requested for you to be on the show. So I’m really happy to have you.

[00:01:51] Career Journey

Henry Suryawirawan: Maybe John, in the beginning I’ll ask you to share a little bit more about yourself for those of you who probably haven’t heard about John. Maybe if you can share any highlights or turning points that we all can learn from.

John Crickett: Sure, I’ve been a software engineer for about 30 years now. And I guess the highlights for me is being seeing how much the industry has changed since then. I started off at a very traditional engineering company, who were focused on things like radio comms and very traditional software engineering. Very, very quickly within a year or two, I got experience with internet service providers and the birth of the internet. And that just changed the way we worked. So going from that session where you walked into an office, you grabbed a book, if there was one, and I looked up stuff in the manual too, I can now look it up on the internet and have access to almost any information in the world instantly. It’s been transformational and it’s been a real exciting part to see how much that’s changed the industry. See the growth of the industry and how much interesting software we have to build since then.

Henry Suryawirawan: So, I think I also experienced back then, right, when the internet was just starting. Previously, it was even quite slow, right? 56 Kbps, probably some of you would have experienced that. So it’s still kind of like slow. Searching is probably also expensive because you need to pay for those dial ups. So I can actually see that the way internet has actually transformed the way we work, the way we get information. And now I think it’s very easy. Sometimes even you have too many options of resources that you can learn from.

[00:03:51] John’s Multiple Roles Transition

Henry Suryawirawan: Yeah, so in the beginning, John, I think you have almost 30 years of experience. I think throughout the preview of our conversation, you actually shared that you have actually gone through multiple roles in your career, right? So from being an IC, from a senior leadership and even a founder one time. So maybe if you can tell us a little bit more about all these roles and transitions.

John Crickett: Yeah, sure. So I started off, as you say, as an IC, a very traditional engineering company. Weaved into an internet service provider at the early part of the internet. And then I moved around a couple of engineering companies, and then I moved into, shall we say, more tech companies. And the whole dotcom boom was going on around me. We were hearing about Google, Yahoo, Amazon, GeoCities, and other companies that were big then. And I had always planned to start my own business when I got to 40. But as a 22 year old, seeing this dotcom boom around me, it’s like, I should do it now. Why am I waiting? Lots of other people are doing it. Wasn’t quite as good an environment in the UK as as perhaps it is in the US, but I started my own business then.

In my epic failure of imagination though, I just started a software consultancy, just like the companies I’d worked at. No big vision. No, I’m going to start the next Google, just, oh, how do I become the next software consultancy and sell that? Kind of sticking to what I knew from a few years experience. Did that for several years. Accidentally fell into kind of doing the dotcom. So ended up building a bread and breakfast search engine. Kind of like Airbnb, but much simpler back in 2004. But again, didn’t have the vision. We only aimed to capture the whole B& B market in the UK. Didn’t think about making this worldwide. Didn’t have that vision, the ability to execute. Or the vision to execute on, should I say.

Did that for several years, then through, well, basically, through my brother who’s my business partner, getting married and deciding to pursue other ventures, ended up moving into different areas, got married and started a family myself, so putting 60 hours a week into a business just wasn’t viable anymore. So I went back to working for other people, early IC career, did that for a few years, moved into management and employment. Then, coming up to 2018, again, I was doing a lot of travelling, I wanted to spend some more time with my family, so I went back to contracting. Again, back to being an IC. So I could work remotely and see more of my family and support my kids who are home educated.

Then pandemic, everyone went remote, so I ended up going back into management at last. Did that for a little bit, but then, also circumstances down here, we’ve had tech layoffs, I got laid off as well. That put me back to contracting and eventually that’s led me back to now starting up my own business, which is where I am now in doing yet another small scale startup should we say

Henry Suryawirawan: Wow, I think it’s pretty much variety of roles that you have played, right? So I think some people here probably could relate. Because I believe, although probably not as plenty of roles that they have played in their career like yours, but actually they have transitioned from IC, management, maybe some even back to IC, right? I myself have done it twice, you know, IC-management-IC-management. So I think there’s always a challenge.

[00:06:44] IC-Management Transition

Henry Suryawirawan: But I think the first question I would like to ask is like, some people actually question, should they actually go to management? Or maybe for those managers who probably don’t really like the management job, should they go back to IC? Maybe you can give a little bit of perspective. From your experience, what do you think about all these?

John Crickett: So I think if you’ve never experienced both, and you think you might enjoy becoming a manager, you should try and take the opportunity to do that. And you should try and get that experience, because even if you don’t enjoy it, it’s like it’s not for you, it would have given you that insight into what the role involves. It’ll give you more empathy with what a manager is trying to achieve, with what they need to do. It’ll give you that broader commercial awareness, so when you do go back to being an IC, you’re better positioned to use that knowledge to advance your career as an IC.

So maybe when you get to senior or staff, depending on your company, and you switch to a management track or you become a manager, that’s a lot of potential learning that when you then, if you decide it’s not for you and you move back, you can use to go staff and staff plus. And that awareness, the kind of awareness of the big impact, the awareness of how to influence people, the awareness how to drive change, the awareness of what the commercial realities are and how you have to network outside of tech, are incredibly useful and will help you have more impact, and as I say, progress your career. So I would advise anyone that thinks they might be interested to try it, because if you find it’s a career for you, great! If you don’t, there are transferable skills you can bring back to being a software engineer.

Henry Suryawirawan: Some people actually perceive management to be a higher role, hence a bigger pay. Although in some companies, that may not be true. And some would actually stay in the job simply because of that. Even though they are maybe not as passionate as being an IC, right? So what would you tell to those people probably who are kind of like stuck? Like they don’t want to lose the management position, but they’re also not enjoying it.

John Crickett: Well, I think it depends on the market you’re in. Because here in the UK, at least, the best paid roles are normally in contracting, so… It’s changing a little bit now, but at that point, I would say leave the management role. Go out contracting. Or, again, fortunately, it’s changing. Certainly going back the 30 years, when I started, your career was you get to senior software engineer then you move to manager if you want to progress and you want to get higher pay. There was no dual career track. And that’s a mistake because not everyone’s cut out for it. It’s a different skill set. But there are increasingly, and I would say about a third of the companies I see in the UK now have this dual career track. So if you’re stuck in management role, and you’re stuck there because it’s better benefits, it’s better pay, and you feel that it’s valuable but you hate it, start upskilling. Do some of the coding challenges, practice your LeetCode, whatever it takes. Find a company that has that dual career track and look to move as soon as possible. You’ll be more productive, you’ll get more out of it, you’ll be more satisfied. And there’s nothing more soul destroying than being stuck in a job you don’t like.

Henry Suryawirawan: Yeah, so I think being stuck definitely is not gonna be helpful in the long term, right? So I think for those of you, you can consider, I think there are many roles these days that are even remote, right? So probably getting an IC remote job is possible.

[00:09:39] Importance of a Vision

Henry Suryawirawan: You mentioned a couple of times in the early of our conversation that you started maybe some kind of business, but didn’t have vision, and now you’re back being a founder. So what is the importance of this vision for those of us who would like to also venture maybe into consultancy or maybe some kind of small business like yours?

John Crickett: So I think there’s two sides to that. The importance of the vision is if you want to build something like Airbnb, you need to be thinking bigger. You need to be thinking about executing much bigger than I ever did. And I think also it strengthens a point that I’ve made several times that ideas are worthless. I’ve thought about and did Airbnb solution long before Airbnb was conceived. I didn’t have the vision. I didn’t have the drive. I didn’t have the, whatever word you want to use, to actually execute that. So ideas aren’t worth anything. It’s how you execute them that is. Airbnb have executed way better than I did. So point proven, I think.

For the smaller business, I think it helps to have the vision to know what you want, to know what you’re trying to achieve. Do you want to build the next Airbnb? And the massive work that takes and the commitment that takes? And do you have a big enough vision? Or to be honest, for more like myself, I would rather build what many people would call a lifestyle business now. I enjoy working remotely. I enjoy working from home. This is my office. My office has guitars in it. And it’s very comfortable. I would rather now build a business where I can comfortably make, hopefully, a little bit more than I would make as a salary, but I can make the lifestyle and the choice I want. I can pursue the technology. I can pursue the commercial or leadership areas that interest me. I can pull the guitar off the wall and play when I want. I can walk the dog when I need to. If I want to work 20 hours a day, because I’m really enjoying my current project, I can do that. If I’m not inspired and I want to work half an hour a day and pop off and do something else until that inspiration hits me, I’ve got that flexibility. Whereas if you want to build something that’s maybe a mid-tier 10-20 million company, again, that vision and clear idea of what you want and why you’re going there, I think that really helps.

Henry Suryawirawan: Yeah, I think just what you mentioned, right? Ideas are kind of like worthless or even like worth very little, right? So it’s the drive and the execution that actually matters. And also your vision. If you want to aim for bigger things, you have to have a bigger vision for sure. And take the drive to actually get there, right? Or even though if you don’t reach there, at least you reach some way almost near to that vision.

[00:11:55] Lifestyle Business

Henry Suryawirawan: So speaking about lifestyle business, I think it’s getting trendy these days. And again, internet, social media allows us to actually have this kind of a lifestyle business. I believe some of the listeners here also have that kind of vision and dream. Maybe a little bit of tips from you, how can people get started to aim for this lifestyle business?

John Crickett: I think it’s always been about understanding what lifestyle you want first and then don’t get distracted by other people’s vision. Don’t get distracted by whatever people aiming for. So it’s very easy if you look on social media and see people talking about a lifestyle business where they’re making four or five, six million. That’s not going to be the reality for most people. They’re probably the exception. Figure out for you more what’s comfortable, what do you want? Do you want to be chasing that kind of money which is going to be a lot of work? And to pretend otherwise is a bit naive. Are you happy making the equivalent of 60,000 a year? Because that will cover all your bills and you can spend time with your family, your kids, dog, whatever. Whatever floats your boat. And then aim for that. Don’t get distracted by other people. Just focus on what your goals are. Again, there’s, you know, the comparison takes a lot of joy from these things. And if you’re going for lifestyle business, it should be about what motivates you and getting joy from it.

Henry Suryawirawan: And I think also one thing very important is to find the niche, right? Like what kind of specialty or professional things that you can help people, so that they actually look out for you. And I think lifestyle also means that sometimes you have to understand what things that you want to do, right? It’s not like consulting where you take all the opportunities, and that in the end, probably, is not a lifestyle business. But also like having a selling value proposition that you enjoy doing. I think that’s also very important.

[00:13:30] Coding Challenges

Henry Suryawirawan: So speaking about the things that you’re doing now, right? Aside from your business, I think you’re also doing this coding challenges, which I believe is kind of like quite popular for some of those who follow that. So tell us a little bit more, how did you actually come up with this idea of coding challenges?

John Crickett: So it’s a bit of a mixture. As I mentioned, I got made redundant a couple of years ago. And I was looking around and thinking, when I have my own businesses, I’ve never been made redundant. I’ve never been let go. I’ve actually had a more stable role in the businesses I’ve run than when I’ve worked with other people. But again, I was having that problem with I didn’t have a vision. I didn’t have an idea of what to pursue. So I was starting to think about how do I find an idea? How do I find something that’s going to inspire me, that’s going to excite me? And the answer has got to be something that I’m interested in. I’m interested in computers, software engineering. I’ve been doing this for years. But if you’ve experienced entrepreneurship before, you’ve learned quite quickly that actually it’s not just the idea. It’s, as we say, the execution that matters. And a big chunk of the execution is that distribution. How do you have people or companies or organizations or whoever your customer is going to be, to sell to? How are you going to get your product or service in their hands?

So I thought, actually, I see a lot of people talking about social media personal brands. I should do that. Build up a following. Build up a bigger network in software engineers. Create the distribution and then figure out what of all the problems that software engineers have can I solve? What am I interested in solving? So I started doing that. So I built my personal brand, started building and posting on LinkedIn regularly and trying to create that. And as part of that, I also talked to a few other people at startups. And I made a comment about MVPs one day. And then I decided actually I was going to illustrate my point about MVPs of how quickly and easily you could validate and test an idea.

And one of those ideas is software engineers want to level up. They need something to do that. They’re always looking for projects. Could I create something in that area? And ever since I started programming professionally in 1995, I have built real world projects to learn. I don’t like picking up a book and just implementing a function. I wanted to build some actual software. And I have done that and I’ve got a collection of these projects that I’ve done over the years. Some of which I no longer do. Some of which I do repeatedly. And I thought, fine, I’ll just put together a newsletter. I’ll share one of these each week. I’ll share the projects I’ve got. I’ll share new ones. And I’ll see if I can build an audience for a thousand people by Christmas 2023. If I can build an audience of that, maybe, there’s something that I’ll find as the right business idea for me.

So I announced the newsletter, bought a domain name. And I was surprised to get 1,500 people subscribe in the first weekend. So at that point, I thought there’s something here so I could keep building this. And I’ve definitely got to pursue this. This will lead somehow to the business idea and what i’m going to pursue. And eventually, it has. I’ve been selling a few courses off the back of coding challenges that help people do some of the more technical challenges.

Henry Suryawirawan: I think that’s very interesting idea in the first place, right? You came up with the idea. You want to build a distribution, right? So you execute that by creating MVP, the newsletter. And now, I think, it’s been more than a year, I believe, right, for you to run this?

John Crickett: Yep. March 11th, 2023, started.

Henry Suryawirawan: So it’s kind of like popular on the LinkedIn, I can see that.

[00:16:37] Building Real-World Projects

Henry Suryawirawan: So maybe I’m actually interested when you say you love building real world projects, right? Or real world application. And in fact, in coding challenges you will see challenges, something like building a password manager, building like Redis, building like even Docker and things like that. So tell us a little bit more why we should learn from building real world projects rather than maybe some people love to do algorithm-based project?

John Crickett: So algorithm-based projects are great if you want to go and learn that algorithm, learn that data structure, understand how to implement it, maybe test out and understand the time and space complexity, so you get that basic knowledge. But very few of us actually write an implementation of a linked list or reverse a linked list in a real world job. It’s not what we do. And if you do want to do it, it’s built into the standard library of your programming language. The normal challenges we face is how do we build something bigger? How do we actually build a full application? How do we capture requirements? How do we understand a network protocol? How do we implement a network protocol? How are we going to store data? What logging do we need? How are we going to make the system observable?

And all these things, you’re only going to do if you’re actually building something real, not a toy application, not a little toy function. So like I say, if you want to practice building a network protocol and a server and exploring async versus multi threading for a high performance server, you actually need to build a high performance server. You need to implement the network code. You need to build a protocol handler. So I would choose to do that and actually build those applications and experience it. And if you take it far enough, you then implement things like CI/CD. Maybe if you’re doing the, like a Dropbox clone, you might implement some infrastructure-as-code. You might actually go as far as actually deploying it.

And when you do that, when you build a real application, you face the challenges that you will in the job. You come across issues like, oh, this dependency is complex or this dependency’s documentation is out of date. How do I use this? And you have to start solving the problems you will in the job, which when you’re writing a 10 line solution for LeetCode, you’re not facing those same challenges. So that’s one of my focuses. I like to build the skills to do the work to building real world software.

[00:18:39] CodingChallenges.fyi

Henry Suryawirawan: I think one of the challenges, definitely in building real world application is about the experience, right? So sometimes if you want to learn about algorithm, there are so many books or maybe resources that you can look up into as a reference. But let’s say, for example, building a Docker container, right? Sometimes it’s really hard to actually figure out in the beginning where to start. Maybe if you can give tips for people who always face this challenge, I want to build real application but actually I don’t know where to start or I don’t know how should I start. So maybe a little bit of tips.

John Crickett: Well, that’s going to sound like an advertisement, I’m afraid, because the obvious tips are go to codingchallenges.fyi. And I’ve done that work for you. I have 60 odd projects there where I’ve explained what you’re going to build and I’ve explained, you know, for the Docker one, here are the man pages, here are how you can look at things like sys group and chgroup and cgroup and chroot. The projects that I put together don’t tell you how to do it. They tell you these are the kind of things you need to know.

So without that, the way I approach it is I go and read about the technology. I look for the documentation. I read the documentation. And I apply some of the experience I’ve got over the years of, say, building a network server, to like this is going to need a protocol handler. This is going to need something that’s going to handle concurrent clients. Oh, there’s something interesting here. Like this one is, for performance reasons, they’ve built this with a zero-allocation parser. I’m going to read about that and learn about that, that’s quite interesting. Or Redis, for example, is one of the few things I’ve come across that’s using skip lists. So if you want to learn about data structures, that’s a different data strategy you don’t find in most books. It’s something interesting you can learn about. So I can point you towards that.

And also you get a chance to apply tools and techniques like TDD. So again, one of my approaches is to think about, well, what functionalities is this going to do? How can I build a little test? And perhaps when doing the startup sort of things, I’ve always thought of how can I break things down into, I think what the book Pragmatic Programming described as a walking skeleton. So what’s the smallest vertical slice of functionality I can pull out and identify? So for a server that might be, I can connect and do a ping. In fact, you know, that’s pretty much what it is for Redis. I can receive a TCP/IP connection, get the ping message, parse it, and respond and connect with pong. And that’s your very simple walking skeleton. And then it’s just layering stuff on top of that, figuring out what the next little incremental step is.

Henry Suryawirawan: So I believe those of you will be actually interested to figure out how coding challenges can help you to actually level up, right, by building real world applications. And I believe these kinds of resources are still not a lot over the internet even. Like what I can see, for example, ByteByteGo sometimes also covers this kind of resource. But not many books or maybe resources that people can refer. So I think do check out Coding Challenges.

[00:21:17] Learning the Non-Functional Aspects

Henry Suryawirawan: One definite aspect, I think you mentioned this as well last time, right? Is that there are so many aspects that are probably required not in building real world applications, right? It’s not just the coding, but it’s like the observability, the CI/CD, the testing part, the system design, probably the quality attributes that needs to be built in terms of the architecture and design. So maybe any kind of tips how we can also level up on these kind of aspects, right? Not just on the functional aspect.

John Crickett: So I think it’s all about learn by doing. So again, when I write the challenges, I quite often leave little bits out. So I’ll say, you need to implement this protocol. Or, say, the TAR challenge I took. I mean, TAR is a relatively simple tool. But to implement it, I’ve basically pointed you out, here’s the spec that you can find on Wikipedia. Go and read the file format and understand it. Here are some of the tools you can use to actually go and explore a binary file. It’s better to see what’s in it, explore that data, and start understanding it. And even if you didn’t do the challenge and like to code, you’d go and look at a binary file and say, oh, it’s got a header. The header has these bytes. Now that’s how we structure the stuff. If you do a couple of these things, you might recognize that actually some of these file formats have commonality with protocols over the wire. So that learning by doing, that being curious and digging into it.

And again, if you aren’t building something real and having to go through all these steps, you’re not getting that experience that you will in a job of somebody’s going to give vague requirements. We all know how important it is to give good requirements, but the reality is you don’t get them. You will have to get your requirements and you’ll have to read them and go, but what about this? What about this edge case? Have we thought about this? And a common objection to TDD is we can’t do TDD, because we don’t have good requirements. Well, whether you like TDD or not, you very rarely get good requirements. Part of the job is going to go, ah, these things are missing. How do I get them? How do I get them for myself? By either asking somebody. How do I work them out? How do I find the documentation or the protocol?

You know, if you get asked to like, say something that’s going to do DNS, you will need to better go and be self motivated and curious enough to go and find the RFC that defines DNS and figure it out. You’re not going to get a product owner that’s going to come and tell you what the DNS protocol is. You will have to find the skills to figure that out. So again, let’s learn by doing, let’s go and experiment, be curious. And go and take the steps that you will have to do on the job.

Henry Suryawirawan: I think you mentioned something really important for any software engineers, right, is that the importance of requirement and breaking it down actually to the smallest thing that you can do, right? If you’re stuck, do some kind of research, ask the people, right? And clarify the requirements before you actually proceed.

I think that’s a very, very important skill set. And like what you mentioned, right? In my experience as well, in my career, I’ve never seen any requirements that is complete and kind of like everything is perfect. You know, you just follow and then you get everything done. So I think it’s very rare to see that kind of thing.

[00:24:04] Allocating Time to Learn

Henry Suryawirawan: So learning by doing is definitely very important. How much time people should spend doing outside of their job or their role to actually level up? I think that’s also another thing that some people are, they want to do it, but they couldn’t find the time. So maybe a little bit of tips from you.

John Crickett: Sure. I mean, we all struggle for time, don’t we? And that’s, that’s a choice we’ve all got to make and how we do it. For me, it’s quite easy nowadays. You know, this exploration is my passion. It’s grounded of my business. In the past, I’ve approached it by looking at where there was dead time in my day. So I’ve commuted to London a number of times on the train, which is generally a pretty horrific two hour journey each way, but that could be four hours. Sit with a laptop, sit with a book and learn something new. At other times, I’ve had jobs where scheduling is inefficient, people are often late for meetings. I haven’t been opposed to carrying a book or carrying my laptop around with some learning on it. If I get to a meeting room in time for a meeting, and no one else is there, sit and read and go through a blog post, go through some documentation, make use of that time.

And I just look for ways of fitting it in throughout my day. I’ve worked at a company, we’re going around 15, 16 years now, where quite often it took 10 minutes to do a build and then a test. That 10 minutes, you couldn’t do anything else, so I went through a bunch of Herb Sutter’s articles on Dr. Dobbs at the time. Every time I did a build, click the build off, read an article.

So just looking for little bits of time you can find in your day that you can make use of things. More recently, I was working at the UK Met office. Quite a nice campus. And over lunch, I’d stick a podcast on and walk laps of the campus. I was getting a bit of exercise, getting some fresh air and listening to a podcast. Same went out again. It’s an hour and a half drive from there back to where I live to take a podcast on in the car. So there are little times when most of us can find time during our day if we want. Just looking at how do you use that? How do you fit things in? How can you claw that back? And if you look there’s quite a lot of bits of wasted time during your day now. They won’t be as efficient. If you get that five minutes at the end of a meeting or before a meeting when you’re waiting for something else. And you’ll get interrupted just maybe as you get into the juicy bit of the blog. So it’s not as efficient as if you sat down and had now a focus time to do it. But if you’re really struggling for time, it gets you something. It gets you moving.

And then, I’ve always been quite lucky to work with teams where we’ve had an emphasis on CPD or when I’ve been a manager I’ve done that. So we’ve normally set aside one or two hours a week to be able to do that quite often with a team member doing a presentation or bringing along a YouTube video that they thought was interesting on a conference talk or a podcast. Sticking it on for half an hour as a team, watching it and then discussing it.

Henry Suryawirawan: That is really practical tips, right? For those of us who struggle, always struggle to find time. Or some of us actually think if you want to learn something deep, we have to spend, I don’t know, like how many hours uninterrupted, before we can actually learn something. But actually, that is not true. Just like what John mentioned here. Find a little bit of time here and there, right? Maybe during your commute, maybe during your break, or maybe even before the meeting starts. And actually, quite classic, right? When the build actually is running, because I believe 10 minutes is quite fast for you, actually. So many people run maybe like 30 minutes to one hour kind of a build. So don’t waste the time there. Actually, you can learn something while waiting.

[00:27:15] Working for Non-Big Tech Companies

Henry Suryawirawan: So another thing that I’m really interested in, right. You actually mentioned before this conversation that you find many engineers aspire to work in big tech companies. But actually, in reality, so many engineers, you mentioned like 99% of engineers probably wouldn’t have a chance to actually work in big tech company. And hence we should actually focus on leveling up working in a kind of like non-big tech company. So tell us a little bit more about this reality, right? Because many people still aspire to work in a big tech giants. But yeah, not many opportunities are available, right? So tell us a little bit more about your perspective here.

John Crickett: So I did the numbers on that about six, seven months ago, because social media is flooded with people telling you how to do LeetCode, do system design and pass the interview to get into Google, Facebook or, you know, big tech company of choice. And when I did the numbers, the number of engineers they’ve all got, it’s less than 1% of the people who work in software engineers. So 99% of us aren’t working in big tech. Now, some of us probably never will.

Until fairly recently, most big tech in the UK, what there was of it, was based in London. I spent most of my career trying not to work in London. So, whether or not big tech wanted me, I didn’t want to work in London in their offices. I didn’t want that commute. I wasn’t prepared to move there. I may never have got accepted, I don’t know. Not pursued it. But outside of London, if you don’t live in London in the UK, and you’re not able, you don’t want to move there, there was just been very few opportunities. There’s a few more now that you can work remotely and now that things have evolved. But there’s probably a lot of smarter people than me that are better suited to fit themselves and again want that kind of lifestyle.

But for most of us is not going to be. And there is, again, if you look at social media, there’s this impression that everybody works in big tech, everybody builds websites, everybody does data engineering in the way that Airbnb do. But there’s not. There’s a massive world out there. There are people who are building software that fits in the microphone we’re using today or in the webcam that we’re using today, in the audio interface that’s in front of me. There are software in guitars these days, there are software in the guitar amplifiers these days. There are software in the lights around me. There’s software in your washing machine, your fridge, the medical devices that are in our hospitals, the aircraft, the air traffic control, the ships we have. Everything. And people are building all this software. And there’s a whole world of software outside of web development that almost gets forgotten about in social media. And a lot of it’s very interesting. There’s some really fun engineering challenges.

You know, if you’re trying to build some software that’s still fitting on an 8 or 16 bit processor with 16K of RAM, it’s a fairly different experience to building stuff on a web server with 64 gig of RAM. And however many Xeon cores or whatever. And there’s still people doing that. Then there’s still, you know, take your iPhone, for example. There are dozens of small chips in there, all running their own little embedded operating system, all with software that’s been written by somebody. And we forget about all of those, and there’s a lot of, there’s a huge world of software development out there.

Henry Suryawirawan: Yeah, so I think there’s a trend of, you know, learning system design, just like what you mentioned, right? And preparing for these big interviews as if like you’re interviewing for maybe the FAANG, right? The Googles, the Facebook, the Amazon, and all that. And people focus a lot on that, because simply the job is probably attractive, right? You’re probably solving bigger problem, you get a better pay and things like that. But in reality, maybe 99% of us actually probably don’t have a chance to actually work in such big tech company.

[00:30:39] Relevant Skills for Non-Big Tech

Henry Suryawirawan: And I think even building website and those APIs, right? I think software is eating the world these days. Everyone wants to build software in their company, right? So tell us a little bit more, what kind of skill set actually very important outside of the big tech giants that we should actually also level up?

John Crickett: So I think one key thing there is system design. So be aware there are systems outside of these big websites. So for example, my first exposure to system design was actually working on the signaling system for the Singapore Metro. Now that at the time was a pretty big distributed system. We’re talking, if I remember rightly, there’s about 64 nodes to that network, a few central servers, and they’re running over 96 board serial, originally. So, very slow serial connections between all different stations, between all the signaling systems. And back in 2000 when I worked on that, that was a pretty big distributed system. There’s some fairly powerful central service there. It’s a a network over serial cables of, I would say, nearly 70 nodes. That was quite big. How do you manage all that? How do you make sure all that’s coming through? There are very different challenges. It’s also, it’s a safety critical system. If trains crash into each other, people potentially die.

It’s a very different level of experience versus your Google search is 100 milliseconds slower. So you click on one, let’s add. It’s a very different level of scale. And, you know, the same, I’m sure for people doing software in avionics and aircraft and air traffic control. Or people doing software for NASA. NASA is a great example. They’ve been doing it for years. Far more focus on defensive programming. Far more focus on how do we have very, very high quality because you don’t get a second shot. Yeah, and also we don’t have that issue of scale. Instead, we want hard real time deadlines. And again, a lot of software engineers nowadays don’t really know what real time means, for example. And for something like NASA, it is hard real time. If you change the angle of entry of a spaceship coming into an atmosphere, it burns up and gets destroyed and you’ve lost hundreds of millions of dollars. And again, maybe people’s lives. That’s a completely different environment. So the skill sets you get vary hugely, and it depends which area you’re going to go into.

One thing I’d like to illustrate there is I’ve talked a few times about data engineering. Now I’ve done a bunch of data engineering over the last six, seven years. In that, I’ve hardly written any SQL. You see a lot of talk about data engineering and social media, and it’s all about Spark, how do we handle this data, how do we go into Snowflake? The data engineering I’ve done has been with hundreds of terabytes of data. But it’s all been binary. It’s been binary data for climate models that come off a supercomputer. It’s been binary data for audio files that are being processed and used to train machine learning algorithms. So the key skills you want to have is that curiosity that awareness that there are more things out there. The awareness that everything is not a website. The awareness that some things have very different constraints.

Scale can be very, very different again. So taking one of the systems I’ve worked on recently. We had 10 users at most. But it was pushing 20, 30 terabytes of data a day through the system. That’s quite big scale in one dimension, but miniscule in the number of users. But those number of users could easily push hundreds of millions of requests a day. So it gives you a very different perspective also. The key skill is to be curious, be interested. Be adaptable. Be aware that there are different technologies out there, different approaches, and be willing to go and look for the different experiences and different approaches that people have got. Because you can’t, particularly, when you do that kind of engineering, it’s less talked about. There aren’t necessarily the books about it. There aren’t necessarily, this is how Google does railway signaling systems, or this is how Google does avionics. You have to hunt down and track down people with expertise and dig into it a bit more and have that curiosity.

Henry Suryawirawan: Right. I think curiosity is definitely important, no matter you’re dealing with web or dealing with avionics or maybe any kind of software, right? Be curious. Having the passion to actually want to learn, I think that’s also another important stuff, right? Because it’s very easy to get stuck and just give up, right? But actually, figuring out the community, maybe finding open source project where you can learn from. And even like listening to podcasts, all these resources that are available, right? I think curiosity is definitely very, very important.

[00:34:44] AI Impact on Software Engineering Role

Henry Suryawirawan: So speaking about software engineering, one trend that is not going away is actually the involvement of AI. Be it building websites or building any kind of systems. So what’s your view, what’s your take about AI in the software engineering role?

John Crickett: So AI, I find quite interesting. I literally got into software because I was interested in AI. I was trying to do AI as a 10-year old on a BBC micro, which obviously was doomed to failure. And AI was, maybe from too much sci-fi, it was a passion, what got me interested in all these years ago. And it was kind of the late 80s when there was a bit of an AI hype cycle anyway. Then we had the AI winter. And right from the late 80s, all the way through my career, there’s been “in the next five years AI is going to put software engineers out of a job”. I think one day it might happen, but I think it’s a lot further away than we think. The current LLMs are amazing, you can do some great things with them. But they don’t reason, and you can see plenty of examples of this, if you genuinely look. They are effectively statistically picking what’s likely to be the next text in response to the text that you’ve put in. That can be incredibly powerful if you want some evolution, or something maybe translate a report a little bit, look at what code would be next, something that’s been done before. But it’s missing that reasoning. So I don’t see it being a big threat to software engineer’s jobs anytime soon.

I do see it as potentially quite an interesting tool, and one that we can leverage in many different ways. Probably more for us to say that translating data, how do we take something and present it in a different way. Which could be incredibly useful for learning as well as reporting and analysis, because one of the things I’ve done a lot when I wanted to learn something new is find multiple different sources, find multiple different blogs and multiple different books, because every author presents things in a different way. I’ve maybe found that with a subject, I might learn 10% from one book, 20% from a different book, 15% from a video. Because they all presented things with a different slant, a different viewpoint, used different terminology. Some would use longer, fancier words and I’d have no idea what they’re about. And some would talk to me like a five year old.

So AI is potentially incredibly useful for us to take these things and say, will you present this to me as though I’m a five year old or present this to me as if I haven’t heard of these technologies. I think it’d be very useful for learning for that, but I don’t see it replacing software engineers anytime soon. And the final reason for that is what we touched on earlier, is the hard bit is good requirements. You replace a coder with AI, you’ve still got to tell it what the requirements are. If you can’t do that, it’s going to give you just as bad software as a coder will. It’s going to struggle just like we will.

Henry Suryawirawan: I think that’s a very, very valid point, right? The requirements, right? Something that probably AI wouldn’t be able to help us. And as, I think also as long as the software is used by human, as in like they have human interface, right? Probably something also that needs a little bit more creativity, which AI probably wouldn’t be able to provide best as of now. And what you mentioned, right, AI currently doesn’t have a good reasoning. It’s all always based on like statistical or sometimes undeterministic right? That can probably lead to some bugs if you are not careful. I’ve been using AI a lot lately as well. So I find it really interesting, although sometimes frustrated as well, because of what I wanted actually didn’t get executed by the AI, so I have to fix that. So I think there’s always this kind of challenges, here and there. But I think definitely we all agree that AI can be really useful to help us maybe boost our skillset, learning about new things. Asking questions from like multiple perspectives, I find it really interesting as well, right? Because so many things now, we can just ask AI to actually give us a kickstart, right? You know, like if I want to learn something that AI can give us a kickstart and we can move on from there.

[00:38:21] AI for Coding Challenges

Henry Suryawirawan: So how about coding challenges here? Can AI actually help you solve those coding challenges? Or how would you envision, you know, using AI to work on those coding challenges that you have?

John Crickett: So I haven’t seen anyone solve them with coding of AI yet, and the few that I’ve tried and experimented with the AIs haven’t been very good at. They can, without hoping not to get sued by Stack Overflow, but when you’ve asked them how do you implement this, they’ve given an answer that’s incredibly like what was on Stack Overflow. So the kind of dumbed-down version that doesn’t meet all the requirements, and it almost looks like it’s regurgitating information from a Stack Overflow answer. And we all know that that’s not software engineering. You can’t just copy and paste simply Stack Overflow. You need to actually understand the code. Build a reason about it. Better add the requirements in the edge cases. So it’s falling short in that side, from what I’ve seen.

But Mike Thornton did an excellent piece. Must be about eight or nine months ago now, where he went through one of the challenges and he used ChatGPT to generate tests and to create the test cases for it. And he got a lot of mileage out of that way and it worked quite well for that. So if you look at Mike Thornton’s blog and how he’s tackled that on Substack, I think that’s quite an interesting lead. And that’s a potentially useful area where we can use it for to speed up coding.

Henry Suryawirawan: Right. I think some people get more creativity by using AI, definitely, you know, with the clever prompt engineering. So I think never underestimate the power of prompt engineering as well. Maybe one day AI will be able to give us a much bigger solution to a bigger problem.

[00:39:54] Building Personal Brand

Henry Suryawirawan: So another thing that you are doing at this moment is about personal branding. I can see that you actually encourage software engineers to build personal brand. And you even have a course about it, right? So tell us why everyone should build personal brand these days.

John Crickett: Well, we’ve seen all the layoffs that have occurred recently. We’ve seen the job market change from, you could stick your resume somewhere and your phone would ring off the hook, and even if you didn’t stick your resume somewhere, people would be hassling you on LinkedIn trying to recruit you as a software engineer. We had, you know, hyper demand recently. The market’s changed. There’s been a lot of layoffs. The demand is a lot calmer now. So as people want to differentiate themselves and people want to stand out, a brand is a way, a personal brand is a way to do that.

A lot more recruitment these days is coming through your network. Well, it’s always come a lot through your network, but a lot more is coming through who your network is and what you’re known for. Recruiters are going to look for people. So, again, if you’ve got good AI experience and you’re known in AI, I’m sure you’ve got people knocking down your door at the moment trying to offer you jobs. And, again, if you’re the Chief Scientist of OpenAI, if you were to look for another job, you could put a one line resume up there, you know, Chief Scientist for OpenAI. You wouldn’t need anything else on your CV to get. That would be enough of a brand for you to create. And, again, that’s why we see people put ex-Facebook, ex-Google on their CVs, because they’re trading off that brand.

For the rest of us, the 99% of us that don’t work in big tech, that brand has got to be what are we known for? What is our expertise? What have we done that’s unique and different? And for an awful lot of us, we can’t talk about we built Google, or we scaled AWS, or we designed their data centers, or we did something, you know. Most of us have been part of 99%. We’ve maybe built a few CRUD apps, maybe we’ve scaled them to something interesting, vaguely. So we need to find different ways of standing out, and different ways of differentiating ourselves from everyone else.

And that makes it easier for recruiters to come and get you when they’re given the shopping list of we want somebody who’s got some leadership, can lead a team, can mentor people, knows PHP, VB, and C#. Then if you stand out as a personal brand, they might have seen your post, they might recognize your name. They might find you in a search on LinkedIn. Basically, it makes you findable, makes you attractive to somebody. Again, if you’re showing that thought leadership, to use that quite horrible term, and you’ve built a personal brand, maybe if I’m a hiring manager looking for somebody and thinking, I really want somebody that knows about AI. If they’ve been following your posts, maybe they’ll reach out to you. Maybe when you put open to work on your LinkedIn profile, they’ll think, oh hell, I’ve got to talk to that guy because they’re an expert on AI.

Alternatively, if you want to build a business and you want to do something in some way. So I want to look at helping people level up this coding challenges. My name’s not quite well associated with coding challenges. If people want to think, if people mention real world projects to level up or what can I build, the response generally now from the people on LinkedIn is to mention Coding Challenges and my name. So, you know, for better or for worse, that’s kind of my personal brand now, and that’s what I’m known for, and that’s what people associate with me now. Not quite as monetizable and valuable as being known as the Chief Scientist of OpenAI, say, but it still means that I’m now set apart and differentiated.

And again, if you’re a junior developer without experience and you can’t stand out from someone. But maybe you can get known for having built some interesting little bit of open source. So I had this conversation this morning on LinkedIn. Somebody’s saying, oh, junior developers can’t do anything. They need to have years of training before they can do something useful. Well, Linus built Linux when he was a student at Helsinki Uni. He wasn’t even a junior developer. He was still a student. He never actually, as far as I’m aware, became a junior developer, because Linux took off before he graduated. And he’s just worked building that open source software, since that has become his career.

Now, okay, not everyone’s going to do something like that, but if you’re a junior developer with no experience, and you’re not known, you don’t stand out against a lot of CVs, you’ve got nothing in your CV, you can’t show any impact, you can’t show what you’ve done. If you’ve built an open source project that maybe 10 companies are using and getting value from, you’ve now built some real world software. You’ve got something published, people are getting value from it, you can talk about some impact. Even though you’ve never had a job, you’ve not got any experience. You have got some experience to talk about. Like I say, if you’ve got 10 people using it that are finding it valuable, that’s going to put you head and shoulders above 99.9% of the other junior developers that you’re competing with. You know, you don’t have to be Linus, you can just find that few users that are delighted with your software.

Henry Suryawirawan: Oh, what a fun fact just now. I wasn’t aware as well that Linus actually started building the OS when he was back as a student, right? So I think that’s kind of like a inspirational story, right?

[00:44:28] How to Build Personal Brand

Henry Suryawirawan: So many people probably, they want to build personal brand, but they don’t know actually where to start. Or they feel that they don’t have unique enough value or maybe skill set to actually offer to build a personal brand. So maybe some tips from you, how to get actually started. Like maybe should we actually pick a niche or should we just randomly post something or should we do something else? Maybe from your experience how would you advise people to get started actually?

John Crickett: So, the right answer is pick a niche and be curious. So decide this, I mean, take Linus for example, he was interested in operating systems. He wanted to implement something. So he did, and he went deep, deep into that niche. And you can’t mention Linux without thinking of him now. So he absolutely owned that niche. And that is the best way. I’ve epically failed at that because I have many different interests. I’m quite curious. So I’ve completely failed at a niche, because, yeah, I love coding challenge and I’m really interested in coding and software. I’m also quite interested in business. I did an MBA. I’ve run a few businesses. I got fascinated in corporate finance for that. So I’ve dug deep into that and my MBA dissertation was corporate finance.

When I started my first business, I was a very typical software engineer. Sales is a dirty word. Don’t want to do that. And marketing, they’re just those annoying people that promise the customers lots of things that we’re never going to do. Yeah, fine. Good for you. Can’t really object to it in many ways, but when I started the business, you suddenly realize, actually, I’ve got to go and sell to somebody. I’m not eating this month. I need some customers. I need somebody to pay me money. So I have to learn sales and marketing.

I found that actually, sales isn’t bad. It’s just talking to people and being interested in them. Being curious. Hey, Henry, what’s your problem? What are you struggling with right now? Oh you need some software to do that. Cool. We can do that for you. I can solve that problem. What’s it worth for you to solve it? Oh, it’s worth 500. Cool. We can do it for 450. It’s a simple sale. Now, somebody’s told you what their pain is, they’ve told you what is worth solving for them if you can solve it for a cost effective value, you sell. And actually when you take that it’s a transferable skill as well, if you go back to employment and working for people. If you want, as a Staff plus engineer, you want your company to be like something in Rust or Go, you are selling. You’re not selling something for money, but you’re getting people to invest their time, their belief and buy into that. So, you know, sales is incredibly valuable and you get those transferable skills.

Henry Suryawirawan: Right. So I think, definitely, learn. Sometimes even like you don’t even need to pick a niche in the beginning, right? You can try out different stuff, right? You can talk about something that has some interest. You know, like you have some interest in it. Maybe start from there and you can see whether you love doing that. Sometimes the brand doesn’t have to stick forever, right? So it doesn’t mean that you’re now doing coding challenges and that’s going to be the only thing that you’re doing for the rest of your life, right? So your brand can also still change. Yeah, and, and…

John Crickett: Yeah, it’s like I say. I’ve done coding challenges. I talk about soft skills, I talk about recruitment, I talk about some of the training I do in different areas. I pursue a lot of my different interests, so niching is a better approach. I’m not very good at it because I’m too curious and follow my curiosity. But that eclectic mixture of curiosity and experience that we’ve all got actually makes us unique, so there is probably no one else in the world, though there are many better software engineers, there’s no one else in the world that’s had that experience in me of building a railway signaling system, building a CRUD app for McDonald’s, working on meteorological data, working on voice biometrics, and now building coding challenges. So I’m unique and there’s some unique lessons from that that will help somebody.

There might be a junior developer that’s had this unique experience of building some software for a university club or something that is a bit unique and different. So we’ve all had a unique journey. And even if you are that junior developer with a year’s experience, there’s a person that’s just graduating that hasn’t had that experience that can learn from you. And the year behind them is the person that’s in their second year at university, and they can learn from the person that’s in their third year. And the year behind them is the next person, and the year behind them is, you know, go back to 10-year old coding his bedroom and can learn from a forum from an 11-year old coding in their bedroom somewhere else. So there’s always somebody further behind you that can learn from your journey and benefit from that.

Henry Suryawirawan: Yeah, another tips, which you can also follow just like what you mentioned, right? So think of yourself two or three years ago, right? What kind of problem did you encounter? And what would you actually expect some kind of resources that are available to help you solve those kind of problems? Maybe you can provide that now to help people who are also struggling with the same kind of challenges.

And the other thing, probably as an alternative, is like learning in public can also be a way of building your personal brand, right? So let’s say if you take John’s coding challenges, for example building Docker, and you don’t know where to start, but actually you’re sharing what your learning journey to solve that Docker challenge. It could also be one way to actually build a personal brand, right? And who knows that by building that kind of a niche, by solving the challenges, you actually build a community around you as well. So I think that’s also another power of learning in public.

[00:49:25] 3 Tech Lead Wisdom

Henry Suryawirawan: So, John, I think it’s been a pleasure talking to you and learning from your journey, learning from your experience. Unfortunately, we have to wrap up. But before I let you go, I have one last question that I always love to ask my guests to share, which is I call the three technical leadership wisdom. So if you can think of it, just like advice that you want to give to us listeners here, what would that be?

John Crickett: So I wrote down these three, because you asked for this before. And I’ve hammered one home too much, so my apologies for that, but it’s be curious. Be interested, be curious about the world. That willingness to learn and ask questions will make it a lot easier to lead in every single way.

The other thing that I think a lot of leaders miss, and my second point is be careful. If you are in a leadership and a management role, when you come and ask what seems to you like an innocent question, if you’re in a position of authority over someone else, it seems like an order to them. So when you say, can we add this feature to the software? They don’t hear, is it possible? They hear, “Go and do it.” So as a leader, be careful what you ask for. Your questions will be turned into or heard as orders and instructions.

And the third one I wanted to point out is good leadership is about being a good follower. So, no matter where you are in your leadership journey, you will have somebody else above you, somebody you’re following. If you’re an engineering manager, sure, you might be leading your team, but you’ve probably got a Director or a VP above you. If you’re that VP, you’ve probably got maybe the CTO or somebody above you. The CTO, you’ve got the CEO or the board. If you’re the board, you’ve got the shareholders. We can keep following this up. So, you know, leadership is as much about following the people that you should be following, and being a good follower, and setting a good example for people that are following you.

Henry Suryawirawan: Very interesting, because I rarely hear about this. Be a good follower, for leaders, but I think actually that’s true as well. So you’re always responsible for somebody or something, right? So don’t always assume that leadership is like the top position where you can direct people. But you also need to be a good follower.

So John, for people who would love to do your coding challenges or learn more from you, is there a place where they can reach out to you online?

John Crickett: Yep, sure. If you search for John Crickett on LinkedIn, you’ll find me easily enough. It’s a fairly uncommon name. If you search on Google, you’ll find me easily enough. And Coding Challenges is on codingchallenges.fyi.

Henry Suryawirawan: Right. Thank you so much for being here today. So John, I hope you, you are able to spread more coding challenges to people so that we all can learn and level up our skillset because of that.

John Crickett: Cool. Thank you, Henry. It’s been a pleasure.

– End –