Soft Skills Engineering - Episode 311: (rerun of 207) Unclear career goals and garbage code

Episode Date: July 4, 2022

In this episode, Dave and Jamison answer these questions: I’m a senior software engineer at a fast growing software startup. In the past year and a half that I’ve been with the company I���ve gone through 5 reorgs and have had 5 different managers in 4 different teams. Each time I sit down to do a 1 on 1 with a new manager they ask about my career goals and aspirations. Initially, when I joined the company I was a weak and feeble non-senior software engineer. When I was asked this question then, my answer was “to learn and grow, and have more authority and autonomy over the systems that I build, and be considered a senior software engineer”. Over the past year and half I have proven my worth and paid my dues and got the title of senior software engineer, along with the pay raise that came with it. My career development horizon has not been very broad. I didn’t even know there were levels beyond senior software engineer for a long time. I feel like I’m missing out on growth opportunities by not having a clear answer to this question. Please help! Love your show, keep it up. I career switched via a coding bootcamp 3 years ago and have been at my current company ever since. The bugs created by my garbage code from the early days made me a big believer in clean code practices — I now feel strongly about using descriptive variable names, avoiding duplicate code, etc. However, my boss/CTO is on the opposite end of the spectrum. As long as the code works, he doesn’t care what it look like. I want to stay at this company because I strongly believe in the product and I love the flexibility of a small start-up, but my boss and I keep bumping heads. For example, we recently switched over to PRs, and each PR my boss has made included blatant violations of the coding standards document we created together (!). When I request changes on the PR, he says he’ll do it but it isn’t a good use of our time to rewrite it when the code works. My question is two-fold: (1) As the most senior engineer on the software team, how can I go about promoting a quality-driven approach when the CTO doesn’t see the value in it? (2) If all else fails, I’m open to quitting, but I don’t want to end up the same boat. During interviews, what questions can I ask to find out if the company truly values code quality?

Hey everyone, Dave here. This is episode 311, but we're bringing you a rerun from April of 2020. This is episode 207. Enjoy. It takes more than simulating the outside world with plants in my office to be a great software engineer. This is episode 207 of the Soft Skills Engineering Podcast. I am your host, Jameson Dance. I'm your host, Dave Smith. soft skills engineering is a weekly advice show where we answer your non-technical questions about the technical field of software development i have one plant on my desk it is dying and i feel

like that simulates the outside world pretty well i guess so maybe i'm not even gonna water it okay that is very sad i mean i thought i was going like i'll get more plants and that way It'll be like being outside, but this appropriately covers kind of the whole general scene going on. Dave, do you want to talk about our patrons? Yes, thanks to everyone who's contributing on Patreon. They are Vinlock, Brayden Keynes, Chris Hogan, Dennis Bogdanoff, Evgeny Sladkowski, John Grant, Luis Santos, Luke Bayliss, Nick Hathaway, Philip John Basile, The Agile Ventures Charity, Sean, Stanley Tactical Radio, Stephen Armand Lee, Taras Harouk, Travis, and Zach Grannon. if you'd like to get on this illustrious list or just gain access to our slack community go to softskills.audio and click support us on patreon any contribution for any amount greater

than zero will get you access to our slack community and for certain amounts you will even get your name read on the show or the name of something else you want said out loud i feel like we need a cheesy name for this group the hall of champions or something yeah enter the hall of champions i want to read a follow-up we got from a question in episode 202 which is about somebody who couldn't stand up during stand-up because of some physical limitations hi david jameson i am the anonymous listener who asked about being unable to stand thanks a lot for your answer it made me think i might have been too self-conscious about the limitations i have and how they can affect my working life having an outsider perspective

