Soft Skills Engineering - Episode 149: How to get my engineering career back on track and how to thrive in a heavy process environment

Episode Date: March 18, 2019

Joining us this episode is special guest Nedda Amini! In this episode, Nedda, Dave, and Jamison answer these questions: My engineering career started out pretty promising. But along the way, I took a couple of unfortunate decisions and jobs, that instead of helping me grow as an engineer, were a big setback. When you career takes a few too many bad turns, how do you steer it back to where you want it to go? I work on product development with ~25 other developers, and management recently had us all embark on a journey to gain some level of CMMI appraisal. The goal is to deliver higher quality software at a more predictable pace. In practice this means that we got more processes to follow, more meetings to attend and more time-tracking fuss. I’m trying to keep an open mind because I, as a programmer, also have high standards for the product and it’s development. I’m scared that programmers are being turned in to factory workers stripped of any autonomy. These new processes don’t allow me to do anything without my product owner’s approval. I’m afraid that it will limit my creativity and ultimately cause my work and the product to suffer. In this kind of scenario, what’s your advice for a programmer who often gets inspired to remove tech debt, tinker with our dev environment, and otherwise make small improvements and refactorings that shouldn’t require management approval? What’s your opinion on the level of freedom that programmers should be provided in order to do their job well?

It takes more than digging through technical metrics until your eyes turn red to be a great software engineer. This is Soft Skills Engineering episode 149. I'm your host, Dave Smith. I'm your host, Jameson Dance. Soft Skills Engineering is a weekly advice show for software developers about non-technical topics. Why would it make your eyes turn red? You know, just like, I don't know, you're just staring at the screen for hours and hours, scrolling and scrolling and scrolling. If they were, like, really good metrics, would it make your eyes turn green?

Or would it heal your bloodshot eyes? Yes, but that is not what this show is about. It's not about nice visuals for your failing metrics. Okay, good to know. And that reminds us, we have a special guest with us today. Hello. I'd like to introduce Netta Amini, who is joining us. Welcome, Netta.

Hi, I am a software engineer at CJ Affiliate, and I just waved at a camera that doesn't exist. I work on internal systems, but I also am a front-end chapter lead, so I specialize kind of in designing component systems, things like that. And I'm here to give the best advice I can, I guess. I don't know. We'll see. Well, you know, it doesn't have to be the best. You could, you know, we'll be good with second best. the best i can give my personal anyone anyone who listens to the show long enough knows that the advice is not the quality of the advice is not what brings people here okay good but i'm amongst the company then we have a low bar okay uh we'd like to thank our patrons we would like to thank matthew votovich no angel ventures

hold on hold on hold on oh no okay voitovich matthew voitovich we we need to apologize we've been saying matthew's name wrong for like two years i'm so sorry oh did you ever see the simpsons episode where he's looking for the license plates bart's looking for a license plate with his name on it and he only finds bort no and then there's a bunch of people around him who are also named bort no maybe that's the situation right now anyways uh yeah thank you to matthew voitovich the Agile Ventures Charity, Zach Grannon, Luis Santos, Nick Kantar, Sean Clayton, Sonic the Hedgehog, Maurice Rousseau, and Chris Hogan. Thank you so much, and thank you to everyone else who has supported the show. If you would like to do that, you can go to our website,

softskills.audio, and click support us on Patreon. All right, should we jump into it? Please. I'll read our first question here. This comes from an anonymous listener who says, my engineering career started out pretty promising, but along the way, I took a couple of unfortunate decisions and jobs that instead of helping me grow as an engineer were a big setback when your career takes a few too many bad turns how do you steer it back to where you want it to go this one was a really interesting one because it's interesting giving advice without much context but i i think there is something kind of holistic everyone can take away from this um let's hear it oh well i guess the thing is is that um i think this is something

that you guys bring up a lot in this podcast but it's the idea that you know you should always be interviewing you should always kind of shouldn't be afraid to go and look at other things and just because you're kind of in a position that i don't know maybe you don't feel like your technical prowess might be good like you maybe like a shop that wasn't pushing you enough um doesn't mean that you can't find a place that'll do that for you does that make sense and also it's good to just bomb interviews absolutely is so good yeah and they make it makes great stories yeah later yes in the moment it's terrible oh man aren't all good stories like that though yeah they're not good in the beginning but then afterwards and then later you're sitting around with your

friends all just having a good laugh at the expense of yourself yeah assuming you survive yes wait hang on assuming you survive we're talking about job interviews are you suggesting that there's like death traps in these interviews like i'm assuming that he was saying other kind of adventures but you know maybe it's a particular dangerous job interview who knows i don't know if you read twitter there's a lot of really negative comments about job interviews yeah it's like mr bond reverse this linked list before the laser chops you in half right that's exactly what i was thinking is that not what everyone else's interview process is like really confused we're filtering for people who can reverse link lists under extreme pressure threat of bodily harm or

death you see this laptop we're giving you has a usb cable coming out of it and a timer connected to the usb cable is an iot device which has a blade hanging above your head if you can get this test case to turn green before the timer goes off you can walk away in one piece ready you said iot so you can probably just like log into it with root root yeah as the username and password and turn it off yeah you could probably do that hopefully that was actually the test behind the test and that's how you got the pen testing job you wanted you wanted the javascript job but nope nope you did that one clearly uh i'm i'm kind of wondering like what what would make what qualifies as an unfortunate or or kind of negative job experience is it is it like

netta you mentioned a place that doesn't push you or that you don't grow i feel like there's also the potential that you could be working on stuff that's just like hard to communicate the value of to other people maybe your projects get canceled or it's really niche internal things that i don't know you you don't have much to show for it like what yeah what do you think that means i can understand like that i have also been going through this kind of existential crisis of and i've heard other people too where it's um you don't feel like the thing that you are working on dirt like is producing a lot of value outside um which i can understand like you talk to people and they're like i'm a doctor and i'm then you know systems like i do all these crazy things

and then you just sit there and like i just make a product that does ad tech like things like that and you just sit there yeah and it sounds super cool and you know don't feel super I optimize the conversion flow of yeah I don't know yeah not to not to I mean there's lots of valuable work but I see what you mean where some work feels like it's hard to communicate that value to other people like to me the the uh a big setback or bad job would be one where you're like on a dead-end skill set development track like I'll tell you an example like what mumps isn't that a database thing I saw mumps on a resume the other day I I've heard there's a disease called mumps there is but i'm pretty sure and someone named a database after it

there is some cognitive dissonance there the database was invented after the disease so they have no excuse okay that's just ridiculous and yes that might qualify it's like mainframe data processing stuff from the 60s yeah that's not exactly what i was thinking 60s technology like a stack that's not very up to date and has no like potential to be up to date a little i mean i guess if you're like a fortran programmer you're actually in really high demand nowadays so i'll give you like a i'll give you an example that's kind of an extreme example but i know someone who had a good like 10 to 15 year software engineering career but then the latter half was spent entirely on developing people soft

applications and after doing that for like five or six years suddenly you go to job interviews and people look at you weird you know and it's like are you just a people soft expert that's all you are you know and so it's like well now i can't get a job and so i think that's like salesforce or these yes these kind of locked in platforms that's yes a salesforce developer would be kind of like today's equivalent of that and like salesforce is not going to be around in 10 years i think most people will agree on that and so not i think salesforce man what's his name mark benioff i mean we've made a powerful enemy same things happen to flash right there was a whole group of people who are flash developers and then you know ample was like no and that just

completely put a whole bunch of people who are this kind of i don't want to say like one trick pony but like kind of you know they put all their eggs into one basket and i can see a job maybe forcing you to do that right sure um which is i think i mean i hate to say like you know you should work outside of work to develop your portfolio but um if it's something that's really concerning you and that's kind of a thing that you're doing and you want to keep a career in software development um it's good to um exercise uh your abilities outside develop yourself outside of work keep up to date with things absolutely yeah absolutely like another way i could see a job going off the rails like this would be like you get this job as a software engineer but then

there's this need to do something for the sales team you know and then the sales team loves you and the next thing you know you're kind of embedded with them and you're going on sales calls and then you wake up one day and it's been two years and you haven't written any code and and you're basically a salesperson you know and so it's like it's it's the same thing though where you are in a job you hate you didn't even realize you hated it it happened so slowly like the frog boiling thing right yeah so now how do you get out of it and i think netta you hit it just right on the head you got to be interviewing constantly and and what this means is that if you're in a job that you feel like isn't taking you where you want to go those interviews are probably going

to be really hard at first you know because people are going to ask you questions you aren't prepared for both technically and about yourself yeah and i mean interviews are a really good way to know what is like the most up-to-date on tech stacks and things like that too right i mean you can always get your information on twitter but yeah that's a bit too fast-paced you kind of want to see like what people are looking for uh what they aren't core skills how they're applicable things like that to being which i i have i haven't interviewed in a while so i was just thinking that i feel like a huge hypocrite because i don't i don't know that i do i directly say interview all the time i think dave says that yeah and then i sit silently because i interview every time i

switch jobs so i'm worried if i interview more that means i'll just switch jobs more i mean there are people come and ask or talk like you know you have like recruiters reach out on linkedin and it's always good to like you know follow up a bit and just be like well what is this position what does it entail i don't always go directly into the interview process of like doing the you know doing the on screening and the screening and stuff like that because that's a bit of a time commitment but it's always good to just see what's out there you know yeah so interview more practice outside of work on your skills a little bit what about i feel like there's probably a confidence it would it would be a blow to my confidence if i felt like i started

off really strongly and then i just ended up in a place i didn't like what do you think this person could do to kind of just restore their own belief in their ability to be a talented developer there's community stuff there's there's outside project building things like that too um open source is a very it's like an open world that you can mess around with i don't i don't know if that's a great way to build confidence but it's a great way to practice and mess around and i've got it you start and win a technical argument on the internet oh there it is just get a lot of twitter followers and then you're set that that'll just get you the job every time you feel a little jolt of imposter syndrome you just count and you say that's way too many people to follow an imposter

no one would ever follow it not that many people follow an imposter yeah you can do that and then you need to like start arguing with someone about tabs and spaces then you're set yeah the problem though jameson is i've never seen one of those arguments be won by anyone wouldn't it build your confidence if you were the first person to win though i think the real winner is the first person who like you know signs are off first who just stops responding that's the real winner of any internet conversation yes you get you get points based on how many follow-up comments you get from the other person that you don't respond to this is this is great advice for especially for being on the internet okay uh so troll your way to confidence got it yeah i mean the confidence

thing is though a big thing but yeah i mean i don't know you could have low confidence and be at like a job you tend to enjoy as well so yeah i don't know to me confidence as an engineer takes time and like and on the time scale of years like i don't think there's an activity i could engage in to be like ah now i'm confident after a few hours days or weeks even months i don't think i was really confident as an engineer until i had been at multiple companies had been through lots of review cycles had worked with lots of other engineers and seen how they work and then i could say oh yeah i can do this like i'm not the best not the worst but i know where i am and i'm decent at this yeah there's a bit of a confidence boost at like trying something

that three years ago would have seemed really daunting so i think it's always good to review what you knew before yeah sorry jameson you were trying to say something i was trying to engage in the regular activity of jameson tells stories about his dad podcast so i used to go golfing with my dad when i was a kid and he was pretty good i mean he wasn't like fantastic but he was he was solid but every time he would walk up to the tee to hit a shot i guess i'm assuming people know stuff about golf you hit a little white ball with clubs you like start off in one spot i love how you just i love how you just described an entire sport in like one sentence that was great uh it's really expensive that's the other description of it that's why i don't play it

um but before he would shoot he would just like look down at the ball and say i am great and then he would hit and like half the time it would not go very well and he would just put another ball down and look down at it and say i am great and a hit and then be like yeah like that's so powerful i am i knew it and it sounds so like cheesy and motivational when i say it but i sometimes think about that like i don't know this is like the ultimate sample bias right because it's like i am great and until that ball goes where i want i'm gonna keep saying it until the ball tells me i'm great yeah yeah and then and then when he hit a good shot he was like yeah like see i don't know but that's the thing though is like if you had that level of like confidence and everything like

that that's a key i want to unlock maybe that's what i just need to start doing it's just like yeah, I'm great. I can do this. Jameson, you've shared a lot of advice from your dad and it's all been good. This one just strikes me as kind of weird. No, this is perfect. That's a good description of him.

He's great and he's kind of weird, just like me. So let me say, I think what you're saying is, say you're great, keep swinging, even if you screw up, which you will, keep swinging and eventually you'll be great. Yeah, like I have this tendency to be like, all right i'm gonna i'm gonna try and hit and then if i hit the ball and it goes poorly then i think like see it proves that i suck and that's not being confident isn't like never

messing up or getting anything wrong that's just being perfect and then it's not confidence it's just like how reality is but i feel like there's something to to recognizing that you can do good things even if it doesn't always go perfectly yeah it's having faith in yourself yeah all right This analogy went from weird to pretty good. Okay. I'm glad you saw it because the second I heard the I am great whispered to a golf ball, it resonated with me. So you're saying, okay, go sign up for an interview. Yeah.

Sit in your car, rub your temples, look in the rearview mirror, say I am great, and then walk in there and just fail spectacularly. And then do it again until I am great is true. I'm thinking of another emotion you could have where you look down at the golf ball and just whisper like, I'm going to smack the crap out of you, you little stupid round thing. And then you're fueled by rage instead of confidence.

I mean, that's how I do most things in my life. I'm driven by the light. That's what I do when I take on Jira tickets. Depending on, you know, just so you know, like I am great is I think a great thing to say, but depending on your alien race, you might want to say I am Groot. Okay.

i gave it a chuckle i gave it a chuckle we got something there dave i admire your confidence i can imagine you before you said that saying this pun is gonna be so good this is gonna kill yeah actually i just said i am great and then i lunged into the pun well have we answered the question i think so get out there get your confidence get interviewing you gotta do it it's the only way to get out of a crappy job and get a good job is interviewing that's the only thing between you and the next good job and you got to do a lot of it and you're gonna have to do more of it than you used to have to do so brace for impact be prepared for rejections and go for it yeah practice log what you've done learning logging is also a great way to um boost confidence

so do those things that's really good actual advice it slipped in there at the end i like that finish line yeah finish line advice yeah okay let's uh read the next one i will read it this is from another anonymous listener i work on product development with about 25 other developers and management recently had us all embark on a journey to gain some level of cmi cmmi appraisal cmmi stands for capability maturity model index i index okay uh the goal is to deliver higher quality software at a more i was wrong sorry back it up confidence integration okay cool uh i know that this question hinges on what the letter i stands for okay uh in practice this means that we got more process to follow more meetings to attend

and more time tracking fuss i'm trying to keep an open mind because i as a programmer also have high standards for the product and its development i'm scared that programmers are being turned into factory workers stripped of any autonomy. These new processes don't allow me to do anything without my product owner's approval. I'm afraid it will limit my creativity and ultimately cause my work and the product to suffer. In this kind of scenario, what's your advice for a programmer who often gets inspired to remove tech debt, tinker with our dev environment, and otherwise make small improvements and refactorings that shouldn't require management approval? What's your opinion on the level of freedom that programmers should be provided in order to do

their job well i guess for the class we should probably define what cmmi is oh man this probably means i have to do it yeah i can read it off of wikipedia which is what i did earlier but so i lived in cmmi level three for about seven years at my uh oh boy a long time ago about 10 years ago at a different company uh oh more than 10 sorry a long time ago basically it is a process for tracking development artifacts to make sure that you follow your own best practices as prescribed by this institute that lives in the clouds and just showers down enlightened process on your company.

And basically it means you have to produce a ton of paperwork, but it has basically no opinion on the actual engineering practices you follow when you're writing code or deploying or things like that. It's more like requirements, traceability, verification, stuff like that. And it tends to be tightly coupled with government contracting, which also tends to require very detailed time tracking for billing purposes. So these things tend to come part and parcel. So there's CMMI in a nutshell.

