Soft Skills Engineering - Episode 477: Four months and I already hate my job and grumpy and fuzzy

Episode Date: September 8, 2025

In this episode, Dave and Jamison answer these questions: Hey guys, I have been working for four months at my job and I already don’t like it. This is my first job out of college and I work as a C# backend engineer for a small B2B SaaS company. I really think this company is a dead end. There is a lot of technical debt and antipatterns and we have no automated testing whatsoever. Most of our time is spent manually debugging but no one wants to refactor. I’m already thinking about working somewhere else. However, it took me a while to get this job, and I don’t think the market has gotten any better since. I’m trying to decide whether I should focus on applying to jobs again or if I should work on a bunch of side projects and open source to stand out better. On one hand, I can learn new technologies on my own to make me stand out for my next job, but on the other hand, I feel like as long as I stay at this company I am wasting time, since I’m not learning from my job. I want to switch to more distributed backend engineering in Java anyways, but I’m not sure how to go about it. Listener Ghani asks, “I’m a mid-level software engineer who has trouble communicating with my engineering manager and product manager when there is unclear or missing information about an assignment/story/project. They answer with hostile/dismissive tone/non-answer (e.g it’s on the jira-card, epic, etc). They course correct when they have the information later, harshly my impressions were they don’t have the information at the time they expect engineers to make decision they expect engineers to know something they don’t (e.g architecture, infrastructure, past decision, plans, etc) I really want to look for where we can have a safe exchange of information. How can I do this?

it takes more than replying thread to your own misplaced slack messages to be a great engineer this is soft skills engineering episode 477 i'm your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice podcast for software developers who spend about half their time trying to find lost slack messages and the other half of their time waiting for generative ai to write the code for them i'm befuddled by this intro are you replying thread because you want to be able to find it later i think you're applying thread to bump it back up on your co-workers notification list or is it because you are trying to shame people to say hey you should be threading this message but actually it's your own message so it's like a passive aggressive

call to use threads yeah that would be thread exclamation mark we have an emoji for that in our slack is it is it the thread emoji no it's a little little sock puppet guy oh and is he like made of thread no he's not i don't know why he he says use threads in the little oh above him but i don't know why this particular character is the one i don't know that's not what this is about dave should i thank our patrons let's do it okay thank you to these folks who changed their patreon name to something uh probably pretty befuddling to the folks that work at patreon i would love to get an email from the patreon people one day and be like what have you done yeah every time we send an email to our patrons it says the weirdest things in the in the greeting

yeah yeah how do we how do we tokenize these into first and last name exactly behold let's Normalize calling curly braces squiggly braces, even though they're pretty curly and not so squiggly. I'm a never-ending storypointer.com without AI. Woke up this morning, got myself a gabagool. Matthias, my actual name on LinkedIn, is Yammy. Debugging the dark canny, the mobile development ordinary. First of his name, quote, or one equals one, drop table meow mix.

Jacob Shandling. Bjorn, there's a very particular smell coming from your desk. Please create a spike to investigate. A missing semicolon. Christy, the world's okayest programmer. Noah Lamphart. what's up soft skillet nation it's your boys jnd here to drop some dope wisdom dope daniel remsburg nick molyneux if the service org uses a subsurface organ that controls that the subsurface

organ necessary pretend it's not javier gonzalez chewy ted timbrel princess simon candy cane lollipop chicken bach bach pop pop and dog blueberry pie applesauce snakes input length validator a single open parenthesis oh i appreciate that i think i've talked about that in the past and now now this is a now this is this list of patrons is actually a lisp dan from drone to play chase w norton never is not just a crater on mars flamingo emoji i like chicken i like liver miyamix miyamix please deliver trash panda swiss python summit in october how often do you fetch this took a while kyle voss ken c dodds that guy over there jenny kim the stochastic parrot quinton we have not heard from you in a month please go see susan in hr asap jonathan king's

beautiful functional user documentation you know what we got out now like good one should developers become business creators this episode is sponsored by hor and the rest of your message got cut off dan from drone deploy someone tell will angel how to get the https redirect working for www.vibechart.net ragnar braden canes john grant britney ellick ben and joe cabbage patch wimbledon tennis match thank you thank you one thank you all for supporting the show and for being willing to publicly i was going to say humiliate yourself but i don't think this is humiliating publicly stand out as someone with a unique name on the patreon user list and it's actually remarkable how almost everyone like 85 of these people have literally changed their

