Prolific Mentor and System Automator

Jonathan: Hi everyone and welcome to the Exercism Community Podcast. I'm privileged to be joined by Isaac, who is one of our maintainers and contributors and has recently done a lot of mentoring of a lot of students on our GoHorts, our learning cohorts, which we ran for 30 days, twice I think now, especially in Go and Elixir. And Isaac helped with the Go track, which was awesome. So Isaac, a huge welcome to you. Would you just tell me a bit about where you're based, where you come from and how you got into tech? Isaac: Yes, I'm based in California. I live in San Jose, California. The honest truth is I got into tech because my older brother was into tech and I would do whatever he would do. I had a bunch of siblings. We liked to hang out with each other or some of us liked to hang out with others more than others. I had an older brother that I really liked to hang out with. He didn't necessarily enjoy hanging out with me as much but there was a lot of me following him around and wanting to be doing whatever he was doing. He picked up a C for Dummies book that was lying around the house when he was about 15, and I was 9 if I recall correctly. So he was writing C, and I'm like if he's doing that I'm going to do that. My programs were pretty simple and basic at that age. It was more like you know what is your name, hello Bob type exercises. They were not overly complex. Got to start somewhere. Got to start there. I was like oh you could print out the visual files character, and it makes a sound. That's so cool. I wrote a program that like literally just prints out a slash A. But I was starting at 9. I was writing C programs. We had an old Windows 3.1 machine that booted into DOS and then my brother had set up a batch script that when the computer booted it would display a menu that you could select like launch Windows, launch games, there's like a game menu. You could type like 5 for like Warcraft or whatever. So I was writing batch scripts to sort of as we had other games installed and whatnot. It sort of was all downhill from there. My brother went to university for computer engineering and once again I was like if he's doing that I'm going to do that. So I started writing C when I was 9. I was writing... Visual Basic 6 in high school. I had a POM pilot that I was writing various programs on the POM pilot in high school. My math teacher was really cool. I was at one of those old school... Jonathan: Was that that sort of like, remember they tried to release like the pre-iPad thing and it kind of, a few people got hold of it and it kind of had the little pen scribble thing. And everyone thought it was like super cool because it came out the end, and it was like zoop, and then you could like tap away at it. It was kind of, it didn't, I always remember that because then the iPad started coming out and everyone was like, ah, a bit early. One pilot was just that bit, a bit ahead of the curve, you know what I mean? Isaac: It was great for a decade or so, but yeah, there's like the palm graffiti that you used to input. There's a little input pad, and you had to write like characters, but they were like sort of based on the alphabet. So like the A was just like a triangle and like an F was like the right angle. Yeah, my high school math teacher was like, hey, if you wrote the program, it's cool if you want to use it on the test. So like I was writing POM pilot programs in high school, which was really cool. I went to University for Computer Engineering. See people were talking about scripting languages. I didn't quite know what those were, so I randomly picked up Perl. And then I got out of grad school, I went and I got hired by Google. In 2013, they moved me from the East Coast to California. And that's where I picked up Python about a decade ago. And Python's been my primary language for the last decade. I went to at Google, so my style is very much influenced by the Google style. And that's why I've been primarily writing. And then about...Four years ago, I guess 2018 or so, Google started pushing the Go language internally and I picked up Go at that point. Jonathan: Cool. And Isaac, when you talk about Google style, was there a set sense of this is the right way to do it or is this kind of like, how did, just expand on that a bit because that's interesting. Isaac: Coding style isn't necessarily the correct way to do it, so much as a uniform way that everyone shall do it. They say a good compromise or a good deal is a deal where no one's happy. No one's quite happy with the style guide, but as long as everyone's following it, the code looks uniform. That means that anyone can pick up any piece of code in the Google code base and make modifications, and as long as they're following the same style guidelines, like the code is all uniform, you don't have to be like, oh, this code base uses four space indents and this one uses two space, or this has naming convention like this or like that. Everything across the entire code base is done the same way. Not everyone's happy with any of it. Everyone has their own areas where they would wish it was done differently, but given that there is a documented style guide, which is publicly available, you could just Google for the Google Python style guide and it tells you this is how we write code at Google. As long as everyone sticks to that guide, the code all looks very uniform, which is really nice to be able to open any code base, and it just looks like there's no surprises about like, oh, they would write this differently. Jonathan: Is that why Go maybe sort of fits quite nicely into that context? Because it's formatted and really like this is how it is. You can definitely see the Google influence on that. Isaac: Yeah, I don't know how much Rob Pike was influenced by the Google approach or how much he influenced the Google approach. I'm not sure which led to which, but Go definitely takes that to another level where...There are even more, like with Python, there are different styles and people tweak their linters to accept different things. For example, internally Google uses two space intents in Python because there's a lot of code that's nested deeply and they don't want to have a massive wall of space. Externally, most people use four spaces, and that's sort of written into the Python documentation. But yeah, when it comes to Go, they just took that to another level and they're like, the language itself has both formatting. There is only one way to format. There's no online frameworks about which is the correct way. There is only one way. Jonathan: It saves a heck of a lot of back and forth. Let's just put it that way maybe. Yeah. So that's good. Isaac: Yeah. Jonathan: So, okay, so now when you started at Google, had you never done Python or had you like dabbled or was it kind of an easy jump? Like how, because you made it sound like you kind of got the job at Google and then it was like, okay, cool, learn Python, let's go. Isaac: That's correct. I believe before I joined Google I never wrote Python. I was writing Perl for a year or two. I guess a couple years at that point I started writing Perl. My first summer job. It's a whole different story. I started writing Perl six years prior to joining Google, so I was writing a fair bit of Perl at that point. I was writing a bit of Bash, so I was familiar with scripting languages. But I haven't ever written Python. But once you dabble with enough languages... The learning curve is a bit less steep to pick up another language because you've seen most of the constructs already and it's just a slightly different syntax, slightly different toolkit. But like, it's a lot in the same old, just slightly different, written differently. The constructs tend to be pretty similar. So once you've picked up four languages, picking up a fifth is like, oh, this is just written slightly different. Jonathan: Yeah, yeah. That is interesting. So now you giggled a bit about your first job, like out of high school. So now you, because it's, had you always been like, I'm going to be on the engineering, like I'm going to be doing the computer thing. Had that always been like a conscious thought or was it always like, this is just where I naturally fit and I enjoy this and that's it. Like how did that kind of... Isaac: I guess. I was very much trying to follow in my brother's footsteps. He went to computer engineering. He started writing programming. He started programming when I was a kid. I followed along. I was writing programming since I was young. He went to computer engineering and that was the, you know, I wanted to do the same thing as he did and also I was having a great time writing programming and all that. So I had, from the time I entered high school, and my brother was going to university already, like I knew that's where I wanted to end up. Jonathan: So he's a few years older than you, so it sounds like he played a massively big influence on you as a person. How many other siblings do you have? Or was he like the bee's knees in your eyes? Isaac: I've got eight siblings, but he was definitely the one that I got along really well. He's one of, I guess, I get along with some of them better, more than others. When you have eight, there's always a range. I got along with him quite well. We tend to think a lot similarly. We tend to have similar interests. We would geek out about computers all the time. We still do. His wife doesn't like when that becomes the dinner table conversation. She's like, no work at the dinner table. We just geek about programming all the time and talk about it all the time. It's really hard to say how much was just me wanting to copy him versus us just having similar interests. We definitely have similar interests now. I don't know how much of that is nature versus nurture. I can't really comment on how much of that is me copying him versus us just having similar interests. But given that I was following in his footsteps from an early age, I was following and he was setting the path to some extent and I was following it. Jonathan: Yeah, that's really cool. And is he, where is he now? Just out of interest, is he on the east coast? Isaac: He's still on the East Coast, he's working in tech. We've worked at the same company briefly. Jonathan: Yeah, okay, cool. So there is that. That's cool. I just was interested to ask. Now, one of the things that, so you've been really involved on the cohort that we've just had. So the latest learning cohort, especially with Go, we were running a 30 day thing with Go, like how, and then your involvement with Exercism previously has been sort of specifically in maintaining, but also quite a lot of mentoring as far as I understand. So how have you found that split? Like, I mean, how did you come across Exercism and what are the different aspects that you kind of enjoy contributing towards? Isaac: So I originally came across Exercism because I was trying to relearn Haskell. I took a Haskell 101 class at Google that was quite fun. And then I was like, oh, I should spend more time doing this. And that fell aside. And then I tried to come back to it. Jonathan: and we'll see you next time. Isaac: With any language, I find that the easiest way to learn it is to actually write it. The easiest way to write it is to have a purpose for writing it. I haven't found a great purpose for writing Haskell, which made it really hard to pick up. But I found out Exercism and I'm like, oh, this might help me write more Haskell. So that's how I originally found Exercism. Once I was there, I was like, oh, there's a python track and a shelf track and like a psychoride exercises in here so I Don't the rabbit hole and down? Jonathan: And down the rabbit hole you went. Isaac: Yeah. I started solving exercises in Python. I started solving exercises in Bash. I did a couple of the Go exercises. When the Go Horde came up and I was looking through some of my prior solutions, I saw a lot of them were submitted three years prior. So I did, I first signed up for the Go track in 2019 and solved a chunk of those exercises back then. And then I've been doing Python for a decade at this point. So I felt relatively comfortable joining as a Python mentor, which is where I spent most of my time on exercises in these days. And then I started submitting PRs, pull requests to the Python track because there were things that were out of place. And then I started getting involved in the Bash track. And I'm not entirely sure how it happened, but I went from submitting fixes to the Bash track to being a Bash maintainer. Jonathan: Just like that, I mean it's just like, careful what you sign up for, right? Isaac: Yeah, and then Glenn wrote out the Ock track and I was like, oh I know Ock, I like Ock, let me hop onto that bandwagon. So I helped build up the exercises on the Ock track. I'm not entirely certain, but I think three years ago when I saw Go Exercises, I completed the entire track and then one of the mentors was like, oh, you've finished all the exercises, maybe you should become a mentor. I'm not sufficient, I don't write Go often enough, regularly enough to feel that comfortable mentoring it. So I wasn't really a Go mentor. But then when I joined the Go Hort and there was a bunch of people who wanted mentoring, I was like, oh, I guess I could sign up to mentor for the month and help out there. But I actually recently joined the Go Hort as a student. And then I'm going to slid over from the student section I guess. Jonathan: I just went and slid over from the students such, I guess. Watch out what you sign up for. I tell you, it seems to be a pattern emerging where you sign up for one thing and then you end up as another, but that's really cool. Okay, so in terms of when you've been mentoring students on the Go Track specifically, what are some of the most common things that you see? I mean, the Go Track, there's probably quite a lot of seasoned developers, I would say, who did it, like people who had a bit of track record in development, but what were some of the things that you noticed that you were like, okay, those are the common things that people seem to kind of get stuck on? Were there any patterns or things that you found that were like, okay, that's common, that's fairly...consistently appearing, potentially. Isaac: I don't know. I haven't seen most of the mentoring that I've seen has been on people on completed solutions. People more often than not will have solved the exercise before they go for mentoring. So people generally aren't stuck for most of the interactions that I have. Uh, so it's mostly, you know, they've successfully completed an exercise and then a lot of the input is, um, you know, is there a more efficient way to do this? Is there a better algorithm? Um, one of the common ones that come up way too often is like string building, uh, in. In languages like Go and Python where strings are immutable, doing a lot of string concatenation is not very efficient. So it's a lot of like, hey, you could build this using an array and then join the strings where you can use a string builder in Go. So there's a lot of, you know, pushing them towards better, I guess, patterns, best practices and patterns. Thank you for watching. Jonathan: Okay, that's cool. That's fascinating. So now, currently, what does your day-to-day look like with work in terms of where does development fit in? Say you've been in tech for a while, what does the day look like? What are the challenges? What are the bits that you enjoy with work at the moment? Isaac: So I'm in the site reliability engineering role, which is loosely similar to DevOps. It's got some sysadmin stuff in there. I've been carrying a pager on an on-call rotation for the last decade or so. So my day-to-day depends a lot on whether or not it's my on-call week or not. When I'm on call, it's a lot of watching the pager, there's a ticket queue, support queue, making sure that any failing processes or problems are diagnosed and fixed. So that's roughly one week out of six, or however large the team currently is. And the rest of the time, I'm on call. Jonathan: Mm-hmm. Isaac: I spend a lot of time messing with automation, so it's a lot of identifying processes that are cumbersome and making them less cumbersome. It might be that... There may be a reason for it to happen, but generally I find that until something starts you know, when this problem happens, we have to run, you know, we manually repair by doing these commands and those commands and it's like, well, why are we running these commands by hand? Can we write a Python script that could do all of that for you? Or can we improve the tooling to not fail and catch that problem itself? And a lot of just trying to improve the day to day of how we run systems such that humans are less involved or don't need to be as, you know, as involved as deeply to keep things running smoothly. Jonathan: So does your day, do you enjoy trying to find those little areas where things can be optimized? How much of your job is reacting to stuff and then from the reaction being like, oh cool, this is an opportunity to being proactively looking for those little areas. What's the balance typically? Isaac: I enjoy automation, that's probably the thing I enjoy the most about my job is being able to automate things. It's not always reactionary. I mean reactionary could mean that something breaks, it could also be like oh, you know, people are running this command where I found that there's this command that we tend to copy paste, can I improve that? Where I'll see someone make a change to like a run book somewhere or improve a command somewhere and I'm like oh that command's pretty messy, can I just rewrite that from scratch? And of course attention is too much, it has to be balanced with appeal, it has to be less bigger words, a better language, all that kind of stuff. You have to get on top of that by trying to do that. Honestly, I mean everything in my job really is fitting if I think about it. So I'm a very motivated person, like no, my job I guess is there with anywhere but in any job that I love killing time for myself, it's there only to try and Jonathan: manufacturing you could say Isaac: Refactoring, noticing that there's tools that are, you know, cumbersome to use and deciding to rewrite those or write wrappers around them. I'll see, yeah, like I'll see code changes to like some large, complicated program and be like, oh, that program's a mess. Can I go in and like rewrite that or refactor it? Or creating new, I mean, it's not always refactoring, it's also sometimes just creating new tools. It's like, oh, we have a process that involves doing 20 steps, let me just shove that all into a program. A lot of it does tend to be, you know, I have to discover these somehow. Sometimes I discover them because I'm assigned to carry out a set of tasks, and then I'm like, I don't wanna run these by hand. Sometimes I discover them by just noticing, like, I'll be looking up some code piece somewhere, and I'll be like, oh, this other code over here, this other team maintains, is doing things poorly, let me refactor that, or like use modern libraries or whatever, yeah. Jonathan: So a lot of...Just being able to see. So how much free reign do you have? Do you have quite a lot of free reign to kind of go around and sort of swoop in, tweak here? I mean that must be quite fun, quite enjoyable. Isaac: My manager affords me a lot of free reign, which is really nice. I don't know how much of this came from like I'm not currently at Google, but I don't know how much of this came from my background at Google. At Google, people were very open to swooping in and being like, oh, I noticed the others, you know, I happen to use this library and it could be improved in this way. Let me go ahead and fix it. Um, I very, very briefly worked at a startup where the culture was very different than it was a lot less open. Uh, and at the startup, people were very protective about their code bases and having other people modify their mode was not very accepted. So I'd be like, oh, there's an issue with this code base. Really change it for like that code base. Jonathan: Yeah, back off. But that's interesting because...you assume that a startup would be way more like, well, just get the job done and do it as cheaply as possible, you know, but actually, maybe Google was way more able to handle that as a concept. And that's, sorry, I've just put the lights on because we, no lights currently for everyone listening, no electricity in Cape Town every now and then. Just now I'm blinding myself, but it's fine. But that's interesting going back to that point about the startup culture and how like people are way more ironically caught up in having ownership of stuff and then maybe hamstringing things a bit, you know? Isaac: Yeah, I don't know that being a startup necessarily ties well to being a open...were like a play-based work culture. At Google, a lot of what people did was play where they enjoyed what they do. They do it because they enjoy it. They were very friendly about it or very open about it. Some other workplace cultures are more less about necessarily doing things because you enjoy it and more about it's a job or this is my code and I know how this works. I don't want other people messing with it. I'm not entirely sure what goes into making these workplace culture changes. But Google very much did foster a sense of everyone has access to all the code. You're all empowered to make changes to it. Go ahead and do whatever you think is the right thing to do. And then in my current job with my current manager, he's also given me a lot of free rein. He's like, sure, you found something to fix. Go ahead and fix it. You found an area where things can be improved. I'll just get out of your way. Let me know what I can do to help. So I very much am able to self-direct a lot of what I do and just you know, if I find an area where I'm like, oh, I could make this better. He's like, yeah, that's cool, go for it. Jonathan: Okay, nice. And you, the company is based on the East Coast, am I right in saying so you you actually work remotely? I think I remember you saying you were about to move over, and then COVID hit and it was kind of like, that whole thing came to an end. How are you finding the remote, the distance, the time lag, all of that kind of stuff? Does it affect you or like? Isaac: I definitely do miss being in an office and interacting with people in person. Uh, so there's that, um, the time lag has my, my team has been very, uh, accommodating with the time difference. So I am three hours behind the rest of my team. Uh, there is a short daily standup that I miss. We have two daily setups for two different products. Uh, so the first one I do miss and my team has been very good about accommodating me there and reuse Slack a lot internally. So they would, they're very good about having like a daily Slack thread with issues that came up so I could be caught up and if they need anything, they'll ping me, um, I do, I do try my best to be responsive, uh, and I trust any of that stuff as quickly as I can in the morning. So, uh, it is a bit like it's, it's the time lag is not great, but it's also not, they've been, we've been managed to work through it quite well. Um, and then conversely, there is the other side where they do know that they have someone on the team who's awake a bit later. So I've had some colleagues like, you know, it'd be 6 PM on the East Coast and be like, oh, this is broken. You know, Hey, Isaac's on the West Coast, you know, Isaac could help me out with this because it's still only 3 PM there. Uh, so it does work in both directions. Um, yeah, the, Jonathan: Yeah. Isaac: I was, yeah, so I left Google in 2019, sorry, 2020. I interviewed in 2019. I was supposed to join 2020 in May. I was planning on moving August, April 2020, but COVID started and all that and the office got closed down and it was just a lot of like, oh, the office is not yet open. He'll move as soon as the office opens. And then two years into the pandemic, they started opening the office again. And I was like, you know, I'm not sure I want to move anymore. New York sounded really exciting, but like there were all these businesses open and you know, venues and stuff going on. But now that there's a pandemic, a lot of that's not quite as exciting sounding anymore. So I transitioned to a remote position after working remotely for two years. Jonathan: And are you like a city person or a countryside or like halfway in between? Like what? Because New York is city. It's like 100% city. I mean, there's no two ways about it. You know what I mean? So that would have been quite a shift, I guess. Yes. It's exciting, nonetheless. Isaac: I did grow up in a large petro area so I am no stranger to city life. I currently live in suburbia. I enjoy hiking and cycling and I try to get outdoors as often as I can. So I do enjoy living in suburbia near amazing hiking and cycling trails and all that. Moving to New York would be quite a change. But I figure mixing it up every so often is not a bad thing. And if I hate my life in New York I always move away. Jonathan: It's not that tricky to do that. But that's cool. So now you probably, correct me if I'm wrong, spend a lot of time on screen in like an office, like home office or whatever. Like do you get out every day to sort of, how do you balance the whole in the screen world versus kind of do you have like your daily time where you're like, I've got to get out and just get outside and do something else. Isaac: I wish I did. Some days or some months or some years I'm better than others. 2020. I was pretty good about cycling almost every day. I do get outside most weekends. I try to do one hike a week. I haven't been great about it, but I'm going for a hike. Depends on the season. I'm in California. Some weeks are extremely hot. We just had a heat wave where it was...over 40 Celsius for about a week straight. So that makes it challenging to get outside. We're in California where we have fires, so you know sometimes we'll go for a week or two where the air quality outside is not entirely safe to breathe. So that makes it challenging to be outdoors in California some weeks. And then being indoors in a pandemic is also challenging. So there's definitely some weeks where I'm much more indoors than others. But I do like getting outside. There's been, you know, I've gone like just been six months stretches where I've been hiking, going for hikes like at least every other week. Jonathan: and then. Isaac: I've had stretches where I've been camping like once a month for, you know, six months straight. So there's some stretches where I'm better than others, and then there's some stretches where I'm just like in the house for like two weeks straight. Jonathan: Yeah, that's cool. And so Isaac, what is the next kind of...Maybe, I don't know, maybe you haven't thought this far ahead, but what does the next five years look like for you in terms of, do you have any idea or are you kind of like, I want to start a business on my own or I want to do this or are you just kind of like, ah, just enjoying life and enjoying where I'm at. Isaac: I, before I moved to the West Coast, I thought I had a better handle on what my future is going to look like. But having all of that turned on its head taught me that it's really hard to predict what's going to happen in the next year, let alone five. I'm quite happy. I just changed jobs relatively recently. I changed jobs about two, two and a half years ago. I'm quite enjoying my current job, so I don't see that changing anytime soon. I'd be happy to remain at the same job for the next two, three years, five years down the line. I love living in California. I love being able to go hiking and biking and camping and all that. So I don't see myself leaving California anytime too soon. And I don't see myself leaving that job anytime soon because I do enjoy working there quite a lot. So I'm pretty content and I don't see any major, I don't have any major changes planned, but it's really hard to say. Jonathan: That's cool. Okay, so I've got a couple more questions, which I would love your perspective on. The first one is probably not the one that I prepped you for, but the one... So if you were going to... If 10 people walked into your office right now, 10 complete strangers, and you didn't know anything about coding, and you had like a harpist and a gardener and whatever, what would be the top three tips you would give them to learn how to start coding? Like, if you could boil it down to like, do this at all costs, what would some of those tips? Isaac: So the number one recommendation I would have is to try to find a problem that you could solve with coding. So you have a...concrete project that provides motivation without a specific goal in mind to drive you forward. It is extremely challenging to stern code ink learning, similar to any other skill, learning to code does require a fair bit of tenacity or grit. You just need to keep at it. It can be very challenging at first. It can be very frustrating. Without something to drive you forward, it's very easy to give up on it. So if at all possible, having something you actually want to do with it helps a lot. It's sort of all in the same constellation of advice. It's just you have to have, you've got to keep at it. It helps a lot to be patient with yourself and recognize that you're learning a new skill and you're going to fail a lot. I've had some people who try to learn coding and they get frustrated. They're like, oh, I'm usually good at things and it's not working out of the box. And I'm like, yeah, failure is part of the learning process. And if you're uncomfortable failing at something, you can have a really hard time picking up new skills. You have to be patient with yourself and with the process and just a lot of keeping at it. Jonathan: That's useful. I mean, I would say that's kind of, I've only just realized how methods work. And that's just been going through, because a lot of the knowledge that, well, when people talk about stuff, there's so much assumed knowledge when people teach, especially. So, like, suddenly everyone's throwing this word methods around. I'm like, what on earth is a method? Like, what is going on? And it was only through the cohort with Go that I started realizing, oh, methods work in this way. But it was almost like the penny drop, but I had to immerse myself in this environment and this terminology for so long that it kind of seeps in. I'd say that was one of the biggest learnings for me was not to try and learn it all, but just chip away at one simple concept. Because everything interlinks so much that eventually you are able to kind of start stringing the mental model together, which is really important. So that's a great little tool. So I'll let people know about that, that Isaac's recommendation, be patient and be kind to yourself and chip away. That's really cool. Okay. Then the final question I have, and before I let you crack on with the rest of your day, we talked about as a team this concept of the hill that you would die on in tech. That sounds pretty melodramatic and pretty, a lot of drama involved. And the idea is essentially what is the one thing that you believe is absolutely key that you think is like an immovable mindset or perspective to have in tech. So a good example would be, I don't know, on a very trivial level, I always put my functions and then I code my CSS if I'm doing front end. So functionality, then logic, then whatever. It could be, you know, we had one, Rebecca who runs the Unison track. She was like having a genius who's opinionated and tricky to work with. She would rather have 50 people who really love working in a team and solving problems together, than one genius who takes up all the bandwidth in terms of managing. So that was one of her, and I phrased it nicely, but what would be your hill that you would die on in the tech space that is your kind of non-negotiable. Isaac: This is probably extremely heavily influenced from how Google does things. At Google, they have this concept of readability, where code is supposed to be easy to read. And a lot of what I do when I write code, I want my code to be simple to read and understand. And I've seen a lot of code, especially in code, there's a lot of focus on efficiency and benchmarking and making your code faster. And often I'll acknowledge that the way I'm doing it is not necessarily the most efficient, but if I find that the code is easier to read, I would prefer inefficient code that's easy to read over super efficient code. So, like, you know, there's the, it's a common quote, I'm not sure who exactly it's attributed to, that the root of all evil, that premature optimization is the root of all evil. And whenever people are like, oh, how can this be more efficient? I'm like, does it need to be more efficient? Have you ran into, you know, are you running in production and running into issues with efficiency? Is this too slow to use in production? If you haven't actually experienced an issue with the code in production, where it needs to be more efficient, why would you make it more efficient? It's easier to read as is. It's easier to maintain. Other people could understand what's going on. Why would you give away well-written code that's easy to work with and easy to maintain to save some CPU cycle? Is electricity cheap enough and CPUs are cheap enough that we don't need to optimize code? Just to optimize it. Jonathan: Yeah, it's always funny because it's one of those things I'm like...our program compiled and ran in 30 milliseconds. And they're like, oh, but we made it go down to like 20 milliseconds. I'm like, I could not tell you. I couldn't tell you which was quicker, which was slower. That seems quick. So I think it's a good point. I'm sure I'd enjoy reading your code, but that's great. Isaac, thank you very much for your time, for waking up early and for putting up with load shedding in the Southern Hemisphere. And for me sitting in complete darkness, I'm sure that is probably quite comedy for you. But thank you very much for your time. And I look forward to seeing you on future learning cohorts and in the mentoring streams and all of that. And thank you for all the contribution that you make towards Exercism and across the board. So appreciate it. And yeah, thank you so much again. And I will see you in a second. No, pleasure. Take care, Isaac. Bye. Isaac: Thank you so much again. No pleasure. Take care Isaac.