Soft Skills Engineering - Episode 303: Should I stop coding and off to the field

Episode Date: May 9, 2022

In this episode, Dave and Jamison answer these questions: I’ve been a Staff Software Engineer at my company for 1 1/2 years. We have about 120 engineers company-wide. I’ve had 4 different bosses during the last year and our team has moved around a few times on the org chart. I lead a team of 2 engineers. My boss told me I shouldn’t be doing any of the coding but should spending my time working with the product manager, doing research for upcoming features, doing code reviews, managing the Jira board, mastering jellyfish metrics, reviewing architecture documents, setting up measurement in our logging tool and coordinating deployments of our features. Because my team is small and our product roadmap is pretty well defined, these tasks do not take 40 hours per week. I feel like I have nothing to do. I’ve tried to improve the velocity of the team by doing some coding and triaging on bugs. I miss doing the technical work and feel like I could do more but I also want the other 2 engineers on the team to own most of the big, bulky tasks. What do you suggest I do? Should I enjoy my light load or should I be looking for other ways to add value? I am the lead developer on a few projects with developers that have 20+ years of experience compared to my eight years. I have been made lead of the projects, but I’ve never actually had management tell the team that I am the lead or that I have any control whatsoever on the members of the team (typical ‘all of the responsibility, none of the power’ scenario). One of my teammates is tough. He writes unreadable but working spaghetti code. He also works in the field and will often times push to master and then leave to perform fieldwork, leaving the team in the lurch for several days before he can come back and fix his broken code. He habitually fails to push code, often holding the source on his own computer for months before pushing. I have mandated using pre-commit hooks to guard against breaking the build, but as IT has control over the repositories, these become “optional” and appear to be disregarded. I have brought this up with management, to no avail; the behavior continues. I have also expressed my concerns with management, and provided data on the impact this has to the project via tickets and time spent between the remaining team members. How do I rein in this unwieldy developer? What else can I do? Show Notes https://www.gamasutra.com/view/feature/4111/dirty_coding_tricks.php?page=4

it takes more than putting unnecessary sleep instructions in your code so you can later remove them when you get asked to optimize your program to be a great engineer this is soft skills engineering episode 303 i'm your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice podcast for software developers about how to optimize your program by setting yourself up for success in the past i feel like we've talked about this article from this game programming site about this this old gnarly memory optimization trick where at the very beginning of a game development cycle someone just allocated a buffer of like four megabytes or something back when there was a lot of memory and they built the game and they're struggling to make it fit in

memory and then the developer just went in and deleted the buffer and then it fit nice there's a lot of life application to that like in in budgeting in like weight loss you know it's like you could wait how would it apply to weight loss i was thinking like if you drink like four gallons of water one day and then start a diet the next day you know you're you're you're starting weight will have like four gallons of water weight in it and you're like yes i lost three pounds yeah anyway psychology i guess okay i found the link and i'm gonna i swear we've linked this a bunch of times but i'm gonna link it again because it's always good do it the programming anti-hero so now that we're on episode 303 i feel like we missed an opportunity with 301 and 302 to talk

about permanent redirects and temporary redirects oh shoot what even is it 303 it's probably something see other response it's always a wonky kind of redirect it's a not 301 or 302 it's just another redirect use this if you want to impress your co-workers yeah clearly it's a 303 yeah use this to get into meaningless debates about http semantics we'll come back to this point when we get to 307 which is another temporary redirect that will cause all kinds of arguments on your team well obviously you need to put to 303 in order to correctly interpret the meaning of life yeah okay optimized we did it we this is like this is like when we say um a lot in the podcast and then ask the editors to take it out yes exactly we pre-load it with um you feel

like we rambled yeah and then and then oh the podcast cuts down to a tight five minutes after you delete all the nonsense someone should make a version of our podcast where they just delete all the bad advice and it's like it's like two minutes long good advice if maybe they're zero minutes long i don't know yeah maybe maybe it's the empty file right one way or another you're gonna save time all right should we move on we should i want to say thank you to our sponsor This episode is sponsored by Hired, which is the best way to quit your job and get a new one. And you will find out more about them later. I want to thank our patrons who are contributing at the exorbitant levels where we say their names or an emoji or anything you'd like in any language every week.

