Soft Skills Engineering - Episode 388: Money not compliments and principal engineer coding guidelines

Episode Date: December 25, 2023

In this episode, Dave and Jamison answer these questions: Hey guys, love the show. Not sure if its really a question or more of a confession. I’m an individual contributor at a software company with a few thousand employees. A lot of professional books/training courses I encountered over the years talk about the importance of positively acknowledging your employees/reports/team members when they do a good job. Most of them say that this sort of praise and other immaterial motivation is more important than material motivation (bonuses/raises). More and more, my higher ups had started trying to motivate us with public “pats on the back” for individuals and teams. They were never generous with the material motivation to begin with. Honestly, i find these pats on the back grating. I don’t need to be told “good job kiddo” to actually work hard. To be blunt, i want a raise and/or bonuses, not empty words. But material recognition is all red tape and budget constraints these days, so I dont actually expect much. The issue is that the immaterial motivation just reminds me of what is just out of reach, and thus just demotivates me. Is there any good way to express these frustrations to my manager without sounding like a materialistic greedy bastard? Which I suppose I am, but I’m tired of feeling like one. I’m a principal engineer working with two teams of developers who own a product domain that is being rewritten on an aggressive schedule. We’ve increased headcount over the past year but we’ve started having friction with some of the new hires. Its clear that they want more input into the patterns and coding styles used by the teams that were established prior to them joining. Unfortunately, this seems to come up in PRs rather than discussions and leads to push back from me and the tech leads on the teams. This has lead to our engineering manager commenting that they’re getting complaints about us being too restrictive and developer happiness being impacted. While I don’t want any of the developers to be unhappy, I worry that the EM is risking hurting the team as a whole by focusing on the happiness of one or two new hires. The Tech Leads are also starting to worry about what they are allowed to comment on in PRs. Help! How do I keep the devs from feeling underappreciated, the tech leads feeling empowered to lead, and ensure that the codebase stays consistent between repositories so all developers can move between services without feeling lost?

it takes more than using unlimited vacation in micro doses to avoid meetings to be a great engineer this is episode 388 of the soft skills engineering podcast and i'm your host jamison dance i'm your host dave smith and dave i have 20 minutes of vacation scheduled so you'll have to do the rest of the podcast without me sorry i'll be available by email in case of emergencies i'm just thinking about someone's calendar who's peppered pto midday out of office pto 20 minutes at a time if actually you could really optimize that by taking the first three minutes and the last three minutes of every hour as pto oh to prevent countering systems from ever showing you as available okay it's perfect

yeah there some people see unlimited vacation as a benefit and others see it as a challenge yeah how far can i push this system exactly it's like my son always tells me about unlimited resource hacks on minecraft it's like the same thing but with pto policy yeah if you push this hr person in just the right direction and place them next to a villager you'll get unlimited pto if you pause work at this moment it causes a buffer overflow which then grants you 8 000 days of pto a year okay you want me to thank our patrons you just you have to scoot on your butt perfectly timed okay there's like a super mario speed running thing or something all right yes i do want you

to thank our patrons okay weekly shout outs today go to chase w norton type hero.dev never is just wait never is not just a crater on mars with a flamingo emoji i like chicken i like liver miyamix miyamix please deliver trash panda the computer science book.com valentin a data fold santa hope our kent c dodds jenny kim owen charlotte quagmire the stochastic parrot patreon.com we're hiring ira chan monkey face emoji jonathan king web tau awesome end-to-end testing will angel ragnar travis brayden canes john grant the unsettling nature of not knowing and nick cantor if you'd like to join this illustrious crew go to soft skills.audio and click the support us on patreon button where you can enter any dollar amount to get access to our

slack community and a sufficiently high dollar amount that makes jameson's eyes go super big and it makes his eyebrows go up to almost touch his hairline then we'll say your name on the show every week if you count hairline as hair then my eyebrows are already touching my hair because i my hairline because i haven't gotten a haircut in a long time okay thank you so much we do appreciate the support makes us feel good makes us keep going that's true makes your life better dave shall i read our first question i was hoping you would okay this is from an anonymous listener who says, Hey guys, love the show. Not sure if it's really a question or more of a confession. I'm an individual contributor at a software company with a few thousand employees.

A lot of professional books and training courses I've encountered over the years talk about the importance of positively acknowledging your employees or reports or team members when they do a good job. Most of them say that this sort of praise and other immaterial motivation is more important than material motivation, bonuses, or raises. More and more, my higher-ups have started trying to motivate us with public pats on the back for individuals and teams. They were never generous with material motivation to begin with. Honestly, I find these pats on the back grating. I don't need to be told, good job, kiddo, to actually work hard. To be blunt, I want a raise and bonuses, not empty words. But material recognition is all red tape and budget constraints

these days, so I don't actually expect much. The issue is that the immaterial motivation just reminds me of what is just out of reach and thus demotivates me. Is there any good way to express these frustrations to my manager without sounding like a materialistic, greedy expletive, which I suppose I am, but I'm tired of feeling like

one. How can I be a greedy expletive without feeling like one? We're really getting to the heart of the issue here. Yeah. oh goodness about it huh i have i've vaguely heard this same stuff and i'm sure someone at

some point has linked some research that i haven't looked at and it's probably failed to replicate like all social psychology stuff but i i've i have this swirling around my head too that like people financial rewards don't directly motivate people to do better in the stuff that they test in these papers if you're like a freshman in a psychology course like cutting out more shapes in california or something yeah exactly yeah but if we give you 50 will you cut out twice as many stars this definitely translates to the real world yeah i mean there is something to this in that people who are really driven by a a mission and a purpose often accomplish great things that folks who would like to work harder to earn more money don't.

But it does feel like there's some cold calculus going on here of, I will, with each pat on the back, this is worth $1,000. This is $1,000 I don't have to pay you. So they're like, I don't know. Yeah, it feels weird. The pat on the back feels weird. but I'll tell you, I find myself able to compliment my team and I don't, boy, how do I say this without sounding like a schmuck? But let me just go with the schmuck version. When I compliment my

team members, it is from a genuine place of being impressed with their work as a practitioner of their craft. I look at that and I say, wow, that was a really hard problem to solve and you did it. man i'm impressed that is so cool that's the kind of compliment i give but i imagine this person this question asker is talking more about like you know the the hr manager who comes by and says hey good job everybody yeah yeah there's a there's a slide deck and there's a time to recognize our official pat on the back extra mile recipients and it's the list of names they say good job these people yeah your contributions have been noted so i don't know i i i totally understand the feeling of being complimented what it's kind of like an empty compliment like you don't even

know why this is a big deal like great job with that code you did yeah that you coded yeah yeah i'm like okay you don't even know whatever but but there really are i think really valuable things you can say and do to recognize people on your teams that don't involve giving them money. Like, for example, sharing some of the results of their work. Like, hey, because you fixed that bug, we were able to, you know, close a new business or bring back a customer or help someone solve a problem that they weren't able to solve before you fixed it. You know, all kinds of really cool things. And I think that to me, that stuff is motivating. You know, it's not as motivating it's a thousand dollar check but hey it's pretty good i mean i think if you felt fairly paid

it probably wouldn't feel as patronizing yeah to the question asker so i i think if you feel like you deserve more money than you're getting you should try to address that because it's not gonna get better on its own probably with salaries it's very much the squeaky wheel gets the grease as i was saying that phrase i had a brief moment of panic where i thought wait is this actually a phrase i don't know why it just like left my mind wait did did i just make that up is it i thought it was the squeaky grease gets the wheel but i don't know maybe the squeaky candle gets the wax what is it so i i do think you should bring up to your manager i feel underpaid and i would like a raise

and there's a a vast body of knowledge of how to go about that but i i don't think you necessarily need to say it feels like you're trying to say good job kiddo instead of pay me money because i don't think that's gonna work like i don't know you're not gonna make them feel guilty and suddenly come to a realization of, oh, you're right. We have been trying to manipulate this chink in your psychological armor. Right.