that it's fine helps a lot i did talk to my boss before the mass home office started and there were no issues at all great idea about using the invisible pole to float i hope you did that yeah i ignore all the rest of the advice too well i'm glad it helped and then shortly thereafter everybody moved to work from home and then yeah you can lie down and work if you want do whatever you want yeah just turn off the camera lay down this episode is sponsored by vettery a marketplace for finding you a great new job we'll hear more about them later but for now you can go to veteri.com soft skills to sign up thank you to veteri do you want to read our first question dave sure this comes from a listener named t-bone steak i doubt that i doubt that very much

i'm just going to call this person dr steak okay assume that someone who with the first name t-bone is highly credentialed it's like the smartest steak okay dr steak writes i'm a senior software engineer at a fast-growing startup in the past year and a half that i've been with the company i've gone through five reorgs have had five different managers in four different teams each time i sit down to do a one-on-one with a new manager they ask about my career goals and aspirations let me just pause here to say four teams i mean five different managers is maybe normal for that kind of a startup but four different teams like what in like 18 months like every couple months get out of here working on something new sorry i should wait till the end

of the question before i start talking okay let me continue reading dr stake goes on to say initially when i joined the company i was a weak and feeble non-senior software engineer oh boy when i was asked this question then my answer was to learn and grow and have more authority and autonomy over the systems that I build and be considered a senior software engineer. Over the past year and a half, I have proven my worth and paid my dues and got the title of senior software engineer along with the pay raise that came with it. My career development horizon has not been very broad. I didn't even know that there were levels beyond senior software engineer for a long time. I feel like I'm missing out on growth opportunities by not having a clear answer to

this question about my career goals and aspirations please help love your show keep it up thank you thank you dr stake can we quote you and credit your title as well so it gives added weight i didn't even know there were levels beyond doctor but there's a bunch emperor stake doc supreme leader it takes an extra seven years yeah i think a good goal for your career would be, you could tell your manager, I aspire to stay on the same team with the same manager for more than three months. Nice. I don't think I've ever been in a hyper growth company, but this feels hyper growthy to me where things are growing so fast that new projects are springing up all the time and new teams are springing up all the time and people get

shuffled around. This does feel like a downside of that, that you can just get tossed around by the these these waves of growth churning through your company if you're not in hyper growth then it's a bad sign i guess or maybe it's a feature maybe there's some there's probably some like development philosophy where you change teams all the time i was just wondering like if you really are bouncing around managers and it's changing so often at some point i wonder if the managers just realize this and say what are your career goals because there's no way in heck i'm gonna help you get them i've only got two months this will help get you off my back yeah yeah this is interesting it's it's hard so often career growth which is different from like

learning stuff can be tied to relationships you build with people and if those relationships are continuously upended it's hard to do that it's not that it's necessarily political it's like part of how your your growth is recognized by the company is your growth being recognized by people at the company and if you just switch out all the time it's going to be hard so i i think i said that kind of tongue-in-cheek at the beginning about asking to stay with the same team and manager but i think it could be useful to look at why you're getting changed all all the time and if you have any influence over that maybe make that an explicit effort yeah because really continuity is required for some level of career growth i think so yeah unless you're like bringing

the project with you to a new team i don't know maybe that's a thing i mean especially at levels beyond senior engineer it's like you have to show impact over a extended period of time way more than two months yeah or just be so incredible that you have enormous broad impact in two months and then get changed to a different team yep the other thing you could do is like this is like having a substitute teacher every day at school okay did you ever do this thing where a sub would come in and they would say they would ask like what's the rule around this thing and all the kids look at each other and say like, oh yeah, the teacher said we had to play 10 hours of video games on the computers, but you can let us do eight, I guess, and be really strict. Like they, you get

a chance to reset things a little bit. So I think what I'm saying is you can just do a really bad job and two months is just long enough that someone would start thinking, okay, we got to do something about this. And then boom, new team. Reset. Blank slate. Yep. Reset. Oh man. We haven't seen dr stake in months we assume that they have been working but time to check in oh not my problem anymore okay so you're saying leverage the chaos and maybe get a second job and draw two paychecks yeah all right or just work on like the pet project you have that's going to be really impactful and don't do any work for your current team okay carry that project with you oh so so you're saying decouple your impact and your work from the org chart yeah decouple your team and

