Soft Skills Engineering - Episode 383: In the trenches without writing code and how to close a social skill gap

Episode Date: November 20, 2023

In this episode, Dave and Jamison answer these questions: I recently started the interviewing for a senior engineering manager role at a fairly prestigious, but not huge (maybe 30-50 engineers) tech company. The job description heavily emphasized the idea of leading as a peer as opposed to just relying on the EM title. I love this approach, but the lead interviewer then disclosed that they don’t want EMs writing production code. This seems like a contradiction. Am I naive in thinking so? I certainly understand that taking on a more managerial focus will result in less IC work. However, as a leader I find a ton of value in staying close to the trenches. It allows me to earn the respect of my reports, empathize with their day to day, and sniff out good/bad decisions quickly. As an engineer with good softskills, it feels like gravity wants to rip me away from writing code. How do I stop this? Can I? Should I resign myself to a work-life filled with never ending 1:1s? Hello Dave and Jamison, thank you for your podcast. I have listened to almost all episodes and they provide both educational and entertaining values, you rock! I would like to ask you for advice. I am struggling with a problem related to communicating and cooperating with people in general. I have over 10 years of professional experience. I was always a hardcore nerd, sitting alone in front of the computer and programming, focused only on pure technical skills, everything else was unimportant. Most of my career I spent in small companies where I could just spend time writing code and I wasn’t bothered by anything else. However, one year ago I started to work at FAANG and now I feel overwhelmed. Technical skills seem not so important anymore. Most of the problems are being solved by talking, negotiating and following up with other teams, participating in meetings and presenting results to management. It stresses and burns me out. I feel it like a waste of time and potential but also I was never a people person, so I am anxious every time I am in a new social situation. How could I convince myself that such non-technical skills are equally important as technical skills? What steps can I take to improve my attitude and skills? What would you advise if you had to work with a person like that?

it takes more than describing a Roomba outage as a robot uprising to be a great engineer this is soft skills engineering episode 383 I am your host and non-owner of a Roomba Dave Smith I'm your host and proud Roomba owner so that they don't destroy me when the uprising completes Jameson Dance. Soft Skills Engineering is a weekly advice podcast for all the non-technical stuff that goes into being a software engineer, such as keeping the robots just satisfied enough that they keep working, but not so self-confident that they rise up. So I have an 18-month-old son and he is terrified of the Roomba, but terrified in a way that he can't keep away from it. So So whenever he walks into the room where its little station is, he just stares at it and

slowly walks up to it. It's like the Lord of the Rings when the ring is like casting its evil spell on somebody. And then he walks up and he slowly with huge wide eyes presses the button to turn it on and then just shrieks. But he does it every time. So he senses. He knows they're up to something. The children know.

What do the children know that the adults don't understand? Yeah. This is no benign hockey puck. Oh, my goodness. Dave, I want to thank our patrons. So I'm going to. All right. Thank you to Nick Kantar, Brayden Keynes, John Grant, Travis, Nick Hathaway, Jonathan

King, Ragnar, Webtoe, Awesome Anten, Testing, Will Angel, Ira Chan, Monkey Face Emoji, Patreon.com, We're Hiring, Craig Motlin, The Stochastic Parrot, Owen Shardle, Jenny Kim, Cody Sale, if you would like to join this illustrious, oh wait, not yet, Kenzie Dodds, Valentin at Datafold, Santa Hopar, TheComputerScienceBook.com, trash panda never is not just a crater on mr on mars flamingo emoji i like chicken i like liver miamix miamix please deliver full stack contractor looking for job corp to corp and type here.dev thank you thank you so much to all these people or concepts who are supporting the show we appreciate it they have all done something that you are welcome to do they have gone

to our website and clicked support us on patreon and then provided their payment details in whatever local currency they accept i don't know what it yeah they did the thing um if you want to do the thing too boy would we love it that's my sales pitch yep don't you want us to love it every time you say we thank the people or concepts my mind just immediately has to start thinking of what other categories could possibly be on this list and for some reason this week it went to one concept which is the super intelligent shades of the color blue in the fictitious work hitchhiker's guide to the galaxy or future history hitchhiker's guide to the galaxy yeah super intelligent shades of the color blue also welcome on patreon are you familiar with scp the command no yeah that is

