-4

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?

12
  • 25
    100's of thousands of lines of code... and you think they should start from scratch? I hope you don't voice that opinion. It makes you look naive, young, and childish, saying you want to waste that much of the companies time to rebuild something because you're too snobby about how the previously working / functional code was written rather than focusing on how to solve problems using the code that's there.
    – schizoid04
    Apr 23 at 2:33
  • 7
    @Slaknation Starting from scratch on anything that takes more than, say, a single sprint to code is one of those things you should never ever do
    – Kaz
    Apr 23 at 4:22
  • 16
    You seem to be mixing up a whole lot of different problems. That makes your question here tough to understand and may be part of the reason you're having difficulty communicating in the workplace. Your subject says that the problem is that your coworkers don't know git. When you describe the problem, however, it sounds like the problem is with the code that was checked in not with how the version control system is being used. So either your subject is misleading or your problem description is missing some crucial elements. Either way, your message gets muddled. Apr 23 at 4:24
  • 6
    Maybe the OP could split this into two questions? "My team members don't know git" and "I am filled with the existential despair of a new programmer facing an established codebase with legacy elements".
    – Adam Burke
    Apr 23 at 4:53
  • 2
    Where did you "post" the commit? Apr 23 at 10:23

5 Answers 5

11

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.

6
  • 3
    I upvoted for the first paragraph (which is spot on), but was tempted to downvote for the last paragraph. It seems a bit accusatory to me. Granted, the way they communicated the problems was obviously not effective, but it seems more like the OP could improve on their communication going forward than that they're not a team player. Apr 23 at 14:48
  • So what should I do now? Should I apologize?
    – Slaknation
    Apr 23 at 22:10
  • 1
    I think this one depends on team, and the way it was communicated, a bit. Different engineering cultures might value public discussion of issues more. It can accelerate fixes, for example. However, there's also a difference between "Looks like the issue was introduced as a side effect of commit xyz. <posts diff without userid>" ... and ... "Bob Drongo broke this, here's the proof" : )
    – Adam Burke
    Apr 24 at 3:16
  • @Slaknation depends on what you want to achieve. I would suggest saying sorry to those needing it, but it might be enough to do it in private over the water cooler Apr 24 at 14:42
  • @EJoshuaS-StandwithUkraine the wording was chosen to make it clear what is at stake here. Apparently I did not get it right. Apr 24 at 14:43
8

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.

1
  • Do you think I should apologize or just move on?
    – Slaknation
    Apr 24 at 3:04
6

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.

4
  • 3
    "Gradually over time, people learn and improve." Needs to be "Gradually over time, SOME people learn and improve."
    – Solar Mike
    Apr 23 at 8:34
  • Do you think I should apologize? Or just move on?
    – Slaknation
    Apr 24 at 3:04
  • I considered adding a qualifier like “some”, you’re right @SolarMike.
    – Dan Harper
    Apr 24 at 11:54
  • @Slaknation I would recommend just move on and treat it as a learning exercise.
    – Dan Harper
    Apr 24 at 11:54
3

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.

5
  • 1
    I disagree that identifying the commit necessarily points the finger. The commit will not only show the diff but also the reasoning behind it. In a well-functioning team (which OP's team apparently isn't), this will be invaluable in figuring out as a team how to fix it and how to avoid such mistakes in the future.
    – jcm
    Apr 23 at 23:50
  • Do you think I should apologize or move on?
    – Slaknation
    Apr 24 at 3:05
  • 2
    @jcm If you were the person who made the commit in question, it would be hard not to interpret this incident as being called out in public (even if that wasn't the OP's intent). Apr 24 at 14:51
  • @EJoshuaS-StandwithUkraine I've been that person many times, both in 'you broke the build!' and 'how did this happen and what can we learn?' situations. Team dynamics makes a huge difference.
    – jcm
    Apr 25 at 22:18
  • I would give a small apology. "I'm sorry, I didn't mean to call you out. Everybody makes mistakes." Apr 26 at 0:23
1

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)
3
  • Just so we're clear. I never pointed to how stupid the bug was or claimed people did not know what they were doing. I just simply pointed to what happened and where the code is wrong. Never not once mentioned anyone's name or assigned blame and did not accuse anyone of anything. I don't know where people are getting that idea from.
    – Slaknation
    Apr 24 at 13:51
  • @Slaknation I extrapolated from the question text, as that sounds accusatory, at least disillusioned. Obviously you might have communicated differently to the team. It might still be a different perception of communication or the team has a different evaluation of importance of the code/issue - or the relationship was already soured for other reasons and they're therefore less inclined to "listen to you". Apr 27 at 1:45
  • At least that would be my impression based on the information presented. In general, pointing out actual issues without blaming people is the right move. What others make out of it is out of your hands. You didn't ask how to resolve it, but you might want to feel out the team mood - either in a retro or a kitchen talk etc - do they view the code base as crappy too? Are they just trying to get their work hours done and take the paycheck? Have they still their heart in the project? Different moods allow for different conversation tones... (but perhaps a seprate question for help with that^^) Apr 27 at 1:45

You must log in to answer this question.

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