manager yeah yeah i mean decoupling is a good thing i think you've figured it out loosely coupled yeah i love that you gotta say it in a positive way yes i have a loosely coupled career trajectory i'd like to break these dependencies it's actually coupled to another company that i started working for six months ago yeah that's a hard problem if you're bouncing around so much I think a lot of suggestions I have would play out long term. One thing you could do is if you really have no idea where you want to go is ask for feedback about that. If they say, what do you want to do?

How do you see your career growing? You can say, well, what do you suggest? How have you seen others grow? If they're a new manager, they probably don't have suggestions tailored to you. It might just be more based on what they've seen around them. If you have experience with them and they know you well, then they could start to think about your strengths and weaknesses and opportunities specific for you. But either way, I think it's not bad to ask them for more info. Definitely. In fact, if you ever went to a

restaurant and sat down and the waiter said, what are your goals and aspirations for this meal? By which I mean, what would you like to order? If they don't give you a menu, you'd have a really hard time crafting that answer. And that's kind of a metaphorical way of saying, you should probably turn this back to your manager and say, what are the growth opportunities in the context of this company? Yeah. And your manager's like, I don't know. I've been switched between five different teams in a year and a half. Yeah. You're not the only one. So my wife would thrive in that restaurant where the waiter comes up and asks you what you want to order, but doesn't give you a menu because no matter what happens at any restaurant of any size or fanciness, she always

asks well what do you like we'll go into arby's really there's a menu and she says well what do you like there at arby's i'm trying to think of a restaurant that only sells one thing and we should send your wife there and she could ask well what do you like to order there's probably i mean there are some restaurants where the waiters are rude to you and order for you and that's a feature of it there's probably a right there's like a probably a pickle restaurant where you just get like a big pickle on a plate and it's got a michelin star because it's a really good pickle so are you saying are you saying that you should just turn this question around to your manager and say i don't know what do you want yeah i think so yeah i actually i actually kind of like that so i

actually think you could turn this around and say i'm still working on that what are your career goals and and actually you could ask no really like i'm not really kidding for real yeah like oh okay i mean again you're trying to feel out what's on the menu yeah and for someone who has had kind of a limited view of what the career development landscape looks like why not ask a bunch of people what their career goals and aspirations are including your manager huh i i would laugh because i just imagine like okay now those are my career goals and i'm here to leapfrog you right exactly that's one option pull the old uno reverse card on them all right let's get serious yeah i think i think there are basically three categories of career

aspirations that an engineer can have and i'll start with like the the easier obvious ones the first category is technological which is where you could say i want to become an expert at x where x is some technology maybe it's a programming language maybe it's a cloud platform maybe it's data storage maybe it's machine learning you know these are all like technical categories that you could go into certainly those are career aspirations that you should let your boss know about that you're interested in the second one is more along the lines of like individual contributor career track growth. We saw some titles in this question like staff, engineer, principal. Didn't we see those? Oh no, I think I may have edited those out. That's what they are. Yeah. Staff, principal,

senior staff, distinguished engineer. These are like titles you'll see. And the second category is kind of working up that ladder. And the third category is more about like people management, where you could say, and these are not all orthogonal to each other. Some of these things overlap with each other for example the technology skills might overlap with your interest in becoming a staff engineer but like people management is more is a totally different category where it's like i want to go into management where i achieve our business objectives by leveraging other people by leading other people you know so like that's kind of the menu so like if you were looking at a restaurant menu and it was like here's the dinner menu here's the lunch menu here's the

