Programming Throwdown - 150: Code Reviews with On Freund

Episode Date: January 24, 2023

Patrick and I are always stressing the importance of code reviews and collaboration when developing.  On Freund, co-founder & CEO at Wilco, is super familiar with how code review processes can go well, or become a hinderance. In today’s episode with us, he shares his unique perspective on code reviews and maintaining high code quality!00:00:56 Introductions00:01:38 On’s first exposure to tech00:06:04 Game development adventures00:11:12 The difference between university and real-world experiences00:17:43 A context switch question00:24:41 Points of frustration00:30:53 Build versus Buy complications00:32:06 Code reviews00:39:58 Quality of code00:45:12 Using callouts for the right reasons00:49:57 Code reviews can be too late sometimes00:52:11 Using social interaction as pre-review orientation00:57:03 How not to use code reviews01:01:35 Where Wilco helps programmers learn01:09:11 Working in Wilco01:11:49 FarewellsResources mentioned in this episode:Links:On Freund:Linkedin: https://www.linkedin.com/in/onfreundWilco:Website: https://www.trywilco.com/Twitter: https://twitter.com/trywilcoLinkedin: https://www.linkedin.com/company/trywilco References:Micro-Adventure:https://en.wikipedia.org/wiki/Micro_Adventure If you’ve enjoyed this episode, you can listen to more on Programming Throwdown’s website: https://www.programmingthrowdown.com/ Reach out to us via email: [e-mail] You can also follow Programming Throwdown on Facebook | Apple Podcasts | Spotify | Player.FM Join the discussion on our DiscordHelp support Programming Throwdown through our Patreon ★ Support this podcast on Patreon ★

programming throwdown episode 150 code reviews with on freund take it away patrick well we have a divisible by 10 episode, 150, so that's got to be a positive sign. We made it another... It's not an anniversary? I don't know if you call it another... Decaversary? Jubilee? Oh, that's true. Okay, too soon. Anyways,

so we're here to talk about code reviews, which is an awesome topic. Even in the pre-show, I was getting a little excited just hearing some of the thoughts from our guests today. So I'd rather than tee it up and just make everyone really excited you're already here. So we'll just go ahead and go into it. I don't need to pitch an episode coming out next week. It's here. It's now. We're here with An Freund, who is the co-founder and CEO of Wilco. Welcome to the show, An. Thank you so much. Great to be on board.

So before we get into the topic, although I'm pretty geared up, I'm not going to lie. I talk a lot about code reviews. So before we get there, let's talk a little bit about you. So we try to ask a lot of our guests. I think it's really interesting. Maybe it's just a very vanity project of mine to sort of like, that's not the right word. Anyways, to just understand a lot about other people and how they sort of developed and got into their current roles. But tell me a little bit about, like, do you remember your first exposure to tech? Like the first time you wrote a program

or the first time you got a computer, like just that memorable sort of early thing that happened? Yeah, it's a great question. If that's your vanity project, you're on the right track. So I think I was around eight years old. I wrote my first computer program in BASIC. And back then in Israel, there was like a famous series of booklets about how to write BASIC. It was called Makhshevet. Everyone who wanted to do anything with a computer in Israel had it. And it was like a series of, I don't know, 15 of them or so. You know, the first one was

obviously the Hello World program, but then very quickly it progressed. And I actually loved writing games from day one, you know, whether they're text-based or at some point, you know, with actual graphics. But that was always something that, you know, drew me even more than playing games. I think writing games was something that I found really cool awesome i think eight is a bit on the earlier side than a lot of guys earlier than my in mind but this is interesting so there's a booklet was the booklet like a sort of workbook or just like a sort of copy and paste examples i mean both are kind of interesting but what was kind of like the content so a So a lot of it was copy and paste and like the literal sense that, you know, you look at the thing and then you type it. But a lot of it was like fill in the blanks.

And some of it, you know, towards the end of every booklet, you'd usually get something that's a bit more adventurous. And you have to start from scratch and build something meaningful. That's awesome. That's not uncommon, actually, this, I guess today you would literally like go to the website and just highlight it and, you know, command C or control C, command V, control V. But like, I think this thing you said, it was true for me as well, like looking in an actual physical book and having to, without errors, type in something and see the magic and debug it. And the booklet thing, I don't know of any, you know, in the United States, any sort of booklet for computer science, but there's a famous one for electronics, which is Forrest Mims. That's even, even pretty,

I don't even, I want to say, I was going to guess the decade, but I'll be wrong. So I'll have to look it up later. But in RadioShack, which was like a small chain of electronics hobbyist stores for early computers, they would have these little booklets of circuits. So timers using the 555 integrated circuit or whatever. And it's kind of like what you were saying. People would sort of look at them and you could put them on your breadboard and poke in the little things. Oh, I loved doing of those, you know, electronic kits where you build your own alarm system or radio or whatever. AM radio. Yeah, that was that was cool.

I love those. Yeah. In Canada, we had I don't know if we had this in the US, too. We had these books where it was like you'd basically read through this story. And at some point, the story would pause and in the book there would be all this basic code that you would have to type into your computer and the basic code would include like some interactivity so it would ask you like you know like type in like this number and then do this with it and try and solve this little puzzle and then once you got the answer

you could flip to the next page and then when you got to the next page they just assumed you got it right it's like you're right it's 21 and half the time i was like oh it's 21 but i got you know syntax error 13 well all right let's keep going and so it's but it's really fun that that's awesome i i love those things if you ever manage to pick up on the name of that of those uh books i'd love to get my hands on let me see if i could do some digging it would be some greatness saja so that's great i thought you were going to tell us like a super clever choose your own adventure like if you put your answer go to that page number and then there'd be like a little debug

thing like oh you got 17 you messed up order of operations you know you're off by one this page was intentionally left blank oh yeah okay all right so so you're eight you're you're you know copying stuff from these books and learning basic i mean it's awesome um did you kind of fall out of it for a while or did you just kind of continually do some amount of programming through to college? What was your sort of path there? So I did some amount of programming throughout school. In high school, we actually had this thing where in Israel, you have to volunteer for something during high school in at least one of the years. And there are specific things that you can do. And a friend of mine volunteered for like this, this sort of nonprofit that is working on road safety.

And he was supposed to build a game, like a board game for kids, where that, you know, that teaches road safety. And he reached out to me and said you know what if i build a video game so in addition to my volunteer work i actually ended up uh working on his too and we worked together he was really good with graphics i was good with um with writing code and we built this cool game it had like several levels and the first one was like a walkway. And every time you got the answer right, you would advance to the next block of it. We're not going to talk about what happens if you got it wrong. And the second level was you're like roller skating and you get to street signs and you have to make out which one it is. I don't remember the third level. We actually got together like a few months ago and talked about it.