I didn't quite describe it as succinctly as Jameson described golf. You'll get there. But like golf, CMMI is very expensive. it so wikipedia tells me there are levels one through five level one says process unpredictable poorly controlled and reactive does that just mean like yeah everyone is automatically on cmmi level one yeah actually the cmmi level five people are also on cmmi level one with a lot more documentation i yeah did you was it a goal to to bump your level up a couple more yeah oh yeah absolutely like we got level three you know and what that means is you can bid on more government contracts

but you have to get five to bid on even more contracts you know different kinds of contracts okay is there a secret level beyond five it's like the unlocked it's level six yeah you only know when you get to level five that there's more exactly the wikipedia page changes only for you it's really weird but it seems like they do a lot of this for like auditing purposes too right like because they need to people need to come and make sure they're doing the right things and that i guess all their ducks are in a row things like that oh yeah i mean that it's like a circular thing though it's like because in order to maintain your cmmi accreditation you have to be willing to be subjected to an audit every year or two where they come in and troll through all

your artifacts and make sure your requirements trace through and things like that so it's it's not so much like the customer has valuable audits they want to perform it's more like the customer agrees the vendor agrees that we want to be cmmi certified so here's the audit you have to do okay yeah yeah i can get that i mean i think lots of um lots of organizations like financial and things like that do some process of auditing um so i guess even if it's not cmmi there is a bit of process that a lot of tech companies go through um whether it's self-select or not uh to make sure that they're up to snuff i know that we do kind of like socks auditing and stuff like that yeah we do pci stuff in practice that means like my team mostly doesn't

it means a bunch more work for me to shield them from a bunch more work yeah and there's so many of these things right like hippa has its own rules iso 9001 all these different things but you know what's interesting that i found even though there's all these super rigorous processes and audit methodologies at the end of the day the comment that really stands out to me is i'm scared that programmers are being turned into factory workers stripped of autonomy because this person is worried they won't be able to do things without their product owner's permission and you know what i find really striking about that is that i feel like modern scrum teams actually can easily fall victim to this same thing where it's like everything you must you do must have a ticket associated with

it and the ticket was put there and groomed and prioritized by the product owner and i'm like it's not that different really and i feel like this trend is happening across the industry and it seems to cross-cut both agile and these like process waterfall process heavy things like cmmi um yeah so uh about the whole process thing and and you know i mean i'm in a pretty agile tdd xp kind of shop and i mean the whole thing with the tickets and stories is that each ticket should have user value right and it's sometimes can i ask you to back up for one second i think there might be people listening that don't know exactly what you mean by uh agile or xp probably a little bit less familiar so uh xp is extreme programming and so it's a lot of just kind of uh we do

everything pair programmed um everything is test driven there's no like we can't really submit code without tests um and and we're just like an agile shop so uh i i want to make sure that i'm actually defining as agile is and not just how we do it i'll just explain how we do it um we do uh two week iterations like sprints and you know retro we do have story time in the between and um oh no sorry i'm having some cat issues that is adorable uh okay um where was i right so two week iterations and everything is kind of done via stories kind of like um what dave was saying and i don't know is that a good summary i don't know uh i don't know every time i hear the word extreme programming i just think of like it sounds really radical doesn't it right people

jumping out of planes with like their fingers extended in the rock and roll gestures yeah it sounds way more intense but a lot of it is that we we pair like nothing really gets into the code without uh without being paired right so that's what we do um what else uh we we actually don't have like a qa like we don't have that at all um we like because we have everything test driven we we just kind of use that that makes sense so unit testing and i mean in the absence of that it would be like code reviews but we don't really do that and then you know continuous development things like that there's also just the yeah the ongoing speed metal soundtrack yes all code is written yeah it's an open floor plan and then there's just like death metal playing it's pretty intense