We've been called out. Yeah, you're right. You caught us. Oh, now by the rules of the game. We'll just start giving you money now. Yeah. Yep. Them's the rules.

You could fight fire with fire and start giving compliments back to them. Like, oh. Like instead of doing your job? yeah instead of jira tickets just yeah well i was gonna fix this bug this week but instead i spent the week writing a hollow compliment for my director thank you director for giving me compliments instead of paying me money we laugh but i mean i guess it is a strategy some people use to ingratiate themselves with their superiors by sucking up. So maybe you could do that.

Yeah, I think I would, despite all the red tape and budget constraints, if you feel underpaid, you should still bring it up because maybe there's something they can do and maybe not. And it would be good to know that. It could be that they're not trying to pinch pennies by giving you compliments but they're trying to say look we don't have the budget for raises what can we do despite that so it's more like they're not like stealing from you directly to to fund their yachts they're they're like uh their yacht they've emptied their yacht accounts i don't know i think i switched directions midway through that statement the point is i can see how it feels patronizing you should ask for a raise the answer still might be no but i don't think you need to

bring up saying the the issue of like these compliments feel hollow to me while you don't give me money yeah in other words you can decouple the two facts i'm underpaid and these compliments feel like they are compensating for the fact that i'm underpaid they're compensating for a lack of compensation just kind of meta yeah i agree with you jameson i think as long as you're underpaid or feel like you're not paid well you there's like a whole litany of things that companies can do that will make you mad oh yeah like oh you brought brought in lunch for everybody you know like yeah or oh you took an uber to the office today and had the company pay for it yeah exactly like funny how there's budget for that yeah and like all these things so many things

will irritate you like we pay for someone to come water the plants in our office but we don't engineers a reasonable market rate anyway so so really this is just one example of many so i i agree with you jameson that we ought to separate you ought to separate these two problems the problem of i get hollow compliments and i and i don't get paid well because guess what if you get paid really really well and make a ton of money and you're super happy about it and you get a compliment you're like thanks the extra mile hat privilege this week you know that's fine i'll wear it wear it with pride i showed up in a powerpoint slide they gave me this cheesy stocking cap with a gold star on it well have we answered the question yeah it's like very simple just

go get a raise problem solved yeah like why didn't you already do that okay i've got one more solution you could try which is you need to guide the compliment givers to give more meaningful praise the praise feels hollow but what if they were so good at it that it didn't feel hollow it was genuinely motivating this could potentially solve your problem as well okay like what are the kind of things they would need to do or say i can't possibly go into all that now we've got another question to answer okay good point good luck dave do you want to read our next question i do and and i just want to say

you answer questions good thank you and i will not be giving you the raise you asked for consider this your race yeah consider this hollow compliment your race okay dave you're you're pretty all right pretty all right award of the year okay this question comes from an anonymous listener who says i'm a principal engineer working with two teams of developers who own a product domain that is being rewritten on an aggressive schedule we've increased headcount over the past year but we've started having friction with some of the new hires. It's clear that they want more input into the patterns and coding styles used by the teams that were established prior to them joining. Unfortunately,

this seems to come up in PRs rather than discussions and leads to pushback from me and the tech leads on the teams. This has led to our engineering manager commenting that they're getting complaints about us being too restrictive and developer happiness being impacted. While I don't want any of the developers to be unhappy, I worry that the engineering manager is risking hurting the team as a whole by focusing on the happiness of one or two new hires the tech leads are also starting to worry about what about what they are allowed to comment on in prs help how do i keep the devs from feeling underappreciated the tech leads feeling empowered to lead and ensure that the code base stays consistent between repositories so all developers can move between

services without feeling lost oh good question it's a great soft skills question that's exactly that i was thinking like this question is awesome yeah it is it's it's like the perfect platonic ideal of it's not a technical problem i mean it's it's people and feelings and communication and it's unlikely that you will add two random people to a team and have them have exactly the same technical opinions and preferences as what is already manifest in the team 100 and i just want to say i love this principal engineer this is someone who really feels a strong sense of ownership. It's to say, look, I'm trying to make the engineering managers happy, the tech leads happy, the new hires happy, the existing developers happy, and have a clean code base. Man, that's