breakfast menu those would be the three categories that i would consider this landscape to consist of in your restaurant time has no meaning because they have this idea of breakfast lunch and dinner but you can order all of them at any time oh yeah i just want to make sure i understand just to be clear i'm in denny's right now this is now canon soft skills engineering is recorded in a denny's where time has no meaning yeah they've branched out and diversified and now they offer podcasting boots in addition to 4 a.m pancakes in addition to the moons over my hammy yeah i like that idea of it's much easier to for them to give you specific advice if you've picked like a broad track but if you just say i don't know then they'll probably tell you to just work

harder i guess can you just put in more hours and not ask for anything else i think that's that's the sure ticket to career growth you know to be perfectly fair for about i don't know 10 maybe 15 years i really didn't have an answer to this question you know i don't know if you did jameson but i have never had it well not never yeah i've had long periods of total uncertainty and what did you do when management would ask you this kind of question i ran out of the room as fast as possible i just threw down a smoke bomb and disappeared i i don't know i probably muttered something vague about highly aligned and loosely coupled yeah synergy i don't know i don't i don't remember something about synergy

i do remember saying no a few times when people said well why don't you try this thing that seems like it would help you grow and and me saying like i don't think i want to do that yeah nice yeah i did the bad thing the bad thing of just saying no growth for me thank you well i mean like it's it's my my manager trying to help me so i'm i'm vague i don't know what i want and they're like well maybe you'd want this thing and i just say duh no thanks well see you later yeah exactly and then offering nothing in return just then your manager has to go back to their manager and is like well i mean i offered now it's in his permanent record i think there's also another angle entirely that you could consider at least on the menu which is completely exiting

the three categories that we talked about before and going into something like product management program management project management something else that starts with a p and ends with management yeah there's also just kind of entrepreneurial stuff so running your own business maybe you want to do your own thing and you're trying to if that's the case maybe you'd want to go into like a sales engineer role or something to see how that relationship works yep yeah there's a bunch of ways this could go that's the secret menu at in and out i think yeah i would like my career animal style oh my gosh oh yeah i i mean this question it is i think very successful driven ambitious people

have a concrete maybe even written answer to this question but then there's like 95 percent of engineers who are just like i don't know i want to make more money i want to do cool stuff you know they just don't know yeah and it wasn't until very recently that i started to get more serious about my own career future you know until that point i basically said well any opportunity that lands in my lap i'll just think about it and if it seems good i'll i'll go for it but now it's more like i need to start crafting what i want to be in 10 years five years before now i had basically no ability to look beyond next year yeah well i aspire to be like you dave yeah well in all things that yeah great i would like to borrow one pair of shorts soon

do you like cargo shorts because that's all like i love them i know dress for the career you want not the career you have cargo i would like to dress for dave's career cargo shorts sandals that's good okay have we answered the question not not at all but i feel like we've given about everything we can. We've tried real hard. All right, good luck. Good luck, Dr. Steak. If you've been a software developer at the same job for a few years, it might be time to start looking around. Quit your job is our favorite advice, but first you should probably find a new job. Trust me, it is better this way. Check out a service called Vetteri, which matches developers with employers based on what you want, like your location, salary requirements, and technologies

you want to work with i actually signed up myself and within a week they sent me an opportunity that looked really good my current approach to job seeking is tweet dumb stuff and hope the company notices me so this sounds like an improvement i think yeah once you sign up you get a consultant to help you find opportunities i also like that veteri lets you specify your salary requirements early rather than going through the whole interview process only to find out want want your salary expectations were way off that actually happened to me in an interview Would have been nice to avoid that. You can start using Vetteri without reversing a link list on a whiteboard too.

They don't have a coding test to sign up. If you are thinking about taking our advice, the soft skills engineering patented advice in quitting your job, check out Vetteri. Go to vetteri.com slash soft skills to sign up. That's V-E-T-T-E-R-Y dot com slash soft skills. If you use that link, you will help support the show. And if you get a job through Vetteri, they will send you $300. Thank you so much to Vetteri for sponsoring the show.

