Soft Skills Engineering - Episode 102: Correcting English and Tyranny of the Urgent

Episode Date: March 24, 2018

Dave and Jamison answer these questions: A teammate is a great developer but English isn’t their first language. Sometimes this results in bad grammar or spelling mistakes in code comments, variables, and method names. Often I correct it in code review, but I sometimes feel like I’m nit-picking, although I really do want it changed to be correct. It slows down code reviews. And of course, I don’t wish to appear racist or discriminatory. Any ideas for solving this? This is my first job out of college. Been there for 2.5 years. It feels like my manager is always firefighting and not able to be proactive, trapped by the tyranny of the urgent. It feels like our group is always behind on deadlines trying to catch up and we’ve accrued large amounts of technical debt with little to no time spent on improving our processes or tools. The result is that we produce a worse product and documentation than we should. This causes additional support required down the road further loading down the group. What can I or my manager do to improve this situation? Is this more common than I think? Read more about the hairy arm principle and the fun memory tricks that game developers pull.

It takes more than great topological sorting skills to be a great engineer. This is episode 102 of the Soft Skills Engineering podcast. I'm your host, Dave Smith. I'm your host, Jameson Dance. Soft Skills Engineering is a weekly advice show for software developers where you write in with questions and we provide answers. And we only talk about topological sorting before the show. Yes.

But Dave explained to me what it was. Explained it very well. I did have some. Yeah, I think so. Great. It was interesting, but irrelevant for this show. Totally irrelevant. We have some patrons we want to thank.

Thank you so much to TypeScript Tips, Sean Clayton, and Dustin Coates. They're all donating at the level where we thank them every week. I also want to clarify, there's some people that have made donations, but we start announcing names when Patreon processes all that. So if you have recently signed up, we'll get to you when Patreon processes that. That's right. Thank you so much for all your support. It really helps.

it it helps because every dollar i get makes me happier so these three folks made me 20 happier each no it helps go towards uh just paying for the show paying for hosting paying for hopefully some design and editing stuff yeah thank you so much all right so we have a couple questions today jameson you want to read them i want to read just just do you want me to read both of them at the same I'll do some kind of like Buddhist throat singing. You can sing two different notes.

Can you just speak two different sentences at the same time? I think you can if you interleave every phoneme. Okay. Or it's like inward singing, right? You say one sentence breathing out, another one breathing in. That's a thing. It's like concurrency isn't parallelism, right? You could read them concurrently, just maybe not in parallel.

I never have understood the distinction, but that is not the topic of today's show. All right. This is from an anonymous listener. Big fan of the show and proud to support the show on Patreon. Thank you. I've listened to all the episodes over the last five months. I even quit my job a few months after listening, and I'm at a much better job because of it. I guess you could say I'm a true soft skills engineering fan.

Thanks. Yeah. Thank you so much. We appreciate that. I have a member of my team who's a great developer, but their first language isn't English. sometimes this results in bad grammar or spelling mistakes in code comments variables and method names often i correct it in code review but sometimes i feel like i'm nitpicking although i really do want it to be changed to be correct it slows down the code review process too and of

course i don't wish to appear racist or discriminatory that is not my style nor should it be anyone's style any ideas for solving this how do i speed up code reviews encourage more spell checking etc great question i think one solution is you just convert your code base to their native language and then and then hopefully their stuff will all be spelled right and you kind of flip the problem onto them right and then they get to correct you yeah like teach me spanish or whatever i don't know they didn't say what language it was but you can walk a mile in their shoes yeah yeah i think so you know i just want to point out that this listener had one grammar error in this very question that i that i corrected so you know that sword swings both

ways i guess uh another point is that's a joke but i've worked with plenty of people who are like air quotes native english speakers who have this same problem so i don't think the dimension of it being a second language is definitely different but it's not unique to that that's right if you have ever learned a second language which like everyone besides americans does then then i think it might help you have a little bit more empathy for this because it's hard it's hard to learn a new language yeah it's it's a totally different skill like speaking versus writing and then there are even these different rules around programming so i i think one step might just be like understand that it that it could be tricky super just having having a little

empathy for the person who is, who has gone through a lot of effort to get to the point where they're at. I do speak a second language or I did, I lived overseas for a couple of years and sometimes that was 20 years ago. And sometimes while I'm at work, I try to think of my, to myself, how would I say what I'm trying to say now in English, in Spanish, that's the language that, that I learned. And I am just completely unable to do it. I mean, it is so hard. Yeah. So I have lot of empathy yeah i mean you could do it if you worked at it more though oh for sure but it would take a long time and yeah yeah and you would you would mess up a lot oh i for sure would and i work with a lot of people who for whom english is not their first language um and uh i think