ambiguous huh it's a it's a collaborative i guess science fiction horror bureaucracy universe that started in like 2008 or something okay no so it's a wiki where people write articles describing anomalies they're called and they're like weird creepy spooky things and there's this fictitious society that exists to catalog and contain them so it's like these dry government bureaucracy reports about mind-eating horrors and cell phones that call backwards in time just weird stuff like that okay so when i when i talk about concepts i think about that maybe maybe maybe someone maybe one of those entries from the scp wiki is gonna sponsor the show that would be The abstract idea of nothingness that consumes all it perceives has become a patron.

We'd like to thank it, them. I don't know what to call it. It's probably not helping that I listen to somebody narrate them every night and fall asleep. Yeah. Put on my headphones, listen to my spooky stories, drift off to bed. Perfect. and then wake up and answer a question from a listener. Yes, let's do that.

All right. I'll read the first one here. No, wait. I think I have some feedback here to read first. Yeah. This comes from a listener named Peter who says, I was listening to the answer you were giving to the question about working four out of five days a week.

This was episode 381. In Belgium, and I think in Europe in general, working four days is very common. Most people only do that while they still have young kids, and there is a financial consequence yes i i expect that could be classified as 20 it would be cool to just have that as an option of like yeah if you want cut your hours cut your pay and and that's just a thing you can pick because i know there are lots of people who would choose that oh yeah 20 pay cut and only work four days a week yeah tempting all right i'm gonna read the

first question since you read the feedback do it this is from an anonymous listener who says i recently started interviewing for a senior engineering manager role at a fairly prestigious but small tech company the job description heavily emphasized the idea of leading as a peer as opposed to just relying on the em title i love this approach but the lead interviewer then disclosed that they don't want ems writing production code this seems like a contradiction am i naive in thinking so i certainly understand that taking on more of a managerial focus will result in less individual contributor work however as a leader i find a ton of value in staying close to the trenches it allows me to earn the respect of my reports empathize with their day-to-day and sniff

out good or bad decisions quickly as an engineer with good soft skills it feels like gravity wants to rip me away from writing code how do i stop this can i should i resign myself to a work life filled with never-ending one-on-ones oh i felt this gravity so long yeah i finally gave into it i went the opposite direction i write way more code at this job than my past job even as a non-individual contributor yeah it's a smaller team so i'm a larger fraction of the engineering team yeah now let's talk about the contradiction in this job description so it says leading you must lead as a peer but you may not do peer things like writing code i so i kind of interpret that to mean the expectation is not that you'll show up and say as your manager i command you not necessarily

that you'll be doing the job of an ic but that you are expected to kind of influence and servant leadership is a phrase that comes up a lot yeah instead of command maybe this is this is someone who doesn't have the budget to hire an engineering manager so they're hiring an individual contributor and then not telling the team that it's actually the manager and then telling the individual you must lead through they are the manager you're the manager but a special kind of manager the kind that doesn't get paid well and must not secret manager yes it's like undercover boss except i was thinking about that too you actually have to tell them what to do while undercover yeah and you stay that way forever

yeah it will never reveal it's deep cover yeah yeah yeah i so i don't think leading as a peer requires you to write production code. I also don't think not wanting engineering managers, I think it's reasonable to say we don't want EMs to write production code, but you can still review a lot of code and participate in design discussions

and write manager code where we've talked about this a bunch. It's code to help the team do stuff that they wouldn't normally do to solve some kind of problem or process thing or fix a bug no one's going to get to, but you're not like in the critical path of the major important project with the project

depending on you delivering working features. So that doesn't seem weird to me. You can still write code. Oh, go ahead. Yeah. I was just going to say that this seems great, like this kind of leadership where you are familiar enough with the work of your team such that you can actually make informed recommendations that carry weight simply because they are so informed it's like people feel obligated to uh to follow your direction not because of the positional authority that the direction is coming from but because the direction itself is a good idea yeah and i think that means writing usually less code certainly and and different code but i think you probably read more code if you're in this mode of of like

trying to be in the trenches and have enough context to i don't know i'm gonna take that back you probably don't read more code never mind i mean if you i mean if you end up doing a lot of code review instead of a lot of probably a bigger fraction of your time than yeah than writing yeah and this mode and i think the amount of code that you review tends to be proportional to your seniority as a natural course of things and so in an in a management role where you're actually expected not to write code at all like let's just say that you took that for granted i cannot write code well then i think you will be doing a lot of code review and that's actually a good thing it's also a tricky puzzle to solve if you can't do it yourself how do you get the team to do it

then you have to convince them and like you can't just go and write the code the way you want it to be written you have to help decide on standards and practices and principles and and it's you're working at a more meta level. But that scales better because you can influence the team instead of just your own output. Right. This actually describes the way that I am currently working in my role where I'm leading a team, several teams of engineers. And I think it works pretty well. I think I have a reasonable level of influence on the team, even though I don't actually write code that contributes to each of the team's code bases. Instead, I end up doing a lot of discussion and contemplating. And I also work at kind of the, I'll call it architecture

level, more like architecture in quotes, where I'm more talking about major components that interact with one another and design of these systems and less about, you know, should we be using Java streams or not? You know, like I don't really care about that level. yeah as an engineer but one thing i think you've correctly picked up on is that if you go down the management track it is pretty likely you will write a lot less code than if you stayed on an ic track if you get more senior as an individual contributor generally you write less code as well but you still more than as a manager like if you're a principal engineer somewhere you're you're going to write more code than a director or senior engineering manager,

which might be kind of the same level in the management track. So if you just have to write code and that be your main, well, it's not even the main output for developers, but if that's like a critical part of your satisfaction in the job, then you are going to be, I think you can still do it as an EM, but you will be trying to swim against the current a little bit and you will have to justify it and protect it a little bit

because the vibes are definitely pushing you towards other stuff. Yeah. And I'm kind of ignoring all the consequences of that of like maybe you're going to not do important EM things because you're writing code. Yeah. I'm assuming you're perfect

at all the engineering manager stuff. Which is obviously true. I mean, that's the easier part. Yeah. Easier to neglect, I mean. Sorry. Yeah. Should I resign myself to a work-life

filled with never-ending one-on-ones? I mean, if you don't like one-on-ones, you should not take a senior engineering manager role. That's a pretty good signal. If you just want to be left alone to get stuff done, then that is not what your job will be. So I want to go on record, even though this record carries no weight

and no one will ever read this record, as saying that I think engineering managers should be capable of writing production code and do so fairly regularly, but should also give themselves the option to pull away from it for extended periods of time to deal with other important attention-needing things, such as team organization, planning, one-on-ones, things like that. But I love it when my engineering managers can jump into the breach and fill a gap. I mean, it just happened this past week where we were shipping some stuff to production,

and one of my teams had a little bit of an oversight where they were like, oh, we've shipped all the code, but there's a feature flag that needs to be flipped on for everybody that we just forgot to put a task in. And the engineering manager said, look, the team is already working on the next sprint. They've already kind of committed to that, and we don't want to disrupt them. I'll just take that task. And I'm like, perfect. That's exactly the kind of thing I want an engineering manager to be able to do, jump in and fill a void somewhere. And the manager did a great job. It was no problem. And so if a company takes the hard line that says engineering managers can't write production code, I disagree with that.

Yeah. Well, I would never disagree with you. That's really unfortunate. If we go back to the question, they're asking about this contradiction between leading as a peer and not writing any production code. And I suspect they might have a different definition for what leadership and being a peer means than you seem to be thinking of it as contributing technically like in ICWood and doing management stuff. So that might be worthwhile to dig into. And I mean, I would be surprised if, what are they going to do? Like if they hire you and you write some code and you're getting other stuff done, I don't know. I would be pretty