They are Craig Motlin, Roman Code, I Love Mavis, The Stochastic Parrot, Alice Jost, Andrew Pollack, The Yeet Your Job Podcast, Ian Walter, Arun Duna, Patreon.com.au. We're hiring Ira Chan, Monkey Face Emoji, Jonathan King, testingisdocumenting.org, Ola Dapo Fadiyi, RMRF Prod, Ragnar Hardison, Timmy Garabrant, Nick Hathaway, Travis Sanders, Brayden Keynes, John Grant, Nick Cantor, and Philip John Basile. If you would like to join this crew, you can go to Patreon. No, you can go to softskills.audio and click support us on Patreon. Any dollar amount will get you access to our Slack community, which is a fun group of hundreds of like-minded listeners who actually give good advice.

probably the best thing to do is if you want good advice is just contribute a little money to the patreon and then go ask people on slack rather than listening to us which is great and that's all i have to say about about patreon today i like that it sounds like you were blaming ragnar for doing rm rf prod rm rf prod ragnar come on not again every week it takes us the whole week just to get prod back and then rms again only to have it rm'd again such is life should i read our first question go for it all right this is from an anonymous listener who says i have been a staff software engineer in my company for one and a half years we have about 120 engineers company-wide i've had four different bosses during the last year

and our team has moved around a few times on the org chart i lead a team of two engineers my boss told me i shouldn't be doing any of the coding but should be spending my time working with the product manager doing research for upcoming features doing code reviews managing the jira board mastering jellyfish metrics is that i'll come back to that reviewing architecture documents setting up measurements in our logging tool and coordinating deployments of our features because my team is small and our product roadmap is pretty well defined these tasks do not take 40 hours per week i feel like i have nothing to do i've tried to improve the velocity of the team by doing some coding and triaging on bugs i miss doing the technical work and feel like i could be

doing more but i also want the other two engineers on the team to own most of the big bulky tasks what do you suggest i do should i enjoy my light load or should i be looking for other ways to add value tough call low expectation situation but also bored mastering jellyfish metrics i looked it up it's like a team productivity metrics okay like in it like inspects jira and get and tells you what your team's working on yeah this is one of those there's there's a whole bunch of these that are like we read accelerate and then we built a tool that measures those four things okay got it so by mastering these metrics you mean gaming them re reading them okay gaming them change lead time all right we'll get it down to one second that's right look at that wow deployment

frequency every keystroke is a deploy bam oh man i have mastered the metrics they work for me now okay when the question asker says i lead a team of two engineers do you think that means two other engineers or is it this person and one other person no i later in the question they say the other two engineers on the team oh that's true so this is this is a three-person team one leader and that your question is really the answer that i am coming up with here doesn't matter whether it's one person or two people that is being led here because this is a tiny team and the fact that you have a company that thinks you could fill an entire professional work week just providing technical leadership for two other engineers that strikes me as a little weird yeah i noticed that

none of this is people management stuff either yeah it's not like yeah you're you're you're the full-time kind of tech lead that doesn't do any individual work of two other people yeah so there's there's a bunch of a bunch of other stuff that someone else is doing that would add more to the workload if you were doing it for two other engineers but you're not exactly and this this kind of prompts me to ask one of two questions like either one of these two questions is going to be a valid question either question one what does your boss know that you don't know or question two what do you know that your boss doesn't know about leading such a small team i shouldn't be doing any of the coding so weird right i mean i i hear this bandied around quite

a bit that that usually it's about engineering management though like the people management stuff yeah sure not about the tech lead stuff even don't you think though that i don't know curious if you agree with me on this even in a people manager role maybe let's say you're the combined technical leader and people manager for a team of two i still think you should be doing individual contributor work on that small of a team as the leader that feels right to me because that's what i have done and what i have done is right obviously the baseline for all truth yeah exactly i've had four different bosses during the last year my boss told me i shouldn't okay so this is boss number four it's possible they don't even know how many people are on this team

yeah maybe there was an error it's like oh i thought you were leading 20 engineers not two in that case you're laid off so there one thing you could do is i think what you don't want to do is just say okay and then go do technical work and and the team looks better for it but you don't get any visibility or any any like acknowledgement that you are helping you're just kind of silently doing more work. That feels like the wrong way to do this. Yeah. I think you're going to need... So I'm pretty sure that of the two questions I posed a few minutes ago, I think question one is the question. What do you know? I forgot what those were.

No, wait, hold on. Question two. Is it what do you know that your boss doesn't know? You know something that your boss doesn't know. And I think that thing is that technical leadership for a team of two engineers is not a full-time job. And I think you're going to need to convey that to your boss without using those exact words i think what you're going to want to say hey have you ever been trying to reduce your budget i think what you're going to want to convey is some kind of number like i'm thinking to myself okay they've your boss has asked you to do technical architecture documentation and i think you're going to

