Social media is flooded with people telling you how to delete
code, do system design and pass the interview to get into
Google, Facebook. 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 if you look at social media, there's this impression that
everybody works in big tech, everybody builds websites, but
there's not. 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. Hey everyone, my name is Henry
Surya Virawan and you're listening to the Technically
Journal Podcast, the show where I'll be bringing you the
greatest technical leaders, practitioners, and thought
leaders in the industry to discuss about their journey,
ideas and practices that we all can learn and apply to build a
highly performing technical team and to make an impact in your
personal work. So let's dive into our journal.
Hello everyone, welcome back to another new episode of the
Technically Journal Podcast. Today I have with me John
Cricket. 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 coding experience.
So welcome John to the show. Looking forward for our
conversation. Thank you Emily, thank you for
inviting me on the show and thank you for reminding me that
I'm getting great. Been doing this for nearly 30
years all. 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.
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.
Sure. I've been a software engineer
for about 30 years now and I guess the highlights for me is
being seen how much the industry has changed since then.
I started off at a very traditional engineering company
who were focused on things like radio Commons and very
traditional software engineering very, very quickly where within
a year or two got experience for Internet service providers and
the birth of the Internet, 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 looked at 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 get to build and so.
Hey, thank you for being part of the Techledjournal community.
This show wouldn't be the same without your ears, and you are
the reason this show exists. If you're loving TLJ and want to
see it keep on growing, consider becoming a patron at
Techledjournal dot Def Patron or buying me a coffee at
Techledjournal dot Def Coffee. Every little bit helps field the
research, editing and sleepless nights that go into making this
show the best it can be. Thanks for being the best
listeners any podcast could ask for.
And now let's get back to our episode.
So I think I also experienced back then, right when the
Internet was just starting, previously, it was even quite
slow, right? 56 kilobits per second.
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.
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 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? Yeah, sure.
So I started off, as you say, it's an ICA, very traditional
engineering company briefs into an Internet service provider,
the early part of the Internet. And then I moved around a couple
of engineering companies and then I moved into, should we say
more tech companies andthewhole.com boom was going
on. And I had me, we were hearing
about Google, Yahoo, Amazon, Geocities and other companies
are 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.com boom around me, it's like should do it now.
Why am I waiting? Lots of other people 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 it my epic failure of imagination.
I just started a software consultancy just like the
companies had worked. No big vision.
No, I'm going to start the next Google.
Just 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 kindofdoingthe.com so ended up
building a bed 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 and 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
decides pure adventures. Ended up moving into different
areas, got married and started found myself.
So playing 60 hours a week into a business just wasn't viable
anymore. So I went back to working for
the people really IC, created that for a few years, moved into
management employment. Then coming up to 2018, again, I
was doing a lot of travelling. I want 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 I'm educated and pandemic,
everyone at the Moat. So I ended up going back into
management goals, did that for a little bit, but then also
circumstances. And here we've had tech layoffs
a lot laid off as well. That put me back to contracting
and eventually that's worked me back to now starting up my own
business, which is what I am now doing.
Yet another small scale startup, should we say?
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.
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? 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, you decide it's not for you, it will have given
you that insight into what the role involves.
It'll give you more empathy with what a manager is trying to
achieve who 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 careers and 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 backed, you can
use to go staff and staff plus. And that awareness, the kind of
awareness of the big impact, the awareness 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 it might be interested to try it because if you find it's
a career for you, right, If you don't do the transferable
skills, you can bring back to being a software engineer.
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?
Well, I think it depends on the market you're in because here in
the UK at least, the best paid roles and all being 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 see your 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 could out for it.
It's a different skill set. But there are increasingly and I
would say about 1/3 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 benefit,
it's better pay and you feel that it's valuable but you hate
it, start upscaling. Do some of the coding
challenges, practice your E code, whatever it takes.
Find a company that has a 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 that means stuck in a
job you don't like. Yeah.
So I think being stuck definitely is not going to 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. 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? So I think there's two sides to
that. The importance of the vision is
if you want to build who I Care B&B, you need to be thinking
bigger. You need to be thinking about
executing much bigger than I ever did.
And I think also it strikes a point that I've made several
times that ideas are worthless. I've thought about did B&B
solution long before the B&B 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.
It is. And 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, more like myself?
I would rather build what many people call a lifestyle
business. Now I, I, I enjoy working
remotely. I enjoy working from home.
This is my office. My office has guitars in it.
It's very comfortable. I would rather now build a
business where I can comfortably make hopefully a 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 flexibilities. Whereas if you want to build
something that's maybe a mid tier 10/20 million company,
again, that vision, a clear idea of what you want and why you're
going there, I think that really helps.
Yeah, I think that's why 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 if you don't
reach there, at least you reach some way almost near to that
vision. 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?
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 extracted by whatever people aiming for.
So it's very easy. If you look on social media, if
you see people talking about a lifestyle business where they're
making 456 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, is
a bit naive. Or 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 folks you're about.
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 and gain that joy from it.
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 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.
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?
So it's a bit of a mixture. As I mentioned, I got made
redundant couple years ago and I was looking around and thinking,
when I've learned 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
learned than when I work 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, 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 learned quite quickly that
actually it's not just the idea, it's, as we said, the execution
that matters. And a big chunk of the execution
is that distribution. How do you have people,
companies, organizations, however your customer's going to
be to sell to? How are you going to get your
products, your service in their hands?
So I thought, actually I see a lot of people talk about social
media, personal plans. I should do that, build up a
file and build up a bigger network in software engineers,
trade the distribution and then figure out what of all the
problems that software engineers have, Can I solve that?
What am I interested in solving? So I started doing that.
So I build on my personal brand and started building, posting on
LinkedIn like UAE and trying to create that.
And as part of that, I also talked to a few 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 was
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 it. I don't, I like picking up a
buck and just implementing a function.
I wanted to build an actual software.
And I've done that. And I've got a correction 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 1000 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 1500 people
subscribing the first weekend. So at that point, for there's
something here. So I'll keep building this and
I've definitely got to pursue this.
This will lead somehow to the business idea of 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. I think that's very interesting
idea in the 1st 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 March. 11th, 2023.
Started so it's kind of like a popular on the LinkedIn.
I can see that. 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. So out of these projects are
great if you want to go and learn that algorithm, learning
that data structure, understand how to implement it, maybe test
out and understand the time space complexity so you get that
basic knowledge. But very few of us actually like
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. If you're 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 the network protocol?
How do we implement a network protocol?
How are we going to store data? What log in do we need?
How are we going to make 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 say, if you want to
practice building a network protocol and a server and
exploring asynchronous multi threading for 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'll choose to do that and
actually build those applications and experience it.
And if you take it far enough, you then implement things like
CICD. Maybe if you're doing the like
Dropbox code, you might implement some infrastructures
code. You might actually those files
actually deploying it. And when you do that, when you
build a new 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 like 10 line solution for leak code,
you're not facing those same challenges.
So that's why my focus is like build the skills to do the work
to building real world software. 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.
Well, that's going to sound like an advertisement I'm afraid,
because the obvious tips are go to coding challenges dot FYI.
And I've done that work for you. I have 60 on projects there
where I've explained what you're going to build and I've
explained, you know, for the Docker 1, here are the man
pages. Here are how you can look at
things like sys groups in Trigroup and C group and
Triloot. 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 leave 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 0
allocation parser. Don't read about that and learn
about that. And that's quite interesting.
Or latest for example, is one of the few things that come across
is using skip lists. So if you want to learn about
data structures, that's a different data structure 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 functionality
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 pragmatic programming described as a walk from
skeleton. So what's the smallest vertical
slice of functionality I can pull out and identify?
So for a server that might be, I could connect and do a ping.
In fact, you know, that's pretty much what it is for Lettuce.
I can receive a TCP Ari key connection, get the ping
message, parse it, and respond correctly with PONG.
And that's your fairly simple walking skeleton.
And then it's just layering stuff on top of that, figuring
out what the next little incremental step is.
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 kind of resources are still not a lot
over the Internet, even like I what I can see, for example, by,
but Go 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.
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 applications,
right? It's not just the coding, but
it's like the observability, the CICD, 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?
So I think it's all about learning by doing.
So again, when I like the challenges, I quite often leave
little bits out. So I'll say you need to
implement this protocol or say the tar challenge is a
relatively simple tool, but to implement it, I've basically
pointed you out. Here's the spec that you can
find in Wikipedia. Go and leave the file format and
understand it. Here are some of the tools you
can use to actually go and explore the binary file.
It's better to see what's in it and explore that data and start
understanding it. And even if you didn't do the
challenge and write the code, you'd go and look at the binary
file and say, well, it's got a header.
The header has these bytes. Well, that's how we structure
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.
And a job of somebody's going to give me 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
leave them and go. But what about this?
What about this edge case? Have we thought about this?
And now 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 Lens, Go. 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 that 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
this. Go and experiment, be curious
and go and take steps that you will have to do in the job.
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.
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.
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 in my business. In the past I've approached it
by looking at where there is dead time in my day.
So I've commuted to London a number of times on the train,
which is generally a pretty horrific 2 hour journey each
way. But that could be 4 hours.
Sit with a laptop, sit with a buck and learn something new.
And other times I've had jobs where scheduling is inefficient.
People often like for meetings. I haven't been opposed to
carrying a buck or carrying my laptop down with some learning
on it. If I get to a meeting room, it's
time for 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 looked for ways of fitting it in front of my day.
I've worked at a company, we're going around 1516 years now,
where quite often it took 10 minutes to do a build and then a
test. Not 10 minutes.
You couldn't do anything else. So I went through a bunch of
Hipsetas articles on Doctor Dobbs at the time.
Every time I did a build, click the build off, read an article.
So 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 the walk lapse of the campus.
We're getting a bit of excise, getting some fresh air and
listening to a podcast. Same one out again.
It's an hour and a half drive from there back to where I live.
Stick a podcast and in the car. So the little the little times
when most of us can find time during a day if we want.
Just looking at how do you use that?
How do you fit things in? How can you call 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 5 minutes at the end of the meeting or before
meeting when you wait for 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 an hour
focused on to do it. But if you learn 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 CPT or when I've been a manager, I've
done that. So we've normally set aside one
or two hours a week to better do that quite with A-Team member
doing a presentation or bringing on a YouTube video they thought
was interesting on a conference talks or podcast, sticking on
for half an hour as a team, watching it and then discussing
it. 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. So another thing that I'm really
interested in, right? You actually mentioned before
this conversation that you'll find many engineers aspire to
work in a 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 this 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 yet not many opportunities
are available, right? So tell us a little bit more
about your perspective here. So I did the numbers on that
about six or seven months ago because social media is flooded
with people telling you how to delete code, 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 that are working software
engineers. So 99% of us aren't working in
big tech now. Some of us probably never will.
Until very recently, most big tech in the UK, what there was
of it was based in London. I've 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 mean, if we've got accepted, I don't know and not pursued it,
but outside of London, if you don't live in London in 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 them out with 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 kind of lifestyle.
But for most of us, there's not going to be.
And there's, again, if you look at social media, there's this
impression that everybody works in big tech, everybody builds
websites, everybody does data engineering 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. 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.
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 thing
on an 8 or 16 bit processor with 16 K of RAM, it's a fairly
different experience to building stuff on a web server with 64
gig of RAM. And however many see on cores or
whatever. And there's still people doing
that, then they'll 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.
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 that you're interviewing for maybe
the Fang, right, the Google, 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. And I think even building
website and those APIs, right? I think software is hitting 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.
So I think. One key thing though 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 a pretty big distributed system.
We're talking, if I remember rightly, there's about 64 nodes
to that network, few central servers and they're running over
96 board serial originally. So very slow serial connections
between all different stations between all the signal systems.
And back in 2000 when I worked on that, that was a pretty big
distributed system. There's some fairly powerful
central servers there. It's a network of serial cables
of that would say nearly 70 nodes.
That was quite big. How do you manage all that?
How do you make sure all that's going 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 of us 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 focused on defensive programming, far more focused 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 someone 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.
It's a completely different environment.
So the skill sets you get very hugely and it depends which area
you're going to go into. One thing I like to restrict
there is, I've talked a few times about data engineering
now. I've done a bunch of data
engineering over the last 6-7 years in that I've hardly been
in 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 to go into Snowflake?
The data engineer that 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 minuscule 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 to be curious, be interested, be
adaptable, be aware that the 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 when you do that kind of engineering.
So that's talked about. They aren't necessary.
The books about it, they aren't necessary.
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 and have that
curiosity, 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 podcast, all these resources that are available,
right? I think curiosity is definitely
very, very important. So speaking about software
engineering, 1 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?
So AI. Find quite interesting.
I literally got into software because I was interested in AII,
was trying to do AI as a 10 year old on the PVC micro, which
obviously was deemed to failure and AI was maybe from too much
sci-fi. It was the 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
hope cycle anyway. Then we had the AI winter right
from the late 80s all the way through.
My career has 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, 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 evolutionism or maybe translate the port a
little bit, look at what code would be next has been done
before, but it's missing the reasoning.
So I don't see it being a big factor software engineers 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.
And I have maybe found 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 have no idea what
they're about. And some would talk to me like a
5 year old. So AI is potentially incredibly
useful for us to take these things and say we present this
to me as though I'm a 5 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 who placing software engineers anytime soon.
And the final reason for all that is what we touched on
earlier is the hard bit is good requirements.
You replace a coder with AI, you 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 coder will.
It's going to struggle to your side.
We will. 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 yeah, 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 AIA 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 skill set, 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 kick start, right?
You know, like if I learn something that AI can give us a
kick start and we can move on from there.
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? So.
I haven't seen anyone solve them with coding both AI yet and the
few that I've tried and experiment with the AIS haven't
been. They can without hoping.
Not getting sued by Stack Overflow, but when you've asked
them how do you implement this, they've given an answer that
looks incredibly like what was on the Stack Overflow.
So the kind of dumbed down version that doesn't meet all
the requirements. And it almost looks like
actually gurgitating information from a Stack Overflow answer.
And we all know that that's not software engineering.
You can't just copy and paste it stack over you.
We need to actually understand the code better, reason about
it, better the requirements in edge cases.
So it's fallen short on that side from what I've seen, but
Mike Formson 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, and he got a lot of mileage out of that way.
And it worked quite well for that.
So if you look at Mike Fornton's blog and how he's tackled that
on Sub Stack, 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, right, I think. Some people get more creativity
by using AI, definitely, you know, with the clever prom
engineering. So I think never underestimate
the power of prom engineering as well.
Maybe one day AI will be able to give us a much bigger solution
to a bigger problem. So another thing that you are
doing at this moment is about personal branding.
I can see that you actually encourage software engineers to
be a personal brand, and you even have a course about it,
right? So tell us why everyone should
build personal brand these days? 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 lesbian somewhere, people
would be hassling you on LinkedIn trying to recruit 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, if people want to stand out, a band
is a way, a personal band is a way to do that.
A lot more recruitment needs says this can be through your
network. Well, it's always coming a lot
for your network, but a lot more is coming through 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 know it 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 open AI, if you
were to look for another job, you could put a one line lesson
there. You chief scientist for Panaya,
you wouldn't need anything else on your CV to get that would be
enough of a brand for you 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 studying out and
different ways of differentiating ourselves from
everyone else. And that makes it easier then
for the cruisers to come and help you when they're given a
shopping list of we want somebody who's got some
leadership can lead a team, commence people knows PHPVB and
C#. Then if you send out as 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
for leadership to use that quite whole term and you've you've
built a personal brand. Maybe if I managed to look at
somebody thinking I really want somebody to know 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 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 with coding challenges.
My name's not quite well associated with coding
challenges. If people want, if people
mention real world projects to level up or what can I build the
response generally now from the people that intend is to mention
coding challenges on my name. So for better or for worse,
that's kind of my personal blend now.
And that's what I'm known for. And that's what people that say
show with me now, not quite as monetizable and valuable as
being known as the chief scientist of open AI 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
actually this morning on LinkedIn.
Somebody's saying 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, OK, not everyone's going to
do something like that, but if you're a junior developer with
no experience and you're not knowing, you don't stand out
against what CV you've got. Nothing you'll CV, you can't
show any impact. You can't show what you've done.
If you built an open source project that maybe 10 companies
are using and getting value from, you've now built some of
your old software, you've got something published, people even
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.
And I'd say if you've got 10 people using it, that finding it
valuable, that's going to put you head and shoulders above
99.9% of the ever genie 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.
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
an inspirational story, right? 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 so.
The right answer is pick a niche and be curious.
So decide this. 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 owns 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 that we're interested in coding in
software. I'm also quite interested in
business. I did an NBA, I've run a few
businesses. I got fascinated in corporate
finance for that. So I've dug deep into that and
NBA dis station in corporate finance.
When I started my first business, I was very typical
software engineer. Sales as a doer, don't want to
do that. And marketing, they're just
those annoying people that promise the customers lots of
things that we're we're never going to do.
Yeah, fine, good view. Can't really object to it in
many ways. But when I started the business,
she suddenly likes, actually I've got to go and sell
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.
And I found 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 you struggle 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 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 you lost or go, you are selling.
You're not selling something for money, but you're getting people
to invest their time, their belief and buying to that.
So you know, sales is incredibly valuable and you get those
transferable skills, 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 the only thing that you're doing for the
rest of your life, right? So your brand can also still
change. Yeah.
And and yeah, it was 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, pursue a lot of
my different interests. So niche 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 experience we've all got actually makes us unique.
So there is probably no one else in the world.
There are many better software engineers.
There's no one else in the world that's had that experience of me
of building a railway signaling system, building a CRUDAP 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 them that
will help somebody. There might be a junior
developer that's had this unique experience of building some
software for their the university club or something
that it's a bit unique and different.
So we've we've all had a unique journey.
And even if you are junior developer with a years
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
the third year. And the year behind them is an
expert. And the year behind them is, you
know, go back to 10 year old coding his bedroom can learn
from a fallen 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. 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 are sharing what you are 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. 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?
So I let Danny. 'S free because you asked for
this before and I've hammered one home too much, so my
apologies that, but it's be curious, be interested, be
curious around 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, in a management role, when you come
and ask what seems to you like an innocent question, if you're
in a position of a faulty of 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.
There's 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 some minutes 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 CTO, you've
got the CEO of the board. If you're the board, you've got
shareholders. We can keep following this up,
but 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 that people that are following you.
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? Yep, sure, if you.
Search for John Cricket on LinkedIn, you'll find me easy
enough. It's fairly uncommon name you
search on Google you'll find me easy enough.
And coding challenges is on codingchallenges dot FYI right?
Thank you so much for. Being here today so John, I hope
you are able to spread more coding challenges to people so
that we all can learn and level up our skill set because of that
cool thank you Henry it's. Been pleasure
the.