But then after that, it was really cool. We decided, all right, let's build another game. And this one was like a fighting game, like Mortal Kombat style, which was really hot in those days. And we filmed one of our friends against a white sheet. And he kind of went pixel by pixel to get just, you know, just the guy. And we filmed him like, you know, giving out punches and kicks and all of that, and jumping in the air. And we got to a point where we have our friend against like a, like a sketchy bar backdrop.

And you can make him jump, you can make him kick, you can make him throw a punch. And it was really cool. We never got to the stage where there is another player. So you could just move this guy around and that's it. But it was fun. Yeah, that sounds awesome. Just for posterity's sake the series is called micro adventure and

it was actually an american thing it was published by scholastic but if folks want to look that up you read these micro adventure books and they have to solve little basic programs along the way but similar to you on i also made a bunch of video games the most infamous one was it was arm wrestling where you had to hit the space bar so many times per second to to you know for so many seconds to arm wrestle victory and the computer lab they broke three keyboards and then that game got banned but i wonder what the equivalent is for nowadays for kids who are you know that the age that we were back then like what is this thing they're tinkering with now but i'm not sure that they create videos

on tiktok yeah that's probably but is that is that to the same level of like uh i guess it is kind of a technical thing like it can lead to more technical stuff later yeah and it all depends on you know how far they take it. Right. They can, some of them get really professional and, and, you know, throw in some really cool things, but it's not completely programmable. Maybe I'm blanking on the name, the, the block thing, Minecraft and Minecraft. Exactly. Yeah. Yeah. So maybe Minecraft and Roblox are the the closest equivalent these days yeah

makes sense so if you're fighting game on i'm not sure if you were aware at the time or even now but that description of how you did i mean that early motion capture video whatever is how the original mortal combat you know there was some video a few years ago that i think came out where they were showing yeah the person like doing the scenes of that ended up in the in the video game so i don't know did you guys know that or did you like independently just like have this idea well we we assumed i i only caught that video like three months ago i think and and we're talking about more than 20 years back but sure uh we we did assume you know mortal kombat looks like these characters were videoed so we assumed uh that's what was happening and we did know about the green screen technique but we didn't have anything green

so we just you know went with white we had to dress him up in very dark uh uniform to make sure that he stands out against the the white background no but that problem solving right i mean like interdiscipline problems. I mean, that's actually like really awesome. And I can totally see like how you end up in a career in tech if that's the kind of things, even if you don't know that's where you're going, if that's the kind of things you're doing,

like it just feels like a natural follow on in my opinion. Yeah, I agree. Okay, so you're in high school helping volunteer stuff, doing this. And then did you end up studying computer science or related field in university? Yeah, I did. I went to Tel Aviv University. I studied computer science, which in retrospect has nothing to do with programming.

It's computer science. These are very different topics. I enjoyed every minute of it. Don't get me wrong. I think computer science is a fascinating topic. And at some point, I was contemplating continuing a more academic path and, you know, actually doing computer science as a career. But, you know, when I got my first real job, I realized that actually nothing that I've learned in college has any bearing towards what I do at work. I think this thing you're saying might be is definitely true.

But it might be a sort of revelation to some people that like going and getting a computer science degree doesn't make you a programmer out the other side. Do you want to elaborate? I mean, I'm happy to elaborate too. But I'll give you the opportunity since you're the guest. Do you want to elaborate like why one isn't equivalent? Sure. So first of all, you know, I'll start by saying that I do recommend people get a computer science degree because I think, like I said, it's awesome. It's interesting. It's a fascinating topic. There are a lot of subtopics within it that you could explore up in college in your job, but it's usually, you know, few and far between. But most of what you learn in school is very theoretical. It actually has nothing to do with computers. Computer science is eventually a branch of math. And large chunks of it deals with hypothetical computers with tapes and operations.

So what you learn doesn't necessarily prepare you for the job. And I guess even more importantly, the few things that you do learn that are meaningful are all about code. And the work of a software engineer is way more than code. There are so many skills that go into what you do on a daily basis. Whether it's soft skills, whether it's hard skills, there's just so many of them. And you don't touch any of them in college. Yeah, I agree. I think there's maybe an obvious, but this tension between, as you sort of saying, sort of the mathematical or I don't want to say philosophical, but almost that bent of sort of the mathematical or I don't say philosophical, but almost that bent of sort of how to think about programs as a conceptual sort of underpinning and actually coding or programming. And depending on your university, there may be a balance between them or even different degrees

or specialties within the degree that have you doing more of one or more of the other. But I think like you're mentioning, you could take an image processing course and learn all about like theoretical, like binary thresholding of images and never open up OpenCV. And if you go do image processing, like on your own, you're like immediately going to go into a library and sort of be doing image processing tasks. And some universities have tried to adapt to match the expectations, but some have said, wait, that's not our business. Like our business is the business of teaching sort of like you're saying Turing machines

or the theoretical differences of a von Neumann architecture versus something else, or talking about compiler languages as like abstract syntax tree manipulation, not sort of the brass tacks of optimization. And so really kind of, I think that's part when you choose a university, that's like a decision you're making when you're choosing what focus you're going to have. But what I, having now being in the role where I interview people coming out of university for working on

teams that I'm on and learning is a a couple things that one, not everyone, even at the end, is realizing that they aren't coming out automatically as a programmer. It's not just telling me their curriculum or telling me, even if they did programming as class projects, that's not going to sell me enough on them. That doesn't teach me that they're going to hit the ground running or help me feel confident they're going to hit the ground running. And most of them don't realize, although I have had some candidates kind of self-aware say it that, you know, hey, there's a big difference in university. I was, it's all throwaway. There's like a scaffolding and I do a little fill in the blank. We were kind of talking about that. And then it goes away. Maintenance isn't a concern, even though

we might talk about it, but there's no practice of maintenance. You work on a quote unquote team, but the dynamics, the economics of it, everything is just different. And so maybe it hints at what it would be like. But some people have internships, have that realization. Some have internships, don't quite, but it's just this interesting sort of mix of people and how prepared they come out. And often it's because of work that they took on on their own or on the side and not the curriculum. Exactly. And you know, you come into the first day on the job and you're in the office and, you know, the person welcoming you is probably going to say, hey, why don't you familiarize yourself with the rest of the team? And guess what? You've never learned anything about teamwork. You know, maybe there was like a project that you had to do in a group of four

where, you know, two of them were too high to participate and the other person was, you know, banking on you to complete the entire project. So you never really learned how to work in a team. And then maybe go familiarize yourself with a build system and you're like, wait, what is a build system? I've've never done that and this is the way our cicd pipeline works and like wait what and oh by the way we're using git and like what's git you know i've been doing everything on svn and cvs oh awesome okay all right well maybe we keep going because we can't stop here we can't pull

