Bonus Episode - Soft Skills Engineering Meets Developer Tea
Published 3/26/2019
Today is a special episode of Developer Tea, we're airing an episode in which Jonathan was interviewed by the folks at Soft Skills Engineering podcast. We talk about looking for a job when you already have a job and so much more with Dave and Jameson.
Soft Skills Engineering on the Web
Get in touch
If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea
🧡 Leave a Review
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
🍵 Subscribe to the Tea Break Challenge
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
Transcript (Generated by OpenAI Whisper)
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. 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? What are the different scenarios that might play out? And so I'm 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. Just a quick note, this episode is very different from our average episode of Developer Tea. It's an... It's an episode that's 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 this 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 this special bonus episode, this 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 was just full of jokes. I know. You know, this functional 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 Tea podcast named Jonathan Cottrell. Welcome, Jonathan. Thank you so much. I appreciate you guys letting me join you here on the show. Happy to have you. Yeah. I'm excited for a couple of reasons. We have some overlap in 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 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. The devil on the shoulder kind of thing. Yeah. Yeah. What if you just quit? Just quit your job. Every problem, just quit. Leave a trail of quit jobs behind you. It's kind of the fallback advice at the very end, right? Oh, yeah. And it's actually not the fallback. That's the primary. Well, first, have you tried unplugging your job? Yes. That's 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 Kantar, 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 softskills.audio and click support us on Patreon. Let's dive into our questions. Okay. 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. Hmm. See, this is an example of a problem that would be solved if you quit your job. 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 money, you don't have a bunch of savings, then your hunt is going to be so drastically affected by that time, like the clock that you started. Time pressure. 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 I even submit a resume somewhere. You described my previous four job searches, basically. I'm like, 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, 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? Don't have unlimited vacation. Sounds like it's possible they've already used all their vacation too, not just that they don't want to use it on this. Yeah. So how do you handle this without just mysteriously disappearing? It also probably depends on, are you determined to leave your job and you're just looking for the next thing or are you exploring other options? Yeah. It feels 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. So like Christmas day, New Year's day. These are good interview days. Yeah. Classic interview days. How was Christmas? Well, you know, I interviewed at three companies. Spend the day getting to know new people. Made some new friends. Was offered a 10% raise. Doing 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 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 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, you know, 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 it would work out well if they put in some effort to make it work for your schedule. 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 onsite interview, even the ones that are a bit of a stretch or maybe that don't interest you that much, you could end up burning a lot of your work time by doing that. And if you're, you know, if you're willing to do like 10 different companies, interviews with 10 different companies, you know, 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 onsite to the ones that you're pretty confident and serious with. And don't get into a situation where, okay, I've, I've done 10 interviews now. I'm sure this 11th one will be great because I mean, that can, 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, 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? Do 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, 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, 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, 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, actually. Yeah. Yeah. Yeah. Have we answered the question? It feels like you've, 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, to take that, I personally, you're saying like just completely fail. I mean, you know, we, 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 take. And I think that's something that we're all 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, 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've, 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, of your current salary saved up if you can, 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, 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 a good negotiation strategy. If you went to them and asked for them, ask 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? Yeah. 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, that's kind of the industry way of handling these things. You are expected to tell them, 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. You know, I really do believe that it's all about trying to figure out, you know, what is the, what level of safety do I need to, 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 a, 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 you get that month of savings automatic. Yeah. Well, yeah, it is actually a strategy, you know what I mean? Some people actually get, I personally would never do that. Yeah. 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 was a, I think it was a few days. Wow. She made a great concerted effort to get fired and it succeeded. Are you, 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 don't, 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. Maybe truncating your production database tables repeatedly. Yeah. Yeah. Run all your local migrations on the production database. Yeah. And then, I mean, there's this culture of blameless postmortems. So you'll probably, 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. Yeah. And then you'll know what all the safeguards are because you're in the postmortem meeting. 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 enough. Challenge accepted. All right. I think with that, we've answered the question. All right. No more, no more light can be shed on this. Okay. I'll read the next one here. Okay. This one comes from a listener named Gretchen. 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 VHSs. I'm going to be the best. At last, bringing you the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title of the title 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. 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 engineers. No, that's what I'm saying. Yeah. So as a staff software engineer, your coffee fetchers are the senior engineers. Is that what you're saying? Exactly. Maybe it's worth just being explicit about the ladder. So I think the world they're talking about has a ladder that looks like junior, regular type engineer. Medium. 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'm, I don't know. There's it's the wild west out there. So yeah. Yeah. Titles. Principal could be your coffee fetcher. Yeah. Oh, good, good question though. Right. And, 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, 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, you are expected to lead. Yeah, I agree. That's what I interpret from 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, you know, 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 this is, 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, and just like know everything already because of your, 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. Yeah. I think that's good. Yeah. 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, you know, will make your opinion not necessary. And even though, you know, your, your goal, your, 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? I said, post-gress. I think that's really good advice. And I think it's more important the 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. You know, 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 kind of a different story. I was a senior role, but I was a senior role. I didn't know. But prior to my joining, they didn't have anyone who was 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 months later, someone came to me and they're like, the team has been, it's been so much better with you here. And I'm like, why, what, what happened? And they're just like, it's just 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. Yeah. 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, you're 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. 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 team members. And so, you know, I think that's, I think that's a really, you know, a really important thing to be aware of. And I think that's, I think that's a really, you know, a really important thing to be aware of. And I think that's, I think that's a really, then they will have with each other. Right. So, so the, the perspective that we have of other people is difficult to update. And so if you say something that, you know, maybe is, 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 opinions held loosely thing. Well, the problem is that you get three weeks or even three months to do something that you're not convinced of. 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, 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 an, 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, you know, things that could be conflated with each other. Yeah. 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, 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, you're not going to be able to feel that emotion attached to even technical There are ways to give it where people feel, you know, disparaged. 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, so they could get repeated and, and maybe distorted or misunderstood a little bit. I feel like you have to repeat yourself a little bit more. Yeah. 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 Dave 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. Which, for the first time, I feel like I'm saying the same thing. The first few times it happened, I was like, what is wrong with either me or you? And then, then I just realized it's, I don't know, everyone comes to a conversation with different context and, and it just takes a while to get messages across people's, people's communication styles. And, and everyone has a lot on their plate, which takes a while. So I think repeating yourself on, on core important things is pretty valuable. And on that, on that note, one way to make sure that you automatically repeat yourself in a I thought you were going to say robocalls because I just listened to a podcast about the rise of the robocall 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, make sure everyone sees it. No, but seriously, like, I think, I think writing documentation about your vision and, and, 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 yeah it becomes mythology or something yeah sure yeah it becomes less rhetorical right you don't end up parsing words it it's more there's a different kind of authority to words that are written down on a screen that's kind of weird i know anyway you mean with the sharpie right they're taken down record yeah exactly um just go around to each of your uh developers screens and write on there that has a lot of authority i mean that's like hard to erase yeah no but it's it is true that we we parse the spoken words 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 uh 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 we create a little bit more of a 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 and so i believe it more it's gonna say the same thing about you oh my gosh oh my gosh we're just sitting here wait 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 gonna 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 okay speaking of trustworthy 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 that's a good question so turn that around and think about yourself and why you would trust think about the people that you trust and 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 have just made them likable 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 to be around so like lots of hugs lots of lots of that's it no i i you know 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 to gain trust not 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 were 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 gonna 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 gonna try and behave to demonstrate that i'm i'm here to help and just stating that feels like you would help earn some trust right away but then you do have to act on it too yeah there's uh i think that goes into part of not coming in and just being really heavy-handed too 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 the people that i trust most in leadership are the people who have definitely been the ones who have been the ones who have been the ones who have been the ones who 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 uh some of the like more monotonous or frustrating things that i do that other people on the team don't want to take on take those on and if your 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 be a leader and i think that's a really good way to do that than to have only second-hand information yeah yeah i think uh i think you point you you hit on something really interesting there right in the middle of what you're saying of 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 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's 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 you're working on that continues to pay back and people will start coming to you to ask questions right and then you're going to have to figure out how to do that and then you're going to have to figure out how to do that 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 reply 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 months every standout yeah repeat yourself consistent messaging you know that bug would never happen if 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 wastes yep type check all your code and make the compiler pass you know if it we could do this in a single line of python and just like a comprehension and and you and so the cycle completes the the flip flop of increasing trust then talk about how everything should be a monolith and then talk about how everything should be in containers yeah you know i think if you just follow the industry you'll end up there naturally there it is 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 metal 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 or 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 jameson offered to get more questions but i think the world just got harder just a big way to end the show i think it's probably all those bribes jameson offered to get more questions but i think the world just got harder just a big way to end the show i think it's probably all those bribes jameson offered to get more questions but i think the world just got harder just a big wave yeah a lot of problems out there more challenges that need answers uh jonathan how can people find you on the internet uh you can find me on twitter at jay gattrell at developer t you can also find developer t at spec.fm and a bunch of other awesome shows over there as well thank you so much for joining us thank you for for letting me take care see you next week thanks so much for listening to today's episode this bonus episode of developer t where we cross posted over from soft skills engineering i had such a good time and is really thankful to be on the show and really enjoyed our conversation i hope that 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 you