i just am super impressed with how well they do compared to how well i know i would do in my second language so yeah i mean it's just so difficult so anyway i'm just really really amazed yeah if we focus on the issue of code reviews to me the the it clarifies things down to expectations because code reviews are they're a famously like squishy fuzzy topic that can cause a lot of like unhappiness and discord and hurt feelings and and i think the root of all those is what are the expectations for code reviews? If you have clear expectations on your team that, hey, we know some of you are English

as a second language people, but the expectation is that the grammar is correct in comments, in code, in everything. And it's fine if you make mistakes, but we just need to make sure those get corrected. If that's an explicit expectation among the team, then I don't think it would feel like nitpicking and it wouldn't feel like you're discriminating

or you're just holding people to the standards that the team has agreed upon. but what i imagine is that no one has any explicit expectations around code review so you're just kind of dancing around the issue thinking like i sure would like this to be the case but yeah i might be offending them because they think it's good enough and i i think it's not and so one solution might be to discuss as a team how do we do code reviews what are we looking for what what are the criteria that code needs to meet to pass a code review and then you're holding it's like i do this a lot with my daughter you make the rule the bad guy and you're saying like it's not my

fault it's just the rule that you can't have 14 cupcakes it doesn't help she still loses her mind but hopefully with adults it helps a little bit more it's it's not like you listener are no longer the english police you're just helping them look i don't make the standards rules yeah you know i'm just the ruthless enforcer yeah i had nothing to do with this cupcake rule if they were up to me honestly you can have 15 cupcakes but i just sorry sorry and then she says i sincerely apologize literally every time she says go ask mommy oh man which is why you all need to be on the same page because otherwise your your co-worker will say go ask manager or whoever that's right go ask the person who cares the least about code

reviews and get the like blind thumbs up whatever man ship it yeah yeah i was thinking call them the accelerator the code review accelerator yeah i was thinking that the problem here is we don't have a level playing field i think all your code reviews all your documentation and all your code should be written in esperanto ah yeah okay everybody comes to the table with the same i don't know lack of understanding what is what is esperanto esperanto is a language that was instead of evolving it was invented and uh it's it's very consistent and allegedly pretty easy to learn compared to other spoken languages and it's been proposed that esperanto could be like the universal language that humans communicate with and then everyone would have their natural

like second language that they were born with but um anyway i i actually there are dozens of esperanto speakers there are literally dozens dozens with a d like i think um i actually think this idea might be pretty good for international teams yeah i don't know i i've just i really have been wanting to learn esperanto recently i think a lot of the esperanto speakers are technical people because i think the idea of like grammar is confusing and all these rules are fuzzy and don't make any sense what if we just made it make sense yes that'll solve all our problems and it's really it turns out it would not oh come on give it a chance at least i will not because there are social problems that the reason i speak the language i do is not because other languages

are inconsistent it's it's complex anyway that was only half i shot your idea down totally i think esperanto is fascinating but i am skeptical that that would ever ever work in the real world maybe one day when we're all enlightened yeah i guess how do you say enlightened in esperanto no idea no idea how comes the google translate is there a google translate for esperanto i'm sure there is those nerds gotta love their esperanto clara hang on clara that's how google told me to pronounce it enlightened is that what she said or clear enlightened yep i can't i got lumiga lumigita lumigita okay every esperanto adjective ends in an a how is that for awesome

awesome uh all right so that helped uh what else what other helpful what other helpful point can we make now if it's spelling you're worried about then just install a spell checker in the cr tool easy i said cr code review tool easy peasy no problem if it's grammar you're worried about that's a little harder but there are still grammar checkers just automate it like spending time on this stuff as a human is such a waste of time i mean sometimes you're right sometimes meaning can be lost through grammar errors or spelling mistakes but i would say automate it as much as possible so that you aren't sitting here policing things it seems like a bit of a tricky problem to spell check code because yeah there's all kinds of weird stuff there's like weird

abbreviations there's there's you have to like tokenize all of the tokens again so like a method name might have five words in it all smushed together and you'd have to break those apart and spell check them and i think i've seen editors do this really yeah i think so i guess i used eclipse way back in the day in school and all i remember is my whole screen was full of squiggly yellow lines maybe it was doing that i don't think it's that hard of a problem honestly and for spell check and then for grammar check and comments and grammar check in your code review description or git commit messages also shouldn't be too hard right i don't think i've ever seen it done but surely it couldn't be that difficult these days that's an interesting idea well maybe

i'll check it out if not you could write a chrome extension to do it i bet yeah so here's the worst case scenario i go down a rabbit hole of this i find oh dear dave our code base has 15 000 spelling mistakes and then i spent two days fixing them all and make this giant giant pull request that like conflicts with everything you would never know how yeah i would never be so foolish just to waste my time and ineffective things like that but really at the end of the day what's the difference between a spelling error in a function name and a white space indentation problem i mean i guess they're both distracting but if they're just obvious if the spelling error is an obvious typo it's not that much more distracting than a white space issue so why

not treat them the same and automate it yeah i don't know maybe i'll try it and see how horrible it feels or how good it feels maybe you will get lumigito lumigita cool any any other wisdom to shed on this question advice i would give is don't bring it up unless it makes a material difference unless you can see that there's going to be direct and pretty significant impact from the spelling or grammar error just don't bother you know i don't know life's too short basically like i would say try to get over it yourself it really isn't that big of a deal unless it is if it is a big deal and it changes the meaning of things then you know if you're reading this and saying wow if a customer read this or if another developer reads this they're going to get the

totally wrong idea we need to fix it that's a very different situation from oh i before e except after c you know like this is not that big of a deal i would say for more customer facing things like documentation it might be a bigger deal for sure internal stuff i don't know i i could i could go either way i guess it depends on the level of professionalism that's needed right yeah yeah like if if if you're writing i mean some of your code comments turn into documentation if you're like building a very strong interface that other teams will consume it might be pretty important there if it's just like the spot where you put your daily journal entries you just put them in as comments in the code wherever you're typing to add a little flavor then it might not be as important

and and actually spelling errors would be part of the art in that absolutely i'm gonna do that i'm gonna submit my next pull request and it'll be like this morning i woke up at this time i was really just thinking about this episode of the office i watched last night and then the last line of the comment will be increment i by one useful and artistic that yeah that is it yeah all right anything else to say about this question have we answered it i don't know we're kind of wishy-washy what you didn't come down on one side or the other about should he bring it up i think you should ask the team if it's worth making an explicit expectation around it and if they don't care then say no worries mate or

whatever however you say it in your native tongue i i do think that you know one more quick comment here is reading into the question it says sometimes i feel like i'm nitpicking like that's a really good signal if you feel like you're nitpicking you're probably wasting someone's time right to some people i think some people feel like they're always nitpicking i think if you are if you're inclined to make people happy then any input that slows down the progress of their code from pull request or code review to production it feels like a nitpick oh i see i see even if you discover like a major issue that like a bug or no no i'm saying nitpick is like the baseline level of like every comment is like this might be a nitpick and i mean there are definitely more

serious things i so i'm talking about myself dave and other people like me but often in code reviews i feel like if i if i deleted everything that i felt like oh this might be a nitpick then i would just be the the code review accelerator man i just thumbs up everything so you feel like almost everything you write is a nitpick i feel like i have to fight against the inclination to consider everything i write as a nitpick okay okay and and i think when i step outside my like just make people happy at all costs default viewpoint then i i think that a lot of the feedback is valuable and helpful and i care about giving it but just the incentives in the moment are like ah just say it looks fine you know yeah so they can ship it and get on with their lives

yeah for things that aren't just like it's totally broken okay all right well maybe i should take that back then i'm trying to make you waffle well mission accomplished you're not supposed to come to a conclusion you just nitpick the crap out of me i have no more nits you've all been picked i think i like your advice of seeing if you can automate it i also like my own advice of trying to set clear expectations i think some combination of that and then just like if none of that works or if the if no one else cares that much and it's not super public maybe just deal with it i think that seems like a reasonable solution to me just bottle it up deep down inside save it for the retrospective in like four or five months from now

all right that sounds like a great outcome in march it's august what are you talking about all right question answered question answered all right i'll read our next one okay this also comes from an anonymous listener who says hi david jameson i really love the show i'm actually a hardware engineer but we need soft skills too so hopefully you can provide some advice all right hardware engineers okay uh hardware engineer writes this is my first job out of college been there for 2.5 years it feels like my manager is always firefighting and not able to be proactive trapped by the tyranny of the urgent it seems like our group is always behind on deadlines

trying to catch up and we've accrued large amounts of technical debt with little to no time spent on improving our processes or tools the end result is that we produce a worse product and documentation than we could or should be which causes additional support required down the road further loading down the group what can i or my manager do to improve this situation is this situation more common than i think yes i think that's the default state of technical teams you were like you sounded so downtrodden when you said that like oh downtrodden i was going for like gravitas oh yes like i don't know focusing on the short-term costs causing long-term problems yeah that's that's i feel like i've seen that at every place

i've ever worked you've worked at a lot of startups too so even more so yeah that's true and those it's like the short-term problem is our company will not exist so that does trump long-term problems a lot of the time you actually don't have any long-term problems yeah the long-term problem is like i go get a normal 40 hour a week job for less stress can i just say how much i love the phrase the tyranny of the urgent oh it's so good trapped even trapped by the tyranny of the urgent there's a little alliteration in there what an eloquent person we could call that the ttu trapped by the tyranny of the urgent see that really adds to the eloquence if you turn it into an acronym absolutely i think wasn't it a james joyce he was all about acronyms i don't know

james joyce remind me who that is oh he wrote ulysses and he was not all about acronyms no solving this problem i feel like is one of the key roles of a manager like they're part of their job is to look ahead and solve second order problems the immediate problem is we need to get this feature done we need to fix this bug we need to help this customer and then the second order problems are like we are not getting enough feature features take too long to get done in general we're spending too much time firefighting our our app goes down in production too much like how do i change the day-to-day stuff that comes up by doing other work yeah um it doesn't mean that you can't think about it but i feel like this is this is a pretty big part of a technical

manager's job absolutely and boy is it hard to see right i mean it's hard to know what's causing you like okay you slowly get slower and slower yeah and then one day you look up and say we are really slow yeah why is that yeah i think it was a camille fournier in in the manager's path i think she said that debugging the team is slow and i don't know why it's like the hardest managerial problem you can't profile it yeah there's no flame jar yeah yeah lots of times it's it's just very hidden stuff well i can't give up my twitter time i mean how would i know what the day's news is if i don't spend my four hours on twitter yeah for sure i'm sure that's not that easy i'm sure no that's like the have you heard about the

duck thing uh no where i i think it was designers some designer was like i just put a duck in everything so that it gives the client something easy to take out so they can just say oh it looks great give her that duck oh yeah that's the hair that's also called the hairy arm principle okay i think hairy arm principle i've not heard it described that way basically if you begin your team's career by having them spend four hours a day on twitter then when someone's like it seems like your team isn't getting enough done you're just like oh well i guess we'll stop spending half our time on twitter then then you speed up problem solved yep or yeah that happened in it was in uh some video game engine too they just put in a loop that did nothing to like make sure that they could

keep under the performance budget so by the end of the development cycle when the app was when the game was way too slow and they had to fix it up the like secret chief warlock engineer just went in and like deleted the oh my gosh empty loop and then we're like i solved it it's fast now oh my goodness so maybe that's what's happening they do that with memory too they'll just allocate a giant buffer like put nothing in it and then free it up at the end of the project yeah and then free it up at the end when when they're way over the limit uh that's called sandbagging i think is it i think so right and you can sandbag when you make estimates but to deliberately perform at a lower level than you are capable of yeah and then later you can

pull out the sandbags and now you can perform better huh well it sounds bad when you say it that way dave well it didn't exactly sound good when you said it well i i thought it sounded like a great idea okay uh yeah so don't do the thing i said yeah i mean not that it's not that it's even possible right like yeah okay everybody take two four hours a day and just do nothing so that in six months when we have tons of technical debt we can appear to go faster yeah the point of that was not like try that the point of that was that's probably not what's happening so it's probably not an easy fix like saying hey just don't do that really dumb thing um what should this person do well i think as an engineer you have a responsibility to the company and to your

manager to identify sources of slowness and call out how they impact the business in tangible ways that a decision maker can understand and act on. So like, you know, if you have noticed that your tools are causing you build time pain, that's slowing down your builds or causing iteration or lots of rework, track it, put a number on it, call it out and say, hey, our releases are taking x days longer than they used to and we have this many like turnaround what's the word like rework cycles compared to what we had six months ago i think we need to spend some time fixing our tooling and we can reclaim this lost time yeah um i mean without that you just are like well things are slow and i want to take some time to make them fast and

and my first question as a manager is how slow are they and how fast are you going to make them and how long is it going to take you to do it and so if you have some answers to those questions you can get traction yeah i really like that point giving data around the cost of the current bad practices because it's one thing to just say like man it feels like i'm fighting fires all the time but it's another one to say the on-call engineer or however you distribute it spent x percentage of their time fixing bugs or or not even fixing bugs just like poking the system until it worked again or responding solving the underlying issue yeah exactly or like they you Or doing support or yeah, whatever the work is.

