42

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.

13
  • 15
    This isn't a software engineering problem, although it appears in the context of creating software. We don't know you or your colleagues, your company, your culture. How do you think we should come up with a solution to this workplace problem? If you don't have senior developer who can coach your colleagues, you may need to step in and provide guidance, possibly in the form of pair programming which is probably the least intrusive way to nudge them towards better solutions. Jun 13 '20 at 22:07
  • 5
    It seems to me to be an appropriate question of development method: how to handle developer peers of differing competence on a shared project.
    – Steve
    Jun 13 '20 at 22:57
  • 4
    This would be appropriate for workplace.stackexchange.com, if that helps. Jun 13 '20 at 23:52
  • 6
    I'm going to argue against closing this question because there are solutions to this issue that fall under the umbrella of self organizing teams. Jun 14 '20 at 0:03
  • 2
    @Jovash If you yourself are also a junior developer one thing I would consider is if you really want to work at a company where you don't have any opportunity to learn from experienced programmers. Sure you can learn about things like good development practices, devops and so on yourself too, but it really helps to have people who can mentor you and lead by example.
    – Voo
    Jun 15 '20 at 10:30
65

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.

11
  • 4
    Please let me clarify that I am also a junior programmer, it's all junior programmers on my team. Point 3. is perhaps good advice to my company as I do feel there is some mismanagement of us juniors. I did ask that we do code reviews, but people proceeded to merge straight into master anyway, and code reviews would only bring the errors to my eyes more immediately, not help in actually effectively resolving them. I wrote tests, my teammates then change the tests so that they pass while being incorrect, at one point someone actually disabled the tests.
    – Jovash
    Jun 13 '20 at 23:03
  • 3
    1. will not work. The code the people create does eventually work, but is unmaintainable. Jun 14 '20 at 7:20
  • 13
    @OliverMeyer: the three points in my answer are cumulative. It's not “You can do tests or code reviews,” but “You have to test your code and you have to do code reviews.” Jun 14 '20 at 7:53
  • 11
    "code reviews would only bring the errors to my eyes more immediately, not help in actually effectively resolving them." The thing about code reviews is that when they are in a system for code reviews, IE any of the big ones like Github or Bitbucket, you can reject the code. Then the person that broke it has to fix it before you allow them to merge it. If they merge it anyway, that's when you go to management. Even senior devs benefit from code review, why would a junior assume it's too good for them?
    – n_b
    Jun 14 '20 at 18:46
  • 1
    This suggests OP to ask management to close project and fire himself to stop losing money.
    – Basilevs
    Jun 15 '20 at 5:55
30

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.

13

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.

5

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?

2
  • Thank you for your response. To answer your somewhat implicit question re source control, we use git with bitbucket. I really like the idea of static analysis and pre merge hooks, things which help the person writing the code realise things are wrong rather than that them leaving it to someone else to realise would be a great help.
    – Jovash
    Jun 14 '20 at 19:33
  • 1
    Excellent! I'm glad you don't have to fight the battle for using git or bitbucket. Bitbucket has a primer on how to set up the hooks- confluence.atlassian.com/bitbucket/… If you all have admin access, then someone could disable these checks easily, though
    – n_b
    Jun 14 '20 at 19:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.