patreon profile name yeah i don't know what's more expensive like in terms of actual cost the the fee you pay every month or the the weird social capital loss by changing your profile name to this weird thing i would love to know if these people are patrons of other things as well and kind of what's going on there it'd be funny if some other like some other patreon thing does this and sometimes we see names that don't make sense to us you know because it's like i don't know it's yeah niche vertical yeah maybe that's already happened and we didn't realize i would not be surprised i don't realize a lot of things um if you want to join this group you can go to softskills.audio click support us on patreon where any amount will get you an invite to our slack

team and any uh i guess it makes you a member of the soft skillet nation to use the youtube verbiage and enough we'll get you a weekly shout out and our eternal gratitude we actually got some pretty harsh call-outs harsh in air quotes here from uh some listeners for not addressing them as soft skillet nation in our last episode like we promised oh yeah was it more than one person or was it the same person multiple times i don't know either way there were multiple pieces of feedback clamoring to be addressed the people cry out to be called soft skillet nation yes we are men of the people so so you're gonna do it shout out to soft skill nation yeah that'll have to be the closing though right like that'll be the closing tagline all right okay dave do you want

to read our first question i will this comes from someone who calls themselves close parenthesis which is beautiful because we had an open parenthesis yeah it completes in the patreon so now the lisp yes the lisp s expression has been closed all right so this is from mr or mrs parenthesis who says hey guys i have been working for four months at my job and i already don't like it this is my first job out of college and i work as a c-sharp back-end engineer for a small b2b sas company i really think this company is a dead end there is a lot of technical debt and anti-patterns and we have no automated testing whatsoever most of our time is spent manually debugging but no one wants to refactor i'm already thinking about working somewhere else

however it took me a while to get this job and i don't think the market has gotten any better since. I'm trying to decide whether I should focus on applying to jobs again, or if I should work on a bunch of side projects and open source to stand out better. On the one hand, I can learn new technologies on my own to make me stand out for my next job. But on the other hand, I feel like as long as I stay at this company, I am wasting time since I'm not learning from my job. I want to switch to more distributed backend engineering in Java anyways, but I'm not sure how to go about it. I want to challenge the premise here that you're not learning anything at your job. You're learning a lot about how to do manual debugging.

It's valuable. You're learning a lot about how to work in a code base that is difficult. And first job out of college, technical debt and anti-patterns. I'm also going to challenge that assumption. You do not know what the average professional code base is like. No automated testing. I mean, that's, yeah, that doesn't, that sounds rough. I don't know that I've worked somewhere with literally no automated testing.

But this might be the median code base. right and you think it's horrible because you haven't worked somewhere yet i guess what if i told you that all code bases are horrible yeah every code base that makes money is a nightmare in some way yeah and if you don't think it's a nightmare it probably hasn't made very much money yet yes or maybe you're the one who wrote it i think it might have been enough years that i haven't uh said this little quote about bad code that maybe i should bust it out again you think the time is right jameson yeah i don't know what the quote is but i approve of all your ideas it's like the best blank check of all time yeah okay so uh the quote goes like this or the quote

the coat that was a mix of code and quote it's a code quote a coat there's two kinds of companies those that are embarrassed of their code and those that fail you're saying that the company that spends so much time on the code base that it's it's beautiful it's probably not going to make it because they haven't chipped quickly enough is that sort of it that is for sure one avenue to get to failure but but also success demands trade-offs and rapid bad decisions decisions that are bad in the long term that that make you survive yeah yeah every code base is path dependent in some way if i take close at their word that's the first name i assume close um hey close hey what's up close maybe this is a bad code base yeah and people don't want to refactor

i mean actually not wanting to refactor it can be usually people that write the checks don't want to refactor yeah but say it's actually bad what can you do to learn and improve as a developer while you are working in somewhere with poor technical artifacts and or poor technical practices i feel like there's still stuff you can do to get better and that will give you experience and the answer isn't just jump to a better code base all the time or or if it takes you a while to jump ship you can still benefit from having a job not just because you get to keep paying for life but because you you get to obtain experience that will help you in the future yeah at the very least help you understand where the where kind of the i don't know maybe the word i'm looking for is calibration

