Cup o' Go

★ Support this podcast on Patreon ★

Creators & Guests

Host
Jonathan Hall
Freelance Gopher, Continuous Delivery consultant, and host of the Boldly Go YouTube channel.
Host
Shay Nehmad
Engineering Enablement Architect @ Orca
Editor
Filippo Valvassori Bolgè
Sound Designer / Audio Editor based in Milan

What is Cup o' Go?

Stay up to date with the Go community in about 15 minutes per week

Shay Nehmad:

This show is supported by you. Stick around till the outbreak to hear more about that.

Shay Nehmad:

of go for November 8, 2024. Keep up the dates with the important happenings in the Go community in about 15 minutes per week. I'm Sinek Mann.

Jonathan Hall:

I'm Jonathan Hall.

Shay Nehmad:

We're getting close to the end of the year. I don't know if you're preparing for Christmas already. I already heard some jingles. I'm really worried that we're gonna mess up the intro for, like, January. It's gonna be a month where we do the intro and say, this is for 2024.

Shay Nehmad:

Oh. Oh, no. It's 2025.

Jonathan Hall:

Stick around till the bloopers reel for for all that.

Shay Nehmad:

Oh, no. There's no bloopers reel. We force our editor, Filippo, to shred those files. We'll talk more about safer file open, operations later on the show. Mhmm.

Shay Nehmad:

But we have some cool stuff for you. We're gonna talk about the new release. We're gonna talk about some proposals that were accepted. We're gonna talk about some metrics even if they're vanity metrics.

Jonathan Hall:

talk about lead code.

Shay Nehmad:

Yeah. For sure. We're gonna talk about some Reddit posts and blog posts. I'm gonna repurpose the lightning round to talk about, my obsession with Factorio. And we have a very very, interesting and I think rather deep interview with John Cricket.

Shay Nehmad:

You you might know, as the person behind Coding Challenges, FYI. So we have a lot of stuff to talk about, so let's get into it. Right? Let's do it. Go 1233 and 1229 have been, released.

Shay Nehmad:

There's no immediate, security thing you have to worry about. It does include a lot of small bug fixes to the runtime. I think specifically if you're having issues with profiling, there are a few things that are interesting there. Some timer ticker bugs that we actually talked about, specific Mac OS stuff. So you can upgrade.

Shay Nehmad:

This time, it's not, if you're not experiencing the bugs, not hugely urgent. And because they're very specific, like, we won't go into them.

Jonathan Hall:

I am looking forward to the next release though. 1234.

Shay Nehmad:

Oh, that would be good. We either need, another 41, like, patches to get to 1, 2, 3, 4, 5, Or even more unrealistically, a 100, no, 221 or something like that.

Jonathan Hall:

Yeah. That'll happen in 60 years. Right?

Shay Nehmad:

Well, we can map it out. Alright. Let's do some proposals, man.

Jonathan Hall:

Alright. So we talked about this one last week, so we're not gonna go to the details. Listen to last week's episode if you want that. But the SAFER file open proposal has been accepted. So look forward to seeing that in probably 1.24, I'm imagining, in 3 or 4 months.

Shay Nehmad:

And, hopefully, in your API design courses, like, in the, like, slides that talk about

Jonathan Hall:

Yes.

Shay Nehmad:

How to do API design correctly. Put something on the board and then iterate until the API looks really, really, really, really good. And one other very obvious, proposal that should be likely accepted, if you have Mac OS 11, go, you know, stand on the picket line for this, proposal. It's in the final comment period because Go will drop, support for Mac OS 11 in Go 125.

Jonathan Hall:

It's still a year away ish. So yeah. But still, if you have vital services running on Mac OS 11 and need Go support, go make your case.

Shay Nehmad:

And it's actually gonna stop on, like, February 2026. So you have enough time to grab, like, a second hand, I don't know, Mac m Pro m 6. You know, you I was a very this is, unrelated. And we talked about, like, our personal favorite operating systems in the past, but I've been configuring my Mac more and more and more and more, and I'm I'm very much used to it. And it's it's great to see that they support and they and they have extra years supporting, for, you know, for Go versions because I use some Go tools just to, like, mess around with my machine, and it's great to know that I have, like, 3 years until the maintainer sees that their Go version is not supported anymore and they can recompile it with a newer version.

Shay Nehmad:

But just for small utilities that I use here and there. They're very orderly over there, the Go, release team. Probably really good at Excel. And they have to be because they have to maintain all these issues.

Jonathan Hall:

Yeah. Right? Like, I don't know, like

Shay Nehmad:

a 100 issues or something.

Jonathan Hall:

Yeah. At least. So, we actually should have talked about this last week, but I didn't even notice until today. But the Go issue tracker has passed number 70,000.

Shay Nehmad:

Is that a celebration?

Jonathan Hall:

I don't know. It might as well be for our show.

Shay Nehmad:

Is that good or bad? The fact that Go like, it it just means that Go had 70,000 bugs. Right? That sounds bad.

Jonathan Hall:

70,000 bugs, 70,000 duplicate proposals that got closed because YAML sucks. I don't know. Things like that.

Shay Nehmad:

I'm proud to have 3 of those. Yeah. And this one's actually one that is relevant. Like, it's a bug fix that actually was fixed in the release we talked about. Short rights with file server on Mac OS.

Shay Nehmad:

But, yeah, Paltrykov from Munich. You will live forever in infamy for opening the 70,000, ticket. Can I tell a story that's that's somewhat related? I think, it has statue of limitations, so I can tell it. At my previous startup, we were creeping up on the 1,000th, Jira ticket.

Shay Nehmad:

Right? Jira ticket number 1,000. And I really want to get it, so I opened 2 bullshit tickets and then I got 1,001.

Jonathan Hall:

I remember playing silly games like that back when we were using subversion because subversion commits are numerical order instead of effectively random on get. So I remember playing games like that with my colleagues trying to get, you know, commit number 1234 or or whatever fancy number we like.

Shay Nehmad:

Well, I guess we have, just, like, very much boring numbers until we get to a 100 k. Yeah. That took 10 years. So and but the goal is project is much bigger. So maybe in 2 years' time?

Shay Nehmad:

Cool. Cool. Cool. What else is in the future? Maybe not, 2 years, maybe next week.

Jonathan Hall:

Yeah. So next week, Golab is happening. We've talked about this before, but it's been a while. So in Florence, Italy, if you're there, November 11th to 13. Filippo Val Sordo, who's been on the show before, is the emcee for this event.

Jonathan Hall:

So look forward to that. And Russ Cox will be doing, the opening keynote. So I guess I picked the wrong time to move away from, Europe. I won't I won't be there. But, yeah, it should be a good show, good conference for those, of you who are able to make it to Italy.

Jonathan Hall:

Tickets are still available, so you still have a chance if you're in the area and wanna go.

Shay Nehmad:

Yeah. The they have a whole thing about why their tickets are priced as they are, and we really I really appreciate that being, like, upfront about why your tickets cost as as much as they do. If you're on the fence and you have a job, you can't convince someone to at your company to pay for this ticket. I a 100% guarantee you that.

Jonathan Hall:

It's also worth mentioning that, you can buy a combo ticket, which is good for both Golab and RustLab, which I don't even know when that is, but you can get a combo ticket for for both of those. So if, if you can get your company to pay, you might as well go to both conferences.

Shay Nehmad:

Yeah. If you dislike it's, Rust Labs starts just before Golab. It's November 9th. So you don't have a ton of time. You just have 2 days.

Jonathan Hall:

Yeah.

Shay Nehmad:

If you if you're, like, wanna hate on Rust and you like Go, then you can go and, do that. If you're the You

Jonathan Hall:

can do that for free on Reddit. You don't need to pay for a ticket.

Shay Nehmad:

Yeah. One last thing to mention is it's very I I always worry when I see a a Go conference site look really really good because I'm, like, wait, we're back end developers. Our our front end shouldn't look as good as this. This is, like, beautifully designed. Well done whoever did this, design on the website.

Shay Nehmad:

It's elegant. It's it's modern. It looks great. Good stuff. Talking about Reddit, there was a poster that I wanna get super deep into.

Shay Nehmad:

I just thought it was, interesting to mention for two reasons. So the post by violentcatnap. Right, is there a path forward for Go's YAML situation? Which is already, like Yeah. And upfront, they're saying, oh, now I need to deal with manipulating YAML files in parentheses, hell.

Shay Nehmad:

I'm like, yeah. This is not fun, usually. And the OPE, like, highlights 2 libraries, go yamll yamll and go c c y go yamll. And he's like, this has 300 issues and has been updated for 2 years. Go YAML YAML has its own set of issues.

Shay Nehmad:

I I thought this was, interesting because one of the 70,000 proposals that are on the backlog, I was like, hey, let's put Yaml in the standard library. Long story short, Rust closed it as infeasible. Apparently, I was, like, living in some world where I thought, oh, it's just like JSON but with white spaces. But apparently, there are so many things in the spec that are are weird that that I wasn't aware of. For example, one thing that I learned, a few weeks ago is when you type on in YAML, which I tend to do a lot because I'm in the engineering enablement team at Orca and we work a lot on GitHub workflows.

Shay Nehmad:

You remember the syntax of GitHub workflows is like on

Jonathan Hall:

Oh, yeah.

Shay Nehmad:

Full request to master. Right?

Jonathan Hall:

Yeah.

Shay Nehmad:

So on means true. It evaluates to true. And then you have to go into YAML int and saying, like, no. It's okay. Please ignore this line.

Shay Nehmad:

I didn't mean it to be a truthy value. I literally mean run on as, like, the trick. Mhmm. I'm still running into interesting YAML things. Is there a path forward for a go yamul situation?

Shay Nehmad:

One thing that's not gonna happen, it's not gonna go into the standard library. That's for sure. And then the other thing is that the one of the maintainers of the libraries that the OP mentioned actually commented and was like, hey. I'm the author of this, library. I started to develop it alone.

Shay Nehmad:

If you want it to be good, either put in pull requests or pay me. Like, he wrote it really all nice and and customer facing ish like, it's not full of the usual Reddit derision. But the bottom line is this, either put in time or money. This is open source. So just don't just complain.

Shay Nehmad:

I'm wondering what what's your take on this? Like, if you have to deal with YAML, what what library are you are you picking up?

Jonathan Hall:

So I I've mostly used go yaml yaml v 3, I think. I haven't run into problems that they're talking about in this post, but I haven't done anything interesting with it either. You know, I haven't tried to do inline modification of YAML structs or whatever. I've just done basic deserialization primarily. My take is the problem here isn't Go.

Jonathan Hall:

The problem is YAML. That's my hot take. YAML is basically it's more subtle than this, but I think YAML is a terrible format. So there's some nice things about it, but it sucks.

Shay Nehmad:

There's no, like, true YAML format. There's no specific thing. The only I I do think there is a a path forward, specifically for Go. And the path forward is if Kubernetes, on like Kubernetes we're on Kubernetes 131, right? I have to assume that 30% of the code that manipulates Yaml in Go is about Kubernetes.

Shay Nehmad:

Honestly, just like it's such a big project and so many of the projects that are written in Go are about, you know, all the CNCF stuff, all the whatever, creating maybe I'm just a bit too DevOps built, but it's definitely not 0.01%. Right? It's some significant part of the pie chart. I think if Kubernetes writes their own subset of YAML spec and says, this is the official spec that we're using. It's gonna make it a lot easier for everybody else who's doing Go to say this is the, like, standard we're gonna follow and if it's gonna drop some things from Yamel, for 99% of people like yourself, John, it doesn't matter.

Shay Nehmad:

If you're already doing inlining and all these very complicated, things and you're using n o as Norway instead of false or whatever.

Jonathan Hall:

So I I can appreciate that sentiment. I I don't I'm not as optimistic as you. Partly because I'm pretty sure they've already done that. They already have their own subset of YAML that they use. The the bigger problem though is that when you use YAML, you wanna be able to read YAML from various sources whether you're using Hugo or you're whatever.

Jonathan Hall:

There's a lot of places you get YAML sometimes. But if you build and consume your own YAML all the time, then you can just decide here's the version of YAML I use. That's fine. Problem is when you try to interoperate with other producers or consumers of YAML that aren't quite compatible. So I I really think the solution forward is to come up with a completely different language.

Jonathan Hall:

It's not a subset or a superset. It's just completely different so that you have an obvious break from the mess that is YAML, but good luck getting that adopted.

Shay Nehmad:

It's exactly that xkcd thing. Right? Oh, there are 13 standards. We need the to unify them. Oh, there are 14 standards.

Shay Nehmad:

Well, maybe there is, maybe there isn't. It's not the standard library, and I just wanna correct one, thing that, John said. John said, oh, if you're using Hugo, you might need to consume Yamel. But obviously, Hugo supports TOML, which is the format I used to configure my Hugo website.

Jonathan Hall:

It it does for the config file, but I don't think it does for the the what do they call the the content at the top of each file?

Shay Nehmad:

The front matter.

Jonathan Hall:

The front matter. Isn't that always, Tom, Yamal?

Shay Nehmad:

No. It can be Tamal as well. Oh, it can be. I do use Yamal for it just because I just use the key value and some lists. Mhmm.

Shay Nehmad:

But it does support Tom. Wait. You know what? Filippo put a a, like, waiting music or, like, frantic research music while I go look that up. Hugo, Front, Matter.

Shay Nehmad:

Because I think that's might be a markdown thing and not a Hugo.

Jonathan Hall:

It supports Jason, Toml, or Yammel, apparently.

Shay Nehmad:

Hey. You know what?

Jonathan Hall:

Saying Jason or YAML is redundant.

Shay Nehmad:

Wow, I might switch my You have

Jonathan Hall:

to change your, you have to use plus plus plus instead of minus minus minus to indicate Toml though. I'm I'm okay with that. Or curly braces for Jason, which is silly since Jason is a subset of YAML. Or whatever.

Shay Nehmad:

Cool. So Hugo does support Tamil. Awesome. Factorial round. Round.

Shay Nehmad:

Round. Roughly. Here, you don't even have to do the effects. I did them for you. Welcome to the Factorio round where I apparently need to, first of all, inform Jonathan and the listeners who don't play Factorio or, like, 4 of you what what the hell Factorio is.

Shay Nehmad:

Factorio is, a game, where you do your job, where you program. It's it has a skin of, like, a game where you land on an any, alien planet that you have to build, like, these factories and automations. But it is actually just a way to teach you how to program, to collaborate, to manage projects, and to deal with, everything you need to do as a software developer. Okay. And it hooked me and my friends and we had a server and we won the game.

Shay Nehmad:

And recently the the expansion went out and we restarted our server and we're playing it again. I highly recommend it for anyone who wants to lose sleep and want to skip off work and have, Factorio consume, everything because the factory must grow. Cynicism aside, I think it's a good game. When you go online to, GitHub and you look at Go projects that have the name Factorio in them, you can find 100 of them.

