Soft Skills Engineering - Episode 183: Terrible boss code and peer-to-peer mentorship

Episode Date: November 11, 2019

In this episode, Dave and Jamison answer these questions: I work in a small team under 10 people on a new project that should be shipping soon. I have a manager who is leading this project, and I’m the most senior developer on the team. My manager tries to help with the project by writing code, but does it rather poorly. When he wants to implement new functionality, he creates a new branch and brews his code in this branch for 2-3 months, constantly complaining how hard it is to write code in our codebase. After he is done, the resulting code is unreadable, unmaintainable and untestable. He doesn’t write unit tests himself (which is weird, considering he was working as a QA before for several years) and usually breaks good portion of already written ones. I always have to go to his branch and refactor his code so it’s at least testable, fix broken unit tests and write new ones for his functionality. He always makes it look like our codebase is hard to work with, though the rest of the team doesn’t have this problem. How should I deal with this situation? I tried speaking to him directly, but he is pretty stubborn and thinks that he is doing everything perfectly. I can’t talk to his manager, since we have a pretty flat company and his manager is the CEO who I don’t have a direct access to. I work in a digital agency as part of team of 5 front end developers with varying levels of experience. We don’t have a senior / lead / director, it’s pretty flat. I have been told by management that we need to work on peer to peer mentor-ship because each of us have been guilty at some point of spinning our wheels on some problem when we should have reached out. The problem is we all work on different projects, there’s never 2 ““fed””s building the same site, and each site kind of feels like it’s own unique bowl of spaghetti. If you have any pointers about breaking out our code bubbles that would be amazing! Love the show, I hadn’t given non technical skills much thought but you’ve opened my brain! Thank you!

it takes more than laziness impatience and hubris to be a great engineer this is episode 183 of the soft skills engineering podcast i'm your host jamison dance i'm your host dave smith soft skills engineering is a weekly advice show where we answer all of your non-technical questions about the technical field of software development and i share old larry wall quotes wouldn't you say that laziness impatience and hubris are kind of soft skills they are yeah that's a good point so they're very applicable yeah this was a quote by larry wall the inventor of pearl and it's kind of pithy and he has definitions that make these sound actually like good things but ignore those and just focus on being lazy impatient and hubristic what's the adjective form of hubris

it's hubri hubri huey be huey yeah you want to talk about our wonderful patrons yes thank you to those who are giving us so much cash that we are able to make our yacht payments every month and also pay for our hosting which by the way is getting more expensive thank you to all of your listeners which we love they are matthew voidovich the agile ventures charity bartek tatkowski ted nugent crash bandicoot zach granin maple syrup louise santos kriska kanapka piska Jopka, Nick Kantor, Vinlok, Taras, Harug, Sean, Sunny Tai, Brittany, Alec, Sonic the Hedgehog, Ivor, Robotnik, Florian, Tadsel, Murray, Rosso,

Chris Hogan, Dimitri Janssen, and Stanley Tactical Radio. Woo! Woo! Nice work! I'm like the micromachine guy from the 80s who did the commercials. I was maybe not alive then. Crap! Oh! I knew it was a risky reference. Okay, if you would like to support the show financially

and get invited to our Slack community, which is growing and awesome, just go to softskills.audio and click support us on patreon thank you so much to everybody soon the lego model yacht will be real all right i'm gonna read our first question this is from an anonymous listener i work in a small team under 10 people on a new project that should be shipping soon i have a manager who is leading this project and i'm the most senior developer on the team my manager tries to help with the project by writing code but does it rather poorly when he wants to implement new functionality he

creates a new branch and brews his code in this branch for two to three months, constantly complaining how hard it is to write code in our code base. After he is done, the resulting code is unreadable, unmaintainable, and untestable. He doesn't write unit tests himself, which is weird considering he worked as QA before for several years and usually breaks good portions of already written ones. I always have to go into his branch and refactor his code so it's at least testable, fix broken unit tests, and write new ones for his functionality. He always makes it look like our codebase is hard to work with though the rest of the team doesn't have this problem how should i deal with this situation i tried speaking to him directly but he's pretty stubborn and thinks that