it'll it'll give you one more data point on your calibration data set which will help you understand whether things are better or worse at a future place i mean here's an easy well here's an easy thing for me to suggest um nice not easy to do necessarily what if you were in charge what if you were the cto or vp of engineering or whatever the ceo's cousin however however they decide whoever has the final say of technical decisions you have your evaluation of the current state what would you do about it and this can be a fun thought experiment often developers will say like well we need to stop all development and fix this because it's such a mess we're not going to be able to we need to we need to invest so that we solve the underlying technical problems and

then we will be able to go back to building stuff for the company and if that's your answer that's a bad answer um uh that cannot be your answer because that is that is impossible if you are in charge of the company you have customer demands you have revenue targets to meet like the company has to stay alive yes and i i believe that if you say we just won't do anything except maybe break it right at the very the very best case is the customer will see no additional benefit for some period of months right and the worst case is maybe stuff will stop working that right works right and that's 100 of non-trivial refactors involve some kind of breakage yeah that's not a tenable solution especially especially refactors that were like this one that don't have any

automated testing whatsoever yeah i guess i'm saying that can't be your answer but i think you will learn valuable things if you step back and say what if i own this whole problem what would i do about it how would i yeah how would i improve things in a way that still provides some value to the business and correctly balances or correct is hard because i i think it's i think it's tough to empirically prove like this is the right answer but how would i have a justifiable reasonable answer and plan for for the business and the technology that that improves this situation because there's some trade-off there's another great thought exercise on this subject which is take the most onerous terrible anti-pattern filled code in your code base and

then just walk yourself through the hypothetical of what it would feel like to completely refactor that to push that code back up to get deployed to production and have it work i gotta tell you it doesn't feel as great as you might think you know like what i have found is that the idea of having clean refactored code feels a lot better than actually having clean refactored code in my experience for me it depends purely on how much praise and modulation i receive in response for refactoring it if it's this code that everybody hates and then i make it code everybody hates less like we can thank jameson for this yeah thank you for trudging through fire in flame and making it confusing in a different way now yeah now i'm at least surprised by the

new kinds of confusion yeah now it's novel yeah i mean this is yeah this i guess the underlying point is i think this is a problem you can learn from code is bad it's hard to work here okay what do you do about it how do you ship stuff and improve things technically at the same time That's an evergreen skill for every level of engineers. Totally is. I look at this question and I think, okay, this person has code they hate. Okay, I get it. But I actually think there might be a bigger problem here, which is I think this company itself is a dead end.

And that really sucks the joy out of anything else you could do. Even if you do successfully refactor all this code and make it all beautiful and wonderful and no more anti-patterns and you have a bunch of automated testing, then what if the company fails anyway like it doesn't feel great so that that's hard to overcome yeah that's a good point and and i should temper my advice by saying i don't think it means you should just go all in and dedicate your life to this company i think i'm kind of just assuming that you'll move on but like you said the market is tough right now how do you spend your time while you are looking for something else to do yeah and side projects and open source that's fine i think it's probably unlikely you will make a side project that's just awesome enough in your

free time to just get you a job i feel like most side projects i see are pretty shallow and i think a bad side project can be worse because it destroys the mystery yeah where if there's no if there's nothing i can entertain this idea that oh maybe they have great taste and could build excellent stuff they just haven't had time and i see it i think oh no no that's like that's like that famous quote it's better to keep your mouth shut and be thought an idiot than to open your mouth and remove all doubt. Yeah. Can I just say that I actually resonate a lot with this story because my first job out of college was also a dead end company. And it took me a little while to feel it or to realize it maybe even longer than this person because I

stayed there for about 18 months. But I remember working on this. It was a really weird software project. I don't know if I've ever mentioned this on the show before, but we were working in Java on this concept called mobile agents. And when I say mobile, you might be thinking, oh yeah like smartphone mobile like no not mobile apps that you know them today mobile agents that are able to package themselves up and move to another computer and then run on that computer for a while and then package themselves up and move to another computer run on that computer this is a like really fun academic idea that has no real world value or application yeah this sounds like somebody's a chair of a department somewhere that has written a bunch of papers about it it is