Exactly. And you probably have a way to track that. That one's pretty easy for on-call stuff where you have like a help desk or a ticket queue or something to keep an eye on. It's just the day-to-day engineering that runs slow. And you're like, why is this running so slow? You can't see it.

It's so hard. And that's what technical debt is. And you can't pay technical debt unless you have a bill. And like a credit card debt. If you have credit card debt, but you never get a bill, how are you gonna know to pay it and how much?

But if you have technical debt, you need to provide some kind of bill and um like if you can point out bugs or if you can point out qa time or you can point out uh feature delivery time that that has changed over time and a lot of these things are really hard to measure and i think that's what makes it so hard for engineers to call out technical debt because you can't just say like well we used to be able to do 10 features a week and now we're only doing six like features don't work that way right yeah and and even if they did usually the individual contributors aren't in a position to track all that and keep track of it in their head themselves yeah for sure it's usually that's the manager or product

manager or some someone else's job so you could do it but it's hard and that's a lot of extra work which would take more time away from doing your other work which you already don't have time to do because all this other stuff in extra detail that we didn't read at the beginning the question asker basically says they've talked to the manager about it their manager has commiserated with them and they felt like their manager agreed with them, but then just never did anything about it. Yep. Classic management technique.

Tell me about your concerns. Wow, that sounds hard. Boom. There. In just those few words, you're now better than 90% of managers. I guess. Yeah, that's true.

That never happens. Well, okay. But yeah, to get to the 1% you have to say, and here's what i'll do to fix it yep or say here's what you can do to fix it it sounds like you need to do it yourself then if the manager isn't going to do it have you dave have you ever read turn this ship around no it's a classic like business erotica book about it's it's about a uh submarine captain basically who who became captain of a failing submarine and helped it become a very high performing one and one of the phrases he always

repeats in the book is i intend to so as a as a member of an organization you can wait for people to give you permission to stop to do stuff or tell you to do things but in his ship he he changed it so that people would just come up to him and say i intend to do this and if he really hated it he could say like no don't do that but most of the time was just like yeah sure that sounds fine so instead of waiting for explicit permission or saying like here's this problem and then just kind of sitting there you could say here's this problem here's what i'm going to do about it here's how it will help and then that forces your manager to either say like no you cannot do it in in which case things are bad or or hopefully just say like sure that's fine like if your manager's response

right now to bring up this problem is to be like yeah then i imagine their response when you bring it up and say and here's what i'm going to do about it will also be no i mean i think man at that point you've you've actually backed your manager into a corner and they have to respond with something either positive or negative they can't just go oh that sounds hard right now you're saying i need an answer yes or no can we do this yeah i mean maybe they don't actually believe it's that big of a problem and they haven't just been trying to commiserate with you and then when you say i instead of doing this other work i'm going to spend this amount of time doing this thing, because I think it'll pay off in the long run, then maybe you have a real

discussion about actual priorities. So my last company, I helped shape a mechanism that managed this. And I think we've talked about it on the show, but it's been a long time. So I'll restate it. We had our product roadmap, which is basically a list of features, and the value that those features expect to give and rough engineering estimates for how long they'll take to build and so on. But we had no such list for technical debt fixes that needed to be made, or infrastructure improvements, or you know, in things that a customer would never ask for, but that were nonetheless important to our customers being able to continue to use our product. So we created this thing called a technical roadmap. And so it was a parallel roadmap to the product roadmap. And when

teams went to do work, they were encouraged to take items from the technical roadmap and from the product roadmap at each sprint, so that things would get done there. And we had like a prioritization meeting every week where we would review the technical roadmap and decide what was most important and what would give the most value and whatnot. And I think it actually worked really well. And we started tracking like how often things are getting worked. And, you know, we had some problems where some teams would never pull items from the technical roadmap, they would only go for the product roadmap. And, and we had to fix that. But in the end, it was a great way to show management like, look, these are the problems. And one of the big questions we were able to answer

for each item on the roadmap was what happens if we do nothing and it would kind of spell out the doomsday scenario that would eventually unfold and it's important for management to know like do i have six months before this bomb goes off or do i have six years before this matters you know yeah so those are those are the kinds of things you got to tell management and if you go to them and say i want to build a technical roadmap and here's the first three items i want to put on it can we do this and have like a weekly session where we prioritize and then assign these things out to engineers i think that that will start a conversation and possibly lead to a much much better outcome yeah this is pretty high level work and it's it's i think it reflects well on

