Soft Skills Engineering - Episode 148: In the orbit of a Rock Star Programmer and Should I share my salary with my coworkers?

Episode Date: March 11, 2019

In this episode, Dave and Jamison answer these questions: I’ve been an engineer for about 5 years and in the last two jobs, rock-star programmers have made my life very difficult. I define rock star programmers as ones with ability to produce lots of code and implement features at a pace that dwarfs my own. In my last job, the RSP would constantly rewrite core libraries and I would have to figure out his design and rewrite my code to adapt to the new design multiple times. In the current job, the RSP is very uncommunicative but with his sheer productivity steers the project into wild directions that are always coming as a surprise. Half the time my work then becomes throw-away because I was working based on the previous design. Am I a slowpoke and I’m seeing a normal programmer as a rock star or are these programmers just slightly above normal programmers but creating lots of work for everyone else? Managers are completely starry eyed at RSP and so talking to managers seems like a bad idea. What should I do? How do you feel about sharing salaries amongst your co-workers? I’m about to have my yearly review and I get the sense that my raise (which has already been promised to me) will be underwhelming given how stingy the company has been previously. That is simply a hunch based on previous experience and the fact that our team budgets have tightened up in the past 6 months. Recently a co-worker let it slip what his salary is, and though I don’t like playing the comparison game, it made me feel underappreciated. I discovered that he was making the same salary I was, but for lower quality of work and less contributions to the team. I’ve heard some devs in other companies advocate for sharing salaries amongst their peers, but I’m not sure if it’s a good idea. Will sharing my salary and encouraging my co-workers to do the same, allow for myself and my co-workers to better understand our value and help us negotiate raises? Or will it simply foster resentment and division?

It takes more than knowing about dining philosophers to be a great software engineer. This is episode 148 of the Soft Skills Engineering podcast. I'm your host, Jameson 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. Can I just ask, like, what is really what is the point of the dining philosopher story? What I really want to know is what are they eating that is causing them to just furiously

scrabble for forks? was it is it like an n minus one problem there's like fewer forks than there are philosophers i don't remember see i totally have that off the top of my head but i can't tell you because that's not what this show's about it's it's a concurrency problem right isn't it about deadlocks i think you're basically right where there's yeah there are fewer forks and i remember in college like studying this and being like wait is there supposed to be a solution to this like a puzzle that you're supposed to solve and i just i never got the point like i know what semaphores are i know how to use mutexes i've done a ton of concurrent programming but i never got the

point of tiny philosophers. Someone will have to enlighten me. It won't be me. I'll just say that. Do you want to thank our wonderful patrons, Dave? You know I do. Thank you so much to those that are contributing. I don't know if we've made this clear, but at certain levels, you get a one-time shout out. And at other levels, you get a shout out every single week. And the list just grows. So thank you to those who are contributing. This week, we have a one-time shout out from Dr. Ivo Robotnik. And the rest of our group contributing at the level, they get a shout it every month, sorry, every week, is Matthew Wodowicz, the Agile Ventures Charity, Zach Grannon, Luis Santos, Nick Kantar, Sean Clayton, Sonic the Hedgehog, Marais Rosau, Chris Hogan.

Thank you so much. If you'd like to contribute, go to our website at softskills.audio and click support us on Patreon. All right, I'm going to read our first question. This is from an anonymous listener. I've been an engineer for about five years, and in the last two jobs, rockstar programmers have made my life very difficult. I define Rockstar programmers as ones with the ability to produce lots of code and implement

features at a pace that dwarfs my own. In my last job, the RSP would constantly rewrite core libraries and I would have to figure out his design and rewrite my code to adapt to the new design multiple times. In the current job, the RSP is very uncommunicative, but with his sheer productivity steers the project in wild directions that are always coming as a surprise. Half the time my work then becomes throwaway because I was working based on the previous design. Am I a slowpoke and I'm seeing a normal programmer as a rock star? Or are these programmers just slightly above normal programmers, but creating lots of work for everyone else?

Managers are completely starry-eyed at RSP, and so talking to the manager seems like a bad idea. What should I do? Oh, wow. You know, this is like the rock star programmer metaphor, which I hate. Actually sounds pretty good here, right? Like you've got this person, they do a lot of drugs, yeah, they trash your room. yeah they're disrespectful of your life of your code they do whatever they want because they're

the rock star yeah you know next time i see a billboard that says you know we're hiring rock star programmers i'm gonna be like that job's not for me our mechanical keyboards have a special groove that you can fill with cocaine to snort exactly yep oh my gosh that's the environment for me surely oh so i i am not a rock star programmer i have worked with folks that are very productive And I've worked with folks that are also very disruptively productive, but I don't think I'm the person that would, I don't think I have just the sheer chops or pace to just like crank out enough stuff to, to move folks worlds around like this. Yeah.

I want to latch on. So I think there are, you mentioned there's super productive programmers and then there's disruptively productive programmers. Yeah. And I don't think those things have to go hand in hand. Like you can be productive without being disruptive. And this particular Rockstar programmer looks like is very disruptive. Rewrite, it says here that this RSP, I like that acronym, by the way, RSP.

This RSP rewrote core libraries multiple times, and I had to figure out the new design and rewrite my code. I'm like, whoa, wait a minute. You can be productive and crank out code, but if you're a library owner and you're rewriting the library such that it breaks your APIs, other people have to rewrite their stuff. Yeah. That's just straight up irresponsible, no matter how fast you're doing it. Yeah. It feels like there's some technical, there's the technical output is far outstripping

the communication output and coordination output, which makes sense. If you don't have to coordinate with anyone, like you can go faster. It turns out if you just, if you just don't have to maintain backwards compatibility ever, like, yeah, it would be faster. Oh yeah. Nothing slows down a software project like customers. Oh boy. Yeah. It's pesky customers. You know, Why aren't there any folk star programmers? Folk star? Yeah, or like jazz star programmers. Just like smooth jazz, responsible, you know, easy listening.

Yeah. We need to branch out to other genres. Pop star programmers. I feel like pop star programmers might be pretty good to work with because I feel like they're a lot more polished and like broadly appealing. The crowd pleasers. yeah yeah they're not they're not gonna like smash their drum set yeah be a pop star programmer a psp yeah and then yeah i like that so

what what do you do if you're if you're the hotel owner and your hotel room is getting trashed i'm sure your music is great please stop throwing my tvs out the window well you certainly can't go talk to the band manager hey can you just get a nicer rock star yeah what a predicament though it's like what do you mean our most productive awesome programmer needs to slow down are you crazy yeah i mean that's the manager response right yeah i could see getting addicted to if they are disruptive but check off a lot of things i could see that being addicting as a as an engineering manager or product manager or something where you know it's got these longer term effects and it kind of hurts morale and causes other folks a lot of work but boy does

stuff really move through fast and yeah it would be hard to recognize the longer term damage that this is doing i think it's especially hard if no one brings it up too you know in the x-men universe there's that one character who can shoot laser beams out of his eyes his name is cyclops yeah as a kid cyclops had a problem because these like laser beams would just come out you know crazy out of his eyes in every direction he couldn't control them and then dr charles xavier gave him special glasses so he could like focus the energy that's what i think this programmer needs like you have this raw talent that's just spewing out in every direction in the form of high velocity code changes but he needs focus right like needs to be able to focus that laser beam in such a way that

it's unharmful to your teammates while still being productive and useful for the product and your customers i i think about one of the most productive developers that i ever worked with and and they were so productive because they could both produce a lot at an enormous rate but also do it in a way that wasn't disruptive to the rest of the team. And they were really good about maintaining API compatibility, and communicating and documenting changes, and also planning things out. So kind of letting us know upfront, like, hey, this giant thing is going to get done pretty fast. But here's kind of when it's coming and how and I feel like they could have been a rock star and just just done everything and made life hard for the rest of us. But they weren't they were

they were purely a net positive because of that. They were careful to communicate around it. And that feels like what's missing. There's no communication. Like code is not the only artifact that you produce as a developer. So I have a question about this super productive developer. Are they looking for a company to join at the moment? I don't know. Yeah, I mean, but I've worked with more people that produce a lot of code and change everything all the time than I have who are like responsibly super productive. So in the end, do you think that the net productivity of the team comes out to like a positive number as compared to if this person were operating at more normal rates? Or do you think that the disruption actually

exceeds the net productivity from this rockstar programmer? I don't know. I don't think I have a way to quantify it. I think it probably depends, which is just a great answer because I don't have to share any knowledge. You can never be wrong. Yeah, exactly. I think it depends on the situation though there might be times when maybe the team's okay with it but if it causes maybe folks bounce out of the team or oh yeah or your product gets there's no coherency to its design that's probably not a word but now it is uh it has evolutionary design i guess is what you're saying yeah yeah if yeah if it's just like how what's a good metaphor for this if it's grown tentacles and in places it shouldn't have tentacles isn't there did you ever watch fantasia oh yeah do isn't there

a scene where the the earth when the earth is forming in one of them and the mountains just like jut out all over the place am i making that up i can't remember but yeah let's go with it but i feel like that's that's kind of the design you could end up with in your architecture if you have someone who's just like recklessly productive like this where suddenly they're like they just slam a bunch of code down on one thing and then move on to the next thing and and it it doesn't grow in an orderly way yeah so i think that's a potential danger too yeah i don't know what you do about it though right this is all like is it good or bad but what what what do you do if you're working with one of these people yeah this is a this is a great question and indeed the question

that was asked of us oh maybe we should answer it i think now is a good time to answer this question so i think that it takes a very capable manager to recognize that you have this kind of a situation and to coach this person into a focused productive and unharmful pattern and if your managers think that this person is just perfect and that they are doing everything right i think you're going to have a much much harder time getting this situation fixed and if that's the case i'm just going to assume that's the case i think you're going to have to go to this person and somehow quantify the derivative effects of their rapid work and and this is by the way this is not just a good programmer a fast programmer this is a this is the kind of person who seems to disregard the

pain they cause others like rewriting core libraries takes the project into new directions that no one saw coming and it's a surprise then causes us to throw away work if you can bring that information in an easy to digest way to this programmer and say i just want you to be aware we had to throw out this many hours of engineering work because of this decision and if you had instead consulted with the team first and gave us a heads up about the direction we were going to go we could have prevented going down these dead-end paths that we did i feel like i'm i'm forming an image of them in my head that's based on only this question but i wonder if they're the kind of person that just loves to code and everything else they see as kind of a distraction so writing

up docs is is pain that is avoided by diving into the code or or there's all this communication overhead that goes into changing and building software and it feels like they just don't want to do any of it and and that feels irresponsible to me absolutely i think if you're going to make large changes you should be expected to communicate about them so i think it's fair to go to them directly and say hey we we need to work together effectively and we can't when you make sweeping changes like this without talking to us beforehand yeah and i think you have to make it clear that you're you're okay with them being productive and kind of working on on things that they're excited about but it just has to not come at the cost of the rest of the team it's not your job to

like toil away in their shadow while they hog all this glory by just changing all this stuff in front of you yeah and okay have you ever heard of the concept of an externality in economics i have but i want you to explain it i think that i think i think that's what's happening here this programmer is having just a great time you know cranking through the code making all kinds of progress getting praise for management but causing externalities which are effects that other people they're negative effects that other people shoulder as a result of this person's work and i think if you could make those externalities clear to this person or to management then i think you could have a chance at fixing the situation and that's why i think it's not out of the question

