My coworkers don't know how to git and won't listen to me

Question

I have been working with software for about 8 years and git for almost 6 years. I feel like I know git like the back of my hand.

I started at a new company about a year ago and my coworkers don't seem to know git that well. Recently there is a build that just started failing and I investigated using git and found where everything went wrong and posted it.

It seems like nobody believes me since I am more new but I literally post the exact commits where things went wrong but still no one listens. I think some people are offended about their code being wrong instead of just trying to get things working right. Like I really don't care whose code is right or wrong I just want to show what happened.

Do you think I was in the wrong for informing everyone on where things went wrong?

The project I work in at my company is so outdated and code is just bad. Since it is literally hundreds of 1000s of lines of code, it would take forever to clean up. We really just need to start from scratch but I do not have the authority to make that decision and our superiors won't make this decision. Do you think I should find a new job working for a company that actually has it together with their code? Or should I just stick it out?

Answer 1

and found where everything went wrong and posted it.

This is where you instead of posting should have gone to the person responsible for breaking the build and telling him/her this in private, perhaps even with a suggested fix. (EDIT: this is what build servers are designed to - discover when the build breaks. If you don’t have one, it might be a good suggestion)

(EDIT: It is my impression that the rest of your team might think at this point that) You are not a team player. You might want to start with fixing that.

Answer 2

Knowing the correct answer doesn't do you any good unless you can communicate it to people in a way that they can receive it. Publicly telling people how wrong they are doesn't do that.

It doesn't matter that you don't care about assigning blame if people feel blamed. If people think that they're being blamed, the effect is exactly the same as if they actually were.

Delivering feedback to people (which this basically is) in a way that they'll be receptive to is not trivial; there are literally entire books written on how to give and receive feedback. I would encourage you to at least check out some articles on the subject, as it could help you deliver this kind of message more effectively in the future.

Also, the fact that you know Git well has no bearing on whether people believe you. Expertise doesn't do you any good unless you can translate that into actual personal credibility. Unless other people believe that you're an expert in Git, the fact that you actually are is almost entirely useless in a team context.

If there's a main point here, it's this: perception matters. In communication, it's the only thing that matters; if the recipient of your communication isn't "getting" what you're trying to say, the communication failed.

It sounds like you have good ideas, but would benefit from understanding how to communicate them to other people in the most effective way possible. There are quite a few good books and articles on how to deliver feedback effectively and "sell" ideas to people, which could help you a lot in your role.

Answer 3

Some overarching philosophies that you could consider adopting:

• You will never work on a codebase with "perfect" code. All code has an element of "bad" to it.
• Humans are imperfect, including yourself, and are a work in progress. Gradually over time, people learn and improve.
• All companies and code bases have varying levels of code quality.

Now, you have an opportunity. Your team mates will not be perfect, but you can work to support others and help them improve. Pointing out their flaws will not work out all that great. They'll probably dismiss you and think you're a jerk.

Another alternative is to accept that people can improve over time, and that you can help teach others over the long term. An engineer who can step into any team, in any condition and improve things is invaluable. If you could demonstrate a track record of this, then you will easily be able to demonstrate value in promotion discussions and future interviews.

As you get more senior, your performance is reflected less so on individual performance, but instead, how you can increase the performance of others around you.

If your team mates don't know git, run some workshops on how to use it. Don't find blame in others' mistakes, fix the bugs and improve things and don't worry if others recognise it or not. There will be some who don't want to learn, who don't want to take responsibility to improve. That's OK. Find the team mates who are keen to learn and teach them. Getting better in teaching and influencing will change the culture of the team and those that don't fit will move on.

Answer 4

Let me address the specific issue of giving feedback.

The important thing here is not to be pointing the finger or assigning blame. Identifying the specific commit does assign blame and point the finger. Instead you need to address the cause. So instead of starting by identifying the commit and the person who made it say something like:

What happened is that the code that retrieved the parameters was changed to use the "getParametersForDevice" instead of "getAllParameters". But "getParametersForDevice" returns a JSON structure instead of an array so the parameter isn't found. The fix is to change the search code on the return value to expect JSON.

Note that everything is about the code not the person. The passive voice is useful here "The code was changed" not "X changed the code". The person who made the change probably realises they did it, but you haven't made them look bad. If someone specifically asks you to identify the change do it. Offer to make the fix.

This problem has nothing to do with how well your colleagues understand Git.

Answer 5

While it is hard to tell exactly what is going on in the heads of your colleagues, if there is an issue, the issue likely is not what you did, but how you did it:

• If something that affect the whole team breaks and you figure out the reason / what exactly broke and how to fix it then it is absolutely the correct professional action to share that finding with everyone involved!
• That means pointing it out in a team channel/mail/message is totally fine and even warranted instead of speaking to individuals to help them save face, because you don't want to waste the time of all the other colleagues that are looking for a fix (that is assuming everyone is looking into this or should). In a healthy environment no one looses face anyway, as it is clear that a) everyone makes mistakes sometimes and b) the goal is to fix the issue not blame a scapegoat.

However

• The intention needs to be to solve the problem, not assign blame
• You don't point out how stupid the bug is and claim people did not know what they were doing - especially if the people who wrote it are still around, instead you point out how to fix the issue at hand
• you voice the problem as loud as necessary and, in particular, in line with how important it is for your team to solve the problem
  • That also means, if it is relatively unimportant then the right path might be to just create an issue/ticket with the relevant information and channel that into the regular bug-fixing pipeline

I speculate here, but judging from your question, I must assume that perhaps

• you sounded accusatory rather than genuinely interested in solving the problem and thus they feel like you attack them for no good reason (as they might have had reasons to build it like that back in the day, perhaps those reasons are gone, but a) you have no idea, b) throwing blame around won't help solve the issue and nobody likes a know-it-all-better-than-everyone)
• you might attribute a vastly different level of importance to the issue than your colleagues and thus they hear you but have better things to do at the moment
• you might have communicated unclearly and gone on a tangent (the question shows symptoms of this: you talk about git and how well you know it, implying the question is about git, when in the end it is about some code and you just were fast to find the right commit - likely - via git, but the actual topic is dealing with legacy code)