you as an as an individual contributor if you want to take it on because it fixing this kind of stuff has pretty big productivity gains across the team there's a limit to just how much raw stuff you can output by yourself, but the, where it starts to scale a little more is where you tackle these kinds of problems where say it's really hard to set hardware engineer. So you probably do some kind of, what is it? VSDL? Is that the hardware? VHDL. VHDL. Yeah. I don't know anything about it besides the acronym, but maybe it's really hard to write your VHDL and you make it easier so that now everyone else who does that does, does it a little bit faster. Yes. And my current company, we call that we call that activity being a force multiplier which is where thanks to your efforts

the rest of your team can work more effectively yeah i mean if you do retrospectives or if there's some form for feedback beyond getting the work done i think that's a pretty good place to talk about these kinds of issues too the danger with those is you just kind of gripe and then nothing ever changes but if you have if you're doing agile stuff i don't know how it works in hardware land maybe you do maybe you don't but there's generally a meeting where you talk about what we did recently and how it went and what we could do better and and if you can get the team on board with your ideas there that also helps a lot especially if you're doing this as an individual contributor it's hard to drive consensus among the whole team and if it's going to change how

other people work then then you kind of need to get their buy-in too whereas if you're a manager you can though you should not often do this you can't just say here's we're going to make this change uh so you might have to spend a little bit more time kind of getting consensus and making sure everybody understands the problem and feels like the solution makes sense and yeah absolutely yeah i think we've clearly solved it i think uh yeah right technical debt erased you could you could just declare technical debt bankruptcy and see how that shapes up yeah it might impact your credit score i think that's um that's called a rewrite isn't it i guess you're right yeah it takes a while to get out of that bankruptcy that's true you can never buy a house again

unless you're a company and then it's just like fine somehow i don't understand yeah you just go yeah you can just reincarnate yourself as a new company with no debt yeah perfect easy um yeah i i feel confident that we've answered this question it's hard this is a hard problem kudos to you for thinking about it and for working on it uh you you can definitely help and if your manager just shoots down all your ideas then um there's some pretty big misunderstandings about what the source of the problems are or even if they are problems yeah yeah definitely it is possible that they like firefighting too some people love being the hero they're they're adrenaline junkies yeah yeah it feels it feels great to be able to swoop in and

save people or to just help people and if you're addicted to that technical debt must just be like nectar for these hero types stuff is broken at 4 a.m i will solve it and by solve it i mean i will work around it yeah you gotta have a i mean you have to have a balance of that but it can you can get addicted to that interesting so let's answer this last question which i think we already talked about a little bit but just circling back is this situation more common than i think absolutely every company every tech company has technical debt there's just no escaping it the only question is whether you will manage it and how so if you bury your head in the sand eventually it'll it'll

get you so this specific situation of feeling like there are things that we should be doing to help resolve this long term but we aren't doing any of them that feels pretty unique i've always on every team there's always just been things that would be nice to clean up and things that cause us problems long term that we work around short term and there's always there also are always people that feel like it's worse than i feel like it is and people that feel like it's less of a problem i'm kind of in the middle surprising no one but this situation of like my manager doesn't believe that anything is wrong and doesn't want to solve any of it that seems a little weird to me yeah that's the unique part here that's true maybe you should calibrate with

some of your peers and say are these things issues to you or just me yeah cool all right we have done it we have solved this problem forever and in the process coined an awesome phrase called tyranny of the urgent are you taking credit yeah this is for since i mean i read it out loud right yeah and you know i picked this question so i actually i'm gonna just swoop in on top of you and say i coined this phrase nailed it yeah i agree with you you coined it's trapped by the tyranny of the urgent by the way right you are getting my trademark wrong and so i'll have to uh remedy that yeah that's a cool phrase what can people do if they want us to steal their cool phrases go to soft skills.audio and click ask a question then input all of your

intellectual property it's so tiny you can't even see it but there is a little terms of service there and an already pre-checked checkbox yeah and you can't uncheck it it moves every time you try and click on it oh that would be so funny i've seen that we should we we could add that if we want uh yeah if you if you submit a question we'll get to it thank you for asking your questions we've had a bunch of good ones lately and we're working our way through them so thank you so much thank you again to our patrons we really appreciate your support if you want to join their noble ranks you can go to patreon.com soft skills eng also follow us on twitter at soft skills eng where we post episode updates and interesting tidbits i think we will catch you next week all right bye