All right. Do you want to read our next question, Jameson? Absolutely. This is from a listener named Raquel. I career switched via a coding bootcamp three years ago and have been at my current company ever since. The bugs created by my garbage code from the early days made me a big believer in clean code practices. I now feel strongly about using descriptive variable names, avoiding duplicate code, etc. However, my boss slash CTO is on the opposite end of the spectrum. As long as the code works, they do not care what it looks like.

I want to stay at this company because I believe in the product and I love the flexibility of a small startup, but my boss and I keep bumping heads. For example, we recently switched over to pull requests and each PR my boss made included blatant violations of the coding standards document we created together. When I request changes on the pull request, they say they'll do it, but it isn't a good use of our time to rewrite it when the code works. My question is twofold. as the most senior software engineer on the software team how can i go about promoting a quality quality driven approach when the cto doesn't see the value in it if all else fails i'm open to quitting but i don't want to end up at the same boat during interviews what questions

can i ask to find out if the company truly values code quality huh hmm interesting interesting this is not the first time we've gotten a question where an engineering team is frustrated with quality of the code contributions from their CTO. Yeah, that feels like a trope. Yes. There's something about being in a position of responsibility and still writing code that means... I mean, you're not writing code on the same playing field. You bring different levels of power to it, so it's harder to give feedback. And it sounds like in this case, the listener is giving feedback and the CTO is just saying like, nah. Exactly. I don't think so. My code doesn't feel bad to me yeah so i want to look at it from the cto's perspective or what i assume to be their

perspective they're grizzled they're weary they've seen products rise and fall they've probably seen a shell script that generates pearl that generates awk and made a million dollars in revenue and then they saw this like artfully designed carefully constructed tdd everywhere 100 code coverage just disappear into like a puff of a reorg yes some ceo writes a memo and then their project is blown away like a dandelion in the wind and they have a pragmatic approach to life now which is yeah as long as the code works i don't care what it looks like yeah and i feel like this is a this is a spectrum but it's also a pendulum that people oscillate back and forth on but it's also like a a journey that the the more you get into management and leadership the less you're involved

in the nitty-gritty of the code so you feel the pain of bad code less and you also see like the opportunity cost of investing a ton in really good code more yes hmm so maybe they're just right i guess that's the summary no that's not the summary but the summary is like they might have some reason to to value clean code less than you do and if you can get into why that is it might be a better discussion than just like focusing on the specific disagreements of we wrote this document and now you're not following this document and it frustrates me like why i mean do they not see the pain it causes to maintain it later on do they think that this project is all it's just going away so it doesn't matter like

what's what's going on here maybe they're looking at their employment contract going okay three more months until all my stock vests and i can get out of here yeah i'll tell you what though i i have ridden the clean code ship it code spectrum roller coaster for my entire career and it's so strange i will look back at code and say that oh that was garbage I'm going to change my practices and then fast forward a year and look back at that now allegedly clean code and say, wait, this is also garbage. Like, wait a minute. Yeah.

That's another perspective the CTO may have is that no matter how, quote, clean you think your code is, when you look at it a year from now, it's going to be just as hieroglyphic as you thought your other code was. And it's very possible that the code they write is garbage. And there's, there's, there's like a middle ground between over-investing in cleanliness of code and doing absolutely nothing. But it's possible that they don't see that as well. Like naming everything, every variable, some number of eyes. It's like one eye or two eyes or 500 eyes.

That's totally fine. Cause this, cause it's hard to design good code. Like you can have this nihilistic approach to it and you can, I think that's wrong. and you can still be pragmatic and design things well it's just good design is really hard and involves some amount of predicting the future and and maybe they've been burned by predicting the future too much that they've given up completely and you can still say like i mean yeah we might not be able to predict how this evolves but i can predict that 501 eyes is going to be hard for me to figure out what this thing does tomorrow. There's another, I guess we're