just awesome. I wish every principal engineer had this kind of level of care, you know? Yeah. Yeah. Well, what do you do? Well, because you're a principal engineer, you've reached the top of the chart. So there's no sense in really solving any problems anymore because you're not going to get promoted. So I don't know maybe nothing have you tried giving empty compliments yeah you're so good at complaining about our coding style yeah i i can see both sides certainly when you are new to a place you're both experiencing the the you've like jumped into a new ecosystem and it is for sure different from your previous ecosystems and and so there'll be stuff that seems weird and some of

that stuff will seem weird and bad and some of it will be weird and you just don't understand it but it'll it's neutral and there's some stuff that seems weird and bad that's actually good for an important reason and and you just have all this past knowledge you're trying to apply to a new situation without knowing the new situation super well but you want to feel like you are effective and impactful and also that you have ownership that you're not just doing the task someone tells you to do but you can like do the meta work of making it easier to do the work and making the work overall better so that that makes a lot of sense and also boy does it suck when someone joins and they say hey we gotta do the we can't do this the same way we gotta do this differently

and then like it's gonna be years of migration and yeah like yeah you have this preference it will cost us six months to accommodate your preference right how many millions of dollars should we expend in engineering labor and opportunity cost yeah to yeah format our code a little differently yeah and my answer many many millions as many as it takes baby well that would have been true in a zero interest rate environment yes right that would have been true for a brief 20 year period yes yeah developer happiness was like this magical talisman you could wave in front of people and it just it of course it was good like i can hear this the engineering manager is saying developer happiness is being impacted

and we cannot we cannot have developer happiness impacted it's our most important business metric Yeah. You know, I've worked at one company that had hit the last goal on this principal engineers list, which is ensuring the code base stays consistent so that all developers can move between services. I honestly don't know how they did it, but I was struck because I worked on like two or three different teams over the course of four years and saw probably, I don't know, 15 or 20 repositories in that time. And even when I was reading other teams' code, I was struck by how consistent the styles were. Very similar style, very similar processes, like deployment processes,

code review processes, very similar set of libraries that were used versus not used, just occasional deviation here and there. It was very impressive. And the only thing I thought that I could attribute that to was, well, two things. One was very clear documentation that had been written that everyone could point to like they were 10 commandments etched in stone, you know, where it's like, look, here is our style. You have a problem with that style, take it up with the style guide authors, you know? And so you could just link to it. And number two, very aggressive linting and code formatting rules that were actually not that aggressive. I'll just say moderately aggressive code formatting and code style rules that were imposed on all code at code review time through automatic tooling.

You know, things that would call out like a bot would auto comment on your code to say, hey, this doesn't conform to X, Y, Z. But typically those weren't so much formatting as they were things like security vulnerabilities that were common problems in this language. things like that so i would say that it was actually the documentation the style guide docs that really governed the consistency that feels like if you're already in that state it keeps going but yeah if in this case they're rewriting some software on an aggressive schedule i'm assuming they don't have an exhaustive style guide and it doesn't sound like they have time to just pause and write one up real quick. Well, you know who does have time? It's these new developers that are making all the noise. It's like, here, redirect that energy to writing a style guide and

then go through the process of building consensus and getting everyone to agree to it. And honestly, if a developer is not willing to put that kind of effort into it, then they probably haven't earned the privilege of complaining about the code style. Yeah. It's a little harsh, but it's Like, how much effort are you willing to put in, you know? I know that I have been, I've definitely begun to care less about this. I mean, I kind of have to. I care less about this the longer I work in software. By this, I mean what the specific patterns are, but I care about a minimum set of, or

minimum bar of consistency. I think a overly rigid insistence on consistency could be harmful. Maybe it's worth the trade-offs at scale, though. I don't know. But I care a lot more that you're trying to be consistent than what you're trying to be consistent with, I think. What is my point? I guess I'm just better than you. That's my point.