over the train here and uh taking the train stop so we'll go keep going because we can't stop here. We can't pull over the train here and take the train stop. So we'll go keep going. All right. So, so you're studying in university, computer science. Did you, did you kind of like do internships or did you just kind of focus heads down and get through and then, and then enter the workforce? How did that come? And you said you were considering academia. Yeah. So I was, I was actually very, very fortunate. So second year, third semester of school, there's like a career fair.

And it was actually meant mostly for electrical engineering majors. And it was meant for like, you know, seniors. But last minute, I say like, what the heck, let me go there and see what's happening so I go and and I'm late because you know I wasn't intending on going so I'm late the guys are like folding up the booth of a company called Applied Materials and I'm like oh I'm too late and the the guy that was doing the interview is like you know say let me ask you a couple of questions. Let's see if, you know, if it makes sense. And all of the questions he asked me were about operating systems. And I just happened to come out of operating system class, like that day. And all of the questions he asked me were fresh in my brain. So he's like, what is, you know, what's, what's a context switch?

And which, by the way, developers today probably don't even know what it is, but because they're lucky enough to be in higher level languages, but what's the context switch? And I look at, look at him and I'm like, are you kidding me? Because it's so fresh in my brain that I think that it's common knowledge. Are you kidding me? And he's like, no, what is it? And so I give a perfect answer, you know, and he's like no what is it and so i give a perfect answer uh you know and he's like so he writes down and i know this because he told me afterwards he writes down

very cocky but knows his knows his stuff um from the sound of it yeah in retrospect this was he got it completely right we're actually very good friends now till this day. And this was, you know, almost 20 years ago. So he writes this down in his notebook. And then a few days later, I get a call. And they're like, why don't you come over for an interview and interview and I managed to get the job and I start working, you know, this was like, you know, in the break, the winter break between the third and fourth semester, I start working. So I never really had an internship per se. But I was working throughout the second half of my degree. Oh, awesome. So you were like working part time while doing school? Yeah. Oh, nice, nice. Oh, and what and so that company, they were pretty low level if they're

asking about operating system and context switching? Yeah. So Applied Materials is in the semiconductor industry. And what they do is they make machines that either build or test or do anything in the manufacture of chips. So specifically, the team that I was working on was building this machine that could do two things. It was like an attempt to take two machines and turn them into one. So there was one machine that is measuring, say the distance between two conductors to make sure that the board was printed right. And, you know, we're talking those distances, obviously it's, it's microns, right?

Sure, sure, sure. So there was like this crazy electron microscope and, and all of that. And the other machine was classifying defects. So you know that there is a defect in the wafer that so you know what happened wrong during the manufacturing process and we were building a machine that is trying to do both so there was a lot of image processing there was a lot of controlling the machinery you know you had like basically a robot that is taking one wafer while taking the other wafer out because you didn't want to waste time this is like the manufacturing floor. Everything needs to be super efficient. So you had, you know, these arms that

are bringing in one wafer, taking the other one out. And there's like a chamber in between where they, you know, it's like, it's like those spaceships where you need like a double latch. Oh yeah. It's gotta be vacuumed down. Yeah. Yeah. Because everything is like super clean. You can't have any, you know, any particles of dust in there. So it was it was pretty wild and pretty low level. It was fun. But I vowed not to do low level since and I like many promises I made in my life didn't actually live up to it. Okay, so you and I can't be friends, but okay. So we won't get sidetracked there either. So you're doing this, you're finishing up your degree. And then it sounds like maybe you decided not to go there when you graduated,

or kind of take us through what happened next. So when I was close to graduation, I decided that Applied Materials is no longer for me. Applied Materials is a Fortune 500 company. It's huge. It's American. I wanted to join an Israeli startup. I'm based in Israel. I want to be where decisions are being taken, et cetera. And I joined a small startup. It was about 20 people. It was in the cybersecurity space. And I joined the server team because I didn't want to do low level anymore. So I'm on the server team. I didn't want to do low level anymore, right? So I'm on the server team, I'm writing.NET code, and no need to manage memory, all of that. And what we were doing is this product that lets CISOs control what's happening in the organization in terms of external devices and content. So you can't copy those files over to a USB, you can't send that type

of content over email, et cetera, et cetera. And what do you know, within a year, I find myself in the agent team writing Windows kernel drivers. Sounds like you didn't last long in your avoidance, so you must have some skill there, I guess. I hated it. You know, when you write Windows kernel drivers, you know, today it's somewhat easier because a lot of it could be done with virtual machines. But because we were dealing so much with hardware, you know, many of the things we did

actually meant that we had to have another computer to test what we're building on. And, you know, your actual computer and the other computer are connected through a serial cable, because that's the only way to debug kernel drivers. And any bug, or almost any bug would cause a blue screen of death. And, you know, sometimes the cycle of blue screens of death, where you actually have to wipe the hard drive clean and start from scratch. And this was just, you know, that's where I learned the importance of a really short feedback cycle. You know, when you're writing a driver and everything that you do wrong,

takes you like two hours to, you know, get something new on that computer to test it again. It's just so frustrating. Yeah, I think also the other thing that you're mentioning, which is kind of interesting, like nowadays or most development, I guess, takes place in an app running in your computer. And the goal of the operating system in part is to prevent the app from crashing the operating system.

And so, or one of the many goals. But this level you're talking about is lower than that. So those protections aren't in place for efficiency reasons for whatever. And over time, they've tried to kind of get better at it, as you've said, like you're over some serial cable or USB to a tiny little board. And if you screw up, like, you know, who knows what's going on? You know, you're trying to like get commands out. You're probing it with like a little multimeter or an oscilloscope trying to like move a line up and down to say that you're alive and still running. The one thing they do have going for them is that boot times are faster. Other than that, it's just like those days of Windows drivers. But you know,

Windows could take two minutes to boot. That was another point of frustration. And, you know, you said that you're, you know, lower level than the operating system in many cases, you know, the crazy thing is, sometimes when you're writing Windows drivers, you're in a higher priority than the memory pager, which means that you can't use certain types of memory because your code can't be interrupted. Like the processor is going to prevent your code from being interrupted in order to fetch memory from disk so that means you have to do with only memory that is available in your ram this this is hell like if you can avoid it please do oh i thought we're gonna get a chance to talk about it i mean i have a bad anecdote one time

about spending several we can talk about it i'm'm saying you should avoid it as a profession, but as a discussion topic, sure. Several weeks spent debugging an intricacy between a deadlock of two interrupts at slightly different parties that were not at the parties they were supposed to be, and one was interrupting the other. And it just created a sort of cascade where it kept interrupting it, which would fill up the stack. But of course, none of that's obvious, right? And so, yeah. I have a similar kind of story to you on. Patrick and I worked at a place where we did a lot of embedded, but I didn't do a lot of embedded.