sometimes i can convince them to play like nordic death metal which is a little bit more somber but special occasions i can just see like people's hair blowing by the subwoofer as they're focusing on their programming yeah it's very intense but it's it's i don't know it it's um it's hard to get used to but it's it's fun i like it you know you're really locked in with a pair when you start headbanging at the same rhythm that's when you're in a flow state they know not to talk to you when you're headbanging but yes uh so the whole idea is that uh back to the process thing is that every story is technically supposed to be user facing like what kind of value are you delivering to the user

and it's hard to kind of say that you know we're doing this off kafka upgrade it's hard to kind of sell that as like a user-facing value um which is i mean you you can say it is like if we don't do this upgrade in x amount of x time you're gonna have to have more developers rip kind of out this whole infrastructure to replace it um but there's something about just kind of doing that refactoring in the context of a story so you're just kind of cleaning up where you are you're in a bit of code and you have to update a bit of things you refactor that function and you clean up that unit test so that it makes more sense and kind of rolling it into the current work that you're doing so do you do you get your product owner's permission to extend the time span for a single

story in order to do these tasks or do they are they just blissfully unaware we do like estimate things up front and so a lot of times we will say like this part of code is is very old i work in a pretty big legacy system too it's like this product code is really old and it's going to cost us to go and update this feature because maybe this feature can't even be done in this current system so we might have to do some refactoring and um we we let them know sometimes and like you know sometimes it's a hard pill to swallow and sometimes like sometimes the product owner will say you know we can't do that right now and and that's when you clearly explain to them like you are cutting a corner right now and you need to be willing to accept what happens afterwards right you you have

to be accepted like technical debt has cost and you have to like your job is kind of like when you're estimating things is you're saying this is what you'll cost you and as a product owner you have to weigh those costs right and see like as an example is like okay if you choose not to do this now you may go out to the parking lot this evening and find your tires don't have any air uh yes that's when you flip the switch over to was it nordic black metal yes yeah i might have said noric um norwegian black metal where it gets really scary and somber um no it's just where you say like we're not going to upgrade this thing but you know we're going to be three versions behind and you know they're going to deprecate this system and we're

going to be behind and it'll just be more painful down the line and i mean we've done it we've had to have occasions where we have we have to have the whole entire floor take a day off so that we can upgrade this entire system and you know you eventually have to explain to your product owner your product in general like you can avoid all of those hours of uh developer time which is money for the company where they could have been doing other things not spending that whole day doing that if you had just you know allotted a bit more time earlier yeah it's a battle that you you gotta of it's like picking your fights right yeah i feel like i really like what you said about couching it in terms of cost to the company if they don't do it because i don't know i'm a

developer i know that there's part of me that just wants to go fix everything all the time and there's always something new and shiny out there and and if you just ask me like hey what should you work on to make this better there's a chance that the the list is infinitely long of things that that would make it better but um i don't always just immediately think of it in terms of cost to the business and what would be most effective so i think if if you really want to justify investing in technical infrastructure or dev tooling or things like that the the easiest way to speak that to the business is in terms of money and loss productivity can often be a thing like speed of deploys or speed of onboarding engineers or things like that um yeah but if

if you can somehow turn it into a number instead of just, I feel like there's a tendency to hear developers complaining about technical things and just think it's the developer crying wolf. Like, oh, they're developers. They always complain about tech debt. That's what they do. And so you need to kind of make it stick out from that a little bit. Yeah. I mean, I've done things where we will log, we'll log like how many hours we spent working on bugs for this one system that's technically not our domain right it's it's we have ownership of it but it's an old legacy system that keeps breaking and at some point we were saying like you know 30 of our story points for that agile week was spent on this broken system

so and this is spread across you know multiple multiple iterations multiple months so you can see how we're not releasing the product that you really want us to release faster because this old thing you won't let us go fix this old thing and we can estimate how much it'll take for us to just go and do that for a couple weeks to fix it um and and coming to them with like metrics it is like it takes time you have to take time out of your day to like set that up but a lot of times coming to them with the like this how many hours of my time which billable is this much because let's I work X amount of hours, and this is how much I'm paid. It's going to cost this. This is what it's costing you to not upgrade this. And you're doing CMMI level whatever,

