Chris Keathley
The Elixir Outlaws now have a Patreon. If you’re enjoying the show then please consider throwing a few bucks our way to help us pay for the costs for the show.
Episode Transcript
Amos: Welcome to Elixir Outlaws the hallway track of the Elixir community.
Chris: How is it going?
Amos: Ah, good, good things are crazy busy. Um, I had a great time at, uh, Code BEAM Virtual America last week.
Chris: Virtual America.
Amos: Virtual America, not the real America, but the virtual one.
Chris: Can we just say really quick, uh, conference MVP has gotta be Toucan, right?
Amos: Seriously. Uh, I mean, there were some, some things about the app that I would change, but it made
Chris: Explain this phenomenon to people because I-
Amos: Toucan?
Chris: I heard it, I heard about it. You were explaining it to me. And I was like, this sounds gimmicky as hell. This is going to suck and be janky and not work at all, like, I don't get it.
Amos: And then what did you think?
Chris: But yo, like I kept saying to people like, so like this app is like actually really good, right? Like it was surprising, but I, that I kept saying to people like, so this app is like kind of awesome. Explain what we're talking about.
Amos: Okay, so I think that it brought the hallway track back to remote Meetups or not Meetups, but well, yeah, Meetups too, but conferences, so, okay. Toucan, um, okay, so you, you have Zoom and you can make rooms in Zoom and assign people to them or randomly assign them and things like that. It's kind of like that, except for, you're not randomly assigned and you can see all the other rooms and move from person to person. So you log in and it presents you like your little head is like a floating icon in the middle of the screen and you can see everybody else in the room. And there are the tables,
Chris: And they are also little floating heads.
Amos: They are also a little floating heads. There are tables with topics on them, but you can also just click on a person if they're not at a table and say join and just start like talking, not at a table, just like if you were walking through a hallway or walking around all the tables at a, at a big room at a conference and you know, you like stand by one table and you, you hear that they're talking about some topic and instead this one, you get to see what the topic is. So you can just like, go talk to somebody for a little while and pop over and talk to somebody else for a little while. You can wave at people. You can send them hearts, especially if they're Frank Hunleth, uh, which we, we heart bombed him enough times, it was pretty funny.
Chris: Multiple times throughout the evening, but we, pause. Okay. So what's awesome though, is like you click into, you know, one of these conversations with people and you can, and most people can jump into any conversation and just click on someone else's face. And now you're like talking to them, it just opens up a video chat, but it opens it up in such a way that it's like the canvas just sort of zooms out a little bit and you can still see all the other little groups around hanging out. And so it's like, you know, it just like in the hallway track, if you're like, "Oh look, there's my friends. Hey, you know, I'm going to go say hi to them or whatever real quick, I'll be right back." Like, you can just do that. It's so cool!
Amos: Yeah. It's awesome. Uh, and people do the Irish goodbye too, where they just like, sort of disappear from your group. You're in the middle of talking and then they're gone.
Chris: Yeah, I did that a couple of times.
Amos: I think, I think one of the big things is not just being able to move around and see, which I think is a fan is like hands down has to be there. But the videos, like when you click on a table, they didn't go into like the Zoom mode where everything's a big rectangle and there's a bunch of rectangles on the screen. It, everybody was still a little circle and it brought focus in, on them in the middle of their screen, their face. And there was something about that, like emotionally that said, we're not in Zoom anymore. I'm not looking at the rectangular world that I've gotten used to when talking to my friends. And it also allowed them to like put people in, in different configurations. Like as people add into the room, it would go from like everybody's in a triangle shape to everybody's in a, in a star shape or whatever. And so it looked like people actually moving around and I loved it. I don't know.
Chris: Yeah. I was a large fan of that experience. And I think one of the other key, really key things about it. Unlike Zoom is when you get in a Zoom call with like a hundred people, 150 people, man, no one’s going to say anything except for like jerks like me who, you know, can't go 10 seconds without hearing this out of their own voice. Ya know? It limits the conversations, you're going to have so much. And with this, it's like, if you just wanted to go be with two people, you could just break off and go be with two people. And that was awesome. Like, I don't know. It was like you said, it was the closest thing to a real hallway track that I have experienced and it has a very cool experience. It was a very, very cool experience.
Amos: I love it. I would really like, there's only like two little things is when everybody's joining, when somebody joins, it, like, rings like a doorbell sound.
Chris: Um-hmm. Yeah. Gotta disable that.
Amos: And when, when everything was starting off, it was super annoying. Cause it was like, ding, ding, ding, ding. And then they also appear right in the middle of the screen, which is where your table is. And then they float over top of everybody in your room away. The nice thing is that you get to see people who are coming in and you get to see who they are. And you're like, "Oh, I want, I want to ping them or wave at them," or whatever. The bad thing is is if you're like me, it draws your attention away from the conversation that you're having. And then I would miss what everybody was saying and would have to ask them to repeat. I'd be like, Ugh, sorry. I know you were talking to me, but I missed it.
Chris: Right.
Amos: Floating head!
Chris: Yeah. It's it's overall. It's a very, it's a very cool thing. I dig it a lot. I was, um, it definitely has a couple of like UI thingies, you know, like it has a couple of like little UI quirks that, you know, obviously are not, you know, it's still early days, it seems like for that app, but I'm impressed. Color me impressed.
Amos: I haven't, I'm going to keep a watch on it. We'll see how it goes. I think would be good for remote Meetups. Even like, remote working. If you have a large enough team or a group working on different projects, you could have project tables, but then like people can still go talk to each other.
Chris: Yeah, I was thinking like, even for company events right now and stuff like that, if you like, or having like a, you know, kind of a pseudo virtual happy hour type thing, like be great for that. I don't know. There's a lot of, there's a lot of cool, cool use cases for that thing.
Amos: I have, I have some stuff going on here today, that I might try to get the group to use it.
Chris: That'd be fun.
Amos: See how it goes. What else, what else have you been up to?
Chris: Well, I am day three into my new job.
Amos: Ooh. Yeah, that started Monday. Yeah. Congratulations.
Chris: Yeah, thanks. It's been really interesting. Very fun. Lots to take in. Um, I think people might know this already, but I, um, recently started at Frame.io, joining their backend team there and uh, it's been, um, yeah, it's been really good. There's a, there's a lot going on. Lots of take in. And so just, you know, easing my way in there and starting to look through the code base, starting to get a feel for it, you know, it's like, it's like, that's, I think the most important thing to do when you start at a, at least for me, right? Like after so much consulting, and like, needing to figure out how to get ramped up on a project quickly- and I don't mean in terms of like, just understanding the code, but just understand the context around the code, you develop like tricks, right. To get into a code base really quickly. So I'm just doing a lot of that.
Amos: What are your, uh, top few, few tricks of getting into a codebase?
Chris: Yeah, so I think the most important thing, and I, this is probably just all holdover from being a consultant for so long. I think the most important things are really to get an understanding of the context in which this app was created and is being maintained and still being worked on. And so by that, I mean, all of the things I do are just to get a sense, like, uh, like I, I refer to it as sort of like, you're trying to get, uh, get like determined the gestalt of like the code base, right. You just want to see what the shape of it is. You want to see like who, you know, who's contributing to what and what the, what the major things are, and like how it's moving around in the world and that sort of stuff. And so what I tend to start with, I have a bunch of scripts that I run and then just sort of like some manual work, but I go, one of the first things I do is I look at the top contributors. So I have a script that just dumps out, like, who has the most commits to this repo. And then I take that list and I go cross-reference it in Slack or whatever the like pseudo company directory is. And I see how many of those people still work at the company.
Amos: Oh, interesting. What are you after there?
Chris: I'm trying to see like how much knowledge like walked out of this building. You know what I mean? Like how much, how much, uh, who was the previous owner and what's, you know, like, is that previous owner still here? Are they not? If they're gone, you know, you can start to build an image of like I wonder why they're gone. I wonder, you know, I wonder how things have changed since they wrote this, you know, since that person sort of developed that out, because most of the time there's going to be like, it is often the case that there are one or two people who have all the commits, you know, for a repo, because they were the ones dumping, all of the like generated stuff into there, all the config stuff. So they have just like the most files, you know, added to the thing. And so when you start to look at it like that, they have all the Git blame, just by sheer entropy. But it also is often the case that person's gone , because it's been enough years that like, they're not there anymore.
Amos: Right.
Chris: And so you start to figure out like, well, what stuff has changed since they dumped all this code into this? And since they ran Git in it, you know what I mean?
Amos: Right.
Chris: And that gives you a sense of like, what's going on. I look at things like, what is the most churned file? Meaning what's the file that changes most often. That's a really good indication of things like the, you know, guess what nine times out of 10, you know, what the thing is that changes the most often, it's your user object or, you know, user model or something like that, right. It's whatever the core thing is that, that this app cares about. And now you can start to go look at that file and you can start to say things like, okay, who changes this file the most, right. Is there, is it evenly spread out or is there one person, well, if there's one person that indicates that that person is the most familiar with it and they are naturally self-selecting into changes that adjust this thing. That's an important thing to be aware of. Not for any real reason, not because like, you're going to undermine that or that indicates a problem. Or there's, you know, some amount of shade that needs to be thrown or whatever, but it's just like what, you're just trying to get a sense of it, right. You're trying to get a picture, like a feel of it, so that you can move around in the, in the code base. So you can just understand a little bit more, you know, and you discard the other things that change a lot are like router files and stuff like that. Like these central points. So you discard some of that stuff, but you know, you look at like, what are the things that matter to this application? I'll look at stuff like what CI checks are they running? Like what matters to this team? You know what I mean? Like what kind of things do they enforce and, uh, what are they, what kind of tools are they utilizing to do that? I look at like dependencies and see like what, how many of them are there and how is the, you know, what sort of stuff is being brought in versus what's being probably, which is sort of an, eh, the alternative that it's like, what does it indicate that people are writing themselves? And then I go look at metrics. So I, first of all, it's like, does this application have them? You know what I mean? Does it export metrics in a way that is useful to on-call people? And then I go look-
Amos: -So, so like application metrics, like things that would come from telemetry, not like how many commits are there in a day.
Chris: Right, right. Right. No, no, no, no, no. Like, I mean like, like application level, like health metrics and stuff like that. And I got to see like, okay, well, is there like a Grafana or a Datadog or a LightStep or a Honeycomb or whatever that we're using to track all this stuff. If yes, what kind of stuff are we tracking? What are, what SLOs are there? And if there are just time series metrics, I'll go and start poking around and see like which controller action gets hit the most often? Which waste controller actions are the slowest? Is there a correlation between those two things? Probably not, in most cases, because if they're hit the most often, it means that they have more attention paid to them, in a lot of cases. But again, the, and that gets back to the thing that you saw in the first place, which is like, what files change the most often?
Chris: What things are slow? Is there, is it possible that there is performance issues, right, around stuff that changes more often? Do you what I mean? You get a sense of it. So it's like if all of a sudden you see that users, the thing that changes most often, and also it turns out that the user's controller is the slowest, well, that's really interesting. Not, not , again, not because of any sort of shade or any sort of like, aha, like I've caught you, uh, I've found the problem, you know, you're just trying to, you're just trying to get a sense of, like, the state of the application. So that's, that's like the start of what I, what I do. Like, so that's what I did on day one, after, you know, lots of onboarding stuff. I, and no one like asks me to do this. I just, because it's fun for me. I went and found the repo, like the, the, one of the main repos and started poking around and just seeing like what kind of stuff's there. And, you know,
Amos: I never thought about looking at the top contributors part and whether they're still there. That makes a whole lot of sense though. I guess it also gives you like who you can ask questions to about why decisions were made. And that really handy that context, because I know sometimes I go and I look at code and I'm like, why the hell would you do this? Like, this is crazy. And then I go talk to somebody and find out there's a whole lot of context in there and why they made that decision.
Chris: Right exactly.
Amos: And it might be the best decision. It just might seem weird because I have a lack of knowledge of the system at that point.
Chris: It's almost always because you have a lack of knowledge about the system.
Amos: That's true.
Chris: It is nine times out of ten because you have a lack of knowledge of the system. Very, at least for me, my initial impressions, I do this less now because I've trained myself to not do this as much, as a younger person, my intuitions about what was good design and bad design and good about an app and bad about an app , on first blush, a hundred percent, always wrong. Because it was missing, or at least in the best case, deeply uninformed, because I was missing all of that context, all of this stuff that I'm talking about right now, like I do this because this is crucial for me and my part and my process. Like, I need this to be able to function in the application and like provide good solutions.
Chris:
And that comes from the fact that I got it wrong for years. Like I went into applications and assumed that stuff was bad because it looked bad to me, without understanding any of the context of how this stuff came to be, and you can learn a lot. So for instance, I was, I was working on a consulting project. I did all this same stuff, and I could tell very quickly that two people had worked on this thing. And I could tell very quickly those two people were not there anymore. And hadn't been there for like six months to a year. And at, you know, at least, and there was a lot of like issues on this app. And like people were trying to fix stuff and whatever. And it's like, it became very clear just by looking at this stuff, like you started to get a picture of like, oh, these two people knew everything and then they bounced or they like got quit or they, you know, had a better opportunity come along. Whatever. I mean, again, no shade, I'm not hating on them and why they're not there anymore. It's just, they're not there anymore. So all that knowledge is gone. What idioms are being put in place now, what things are changing now, if you don't have those people who are conveying that vision anymore, how are you maintaining that vision? How are you maintaining your idioms? How are you maintaining all of this consistency in your application? Are you,? And it becomes really, it becomes really apparent the context in which this application was built and the context is being maintained now. And that helps you tailor your view of it and your solutions that you're going to provide. I think.
Amos: How, how does that, that past context, when you run into something like that, where you have, you know, two people wrote a lot of the application and then they're gone. How does, how does that change your approach to the application?
Chris: A lot. Because it changes it pretty substantially because if let's say those two people are there, then you need to be willing to work within those idioms a whole lot more because they're the ones who built them and thus they're going to enforce them because they're there. So let's say you do disagree with an idiom that has been put in place and you want, and you believe that there is a way to build a simpler version of the thing. Uh, barring, you know, a lot of like, barring the sort of obvious presumptions inherent in that concept, like, that, you know, better than somebody who worked on this thing for years, you know, you start to get a sense of like, how much am I going to need to play within the rules set by a defacto leader, right? Like whoever is the top contributor is almost certainly, probably, also setting a lot of those idioms in place. And they're probably enforcing them.
Chris: And so you're going to have to play within that system a lot more. If those people are gone, you can start to figure out why they're gone. Are they gone because, you know, like they just got bored and wanted to move on to the next thing, which is fine. Well, like maybe those idioms don't make sense anymore. Maybe the business requirements have changed in the past, in the proceeding six months. And yeah, that design pattern doesn't make as much sense at this point. And so you didn't get a sense of like talking, it, it changes the way that you frame a lot of your conversations, the way that you talk to the, the remaining engineers, like, Hey, like what do you think is the thing that needs to be worked on the most? Like what is causing you the most pain? Okay. Interesting. Like that gives you a sense of it.
Chris: And they're going to be much more and, you know, ahead of time, they're going to be much more open to talking about changing certain things, because the person who enforced a lot of those idioms is now gone. Or, you know, simultaneously they might be more beholden to it because they like, they're like, well, this person was really smart and I want to defend their vision or something like that. You know, you just don't know. So yeah. So all of that stuff is what I mean by like, it just colors the way that you have these conversations and conversations are key when it comes to getting ramped up on a project. Asking a lot of questions and like actually listening to the real answers is a, is a major part of ramping up on a project and doing good work quickly. Like it's not useful to just jump in and start committing code.
Amos: So, when you say doing good work quickly, like what is, what is your timeframe before you start to get like, "Crud, I should have, I should have contributed something already."
Chris: So I used to be real bullish on this idea that like I wanted to fix or get involved in, that I wanted to ship something on day one. Like I wanted to, like, check out the code and get it running and, like make a commit, like day one. I used to be like, cause I think I heard GitHub say that. And I was really enamored with that way of working for a long time. And as I've gotten older, I have put those sorts of things farther and farther aside. And now I'm like, it's, it's longer. It's like, I would say, it's measured more in like weeks. Like you should really get in and learn stuff and really understand what it is you're working on. I mean, bugs are different, right? Cause a lot that happens a lot, right. You get handed a bug like in your first week or something like that, Hey, like go track this down and it's gonna teach you a lot about the code base or whatever. And it's, I think those are useful exercises. I don't, I don't disparage that idea. For me personally, I find there to be a lot of value in taking the time necessary to sit back and sort of just listen a lot before I start talking, uh, at a new company. Which is interesting because it's often the opposite of what that new company wants you to do. Like that, I've also discovered that. It's like, they want you to provide suggestions and that sort of stuff. But I find that to be very difficult for me to do, uh, without the context and without the understand and honestly, without understanding what the team is comfortable with. Like it does you no good to go into a new application and start talking about distributed Erlang and how you can use consistent hashing to do blah, blah, blah, if the team has no context of what those words mean. That is not useful.
Chris: And so it's like a thing that you could suggest, and it might, and you might be right, but it is not helpful in that context of a new team because they, they're not comfortable with it. And they're, and you don't know that yet. So there's a lot of give and take there. Like you want to sort of just ask a lot of questions and you don't want to ask them leading, you want to ask a lot of legitimate questions, you know,. You don't want to be that guy. Uh, cause it's always a guy, who goes in there and says like, you know, "Why aren't we using Dialyzer on all these files?" It's like, well, like, I don't know don't, with the implicated, the subtle implication that you're doing it wrong, right. I think you just go in and like legitimately ask a lot of questions and, and actually listen to the answers. Don't just listen for what you want to hear, but listen to what it is they're saying and try to pick up, like, what is the context that these decisions were made in? Oh, it was it, you, it turns out that, uh, we made that decision when there was three people on the team and we basically didn't have to talk that much because we could all share a vision. Okay, cool. Have we, you know, have we considered changing that? Or has, has anybody rethought that since then? Oh no, because no, one's had time and like we've just grown too quickly. Okay. What do you, I mean, is this where you want to be in the future? Like, what do you want to do in the future? Like, you know, like, I don't know. Y'all have been working on this. You tell me. So. And actually, listen and be respectful of like the idioms that they're putting in place.
Amos: Are there any, any questions that you always generally ask?
Chris: Uh, I'm trying to think. That's a good question. I don't know if there are, um, yeah, I don't know if there are. Uh, I just tend to poke around a little bit, you know, and, and get a sense. And I ask a lot of stuff, these days, I ask a lot more operational stuff, you know, where do, how do you get logs? How do you, how do you get time series? How do you get blah, blah, blah. Like, how do you get APM? Does, does, does this app have APM? Do people normally remote into the box and start using Greek entrees to poke around? Like what, you know, how does a debugging work? How does on-call work? I asked a lot of those sorts of things and that again also provides a lot of insight into the, in the system.
Amos: Yeah. I, I think that, that, "How does on-call work?" is pretty interesting question and it's not one that I frequently ask out of the gate, but it, I think that provides a whole lot of context of what's going on in the company. And you know, if everybody's on call, there's a lot of follow-up questions to that. Like "How often do you get called when you're on call?" That's a good one. I, I typically try to ask people too, like, "What do you love most about working on this? Like what part of the codebase are you most proud of as a team?" And then like what, what's the, what's the part of the code base that you're like, “Oh crap. I gotta go change that. I don't want to go over there." Which I think might have a tendency to, to be the ones that churn a lot, are probably the ones that you don't want to work on. But anyway,
Chris: Yeah, I think that's, that's the thing is like, if you can go into those conversations too, with a lot of the stuff that, it'll often be that like, what's the most painful thing. It's like, oh, it's this, it's this one file that needs to change all the time. And you're like, if you can go in there already sort of having seen that that's useful, right? Cause you can start to like piece together, this sort of stuff, which is really interesting.
Amos: So it sounds like you're just trying to get the whole, like the story of the code, the life of the code, like as close to beginning to end as you can.
Chris: I mean, this is like also artsy and sort of poetical or philosophical or something like that. But I don't know, you really are like, you're sitting in the cave and you're just trying to understand the shadows. You know what I mean? Like you're, you're trying to just, you're trying to understand the shape. Like how does it feel? Like when you hold it in your hands, you know, what's it look like to you? Like what, you know, like all of that sort of artsy stuff. That's why this stuff is so hard. It's like, it's why this stuff is, is it's not a science in that way, right? It's like, you're just trying to understand that like the sense of it.
Amos: Right. There's a lot. And there are so many angles, right? If you and I both went in, we could ask the same questions and look at these same things and we're going to end up with thinking very different things about the object.
Chris: Yeah, with different impressions of it. Probably largely because we have different design ethos, you know, we have different design aesthetics and things that we care about. And things that look and indicate warning and danger to you may not be the same for me, just because we have different life experience. We have different sensibilities about stuff and we've had different like experiences with, uh, errors. It's like, it's like the first time you see a Yoda conditional, you see somebody type, you see your pair type a Yoda conditional. And you're like,, "What in the world are you doing? Like, why are you doing it that way? That is jank. What are you doing?" And then you realize, uh, that it's because after years of programming C and being bit by not accidentally forgetting to type a second equal sign, does everybody know what a Yoda, Do you know what a Yoda conditional is? Sorry, I'm realizing I'm using a very obscure reference.
Amos: Uh, I, I've heard of this before, but it's, it's where you put the value that you're trying to say is equal before-
Chris: Yes.
Amos: So that you're not like checking a quality of an assignment instead.
Chris: Yeah. So if you want to, so in, so if you're doing an if statement and let's say you have a variable, a number, and you're trying to say, "if this variable is equal to three" you will write that as " if three equal equal," like, you know, equal sign, equal sign, number, as opposed to if number equal sign equal sign three. Because it avoids the bug where you forget one equal sign. Because in C and C++, this that's valid syntax to do an assignment and an if statement. It solves that bug, it prevents that bug from, from occurring because you can't assign to a literal.
Amos: I have holdover of that, I think too, I often do the same thing in Elixir even that doesn't matter. I will do, like if I, if I, in an assertion, in a test, I will say assert some hard-coded value equals-
Chris: Oh, sure, sure.
Amos: Some called out value.
Chris: But I think the interesting thing there too, is that like, if you are a, like, you know, OG, only runs on metal C programmer, and you see a bunch of conditionals that don't do it that way, that's a red flag to you. Because you're like, "Oh no. Well, who knows what could be in here? Look at the sloppiness," you know, like or whatever.
Amos: I can't trust anything.
Chris: But like, I would not, like I wrote C for a long time and still don't do that. You know what I mean? I look, I look at code that does that and I do not think that it is bad. Um, partially because you know, we work in languages where that's not even allowed. It's like not even a semantically, correct thing to say, but also because I just think that, you know, your sensibilities about that stuff are different. And, and that's what, that's really what I mean by like the stuff that seems like warning signs to you are different than what they are to me because our, we have completely different life experience, you know.
Amos: And all those warning signs come from failures that we've seen. I think that's why building software as a team is really important is because like, if you and I have both seen different problems in the past, then when we're working on a solution together, we avoid both of those sets of problems. Probably create brand new ones, but we avoid those, those problems that we've, we've both had in the past.
Chris: So that's, that's the main, I don't know. That's all the stuff that I think you do when you're starting a new thing, is like you start to figure out that history and that story because I don't know that you can make, I'll say it this way. I'll say it this way. It's been my experience that, uh, you will, you will provide much worse solutions and you will, uh, whatever the opposite of engender goodwill, you know, you'll, you will, it will take you longer to get involved with that team and, and start to build relationships with that team, if you lead in with a whole bunch of, you know, here's a bunch of ticky things that I found that don't make sense to me that I think are bad. Because they, because they don't, because they offend my personal sensibilities. And if you try to get in there and start writing code too quickly, that's, uh, has, it can be net negative for your, uh, for, for you getting ramped up and involved in that team. That's been my experience. So take your time and sit there and try to learn it.
Amos: Don't come in like Godzilla or.
Chris: Yeah, like sitand like, and, and, and definitely like, I don't know, like you can use like, like what I'm talking about, these scripts and tools and stuff. Like, that's all useful stuff to figure out, to get a sense of the thing. But, you know, really just sit there and listen, and I don't know, take your time before you just start jamming, you know, features.
Amos: You don't like jamming features?
Chris: I like jamming features. I like jamming features, but man, like, you know, you don't want to go off in the wrong direction either.
Amos: So I, I often still feel that, uh, that drive to try to commit something in the first day or two, but also like you, like, I try to hold off. Because, and that's the hard thing to fight, is that, like, desire to feel like you're contributing instead of just sponging.
Chris: Oh yeah, absolutely.
Amos: I don't want, I don't want to soak up the water. I wanna, I wanna clean the desk, right? Like, I don't know.
Chris: No, a hundred percent.
Amos: I have a tendency to try to do things that aren't production when that happens, just to calm myself. So I'll go in and find something that seems, that is seemingly important, but maybe not tested. And I might throw a test in , just cause like, it, it allows me to feel like, okay, I've done something now I can, now I can relax.
Chris: And its calming.
Amos: Yeah. And focus on, on like figuring out what's going on. And what's important. And sometimes writing that test is exploratory enough that it also gives me another facet of the whole thing that I don't get from just looking at stuff.
Chris: Um-hmm. Um-hmm. Yeah. I, yeah. And I definitely feel that as well of like, I really want to do something. It'd be nice to do something useful. But I think, yeah, especially you're, especially if you're not connect, eh, I'll say that that drive comes out more in a consulting scenario because you are being sort of paid by the hour and you're there to provide insights as quickly as possible. If you're joining like a product company, you're going to be there for a long time, you have a lot of time, you know, you have, you have, you have a week.
Amos: (laughing) It's okay.
Chris: Yeah. You have at least a week. It's just, you know, don't, don't stress.
Amos: Well and your first week, a lot of times coming in as a, you're going to be setting up all kinds- you're learning about company culture and setting up systems.
Chris: Yeah, exactly.
Amos: And sometimes they have you filling out lots of paperwork. Like that first week has already got too much on your plate. You probably, probably really shouldn't be writing too much code, I think, in that first week. It seems irresponsible with all the other things that often come with starting a new job.
Chris: Exactly. Well, and just easing into it is good. So. That's my take. That's all I have.
Amos: It's all you got.
Chris: I think we keep this one bright and tight.
Amos: Yeah. I think this is good. I, uh, I enjoy this and I'm, I'm starting a new greenfield project, which is different. Um, we're about three weeks in now. And uh, so now you got me thinking like when somebody is coming in and they're looking at it, all of this, how can I make sure that I'm con- I often think of how can I convey information to the future, so. So maybe, maybe that's a talk for the future.
Chris: Yeah. Absolutely.
Amos: Cool. Well, You have a wonderful day, sir. Don't yawn too loud. I hope you get, get to catch up on some sleep.
Chris: Thank you. I appreciate that.
Amos: Okay. See ya.