And so I was writing these kind of like, I was in a space where we had, you know, gigabytes of memory. And so it wasn't an issue and at some point someone asked me to do something on a dsp and uh yeah i just i couldn't do it i was like you know i just i started like i was like oh i'll make all these structures and i'll just have this like linked list and this tree and i'll manage everything and then i it's like oh your program won't actually fit on the chip. And I was like, wait, what? I was like, oh, yeah, I guess the program itself takes space.

And I was way out of my league. I was like, Patrick, bail me out. Somebody help me. All right. All right. So, okay, keep going. So you're at a cybersecurity firm. You're writing agents.

So like things that run on the Windows computers and then get managed up. And then from there, sort of how to do what came next? Yeah. So by the way, after that, I once again, vowed not to do any type of low level programming and failed once again, to keep my promise. But this time, it's, it's, you know, a bit more elective. So I'm, I do a lot of home automation, and I end up writing a lot of code that actually deals with hardware in my home. Sometimes I have to reverse engineer the protocols that they use. But anyway, so after that, I was with that company for about seven years in total. It was acquired at some point.

I stayed with the acquirer. But at the same time, I also moved to New York. And after leaving the acquiring company, I joined a small startup called Handy. And Handy is kind of like Uber for home services. So you can book someone to come clean your home, etc, etc. It was a very small startup. And we were like four people. And I joined as VP of engineering. And I was supposed to build an engineering team and start, you know, making sure this thing actually works. And, and, you know, finally, I'm in the clear, and I'm writing high level server, backend code, you know, I started hiring people. And, you know, once again, I witnessed that, you know, coming out of college

and not being prepared for work kind of thing now as a hiring manager, but very similar to what I experienced on my first day on the job. And I did that for a couple of years and then once again transitioned to WeWork where I was initially VP of engineering as well. That was a wild ride. That's material for a 90-minute long episode for sure.

Probably, you know, way more than that. Yeah, I think we'll just not have to go on to that one. Yeah, okay, keep going. And, you know, did that and spent a few years at WeWork. That was actually really cool. We've built some really amazing tech. You know, people always ask, why does WeWork even need tech? But I can honestly say that some of the things that we've built are groundbreaking. And, you know, even things as mundane as making

sure that key cards, key cards actually work. So if you've ever been to a hotel, you know that they don't work in like, at least 20% of the cases, whereas at WeWork, they always work, and you can actually switch buildings and switch companies and even visit a building that you're not a part of. And if you have a booking there, it's going to open. So we built a lot of really cool things, both software and hardware to make these things work. And after leaving WeWork, I spent a few more years. I was six years at WeWork and I've done more than just engineering at some point and moved

on to different roles. But after leaving WeWork, I did a short, very short stint as a VC, but decided that the life of a founder is a better life for me. And that's when we started Wilco. Okay, awesome. Well, we're going to come back to Wilco at the end. So we'll put a pin in that. And I think this observation that you made is people saying, oh, what kind of tech do you have to build for insert company here? And I think that at some level, people say tech is changing the world and things are, but then this thing you're elaborating like key card example, just as the thing is, you think it's just a commoditized product at this point.

But then are you even mentioning about home automation? And most people's home automation experience just tell them it doesn't actually just work. And so you run into all of these for no fault of necessarily the product provider, but they're fine tuning for like a specific use case and sometimes overly so. And if you're just outside of that

or two steps outside of it, you sort of end up on your own. They're happy to sell you their product and it'll do maybe the thing it says on the package outside of that, or two steps outside of it, you sort of end up on your own, they're well, they're happy to sell you their product. And it'll do maybe the thing it says on the package, or you can hold them to it. But if you want to use it in a new application or a new way, you're sort of left out on alert yourself and sort of adapting it or adding front ends or gluing it together in some way or interfacing systems. And that's a bit of a recurring theme. And so yeah, I'm not surprised to hear you say that, but it is great to hear such a sort of,

I think, understandable example. Yeah, and that's what makes, we're going completely off topic, but that's what makes build versus buy decisions so complicated because sometimes you have a product that is the leader in the space and supposedly great, but your use case is, like you said, just not the right use case for it. And, you know, sometimes you can adapt what you're doing

and then, you know, just buy it and use it off the shelf. But sometimes what you're doing is unique and enough and not adaptable that you just have to build your own and, you know, always have to be very careful to make sure that you're not, you not invented here biases that are causing you to build this yourself. But sometimes it is the rational decision to build something that already exists. You are right. And I think making sure you've avoided the biases is a bit of a trick there. But yeah, it's very difficult. Okay. Well, to finally get to the- Trying to avoided the biases is is a bit of a trick there but uh yeah it's very difficult okay well to finally trying to avoid the biases maybe maybe that's a better a better way to phrase it

doing your best doing your best yeah uh okay so finally here we go we're here it's time we're going to talk about this so uh code review we already i think even set it up unintentionally not that it was the purpose of the lead in, but already sort of talking about students coming out of college, talking about, you know, expectations that are unobvious. I think several of those sort of TS up or describe sort of code review. If you sort of type in,

I don't know. I haven't tried it. If you type into the search engine, define code review, I'm sure you get back something that probably adequately describes the gist, but it doesn't capture the essence, right? Code review is a bit more than just the most obvious, like I show you my code

and you grade it like a school paper. I think there's a bit more to that. And I think this is gonna tee up the discussion. So I'll give you the opening argument here on or opening discussion about, you know, how do you think about code reviews? Well, you know, I actually like to start with a topic that's early discussed,

which is why code reviews, right? And if, like you said, you type in code review into search engines, you're actually going to find a lot of content on how. You know, these are the best practices when reviewing code. This is what we do at Company X to review our code. But why are you using code reviews? you get into that, there's a whole world where you start to realize, wait, how am I even taking someone else's workflow when our motivations are completely different? And sometimes you'll find that even within a single company, the motivations for code review are different between teams.

Now, if you ask most people, I would assume that a lot of them are going to think that finding bugs before they make it to production is a motivation for code reviews. And that's something I don't like, to be honest, because I think there are better ways to find bugs. Now, I'm not saying that if you find a bug in a code review, you should ignore it. I'm just saying that, you know, finding a bug in a code review is finding it too late in many cases, right? You want to find those way before that stage. A code review involves another person. You want to find that before you involve another person, unless you're pair programming. Yeah, I think just on that before you keep going, i think that this thing is interesting i've had

occurrences where i've reviewed someone's code and missed a bug and they want to share responsibility they're so so gracious right well you reviewed the code and so therefore you know you should have known it didn't do anything or didn't compile or didn't work and i sort of you know that that conversation that missed expectation about what was happening. But this thing is that even at the time, maybe I didn't spend infinite amounts of time and try to come through it or redo all their own work. But sort of setting up those expectations and making sure that the team shares them. But yeah, this one in specific, like that if you review your code, if you don't catch the bug, it becomes like your bug too. That's a bit of a hard arrangement to have.