he is doing everything perfectly i can't talk to his manager since we have a pretty flat company and his manager is the ceo who i don't have direct access to oh oh my goodness huh wow this question caused some soul searching because i still write some code and you're a manager i am a manager is it terrible code i think it's great code do you constantly complain about how hard it is to write code in your code base no i don't think so but there's definitely some some power dynamics there when your manager is the one submitting a pull request versus when it's your peer a developer it's much harder to reject a pull request and say hey this is not good you did this in the bad way

oh man this is so hard yeah so jameson how often have you gotten negative feedback on your pull requests i mean i get feedback if it's breaking things and we have this cool invention called continuous integration where it tells you if the unit tests break ah what a novel idea yeah it's the computer's fault it's not someone else's job to point it out to me if i break all the tests yeah and i also don't i certainly don't work on new features that are important for shipping the product at all i i won't go off and brew a branch i love the phrase like brewing it brewing your code it's fermenting there's some yeast and bacteria and all kinds of stuff going on in it but yeah i don't do that i don't go off and work on something for months unless it's a thing that

would take me two days of dedicated time and i just don't have those two days so it gets spread out over two calendar months yeah but but not not large-scale work okay so i've convinced myself i'm i'm not this bad okay question answered yeah i am okay it's all about this is all about you let's be honest you're welcome listener oh man this is such a hard situation i mean if it weren't for these through a few follow-up points like i i've already tried speaking him directly but he's really stubborn and he thinks he's doing everything perfectly and i can't talk to the ceo what do i do well yeah this is hard and you're the most senior engineer on the team which means you're the only one who can solve this problem it's all on your shoulders yeah it's kind of your

job hence why you've turned to dave for his sage wisdom oh man and there's so much wrong with the situation too like the fact that the manager is building like big complex features that takes two to three months and they you know move the project in a new direction and cause all this harm when they try to merge them the fact that the manager's even in the critical path is probably itself a problem worth addressing yeah and the fact that they're stubborn and don't take feedback well from engineers working in the code base and the fact that they used to be a tester before this and don't write tests well it's like how i used to have to do homework at school now i'm i never have to do that again and i wash my hands of it good riddance oh true i've done

enough testing for a lifetime so exactly you can write my stupid test for me paid my testing dues and you can fix all the tests i broke with this change this is so rough okay so let's let's back up jameson as a manager why do you sometimes write code in your code base when you know you probably shouldn't be sometimes it's to escape hard problems that i don't know how to solve there's some tricky thing ahead of me to deliver some bad news i have to weigh two difficult trade-offs and i choose the third option which is why don't i go fix that little very low priority bug that's been nagging some people for a couple weeks that i just discovered five minutes ago and probably doesn't matter yeah why don't i just do some therapeutic refactoring

you know what we need a new linter too many tabs here these should be spaces i've got some really hard feedback to deliver to a co-worker but boy do we need a new linter yeah part of it is that part of it is trying to shelter the team where if their heads down on sometimes my goal is to be interruptible so the team is less interrupted and sometimes it's little things i can crank out that aren't on the critical path but are still useful to someone else and it avoids them having the context but the worst case is when i feel like we just need more engineering minds on this and i will do it because we we just need more people on it that's the case where it

usually goes the worst yeah how about you dave what about me just all of yourself um when you've been in management have you still written code and if so what what led you to do that yeah i i have i mean i guess one one other reason is i want to stay in touch with what it is like to work in the code base yes i don't want to totally lose touch yes and so i was very careful never to take on critical path tasks except one time and honestly i was guilty of being a hero kind of swooping in and rescuing a project yeah that was a mistake in hindsight but there were there were other times when i thought okay here's a cross-cutting concern that no single team well you know i was actually managing about seven or eight teams at the time and there was no single team who would own the

solution it was a cross-cutting problem and i thought i'm gonna work on this in my free time and i used kind of nights and weekends to work on this thing for a month or so and to try to help manage this issue and it it was okay and then other than that i just try to do occasional small fixes and just stay the heck out of the way of your teams yeah which sounds like is a lesson this manager needs to learn i just don't know how to make them learn how do you learn them this lesson yes right did anyone ever complain to you or approach you about it any developer on any of your teams no one did but you know there's this power dynamic problem yeah that i think a lot of managers just don't recognize because they don't feel how effectual the power dynamic actually is

on the other people certainly and so no one no one approached me about it also i had i had been one of the very early team members individual contributors on the project so i had a ton of context and that was actually another another big problem for me was how to transfer that context to others to empower them to not have to come to me and ask me questions like how should we do this and that was something i probably could have done better too none of these things are lessons this boss has learned apparently yeah i mean bruise code in this branch for two to three months how is he being a manager if he goes to code for two to three months well maybe it's the kind of thing where he starts things but then gets you know deprioritized for a while and then comes back to

it and the branch rots and now he's got to do a big merge and yeah you know he just force pushes over everybody's stuff i'm the boss get out of my way exactly you know i i do see one problem here that might be solvable which is this senior engineer who wrote in with this question says he himself is fixing a lot of the issues fixing the merges fixing the broken tests writing new tests for this boss basically you're enabling this behavior because you're allowing his code changes to get done and without you he would not be able to do anything other than sit around and complain about the code base unless he's saying it's like a train coming to hit your code base it's like hey i'm gonna click this merge button in four days whatever's in there is is going into master

so i actually just remembered a situation that happens where it wasn't with code but i was managing a team that does some other not code related tasks technical but non-coding and i kind of jumped into help i was like oh they're they're a little swamped i know a little bit about this i can i can step in and help and i did it and i didn't know the context around their process and how they managed the work and how they tracked it and followed up and some of the context around how help affects further requests from from customers and one of the folks on my team reached out to me and was like hey if you're gonna help you have to do it right like you have to follow these processes here's why we do these things and i want to be like this person when i

grow up they're really great and they're also very very good at being direct and it was kind of eye-opening because in my mind i was i was helping you know i was like this is just some extra help i'll sprinkle on yeah and so maybe it's not as important that i follow all the rules because it's like free it's free money you know yeah you get what you pay for people why are you complaining yeah but but they pointed out to me hey it's not free i mean it's nice to help out but it has consequences and affects our further work and relationships if you just kind of swoop in and do things your own way. And that was very eye-opening to me. And I wonder how you get that message across if you've already tried speaking to him directly. Exactly. I was just thinking

that sounds exactly like the kind of conversation this manager would not get anything out of. Yeah. I'm just staring at all your good ideas you wrote and I want you to say them. Oh, okay. I shall say them. So this manager has a little bit of a self delusion. According to the question, it says, quote, he thinks he does everything perfectly. So I think the only way to disavow someone who has this level of illusions of grandeur and self perfection is to present them with cold hard facts. And maybe that means that you have to start tracking defect rates or time to merge or some other metric that you can find that shows that the rest of the team is working at one level and your manager is working at one very much worse level. And the goal is I assume

to show the effect on the team as a whole. It's not just hey you're bad at this it's hey when you do this thing the team slows down. That would be a very productive way to think about it. I was thinking of it kind of in the shorter term of just trying to disavow him of this notion that he's doing everything perfectly yeah but i think your approach is actually more productive like drill sergeants have to break recruits in boot camp that's right break them down first and then you can build him up after at your new job that you got fired from yeah i mean this person sounds like a difficult personality to deal with on the one hand he thinks he's doing everything perfectly he causes a lot of trouble and he complains vocally a lot my guess is that your ceo is

already aware of these personality traits and is probably already bothered by them unless they're just completely insulated who knows but another thing you could do is you could apply the jameson dance tried and true technique of doing nothing and then over time this guy might be gone anyway yeah i mean presumably the job of your manager is to make your team better and they are making the team worse and if if the conversation has been focused on kind of technical details of hey when you when you the question mentions code that's hard to unit test you know so then that could get you bogged down into lots of opinion-based discussions about dependency injection and and kind of like pure functions versus versus object orientation all these techniques you can

use to write unit testable code but in my mind the core problem isn't that they're not writing unit testable code it's that they're having a negative effect on the team as a whole yeah and maybe if you raise the discussion up to that higher level instead of saying like hey please brew your branches in this better way yeah if you can say hey we got this you know like we we need you to focus on these other tasks so that we can focus on the technical things and when you contribute technically like this it it slows the whole team down yeah and that's a discussion you can bring data to as well if you just say hey i spent i don't know 10 hours last week integrating your branch and fixing issues and that time isn't worth it yeah that's a great idea the other thing

i would consider is try creating automation and mechanisms that make it so that you don't have to be the bad guy or the cleanup guy meaning try to get your boss on board with creating new policies automated policies about how code contributions get made into your code base you're talking about like code coverage and yes unit tests passing and stuff like that exactly like yeah branch merging like to have a branch merge first all the existing tests must pass and secondly your code coverage cannot go down without an exception being granted or something and then when your boss writes new code and it breaks existing tests the system will stop him from merging them or if your boss writes new code and fails to write new tests then the coverage percentage will drop and the system will

stop him from merging them now this might just give him more things to complain about but now at least you're not the gatekeeper code coverage is a plot by the illuminati to poison our minds exactly yeah i like that i like that a lot having to feel like you have to jump in for very easily technically verifiable things like the tests are all broken does feel bad and that has a technical solution which is way easier to to implement the other thing you could do is try to figure out why we talked about this a little bit but try to figure out why your your manager is getting involved at this level and maybe the problem is they don't have enough management problems to deal with so you could create some management problems

yeah start a power struggle uh-huh try to get your your cousin hired yep create some like romantic drama on the team yeah yeah that would that would give them something to do yeah easy just run interference i'm certainly guilty of like i said earlier i'm sometimes guilty of of avoiding these fuzzier higher level management people issues and just diving into code but at least i know that i shouldn't do it you know like i have things to do sometimes i just don't want to do them right but maybe maybe they aren't aware of what they should be doing with their time in which case you need to like i don't know sneaky mentor them drop management books at their feet

on accident oh whoops and see if they're interested in in it oh oh look it's uh my my copy of andy groves high output management that just slipped out of my hand weird it's marked already in some certain passages that's what we call stealth mentorship what do you know it's the making of a manager by julie zoe and it it it's on kindle and i tripped and it emailed itself to your device that's so good okay so those will all work yeah guaranteed any other advice we have no i got nothing i mean this is a very tricky situation and i would love to hear how it turns out so this might not help you but one potentially one benefit for the listeners is if you go on to become a manager you should know this is this is a bad way to do things like do not do this put

put this on the bad list yeah try to be very very aware of how if you are going to contribute technically how those technical contributions affect the team and how the power dynamics go into that as well because it can cause weird stuff like this yep question answered all right question answered you want to read our next question sure this one comes from another anonymous listener who says i work in a digital agency as part of a team of five front-end developers with varying levels of experience we don't have a senior slash lead slash director it's pretty flat i have been told by management that we need to work on peer-to-peer mentorship because each of us have been guilty at some point of spinning our wheels on some problem when we

should have reached out the problem is we all work on different projects there's never two front-end developers building the same site and each site kind of feels like its own unique bowl of spaghetti if you have any pointers about breaking out our code bubbles that would be amazing i love the show I hadn't given non-technical skills much thought, but you've opened my brain. Thank you. You're welcome. All right. Thanks, listener. What I can tell from this is that your company is living Conway's Law perfectly. Wait, give me the Conway's Law definition.

Okay. Conway's Law is an old saying that says that organizations tend to produce software systems that mirror their own organizational structure by Melvin Conway in the 60s. And that's exactly what we have here you have a disorganized mess of an organizational structure and your code base is a disorganized bowl of unique spaghetti it's perfect i'm pretty sure melvin conway is on twitter or it's one of those accounts like dykstra quotes that maybe he's dead and it's someone tweeting on his behalf is wikipedia says is a computer scientist yes not dead i'm pretty sure he's on twitter oh yeah his name is conway's law yeah wait that gives me conway's solicitors in england oh it's conway's underscore law okay yeah yeah that's the dude that's him there you go