to talk to management about it not in a tattletale way but just to say if they're so enamored with their output that means that they do not notice the effect that they have on the rest of the team that's right so so you could just say hey like this task is late and it's late because we had to throw away all our work because all these changes and make make those because to your manager that's not an externality because they're they care about the productivity and output of the whole team and the individual programmer might just care about getting their stuff done but the manager like if the team is less productive overall then that's that's that's something they should care about that's a really good point and you know what else i think that if you come to

this this co-worker and say look at all this extra work you made me do and all this code i had to write they might they might not see that as a problem because like they love writing code and if they have like yeah you get to use my new awesome design yeah like this is so cool like you get to rewrite all your old crap with this new thing it's going to be great yeah and also they they probably run at a very very fast pace and so to you it's like crap this is going to take me four days to unravel this mess they would be like oh that's going to be like an awesome afternoon you know yeah and so i think it might be hard for them to see the overall productivity of the team as having issues and i gotta admit like confession time this can be me on your i am

like this sometimes you know i i write code i love writing code very i write very fast i think and i crank stuff out and i want to move fast and occasionally i have caused my team pain this way what happened let's see i mean like did did you ever did anyone ever address it consciously or did you just kind of not do that anymore well yeah i i'm a i'm a little more sensitive than it sounds like this person is like i can tell when issues have happened like for example my hastiness caused a bug just in this past month where i was making some really big refactoring changes because I was dissatisfied with the way this code was written and someone else was working in the same code base. And out of courtesy, I let them merge first and I dealt with the conflicts,

you know, because that's kind of how it goes. A person who merges second, they have to deal with all the conflicts. Well, because it was such a big change and because I was resolving conflicts in a somewhat foreign code base, I resolved one wrong and ended up shipping a bug that took this person like a week to find. So, you know, a huge, huge mistake on my part. And the reality is I should have sat down with the team and talked through it and actually like described the problem. And then we could have worked on it together and in smaller chunks to do the refactoring. It would have taken longer, but we probably would not have had that bug. So that's just one example. Yeah, that's, that's really interesting. And I think it illustrates the point

that you can go fast as an individual, but to go fast as a team, the only way to do that is by communicating. Yeah. And if you skip those steps, I think you go slower overall. Yeah, absolutely. Well, so there you go. I'm sorry. I have never been a rock star programmer. I'm more like a contemplative philosopher programmer. Struggling to get that fork off the table. Yeah, just slowly thinking.

Are you a writer? Do you tend to write your ideas down on paper before you implement them? I've started doing it a little bit more. yeah so you're just more of a thinker beforehand like naturally you just sit back and thinker implies that the end result is like really well thought out and i can't claim that's always the case sometimes the only thought in my head really is like hmm it's not like hmm which of these trade-offs should i make and which is best it's just hmm yeah it's just hmm i'm i'm you know what i am i'm a leisurely programmer that's what i am i'm all about the leisure what's the okay what's

the metaphor if this guy's a rock star what are you i am a fisher programmer but one of those fishermen that doesn't even like to catch fish i just chill on my boat it's got like speakers and a little umbrella a little like ukulele that you can play sometimes yeah yeah all right rock star programmer fisherman programmer with our forces combined we will conquer all right let's answer our next question okay you want to read it um yes i do okay this one comes from an anonymous listener who says how do you feel about sharing salaries amongst your co-workers i'm about to have my yearly review and i get the sense that my raise which has already been promised to me will be underwhelming given how stingy the company has

been previously that is simply a hunch based on previous experience and the fact that our team budgets have tightened up recently a co-worker let it slip what his salary is and though i don't like playing the comparison game it made me feel underappreciated i discovered that he was making the same salary i was but for lower quality of work and less contributions to the team i've heard some developers and other companies advocate for sharing salaries amongst their peers but i'm not sure it's a good idea will sharing my salary and encouraging my co-workers to do the same allow for myself and my co-workers to better understand our value and help us negotiate rages raises or will it simply foster resentment and division you had a freudian slip there yes i

know i was just thinking will it get better or just more rages oh man it's okay it's a tricky balance i think sharing salaries will in the long run result in you making more money and in the short run it will result in you being less happy and because raises are usually not just given by you knowing that there's money out there right like they're usually there's some process and if you're earning an amount that you're earning unless the company has this guilt they're just waiting for you to find out that you're underpaid and and like ready to make it all up by paying you even even if you find out you are underpaid i don't think they'll just automatically give you a raise if you come and say hey i'm underpaid by this much please hand over more money even if you

can point out that a lower productivity employee is making more than you yeah i don't think that automatically would get you a raise do you i don't know i i mean if i were in the decision making seat and didn't have to consult with an HR department, it probably would get you a raise. Yeah, that's what I'm saying. There's a lot of machinery built into companies sometimes to make it so that it's not one person that needs to be convinced. It's like finance and budgets and approvals. And it's that thing where you're buying a used car and the salesman has to go back to their manager. So even if you're a really good negotiator, they don't just sell you a car for cheap. I guess maybe at a small company where there are fewer layers, then it's easier to just

say like here's the deal and then there's one decision maker and they're convinced but i think a likely result is you will find out that you do not make enough money or the other person will and then there won't be an immediate resolution so you can either work long term to resolve that through a promotion or the raise cycle or raise process which is sometimes works but sometimes does not or you'll just find out and know more for your next negotiation cycle and often the main time you negotiate is switching jobs right so i guess that's why i feel like it'll probably cause short-term unhappiness and longer term more money that is very insightful maybe you'd be better off asking your peers what they make at other companies i think maybe they would have less

resentfulness in the short term that way yeah i don't know it's it's tricky though because people should know their value and they should know what they're worth it's just it's weird that you could be making the same amount of money you made yesterday and suddenly be upset about it yes exactly nothing changed except your knowledge yeah and and if you've been underpaid for a long time that could cause some really bad feelings right like you have this wave of resentment where you've been taken advantage of for a long time right i mean you should know about that i guess but i don't know that knowing suddenly gives you the power to change it immediately it certainly gives you the power to change it longer term though i think there are probably cases where people have been

taken advantage of in that sense because they just didn't know what to ask for oh yeah that happens all the time yeah and and i've seen this where people have actually come to me when i was in a management position to offer salaries and the top end of the range they asked for was at the bottom end of the range that we were prepared to offer and what do you do you're like well it's like they've told me what their wildest dreams are and i can make that happen or i can and and it's like it's at the bottom end of our range but like in a company's shoes it's you're very hard pressed not to just give them what they ask for i think it takes a very special company to say we need to pay you what the market says because you don't have an understanding of what the market is that

happened at kawali a company i worked at a while ago there was a developer who came in and asked for some money in the interview process and my boss was like uh you'll get this much more actually because he he like super low-balled himself oh man like and as a percentage what are we talking about here i don't know the numbers i just know it was he negotiated himself down and then it was like a reverse negotiation yeah so i actually i don't know that was when it was much much smaller though like that was there were a handful of people at the company right right so i don't know if i don't know if that would persist through growth and so i i used to think that it was in every employee's best interest to know their their pay all their sorry all the employees pay

because it could only result in upward mobility for all salaries generally on average for the average salary and since companies never give pay cuts i mean as a rule generally they never give pay cuts not in tech not not in tech um not yet not yeah one day one day yeah you know it can only move up right so the employee always wins but then you have these situations where it's like i make two percent less than this person who i think i perform better than and is two percent really going to make a big difference in your life probably not yes there are people for whom it will but probably not so now all you have is resentment right and even if you got that two percent gap closed like is it really going to make a huge difference for you probably not just

thinking about this this is hard because i want the world to be fair i want people's pay to reflect the value they provide and also i want everyone to agree on everyone else's value yeah so like there's this global ordering of pay and value that align and that's not how it ever works nope and it's influenced by so much besides how good everyone agrees you are at your job and people's opinions differ too exactly like how are you ever gonna get yeah you could think that someone else does nothing and you deserve way more and they could think the opposite about you like i'm this is the way it should be because that joker doesn't do anything yeah but okay here's here's my opinion you should have enough data points from the broad market whether it's from the market that applies

to you whether it's from your company or for others to know what the market currently values productive software and engineering at that aligns with your experience slash value that you bring you should have that information you absolutely should now whether you get that from your co-workers for whom you have a lot of baggage and opinions and all this extra context that i think is a question that should be set aside but to actually benefit you you should know what the market is and i i don't think it matters if you know how much your co-workers make because like i said like all that's going to do is lead to this comparison game where you have resentment you you don't think it matters or you don't think you should i don't think you should

no get so okay there's so much nuance here and i'm sorry i'm not doing a good job if you're at a company where it is the culture not to disclose your salary you should probably opening that can of worms to learn everyone's salary is not going to benefit you that much instead your goal should be to understand the market because that's what you should be going after and if you can if you can get there through other data points i think you should because then you can get that data without the resentment that was long-winded i don't know does that make any sense it does make sense i just i just feel sad about the outcome because it it feels like i i can totally see the resentment it would bring but isn't some of the most relevant data data about your peers like

yeah you you know the most about their skills and output and and kind of relative importance in the companies. So that feels like it'd be a pretty powerful source of data too. It feels that way. But in my experience, the biggest raises I've been able to negotiate at companies have been from data points that I shared from other companies. Because at the end of the day, that's your leverage, right? When I go to my employer and I say, Bob over there doesn't do very much and makes more than me. I think that doesn't speak as strongly as Bob at this other company, which by the way, I'm interested in joining, makes more than me. Now you got leverage, but what are they going to do about a disparity among salaries within their own company? There's

no leverage there for you as a negotiator yeah there's also huh we need you need to spend some time in your fishing boat on this one i think yeah i do i do need to spend some time on my fishing boat so i i am not actually the contemplative programmer that just thinks zen thoughts all day i actually get stuck in rabbit holes comparing trade-offs forever and that's what i'm doing right now about this question too like it's just there's so many trade-offs and how do you value one above the other yeah because i i really do think i think about the times that i found out what co-workers made did i ever find out i found out what some co-workers made in one of my jobs and that was at a small startup and i actually i didn't use it

to say my co-worker makes this much please pay me this i but i did use it to ask for more money in like annual performance reviews and because it was wild west startup land and and we had funding and everything was good it went relatively smoothly then so i did directly benefit from knowing how much my coworker made. Wait, did I know they left? That's what it was. They were leaving. They told me how much they made. I found out it was more than I made and kind of like use that information. You knew that that number was within the boundary of reasonable pay. So you knew you could go for it. Yeah. But I didn't walk around knowing what my coworkers made. I don't think I've ever done that actually. Like knowing what several of my coworkers have made while we work

together. It's kind of been at, I've known a couple folks that I've worked with and I've, I've known more when I've left as well or someone else has been leaving. Yeah, me too. And since that's what I did, that's the right answer. I'm going to say. The fisherman has spoken. Yeah. Use it when you don't have to work with them anymore.

So you don't have to worry about the resentment. See, that's a good point. I really do think the resentment is a problem and you got to try to mitigate it. Yeah. So basically, if you work at a place that just churns through developers, yeah you'll have the most accurate information about salary yeah because because yeah the all the all the context around how much are you worth and what kind of work have you done it kind of goes away when when you're going somewhere else or they're going somewhere else and you can just

be open about it and then you'll be like huh well that was weird or whatever yeah all right well so that's my middle of the road recommendation you should just get all your co-workers to quit and on their way out ask them how much they were making yep that's it problem solved all right what can people do if they want their own problem solved go to soft skills.audio and click on ask a question feel free to share as much information as you want you can be anonymous or not thank you so much to all those who have asked questions we are sorry for those we can't get to but we promise to eventually before the universe dies it's heat death yep all right catch you next week