100% what this was. It came out of academia. And this company somehow procured a bunch of government funding to work on this and make some kind of weird, viable, semi-viable product that the government would then buy from us. And it was terrible. It was a huge waste of time. It was so dumb. And there is honestly, to me, nothing more demoralizing. To what end? Sorry, I'm just distracted by thinking about the mobile agents thing. What is the problem that solves? Yes, the problem that solves is my bank account didn't have enough money in it, and the government had grants available that would put money in my bank account. I believe

that was the main application for mobile agents. Maybe it's like a durable execution type of... I don't know. I'm going to stop. I will shut my mouth and preserve mystery that I'm smart. I spent a year wondering, just trusting that the people above me in this company knew what they were doing and had chosen wisely and yeah finally i went and found like some online group and i'm like what is the point of this and it was some of the people who had originally originally like conceived of this idea and built the initial implementation which by the by the way was an open source project out of ibm called the aglet project a-g-l-e-t ibm aglets i wonder if that you could probably google that and see but yeah that's what i'm gonna do now instead of

listen to you anyway so one of the people on that on that forum was like i said how come i don't see mobile agents anywhere except this weird project i'm working on and this guy's response was we just haven't yet found the killer app for mobile agents well it's 22 years later and we still haven't found it so it was demoralizing and i gotta tell you like it didn't matter like nothing i did mattered at that company because i knew that it was a dead end and i also knew that i mean i worked on this enthusiastically for the first six months of my profession and we went and took it to a customer site in the federal government

and we presented these things to them and they were like, okay, cool. And that was that. There's like no application. It was completely shelved. And that was devastating to me because I realized that I had put all this love and care into writing the code

and accomplishing all this cool stuff or that I thought was cool. And it was just totally useless. So I quit that job. I first found a new job, but then I quit it. I just could not handle it. And actually, I was so slow and dumb at the time that it took me at least one more project, maybe two more projects with the same outcome. The first one was mobile agents.

The second one was some dumb biometric thing that no one was ever going to use where we just cobbled together third-party vendors. And then some other thing. And finally, I'm like, what am I doing? Like, this is such a waste of my time. And I went and found a company to work for where my work was actually getting productively used by people to accomplish really cool things. and it was a hundred times more gratifying and I was so much more motivated and I just absolutely loved it. So I think there's nothing worse than being part of a company that you think is a dead end. And I would say, get out as soon as you can. Side projects, fine, whatever. Like you can do

everything on this list. You can start interviewing, you can do side projects, you can do whatever, all these things at the same time, but I would recommend getting out. It's just life's too short to work on things that don't make any difference in the world. Thank you for giving good advice and now to google ibm aglets no too late i already did i'm on the mobile agents page right now nice anyways um this is great there's some inspiring quotes especially by andy herzfeld who i think was a big deal in apple days it's the beauty of telescript is that now instead of having just a device to program we now have the entire cloud out there where a single program can go and travel to many different sources of information and create a sort of virtual service

and then the next sentence is the company was unsuccessful however because it turns out you don't need the code to go to the place where the data is you can just ask for the data over the network that's a lot easier it turns out can you imagine like a runtime environment for all your guys can you i mean the trust issues like there was all these certificate things that you like the code had to be signed before it could be shipped over and show that it was from a trusted source i mean it's basically like saying i'm going to create a runtime environment where any virus on earth can come and run on my computer yeah yeah no well i'm convinced don't work on mobile agents i believe that was the question right yeah i think that's what we

i think that's what we came here to answer no i'm gonna make one more attempt to justify my original advice which is i'm assuming you're kind of stuck there for a while and i guess my advice is like make the most of it while you can you can still learn valuable stuff even if it's a dead end and in some ways it frees you to experiment a little bit more because what are you going to do make the company not successful exactly i guess uh good news and no matter how much of a dead end you think that company is there's no way it was as big of a dead end as my company in my first year so i'd say there's probably a good chance you can learn a lot here and do some cool stuff you're better off than dave yeah totally totally this is summary all right have we answered the