Yeah, that's a bit extreme. But you mentioned the word share, which I think is really important in this context, because code review is a lot about sharing. And to me, one of the biggest motivations is creating that shared ownership of the code, not shared ownership of the bugs necessarily. And I don't think people should own bugs. I think they should own up to them. But it's about creating that shared ownership of the code. And this is actually something that both the reviewer and the reviewee can take. Because if I'm reviewing your code and you might be working in this company

or on this code base for four years and I'm just coming in and I'm reviewing your code, I'm actually learning a lot through it. I'm learning, first of all, how are you used to working? And maybe I'm used to a different workflow. And I'm learning about the patterns that you like in the code base. And I'm learning about the patterns that you like in the code base. And I'm learning

some of the gotchas that I might find in this code. So reviewing is actually a great way to read code. And reading code is a great way to familiarize yourself with the system, right? And you can't just go around reading code, but you can go around reading changes. That, you know, is a great way, I would say, if you're starting, reviewing code is actually a great way to start. Now, some people might balk at that. And, you know, they'll say, wait, but the person reviewing should know better than the person who's being reviewed. And you know what, that's not always the case. And, you know, in many companies, there's someone at the top of the pyramid, someone needs to review their code right uh ai that's we have ai for it um no i

think i think this observation is great and i think so two things one is like you can have more than one person review your code so there's always that but i do agree with this and the other thing that being thoughtful about this when you decide how to group stuff for a let's just say we're using a git workflow or whatever you know for a pull request or you know that that's that's what we're going to take how do you decide when to stop and when to do that and making sure that you are not just doing that for your own convenience, but for the convenience of reviewers. And further, I agree with this point that like, doing it such that a new person has a sort of self contained snippet narrative that takes them through, you know, hopefully, we're all we're going to assume some good software practices here assumption is like, you're seeing that maybe the

person added a unit test for the failure that they were fixing or a test for a new feature they were adding. You see the code that was changed. You see how many places and what parts of the system got affected by that particular feature or that particular thing. And it becomes this self-contained, encapsulated description. Now, not all pull requests would be like that, but I think a large amount of them can become this very

readable thing. If you try to make sure you divide up your work in a way that the stream is readable, you're doing a great service to the people who are coming after you. Exactly. If you need to familiarize yourself with a code base, that's a

tough thing to do. You probably need some combination of top-down and bottom-up, right? You need to understand the architecture of that code base. And that's sort of the top-down approach. And you see how things communicate with each other, which components are there, et cetera, et cetera. But then you also need that bottom-up. And I think that reading past reviews is actually a great way to familiarize yourself with a given code base and and the given practices around it which are just as important i have uh i'm not the best at this but i have consulted old code reviews of

myself or others for just remembering which pieces need to go get changed again and seeing who commented on the time and said like oh yeah in the future this needs to shift or this and i'm like oh i'm doing it again now that didn't make it in the code it's necessarily appropriate as like a code comment but let me go back to the review that happened at the time and see what did we discuss what was our thought about about, hey, next time we visit this, let's consider doing, and ah, there it is. And so even if there isn't people on the team right now learning or in that stage,

yeah, there could totally be in the future people reading your old code reviews and the process you, what you're writing in the code, but also how people are interacting with that process and observing it. Exactly. So, you know, that's one motivation, but I can think of so many other motivations that you might want to review code for. And, you know, another one of these could be the quality of code. So you can automate some of that stuff, but some of it, you know, you want humans to take a look at the code and say, all right, I'm going to perhaps assume that the code is doing what's advertised, right? But is it good enough? Is it maintainable? Is it something we want in our code base? And that's, you know, another great motivation to have a code review. And there's so many different things, you know, is it secure? Are there any performance implications to what's happening there? So many different things that

you would like to test and review. And finding bugs, like I said, to me is way towards the bottom of the motivation. But, you know, let's say that you've decided what your motivation for code reviews is. As I said earlier, it doesn't have to be consistent between teams, even with the same company. So at WeWork, for example, we had a billing team. They were building a product that build our customers. And when you build your customers, you need to make sure that everything is super accurate. And you need to make sure that everything complies with tax laws, etc, etc. And the code review process is actually very long. And some of it is actually regulated.

You have to make sure that to meet certain types of certain sets of compliance rules, the review needs to go through some process, etc, etc. But then you have another team that might be working on the front-facing website and wants to iterate quickly and get experiments out there. And if anything bad happened, they're just going to roll forward and fix it on the go. Why would those two teams follow the same process? They start with different motivations. It can't be that, you know, what I'm seeing in a blog post about the best way to do code reviews applies to both of these teams equally, right? I mean, there has to be some sort of adaptation to the specific motivations you have on your team. Yeah, maybe a poor analogy, but someone brought something up the other day that I think like applies here or whatever,

that if you take folks who work with wood wood someone who like frames a home and someone who builds fine furniture they may both use a hammer they may both use a saw but like they don't use them for the same purpose like sure to cut wood or nail a nail but like if you're doing fine furniture like the delicacy and like force you're going to apply are very different than someone who has 783 two by fours to put together to, you know, make your house like the, how,

how, what happens if you miss, right? Like, Oh, I hit the two by four. Who cares? It's going to get covered up,

you know, versus like I'm driving in this nail into this, you know, a thousand dollar piece of wood or whatever, right? Like you may both say, Oh, they're both hammering.

They're both doing carpentry or I don't know if that's the right word for it. They're both doing woodworking. But to your thing, the motivations are entirely different. And the way you would judge their performance shouldn't be the same. Yeah, you're absolutely right. And you know what, this actually happened to me when I showed this design to a carpenter that's doing furniture and he looked at it and he said, this looks like someone who's building homes designed this. This is not the way that you would design a piece of furniture and not the way you'd assemble it. So, you know, he had a beef with the inside out versus outside in of like connecting, you know, the pieces of wood together. So you're absolutely right. And I've seen it firsthand.

And I think like to bring it back, I mean, I think your illustration, maybe people don't realize that actually that there are certain accreditations or sort of standards of safety or privacy for things like medical or whatever, where actually the artifacts, the code review itself becomes like a thing that should be recorded and processed to be followed for auditing purposes later. It's not that an external auditor is going to look at every one of your code reviews, but they want to be able to look at one of them. And they want to see that it's always done and that it's not rubber stamped, right? That thought is put into it, that time is taken. And that's very different than like you mentioned, you know, hey, I got to get this hot fix out to the server in 37 seconds, or we're going to lose a million dollars on the, you know, whatever, right? Like, those two things don't have, shouldn't follow the same sort of code review. Yeah, I've seen auditors, you know, sample code