kind of riffing on the question asker right now, but we'll come back and take your side here in a minute, I think. But one more thing in defense of the CTO is engineers just have a really hard time naming stuff in such a way that other engineers can follow along. And I call that out specifically because the question asker says using descriptive variable names is one of the criteria of clean code i have seen long descriptive names that are just not descriptive they don't actually describe what the variable or function or class does yeah and it's like i read that and go wait a minute now i have to decipher what this thing does anyway like it may as well have just been called x it's probably harder because it's like misnamed now no that's right like it misleads you sometimes

when you read the variable name and you're like oh i know what that does based on the name and then you and then you make some assumption about what it does and boom you just shipped a bug so i don't know yeah it can be it can be very tricky your cto has figured out how to avoid being misinterpreted yeah make it impossible to interpret yeah don't if you can't interpret you can't misinterpret yeah uh so anyway i mean this is just such it is such a hard thing to do and i i am the kind of person though who loves to make sure that all of the things i write are descriptive and they follow conventions, you know, where I feel like other people who have adopted those conventions could come into my code and they could make sense of what I've done. Yeah. So I believe

in clean code in a certain degree, but I've just seen so many engineers over the last almost 20 years, write things, name things, especially that I'm just like, it's hopeless. I can tell you to make a descriptive name and they'll say, here's one. And I'll say, well, that's describing something else i mean writing prose and code get compared a lot but it's because they have a lot of parallels it's like how you can't edit your own writing you you you spend a bunch of time crafting some prose you believe you have put in enough work to make it good you hand it to someone else and they immediately it doesn't even matter if they're like a great editor if they just read it as a human i'm sure they can find stuff that doesn't make any sense or easy things you missed

you're just too close to it often and and there's kind of a mindset there i guess about the value of other people giving you feedback and it's not is it good to have good variable names or not it's like is it helpful for other people to give me feedback to catch things i've missed and they might think it's valuable to have good variable names but i i did it i named all the variables well so like why are you bugging me right there's there's some maybe some some ego there or something yeah so what do you do about it if if it's causing problems you're having disagreement even though you had i mean it sounds like you did the right thing earlier where you made this standards document yeah to try and make that thing hold people accountable instead of you have to

nag people yeah this is this is the part that is crazy to me like the cto in theory agreed on it and maybe even wrote portions of it and then was like okay well that's nice i'm gonna go write my code now and the way i always have that's just that's insane yeah i don't like that one bit so okay here's here's what i would recommend you've you've done step one which is write a document and you've gotten consensus from the cto about what constitutes good code at your company that's a good first step now you've got to get yourself out of the position of the bad guy you individually should not be the code cop and the way that you do that is you build tools to automate as much as possible of this away from individual review so you set up things like linters and static

analyzers and whatever else you need as part of your pr process so that the robot rejects your cto's crappy code not you i think that'll catch some class of problems but it won't catch everything i mean i've seen some static analysis tools that are good at pointing out duplicate code they're good at structural things that are rule-based because that's what they are usually they're like parsing the st and enacting some rules on it but for variable names how are they yeah i mean they can tell if the variable name matches a format like oh we use camel case instead of right snake case but they can't tell oh this is called concurrent hash map but it actually is not like not concurrent or or you call this a factory thinger like what what does that mean

what is the factory thing or maybe yeah what is a factory thinger maybe that's a sign you have too much abstraction here when you can't even describe what it does right there's still all these judgment things that i don't think you can ever automate away and it comes down to the cto being willing to accept other people's criticism and they're kind of not right now yeah exactly definitely a problem i think you have to you got to get their their motivations out into the open because it really might be that they're saying like i'm trying to keep this company alive and we don't have time to focus on this and like there's something going on besides them just hopefully besides them just saying i'm above all criticism because i'm perfect and and it's possible that

