Today is a special episode of Developer Tea. A few weeks ago, I had the pleasure of joining the guys from Soft Skills Engineering on their podcast and they aired this episode on their feed. And we're going to air it here on Developer Tea. I really enjoyed our conversations and we talked about all kinds of questions like, for example, looking for a job when you already have a job, is that okay to do? You know, what are the different scenarios that might play out? And so really excited about this discussion that I've had with Dave and Jameson had a blast. If you want to hear more of the Soft Skills Engineering podcast, look for Soft Skills Engineering in whatever podcasting app you use and go ahead and subscribe. This quick note to this episode is very different from our average episode of Developer Tea. It's in a question, answer format. And the editing is a little bit different. My voice sounds a little bit different than it normally does. So hopefully it doesn't catch you off guard and hopefully you enjoy this episode. Of course, the purpose, as always, of the show is to help driven developers like you find clarity, perspective, and purpose in your career. And I believe this episode will help you do that. So let's get straight into the special bonus episode, the cross-posted episode of Soft Skills Engineering and Developer Tea. It takes more than reading yet another Monad tutorial, hoping that this time it'll finally make sense to be a great software engineer. This is episode 144 of the Soft Skills Engineering podcast and I'm your host, Jameson Dance. I'm your host, Dave Smith. Dave, did you read a Monad tutorial? And it was really funny and that's why you're laughing because it's full of jokes. I know. No programming crowd, they just love their comedy. You can make some pretty epic puns with category theory. That's what I found out. We have a special guest today. Do you want to introduce them, Dave? Yeah, sure. So joining us today is the host of the Developer Teapodcast named Jonathan Cutrell. Welcome, Jonathan. Thank you so much. I appreciate you guys. Let me join you here on the show. Happy to have you. Yeah. I'm excited for a couple of reasons. We have some overlap and interest. Soft Skills is something that we talk about a lot on Developer Tea. But yeah, I'm very excited. I'm excited to get into questions and try a different show format for once. I feel like I'm on my show. I'm doing a lot of kind of, you know, God voice in the sky telling everyone how to be. And this is going to be a little different. So I'm excited about it. Yeah, we're kind of the opposite. It's like a voice from underneath telling you what not to be. You get devil on the shoulder kind of thing. Yeah. Yeah. It's worth it. You just quit. Just quit your job. Every problem just quit. Leave a trail of quit it. Quit jobs behind you. It's kind of the fall back advice at the very end, right? Oh, yeah. It's actually not the fall back. That's the primary. Well, first have you tried unplugging your job? Yes, exactly. Turn it off and back on again. Hello, soft skills podcast. Have you tried turning your job off and back on again? All right. I think we have some patrons to thank this month. Thank you to Chris Hogan, the agile ventures charity Zach Grannon, David Jackson, Sean Clayton, Nick Cantar and Sonic the Hedgehog. Bringing up the rear. Thank you to those folks for contributing at the level where we say their name or their made up name or maybe their real name every episode. And thank you to everyone else who is contributing or has contributed. If you want to help out, then you can go to soft skills.audi and click support us on Patreon. Let's dive into our questions. Okay. I'll read our first question. This is from a listener named Andrew. I have been job hunting while employed. Gasp. And have a number of opportunities that have advanced to the in person interview. Most of the requests I've seen said there'll be four to five hours in the office, which seems fairly typical. The problem is I don't have unlimited vacation and I feel dishonest taking so many days off. How can I navigate new opportunities without disrespecting them or completely failing in my current responsibilities? Hmm. See this is an example of a problem that would be solved a few quits. Well, can I jump in here? Oh, yeah. I think the first thing we need to address is the stigma of looking for a job while you have a job and the negative stigma there. It's really a bad idea to quit before you look for a bunch of... I'm highly opinionated about that. But if you quit before you start looking and you, for example, if you don't have much of savings, then your hunt is going to be so drastically affected by that time, like the clock that you started time. I'm not sure. Yeah, absolutely. So you're very likely to get into another job that you hate and that cycle will never stop if you keep on saying, well, you know, I have to quit before you're done. Or even submit a resume somewhere. You described my previous four job searches, basically. I don't want to work here anymore. And then I get home and then I'm like, well, I guess I need a new job now. I didn't quite think that was true. What job is closest to my face right now? Yeah, I think that's a good point. Don't quit your job. That was tongue in cheek advice. But how do you deal with this conflict? Do you just get sick a lot? Unlimited vacation or don't have unlimited vacation. Sounds like it's possible they've already used all their vacation to not just that they don't want to use it on us. Yeah. So how do you handle this without just mysteriously disappearing? It also probably depends on if you're, are you determined to leave your job and you're just looking for the next thing? Are you exploring other options? Yeah. So it's like you might approach it differently. I mean, one thing you could do is you could strategically time your job hunt so that it happens during a high concentration of company holidays. To like Christmas day, you know, New Year's day. These are good interview days. Yeah. Classic in your few days. How was Christmas? Well, you know, I interviewed at three companies. Spend a day getting to know new people, made some new friends, was offered a 10% raise to work. I would enjoy more. I think another strategy you can use here is to talk to the companies that you're interested in and let them know kind of the situation that you're in because it's possible. For example, that they would plan a late Friday or something to interview and to interview you in person or even, you know, I've even had companies that will do, you know, not in office until we're well into the late stages of the interview. But the idea is like, if you let them know, hey, I don't want to disrespect that the company that I'm at now, then that shows that you're not going to continue a pattern of disrespect when you get to their company, right? They would want the same respect of, you know, you not leaving work for supposedly, totally, you know, above board reasons and then suddenly quitting. That's, they wouldn't want you to do that for them either. Yeah. Yeah, for sure. Yeah. I also feel like that they already have demonstrated some interest in you if they're trying to bring you in for an interview. So I'm trying to think of what I would do in this situation and we, I just went through some interviews trying to find a candidate and we were very flexible with people's timeline and schedules because we wanted to talk to them. We're remote, so it's a little bit of a different setup, but I still feel like they've demonstrated some interest in you and you're almost giving them a chance to like commit to you a little bit more. I feel like you would work out well if they put in some effort to make it work for your schedule there. There might be some, some like we've invested in this person. Yeah. Feelings associated with that. I think as a candidate, you have to be pretty selective at this point. Like if you're willing to say yes to any on-site interview, even the ones that are a bit of a stretch or maybe they don't interest you that much, you could end up burning a lot of your work time by doing that. And if you're willing to do like 10 different companies, interviews with 10 different companies, you're going to get stuck I think in this situation. And so I like to spread them out. You know, it's like take your time, only go on-site to the ones that you're pretty confident and serious with and don't get into a situation where okay, I've done 10 interviews now. I'm sure this 11th one will be great because I mean, that can look pretty bad. I've done this where I've interviewed for other companies, but I've never done like 10 in a month. You know, I've done maybe three in a month or something. And then it's usually easy enough to stagger it out and disappear for an afternoon without it causing a lot of raised eyebrows. Yeah. You could also, you know, it depends on what company, what your company policies are. And, you know, do you have in office time that's required, you have certain core hours, for example, that are required for an overlap or something like that. If you don't have those things, then it's possible to do, you know, fulfill your current responsibilities in the evenings or even over the weekends when you otherwise wouldn't be able to do those interviews. Right? So if you go to an interview on a Monday morning, then you could work that evening. Again, that depends on a lot of other things lining up, of course, but, you know, don't think about your current job as the most static thing. Think about the interviews as the most static thing and see how that changes, you know, the way that you're planning. Yeah, for sure. And I think, I think it's not unfair to say that most developer jobs allow that level of flexibility. It's one of the perks of the industry. Yeah. Yeah. Yeah. Have we answered the question? It feels like you've all given some good suggestions. Yeah. I mean, I don't want to discount the last phrase here in this question too much, which is, how can I navigate new opportunities without completely failing in my current responsibilities? You know, complete failure is on the table. If you are willing to take that, I personally... You're saying like just completely fail. I mean, you know, we've been, to this point, we've been very respectful and careful and whatnot, but kind of half tongue in cheek. It is going to distract you to go interview at other companies. And so I think there's a certain amount of failure or at least like performance reduction that you need to be willing to accept. If you're going to go and spend 20 hours in a month interviewing at other companies. I would also say there's a... You know, let's say you have three really promising opportunities on the table. At some point, you could kind of roll the dice and go ahead and tell your employer. And it's possible if you've developed a positive relationship with your manager or, you know, if you have been loyal to that company up until that point, you're being honest with them, you know, it's possible that they'll let you go and do these... You know, it's normal to change jobs. It's also possible that they'll cut you right then and there. But if you have those three promising opportunities, you know, you kind of run the odd scenarios here and say, okay, you know, what are the odds that I'm going to truly be out of a job for a significant period of time? And if you're going to do this, then I recommend having, you know, maybe a month, at least a month of your current salary saved up if you can swing that. So what's the benefit for telling your current employer just to get more flexibility to go interview or to try and see if they can resolve concerns that are making you interview in the first place? Like, what do you hope to gain out of that? Yeah, so your current employer will probably, if they're smart, they will probably try to keep you. And you probably shouldn't stay after your employer has tried to keep you upon threatening to quit. That's not good negotiation strategy. If you went to them and asked for them, asked for those things before and they said, no, and then you threatened to quit and they said, yes, that's not a good relationship, right? So the thing that you gain here is the flexibility of not having to walk around and you also are less likely to burn bridges if they were to find out behind your back, right? So you're like, you're kind of bringing everything above board. There's also an expectation that you're not going to tell them until you have an offer in hand, right? So that's kind of the industry way of handling these things. You are expected to look for other jobs on a regular basis. The best time to look for another job is while you have your current one. I feel strongly about this after looking for jobs. After having gone through this experience and watching other people feel like they couldn't leave the company until they had a job, I really do believe that it's all about trying to figure out, what level of safety do I need? To feel comfortable. So if that safety is all about the money, then save up some money. And then quitting becomes an option. Being fired becomes an option as well. Oh, that's an option. We haven't really explored. If you completely fail and get fired, oftentimes that comes with severance. Yeah, maybe a big black mark on your resume, but hey, you get that month of savings automatic. Yeah. Well, it is actually strategy. You know, I mean, some people actually get by. I personally would never do that. I worked at a dry cleaner in high school with a boss who took that strategy. She decided to get fired and the way that she did it was by just sitting in the counter and smoking cigarettes when customers came in and ignoring them, just like sitting there, smoking her cigarettes while people were trying to get her attention for a couple hours. How long did she pull that off before it's been fired? It was, I think it was a few days. Oh, that's great. Oh, that's great. Concerted effort to get fired and it succeeded. Are you privy to the details of the severance package? I'm pretty sure, I mean, it was a dry cleaner. So I'm pretty sure the severance package was now you qualify for unemployment. Oh, I see. But I'm trying to think of what the equivalent of that in developer worlds would be. Would it just be like, I don't know, commenting on all pull request reviews with a single thumbs down, just ignoring all follow up and just see how long you can do that? Change me. Maybe truncating your production database tables repeatedly. Yeah. Run all your local migrations on the production database. Yeah. And then I mean, there's this culture of blameless post mortems. So you'll probably have to do it several times. Yeah. Because the first time you'll uncover some organizational misses and then they'll put in all these safeguards. And then you'll know what all the safeguards are because you're in the post mortemeed seat. Then you'll get a raise. Yeah. Yeah. Look, you've made our culture better. It's hard to blow a prod. And you're like, not too hard though. Not hard at all. All right. I think with that we've answered the question. All right. No more light can be shot on this. Okay. I'll read the next one here. Okay. This one comes from a listener named Chris. Chris says, hey guys, great show though I think as with all shows it could probably use more discussion of badgers. Yes, I said badgers. All right, Chris. That's interesting taste. Yeah. Okay. We'll take it under advisement. Yes. Chris goes on to say, I'm about to start a new job. I took the time honored and hallowed show advice though I'm leaving on great terms with my old job. Apparently didn't take our most recent advice. And we'll be coming in as the fanciest of newly invented titles in software, staff, software, engineer. This is only the third time I've started a new job, not counting odd jobs in high school and college. And I've never stepped into a leadership role before. What are the most helpful things you've done or seen other engineers do when joining a team in a technical leadership role? Thanks. Oh, Chris. It's a question. Time to sit on the throne of the staff software engineer. You bring me coffee. You turn up the heat in this building. Is that what senior engineers do? Oh no, senior engineers are the ones running and getting the coffee. Staff software. No, that's what I'm saying. Yeah. So as a staff software engineer, your coffee fetters are the senior engineers that we're saying. Exactly. That's just being explicit about the latter. So I think the world they're talking about has a ladder that looks like junior, regular type engineer, medium, not senior, not senior or junior. Yeah. Senior. And then staff is usually the next level above senior. Similar to I think it's kind of similar to principal maybe. Yeah, some companies go from senior to principal. Some go senior staff principal. Yeah, my company's principal is above staff, but I don't know. It's the Wild West out there. Yeah. And principal could be your coffee fetcher. Yeah. Yeah. Oh, good question though, right? And the interesting thing about this is it's not a management role or usually it's not. It's a purely technical seniority role. So you're not coming in to run the team necessarily, but you are coming in to make a bigger technical contribution. So there is some technical, I guess that's the difference between the leadership part and the management part. You're not necessarily just managing, but you are expected to lead. Yeah, I agree. And I'm not interpreting the question here is we're not talking about people management, but there is technical leadership, which is a whole other ball of wax. I have stepped into leadership roles at three or four companies now. Most of them I have come in as a non-leader and then grown into the leadership role, which is a much more comfortable transition, I think. But in one case, I stepped straight into a technical leadership role and it's a lot harder because there's so much context you don't have. Yeah. So I think this is like the most challenging way to do it right here. I feel like an easy mistake you could make is just come and bring all of your good staff software engineer brain and just know everything already as of your position. And like Dave said, there's a ton of context that you don't know. I feel like you have to kind of sit back and uncover the problems that exist instead of just show up and say like I was hired to switch everything to Postgres because Postgres is my true love. Yeah. I think that's good advice for pretty much all developers really is maybe start whenever you have the kind of the urge to share your opinion, make sure you've listened first. Very often somebody else has something to say that will either adjust your opinion or make your opinion not necessary. Even though your entire job is to come in and lead like your opinions are going to be important, but the problem is your opinions are only as worthwhile as they are heard. And so if people can't hear what you have to say and it doesn't matter how good you are, it doesn't matter what your experience is, people are discarding what you say, then it becomes useless. So maybe you're saying like talk a little louder, maybe like some shouting. Can you hear me? Yeah. Postgres, I think that's really good advice and I think it's more important than more senior your role is because your uninformed opinions can do more damage because you have people for better or for worse people will listen to you more because of the position. And if you don't understand the scope of the problem that you're trying to solve, not even the scope, just what the problem is that you're trying to solve. It's possible you will lead people down the wrong path by just talking before you know what you're talking about. Yeah. And when I joined my current company, I came in as a senior role, which in my company basically means technical lead. And the team I joined, this is context I didn't know, but prior to my joining, they didn't have anyone who is officially designated as the technical lead. And so one of the challenges that they had had was that they didn't have someone to be like a tiebreaker or an authority to be able to say, yeah, we're going to do that. That sounds great. Let's do it. And so there was kind of like a lot of discussions would just end with shrugs, you know, like I don't know, like they just didn't really have a clear path forward a lot of times. So when I showed up, they started asking me my opinion. And I was very much in this humble role like, no, no, I am here to learn from you. And I didn't even realize I was actually breaking ties and causing this log jam to flow just by saying, yeah, that sounds great. You know, and then like months later, someone came to me and they're like, the team has been so much better with you here. And I'm like, why? What? What happened? That's great. You give us clear direction and I'm like, uh, direction. I thought I was just saying like, I like that idea. But they, they loved it. It gave them something tangible to latch onto and run with. And it made a huge difference for the team dynamic. But again, that's context I didn't have because I just wasn't there to experience the like lack of direction before I showed up. Yeah. I think to talk more about the specifics of the staff software engineer role, one way I've heard it described is the higher up the engineering ladder you get, the more you're supposed to be defining the technical problems, not just solving the technical problems. So you're expected to be identifying things that you could then produce solutions for where that's a role you might not have as much, maybe lower down on the ladder. You're kind of just fixing problems that other people have identified. And that's, that gets into listening even more where you have to find pain either. Customer pain or technical pain or, or, or some kind of pain to solve. And if you can't find it, you got to create it. Oh, it's there. It's there. Don't worry. I think there's a word of caution for all leadership and I learned this the hard way. So your words last longer, the higher you are on the leadership change. They're change. So and it's kind of like take your words and imagine saying them a hundred times when you're in leadership because they're going to be repeated number one. So they actually end up being said a hundred times. And secondly, people are going to, you know, the natural way that we see each other is through a static and very seldomly updated picture, especially if we have less interaction. And if you are in a leadership role, often you're going to have less interaction with teammates, then they will have with each other, right? So so the perspective that we have of other people is difficult to update. And so if you say something that, you know, maybe is kind of a soft opinion of yours, like you don't really have a strong opinion about something, but you say it as if you do. Maybe you read something that has convinced you, but it's really something that you're holding loosely, right? The whole strong opinion tell loosely thing. Well, the problem is that you get three weeks or even three months down the road and that's become, you know, part of the engineering standard at that company. And it's because somebody said something and that somebody was you and because you have some level of authority, very few people want to go against that. So the point being, you know, as you kind of grow up that chain, the things that you say tend to matter more and people will tend to repeat them more. Absolutely. And I would say that in exactly that spirit, you must learn to communicate in verbal and written form so that you can't be misunderstood. It's very easy to say something and have different folks interpret it differently based on context that they bring. And so it's just as important to say what you want as it is to say this is, and sorry, it's just as important to say what you want as it is to say what you don't mean. In other words, like I saying this, I want you to do this. I don't want you to do this, this or this. No. Yeah. Things that could be conflated with each other. And to add to that, you know, don't forget that even in technical leadership that people are going to feel whatever it is that you say that there's a lot of emotion attached to even technical decisions. And that's something that this title distinction that we've talked about a few times, you're not exempt from those kind of emotional connections with the people that you're leading, right? Even though you're not managing people, the decisions that you make and even the kind of feedback that you give, there are ways to give it where people feel, you know, disperaged. They feel like they don't want to work with you, right? There are ways that you can come across that ultimately drive people away and drive them apart. Or in with the same decisions, you can communicate them differently, the same opinions you can communicate them differently and bring those people closer or make them feel safer. To work with you. I like what you said earlier, Jonathan, about how your words get repeated. And I think one way to maybe acknowledge that or even combat it. So they could get repeated and maybe distorted or misunderstood a little bit. I feel like you have to repeat yourself a little bit more because of this communication gap where you're not spending as much time with each individual person. So and that gets back to being explicit, like what they've said about, being explicit about what you mean and what you don't mean. I feel like I often find myself saying, feeling like I'm saying the same thing, but people feel like they're hearing it for the first time. Oh, yeah. For the first few times it happened, I was like, what is wrong with either me or you? And then I just realized it's, I don't know, everyone comes to a conversation with different context and it just takes a while to get messages across people's communication styles and everyone has a lot on their plate. It takes a while. So I think repeating yourself on core important things is pretty valuable. And on that note, one way to make sure that you automatically repeat yourself in a scalable way is to write. And a lot of times it's easier. I thought you were going to say robo calls because I just listened to a podcast about the cries of the robo call epidemic. That's a great idea. But it'd be robo slack. Oh, yeah. Okay. So like every time you put a slack message in, it repeats your same message in 30 minutes, several days. Okay. That's your everyone's season. No, but seriously, like I think writing documentation about your vision and direction can serve as a reference for people and that people can share that. And so it's like, it's less likely to get distorted telephone game style if it's written down from you from yourself, you know, rather than being relayed like through oral tradition, you know, it becomes mythology or something. Yeah. Sure. Yeah, it becomes less rhetorical, right? You don't end up parsing words. It's more, there's a different kind of authority towards that are written down on screen. That's kind of a weird thing. I know. Anyway, you mean with a sharp, you're taking down record. Yeah, exactly. Just go around to each of your, get that with your screens and write on there. It has a lot of authority. I mean, that's like hard to erase. Yeah. No, but it is true that we, we parsed. The spoken word is very different. And for a bunch of reasons, you know, one being that when we hear other people's voices, our brains are totally parsing that differently than when we're reading. We're creating the voice when we read, right? So there's kind of like this, this sense that we actually kind of want to believe what we're reading. And so we create a little bit more of an acceptable voice. And when we're listening to other people, all of our kind of reptile stuff is happening, right? Our lizard responses to competition, for example, are also firing at the same time. And so it's a little bit different than when you're reading something. When I read what Dave writes, I hear it in a British accent. She still like you. And so I believe it more. That was going to say the same thing about you. Oh my gosh. Oh my gosh. Oh my gosh. We're destined. We're waiting for it, wait for it. Oh my gosh. Perfect. Okay. We both read each other's voice in a written. No, I did a slight amendment. I was going to say that when I read your words, I hear Kermit the Frog's voice, but whatever. You know? Oh, okay. I hear it with like some reverb. So it sounds like you're speaking in a large auditorium. Just really trustworthy. But but warm too at the same time. Not like dictator style. Okay. How as a new lead? How do you earn the trust of your team? You can't just come right in and start throwing out edicts and proclamations and expect them to be honored. You have to earn that. How do you do it? I show them my Twitter account and say, look how many tweets I have. I tweet a lot. Look how many memes I've retweeted. Yeah. It's good. So turn that around and think about yourself and why you would trust. Think about the people that you trust. And imagine the moments or like the experiences that you've had with those people that have either instilled that trust or you know, have just made them likeable. Like language is hard because we use these words to categorize all of these various feelings that we have. The feeling of trust is very close to and probably often synonymous with the feeling of liking. You know, affinity. It's difficult to have an affinity to somebody and simultaneously distrust them. So I would say, you know, a lot of that is as simple as people just enjoying being around you, not being difficult to be around. So like lots of hugs, lots of tuff. That's it. No, I think like for example, being helpful, it sounds so simple and unfortunately it's actually not simple at all. But being helpful to another person is, you know, that's one of the best ways to gain trust. But having some kind of hidden motive, you know, where you're obviously, you know, doing something to get on their good side. Like if you're to use a bunch of tricks to try to convince them to like you, people have pretty good, you know, bullshit radars, right? And so they're going to people generally know if you're being genuine or not. I think you could even just come out and say that too. Like I'm new to the team. I want to earn your trust. Here's how I'm going to try and behave to demonstrate that I'm here to help. And just stating that feels like you would help her in some trust right away. But then you do have to act on it too. There's, I think that goes into part of not coming in and just being really heavy handed to. I feel like I would have a hard time trusting someone who just showed up and felt like they had all the answers on the first day because I would be skeptical that they did without understanding what my life is. The people that I trust most in leadership are the people who have demonstrated good judgment. And in order to demonstrate good judgment, you have to actually get your hands dirty and get involved and learn the facts on the ground. You know, I mean, you can only stay in the philosophical realm as a leader so long before you start making bad calls. And so I think one thing I like to do when I join a new team is take on tasks that will get me exposure to ground truth. Usually it's like non-critical path bug fixes or small features or some of the like hard work, not hard, but some of the like more monotonous or frustrating things that other people on the team don't want to take on. Take those on. And if your company will allow it and your business can afford it, take the time to go deep on some of these issues. And then when you come out, you'll be able to speak with more authority and people will trust you because you have first hand experience. I think a lot of leaders, they stay around the perimeter and everything they know about their software or the systems or the infrastructure is all second hand knowledge from stuff they've heard other people tell them. And I just can't think of a worse way to lead a technical team than to have only second hand information. Yeah. Yeah, I think you point, you hit on something really interesting there right in the middle of what you're saying of taking on the tasks that other people either are uncomfortable taking on or they just don't want to take it on. Those could be two different types of tasks. One is kind of the annoying stuff, right? But the other is like, this is dangerous. If I go into this, then I may not come out. You know, like this may be the end. I think that's a really interesting space to work in. Some of the, like if you were to take on the annoying tasks, for example, there's an immediate trust build right off the bat. And then that could be easily forgotten, right? Whereas with the other piece, you know, that you were discussing of really understanding more core ground truth in whatever the software is that working on, that continues to pay back and people will start coming to you to ask questions, right? And that's really, that's where you want to be. You want to be in the place where people view you as a resource rather than just a leader, right? A leader is not really, that's more of a restriction on them until that leader is empowering them in some way and that leadership is providing them with answers to questions they have. My last suggestion is to suggest a rewrite into a different language or plan. Because then you're just dangling this carrot, this promised land of what if all the problems went away and new problems pop up, but you won't know about those until you get into it. So it seems like a good idea. It'll be months. You'll be amongst all problems. Every stand up. Well, repeat yourself, every consistent messaging. You know that bug would never happen if it not in a functional language. And then if you rewrite, so say you're in a dynamic language, you rewrite to a static language, then you have to rail against the overhead of the compiler and how much time it was for sure. Yep, just type check all your code and make the compiler pass. You know, if we could do this in a single line of Python and just like a comprehension and you just cycle up the flip flop of increasing trust. You've been talking about how everything should be a monolith and then talking about how everything should be in containers. Yeah, you know, I think if you just follow the industry, you'll end up there naturally. Cool. Well, have we answered the question? I think so. I think so. Good luck with your first job as a staff software engineer. Enjoy the throne. I recommend getting some padding. They're usually pretty hard sitting on solid gold. The softest battle is still not very soft. It turns out. Yeah. All right. What should people do if they want their own questions answered? Hit us up on softskills.audio and click on ask a question. You can give us as much as little information as you like. Thank you so much. We've been inundated with questions this last week. I don't know what we said or did, but it was probably all those bribes James and offered to get more questions. I think the world just got harder. Just a big wave. Yeah, I've promised up there. More challenges that need answers. Jonathan, how can people find you on the internet? You can find me on Twitter, ad.j.catrall, ad developer.t. You can also find developer.t.spect.fm. And a bunch of other awesome shows over there as well. Thank you so much for joining us. Thank you for letting me take care. See you next week. Thanks so much for listening to today's episode. This bonus episode of developer.t.s where we cross, posted over from softskills engineering. I had such a good time and was really thankful to be on the show and really enjoyed our conversation. I hope you enjoyed it and got some value out of it. And liked the extra variety for today's episode. We'll be back on tomorrow with a new episode of developer.t. If you don't want to miss out on that, make sure you subscribe and whatever podcasting app you use. The one you're using right now is probably a good option. Thanks so much for listening and until next time, enjoy your tea.