How to effectively work with teammates whose fixes to bugs cause more bugs? [closed]

Question

Everyone creates bugs, including me and my teammates. When bugs are pointed out to them, they're friendly and try to fix the bug. But their fix is 'wrong' and just creates a more subtle bug. Usually this takes the form of them thinking that the bug is an edge case, and they put some special check in.

Sometimes they will add an extra boolean parameter to something that gets passed around. Repeat this several times over and there's 5 booleans getting passed around.

The most irritating is when they put things in completely the wrong place because they don't know how to modify some generic thing to handle their use case. So they just avoid calling the generic code entirely and write lots of their own stuff.

This creates absolute spaghetti code, and they end up duplicating a lot of code to handle what they perceive as special cases.

I'm a junior developer, the same as them, and we have no-one experienced on our team. It's all juniors. To make matters significantly worse, everyone always just merges into master. Usually the reason I find bugs is that I look at a recent commit to master, and I can see in a few seconds that they've introduced a bug.

What can I do? Showing them the bug, pointing out their fix isn't right until they get it right under my guidance.

1. It feels patronising, I'm not really superior to my peers, all of us are new. Maybe I have picked things up faster than them and I know what they're doing is wrong.

2. Is time consuming

3. Sometimes they make such a mess that I feel like I have to tear it all down and do it better. Which obviously is delicate.

It makes me want to just fix the bug myself as soon as I see it, rather than report it to them. But I know this is wrong. Both because it's insulting and also because it makes more work for me.

Answer 1

Test your code

Have an actual regression testing, so that when a bug is introduced, the programmer finds it right away.

This doesn't mean that you should just write the actual tests. Instead, it means that you need to work on the culture of the team to understand that without regression testing, the project is doomed.

I wrote tests, my teammates then change the tests so that they pass while being incorrect, at one point someone actually disabled the tests.

This, clearly, is a sign that the culture is all wrong. It might be that the culture is wrong inside your team only, or it may be that it's wrong at the management level as well—for instance, someone may have disabled the tests because he was told to do so by the management, after complaining that he can't urgently deploy a bugfix to production because the tests are red.

In all cases, there is work to do to have a solid build pipeline, and to have a team where everybody understands that a change cannot be deployed to production without testing code for regressions.

Do code reviews

By doing systematic code reviews, you can eventually get rid of:

This creates absolute spaghetti code, and they end up duplicating a lot of code to handle what they perceive as special cases.

No code should go to production untested and unreviewed, when written by a junior programmer.

Don't hire junior programmers if you don't know how to work with them

Imagine that you're an owner of a hospital, and you decide to hire only interns. No doctors with twenty years of experience. Nothing like that. They are costly, after all, and any intern should be able to do exactly the same thing, right?

Junior programmers will build crap. Not because they are bad persons, but because:

• They don't have enough experience.
• They qualify themselves as programmers, i.e. they write code. This is not the most important part of the project, and a project which is composed of programmers only will fail.
• In order to improve, they need help from more experienced software engineers.

Your management decided that the project you are working on is not important for the company. They actually decided it, because they actually hired junior programmers to save money. What they didn't know is that not only the project will fail, but it will cost a lot of money, much more compared to if they hired a few experienced software engineers.

From there, you have to decide what to do. Either you can convince your management to stop being stupid. Or you can't. If you can't, you may either continue working on a doomed project, while trying to keep your head low (when the management will find that the project is failing, they will search for culprits, and if you take initiatives, you will be the culprit), or you ask to be moved to a project which is more important for the company.

Working with junior programmers requires skills and practice. If you have no persons with those skills, hiring junior programmers is as stupid as hiring only the interns in a hospital and hoping everything will be just fine.

Answer 2

Start by inviting people to pick apart your work.

You don't need management to create a command structure to fix this problem. You need teammates that trust you.

You build trust by showing you're not just some power hungry jerk that's looking to get out of work by spending all day approving other peoples work.

Get others to help you improve your work and you show people how to accept input from others. It makes them feel less threatened when they need to do it.

This is part of being a leader. It's not something management can bless you with. You either do this or you don't. You emerge as a leader when people are coming to you with their problems.

Doing this will not grant you authority. What you gain is influence. And influence is enough to fix every problem you've mentioned.

Answer 3

You have two problems. One is that your team allows merges without code review. That isn’t just unprofessional, that is utterly stupid. I don’t even do that for private use code that I create on my own. You need to call upon a team leader or management to enforce mandatory code reviews or decide as a team that that is what you want. I can tell you that if anyone votes against code reviews (developers or management) I wouldn’t allow them anywhere near my workplace.

The second problem is that your teammates don’t create good bug fixes. That should improve with time. Making them fix incorrect bug fixes is educational and improves quality of future fixes. It seems that creating a quick fix that doesn’t work doesn’t have any negative consequence for the developer, that is also a management problem.

There needs to be an understanding that the action for a bug report must not be to do enough work to fix the bug report, but the actual problem needs fixing. Good luck.

Answer 4

I disagree that this is purely a workforce matter. True, your workplace has issues, but there are a few things you can do that will start helping with the problem by addressing the way you handle code.

Do code review

It sounds like you aren't doing code review, and it does not matter at all what the excuses are, because code review will not only help people spot bugs before they go into code, everyone will also become more familiar with the code. If you do not have a system set up for code review, consider migrating your code to a Bitbucket or GitHub repo, and then require people to use those tools to create pull requests and review code. If you cannot use either of those for some reason (probably someone in management?), you should probably quit, because it's not going to get any better and you aren't going to learn any skills that will help you in your career. If your team is all juniors, I'm sorry, but you probably aren't working on anything important enough that a fear over "stolen code" or "service outages" would make any difference. Both Bitbucket and Github have incredibly cheap options for small teams (and you can have free private repos on Bitbucket at the time of this writing), so it would be foolish not to use them.

Add pre-merge hooks

Add pre-merge hooks to your code so that it can't get merged without a code review and approval. The services above have this capability, use it and enforce it. Not only can you ensure that everyone's code has been vetted, you can also add hooks that stop people from accidentally blowing away master by messing up their commit.

Write tests.

Nobody likes writing tests, but you are all juniors, so it's the blind leading the blind when it comes to code quality- anything helps. Tests can even be made requirements before merging, depending on your system.

Those three things are not open to debate (aside from which service you choose). Someone on the team may have their head in the clouds and may not think that you need those systems in place, that "we can do it without ", and whoever that person is, please have them go tell Google, Facebook, Microsoft or literally any other software company how their way of doing things will work in contrast to tried an true ways of doing things. Just because your company is small and inexperienced is no excuse not to use the tools that everyone else uses to maintain code quality. A simple Google search as to how those companies, or any big company, does source control will show you that they aren't being cavalier about it.

Static analysis.

No matter what your programming language, there is something out there that will help analyze your code and point out errors or enforce coding standards. That way it's not even a person pointing out the issue, so you can reject pull requests simply by saying "the machine complains."

As a final suggestion, one that almost no manager wants to hear, try pair programming. Fight for a few hours a week to begin with, where your team sits down with eachother and pair programs. If they argue that nobody does pair programming, Nordstrom's mobile teams pair program, and create a product that was responsible for about 1/3 of the company's revenue (at least, was in 2018)- that's over $100 million USD.

Oh, and if you aren't using Git or Mercurial for source control, why aren't you using git or mercurial for your source control?