question i think so good luck good luck dave do you want to read our next question i could but i feel like i'd be taking the opportunity away from you oh wait you're right this is me i will do it okay this is from a listener named ghani who asks i'm a mid-level software engineer who has trouble communicating with my engineering manager and product manager when there's unclear or missing information about an assignment or story or project they answer with hostile or a dismissive tones or a non-answer for example it's on the jira card or the epic etc then they course correct when they have the information later. Harshly. My impressions were they don't have the information at the time. They expect engineers to make a decision. They expect engineers to know something

they don't. For example, architecture, infrastructure, past decisions, plans, etc. I really want to look for where we can have a safe exchange of information. How can I do this? Oh, very interesting. Boy, I would love to hear the other side of this story from the product manager oh man i i think i do this all the time maybe not as hostile but it's so easy for me to think i know the context here and surely i've written it all down in this ticket and then i look at the ticket and it's like do the thing from the meeting and that's exactly all of the that's everything you wrote it's the only text in the ticket are you are you saying you're a terrible product manager jameson i can be i can be a pretty bad one at times you're capable of it

yep i can stoop to some low depths this story it resonates with me on a deep level like this is the plight of the engineer being given requirements or a specification that is that you feel is just insufficient to actually build the thing happens all the time i feel like there's a couple ways it could be insufficient and one of the ways is someone someone knows or some group of people the the information is out there it's just not communicated correctly or or effectively or in a single place so maybe maybe there is a spec and the spec is detailed and complete and you have to go find it or or go talk to somebody about it and it's in their head or whatever that's one case the information is there it's not there for you in the ticket to gather the other

case is i think scarier which is it's literally not there where you ask questions about what happens when this fails and it's the first time the person responsible for thinking about this has ever thought oh this can fail yeah oh shoot exactly like what happens if you said here you want to display the user's first name with an uppercase letter but 40 of our users don't have first names in the field you know whatever something like that it's like oh now what do we do and i call these things edge cases or i think product managers would consider a lot of these things, edge cases, but engineers have a really hard time distinguishing between what's an edge case that I can decide on and what's a case that's actually so core that it really needs to be

designed into the product. And that is a tricky balance I found where product managers want to do as little of that as possible. And engineers only think about that. And you wouldn't want your product manager to do like every possible edge case because A, they just don't know what they all are usually. And B, that would just be a waste of their time. You know, like they've got a lot of of things to do that's that's higher value so i don't know i don't know where to put this one but i've definitely been that engineer who's like hey what about this how come you haven't thought about this and the product manager is like like frustrated you know and i sometimes perceive that that frustration is pointed at me yeah can't you just can't you just make it work yeah exactly

and we engineers we love this stuff like we love getting into the little details and the weeds about oh what about this edge case oh what about that edge case oh i could write a monad to resolve this edge case you know it's things like that and product managers usually don't don't love it yeah part of it is we're probably going to get woken up when the edge case breaks the system there's some some ownership there of of it's kind of on my head if someone turns out to not have a first name and then yeah the code crashes and then i get paged some of it is i think part of what attracts people to software engineering is is this desire for deterministic things or or things that are correct with a capital C. We want to build systems that are correct. They handle all the

cases in the real world and the real world is very messy. It will continue to throw more edge cases at you that you have not thought of, but it can be gratifying to feel like I have built something so robust that not only does it work, it cannot not work. Yeah, exactly. Exactly. And I've proven it rigorously. Yeah. Behold my type system. Behold the leaning tower of dependent types or whatever yes i think there are a range there is a range of options for how to proceed with this and some of these options are going to be they're going to range from easy to impossible and one of the impossible options is maybe sorry bordering on impossible is trying to convince a product manager that they need to widen the scope of concerns that they need to specify in the

product such as you know like what happens if when an engineer comes back with that like pre-anticipate that stuff and that's that's something that just takes time and training and frankly not a lot of product managers are all that interested and willing to go into it but as an engineer you can you can apply a little bit of professional pressure to your product managers by saying things like i'm sorry it feels to me like this feature is underspecified because of the following six things. Now, would you like me to specify these and implement them? Or would you like to have a hand in it? Depending on how good of a product mind you have, that could be a threat or an offer to help. Do you want to see what my idea of good error handling is?

Oh, I remember I have a longtime friend and coworker who would kind of jokingly threaten product managers to build things like that. And his threat was, look, if you let me design this UI, I'm just going to lay out the widgets like command line arguments just left to right one after the other and when I hit the right edge of the screen I'm going to wrap them to the next line

