0

I work in a small, but established software company. I have been there over 2 years now and with time I noticed a growing frustration with one of my teammates and how he functions in the team.

To set the stage - the has been around for a while and is not a startup. It is small however - there is a total of about 20 people working here and about 10 engineering, all working remotely. We are divided into two teams based on the area of focus. The company has a nice tech culture and a decently modern tech stack, however only now is adopting some software practices like code reviews, build automation and pull requests.

The person in question and I are on the smaller team that consists of 4 engineers, manager and a PM. He joined the company about two years prior to me. We both have roughly same number of years of experience. My teammate is more of a specialist in one area. I am trying to specialize in the same area as him, but I come from a more generalist background. We had different career paths - him working as the specialist in the field, mostly through small companies and contracting, me working for large corporations most of my career.

At work he built a section of the code and is responsible for maintaining it and adding new features, however he is not the only who has to work with it and make changes there. This means his opinion in that area matters more (when asked about it the manager said he it not my boss, but I should count his vote twice).

As a result, the following situations happened over the last 2 years I was there:

  • When working on a complex feature that touches a lot of the code in his area and adjacent ones a number of issues came up. He said that some changes will be needed and he will do them. I reluctantly did not disagree, but said we may need to work on them together. Then the next week, when I was on holiday, he messaged everyone saying that the changes needed will be bigger and he is prototyping a solution - the solution was basically to do what I was planning to do after coming back. EDIT: To add context - the manager and the PM were okay with this plan and did not ask him to take over.
  • When going through a pull request process at least once he created a sub-branch where he made a code refactor then insisted to have it be merged into the pull-request branch and that the same refactor should be applied elsewhere which he leaves to me.
  • When assigning tasks, he insisted that a part of my large future task should be given to him because he has an idea how to do it.
  • In the early stage of the work on another large task he insisted that a different memory layout should be explored due to better cache access pattern. This took a week to do at the end of which it turned out we would have to rebuild half of the large system which he summed up by saying "It's early for that and we don't even know if it's a problem".
  • When working on yet another feature that was suppose to approximate the result I was collaborating with him. When we hit some issues and were discussing them he said he has an idea how to solve it, after which he started coding. Came back after few hours with a ready solution.
  • He used to push commits to other people branches during reviews as a way to include his comments. I have called him out on this and he seems to have stopped to do so.

There are a few more minor ones too.

I tried to be political about it and ask why things are like this and the answers I got:

  • He is just trying to help
  • He wants to make sure we don't have bad code creep
  • He wants to ensure code consistency
  • He wants to make sure the code is performant

Lastly, I want to mention that my code is in no way perfect, I make mistakes. I also tend to be open about my developer process, write a lot on Slack what is going on and ask questions.

At this point I am wondering:

  • Am I making all of this up?
  • Am I the problem?
  • If I am the problem - what should I do about it?
  • If I am not the problem - what should I do about that?
  • How can I bring this to management in a polite way?
  • Any other advice?
4
  • 10
    This is a long post, so maybe I missed it when reading through it, but I didn't really see what is causing your frustration. Your colleague seems like very proactive, doing more than his share of the work and I couldn't see any hint that his changes are causing problems.
    – Helena
    Feb 26 at 19:14
  • Yes. That is correct - he is proactive and does more than his share of the work. He is also very technically competent. What is causing my frustration is the lack of etiquette that is common is software teams - for example you don't just take over something someone is working on without that person or management buy-in. Feb 26 at 20:22
  • 3
    Etiquette differs from workplace to workplace. In my workplace what you describe is not really part of the etiquette, are you sure it is true for your place?
    – Helena
    Feb 26 at 21:27
  • Could be? Though this would be a first for me. Feb 26 at 21:50

2 Answers 2

17