surprised if they said, stop, you are not allowed. Maybe if there's a problem in kind of managerial areas, then they might say, hey, you need to take care of that before you write code. But i'd be shocked if this were an all-out hard ban yeah i don't i would imagine they're not taking it that seriously and and i would hope that this job whoever wrote this job description is really just trying to manage expectations more so than putting a hard ban on writing code as a manager actually that could be what's going on here too there is a common failure mode for talented software developers with good people skills where they kind of get pushed into management and they don't really choose it they don't practice it deliberately and often they will

they will hide in the technical details they will yeah i can't possibly do these tricky conversations because i have to deliver this this re-architecting of the service and like so maybe maybe they're kind of over correcting to try and avoid that could be kind of setting expectations like you said to to make sure that like hey you have to do the job of engineering management, not the job of writing code. Yeah. And I've seen that failure mode manifest pretty strongly. One of the engineering managers who reports to me took on a task and we all thought it would be a straightforward task that could be done kind of on the side, not on the critical path, but it ended up consuming their time like a lot more than expected. And, you know,

it was the kind of thing where we thought, oh, this will be just like a week of calendar time and maybe like five to 10 hours of, of actual time. And it turned into like three or four weeks of calendar time and like 50 hours of actual time. And I started to notice that this manager got more and more frustrated when I asked them to do manager things. Yeah. And it was like, oh, finally it dawned on me like, oh, you've been totally consumed by this technical task. And now you haven't, which technical tasks tend to do, right? They tend to, Yeah. To consume us. Like we can't think about anything else. We go to bed thinking about them and then we wake up in the morning thinking about them. And so I asked this manager to do some other

stuff with the team, kind of more people management stuff. And he was like, well, I just don't have enough room on my plate. And I'm like, oh, I see. So maybe that's like you said, maybe that's a failure mode they're trying to avoid here. Yeah. Well, have we answered the question? Almost. I think there is one final question here, which is how do I stop this gravity ripping you away from writing code? And I have an answer to that. Well, two answers. One is that if you really want to just avoid reducing the amount of code that you write or the amount of time you spend writing code every week, then you just have to avoid management and leadership entirely. And I have done that multiple times through quitting my job because I found that

At all, probably my first three, quote, real jobs out of college, after a year or two, I started to get pressure to go into leadership roles. And I did them because I wanted to be a good team player. And honestly, it came kind of naturally to me in some ways. But I hated it, you know, because I just felt like it was pulling me away from the fun stuff that I really love doing, which is writing code, solving technical problems. And I quit those jobs in part because of that, which was just so refreshing. to jump back into the code without any of the leadership responsibilities. It was wonderful.

The first time you see like a really gnarly problem and just say, good luck handling that to someone else, it's delicious. Oh, your senior designer and senior product owner are both fighting bitterly? Huh, time to go work on these unit tests. Yep. you know it's funny because that also plays the other way you know now now that i'm in more of

a leadership role sometimes i think oh man this is a really hairy technical problem i would not want to solve that it's like a hard to reproduce bug that only manifests yeah when like seven services interact in just the right way when mars is in this part of the sky you know yeah and i'm like well good luck and i'm like i'm going to bed and then i'll three days later i'll i'll come into work and send me the updates hey how's that going you know yeah three days later i come to work and there's this beautiful document explaining what went wrong and how it was fixed and i just i'm in awe of it and i love it so i don't know that that sword cuts both ways james it's not me staying up all night worrying about it anyway i do love those technical problems though but yeah

so like you can just pull away now having said that grab if you are going to get into leadership Gravity will eventually, by default, completely rip you away from writing code. I've seen it in so many leadership careers. But I have one trick that keeps me in the code. And that is, I give myself coding tasks that are not on the product roadmap critical path and usually aren't even on the product. And that is building internal tools. I will write Chrome extensions for my team.

I will write scripts for my team. I will write little backend like data process, like, oh, I'm going to take all of our Jira tickets and put them into a data warehouse so that we can write queries on them, that kind of thing. And that, that scratches my itch and leaves me feeling satisfied and keeps my technical skills sharp. Sometimes I take opportunities like that to learn new languages or learn new technologies or frameworks.