so don't leave this to me little did he know that technology was beyond us in CSS for quite a while it was cutting that would have been that was the dream of web designers for decades

they were like you can do that to lay stuff out in rows oh my goodness what I wouldn't give and it word wraps oh oh to wrap to scroll you can scroll what this guy says he's not a front-end developer but wow i think from this architecture infrastructure past decisions plans etc that that piece makes me think that either the engineering manager or product manager

they have a bunch of knowledge floating around in their head that isn't clearly communicated and they have a hard time like we all do i guess understanding what the audience already knows and what they don't yeah this is a hard skill which part is the hard skill james the hard skill is i guess there's lots of hard skills in here one of the hard skills is knowing your audience well enough to to write things that include the stuff they don't know and don't write stuff they already do know yeah it doesn't leave room for assumptions or false narratives being filled in Yeah, and I guess the other hard skill is telling your engineering manager, hey, you need to communicate more and making them change so that they communicate more. And by hard, you mean this is a hard, soft skill, right?

Yes, a difficult skill, squarely in the vein of this show and our expertise, which is why I have such a great answer for what to do. Which is? Oh, no. Look over there. A distraction. Look, a distraction. wow have you ever seen such a distraction it's so distracting let's see i'm trying to think of how people have helped me recognize when i'm being unclear in this way i think they've just said it

they've just said hey it would have helped it would have saved us time if we knew all this stuff up front that that one got my attention a lot because i'm very sensitive i like to think i'm sensitive to trying to help the team go faster and areas where i've inadvertently slowed them down feel just painful to me so oh yeah totally this has overcome my distaste for meetings at times or or kind of restating things or whatever is is just this will help it go faster it'll take longer because they'll go down wrong paths if they don't have these assumptions so i think you could pitch it that way if you're getting these tickets and you think there's some underlying plan or architecture you might want to ask your engineering manager hey can you

just go over the whole plan with us we're not going to implement it all at once but it'll help me know what to do about these specific tickets. Help me have some context to hang this information off of. There is something else that I like to do, that I like to see team members do when product managers come with an underspecified product, which by the way, is 100% of the time. Because a fully specified product would actually be all the code is written and here it is. The code is the complete product spec. Or it's like binders and binders of documentation. I think you probably don't want to work in a world where everything is fully specified because it's nice to be able to get stuff done sometimes that's right and when i worked at a mega tech co one of the core like the

most sought after and important engineering attributes that was rewarded financially was the ability to deal with ambiguity it was the number one competency on the promotion chart was how much ambiguity are you able to deal with as an engineer and the more ambiguity you can deal with, the more we're going to pay you. And so here's one thing you can do to demonstrate strong ownership, apply really good professionalism, and I think move projects forward with the least amount of delays. And that is when you receive an underspecified product. Instead of coming back to the product manager and saying, here's all the places where you have failed to do your job. Let's talk about that now. Instead, you come back with your own proposals for how you think these

things should behave, along with the context necessary to understand them. So for example, like, let's go back to that example, like, hey, you've said here, you want to display the user's first name with capital first letter, but 40% of our database records don't have a first name, I propose we show a generic greeting instead, like instead of saying hello, comma, space capital D for Dave, you know, I would just say, you know, hello, exclamation mark, and that's it. And then just put that out there as a concrete proposal for how to deal with the situation. And then go one by one through the most important things on your list and bring those to the product manager. And this will have two very positive effects. Number one, it will allow the product manager

the brevity to just say yes if they like it or the option to discuss. And number two, what I have found is that when you show up with a concrete proposal, it prompts much better discussion to get to a solution. Whereas if you just show up with a proposal, or sorry, not a proposal if you show up just with a problem then the group will just kind of go around in circles well here's an idea and here's an idea but there's something about bringing a concrete answer like a straw man that helps a question get to conclusion and so if you do that i think you can you can really shortcut a lot of this time and you can also sidestep the potential perception from this product manager that you are accusing them of being bad at their job yeah it moves it