so you can follow him for tweets and also read his quote on software from 1967 which is just wild to me what the the fact that it's so old is wild or what yeah no the fact that he's he's this font of of kind of in software life's bands ancient software wisdom but also he's just kind of still around tweeting about halloween stuff and also computery things all right okay that was my answer to the question okay go follow melvin conway on twitter you're good yeah okay yeah back to your good idea so this follows conway's law because it's a mess yes exactly and it's also a mess that's right your org is a mess your code's a mess what perfect so the digital agency part is kind of unique here because i imagine there might be some separate billing

like maybe you're billing hourly for each of these projects and it does seem like it would be hard to have a cohesive team when you're all on separate projects and there's this additional thing that they're all kind of four different clients and companies you're just kind of this loosely affiliated group of people yeah and you're not accountable to each other so like if your code sucks you're the only one that will ever know it because you're the only one that works on this project it sounds like there's five engineers and they're all working on five projects or rather each i mean the clients certainly won't know it yeah they won't know if your code sucks it'll just be you yeah and so i mean that's one of the great advantages to working in teams is that you feel

the sense of obligation to your teammates to create well architected well factored and readable code documentation and things like that but if you're working in isolation it's really hard to do that so i think actually this peer-to-peer mentorship idea is not terrible how do you do it though because the question mentions that the projects are pretty different so it's not like i imagine they don't have a lot of context into problems on other projects yeah and you you could share that and that's just time is the cost there a lot of overhead yeah there are some community groups i'm a part of where people will talk about technical problems they're encountering at work and it's this similar-ish situation where it's not people who work together they don't have much

context on the problems and there's a lot of willingness to just help out in general so you could kind of form one of those at work it it sort of becomes more of a stack overflow model where you have to put in a lot of work to give context yeah and it's more tactical questions not someone auditing your code base and noticing things for you right but that's an option what i found is that when you have people who don't have a lot of context on your project and you need to get help with a problem, sometimes just the act of assembling the context in a way that can be shared with them will lead you to a solution. So I wouldn't necessarily walk away from this idea of paying the overhead price of collaborating with your peers, even though they don't work on your

same code base, because it could be that the very act of putting that together leads you to solving the problem that you are trying to solve. Another cool thing about this peer-to-peer mentorship idea is if everyone's doing it, the cost is shared kind of equally across all of your projects but also the benefit is shared equally and theoretically the benefit outweighs the cost for everybody so it's not just one person kind of sinking all their time into helping everyone else it's everyone helping each other out a little bit yeah one thing that has been helpful on my team we're still working on related projects most of the time and it's for the same company so it's a little bit different dynamics but sometimes they're pretty different projects

and we still do a lot of ad hoc pairing where people just just know hey someone might reach out to you to pair program on something and it might not be the task you're working on and it's it's a good trade-off to take some time off of your project to pair with them on their thing and vice versa they will return the favor it's it's this culture of kind of reciprocity and how much time do you find that people need to spend ramping up when they do that i mean like i said it's different it's not agency work and it's it's usually an hour or two at a time and i don't know maybe the first 15 20 minutes of that is just kind of sharing context do you have you found that There's kind of this economy of scale where because you've ramped up on a project before,

when that same person reaches out to you again later, you've already got some of the context. Yeah, that certainly helps. And so you might lose that in agency work if you're starting a new project every six weeks. But if it's longer term work, then you kind of pay that cost once up front. Breaking out of our code bubbles. I'm stuck on this idea of this context cost, but they don't specifically mention that as a problem in the question. It's just how do we do this?

yeah and i think all the ways that you would do it involve spending some time understanding other people's problems and in return they will help you understand your problems so maybe you do like i don't know a friday afternoon review where each each week it's someone else's turn to kind of walk through the project that they're working on and they kind of lay out their code and what they're doing and people get feedback and just some regular scheduled thing where that you get a chance to get feedback from other people yeah ad hoc pairing is a thing you can do too or you could do scheduled pairing and you have to deal with rotating schedules for five people to help pair with each other yeah you could do i mean brown bags are a thing that people talk about a

lot you just meet and talk about technical things i think you're right dave when you mentioned the manager who suggested peer-to-peer mentorship was on to something that everyone knows different subsets of things and fresh eyes can in some cases be just as good as very senior technical experience like someone else who has the same level of experience as you seeing your project for the first time can teach you just as much in some ways. Yeah, and who knows? I mean, if you do enough of this, it could very well be that even though your projects

are different from each other, you might actually start to identify cross-cutting threads that can benefit from shared effort or reuse. Yeah. Or at least like shared patterns, maybe. Yeah, that's a good point. If you look at it as our output is the project, but it's also the kind of team skill

at delivering these projects better, you've kind of been focused on the first, but not the second as much. And that's something that could unite you, even if you're all working on different projects you share the knowledge about how to get these done better yeah trust falls and laser tag are good fallbacks okay so you don't have time to review each other's code or to give context about your projects but you could at least stand up and fall backwards and have people catch you

fall down and see if anyone catches you yeah i just imagine someone sitting down at a desk standing up and then slowly toppling backwards and they thump as they hit the ground everyone looks over like what why did why did dave just fall to the ground and then you get very offended that no one caught you i thought you were gonna say a bunch of engineers scramble to run over and catch me no like the perfect outcome well that would happen to you maybe eventually maybe after a few a few good thoughts oh crap he's falling again run it's his cry for help he's stuck on he's stuck on a tricky concurrency bug

and you do some mob programming while they all cradle you yeah that sounds good what about some kind of like a regular cadence demo or architecture review or something where each developer has to do a presentation on their system that they've been working on yeah that's kind of what i was trying to suggest earlier with this these weekly weekly show off things oh yeah you could even turn those if you wanted to into mob programming which is kind of like pair programming but with larger groups where lots of people all together work on some code but it could also be higher level so it's kind of like pair programming but it's even less productive each person you add has to increase productivity by more than one person's amount of time i think you do it occasionally okay have we

answered it yeah i think i think that's pretty much all i would do i i will say i have heard this as a relatively common complaint about agencies yeah as is feeling like you're not kind of in the trenches with your team learning together right so i don't think these problems are unique to you i do think there are solutions but some of it is also a little bit exacerbated by the environment that you're working in if not totally caused by it i mean i hear this kind of thing a lot and one thing that makes it really complicated is that it's hard to organize these cross-team or cross-project collaboration efforts because what client do you bill for that time yeah you know we talked about this maybe being hourly earlier on and i think that's very likely to be

the case maybe your developers are paid a salary but you're getting billed or rather your company's revenue model is based on the hours they work for a given client yeah and so if they're spending you know three four hours a week doing this collaboration stuff it's like who do we bill yeah now the the slimy ceo might say let's just build both the clients for that time yes pair programming so it's twice as productive yep so and we're gonna build both of you for two developers yeah don't do that i've got no more wisdom in my brain okay i'm fresh out as well all i have in my brain is 90s pop hits little snippets of the chorus stuck on repeat i saw the sun

my kids have been listening to that song and i would walk 500 miles okay another 90s pop it's a good one there you go maybe it's time to introduce them to ace of bass yes maybe it is they're right what can people do if they want their own 90s pop hits stuck in their head they want their own questions answered go to soft skills.audio and click ask a question thank you so much to everyone who's asked questions we will get to all of them we promise eventually and if you want to support the show click that uh support us on patreon button on the same page and to help people find the show go to your podcasting app and leave a review especially if you are on an apple device it really helps people write a few nice words click the six

star button which you know you have to do the konami code first to get that one but thanks that's what we uh really appreciate it helps other folks find the show yeah thank you so much all right we'll catch you next week