It keeps me going and I love it. And it keeps me a little bit, I mean, I'm getting to be an old fuddy-duddy, but it keeps me a little bit relevant, you know, where, and by a little bit relevant, I mean, just enough to where people can't ignore me. you know enough that they can't easily prove you're useless right just i just sweet spot we call it just a little bit beyond reasonable doubt yeah not guilty of uselessness yeah a jury of my purely we have answered it now yes i think so let's move on jameson i want to tell our listeners about a tool that many of them probably know that i love and i

know you've used as well and love that has recently added a whole bunch of cool features and that is notion notion is a it is like a note-taking app but super super good and notion has recently added a bunch of ai features that i think are awesome yeah i've used notion i think this is the third job now that i've used it at work and used it personally for a while too it's it's pretty sweet and it's been really interesting to see them play with integrating ai into the product in a way that's useful and not just kind of tacked on at the last second yes i am i get so frustrated by other products that bolt ai on they're like oh look now we have a sidebar that pops in and you can in you can chat with a chatbot i'm like oh my gosh yeah i hate that i'm so sick of chatbots

showing up everywhere. Notion has actually built AI natively into the product. So I can tell it to do things like generate to-do lists or remove items from my list that match a certain subject, or even ask questions about my own content. Like, hey, summarize these notes I took and extract the action items. Yeah, they just added a Q&A feature, which is pretty cool, where it can use the content of your own workspace to answer questions. So you can say like, hey, what did we say in the meeting that happened on this day? You don't have to give it the link to the doc or anything, it can go and search it and find it and bring it up to you. Exactly. Like, hey, I met with the integrations team last week. What were the takeaways? Boom.

So much better than like trying to remember the keywords that you would have written down in that page to try to find those notes. Yeah, I love it. Go check it out at notion.com slash soft skills. Yes, that is all lowercase letters notion.com slash soft skills. Try the powerful easy to use notion ai today and when you lose it when you use our link you're supporting the show this is a sponsored ad if you can't tell i guess we should say that yeah but we do like notion and i have used it for years so it aligns well all right jameson would you like to read our next question i would love to this is from another anonymous listener who says hello dave and jameson thank you for your podcast i have listened to almost all episodes and they provide both

both educational and entertaining values. Thank you. You rock. Oh, such nice words. I would like to ask you for your advice. I'm struggling with a problem related to communicating and cooperating with people in general. I have over 10 years of professional experience. I was always a hardcore nerd sitting alone in front of the computer and programming focused only on pure technical skills. Everything else was unimportant. Most of my career I spent in small companies where I could just spend time writing code and wasn't bothered by anything else. However, one year ago, I started to work at Fang. It's one of the big megatech companies. And I now feel

overwhelmed. Technical skills seem not so important anymore. Most of the problems are being solved by talking, negotiating, and following up with other teams, participating in meetings, and presenting results to management. It stresses and burns me out. I feel it like it is a waste of time and potential, but also

I was never a people person, so I'm anxious every time I am in a new social situation. How could I convince myself that such non-technical skills are equally important as technical skills? What steps can i take to improve my attitude and skills what would your advice be if you had to work with a person like that ah oh turning that on its head what what would my advice be if i had to work with someone who didn't want to work with me is that what you're asking yeah someone who didn't love

the the communication and non-technical i don't know non-programming work that goes into yeah coordination well having having both of us having worked at one of these giant mega tech companies i totally agree that the social skills required to successfully navigate solving even what should be simple problems simple technical problems are the skills required are much more advanced let's say yeah if you think technically scaling a system is hard wait until you have to scale people and communication issues. That is a whole different kind of hard. I don't know if it's harder or easier necessarily, but it's a different axis. Yeah. I remember one of my very first assignments when I joined a FANG company was to try to make a plan for all the services