talking about that would help you resolve it more clearly but there's also the second part of the question which is maybe i'll just quit how do i avoid ending up at the same situation right yes that's a good question well there's an assumption here which is that there's a meaningful difference in code quality between different companies have you seen that play out in practice i have seen a meaningful difference in the level of review discourse that goes into code reviews yeah i've definitely seen a meaningful difference in the level of like bugs that survive into production but i i can't say that i've ever seen a team of more than just you know two people that actually i feel like oh yeah everyone on this team is on the same page about what constitutes good code

quality i feel like if i look back over all the places i've worked code quality has been like within some range sort of constant and constant in a bad way yeah constantly bad because it's hard to write good code but then when i think back about the thing in common about all those places the thing in common is that i worked there okay i've worked at every job i've ever had every job i've ever had has had some bad code so maybe i am the problem i guess the summary is it's hard to write good code i believe there are probably companies out there where i think it's probably a bell curve though like most companies write about the same quality of code but there are some places on each end of the bell curve you probably want to find the higher end if this is a

thing that's super important to you i mean i think one question you could ask that has an objectively verifiable answer is what does your deployment system look like and your code review system look like and what you can at least ask the questions you know the stuff that we were talking about earlier that is beneath a judgment call but that a computer can enforce and if a team has that kind of system and automation set up that's probably a pretty good proxy that they also care about writing code that others can read later i would ask to see a code review i think that'd be really interesting can you just show me a like a recent review and what how did it go like you'd see what the pull requester put into it how people reacted to it they could also just

like say no and then or show you one where well no this would tell you something too i was going to say show you one where there's no description and everyone just approves without saying anything that would probably tell you something too yeah yeah you could ask do do managers write code does the cto write code to avoid this specific situation because if those power imbalances aren't there then it's much easier to have a conversation if this was a peer it'd probably be easier to talk through than if it was your boss or your boss's boss's boss or whatever i think there's a healthy tension here if people can disagree productively about this where at each end of the spectrum of code quality or or cowboy code there is some value and some danger and the conflict about what do we

focus on and how do we how do we spend our time is useful because it keeps you from getting too far to one end or the other but that doesn't help you find out what question to ask i mean you could just ask like how do you think about code quality and they'll probably say oh it's good like most people would not say well we hate it we like crappy code but maybe you could ask about that trade-off of like how do you balance tight deadlines with still producing good code or things that are easy to work with later and if they say oh it's easy we just don't that tells you stuff too yeah that's why i like the idea of asking about a code review to see one specifically is it's harder to lie there it's easier to say things that sound good if you just ask questions

but if you're asking to see how it actually works or maybe you ask like can i see do you have coding standards written up somewhere can i see those yeah that's a pretty good signal i am skeptical that viewing a single code review however good or bad it is will give you much signal because i find that without context about the system it's hard to really assess whether this code looks good or not i mean you could do what you said before and just measure the level of discourse that's happening on the review but yeah i think that's what i'd be going for i wouldn't be trying to evaluate did someone write good code or not because it'd be hard like you said to tell but i would i'd be trying to figure out how they talk about code yeah yeah like give me an example of

a code review that included a debate about a variable name yeah that'd be pretty interesting maybe like we don't have those okay well that's a all debates are solved by our naming scheme of some number of i's yeah it's really easy to solve merge conflicts you just keep adding i's until it goes away it's perfect your compiler will tell you if you're conflicting with another variable right it won't tell you when you're using it somewhere else but when you're declaring it yes we got tools for that unique declaration enforcement yep perfect well have we answered the question? I think close enough. It's probably an uphill battle. And over time, you two will be a grizzled, exhausted engineer who no longer cares.

Good luck, Raquel. I hope this works out well for you. What should people do if they want their own questions answered, Dave? Go visit softskills.audio in a worldwide web browser and click ask a question. You can fill out our form there. Thank you so much to everyone who has done that. If you want to support the show, share it with your friends, listen, and enjoy. We will be coming out with our gopher presence soon worldwide web is good gopher coming soon all right i'll catch you next week