Jonathan Hall:

Oh, wow.

Shay Nehmad:

And I'm gonna highlight 4 for this lighting round. Open Factorio server manager. Factorio server manager, is a tool to help manage Factorio multiplayer servers including mods and save games. Written in Go updated, just like a few months ago, I guess for in time for the, expansion. Pilots Mapshot, it's a Factorio mod, to export maps as zoomable HTML written in Go.

Shay Nehmad:

So the map, it's 2 d game and you land on an alien planet, right, and you build out your factory and you plop down conveyor belts and things like that. It's a tool that can, help you share your map as zoomable html if you want to share the map with someone else And then they have the example on the, Readme. Right? There's a page. It's zoomable.

Shay Nehmad:

It's really really good because it, like, whenever you zoom it re renders all the things to make them look, really nice. Specifically, they the factory they have lined out doesn't have the best layout, but that's, just my opinion. It's almost not a Go project, funnily enough. It's 40% Go, 25% Lua, 16% TypeScript, 13% JavaScript, and 4% CSS, which is a hellish combo. Yeah.

Shay Nehmad:

I don't wanna maintain that. No. Well, you know what? Lua does have a special place in my heart for being the one language that's one based and that I had to

Jonathan Hall:

use. Oh.

Shay Nehmad:

It's a great example whenever someone says, programming is 0 based. I'm like, have you forgotten about Lua? Finally, there's there's Facto Cord which is very useful. Again, a useful project. Factorio bot for your Discord server built in Golang so you're usually playing around with friends and it probably does some sync and whatever.

Shay Nehmad:

You will never ever ever in a 1000000 years guess the 4th one. Try try to have a guess.

Jonathan Hall:

You have

Shay Nehmad:

a sense of how the the game looks and what it does. What sort of mod or automation or thing would you build if you

Jonathan Hall:

My Little Pony skins.

Shay Nehmad:

Alright. Good idea. Something that's related to the game. Sounds interesting. Think about something a bit more serious.

Shay Nehmad:

Something you would use in a business setting.

Jonathan Hall:

Is it is it a Jira ticket integration with Victoria?

Shay Nehmad:

It's very close. It's very close. Obviously, it's Efox Chainer's Terraform provider Oh

Jonathan Hall:

my god.

Shay Nehmad:

Factorio with a 164 stars. Infrastructure is code for your factory. Current status, on the Readme is stated as barely functional and mostly useless. I beg to differ. This is the piece of code that made me smile the most this week.

Shay Nehmad:

Thanks a lot for this, fun idea. And this is round up the Factorio news. On our server, we just reached Blue Science. Once we ship the rocket, you will be the first to know. That does it for the news segment.

Shay Nehmad:

News news and, shy nerding out about Factorio segment of the show. Stick around for a short ad break and then a super interesting interview with John Cricket. Alright, John. Do this ad break quick. I wanna get back to playing Victoria.

Jonathan Hall:

Alright. Thanks for listening to our show. Thanks for, supporting us as we talk about our gaming addictions. The show is sponsored by you. We wanna do a shout out to some of our patrons this week.

Jonathan Hall:

We don't have any new ones, but shout out to Luchenne Coffee Coffee, perhaps, and Frederic Averpel. Just a couple random, of our Patreon members. If you'd like to have your name mentioned in the show, head over to cupico.dev. There's a link there. Patreon, you can support us financially or you can join Patreon for free if you just wanna show your your moral support.

Jonathan Hall:

This is a hobby for us and it's an expensive hobby. We pay for professional editing, pay for hosting fees. So, your support just helps to make this cost us less money. We're not getting rich off this. We also love to have support in the form of chatting with us.

Jonathan Hall:

We are on the go for Slack channel. I'm sorry. We're on the go for Slack server on the channel cup ago, cup dash o dash go, kebab case. Join us there, talk about the latest show news, talk to the people we interview, talk about whatever you want to related to go on that channel. We have 462 people on the channel right now.

Jonathan Hall:

So it's, pretty active. Yeah. We have a lot of chat on there.

Shay Nehmad:

You're I don't wanna be a stickler for the rules, but it's a Slack workspace.

Jonathan Hall:

Workspace. Didn't they used to call it Slack servers?

Shay Nehmad:

No. They used to call them IRC servers back when you started No.

Jonathan Hall:

I think Slack called them servers too. Anyway, I think so. But I don't know. It doesn't matter. And finally, we would love to have your support in way, by way of a review on your favorite listening platform, whether it's Apple Podcasts or Spotify or wherever you listen to this show, leave a rating and review.

Jonathan Hall:

We'd love to have that support as well. So stick around for an interview with John Cricket about alternative lead code. Really, that's really kinda what we're talking about. So join us.

Shay Nehmad:

How to learn.

Jonathan Hall:

How to learn. Hey, Shay.

Shay Nehmad:

Hello.

Jonathan Hall:

I'm trying to get better at Go, so I'm leap coding. What do you think?

Shay Nehmad:

Oh, it would be fun to sit, as, like, a fly on the wall trying to see you tear your hair out because you don't have any left.

Jonathan Hall:

Yeah. I figured that the best way to get good at programming a language, a a new language, or or or to improve a language you know is to is to delete code, you know.

Shay Nehmad:

Yeah. You gotta grind it. Hashtag grindset, man. Yeah.

Jonathan Hall:

That's the only way. Right?

Shay Nehmad:

After, like, 20,000 codes, you should be okay. You don't have to do different ones. You can solve the same one.

Jonathan Hall:

The same one?

Shay Nehmad:

Yeah. All it's all counting towards your score. Right?

Jonathan Hall:

That's right. That's right. What do you think about that, John?

John Crickett:

I gotta disagree. I gotta disagree.

Jonathan Hall:

A hot take.

Shay Nehmad:

Alright. We're gonna have to, we're gonna have to disassemble this one. It worked. It leveled me up so fast in Runescape. Why can't it work in the real world?

Shay Nehmad:

Alright, John. Before

Jonathan Hall:

we talk about why you disagree with with me on using leetcode to get better at Go, tell us who you are.

John Crickett:

So I'm John Crockett. And I'm I disagree with you because I'm the author of Coding Challenges. Oh. And I push you a different way of learning a programming language. Interesting.

John Crickett:

Before we get to that though, to answer your question, I'm a software engineer. Been doing it for 28 years now. Done all sorts of things from railway signaling systems to the typical web apps like a lot of people. More recently, I've been dabbling in Go.

Jonathan Hall:

Did you say you did railways signaling systems?

John Crickett:

Absolutely.

Jonathan Hall:

So the trolley car problem was actually your life?

John Crickett:

Not quite. Not quite. The the signaling engineers decided that. We just built the software that enabled them to see where all their signals were on the controlling software. And interestingly enough, close the blast doors.

John Crickett:

Early James Bond. Oh.

Jonathan Hall:

Okay. Wow.

Shay Nehmad:

I I'm thinking more Indiana Jones. Like, the hat you have to slide beneath the the door just in time.

John Crickett:

Well, this this signaling system

Shay Nehmad:

When you say coding challenges, what do you mean? Is it like educational exercises that, one can do? Is it for hiring and assessment?

John Crickett:

So coding challenges is a newsletter I've been running for a little bit over 18 months now. It's called coding challenges because it's about coding and I went for the alliteration. If I'd thought a bit more carefully, I'd have called it programming projects. That's what I should have done. Because it's not about challenges.

John Crickett:

It's not about interviews. It's about real world projects that you can do to learn a programming language. That is exactly what I was doing. I wanted to demonstrate an idea around building MVPs and starting a business. Something I was posting on LinkedIn.

John Crickett:

And I thought, how can I start a newsletter and demonstrate the concept from that? And if if I get a 1,000 subscribers within a year, I'll have demonstrated how you can build an MVP and do something. So I'd been talking previously to a friend. I was learning this at the time, talking about how I learned a programming languages and I built leer world software, and that I've built the same software 7 or 8 times in different languages over the years, starting in the late nineties. And they said, well, why don't you share that in the newsletter?

John Crickett:

That would be it. So that's what I ended up doing. So it's a bunch of little world projects that you can build to learn a programming language or to get better at a particular technique that you wanna do.

Jonathan Hall:

So how is that different from leetcode? Because I mean, at the surface, leetcode, like, certainly it sounds like coding challenges, but you've explained it. It's not exactly what we're talking about. But but since that's how we started the conversation, let's let's talk about what the differences actually are.

John Crickett:

Sure. So leet code, you know, a typical one that everyone starts off with is to some. You know, you're gonna go for an delay and find that the 2 things add up to a certain number. And that's what Six, seven lines of code, depending on how verbose you are in your solution. It's one function, and it's an algorithmic test.

John Crickett:

So, you know, cool. But it's kind of like solving Sudoku or doing crossword puzzles for a programmer. Coding challenges, as I said, should have been called programming projects. It's about projects. So one of the early ones I had was building a compressive compression tool or decompression tool Mhmm.

John Crickett:

Using Huffman encoding. So this is something I first did in 1996. And as a student at uni, you know, you learn about Huffman Encoding. So I did that. And at that same time, I led Michael Blash's graphics programming black book, if I remember rightly, which had a lot of detail in it about how to optimize code.

John Crickett:

So and even though it's a book about graphics, it talks about caching, and it talks about hard drive caching. And at the time, you know, hard drives were spinning disks that were very slow. So I took this program in c doing, the Huffman encoding, and it took, I don't know, tens of seconds to encode a fairly large text file at the time. And I profiled that, and I looked into that, and I learned all about caching. I learned about different things.

John Crickett:

And I took my c plug, I mean, to the next level. My understanding of computer architecture to the next level with that. And that's then a a problem that I've solved again in other languages. I kind of we did it in Perl. I did it in Python over the years.

John Crickett:

So this has been my approach to learning different languages. And that's fairly, very different because you are building an entire program. You're dealing with a file system. You're dealing with some input output. You're doing some validation.

John Crickett:

You're actually building a full piece of working software. You you learn a lot from that process. You learn to do the bits that you want to avoid. Because in weak code, if you don't like a problem, just hit next, go and do the next one. You know, you can move on and try it, and you can kid yourself you're making progress because you've done 1,000 of them.

John Crickett:

Where if you actually build an entire program to the specification, and particularly when you match an existing one that you can test it against, you're forced to do those corner cases that you would otherwise avoid. You're forced to think, actually, no, file handling sucks in this language, but I've gotta deal with it. Or how do I handle a network connection? How do I do this, that, and the other? And you've you've got you're forced to think about things properly.

Shay Nehmad:

I think you describe, leaf code as a very, internal thing, And the like something that I do for myself and coding, projects or your coding challenges, which by the way, I'm just gonna front load. Coding challenges dot f y I slash challenges slash intro is where you can sign up to the newsletter. Just go there, coding challenges dot f y I. It's also in the show notes. You're describing, oh, coding challenges is a good way to learn and you're comparing, learning to learning.

Shay Nehmad:

But I think it's not really apples to apples. The main reason people do LeetCode is to get a job at a at a specific companies where they already know how to sort of game the the system. And looking at the list of your build your own x projects, some of the like, they're all really really cool and the problem is, now that you have a long list of them, I wanna do all of them. But I I could imagine some companies trying to interview with decode. And if you know that ahead of time, you can optimize for that.

Shay Nehmad:

And some companies like the way I interview, just giving you sort of a general programming task build an x. For my team specifically, it's a small h t p server that deals with Git locally. And for those like more quote unquote real exercises, hiring exercises, that would be more relevant. But you're focusing on

Jonathan Hall:

the learning. And in learning, I think doing challenges and and, just coding for real is a lot more relevant.

Shay Nehmad:

So I think they both have their place, is just what I'm saying. If you wanna get into, Microsoft, you're gonna have to grind some lead code.

John Crickett:

Yeah. Absolutely. If you wanna get into big tech, it's a way they interview. To filter their use, you're gonna have to do it, which is fine if you appreciate that's that's what it is. Where it upsets me when I see people doing it is where people say, well, I spent a year doing 2,000 leet code things.

John Crickett:

You'd have learned a lot more about software engineering and programming if you'd spent 4 or 5 weeks really grinding the leet code, and then the less of that year actually leading a good book on data structures and algorithms, and then going to build, you know, the Huffman encoder. Going to build a clone of sort, and doing the different sorts actually in a real world problem. Maybe even building a clone of w c, because that's gonna have you some interesting stuff. Or you build a parser or build an interpreter. So get the experience of both because great, you get into Microsoft as your example.

John Crickett:

You've done your leetcode. Day 1, you sat down in front of a computer. You're gonna be asked to start writing software. You're not gonna be asked to reproduce leetcode. So you need the skills not just to get the job, but to actually do the job and keep the job once you've got it.

John Crickett:

So, yeah, both have a place. Don't over index on EVA.

Jonathan Hall:

I I like the the way you said, or or I like what you said that LeetCode is a lot like crossword puzzles with Sudoku. I I love me some Sudoku, but I don't and and I will spend hours at that when I'm in the right situation. Right? I'll spend hours doing Sudoku. I like the really complicated ones where they have the the groups of of numbers that add up to certain sums rather than just straightforward.

Jonathan Hall:

Again, the straightforward ones are too simple. I like the hard ones, but I don't, like, have this illusion that doing that is gonna make me a mathematician or or or whatever you might say. I've said for for years that, Leak Code is to software development as crossword puzzles are to journalism. And I I think there's no no shame in doing crossword puzzles or enjoying them or getting good at them or spending hours. There's no shame at that.

Jonathan Hall:

But to think that that makes you a good writer or a good journalist or whatever, I think it's kinda silly. And I and I feel like it's similar with leetcode. There's no shame in doing leetcode if you enjoy it, but don't think that that's gonna make you a good software developer.

John Crickett:

Exactly. Absolutely. So, you know, that's my concern when people have done thousands and thousands of them dedicated a year or 2 of their life before they start applying for jobs. Then they don't have those real world skills to actually keep the job afterwards. The other aspect of it I don't like is when, you know, big tech has a different challenge.

John Crickett:

They get a 1,000 fairly good candidate supply and maybe 500 fairly irrelevant candidate supply to each role, but they've got a lot of people to go through. They need a filter, and lead cosign interviews work as that filter. I might not particularly like them personally, but they they do the job. What concerns me more is when you then get a startup or some enterprise company that's getting 10 CVs for each role. 1 or 2 that are appropriate, and then they're getting people may have maybe 20 years of relevant domain experience and relevant knowledge to do a DSA elite co style interview.

John Crickett:

It's not relevant for their domain. The interviewer doesn't know how to conduct their style interviews well. They've just seen Google or Facebook or whatever doesn't. So we'll do them. They give the interview, then they say, well, we can't find anyone.

John Crickett:

We can't hire anyone. There are no Go developers out there. Like, well, yes, they are. You've got people that have, you know, got years of domain experience. And I've seen this once or twice with a friend of mine who's a member of the c plus plus standards committee.

John Crickett:

And he's been, you know, he's been a member of that standards committee for 15 years. He's been the UK's primary expert at least once. But he'd gone away to a DSASA interview and been failed as not knowing enough c plus plus. That's kind of broken.

Jonathan Hall:

Indeed. Yeah. If if I can throw another hot take in there, I've I've often said that the big companies you said like Google, Amazon, you know, these big companies, they need a filter. I'm not convinced that LeetCode is even a good filter per se. It's it's just a filter that feels relevant more than, say, choosing people who are born in January, which would probably get them in trouble with HR and legal.

John Crickett:

It's a scalable filter though for them, isn't it? Yeah. It's it doesn't have to be good. It just has to scale because Yeah. As I say, if they've got a 1,000 applicants and there's a 100 qualified ones, they can afford to accidentally filter out 50 of those

Jonathan Hall:

qualified companies. Exactly.

John Crickett:

Yeah. Whereas when you've got 10 CVs, you can't because you'll filter out everyone.

Shay Nehmad:

And how's the, you said you've been doing this for 18 months on a weekly basis.

Jonathan Hall:

First of all, I commend your, dedication to doing

Shay Nehmad:

a weekly thing about, coding. God knows it's hard.

Jonathan Hall:

The only reason I I stick to it

Shay Nehmad:

is because I'm afraid to, leave Jonathan alone on the call. It's like, I don't know, 49% ashamed driven podcasting. This

John Crickett:

one. Right.

Shay Nehmad:

But the the other 51 are like learning, so that's okay. Where do you come up with the ideas for all these projects? Obviously, it's not the same project every week. Right?

John Crickett:

So like I said, some of them I've been doing for nearly 20 years. So some of them have been kicking out in my head for a while, and I've done at various stages. Others of them, people are now suggesting to me. So somebody leaked out the other day and suggest DHCP client and a DHCP server. So that's on my backlog now.

John Crickett:

It's something to think about. Some of the like NATs, for example, somebody suggested I went through the, c c n f, is it? List and I picked out some little open source projects there and I picked up that. Tomorrow's not tomorrow's. Saturday's coding challenge is to create Hugo.

John Crickett:

Again, somebody mentioned it. It's a website of Hugo. So I had a little play with that and thought, hey, this would be a cool tool to clone. It's an open source Go project, so it's you know, perfect. People can look at the little thing people can build on clone.

John Crickett:

So it's it's a mixture of

Jonathan Hall:

all those, and I've I read an absolute

John Crickett:

pile of books and newsletters and stuff. So I see different tools there. I really like a lot of the Unix command line tools because people don't realize how useful they are. One of the things that occurred in the first two weeks of learning coding challenges is most people these days don't know that they can type man in a terminal, followed by the tool or the library and learn about it. So I was educating a huge number of people that man exists and man files exists.

John Crickett:

So then there's a whole bunch of people that don't know that you can actually do an awful lot of data engineering with the simple command line tools in a Unix shell. So I've gone through a bunch of those partly to show people what they are, partly to show people the sheer power of them, that you can chain these tools together and pipe between them and do a lot of data munching. And partly because take WC, which was the first coding challenge, a lot of people look at and think it's very simple. Most people fail to actually build a correctly working software. So there's still a lot of useful lessons there.

Shay Nehmad:

Looking at let's just pick one example, which I just, pick out because the title is really funny. It's build your own head. It just takes a second to oh, your own head? Command. Alright.

Shay Nehmad:

Cool. This is gonna be less gruesome. And I think this is, true for all the challenges, I haven't read all of them, but they're divided up into steps. Right? What's the reason for, like, not just, giving me, hey, this is the command, replicate the command.

Shay Nehmad:

Why why, separate it into, like, smaller steps?

John Crickett:

So one of the things I've seen a lot of people struggle with over the years, as I've mentored developers at different levels, is a lot of people not had that experience of breaking a project down into stages. Figuring out how do I tackle this? You know, I maybe it's different in big tech. I've never worked in big tech, probably never will. But a lot of the engineers I've met across the small startups and enterprises, at least in the UK, have been relatively inexperienced.

John Crickett:

They haven't necessarily had a lot of exposure to system design and architecture. So I started off by lighting the challenges as how can I break this down for somebody just so they can have series of small wins and they can start to understand how somebody might think about breaking this project down and they might think about architecting it? Then I can introduce things like TDD. So if you look at the latest challenge, for example, the first step is to build a protocol handler. And I introduce people to using TDD, and I don't particularly push it, but I suggest that TDD would be a really good way of doing this because you can jump straight into how do we pass this protocol.

John Crickett:

You can start building the parser without having a working program.

Shay Nehmad:

Isn't, would you say that this makes the challenges more, like, approachable or is it just a way

Jonathan Hall:

to make sure that people don't follow through, like, don't fall off at the, like, a funnel in the middle? Because I I

Shay Nehmad:

guess, you say one of the things you saw that is people, they don't know how to break down a project so when they look at this, they learn by example, and then when when they come into work, they'll be like, oh, I remember in my, weekly coding challenge that it had like step 1 was a very small thing. An example of of the build your own head is take the file name and print the contents. Right? Okay. So when I get us a task at work to, I don't know, read all the DBs and and run vacuum on them, first step I will print out all the DB names.

Shay Nehmad:

Is that the sort of thinking you want people to apply?

John Crickett:

It's it's partly what I was going for. Yes. Partly as well I was figuring out as I went along. I I honestly didn't expect to get I thought success would be a 1,000 subscribers in the 1st year. I announced it on a Friday, and I had 1500 subscribers by Sunday evening.

Jonathan Hall:

Wow. Wow. So I

John Crickett:

was kind of taken aback by how much interest there was in this. I hadn't put a huge amount of thought into it other than I'd written the first four, when I announced it. And I thought, you know, this shows some interesting things that I think people will find useful.

Shay Nehmad:

Very, very cool. And with so many people, what's the feedback you've been getting? Like, that's I guess it's, hard to manage.

John Crickett:

It's pretty good. It's pretty good because a lot of people, have been kind enough to share it in social media. A lot of people have sent me emails and then said how much they enjoy it. There's a GitHub repo with shared solutions, and there's several 100 solutions that people have shared on there. And it's not been too bad for for, you know, volume of feedback, but it's been very, very nice to see how many people are getting something and enjoying it.

John Crickett:

And I've had a few people reach out and say that they did fulfill the challenges, and it gave them confidence and the skills to get their next job. Which is really nice to hear for something that, you know, I literally built as a let's try this out, and I'll figure something out from here. And it will be a learning curve for me.

Jonathan Hall:

How do you monetize this? You mentioned that I think it was before we started recording that this is kind of your I don't know if it's your full time job, but you're running this business anyway. How do you monetize this? I mean, a free mailing list with 69,000 subscribers is cool, but it doesn't pay the bills.

John Crickett:

Yeah. Like I said, I I didn't build it as a business initiative. I'm trying to build an audience of software engineers, which I started on LinkedIn, because I've been made redundant, and I intended to build a business. The idea was build an audience, and then I figured out from the audience what to build from them. And Coding Challenges was never intended to be a business.

John Crickett:

It was intended to be that audience, and it helped me discover it. But again, part of that discovery is people reach out saying, well, this is cool, but how do we solve these challenges? Can you give us lessons on how to do it? Can you provide coaching and mentoring? So, I left my full time job, in beginning of April this year, and my goal was to start building out some courses there.

John Crickett:

So I have a couple of courses that take you through 1 or 2 of the challenges. Just yesterday, I announced that I'm going to do a live one in December. Going to work with for you with anyone who's come along to it, and build the Lettuce clone, over a 1 week period. So now we'll take the structure of it's 5 days of 6 hour days, quite intensive. Quick talk, quick explanation and stuff.

John Crickett:

So introductions of to the less protocol, for example. Then we'll build a protocol parser, and everybody will do that in the line. And works for TDD, works for board programming, or mob programming. It depends how the people on the course want to do it. Mhmm.

John Crickett:

But it'll be a bit introduction, and then we'll aim in that week to build an equivalent to the original latest server. Cool. Got a couple of self paced courses. And the rest, I'm still figuring out, to be honest.

Shay Nehmad:

So you're planning to do a live session where everybody can join? So it's not a mentorship session. You're planning to go through, like, one of the challenges or something like that?

John Crickett:

Yeah. Absolutely. It's it's a live we could call it a mentorship. A short 1 week workshop, bit of coaching, bit of mentorship, bit of pair programming, and an introduction. And we explained some of the concepts.

John Crickett:

So introducing people to how to pass protocol, how to handle network programming, how to do TDD if if people on the course are interested at the time. So that's 1 week in December, and that will be a paid course. And I would say it's live 6 hours a day.

Jonathan Hall:

Now your courses that you offer, it looks like they're, offered in for both Python and Go. And you already did the Python one for Redis and now you're preparing to do the Go one. Right? But your mailing list is is programming language agnostic. Right?

Jonathan Hall:

You can do this in c sharp or in Pearl or JavaScript or whatever you want because they're just challenges. There's, you know, there's Yep. There's nothing language specific.

John Crickett:

Yeah. And they've been done in Scala, Go, Lust, Java, c, c plus plus, Dart. I probably missed a few, but people have done them in all kinds of different languages. Yeah. Python, definitely.

John Crickett:

And, again, the last couple of years, I've done quite a lot of Python. So I've built some stuff in Python. I had a lot of demand for Go. So I've been building a few of the courses in Go. Mhmm.

John Crickett:

Which is why I've been doing Go for the last 18 months. I started actually, sharing the projects I was using to enlist 18 or so months ago when I started to do it. Mhmm. Go on and Python have actually been some of the most asked for certain approaches. So, again, I've put my focus on that.

Jonathan Hall:

Were you did you know Go before coding challenges? Or or was that the the impetus for you to start learning and and playing with Go?

John Crickett:

So I started learning Go, I believe, in 2011, given what job I was in at the time. And I did a little bit briefly then. But again, the adoption really wasn't there at the time. I've looked at it a couple of times since, so I've done a little bit, but not very much. But then the impetus was a lot of people asking, can you demonstrate these in Go?

John Crickett:

So I had a little bit more of a look at Go. And I really like Go. It's it I mean, I started off as a c programmer. But then I got to the frustration of, like, why do I have to keep building a link list? And why do I have to keep doing this?

John Crickett:

Why haven't I just got a library with it in? So then I discovered c plus plus and the SDL, standard library, should be what we call it now. And I've moved to c plus plus And I was like, I I don't wanna have to implement a list again. I wanna be doing the business logic and the value. Mhmm.

John Crickett:

And again, that was my logical progression to Python. It's like I'm fed up with, like, make files and having to find the library and sort all these things out. And if I wanna go and do this machine learning that I'm doing and build a neural network, I can knock that out in no time in Python, and it's gonna be just as fast as under the hoods. Well, I don't wanna implement it from scratch in c plus plus. The value is in the the neural network, not the c plus plus.

John Crickett:

So again, I looked at Go, and it was like, hey. This this looks like nice and simple like c. All the good things I remember about c, but it's got a good library more like Python. I've got networking right there built in. It's clean.

John Crickett:

I can easily handle HTTP requests. I can I've got some maps and sizes and they're all built there. I don't need to reinvent the wheel.

Shay Nehmad:

This actually lines up pretty well with my,

Jonathan Hall:

sort of next conundrum with these challenges.

Shay Nehmad:

If you were to, pick one of these challenges, I'm looking specifically at build your own JQ because I love JQ. I use it all the time. You you could say that I don't know if that's true, but you might if you go the hardest way possible and you solve build your own JQ with turbo assembler or c, like, 2 languages that I used way back and and I remember, like, you have to actually know where each memory is going to and, you know, malloc free whatever. Like you said, when I build business software, I don't wanna mess with those things. I want them out of my way.

Shay Nehmad:

But looking at building your own JQ with Go's, like, super strong standard library, many of these steps are they're not trivialized, but they're pretty simple. Right? The first step of pretty printing, the standard library in Go and also the JSON module in Python, the it's just a flag of, like, indent equals 2 or or something like that. Is your intention, oh, now you know how to do this and go and that's good enough and you can move forward? Or is the thought behind it like, I want you to go through, like, the hard way and implement this yourself, and like iterate over lines etcetera etcetera?

John Crickett:

So I describe it as a choose your own adventure. You can solve it at whichever level you want. So you can implement some of the things like jq and wc, whatever, in 5, 6 lines of Python, for example, or 20 or so lines of Go. Or you can go to the next level down, and you can hand code things. And it's so it's all about this is a challenge.

John Crickett:

This is the problem that you've got. What is it you wanna learn? What do you wanna get from it? If you're learning Go, then doing it with the standard library is probably a great approach, because you'll learn all about the standard library. You'll find what's there.

John Crickett:

You'll find the limitations of it. If you want to learn how to build a parser, then go the next door down and build the parser from scratch and and do all that. So it's very much, choose your own adventure, pick the level, and pick the learning you want, and the projects are there for you to explore. Know, there's no quite a long way of doing them. The only thing that's long is if you don't learn something from it.

Jonathan Hall:

I like that. Yeah. And of course, if you're if you're building a JQ, let's say, for for work, not as a learning exercise, but because you need that functionality for some reason at work and off the shelf it will work. Then you're gonna have another set of challenges which will potentially include things like how much memory is it using and is it fast enough and how can I make it, you know, do everything in memory without touching the disk or how do I, you know, there's different things that come up? Do any of your challenges try to address these sorts of things like memory profiling, CPU profiling, I don't know, performance things.

Jonathan Hall:

And if so, how do you approach that? Because because like this high level, like, make your program pretty print JSON. There's a 1,000 ways you can do that. Some are efficient, some aren't. Do your challenges the the question is, do your challenges, start to approach this or is is that kind of left as an exercise for the reader?

John Crickett:

So remind me of that if I if I drift off, but I wanted to thank JQ. One of the reasons I picked JQ actually was not necessarily for technical side, but again, coming back to so many people not knowing about the power of the command line and command line tools. And I'd had a discussion before I did that challenge when somebody was handling JSON and going, well, how do I get through this? And I was trying to grep through JSON file. I was like, why on earth are you trying to grep through JSON and find the bit you want?

John Crickett:

Why don't you just use JQ? And what

Jonathan Hall:

was that?

John Crickett:

So I showed them and I, oh, my God, this is amazing. Why haven't I known about this? It's like, well, so it's just try again, trying to make people aware of all these command line tools that can be very, very useful and help them do their job and be more effective at it. Coming back to then your question about the performance stuff. I encourage people in the Huffman compression one to go and watch Scott Myers video and to understand some of the things about low level caching.

John Crickett:

Some of the issues around that. In the latest challenge, we make use of latest benchmark, which is all that comes with latest that allows you to benchmark the server and the performance. And I encourage people to look at the performance of their server and compare it to latest itself. Again, we're kind of cheating because we've only implemented the original functionality of Lettuce plus a few more bits. There's lots more that the full Lettuce server does and maybe it'll match that.

John Crickett:

But for example, in Python, on my MacBook Pro, my implementation is not that far off letters itself, given that it's in Python. Mhmm. And a Lust implementation is obviously gonna be a lot more efficient and get a lot closer to it. I, in the past, have done some work, in market data feed handlers, some financial markets. And there's a lot of emphasis out on being very efficient, very low latency.

John Crickett:

So I'm slowly working on trying to figure out a way of building a challenge around that. So giving people a mock market data feed, and to process that and introduce that as a good way of understanding the latency, understanding scale from a different aspect, because everyone talks about scale these days and goes, well, how do I scale to a 1000000 users? Well, not everybody has that. You know, again, you build a market data feed handler. There's 1 feed.

John Crickett:

You know? You you got a feed with the Linux stock exchange. You don't get a 1,000,000 feeds from Linux because there's one feed. But it's a fire hose of data, and you're getting it as fast as your network bandwidth gonna allow it to, obviously, the player of trades are happening. It's a completely different challenge to handle that data coming.

John Crickett:

Process it and feed it at the back to whatever your back end system is. Maybe it's a unified feed or maybe it's into a trading engine as fast as possible. Particularly when you're trying to do that in, you know, sub millisecond times. So I'm working on a kind of inspired by the billion low challenge that happened last January. Or, trying to think of a good way of creating a similar challenge that can scale and work for people to do that.

Shay Nehmad:

One thing I've found is at every one of your challenges, you're like, set up your own environment. You're gonna need x and y. And a lot of these interactive educational programming challenges websites, I'm I'm my background

Jonathan Hall:

is from this, like, cyber security. So I've done

Shay Nehmad:

a lot of CDFs. What you what you'll have is, like, infrastructure already set up for you. You're just, like, SSH ing into it or logging into the VM and you, work for that. Obviously, that gives you, as John, a lot of control over the environment where developers are working. Right?

Shay Nehmad:

And you could say, I think you should be working in the terminal with vi and that's how you should solve my challenges. But sounds like you're, again, giving a lot of trust or freedom to your, readers of the the followers of the newsletter. Just solve it on your own. What do you think about that? Well, like, do you see a coding challenge where you set up a server that has some wanky stuff or the some something weird, something janky and you need to work against that?

Shay Nehmad:

Something in that, sort of style?

John Crickett:

So I have been asked a lot of time to set something up that people can validate their solutions against. And that was actually one of the first projects I started building in Go, last year, and I'm slowly working on. But I made it quite hard then to actually automatically test a lot of these solutions, because some are command line tools. That's fine. Some are front end tools.

John Crickett:

And so thinking about a scalable way of of testing all these challenges, is quite a challenge. And, again, I don't want to have to run a bunch of servers to that because then I have to start thinking about security. Then I have to start thinking about other things. If I'm going to learn arbitrary code on it, I don't want that overhead of the complexity of having to worry about that and learn public facing servers that yeah. Like I say, learning arbitrary code.

John Crickett:

But I have been thinking about how I can build and distribute a tool that people can run automatic tests against their code because what people like. But the whole point of this was to share projects that people could do. The the steps and the tests that are outlined in those projects are all about, here's a very basic test you could do. The responsibility is on you. It's your learning.

John Crickett:

You know, if if you wanna cheat yourself out of the learning and not follow things through, you're only cheating yourself. If you want to really maximize your learning, you can go as deep down the rabbit hole as you want, whichever bit that fascinates you or you need to know. So, yes, I'm I'm trusting people to be honest with themselves about what they want to learn and to do as much as they need to to learn that and get the benefit out of it. And if they're not learning something from it, move on. Do something else.

John Crickett:

And a bit of leet code if that's what you guys need to learn.

Jonathan Hall:

I know related. I'm sorry. I I was muted for a while. There's a lot of noise here, so I apologize. But, on a related note, I'm curious.

Jonathan Hall:

So you started doing this about 18 months ago. That's about the the same time that the AI hype really started. Maybe you don't have visibility into this, but I'm curious how you've seen AI and generated AI copilot chat gpt play into these challenges? Because I could see somebody who's trying to feed this to CheckTpT, and somebody got an answer. You're not gonna learn a lot that way though.

Jonathan Hall:

I'm curious if you've seen any what what you've seen with regard to to AI as it intersects with what you're doing?

John Crickett:

So I haven't seen any answers that to me are obviously AI generated. I have tried a few times putting some of them into AI and seeing generally the answers that come back don't quite work. You still need to you still need to know enough software engineering to better spot what's on with it and fix it, or just to get through the compiler alone. So the the ones that I've tried, I guess if you didn't have a clue how to start in a particular language, they'd give you something that you can iterate on. But they haven't really cut down the work or what you need to do.

John Crickett:

You're still gonna do about as much work. It's just slightly different work than generating. What was quite nice is Mike Thornton went through about a year ago and used AI to generate tests for some of them. And you got a quite long series of web based going through this experience. Again, I think that probably took us long.

John Crickett:

I mean, he did sum it up, but it's it's a while back now. I've forgotten. I think that that took about as long as if he'd done it by hand. But it was an interesting example of how you can use AI to generate some of the test cases and how you can iterate on that. And that looked quite good.

John Crickett:

That looked quite useful if if maybe if you develop it doesn't particularly like lighting test, which a lot of people don't. Or maybe if you've got some system that you didn't particularly like, you don't know how to approach testing it, that could be a good way of of doing it. So I think that was quite interesting, and it would be interesting to see on the newer models of AI how it coped with that as well.

Shay Nehmad:

One thing I I take from this is I a lot of people are have tried to just get into software and be, like, oh, I'll just put it into Jejupti and and, like, move on. I I really hope that people don't cheat themselves out of the the fun of, like, working a problem out. Not because it won't work. Eventually, it will work, but because that's sort of the point. That's sort of the point.

Shay Nehmad:

That's the sort of the point of, not just the exercise, sort of the profession. The profession might be changing, and we might, like, be slow to realize. But I don't think it's that fast. I agree with you. You still need to do software engineering.

Shay Nehmad:

It's just you have a very, very, very junior, very, very, very confident engineer who's spinning out code for you instead of you typing it up.

John Crickett:

I think it's, at the moment, optimistic to assume that they are, at least in the form of LLMs, will take our jobs. Because they're only gonna reproduce stuff that's in the training set. So, yes, if you want to do a simple CRUD app and you want to insert some stuff into a database and whatever. Or some of the example code that, you know, has been done a lot of time in tutorials, so they can churn that out because it's well existing in the training set. You want to do something that has never been done before that is genuinely in as innovative, or you have to solve some different problems again, I don't think it's gonna work that well.

John Crickett:

You know? I am some of my specialty, but I have done some work in AI in the past. And, again, when you go into stuff that's well outside the training set, it generally doesn't work that well. But even even if the LLM could generate all of our code, the hard part of software engineering for me has always been speaking to the user, getting them to actually clearly articulate what on earth they want it to do, and then translating that into a document that you can then implement, that you can then get them to agree to. Now wherever that document is, you're a fan of TDD and you light it as test, and you you document the test, Whether it's a traditional requirements document or whatever, that's been the hard bit.

John Crickett:

And I think that will still exist. And whether you then translate that into code, in Go or C or C plus plus or whatever, or you turn it into prompts for AI, that hard part is still gonna exist.

Shay Nehmad:

I know that, Jonathan is, very much not a fan of TDD because I see him arguing about it all the time on LinkedIn. So I assume he hates it, but I never read his takes. So so I don't actually know.

John Crickett:

Well, now I'm curious.

Jonathan Hall:

No. I'm a I'm a I'm a vocabulary for TDD. He's just being sarcastic.

Shay Nehmad:

He's probably done more for the sales of, the TDD book than the publisher has ever done. Even if it's just people buying the book to burn it. Cool. So something very, attractive about these coding challenges, it is the fact that they are scoped. Right?

Shay Nehmad:

It's not build multi tiered enterprise application with authentication authorization blah blah blah blah. It's small, bytes. Some of them seem more difficult than others. Like head seems very very simple and, I don't know. I think there's build your own git, that sounds a little bit more complicated.

Shay Nehmad:

Build your own password cracker. Like, they have very, like, varying difficulty. How long should I let's say I I get a random email well, not a random email, like your weekly email, and I wanna put time on my calendar to solve, one of these challenge.

Jonathan Hall:

How long should I how much time should I allot?

John Crickett:

So my original goal was to make them generally fit in 8 hours of focused work. That's kind of expanded. For some people, Lettuce will be more like a week to 2. I know some people spend a month doing that depending on what level that. NATS is probably again the same sort of level.

John Crickett:

Depending on what you know, Git might take people that long. So I've now tried to value them because I have I mean, I literally thought they'd be kind of mid to senior level engineers that would really focus on this. But I've ended up with an audience of people who are new to software, you know, straight out of the uni, out of boot camp, all the way up to CTOs who are saying, actually, I'm having a lot of fun doing these to legal and programming because I haven't been hands on. So now I'm trying to value them. So they've some of them might you say head.

John Crickett:

Now you can probably knock that out if you're experienced engineering. 30 to 60 minutes to, you know, could take you a bit longer. And again, it's it's gonna vary. And literally, I'm trying to hit a broad audience now. I'm trying to provide that.

John Crickett:

You know, there's so much there. There should be enough that, again, you can pick your own adventure. If you want to clearly nerd out on networking, you can build go and build a DNS resolver. You can go and build traceroute. You can build NATS or memcached or Lettuce and, you know, go really into network stuff.

John Crickett:

You wanna build units command line tools, most of them are now there. If you wanna get through that internal to Git, go ahead with that. You wanna do some front end stuff, there's a bunch of games there that I've put in, and there's the, carousel generator for LinkedIn and so on. So let's say, choose your own adventure.

Shay Nehmad:

Cool. You can really nerd snipe the CDOs if you, do build your own Jira client.

Jonathan Hall:

There's a build your own Notion in there, I saw.

Shay Nehmad:

Very cool. There's one question. It is rather, self aggrandizing, and you've been very very humble so far. So so try to be a bit more arrogant.

Jonathan Hall:

What do

Shay Nehmad:

you think the impact of coding challenges has been? When I look at things like coding challenges, not coding general like, in general, the concept. Like coding challenges, FYI, the website. How many people have gotten jobs or have gotten promotions or learned that they like programming or figure out early enough that they don't like programming? Because if this was a side project that, you know, 10 people did, I would be like, ah, cool.

Shay Nehmad:

This is this is nice. But you you have thousands of subscribers, So there's there's a real impact there.

John Crickett:

Yeah. There's just under 70,000 subscribers on Substack. There's 120 something on LinkedIn on the newsletter. I literally started the newsletter on LinkedIn as well. And then there's also a bunch of people that follow me on LinkedIn because of coding challenges, and other stuff that I pontificate about.

John Crickett:

So there's probably around about 200,000 people get it in one form or another each weekend. And I say, yeah. You're like, some people have reached out and said it's helped them to get a job. Some people have reached out and said it's helped them understand stuff to the next level. Some people have said it's helping them move forward.

John Crickett:

A bunch of them have reached out and asked me for mentoring or for to develop some of the courses, which is what I'm now starting to do. And it's led to a whole bunch of interesting opportunities for me. I've been invited on podcasts. I've been invited to write books from it. I've been offered some consulting work.

John Crickett:

I've been given lots of chances to collaborate and meet interesting people. So it's it's been far bigger than I ever expected. Like I say, I expected a 1,000 people by the end of 2023.

Shay Nehmad:

I think, this sort of educational programming thing has really outsized the impact. You have a lot of experience in this field and instead of just taking it with you, you're you're sort of making sure that it, everybody gets that. And I think that's really positive impact for for the field or, like, the field of, program. I think it's really cool.

John Crickett:

Yeah. Thank you. And I wanna share some of my enthusiasm that, you know, it can be fun to actually like. I mean, yeah. It can be fun to do Leetcode and Crosswords and Sudoku, if that's your thing.

John Crickett:

Can also be fun to actually like full software programs that do something. Yeah. Scratch your own itch in one way or whatever.

Shay Nehmad:

Yeah. I definitely need that reminder sometimes.

Jonathan Hall:

Well, John, we've been talking a while. Sounds like we're starting to wind down here. Beef before we ask our final question, how can people get in touch with you? Obviously, coding challenges at FYI, you mentioned LinkedIn. Are you available on other social media or other places that you like to to get in contact with folks?

John Crickett:

Yeah. I'm on Twitter, x, whatever we call it nowadays, and on Blue Sky more recently.

Shay Nehmad:

Okay.

John Crickett:

And YouTube. And I'm easy enough to find John Crooked. It's a fairly unique name.

Jonathan Hall:

We'll have links to all that in the show notes. We'd like to round out our interview. We've already talked a little bit about this, but I think we can make it a little sharper, the answer will sharper. So, you talked about how you started Go. When you started learning Go, you'd already done c and c plus plus and Python.

Jonathan Hall:

You've talked about in the past. What did you find to be the biggest surprise or or maybe challenge? It could be a positive surprise or negative surprise when you started learning Go.

John Crickett:

Biggest surprise. I think the biggest surprise for me was actually the testing support. You know, one of the first resources I came across was learn go with tests. And I see immediately testing built into the language. And as somebody that loves pytest and the parameterization of pytest, to then see that there's a big movement around table driven tests in go, and I can drop in and immediately start lighting my primal sized tests or table driven, as you call them in Go.

John Crickett:

And I can do that, and I can just, like, go test and go, brilliant. And I also love the fact that I can just do go run, and I don't have to think about building my code, doing an executable, whatever. I can just crack on and do it, but I can still build it if I want to.

Shay Nehmad:

Cool.

Jonathan Hall:

Yeah. Good answer.

Shay Nehmad:

Go run is gonna become faster. We talked about this, last week because of, cache, like, there's some extra build caching there that's gonna be even faster. So if you liked it, you're gonna like it even more.

Jonathan Hall:

Awesome. Well, hey, John. Thanks so much for coming on. It's been fun. I guess I I'll I'll stop leak coding now and, start doing something else.

Jonathan Hall:

Well, with all that time all that time open, you can,

Shay Nehmad:

harass people on LinkedIn even more Yes. Which I personally love to see.

John Crickett:

It's been

Jonathan Hall:

a pleasure, John. Thanks for joining us on the show, and good luck to you and all of the people doing your coding challenges.

Shay Nehmad:

Thanks a lot.

Jonathan Hall:

Likewise, it's been a pleasure. Thanks for having

Shay Nehmad:

me on. Cheers.