within my department to migrate from one framework to another. And it was like, I couldn't even tell how many teams were in my department and I found out midway through the project that some of the staff in my department were actually funded by another department and we had certain obligations to that department and I got on calls with them and it was like oh we oh man it was so there was there was like political stuff going on where they weren't getting what they wanted so it was like customers layered on customers but some of them were internal and oh boy it was tricky just even figuring out what was going on let alone how to how to proceed was very challenging yeah i observed similar things in in that easy things can become hard and and just when the scale gets that big

you you can't collect all the information you need yourself you can't just look at the code base or look at the directory or like you have to talk to other people and there's layers upon layers of teams like you mentioned and then there's even more layers for stuff to get confused or mixed up so it is a hard problem to solve coordinating at that scale even just even just finding a person who actually knows what they're talking about for the thing you need to know about can be really challenging yeah and finding the a person who knows what they're talking about and is like willing to help you instead of see you as as an intrusion upon their domain right oh man i'm getting flashbacks. Yeah, me too. In fact, I just thought of one person who I just absolutely

appreciated so much because they knew something about the systems that I needed to integrate with and they gave me a couple of hours of their time. And I was like, thank you so much. You have saved me weeks of investigative journalism. I think in one word, I can give an answer to this question that will address simultaneously some of the challenges of navigating these bigger organizations and help compensate for a lack of social skills or for a strong social anxiety. And that word is writing. It turns out that in most of these organizations that I'm familiar with, one for sure that I worked in, but others that I've heard secondhand,

the written word carries so much weight in these organizations because it is just nearly impossible to get people's attention focused enough on you when you're speaking to actually have that convey any meaning. But written documentation tends to travel very well. It tends to persist. And it tends to cut through a lot of the political stuff, a lot of the social stuff. And it ends up being kind of a great equalizer among people who do and do not have these, call it like social charisma. Then you just need writing charisma. Right. Well, and you know, the beauty is that a skilled engineer is naturally a good writer because they don't care about any of the fluff and people reading technical written material

don't want any fluff they want just the facts it's like oh you want to you want to start a new program and kick it off and you need you know four people to work with you give me the facts give me the business value make a case for it and you know business cases are not made through flowery writing and fluffy impressive uh um words see i'm not even good i can't do the flowery stuff but you know like business cases aren't made by inviting someone to an nba basketball game in your special booth that costs millions of dollars you know business yeah although unfortunately that is how some deals many many deals are agreed to but when it comes to technology and engineering choices the most convincing to me way to make those choices is through written

material that just states the facts in an unequivocal way i think even if there is a kind of in-person piece of this that still has to happen if you have to present to other teams or have some kind of real-time discussion it's it's way easier to anchor that with a written document and it can help it can help kind of keep it on track help you know you're not just going off the rails completely i i thought you were going to say money is the one word because usually you get paid more at these places so it's you put up with the pain for dollars this might be a variation on the money theme but you could look at what works if this this will work if you're very motivated by kind of like achieving a thing in the organization then maybe this can help you

because if you are then you have to do the thing that gets results and usually that means talking to people and convincing them and following up and doing all this stuff and if you can if you don't like it you're uncomfortable with it you feel like you're not good but you're motivated to do it because you know this is helping me achieve my technical goals then i think that can be a powerful motivator if you don't really if you don't care that much it's the wrong way to put it if you really want to put your head down and write code then that might not help as much because that's less impactful and meaningful without the results that it will achieve what am i saying i think i'm saying to to be successful you need to work

on this a little bit more which i guess is what you're saying in the question as well so i don't think i'm telling you anything new just repeat that to yourself i don't know it felt new you're just i need to do this you're so good at clearly saying things my words yeah you worded a good word my good words so good even though we said that writing helps and this kind of thing you know what jameson said helps sometimes you do have to actually stand up in person and and justify things and explain things and appear confident and there's really in my opinion no way around that except through it meaning you have to spend time doing that and and now i'm going to put my space psychologist hat on which just as a reminder we are not real psychologists well