so you have all that documentation. Yeah. Right? Yeah. I'm not even logging my time as much as they are, I suppose. But yeah, if I've learned anything, it's hard to explain technical debt to people who are not engineers. So you need to kind of frame it in terms of business value and money sometimes. You need to kind of frame it in a way that other people will understand. Totally. And I think the risk here is that you bury business people in detail that they not only don't care about, but it's frustrating to them to have just like so many little technical bits spammed to them.

Like, well, we need to refactor this and change that. We have to replace this legacy system and upgrade this infrastructure. And they're just like, whoa, whoa, whoa, tiger. I just need to know, like, how much time are you going to spend on this? And I think a good product owner, their job is to be a liaison between the engineering team and the business. And they can say things to the engineering team like, look, baked into every hour we work on this customer's project is X percentage dedicated to ongoing maintenance and operational improvements. And a.k.a. refactoring and infrastructure upgrades and all those things. if your product manager product owner can do that i think you can have a really good relationship

where you say here's the level of detail we're going to share with you here's what we're going to insulate you from and our commitment is to keep these systems fresh and easily changeable so that in the future when we get big sweeping requirements from customers we can implement them confidently the question asker feels concerned that there's not trust here where the product owner doesn't give them permission to do anything which basically means that they don't trust that it'll be actually useful so it feels like there could be something to explore there to try and increase the trust between product and dev yeah and and like you need to trust the product person too if they're going to be telling you these are the important things to work on then you should

be able to trust that there's a reason for that and it's not just them making it up as they go along it's probably a bigger question to answer though how do you generate trust there yeah that's a fundamental one I mean it's easier to develop trust when it hasn't been broken so I don't know in a perfect world you have you haven't broken the trust so your battery's not on low so you don't have to kind of recharge it and from there you can kind of um kind of just be like if you're willing to believe me if we do if we refactor this system it'll be easier when we have to do subsequent stories for xyz but if that trust is broken i don't know i don't like the idea of like surreptitiously refactoring things and cleaning it up but i mean it could just be that you could

you know limit a bit of refactoring when you're in a part of code to x amount of time and just kind of do it as part of your story and you know none no one has to be none the wiser yeah right one one of the keywords i'm latching on here is tinker and i think you know if you want to tinker with things um that sounds like something you would do on your hobby or on your free time but this is a business who is paying you to deliver value and if it's like well i just want to tweak this and change that if it's really worth your effort doing you should create an item in your backlog and you should track it and the team should agree that you should do it now if it's like a five minute thing and you're just fixing a little broken window that you saw that's

not what I'm talking about. But if it's if you're going to spend a day tinkering with the development environment, like I think you owe it to your business to track that. And I'll give you an example. So like last week, I encountered a gap in some data at work where I'm like, Oh, no, our software is not producing data in this one situation that it's supposed to be. I created a story, talk to the team, and I went ahead and implemented the fix. As I was implementing the fix, I found three other major refactoring jobs that needed to happen on our code base. And my instinct was just to launch into those jobs right away and be like, I'm just going to include these with my fix. The people reviewing my code will thank me for fixing all these unrelated things

at the same time. Exactly. And initially I did, I just went ahead and did it. I'm like, it's no problem. And then I realized my refactoring actually caused a bunch of issues. I had to roll back my changes and I decided, you know what, I shouldn't have done that. And so instead I put three new tasks on our backlog and I said, okay, we will prioritize these when it makes sense. and and i think you owe it to your business to be responsible about what you're delivering and how you're spending your time because otherwise it's just a hobby and and we love doing this like as engineers right like it's our like we we love just like being consumed by making it just a little bit better you know um but at the end of the day you are employed by a business and i think you owe it

to them to show a little bit more responsibility than just tinkering we talked last week about rock star developers and part of being a rock star is long self-indulgent solos where you just are like stand back everybody well i also really like the kind of point you brought up which is that when you did those refactors all in once it caused subsequent problems right which is kind of goes back to like when you chunked it out into smaller bits that were documented you can be more thoughtful about doing those things as well and you know make sure that when you do that one chunk it does it doesn't break everything else and it's it's kind of like that adding that additional process which like is really tedious and annoying and sucks because you just want to do the thing