I'm like, why am I even saying this? I don't know. I mean, I kind of felt compelled to say the same thing as you. Tell them all to be like me. Why don't you be more like me? I kind of felt where you were going there because I kind of felt the same way. Like I was thinking, yeah, I also don't care about what the specific technologies or language or style is. I just care about the consistency.

And it occurred to me like, yeah, that's actually what the question asker is saying as well. Like there's no, this isn't like a technology X versus technology Y or pattern X versus pattern Y. It's just like, let's pick one. maybe i'm reading that wrong let's see i i think the point about feedback in pr discussions is interesting because on the one hand you could say part of the goal of code review is to have those discussions so it's it's working right like that conversation is being had someone saw this change and said hey maybe don't do it this way do it this other way and then people start talking about it but on the other hand that's an expensive time to enforce guidelines yeah if you're saying

you need to change your code or your architecture decisions to look like this it's it's already done in in a different way i know it's so wasteful right it's like here we have a working solution that's about to produce value but we're gonna hold that up to rework it now like in in some cases that makes sense but if the business hasn't already committed to a consistent style or set of approved patterns or a linting rule set then this really isn't the time to do that it's almost like a hostage negotiation like yeah i'm gonna shoot this pr if you don't yeah you know give into my demands approve the pr or the feature ships late yeah so this is why i say you really need to be able to point to a document. And honestly, the principal engineer in this case should probably

be the person who spearheads creating that document. It really will solve almost all of these problems, especially if you give everyone a chance to have their input. And especially if you tell people like, hey, look, we're going to do this because we want to optimize for the flow of our organization. And this is going to mean that some people might not get their preferences and others will. And some people might get some of the preferences they want and other preferences that they also want won't be granted. But in the interest of a team that is rowing together in this metaphorical boat, we are going to pin down a set of concrete patterns that we will and will not allow. And then anytime there's a dispute about it, the PR is not the time to do that

dispute. You can reject a PR if it doesn't follow the documented guidelines, but you can't invent new guidelines in a PR. It's like totally the wrong vehicle. Yeah. I think I agree with you that if you, I partially agree with you. I agree with your point that the PR is the wrong vehicle for it. Sometimes you might not notice you're doing things a different way and then it's kind of like a backstop. But if you know, like, I think we should write code this way, so I will do it in the pr and and you know that there's kind of a culture of wanting to be consistent that that does feel less effective and i agree that that's a that's a thing that a principal engineer should be able to kind of like enforce in the team it's very technical it's it's like yeah rowing together

like you said i'm just repeating what you said and and so you can say like don't do this in a pr you could say it in a positive way by saying hey if you want to if you want to change how we do stuff let's talk about it yeah let's talk about it first that's that's the way we make changes right i i do think there is a there will always be stuff that isn't documented that feels like a standard in in the code even if you have a document so i i do think a document can help but there'll be cases that are not covered by the document. So I think you can't point to the document as the ultimate solution.

You still have to have a way to handle stuff that isn't covered by that, but you actually do have some consensus on already. And maybe that's like, oh, good news, you found a hole. We fixed the hole. Yeah, but not in the PR. We'll fix it later. Yeah, yeah.

And I'll just say, just having a document that covers a pretty broad set of the things that do come up regularly, is almost, I believe, enough of a mechanism so that people know there's a pattern for getting team-wide consensus on things like, hey, this pattern is not allowed. And so it almost gives them a route to be able to get that change made organizationally in the right place. Whereas today, the only place that this comes up is in these PR reviews, because that's the only place it comes up you know but as soon as you have another place where that it can take place

then hopefully it'll take some of the pressure off these pr reviews yeah yeah i like that a lot you're channeling it in a more helpful direction it only works if people know it exists and read it yep definitely possible to have a style guide that no one reads and it is it is and i think that's the the definition of success here is if people reference the style guide in like prs and and other places and say oh well actually here this is we've already documented how to do this here it is you know yeah that that that's how you know it's working yeah go did a nice job of this they have a style guide that's just a list of links and just drop like a link to like style guide thing number 31 comment formatting or whatever and they took it even further ago