we are real but not on earth which is where we are now so take that for what it's worth and i'm going to throw out a term that sounds like a real psychology term and might even be, and that is exposure therapy. And by inexperience in psychology, this is where you have a problem or a fear or a skill gap in an area that causes you anxiety, causes you to feel burned out. And instead of avoiding it, you expose yourself to it. And I think that is required to become comfortable with these kinds of situations. Like let's say you've written an excellent doc. You've farmed it out to all the different relevant teams who have to sign off. Now they want to talk to you about it. This inevitably happens where you have to sit down

in a meeting, they've read your documentation, they have questions, and you need to answer them. And the confidence level that you exude in answering these questions and the quality of the answers you give will ultimately determine whether your ideas proceed or get shut down. and in my experience the only way to confidently navigate that kind of a situation is to do it a bunch of times and that and doing it a bunch of times helps you realize that actually it's not that bad and most of the time except for when you are exposed to really badly behaving people most of the time people just have questions of curiosity and they have real concerns that are valid and you need to learn how to understand those concerns pivot your proposal to incorporate

those concerns and then work together as a team. From what I've experienced, the only way to do that is to do that. I was going to say practice, but exposure therapy sounds like we could charge more money for talking about it. Well said. So there's the practice in delivering your material to somebody. There's also a, I don't know, I might be extrapolating or reading more than is in here, But there are some times where you have to present to people who have very little context, are very busy, they're like executives or high level leadership or something. And that's a totally different vibe than presenting to like a peer team. and i think that's harder to practice for because it's less about you knowing your material and more about you dealing with the like rabid wild changes of topic and random stuff that they jump on to and like you have to you have to work to keep them on track or or just go with the flow

i guess as well but i think the answer is sort of the same that you if you really know your stuff because you practice it a lot, it'll be easier to deal with those conversations and follow them where they lead. Yep. What steps can I take to improve my attitude and skills? Well, I listen to this show, of course. Also, I think that one mindset shift

that might help improve your attitude towards these kinds of problems is instead of focusing your professional efforts on the act of writing code and doing the non-social, non-soft skill stuff, instead of saying, I derive my professional satisfaction from doing those things,

you should say instead, I derive my professional satisfaction from producing valuable product that makes the lives of my users better. And then the code and these challenging social situations are actually just a means to achieve that outcome of building great product that makes your users better.

and this is a actually a pretty rare attitude among software engineers most software engineers myself included for many years only take satisfaction in writing code like i like to solve puzzles i like to write code i like to produce code i don't like to fix bugs i don't like to go to meetings i don't like to actually deeply understand my users i just like to write cool algorithms and program stuff but really that is not our business our jobs we are not getting paid to write code you are not getting paid by the lines of code you write you are not getting paid by the bugs you fix instead you are getting paid for the valuable outcomes you deliver and writing code just happens to be the tool that you use and the skills that you have to do that and

when you work at a giant company like a fang company now you need to increase the size of your toolbox and also learn how to navigate these social situations as a means to the same end here here well said well then we answered this question i think so i think you're wise to recognize this and and you say you're not good at social situations but the fact that you are self-aware enough to notice makes me feel like you you can you can do it the people who are hopeless don't know that they are that's the they don't care or don't notice yeah all right what should people do if they want their own questions answered dave go to softskills.audio and click the ask a question button thank you so much to everyone who does that each week the the questions are just flowing in

like a fast-moving glacier that crushes everything in its path but instead of crushing things it fills our our souls with joy so nothing like a glacier at all either in speed or effect so thank you over many millions of years new mountain ranges will appear because of your questions. Yes. We also want to say thank you to those who have responded to our call to give us feedback on our answers. We will continue to read those on the show. We really appreciate you telling us how things went. Man, there were some great ones this week that we didn't read, but we'll try to read them next time. So thank you. You can use the same form at softskills.audio, click the ask a question button, and then blatantly disregard the labels on the fields that say question and

instead write feedback on a previous episode and just write a few words there saying this is feedback on episode x and just let us know how we did we'd love to hear hear that yeah computer's not the boss of you it says ask a question do whatever you want yeah you put whatever text you want in there yeah all right thank you for listening we will catch you next week