actually makes it so that you do the thing better and cleaner and nicer and you slow down and you're not just playing heavy metal in the background um yep but it helps it helps i'm like one of those engineers who like really likes process to a certain extent i think it's a it kind of helps i find that it helps me when i write my code it's not always better it should never be that you're antagonistic with your product owner like so kind of back to this whole lack of trust right you don't ever have to like constantly feel like you're justifying making improvements like it always sucks to to kind of have to fight those battles you know and i've been there um but at the same end like the process also helps because

it makes you a bit more thoughtful and considerate about how you implement certain things yep the the question ends asking what's your opinion on the level of freedom that programmers should be provided in order to do their job well and it sounds like we're kind of arriving at a consensus that there's definitely some give and take where this this situation seems like it's pretty far to one end of the spectrum where there's absolutely no freedom to do anything besides what the product manager tells you and that seems weird ideally there's back and forth where you have input in what's important in the product including the vital role of surfacing technical issues so now that we've told you that your problem is solved now you can just do that let me just make

let me just make this comment that over the last like i don't know seven or eight years i have noticed a trend of control moving away from engineers and into the hands of product management where engineers are kind of relegated to this you just implement the spec I will write the spec a UX person will provide you pixel perfect mockups you just make it look like this Dave, sometimes I dream about living that life

or someone just tells me what to do I don't want to decide wouldn't that be nice I want less control yeah I accept I accept this trend but i i honestly believe that engineers who are more engaged in the process of defining the

product actually do a better job at producing good product because they do they can have good ideas to contribute and they can if they have like a full end-to-end understanding they can do they can make choices that a product manager wouldn't tell them to make but their context that they have helps them make better choices so yeah anyway i as much as it's nice to have someone tell you exactly what to do in your job every hour i push back on that idea quite a bit and i think programmers and product owners should be should be considered partners at the table defining the product not you know one subordinating to the other yeah i think it's always good to know enough about your domain to really question when something comes into your

plate because when you question it you can probably find the right answer um a lot of times people are like i want this and how do i explain it it's not like it's kind of like saying you don't really want that you think you want it because that's kind of how you've seen it but what if you ask the right question you can actually get to the bottom of what really someone wants and when you're engaged with your product an engineer can can really say like well do you really want to see the data in this shape because what is the question you actually want to answer and if that's the case then this is probably not the thing that you want to see you probably don't want to see the you know median you want to see the average i don't know that kind of thing right where you

really kind of drive down and that's something that you know your product owner might not be willing to ask because they might be wanting to please someone so you really it's good to have good domain knowledge to ask those questions and really drive to the point of what they really want yeah the the situation i described where someone knows all the right answers and just tells me what to do has never occurred in practice where the places i've worked where people have told me what to do in great detail there's still been huge gaps in uh in in design where there are still questions that need to be asked or in customer feedback or like if if your product owner is omnipotent then it's probably fine to do whatever they say without understanding it or questioning

it but anything besides that there's going to be they're not perfect and and the level of detail is not going to be complete to cover everything so i think that makes sense uh have we answered the question i think so good luck good luck with your capability maturity model integration let us know what the fabled level six is and beyond maybe there's more levels uh well you need to be at level five before you can know that jameson i'm sorry it's yeah maybe it's like more dimensions where our brains as they exist cannot even comprehend them you can't handle level six i can't even pronounce what is beyond level six in a way that you would understand your mortal language is insufficient level 11

it's the closest i can get uh what should people do if they want their own questions answered hit us up on softskills.audio and click on ask a question you can give as much detail as you'd like uh netta how can people find you on the internet or in real life uh well well uh in real life i live in selling california and i guess that's as much as i'll give you um i i exist on twitter but i'm not really um technical but you can follow me there it's my last name amini netta you can follow me there and i'll just talk about pop stars and share my thoughts when i'm drinking fantastic sounds yeah sounds delightful all right thank you so much and we will catch you next week