Well I'm no software engineer so some of this went over my head, but from what i understand yes, you're the problem. It seems like you're finding offense in a lot of situations where none is intended or warranted. To address each of those situations directly:

  • He claimed ownership over those changes. You "did not disagree", ie you agreed, however reluctantly. He then made those changes while you were gone. Sounds like you get the win-win of your managers knowing you planned to do the same thing that was eventually implemented, without having to do the work. You agreed to let him make those changes so he wasn't stepping on any shoes by doing it. This is not a problem.
  • Don't understand enough of this one to comment on it.
  • He volunteered to help you with a large task because part of it would be easier for him to do. Sounds like a thoughtful gesture to me! If you pushed back and he insisted, well maybe you need to set some boundaries or be more firm in the future, but you might be the problem if you refused his help there.
  • Sounds like he wanted to be thorough and explore some options before you did a ton of work that would need to be changed later. Just because the result was inconclusive doesn't mean it was a bad idea.
  • This one's a little nuanced. Its hard to say if he was in the wrong without knowing the exact dynamic of how you were collaborating. That being said, a lot of programmers like to get in the zone and work through issues like this while blocking everything else out. At the end of the day he found a working solution within a few hours, so what's the problem?
  • Sounds like he was receptive to feedback and this is no longer an issue.

So to summarize, I find very little issue with any of the behavior you described. It sounds to me like this is a very competent coder who sometimes takes over responsibilities that you would like to have, and this is where your issue is. Not in what he's doing, but the fact that it means you don't get to do it. This is definitely not worth bringing to management. If you feel slighted because these are good learning opportunities that you're missing out on then talk to your coworker directly.

Hey so and so, I appreciate that you're a little more experienced in this area than me. I need to learn this stuff too, and sometimes when you take a problem I'm working on and find a solution on your own I feel like I'm missing out on valuable experience. In the future, can you try more to collaborate with me or include me during the process of finding a solution?

At the end of that day, you said he wrote this code base and therefore it seems like he just wants to be efficient because he knows he'll be able to work through stuff quicker. Stop assuming bad intent, understand that this is someone you can learn from, and I think you'll have a much better relationship.

0
10

I'm afraid you are indeed the problem.

"the solution was basically to do what I was planning to do after coming back" -- Welcome to the real world. Needs change, plans change, priorities change. You will work on what is most needed when you get back; your expectations are not anyone else's restrictions. Learn to surf the wave, being prepared to adjust at any time, rather than getting emotionally locked in to any one plan.

18
  • 6
    Doesn't matter. You don't own any of the code. Anyone on the team can submit fixes to any part of it. Plans are nice, but what matters is progress, not plan.
    – keshlam
    Feb 26 at 17:52
  • 2
    This isn't a class project. You aren't being graded on "your part" of the solution. You're being graded on how much, how well, and how willingly you contribute to the entire project. If someone is working on part A, collaborate with them or work on part B or C or whatever still needs to be done
    – keshlam
    Feb 26 at 19:41
  • 2
    @TheDeveloper, You're correct. I don't think this should be allowed if you're actively working on a feature. But if you're on vacation, then I don't think you can argue that you were actively working on that feature. Feb 26 at 20:54
  • 3
    In most places I've worked, anyone can grab any task that doesn't already have someone working on it and that is within their skills. IAnd if someone is out and has left something hanging that someone else needs, it is not considered rude to finish it for them; they still get credit for the work they did. TEAM, not solo developer. You never "own" a task, you've just said that you are working on it so others don't needlessly duplicate your effort, or so they collaborate.. If you aren't around go work on it an they need it done to finish their own task, they may do it, and that really is OK.
    – keshlam
    Feb 27 at 1:38
  • 4
    No except. They were there, it was easy, they did it. No problem except your unreasonable expectations that it would be left untouched until you got back. Invalidation of work does happen, for many reasons; learn to grumble for a minute, then shrug, put it behind you, remember that you did get paid for your time and good management will recognize it in your evaluation, and move on. If you want to be more certain you get credit, make sure you check in your branch on a regular basis so there's a record of what you did... and ideally so your effort can be picked up by the other guy. TEAM
    – keshlam
    Feb 27 at 15:12

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