reviews and look at them. And if you look at a code review like that, if one of the fields is missing, there's a sample through your code reviews. We've had that. I've seen that. And when that happens, you really want to make sure that the code review, everyone's dotted their I's and crossed their T's, and there's no missing field if there is a specific structure to those reviews, etc. But then if all you want to do is move fast and break things, potentially you could be

skipping some of the things. And maybe this thing that is supposedly mandatory on our code reviews, we're actually fine with dropping it every now and then if we think like there's good justification. So the level of leniency could also change according to what's the impetus for the review. Yeah, so I think these callouts are awesome, right? Like, you know, not only about fixing bugs, about using it for the right sort of task at hand? Like, is it rigorous audit compliance and has like a very specific format or is it more sort of go super fast or is it a kind of middle of the road?

I assume most tasks are probably kind of the middle of the road ones and sort of making sure that all of the right bits and moving parts are in place for for code review and sort of like you said i think there was a great call out it's a i don't say a pet peeve of mine but something i also do so like it kind of sounds dumb one thing i screen for like we use c++ and i screen for people using like i don't say banned parts of c++ but like getting too juicy with their c++ work and i'll come in as sort of like, you know, having been around a

bit longer and sort of say like, no, actually, like for maintainability purposes, please, like, don't do this clever, weird template metaprogramming trip and just like, you know, write it out. And so it sounds kind of goofy to kind of do for that purpose. But it's about making sure that the style and not the linter style, like you were alluding to other tools to do the job of checking that code compiles, linting. We didn't say those, but I'll. And so, you know, sort of saying or sort of saying that, like, for me, it's a higher level stuff that is a human stylistic choice. Like, how are you choosing to decompose your functions? How are you, you know, structuring your code in a readable way? What paradigm are you applying here? And that's what I'm sort of

looking for, in part when I do my reviews. Yeah, eventually, you know, we, we spend more time reading code than writing it. And definitely reading code is a more important skill than writing code. And you get to use it in a review, right? And when you read that code, you need to make sure that others can read that code too. And what you said about those C++ tricks is great because, you know, in many cases, you can actually read that code and understand what it's doing and, you know, in a split second, but you know that other people looking at it are going to have a hard time and are going to struggle with it. So sometimes you have to kind of look at it from the point of view of someone who's, you know, not necessarily at the same experience level as you. And when I say experience level, you know,

this could be, you know, not just an experience level, generally speaking, but experience with a specific product or a specific code base. Yeah, I think another one, just to chime in while we're in this vicinity that I've done recently is, and maybe people could debate, oh, let's see what your opinion is, if it belongs in the code review or in something else,

which is someone sort of made a choice that was a choice, and I sort of put to them, like, hey, we have two ways in the code base of doing this, like, you know, this way of made a choice that was a choice. And I sort of put to them like, hey, we have two ways in the code base of doing this, like, you know, this way A or way B. And we used to use only way A, we've started introducing way B, you're writing this utility, and this sort of like, like, what, what is your decision mechanism that you're choosing here to do way A, instead of moving it to new to new way to way B. And then we sort of had a little bit of a discussion where other people could kind of chime in, which is, hey, we're writing this code. We're trying

to move to a new way. What is the rubric we're using to follow about how to decide what technology to use or which place? And I don't know, actually, if that's appropriate for a coder. I mean, I did it in a code review. Shame on me, maybe. But, like, if you're going to burn me for it. But, like, I think, like, to me, that was an interesting, like, it made sense because it was in the place where it was happening. But I'm actually, like, unclear if that's a – does everybody see that on the team? Like, is it the right place to do it? it. So I think that, you know, once you've encountered a practice that you think is no longer the recommended practice for that team, then calling it out during the review definitely

makes a lot of sense. But depending on how big the change is between those two ways of doing that could hint at, you know, the fact that it should have been discussed earlier, perhaps in the same form, perhaps in a different form. But if the different way is we're no longer doing I++, we're doing plus plus I, when we're incrementing a counter, that's fine to do in a review, that's okay. But if the new way is, oh, by the way, we're no longer using remote RPC.

We're using RESTful endpoints. Maybe that's too late. That's a great, like, I don't want to say phrase, like almost fits on a T-shirt, maybe not. But like code review sometimes is too late. And I think this is like a piece of tension between someone not letting people know soon enough about a controversial decision, letting it people in code review and forcing them to really take on more work than is appropriate when they had budgeted and they thought time was done. And

now they're faced with a large change. And when you say that, there's an important point to be discussed here. Code reviews are probably one of the most common and sometimes one of the best examples of combining soft and hard skills. So a code review is not just about code. It's an actual process between humans. And like you said, sometimes people might be looking, might be out to get someone else in a review or might be trying to slip something past the reviewer. But these are just, you know, two things you might find. But

there are so many other patterns of human behavior that you can find in reviews and reviews could be very contentious because of that. You know, that's where developers who in many cases have large egos come in and sometimes have conflicting interests and have to sort it out somehow. There's room for a lot of anti-patterns in here. The two that you mentioned are just two examples. There are so many others. It's scary when you think about it. Yeah think one thing i've tried to i don't say promote i've tried to encourage people is and i think you were alluding to this early on in in part which people think about the tool of code review whether it's like github or some other whatever tool you use code review um and that tailoring it to the needs. But I would say to the review can happen as well.

You don't want to tailor every review in a specific way, but there are some changes which I will tell people, look, you need to socialize this before you put it up for code review. You need to go talk, actually go to someone's desk or schedule a video conference call with them and have a time to walk through so that they feel comfortable in doing the review that they understand what's happening it's not that

that change is necessarily avoidable or bad it may just need to be that way it's a massive change but give people a heads up and and that that in itself is still code review like you are reviewing that code but you're not using the code review tool right like you're splitting the the sort of what the why of code review into different parts you might still go through the formal process of having someone approve it but it might be a relatively empty you know amount of requests or changes to be made why because you did them up front because you had someone go through it and the like one i'll call out here is like people like to do that with interns like wait till an intern gets almost to the end of the internship have them drop off a bunch of code and then like red mark the heck out of it because they didn't

know this is the style or this is the whatever and i'm like no that's a really like you said soft skill that's a really bad soft skill practice like it's really frustrating and the second thing is like you really you you probably knew in advance that was going to happen and you let it get that far like you should have just gone to them and said hey can we sit down and look at your code can you put up your branch and let me look at it whatever the right you know technology you want to set people up for success with their reviews and and you know if people are getting to the review in their last day or last week of the internship and everything is red marked, then, you know, in a way that's sort of a waterfall approach, right? You let them

write everything in advance and then it goes to the review stage where everything is happening. And then afterwards it's going to go to the next stage that it's very waterfall. And, you know, waterfall is considered, you know, bad practice these days, and for good reasons. But it doesn't mean that you shouldn't be discussing things before you write them. It doesn't mean that every change is the same. And, you know, the size of the change matters, the impact that it has matters even more. And more importantly, like you said, the motivation that people might have or their desire to succeed in getting their code into production also plays a part in that. I think we could probably go at length for code reviews and, and pontificating or soapboxing, but I'll try to land,

let's try to try to try to land this, this aircraft down, which is, I think, as you mentioned, like the, we haven't even, or I guess I did,

you didn't, but you know, we haven't talked about the specific tool or the how of code review. Instead, we sort of explored this topic of, of why I know there's probably tons more you'd like to say, but any sort of like final things we kind of didn't get to or sort of things you want to call out? Well, you know, just the fact that it is an interaction between

humans and you need to be careful in how you conduct yourself, just like any other way. You know, people tend to think that what I write in a code review is not like a regular conversation. I can be snarky. I can be offensive. I can just be a bad colleague. Well, guess what? You can't. It's another form of communication. You need to be respectful. People have worked hard to do what they do. And even if you don't agree with it, and even if you're right, it could be because the other person is used to a different team that was working in a different way. And they could be right for the context that they're used to. And you definitely should assume that they're not doing anything bad on purpose. So just code reviews are probably the easiest way to get to developers at each other's throats.

So just keep that in mind and be careful. Yeah, such a great observation. I mean, I guess to use your sort of quip from earlier to your interviewer asking about what's a context switch. Like, are you serious? Not an appropriate code review comment. Like, are you serious? Like, I have seen stuff at that level that's not a a sort of like a like go to them like send them a slack message schedule a meeting like you can have it's not some violation of some

inviolate like contract that they pull down the code review change something and put it back up like this is perfectly fine uh and so you're right. I have seen way too many people get at each other's throats because someone was grinding. There's a cultural norm to establish and help shape. All of us, every time we do it, are subtly influencing the team's culture of code review. And new people especially have to get onboarded to that process. And don't get me wrong. I've had my fair share of arguments over code reviews and I'm not perfect. And I've made many of the mistakes that I try to preach other people not to do. But as you do more and more of these, you start seeing the patterns in advance of a conversation not going the right way.

And if you're the more senior of the people interacting in that review, that is your responsibility at this point to figure out that the conversation is not going in a productive direction. And that is perhaps the time for you to maybe take it to a different medium where you can discuss privately and reach some understanding and then come back to the public conversation in a better mood and less argumentatively. Is that a word? Argumentative. Argumentative. Yeah.

Yeah, that's, that's such a such a good point. I mean, I think the one thing I tell senior folks is, you know, if there's two junior folks, or more junior folks, you know, arguing about something like they're sort of in a competition in a sense. And you as a, you know, you know, a staff engineer or a principal engineer, like you've already won in the sense, like you've already gotten the thing that these people want to have one day. And so, you know, taking that approach of saying, look, you know, you've, you've already won and you can't, you can't unwin. Like no one's going to down. I mean, I've never heard of a company down leveling a prince, an engineer. I mean, they'll, they'll fire people before they down level them. So, so it's like, you, you've kind of, you've established yourself, you know,

and so now like, if you can make a small sacrifice to really like bring these people together that's that's really something that you're uniquely kind of positioned to do and that's something that i think is is could be difficult for people as they kind of move up to uh to understand that that is something that they're uniquely positioned to be able to provide to the to the company but eventually that that is something that they're uniquely positioned to be able to provide to the company. But eventually that's what their job is, right? If you're a staff engineer, one of the responsibilities that you have is making everyone around you better, all the other engineers. So if they don't understand that, maybe they should be down-leveled. I have read a lot of articles on hacker news about what makes a senior

engineer i don't recall reading a lot about empathy or sacrifice or what are you guys talking about that's how it makes a senior engineer you know it's just like the college thing right they teach you the wrong things all the people who chose spaces became senior that's how i have to admit though jason jason i'm i'm i'm envious every time you speak you have such a good microphone and you know i i'm on my you know crappy headset patrick and i got when did we get microphones like five six years in i don't even know how that happened and then i reverted back from, I'm too lazy. Well, yes, you moved, right?

It's probably still on the box somewhere. Somewhere, I got to dig it up. All right. Well, that has been an awesome exploration. I know there's more to do, but I'm just going to, I'm going to just put the sort of period at the end of that sentence, whether we punctuate, whether we should have or not. But let's talk a bit about, about Woco. So we sort of put a pin in it in the beginning. We're coming back to it now. You saw a need for a startup, right? I mean, like, ultimately, maybe I'm

presuming that's what founders tell us, right? Like, I saw a need. I saw something that was not there. And I was uniquely suited or so passionate that I needed to go build it. Help tell us, like, why Wilco? Yeah, sure. So you know, if you take a lot of the points that we discussed today, you realize that there is a mismatch between what people learn, and what people are actually doing as software developers. And it doesn't matter what level I mean, like you said, you read all these, these articles on what a senior engineer should be. And most of it is about code. But code is just one skill out of many that a good software engineer needs. And college doesn't teach them

that boot camps don't teach them that. And eventually developers need to practice. And the only way to practice is on the job. But when you practice on the job, it's A, very slow. It's B, very error prone. And C, it doesn't provide equal opportunity. So much depends on which team you get to and whether you had the opportunity to get into a good team. So what we said is,

what if we give developers a good way to practice? And when we say practice, we mean all of the skills, not just code writing. What if we give developers a good way to practice that is safe, that is all of the skills, not just code writing. What if we give developers a good way to practice that is safe, that is in their own pace, that depends just on their merit. And we came upon this idea of giving them or letting them join a fantasy company. And that company has a production-like system with logging and monitoring and analytics and

load balancing and a real data set, not just five records in a single table. And it has the biggest mess of all, which is people. So you have colleagues and you have team leads and product managers and stakeholders and all of that. And on top of that, you start going on simulations or adventures, or we call them quests because we're so influenced by 80s video games. So you start going on quests and a quest could be, we have a performance problem in production. Please figure out what happened. What's the root cause? What's the extent of the damage? Fix it and communicate it to stakeholders. And the focus is not on fix it because you can learn how to fix it in college or at a

boot camp or even online. The focus is, how do you even know that something's wrong? What do you do to investigate it? When do you go for a quick and dirty fix? When do you go for something more meaningful? How do you ensure that lessons are learned and implemented? And that's definitely something that's not covered anywhere. And all of these tiny things that you really only pick up on the job.

And that's what we're trying to help you do with Wilco. Yeah, I mean, this is, you're right, like such an uncovered, people make quips about sometimes, like maybe I only wrote one line of code, but the hard part is figuring out what line of code to write and i think yeah once you know what it is you're trying to do i mean we make that choice just stack overflow or whatever right like you just go to stack overflow like how to turn off you know database backups and you know during peak performance