which i really like to say look actually our language has an opinion on certain style elements and every time you run it we're going to reformat your code whether you like it or not yeah that's kind of spread more through through other languages and i dearly miss it in any environment that doesn't have it yeah it's a really cool thing it just shuts down so many unhelpful conversations yeah you know it's like oh if you have a problem with the style you know where to fix it yeah well tech leads feeling empowered to lead your tech leads should feel empowered to lead and if there is a way if your tech leads are shutting stuff down in prs because they don't want it to happen i could see that causing frustration on the new devs but if they

have a positive direction to channel it then yeah it's not just like a slap on the wrist no it's like, well, here's what you can do if you want to change our practices to meet this, to fit this pattern. This is actually a really important point for a principal engineer. So in this situation, and in most principal engineering situations, you're doing something a little bit different than just technical leadership. You are actually providing a framework that other leaders can operate in to direct the works of their teams. And so here you've got tech leads and engineering managers that you as a principal engineer are responsible to help coordinate on this. And there's a new hazard that comes up when you move from directly leading engineers to then

leading people who lead engineers. And that hazard is that you are going to provide policy for these leaders to enforce, and sometimes they're going to enforce it wrong. And that may be what's happening here is that your tech leads are doing things that are making your engineers unhappy. And when you find out what they're saying and doing, you're like, that's not what I meant. I wanted you to, you know, I wanted the policy to be more flexible than that or whatever. And, and I've seen this, you know, I'm currently on a, on an executive team and we see this once in a while where we, we will come up with a policy, we will communicate it to the leaders in the company. And then we will find out that those leaders made a decision

that we disagree with in like, you know, whatever it is, approving something or not approving something. And we go, oh crap, we got to have a better conversation with that, that leader so that they know how to run their organizations within the framework but it's super meta like it really isn't it's not just like i'm going to tell you how to do your job then you're going to do it it's like i'm going to tell you how to do a job then you're going to tell someone else how to do a job then they're going to do the job you know so it's like yeah really complicated and so it's worth spending a lot of time talking about this and i and if i were this principal engineer i would convene a meeting with the engineering managers and the tech leads and i would sit down

with them and say hey guys let's figure out what are the tenets that we think are important for our coding style that these new engineers are bringing up. And state the things that you think are important. Like, I think developer happiness is important, but I think it takes a backseat to consistency across repositories. Let's discuss, do you agree or disagree? You know, and start to get, this is how you build alignment. You know, you talk about these different ideas and you bring up the contentious points and you say, what's more important, X or Y? And then you write all that down put it on a document and you've got a good starting point for your coding style guide and you've got some fodder for a technical blog post yes and content put that in your promotion document

oh sorry you're a principal engineer you're done i'm just kidding there are more there's more there's senior principal staff no not staff distinguished engineer distinguished yes and then there's the extinguished engineer after that preposterous engineer the great and terrible yes the unprincipled engineer dave smith yeah they start to feel like royal titles the archduke may his arm stretch ever longer over the seas of clusters i think we're done i think we've answered it i think so good luck what should people do if they don't want their own questions answered if they don't want them answered no they do what did i

hear that right i don't think so i think i said if they can't wait to listen back their own questions answered oh i mean my mind heard just a wonderful version of that which is what should people do if they don't want their questions answered well good news nothing you don't have to do anything It's really easy. But if you do want your questions answered, go to softskills.audio and click the ask a question button. We check that often, obsessively refreshing the answers, not the answers, the form fills. And thank you. Thank you so much to everyone who fills out that form. We love it. And if we've answered one of your questions and you would like to tell us what happened next, if you took our advice or didn't, we would love to hear about it.

You know, we're, we're actually trying to build a training set now, but we don't know how to label our answers as good or bad until you come and tell us. And then eventually we can replace ourselves with AI and make good on our promise to answer all the questions. Yeah, that's true. That would, we'd polish them off. Now I'm just imagining the soft skills audio, like chat GPT plugin. Yeah. I wonder if you could do that. Oh, okay. I know what I'm doing after the show. answer in the style of soft skills engineering all right well we will catch you next week thanks for listening