want to say look we now have enough architecture documentation to satisfy this team for two years you know to keep them fed with work for two years or some number you know find the answer the roadmap is settled the jellyfish metrics whatever that is are fine you know the jira board is in good shape as indicated by these well they're mastered they're not they're not fine fine it's not good enough these metrics have been dominated i mean i don't know that's what i think is that you need to say like look i believe that i can do everything you've asked me to do and pick up development tasks throughout each sprint are you okay with this and and i have a hard time imagining a boss who would say no you must only do these

things and not more work yeah but you're gonna have to prove i think to your boss that you do have all the things under control that your boss wants you to do yeah that's what i was just thinking maybe maybe maybe this is coming from them identifying what they see as a gap in in some documentation or one of these areas or something and then they're just assuming like oh you don't have time like it's not up to par right and so there's definitely something right this doc had a spelling error so no coding for you but also though jameson the counterpoint to that is this is the fourth boss in a year and a half this this sounds like hyper growth this company is is hiring fast maybe people are also leaving at a high rate this boss probably has no

idea what is actually needed or maybe it's hyper shrinking right hyper shrink what's hyper atrophy i don't know what's the word for that yeah hyper atrophy is a weird word because it sounds like hypertrophy which is like getting bigger bigger trophies that's what you want to have happen to your muscles oh is that a word yeah unfortunately it's what's happening to my tummy as i sit and work at this desk job nice yeah okay okay the point the question yes i also want the other two engineers on the team to own most of the big bulky tasks i think that is a correct instinct though like yeah me too i've worked with people who their attitude towards engineering leadership was like stand back i'll i'll figure out what to do and then they just took all the fun problems

and and we're good at coming up with solutions but it was always kind of a bummer because i felt like i never got to wrestle with those problems i just kind of twiddled my thumbs yeah because the leader you just kind of waited for the leader to tell you what to do yeah and if i tried to come up with a solution the leader was going to come up with a solution and it was not going to be my solution so yeah yeah and then you're gonna have to go toe-to-toe and it would be a fight to the death and you already knew who was gonna win i'd be covered in viscera no good yeah so i think i think you can do both of those things at the same time i think you can contribute technically while also having the other folks on the team own the kind of design and and big gnarly

implementation parts and and you get to provide feedback on those and then you get to do stuff kind of falls in between the cracks a little bit. I feel like there's kind of two schools of thought on technical leadership. And on the one school, it's that you as the leader should own the critical path code for the system. And the other school of thought is that you should be creating a runway for your team to own that stuff, create the right guardrails for them, the guidance and leadership and vision for them, but then let them own the meaty parts of the problems and run with it. I don't really know where I stand on that. Yeah, I was going to ask, are you advocating for one or the other? I'm really not. At my previous company, it was explicitly stated in the promotion criteria

that technical leaders were supposed to own critical path code. But that definitely created an environment where it's like, look, the technical leaders don't have time to write that code and you don't want them in there anyway because there's a lot more of us than them. So yeah, I don't know. I actually like the instinct of this question asker, which is they're creating a great environment for their engineers to be successful, solve big, as they say, big bulky tasks. Great. And when I've been in leadership roles that are more technical and hands-on, I would not take the critical path stuff because I needed to be able to disappear for several days to meet with a customer or to handle a fire or something. And the critical path can't tolerate that kind of absenteeism.

So I like this instinct, but I also think there's definitely time in your week to be doing some coding here there should be anyway yeah i think the the stuff i felt most successful the technical things i felt like i i worked on most successfully when i was in this role were either the kind of like important but never urgent work like they're just bugs that hang around that are always annoying but never seem to be annoying enough to rise above the level of other stuff but life will be so much better if they're fixed or there's these kind of like long running again important but not urgent features things that improve quality of life or or enable other work but don't block anything else while you are while you are disappeared to go talk to customers like right i was working on some

internal tool at a company and we had talked for years about adding impersonation to it and the impersonation can be tricky especially if it's like a customer facing thing because then there's lots of issues around like access to the user's data and things this was all internal so yeah it it was much simpler kind of socially to solve it was still like tricky-ish to solve technically and i think i built it slowly over time but when it was done it was the kind of thing that felt like we didn't remember how we lived without it right right even though it was never important enough to stop the developers from doing something else to do yes and i love it when technical leaders pick up that kind of stuff on the side it's like we would never prioritize this

over like a customer critical feature that they need to be successful yeah but it still needs to get done and it's really important for the operation of our team and company yeah the the next level of difficulty with that stuff is you are not the person who has time to do it but you have to help the team like make time to do that kind of stuff if if you just say uh i'll just do it don't worry about it then that's a solution but that doesn't scale yeah it's better if you have a repeatable process to where teams can actually pick that stuff up but with three people the repeatable process is probably like you just do it yeah exactly exactly exactly this is a tiny team so i think we're coming to a conclusion here you need to have a heart-to-heart with your boss