or whatever i don't making something up but knowing what to google this is sort of this like untaught very long lead time long iteration or even knowing that you should google oh there you go fair enough like i mean let's say i change the database schema it's no longer the same should i do something about it or should should I just, you know, go to production and everything would be okay? Well, turns out, most people early in their career are probably not going to search anything about it, they're going to assume that, oh, I just added an index, everything is, you know, everything should be fine. But then it goes to production and the database is halting and, and, you know, nothing's working. Well, you should have Googled it before, and now it's kind of too late. So it's not just how to Google, it's even when.

Yeah. This too, we were joking about senior engineers, this on-the-job, hard-knock training about building up that intuition a bit. And it's great to hear that. I think maybe I call it intuition, but actually, you're kind of like, no, no, no, wait, wait, this isn't that this is some unteachable, unknowable thing that actually put into the right circumstances. There are some commonalities here, some, some simulations where we can put people through and sort of have them

kind of realize that themselves. Yeah. I mean, like they say, the way to Carnegie Hall is practice, practice, practice, right? So it's not just for music. It goes like that for every type of profession. And software engineering is no different. You need to practice. And practicing actually allows you to develop intuition. Musicians that improvise practice a lot beforehand. It's not just that, you know, they go out and improvise, they learn the basics, understand what are scales and how they fit with each other and how melody and harmony work together. And then they can start improvising, right? And same goes for software engineering if you practice enough you'll develop that intuition that allows you to do things or know uh when things might go wrong and when things uh are are pretty

safe you might still get it wrong but at least in most cases uh you'll get it right and you know we've actually seen other professions do something similar So one of the things we looked at as we were working on Wilco is this thing called CTA, which is cognitive task analysis. And what we've seen is that firefighters learn the theory of fires and what to do in an incident, but then they go to an incident and they might not necessarily be able to apply the theory that they've learned, whereas a firefighter with 20 years of experience gets into a scene and knows exactly what to do and how to do it, but they can't teach it. And what CTA does is it tries to extract that knowledge, that expert knowledge,

and turn that into something that could be handed off or could be taught to other people. And that combination of intuition, experience, wisdom, some people call it, is, you know, that's the elusive thing that we're trying to really give you with Wilco. This observation is really that the other fields do. I have some family in the medical field. And one of the interesting things is part of their degree is doing on the job sort of, you know, internships, as it were, I guess they call them other stuff. But they also do simulations where they bring in actual patients who have like a set of things they're supposed to say. And you say, oh, that's just testing their knowledge.

But actually, you can have something that sounds exactly like a very esoteric disease. But I think there's some phrase for it. I'll misquote it, so I'm not going to say it here. But the point being, like, there might be a much more mundane answer that could manifest the same way. And that's the one you should test first, not jump to the one in a million super rare mutation disease. Because all of them watched house and they think that, you know, that's the life of a doctor. Yes, because everyone comes off that training. And so it's this thing you said, which is one, extracting the knowledge, like teaching flows, they call it like differential diagnoses. Like,

how do you decide between A and B? What is the test to apply? What is the choices? But then also not stopping there and teaching it, but actually putting them in a, you know, more complex, more messy case with real humans who don't describe things accurately or, you know, no, I don't have a cough, you know, and sort of like, yeah, you're getting contradictory inputs. And so what do you do then? A friend told me once, he gave me a great analogy. He said that if he wants to understand the state of the art in medicine, he's going to go to someone who just graduated med school. But if he needs someone to operate on his shoulder, then, you know, he's going to go to a

doctor with or surgeon with 15 years of experience and that surgeon might actually know less than the recent grad but they've been there done that and and you know software engineering is like that there's a difference between knowing the state of the art and actually being able to practice it well cool all right so tell us a bit about Wilco as a company too so we talked about it as a as a sort of product and solution and, and sounds very engaging. Um, and we'll include in the show notes, but you can go to try Wilco.com and check it out, but talk to us about, about Wilco as a company. Are you guys hiring interns? Like what is the kind of behind the scenes of creating these quests? It sounds really interesting. Like how's all that powered? Yeah, it's, it's, it's, you know, I'm biased, but I think it's really cool. And writing a quest, you know, is a combination of understanding the the skill you want to practice or the lesson that you want to convey. But also tying that into a narrative and, and, and making

sure that it's part of a curriculum, you can go on Wilco, you can practice all sorts of things. And, and it's not, you know, you use your own tools. So, you know, you're going to use your command line, you're going to use your IDE. But you might be using an observability tool, for example, because you need to maintain production. That's something that you don't do in college, right? But it's not just for college grads, right? You might be doing 20 years of programming in a different field and you're coming into something new or you're just looking to practice. So you're going to touch upon different tools and all of that. And of course, you could also be building your own.

So we don't have it just yet, but very soon we'll have an editor where you could be writing your own quests and contribute that to sort of the Wilco ecosystem. We already have companies that have built quests and they're on the platform, but in the future, we'll open this up to individuals as well. Very cool. Very cool. Do you guys, for hiring, are you looking for people who are like strictly like very senior established and ready to sort of impart what they've learned? Or you're looking for up and coming people to help build out the out the things that build the i mean i guess it becomes a eat your own dog food kind of thing well where do you guys kind of do most of your hiring since we're you know all about developing developers you know it would be very hypocritical of us if if we wouldn't

be open to people of all experience levels and we think that wilco is a great way for them to bridge that gap and and you know very gain experience. So we're really open to all experience levels, that's the kind of people that we want on our side. And actually, you know, being inexperienced in many ways has sort of an advantage of, you know, being able to call out things that we take for granted and might be tough on, you know, people who don't, you know, haven't exercised that skill or learned that area. Awesome. Well, this has been a great conversation on, you know, we covered a lot of ground. We put a lot of sidetracks aside and sort of we tried to stay on track a bit. But sidetrack is my middle name. Oh, there we go.

Oh, I did. I see what you did there. Okay, well, there's our pun of the day. And so thanks for coming on the show. think people are really gonna like this i think it was a a thoughtful thing you know as a as a junior engineer i made a lot of really dumb mistakes i you know sometimes i wish i had the exposure to the things i i think are around now but to be honest probably wouldn't have paid attention to them. But maybe maybe we'll catch the person who thinks they don't need it. But you know, maybe maybe kind of puts a bit of extra thought into it today. But yeah, great advice all around. Thanks for being on the show. You know,

I think it's, it's been an awesome time. Thank you. Thank you so much. It's been it's been really great. And thanks for having me on the show. All right. We'll see everyone next time. See you later. Music by Eric Barndollar. Programming Throwdown is distributed under a Creative Commons Attribution Share Alike 2.0 license. You're free to share, copy, distribute, transmit the work, to remix, adapt the work, but you must provide an attribution to Patrick and I and share alike in kind.