from a complaint to a a problem that you're all kind of standing around a circle looking at like huh what do we do about this exactly and that thing in the middle of the circle is not just the product manager yeah it's not it's not hey you you you messed up you did not tell me enough right hey you i love that idea it feels like it might be a little bit harder for the technical things because i feel like those might be a bit more unknown unknowns where maybe there's some giant abstraction over here that you're supposed to use or you can't look at the spec and know the pieces of the technical stuff you're missing yeah that that's totally true but and some of those discussions you don't even need to have other than to say hey just so you know the way

this product is designed the effort levels are going and this this is by the way this is one of the most important things engineers can do when interacting with product managers is communicate effort levels that come with product design choices like i i can't tell you how many times i've heard a product manager say if i had known this feature was going to take this long to build i would not have asked for this feature yeah yeah i think it is pretty rare that there are just these monomaniacal dictators saying like my vision or or nothing i will i would rather kill this company then move this drop down one pixel to the left. Not one pixel further.

Yeah. Yeah, I like the idea of being collaborative about it, bringing straw man ideas or it could be good ideas too, but just having an idea is the first part of it. Unclear missing information. I'm just trying to think about, they expect engineers to know something they don't. maybe maybe that means the engineer doesn't know the abstractions required to build a thing or

doesn't doesn't know that that thing exists i i don't know it can happen yeah i mean that's part of coming up to speed on a code base if they're frequent questions then you can write the answers down i think it's a good thing to do make it leave it leave it better than you found it it does feel bad if you ask your manager a question and they respond unkindly totally harshly rudely that is not an environment i would love to work in maybe you don't have a lot of choice and this is just where you have to work but i think there's a difference between working with people that don't understand what other people know and don't know and working with people that are unkind to questions because you you can't you can't just join a company and learn a code base

and not ask people that know more than you about it like that's it feels so expensive and i would i would hate that pressure of i don't know what i need to know to build this but if i ask this person, they're going to get mad at me and yell at me or type of frowny face in Slack or whatever. We talked about this last week too, about how do you work with juniors? And you mentioned batching up the questions. Maybe there's some stuff around there about how do you gather the information in maybe an easier way, but at the core of it, they have to be willing to share it with you. Maybe they're impatient because they feel like you haven't picked it up fast enough. Maybe there's something else going on there. Maybe they're frustrated with your technical

expertise or something like that yeah it could be and and you know there is certainly this phenomenon where engineers don't know what they don't know when they jump into a new area of a code base and they end up taking time that is really just ramp up time by going down the wrong paths and then you come back and you're like i'm still not done and they're like oh come on engineer you're supposed to be this is supposed to be your job you had one job build the product yeah but that's also just the cost of learning stuff sometimes it is you have to pay the price of developing your theory of how the program works enough to be able to modify it or you just won't be able to any software product manager who's been around for more than five minutes

has already experienced this like hundreds of times where the engineers are like oh we thought this was doable and easy but it turns out there's a dependency here we didn't realize and now we have to update the version of java on this server because we had to do this to get that whatever thing and that's going to take an extra sprint or whatever you know this happens all the time so obviously we don't try to do that as engineers we don't want to do that but product managers who have been around they should understand that yeah not that they're here to respond to that oh they're here i've got them right here in my closet they're all product managers they're so mad right now they're quite uncomfortable both because of the way they're

crammed in the closet and all the horrible bad advice we've given about them they're like i don't know where what's more uncomfortable my physical pain or my psychological frustration with your advice they're both really bad sounds like my work here is done david have we answered this question i think so good luck let us know how it goes yeah good luck what can people do if they want their own questions answered go over to softskills.audio where you can fill out our form and uh thank you to everyone who fills out that form so dutifully more than 40 of you put in your first name which is great and we love the made-up names too so it's almost like we give you an option to say you're anonymous but

quite frankly i'd much rather you be a fake name than an anonymous submission so thank you for all that really love it we love reading your questions and it just makes us feel like we're right there with you at your terrible job suffering aside you and it's there's nowhere else i'd rather be than suffering at your terrible job yes yeah i too would not like to be anywhere else than beside dave that is terrible all right jameson you're gonna give us an our sign off here oh yeah do i just say i know how they do the intro yeah i don't know i don't know it's it's it's your boys j and d soft skill nation signing off all right little little room for improvement but we'll get there i will do better next time i promise all right thanks see y'all

Thank you for watching.