8

I'm a senior developer at a new job. One rock star programmer on my team is considered senior. He has worked on the project for years. His code has unhelpful or misleading names. It has methods and classes with hidden behaviour and side-effects that cause severe issues (including data loss or data corruption) if not used in exactly the right complicated way, and it would take hours of digging to figure out what the right way is. It has a great deal of complexity that is not divided up in any way. No documentation or even comments.

The boss, project manager, product owner and testers see that he finishes tasks much more quickly than other teams members. They see that other team members frequently make changes that result in severe issues, and then only the rock star understands what went wrong and hops in to fix it and save the day. To the non-programmers, this looks like he is a great programmer. I assert that it is because he is the only one familiar with the unnecessary complexity and hidden pitfalls of his own code. The junior programmers notice that they are dependent on him for help, which they appear to believe means that he is much better than them. I don't think the junior programmers are aware that they could work more independently, more quickly and more accurately if they were working with a code base that was written with clarity in mind.

Other team members always approve the rock star's pull requests without comment, and nobody approves anyone else's pull request until the rock star has approved it. Any pull request with changes that improve clarity, even something like renaming cl_mode_1() to invoiceIsPrintable() is blocked by the rock star with a comment that the change is "pointless". If I reply and make a case for clarity, he does not respond. If I ask him personally if we could discuss it and hear me out, he says he doesn't feel like it. I have also suggested to the team that I could start writing documentation, but the rock star said that he hates documentation and the team immediately dropped the idea. Several times I have seen the rock star interrupt another colleague to tell them they are wrong, and every time that person immediately drops what they were saying and everyone appears to assume the rock star is correct.

I would like to make a case to all team members that we would all save a great deal of time, have fewer bugs and be less dependent on the rock star if we all focused on writing clearer code. At the absolute least, I would like to be allowed to write code for clarity myself when I do my tasks. I am afraid to press this, especially as a new person on the job, because it challenges the rock star who in my perspective is viewed as though he is infallible. How can I successfully advocate for a change that someone with so much clout is very resistant to?

13
  • Does this answer your question? How can I get co-workers to buy into some of my ideas?
    – gnat
    May 13 at 19:33
  • 3
    @GregoryCurrie I haven't made any pull requests with only cosmetic changes. I have renamed methods that I was making changes to in my assigned tasks. Also for new code, pull requests are blocked if expressions are named instead of literal and if they are divided up. If someone writes if (Invoice.IsPrintable) as new code, it is blocked until rewritten to if (obj.index == 0 && (f_mode > 3 || state[1] != null)). Both documentation and self-documenting code appears to be "forbidden" which is what I would like to advocate to change. May 13 at 20:19
  • 5
    +1 It's great to catch up on what my former coworker (mr. alleged rock star) is doing these days. May 13 at 20:53
  • 5
    @DanielR.Collins. I used to work with Mr. Rockstar too but we called him "WB" for "Wonder Boy". He left a trail of destruction in his wake. Unfortunately there is little that can be done but find another job or just tolerate his antics.
    – jwh20
    May 14 at 0:59
  • 1
    Does the rockstar have to approve all the commits, or why can he block readable code like "Invoice.IsPrintable"?
    – Helena
    May 14 at 12:39

5 Answers 5

7

Bring up your concerns directly with your manager in a non-accusatory tone.

From your question I am inferring a couple of things:

  • You were brought in as a senior, while the rockstar isn't. So at least on paper you are higher ranked.
  • You are bringing up your ideas mostly in the group where they are shut down by the rockstar
  • The perception of most people is that the rockstar adds a lot of value, while you are still an unknown to most people.

What I would suggest you to do not wait for group consensus but directly raise your concerns with your manager. It is unlikely that you can convince the rock star or the junior developers. The rock star has no incentive to change, and the juniors will just follow his lead (they have no reason to antagonize the rock star). But you are brought in as a senior for a reason and your job is it to drive change and in that capacity you should be able to get some one-on-one time with your manager. That way you are talking to an audience that has an incentive to change: While the rock star has nothing to gain from increasing the bus factor (quite the opposite), your manager does have a lot to gain.

When addressing issues with your manager you should make sure of four things:

  1. Don't antagonize the rock star directly. Instead try to bring up issues with the code or coding practices in a neutral and factual way that is not specific to one person. Focus on the impact it has on you and other developers. E.g. instead of saying "His code has unhelpful or misleading names." you can say "Many of the names in our code base are unhelpful and misleading, which makes it harder for new developers to onboard".

  2. Give concrete suggestions about what can be done. E.g. "If we divide our code the following way, we can reduce complexity and work better in parallel...". If you come with a concrete solution to your manager, it makes it really easy to help them, all they need to do is to say: "Make it so".

  3. Pick your battles. Even if you see a lot of things going wrong, don't bring them up all at the same time. Focus on the things that impact you the most and are easiest to change. Changing behaviour of a group takes time, and if you bring up too much stuff you will overwhelm the team and the manager. You might want to start with the least controversial item first, just to test the water and getting the team used to the idea that you are bringing in idea for changes.

  4. Relate the impact of your changes to concerns or problems that have been expressed by the relevant non-tech people in the team. E.g. if your product owner has mentioned a concern about development velocity, mention how a cleaner separation of concerns will help with velocity.