and you need to convey to your boss in clear empirical terms that your boss can understand Why the work that you're being asked to do is not sufficient and that you can contribute more to this company And if you couch it that way, I just can't imagine a boss that would say no I guess you you have a few other options, too. You could just yeah enjoy my light load. You could do that You could also say you know I can do this kind of technical leadership work for several more engineers if this is the yeah This is the kind of thing that you need. I have extra capacity So yeah, don't don't tell your boss that you have capacity to quadruple the team because then your boss will be like wait a minute

what are you doing with all your time but you do probably have capacity to quadruple yeah i think i could take on one more engineer you just repeat that every month i think we could take on one more i'm just getting really good at this yeah you've unlocked the secret of scaling which is that each engineer you add is less work to add everyone knows that everyone knows that right i'm a constant like time complexity in big o terms based where n is team size so just keep keep them coming yeah all these other jokers they're all exponential right oh watch it watch a logarithmic master work right i've added 500 people to my team i will say that if you take the i'm just gonna sit here and not have a full week option i think your team will eventually resent

you they'll be like what do you even do you know so i live in fear that that everyone thinks that already when i'm like sprinting all the time yeah what do you do jameson this podcast oh okay hey jameson have you heard about the great resignation is it that charles dickens book wait no the entire population on earth has started taking our advice of quit your job oh yes that's right apparently we have achieved influencer status we've been telling developers for years to quit their jobs and now we want to tell you how to do it we're ready to reveal the secret. I mean, you don't just walk out shooting finger guns. Yes. Well, you do that first. But after you do that, there's a new service we want to tell you about called Hired. What is Hired,

Dave? Hired is the biggest AI-driven marketplace that matches engineers with companies. It is a great way to find your next job. I've been watching this industry for 20 years with a keen interest on hiring in particular, and I've never seen anything like Hired. Tell me about what you're seeing. So I've interviewed about 150 people in the last year. And I am serious. Every candidate that's come to me through Hired has multiple offers and they're incredibly high, scary high, like 30% higher than other candidates. Is that before or after the finger guns?

Yeah, both. The beauty is it's totally free for engineers and we would love for you to go try it. Go to Hired.com slash soft skills to check it out. Hired.com slash soft skills. Quit your job the best way and check out Hired. All right. Do you want to read our next question? yes this comes from an anonymous listener who says i am the lead developer of a few projects

with developers that have 20 plus years of experience compared to my eight years i have been made lead of the projects but i've never actually had management tell the team that i am the lead or that i have any control whatsoever on the members of the team typical all of the responsibility none of the power scenario one of my teammates is tough he writes unreadable but working spaghetti code he also works in the field and will oftentimes push to master and then leave to perform field work leaving the team in the lurch for several days before he can come back and fix his broken code he habitually fails to push code often holding the source on his own computer for months before pushing oh man big oof sorry that was my editorial comment there i have

mandated using pre-commit hooks to guard against breaking the build but as it has control over the repositories these become quote optional and appear to be disregarded i have brought this up with management to no avail the behavior continues i have also expressed my concerns with management and provided data on the impact this has to the project via tickets and time spent between the remaining team members how do i rein in this unwieldy developer what else can i do you did the good advice stuff already of try to document the impact and share it and it didn't work or try to put in guardrails yeah also didn't work also didn't work there are no guardrails stringent enough that a person who doesn't want to be guarded by them can't just get around them

that's right man yeah this is all kinds of unreadable but working the it's the but working spaghetti code part it's like this sounds like a company that doesn't care about craftsmanship or code quality yeah and so the fact that this code works they're like what else do you want it's fine what else what else is there yeah exactly i'll bet this person that we're talking about has absolutely saved this company from failure multiple times oh yeah i bet i wonder if they go off to the field and like perform miracles oh absolutely they like go to some customer site and and and save some system or something like that why is it so often the case that the same person who performs miracles and saves the company

is also sometimes, maybe quite often, the same person who destroys the engineering team. Yeah, they do tend to put the team into a place where miracles are needed. That's right. I don't think it's deliberate necessarily. No, no. This is the guy who put the sleep statements in. They're hiding in the spaghetti code.

and then miracle now it's fast oh okay this is the this is the apex predator of of cowboy coding habitually fails yeah there there are there are three really bad things here so there have to be some good things because i feel like these really bad things all together if there's nothing good means that person doesn't work there anymore that's right there's probably some things here that in management's eyes are so incredibly good that all of these complaints that have surfaced to management are offset by the good yeah if you could figure out what those good things are in and then somehow in the minds of management taint them incept them poison poison them against this person remember that miracle that so-and-so

pulled off last year in the field well you know the problem do you want to know why that miracle was necessary that same person created the problem you remember when all those snakes attacked our customers and and this person came through and just rounded them all up where did those snakes come from why were there snakes there do you remember how you reimbursed this person for that snake charming snake charming school last year do you think these things are connected yeah so the first thing pushing code and then and then piecing out to the field that feels like the kind of next evolution of deploying on friday yeah where friday is actually like tuesday and then right it's like three weeks from now or something

yeah that's next level oh man yeah any day can be a friday if you go to the field that's right oh man no deploy friday any day you like yeah so i okay maybe i missed it in the question but this person has talked to management talked to it set up guardrails but i'm not hearing a conversation with the perpetrator did i miss that i have mandated using pre-commit hooks to guard against breaking the build i wonder if it was a group conversation that really also needed to be a one-on-one conversation right first or or in addition to it's one of those group conversations where you know you're only having this this meeting because of one person in the room yeah but you don't want to single them out so you do it for everyone and then they're like

completely tuned out yeah busy writing spaghetti code sorry i didn't listen to you i i noticed there's this uh thing that appeared in our repo that was slowing me down so i just took it out you're welcome what was this meeting about again oh man it was weird i couldn't merge so i just got rid of that now i can i think that i think this person is lacking some introspection and might not really understand the impact that they're having on the rest of the team. And it would be really good to craft some questions that you can ask this person that will cause them to really look and see the effect that their habits are having on the team.

You know, questions like, hey, remember when you pushed that code that broke the build and then left for two weeks? Like, why'd you do that? or like do you know how much time we spent trying to recover from that while you were gone oh no i don't how much time it was like 30 hours that seems like kind of a lot huh you want to try to put them in a mindset where they're looking for that i wonder if this person works crazy hard too and so like i could see them getting really defensive if you just come in and say like you're you're harming the team and then they just point to all the miracles that they're

doing and all the late hours they put in in the field and and yeah it feels it feels like a bit of kind of the firefighting heroism look do you want to come go to the field do you want to come out here these snakes gonna just take care of themselves no do you know i don't see i don't see you covered in snake skin that you already were covered in before you went to take care of the snakes for some reason oh it definitely could go off the rails that way but you you know if if that doesn't work you've got no management support you've got no it support you don't have support from the individual management hasn't told anyone that you're in charge of this stuff you don't have decision-making authority uh all of this points in one very clear direction oh i think i know

what could it be this does seem like it could be a good candidate for quit your job yeah or i'm assuming that you are being held responsible for the success of the projects and team in some way yeah and and it's not successing because of this behavior yes but it's possible that like everyone's fine and just driving you nuts and and if you can just not care at all then maybe it's that that feels like another option too of like oh build's broken it'll be fixed when when the field work is done okay and it and it could be you know the the opening question was i was made the lead of these projects but management never told the team and and it could be that this lack of information

on the team is making them ignore you and so maybe it's time for you to ask that question and management, like, hey, you assigned me leadership role over all these projects and you've been holding me accountable to it and I'm happy to do this job. Why haven't you told anyone else? Yeah. It sounds like a good approach. I mean, you can kind of make it their problem, right? I've tried to solve it and the lack of authority I have with the team and lack of clarity around my role makes it hard. So if you want me to fix this, I need some more clarity there. Yeah, for sure. And you know what might end up coming out of this conversation with management is that you'll describe all these problems and it might become clear that they

actually don't care about these problems. It's not important to the business or the operations or whatever it is they're responsible for. It's not important to them. And now you have a privatization misalignment. When you're in a misalignment situation where your personal desire doesn't align with the company's desires, you can try to realign those things or you can find a new organization where there is alignment yeah maybe they told everyone on the team that they're the leads maybe this guy is the lead and he's like i'm busting my butt here that's why i go to to do this field work to save these things because i'm responsible for it they read the cover of extreme ownership

yeah i think you gave solid advice dave all right i think you did too oh thank you have we answered the question then i think so let's wrap it all right what can people do if they want their own questions answered go to soft skills.audio and click the ask a question button and we thank you for the continued flow of amazing questions every week we really really appreciate it you keep the show going with your questions and with your money because jameson's yacht payment ain't gonna pay itself so if you want to support the show and join our slack community go to soft skills.audio and click the support us on patreon button thank you so much to everyone who does that thank you Thank you.

We will catch you next week.