Your job is it to convince your manager to try some of your ideas, without making it about the rock star. Ask them to support you, in case of any resistance from the team (don't mention names). After you have commitment from your manager, you can go ahead and push your changes. If nobody wants to approve your commit, explain that this has been agreed on with your manager and if that doesn't help, escalate it.

If you have a reasonable manager, they will understand that they will need to support you if they want to make use of your seniority.

1
  • 2
    Can't agree with this more. This points to a cultural issue around how engineers are incentivized, as well as larger cultural issues around code review and technical debt. When an engineering organization is healthy, senior engineers are able to identify and propose solutions to these problems, and managers are tasked with making them happen. If a manager is unwilling or incapable of executing, it's a great sign that it's time to move on. The bottom line here is, this rockstar is thriving in a system that rewards them. It's up to management to change that, not the rockstar to be altruistic.
    – Eee
    May 15 at 17:55
5

It's unlikely that you're going to impact things.

Because you are hired as a senior developer, I assume you are experienced, and your voice may be more listened to compared to a junior.

You should approach your manager with your concerns. If you have other senior developers that feel the same way, they can also approach the manager.

A significant avenue is to discuss the concept of bus factor with your manager, and explain how having the one person be the gatekeeper to everything is to the determent to the company in the long run.

If the Rock Star's ego is sky high, maybe the best approach is to re-architecture the solution and have two teams. Partition off a segment of the solution that the Rock Star can own and control formally, and allow others to flex their muscle using what you could call better coding practices.

You are still going to get conflicts at API boundaries, but in such a situation, you can write adapter interfaces that hide the dodgy names and behaviours (which is rather common with legacy and disparate systems).

1
  • 2
    I think the bus factor is the argument to use if OP wants to affect actual change. OPs and rock stars joint manager should understand that it is desirable to be able to achieve things even if rock star is unavailable. If OP suggests how to make that happen, the manager might force rock star to go along with it.
    – quarague
    May 15 at 10:44
5

I would suggest to consider carefully what you're trying to achieve here, from your personal point of view. Your description seems familiar. In my opinion, a great programmer is able to write clear and concise code to solve difficult problems, not difficult to read code to solve standard problems - and most problems developers solve are (from my perspective, often not theirs) not that new and exciting.

The problem here is that the rest of the company has no good understanding of what is going on, so they trust the person they know has come through in the past and who seems to be very clever. This is a stereotype, which he is either accidentally (by not knowing better) or, more likely, consciously projecting. It's very beneficial for the rockstar on some level: He gets all the respect, with all the benefits that entails, he is the most important person, he's in charge of all the code etc. He's the one person the company cannot afford to lose now. By preventing the move to clearer code, he is protecting this status. Moving to cleaner code would potentially expose his weaknesses, he would have to adapt, and he would no longer be as important. TL/DR: He will most likely oppose you, and he's holding all the cards at the moment.

IMO, your options are:

  • change the rock star's mind. This is very unlikely to work: He will need to invest in personal growth, moving from rockstar to actual expert. In my personal experience, rockstars don't like doing serious work like that
  • change the mind of people about the rockstar, or his opinions: That's certainly possible, but also hard work. Keep in mind he will not help you, and he's currently the authority. So you'll have an uphill battle. Also keep in mind this will involve politics, so be prepared for that. Your best option would probably be to find someone in the company that has more authority than rockstar and convince that someone, to support you. Note there are very good arguments to support your position from the perspective of the company (bus factor, scale, hiring etc.)
  • put up with the situation. I don't think you'll enjoy that much, and I would caution you that judging from your question, I believe this is going to be frustrating for you
  • leave. This is the standard SO suggestion. However, it should be a serious consideration. Resolving this will likely be a long term commitment.
  • get job offers from elsewhere and while deliberating which one to choose, discuss the issue with someone up the management chain who would benefit from these changes. This keeps your options open to some degree, though I would caution that you should only do this once you are ready to leave if push comes to shove

If you think about it, who would benefit from you making that effort? The company very likely would for many reasons I won't go into here. If you handle the politics right, this may well result in reputation and achievements for you at that company. If you don't (or you get unlucky, and this just can't be made to happen at that company), you'll get nowhere and be frustrated.

The other programmers (you mention juniors) would also benefit. Good for them.

So I would suggest you evaluate your options, pick a path, follow that. Then re-evaluate regularly enough, and bail if you find your efforts are in vain.

I have experienced such a situation, "battled it out" and, in the end, found enough allies and of course real world evidence (there's a reason what the rockstar is doing is bad practice) to come through. I'm not sure I'd do it again, to be honest.

2

Ultimately, this situation is doomed because you don't have a development manager to set technical and architecture standards for the team. All the other managers you've mentioned in your post don't hold technical positions. The only criteria they really understand is "fast" and "works", but they can't relate to scalability and maintainability because it's not in their wheelhouse. For your rockstar, it makes a situation of job security because no one else can get anything done without going through him. At the same time, it creates a serious risk for the business to have only one person be able to independently maintain the code base.

You might share the paragraph above with your management. There will be a cost involved, of course, to get someone to oversee the developers as I've described. If the company doesn't want to invest, there's nothing you can do except tolerate the situation, or leave.

1

My worst case of a “rock star” developer was a guy who changed an “if (ptr != NULL)” to “if (!ptr)” because he liked it better that way. Software developers will notice the absolutely blatant bug. And he checked that in without any code review. And the bug caused problems in very rare cases, but was absolutely fatal (basically your PC would crash while booting). And because it was so rare, it was only found after some major component had been replaced.

Took me a week to find. I showed him the change he made, and said to him “Now think about it.” I hope the knowledge that one guy knew that he wasn’t a rockstar helped with his personal development.

Your “rock star” seems worse. Your choices: Stay there and never look into the mirror again. Find a new job and burn bridges or don’t burn bridges.

Or if you can afford it financially, talk to the manager. Use words like “stinking pile of horse manure” and tell the manager that this is the reason why other developers don’t deliver anywhere near their potential. It will make you feel better at least. Most likely you will then look for another job.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .