This is more of a philosophical question.

I have recently started working on a new team and I see here a pressure on developers to fix bugs in their own code. Whenever a bug is found in a feature, the person who coded the feature is assigned that bug.

As a result, I see a lot of anti-patterns in the code and faulty assumptions that don’t get reworked: instead new code is built onto them. Many developers leave the code in such a state that no one really can understand it afterwards - which to me is the enduring effect of the “fix-your-own-bugs” approach. I guess if later the original coder is the one who fixes a bug, copying code 12 times isn’t really an issue: he/she presumably may remember those 12 places that need changes. But if it is someone new assigned to that code the they will not - resulting in new bugs.

I never before worked in an environment like this. I am used to working on both my own bugs and other people’s. I am used to leaving my code in a self-explanatory state and adding comments if it doesn’t seem clear enough. I am used to leaving my code in a state that someone else assigned to it after me can easily work on it.

So what are benefits of the “fix-your-own-bugs” approach other than the benefit of saving time in the short term ?

Am I wrong in considering this a bad practice in code production or is it really how this policy gets implemented within organizations that is the real problem here ?

Also, I'm not 100% sure what kind of tags I should add for this question. IMHO this issue impacts productivity and code quality directly, so I think those tags are pertinent. And this issue is definitely associated with development-process.

  • 24
    Generally you want developers to fix their own bugs so that they can learn from their mistakes and possibly reduce the number of times they repeat that mistake or take other counter measures. Otherwise people have a tendency to get reckless because they don't have to clean up their own messes. Commented Jul 19, 2023 at 22:30
  • 29
    You are really not asking "should programmers fix their own bugs" but rather "should only one programmer work on a particular program or chunk of code". I will say that one of the best, most professional development environments I was in had good, experienced programmers that each were responsible for a particular area of the system.
    – DaveG
    Commented Jul 20, 2023 at 3:58
  • 5
    @DaveG: "each were responsible for a particular area of the system" - does that mean "exclusively, without letting anyone else look into their code"? Without any code reviews?
    – Doc Brown
    Commented Jul 20, 2023 at 6:11
  • 5
    @SyedM.Sannan-onstrike: I would be more interested in what DaveG actually meant, not someone else thinks what they meant.
    – Doc Brown
    Commented Jul 20, 2023 at 11:03
  • 2
    @DocBrown Yes sir, I just commented on my understanding of it, and if my understanding is right, I don't see anything wrong with it. Commented Jul 20, 2023 at 15:12

11 Answers 11


This seems more a failure of your code review process than who is fixing the bugs. If the

anti-patterns in the code and faulty assumptions that don’t get reworked

aren't getting called out and corrected before the change is merged independent of whether this is a bug fix or the initial implementation, you have bigger problems than whether developers are fixing their own bugs or not.

  • 4
    I do agree there is an issue with code review; which I guess is something I am also working on changing consistently despite the constant pushback I am getting; however, I think that devs in this situation feel like they specialise and aren’t as concerned with modules they didn’t work on - and I think if they had to, that would make them more inclined to take responsibility for the whole codebase instead of that one part they consider theirs. I guess I am curious where does that idea of isolated responsibility comes from and whether this approach is also something that should be changed. Commented Jul 19, 2023 at 10:54
  • 7
    Sure. But again, that's a bigger issue of team ownership vs individual ownership - worry about that, not about the smaller issue of how bugs are assigned. Commented Jul 19, 2023 at 11:00
  • 9
    @Telastyn Do the math on costs. One bug costs probably 10-100 or more times what a single code review costs. So if a code review catches just one bug, it pays for itself at least 10 times over. Even the smallest bug that makes it to integration testing has costs measured in the tens of person-hours. If a bug reaches the customer, it's hundreds of hours. IME it's bad devs who don't want their code reviewed. Commented Jul 19, 2023 at 22:00
  • 8
    @AndrewHenle: this argument is flawed, since for finding bugs, tests are often more effective than code reviews. The real value of code reviews (with refactorings) is a different one: it helps to keep code understandable and simple, which makes it easier to apply further code changes for new or changed features in less time and without introducing too many new bugs in the first place.
    – Doc Brown
    Commented Jul 20, 2023 at 6:36
  • 6
    @Telastyn You have some pretty poor unit tests... Unit tests are always poor - they are written from the same assumptions and interpretation of requirements that the code they're testing is written from. Wrong assumptions or interpretations mean both wrong code and wrong tests. Unit tests themselves need review. Commented Jul 20, 2023 at 9:36

For recent bugs, I agree with the other answers. Most of those are sorted out in the pull request process and it's a matter of pride and familiarity to fix your own bugs.

However, there are scaling issues with longer-term bugs. The most experienced developers have touched the most code simply by virtue of being there the longest, so you need to transfer ownership to spread the work out. Likewise when someone leaves or joins the company.

Additionally, it often requires more skill to fix a bug than to create one, especially when you get into tricky areas like concurrency. Senior developers tend to get the trickiest bugs escalated to them, and in order to have time to tackle them, need to delegate some of the easier bugs.

If you maintain strict long-term ownership, senior developers end up overwhelmed by volume and junior developers end up overwhelmed by difficulty.

  • 9
    This is an important point. The context of 'fix your own bugs' in my mind is mostly within the scope of dev/testing. Once the code has been approved for production, the dev is somewhat off-the-hook with maybe some sort of 'probation' period caveats.
    – JimmyJames
    Commented Jul 19, 2023 at 20:49
  • 2
    "it often requires more skill to fix a bug than to create one" - so it's probably no good idea to add my extreme bug-creating skills to my resume ... Commented Jul 20, 2023 at 9:02
  • I personally enjoy fixing bugs and I hear I am not a very common animal in our developent tribe (seeing that many job postings state working on new features as a perk); but you touched on the issue that I have been tackling in the past and I am wary of in the future - expertise vacuum when someone leaves. But I have a question - what do you consider recent enough to delegate to dev that created the feature? Where would you estimate the cut off for it? Also, thank you for getting sucked into my deliberations :-) Commented Jul 20, 2023 at 19:26
  • 3
    @HagenvonEitzen you can always say what I do - "I do bugs" and leave the ambiguity to a listener - they can decide if I mean introducing them to codebase or fixing them. Commented Jul 20, 2023 at 19:27
  • 1
    I'd add that with regards to requiring more skill to fix a bug - it often also requires some form of a second set of eyes - similar to how writers may not notice an error they made in a book, but their editor will, simply by nature of being a fresh set of eyes and not being able to skim the text -, which solo developers often have to resort to Rubber Duck Debugging to catch their own mistake. They can do that, but often things go more smoothly if someone else takes a look at it. Commented Jul 24, 2023 at 4:37

First, to make this formally an answer, here are some possible reasons why the developer should fix their own code:

  • They wrote it, they understand it best, they need the least time to fix it.
  • They made a mistake, they should be punished for it. To make it explicit after some comments: this is written somewhat tongue-in-cheek, and I wouldn't agree with such a rule, but there are managers in the wild who might assign tasks according to such reasoning.

However, there are some negative aspects which should also be considered:

  • The bug may be caused by a fundamental misunderstanding, and the "fix" only patches the symptoms.
  • The original author may be unavailable (vacation, sickness, urgent work in another project, job change). Ever heard of "bus factor"? If only one person knows and understands the code, your bus factor is 1, which is something to avoid.

There's a quite different approach which should at least be considered, even if your organization isn't willing to adopt it dogmatically: Collective Code Ownership.

In an extreme interpretation, it demands that every developer should be able to pick up and work on code written by another, including when bugs need to be fixed. The extreme isn't always achievable, and that is often used as a straw man argument that collective code ownership can't work. There also is the hidden implication that developers are easily replaceable, which in reality they aren't.

However, if you consider a moderate version of collective code ownership, there may be some advantages:

  • Agree on a number of coding conventions, from formatting to use or avoidance of certain language idioms. This makes code often better readable to other team members, including new developers.
  • Do code reviews not only to find mistakes, but to understand what a piece of code does and gain shared knowledge.
  • When bugs are analyzed and fixed, pair programming (preferably including the original developer) can be helpful even if you don't do it for regular development, as two pairs of eyes often see more, and communication about the cause of a bug helps both people involved to get a better understanding.
  • 11
    "They make a mistake, they should be punished for it." -- Really? Commented Jul 19, 2023 at 12:45
  • 11
    Not my argument. But managers come up with weird reasons why the way they think work should be done is best. Commented Jul 19, 2023 at 12:46
  • 6
    @RobertHarvey -- Joel Spolsky: "On the Excel team we had a rule that whoever broke the build, as their 'punishment', was responsible for babysitting the builds until someone else broke it. This was a good incentive not to break the build..." joelonsoftware.com/2000/08/09/… Commented Jul 19, 2023 at 19:16
  • 4
    @RobertHarvey In my experience, getting support calls at 3AM is a really strong incentive to produce high-quality solutions and learn from your mistakes.
    – JimmyJames
    Commented Jul 19, 2023 at 20:53
  • 7
    I don't know where you work, but where I work, most managers would not say "They made a mistake, they should be punished for it.". Instead, they would say "They made a mistake, they should be given a chance to correct it by themselves and learn from it".
    – Doc Brown
    Commented Jul 20, 2023 at 9:13

You wrote

I see a lot of anti-patterns in the code and faulty assumptions that don’t get reworked

but I challenge your idea of that being caused by "developers fixing their own bugs".

When anti-patterns and faulty assumptions don't get reworked in your team now, the situation won't improve just by making devs fixing more of other developers bugs. Quite the opposite, when I have to work on code not written by myself, I suspect myself to lack some understanding of the surroundings, which the original author might have had. This can make me make even more hesitant to change more than the bare minimum necessary to close the bug ticket.

More generally, bug fixing is IMHO the wrong point in time to refactor (at least it should avoided to do both within the same commit). Removing anti-patterns and fixing "wrong assumptions" beyond the ones which were causing the bug should ideally be done at a separate point in time/commit. Better points in time are:

  • immediately after one added a feature, when code was extended and became less clear by this extension

  • before adding a feature, to make this task easier

  • before or after fixing a bug (but not at the same commit, and regardless of who was the author of that code section!) - especially when the bug fix isn't just fixing an obvious typo

  • during code reviews (as Philip Kendall already wrote)

So in short, who fixes whose bugs and code quality are usually unrelated issues.

Still, in your situation, I think the bug fixing process can become a starting point for improving the code quality and introducing more code reviews: try to convince the team to have each bug fix reviewed by a second pair of eyes. Bugs often come in clusters, and code sections affected by a bug are often worth a second look. Hence the focus for such a review should be on identifying related bugs and letting the reviewer make suggestions for code improvements which prevent to happen this kind of bug again. The original author of that code section - if available - can either be the one who fixes the bug or the one who reviews the fix.

That way, you can satisfy your team's idea of keeping the author of a certain code section informed as well as your idea of getting the code quality improved.

  • This. A bug fix should be reviewed by a peer. Without a validation process of some sort, what's the guarantee that the developer has made any serious effort to address the issue and didn’t come up with a quick and dirty fix instead? Trust, but verify.
    – Kate
    Commented Jul 23, 2023 at 14:42

In addition to Philip's answer I would like to add that it can be quite demotivating when you do not get to fix your own bugs. Maybe not when it's a really small thing like inadvertently writing == instead of != but certainly when the next person decides to go about it in a totally different manner.

Cooperating in the same code base requires respecting each other's work. If something is wrong or missing I would prefer a new issue being assigned to the same person allowing them to dot their i's and cross their t's. This respects their work and has them learn something so they will do better next time.

  • 3
    Why is it disheartening? Don’t you participate in code review together? If I make a mistake and someone else’s fixes it, I can still talk to them about their approach and review their code; I often communicate in two words things like that to my coworkers as well. No offence, but it all sounds like a big case of hurt feelings, while your code could have benefited from someone else taking a run at it. Commented Jul 19, 2023 at 10:44
  • 2
    @emperor: Why can't you have both? I personally like fixing my own bugs (as I have a sense of responsibility about the code I write), but why can't my bug fixes be informed by the code review process? Commented Jul 19, 2023 at 12:02
  • 2
    “A really small thing like writing == instead of !=“ - I am still angry about a supposedly senior developer changing “if (ptr != NULL)” to “if (!ptr)” because he was so smart. Creating a bug that was exceedingly rare, totally fatal for customers and impossible to reproduce. And he was too senior to do code reviews.
    – gnasher729
    Commented Jul 19, 2023 at 12:05
  • 1
    @gnasher729 I understand that but it is very different from what I wanted to illustrate. I was talking about an obvious mistake with an equally obvious fix that is addressed without messing with the creative work of the author. Commented Jul 19, 2023 at 12:10
  • 1
    @Falco in that case the original developper is also faulty, subtle corner cases should always be preceded by a comment with a big all caps "WARNING" and an explanation IMO
    – Kaddath
    Commented Jul 20, 2023 at 14:08

The question is stated as a yes/no question, but the real answer is "it depends". Sure, if there is a bug in code which I wrote last week and which got deployed this morning, I am probably the most suitable person to fix it, as the code is new enough that I'm the only person familiar with it.

But a bug in code written five years ago, and which only surfaces now because it now gets called in a way which triggers the bug? The original developer may not have looked at the code for years. Heck, the original developer may not be employed anymore. What are you then going to do with a policy of "developers fix their own code"?

What are you going to do with bugs which is caused by the interaction of five different systems, each with their own developers? It may take a long time to pinpoint the bug -- might as well fix that bug when you find it instead of tracking down the original developer and tell her what to fix.

If there is one thing I learned in 40+ years of coding, it is that there are no absolutes. There's no "one size fits all". "Developers fix their own bugs" isn't a policy that's always going to work. Neither is "Bugs get fixed by others".

  • 1
    Paragraph 2 is going off track near the end - the poster here is not implying they should tie their dev practice to the actual employment of the dev and otherwise render the code unmaintainable. Paragraph 3 is an argument pro unit and integration testing, and is mostly unrelated to the question at hand. I do agree with the overall spirit of this answer as captured by paragraphs 1 and 4.
    – Flater
    Commented Jul 20, 2023 at 5:31
  • @Flater You know, bugs do appear in codebases which employ unit and integration tests. The guideline "develop automated tests to the point that bugs are categorically impossible" isn't practical for most dev teams. Commented Jul 20, 2023 at 20:09
  • @neonblitzer: I never said anything to the contrary. I don't think you can get a test suite spot on from the get to. I do believe that by extending the test suite to account for forgotten test cases if and when a bug slips through, you can over time grow your test suite (and your developer experience) to be very resilient and better at not letting bugs slip through.
    – Flater
    Commented Jul 20, 2023 at 23:22
  • @Flater So we agree that automated testing doesn't prevent the situation outlined in paragraph 3. Thus, the paragraph is related to the question at hand – who owns a bug that happens at the intersection of five different systems? Commented Jul 21, 2023 at 14:39
  • @neonblitzer The world is decidedly less binary than your last comment is making it out to be. Automated tests will generally catch these issues, and they are a more efficient approach instead of only having a bug assignment policy. Integration collision is very much worthy of testing and (ideally) catching pre merging of the feature that breaks the integration. Of course there are going to be outliers, but the existence of an exception does not disprove the guideline in its entirety. Given paragraph 4, which I already said I agree with, I'm surprised that you've glossed over the nuance here
    – Flater
    Commented Jul 21, 2023 at 18:59

Yes, developers should fix bugs in their "own" code. But developers should also fix bugs in "others" code. I'm using quotes here to emphasize that most developers doesn't own the code they work on - the company does - and feelings of ownership are illusory and may be harmful.

Because in my opinion the core problem here is in the word "own". Having developers feel that they "own" code have advantages and disadvantages. The advantages are that it is clear who is responsible for maintaining some piece of code. That person may also have some freedom in how they want to structure the code as long as it works and as long as it adheres to established style guides. Whoever is responsible becomes a specialist and is is clear who should be able to answer other developers questions about the code.

But there are disadvantages too. Developers may shy away from fixing bugs in "others" code for fear of stepping on someone's toes. Perhaps they'll write a bug report instead, but this introduces bureaucracy if the fix is relatively simple. It can also reduce code quality if the developer who "owns" a module is weak and unable to maintain it properly. A stronger developer may notice that the bug fixes are just band-aids, but be unwilling to do anything about it since it's not "their" module. Ownership can also cause problems for the company if the only developer with deep knowledge of a module quits.

In my opinion, the disadvantages far outweighs the advantages. The whole development department/team/group should "own" and be collectively responsible for the codebase -- not individuals. It's better if everyone has broad, but shallow, knowledge of the codebase and thus are able to collaborate than if everyone is a specialist, but with no understanding of what others are doing.

Of course, collective responsibility is hard to achieve in practice and developers (in my experience) naturally takes on "ownership" of the code they produce. However, in my opinion, development processes should de-emphasize this tendency which means that developers should be encouraged to fix bugs in code written by colleagues.

  • Can't coders "express their ownership" of code managed by another coder via the code reviews process ? Then they may make suggestions for improvement to be implemented by the person responsible for managing that code. This way their obligation to the overall system is discharged without their recoding another team member's code.
    – Trunk
    Commented Jul 23, 2023 at 13:06

There is more nuance to this question (and answer) than the question title suggests.

Rogue devs

Your core complaint is that when there's not enough eyes on the code, one dev is able to go rogue without anyone being the wiser. I agree that this is a problematic situation and there should be general team consensus on the work that is being delivered, to ensure that one person does not write things "their" way.

However, having people fix other people's code from the get go is an inefficient way of doing so. A code review is a much better approach here.

You're putting too much on the second person there. Yes, by forcing them to fix the bug you innately force them to understand the code, and with a code review someone could claim to have reviewed the code and not actually have done so, but that's no longer a discussion on what developers should do, that's an issue with your employee's work ethic.


Let me put it differently. If others always fix someone's problems for them, then how are they ever supposed to learn that what they've been doing is incorrect? And even if they figure that out, what incentivizes them to not do so in the future, since they're not the ones having to clean it all up?

True ownership means you remain responsible for the decisions of your actions. You did it badly, you therefore have to now redo it. Obviously, this is assuming that the person is capable of the required fix - don't send a junior up sh*t creek without a paddle to implement senior level code.

Team ownership

That being said, team ownership also factors into this. If the original dev is otherwise indisposed and not easily available (whether absent from work or having other commitments that cannot wait), it's perfectly reasonable for someone to help get this feature across the line.

Similarly, there is a (not pedantically defined) statute of limitations on a single person's ownership over the work. If the buggy code has been part of the system for some amount of time, anyone can now look at it.
Developers should not carry code in perpetuity. They should carry it during the development stage and it gets inherited by the broader team at some point (this is contextual when it is appropriate to do so).


  • You're pointing at a valid problem but are using the wrong solution to try and fix it.
  • In order to get more eyes on the code and prevent rogue devs, institute a code review process.
  • If devs are rubberstamping the code reviews without proper reviewing, this either means that they're not trained on how to review code, or they have a problematic work ethic. In either case, it is not the review itself that is causing the issue.
  • Devs should exercise ownership over their work, and when they make mistakes, cleaning up their own mistakes is a great learning tool that should not be ignored.
  • Where reasonable, the team still owns the work and members should be willing to take on any of the team's tasks. If the bug has existed for some time, the dev is indisposed, or it requires an expertise that the dev does not have, of course it is sensible to involve another dev at that point.
  • 1
    Don't you think though that if responsibity for areas of code is so clearly isolated then code reviewer may be missing bigger context to conduct the review properly? Not by their lack of work ethic, but merely not knowing what they might be missing. I always say that the issue isn't someone's gap in knowledge, but their ignorance that the gap may exist. By not familiarizing themselves with the whole of the project and not feeling responsible for it, other team members may not know what gaps they have. Anyway, thank you for your answer :-) Commented Jul 20, 2023 at 18:21
  • @emperor-shallots Reviewers without context can confirm that the change is well documented. Maybe because it's self-explanatory, maybe because additional documentation was provided. If the intention is not clear and no further information on it exists, the reviewer can correctly flag that this is lacking and in need of a fix.
    – Flater
    Commented Jul 20, 2023 at 23:11
  • 1
    Perhaps a good policy is that one of the code's reviewers should fix the bug? That's a great opportunity to improve team ownership and understanding. Obviously, ask the original author for input when it's unclear (and use that information to improve the documentation - e.g. variable names or comments). This technique has worked well for me recently (both as author and as reviewer). Commented Jul 21, 2023 at 8:32
  • @Toby Noting that (1) real learning is only achieved by successful practice as opposed to passively receiving info on what is wrong and how to fix it and (2) the Pareto distribution of bugs amongst developers, surely your alternative policy can only lead to (A) most bugs being fixed by the more bug-free developers who eventually review and spot it; and (B) a much slower learning rate by the developers generating the most bugs ? How would you feel if you were a low bug dev but still paid the same as the high bug devs whose code fixes shakle your own productivity and salary ?
    – Trunk
    Commented Jul 22, 2023 at 16:27
  • @Trunk You've explained it better than I could, 100% agree with your points.
    – Flater
    Commented Jul 22, 2023 at 19:55

In addition to the good points made in the other answers, determining the relative productivity of developers is more difficult when they are not fixing their own bugs. I'm not saying it can't be done, but that it requires more rigorous tracking and analysis.

If you have every developer fixing their own bugs, the amount of (roughly equivalently sized) features that a sloppy developer can produce will be less than one who is writing code at a more optimal level of care and/or using better techniques.

That is, if a developer is trying to close out as many items as possible and bugs are distributed to the team as a whole, they can artificially increase their throughput by churning out defective code or in technical terms: 'crap'. There's an opposite issue where developers can be too worried about creating defects and become too careful. That's why it's important to focus on the throughput of working features to production and not the amount of (non-production) defects.

If you push the defects back to the developers, it creates a natural feedback loop and they can learn to optimize their productivity with limited additional information. If you don't do that, it means you need to track the defects and who created them over time and then communicate that back to the developers who are creating excessive defects. This is problematic for a few reasons but the biggest is that it may cause the developers to try to minimize defects to avoid being 'blamed' for them instead of optimizing for throughput. If this tracking isn't done, the management (lead etc.) can easily mistake their least productive developers as the most and vice-versa. The best developers will tend to become disgruntled by this situation and may quit.

The side benefit is that it's also much easier to see which developers are truly the most productive and reward/promote them accordingly. The thought of trying to track and attribute defects and then find the optimal rate seems pretty daunting and I'll assert that it probably requires some guess-work. It's also unlikely that most developers will know use that feedback to achieve the real goal (i.e.: working production features) directly.

If you have a situation where one developer is so bogged down by their bugs that they can't get out from under them, you may need to distribute those defects to other team members. However, this would be a clear indication that you have a developer who needs support and/or mentoring and (unfortunately) may not be able to perform their job adequately. Obviously, if you let someone go or they quit, the rest of the team will need to fix whatever defects they left unresolved.

NOTE: I need to make it clear that I am talking only about bugs found in during development and testing. Production defects are a failure of the team/process and attributing them to a single person is highly misguided and (somewhat paradoxically) tends to lead to more production defects. The question of how a defect got into production without detection is much more important than how it was created.

P.S. I think this is being misinterpreted. This is not about punishment. It's about feedback loops and letting developers 'manage themselves'. As an analogy, there's a condition that certain people have where they feel no pain. While initially, this might seem like a good thing, it's actually a really big problem. No one wants to suffer through the pain of being burned but these people can suffer from serious injuries where they (e.g.) place their hand on something very hot and have no idea they are getting 3rd-degree burns until they smell it or see smoke. Having your defects come back to you is like that immediate pain feedback most people have. You learn of the error you made much closer to when you made it. This allows you to correct and learn much more efficiently.

  • 3
    I find a focus on "individual productivity" to be harmful in a development team. It's much more useful to demonstrate what the team can achieve. Team members obviously have a perception of their peers' strengths and weaknesses, and what support and coaching each needs, but in my experience that's best kept internal to the team. Attempting to measure individuals promotes damaging competitive behaviours, notably an unwillingness to spend time helping others. Commented Jul 21, 2023 at 8:40
  • 1
    @TobySpeight That's basically my point. By not providing a direct feedback loop to the developer, it means that someone has to focus on this. I've been on and managed teams with developers who have negative productivity. That is, their main output is unnecessary work for other team members. I that isn't addressed, it will create bigger problems. It's much better for everyone to work with the developer directly and not get everyone else involved with their challenges.
    – JimmyJames
    Commented Jul 21, 2023 at 16:14
  • @Toby All well and good but the team member coached/mentored by a co-worker has to offer post hoc justification for the help offered. And surely the very least he/she can do is to implement in their own code the bug fixes or code improvements suggested in reviews. Anything less seems to me to be inadequate for team membership.
    – Trunk
    Commented Jul 23, 2023 at 12:52
  • 1
    @Trunk, in my team we don't allocate work like that to individuals, except for straightforward tasks that are already well-understood by the whole team. So when the bug is a simple omission, then the developer who introduced it is likely to say, "that's a simple fix - I'll add the relevant tests and code"; when it's more complex, I'd expect a couple of developers to look into it together and come up with a shared understanding of what needs to be done. We don't like to silo knowledge within individuals - that's why attempting to measure individual output are in conflict with our values. Commented Jul 27, 2023 at 7:11
  • 1
    We consider team productivity to be measurable; sprint retrospectives often look at how we can improve our communication, knowledge sharing and individual skill-sets to give higher velocity. We'll certainly do our best within the team to support engineers' personal development, and that often involves some coaching or pair development in their weaker areas (we all have some!). But no need to air our dirty laundry publicly - outsiders are only interested in the results they can expect from the team, and so we optimise for team productivity rather than that of individuals. Commented Jul 27, 2023 at 7:16

A bug is a deviation from wished, expected, or specified behavior or state. Bug fixing is implementing a new (wished/expected/specified) behavior or state. The only thing that the word “bug” adds is a negative attitude to the old behavior; however, technically, bug fixing is simply the process of implementing a requirement (for software at least, as actually removing insects from hardware is manual labor). So your question is simply whether the same developers should continue working on implementing a requirement concerning a piece of code they worked on before. Here are my answers:

  • For a good developer and good code: yes.

  • For a good developer and bad code: the developer has probably improved in the meantime, but still, determine first why the code was bad before taking any decision.

  • For a bad developer and good code: something went wrong in the meantime with the developer, so give the code to a good developer.

  • For a bad developer and bad code: give the requirements to a good developer and ask him/her to write the program anew.

(Naturally, it's sometimes hard to determine the quality of the developer and the code. In such cases without full information, it's hard to give a good piece of advice.)

  • 1
    I disagree with the answer because a "bug" is not defined as "what it used to do" (i.e. the old behavior), but rather "not doing what we had already asked it to do". In ITIL terms, a bug is an incident, not a change. If the old behavior was once correct, and now they want new behavior, that's a change and not an incident (and therefore not a bug either).
    – Flater
    Commented Jul 20, 2023 at 5:25
  • 2
    "So your question is simply whether the same developers should continue working on implementing a requirement concerning a piece of code they worked on before." I also disagree with this, to the point of expecting the actual opposite. A new change should be able to be handled by any dev. A bug should in principle be able to be handled by any dev but is better assigned to the dev who made the mistake as a point of learning - assuming said dev is reasonably available.
    – Flater
    Commented Jul 20, 2023 at 5:28
  • It's usually not the case that you have actually “asked it [the code] to do anything”. The vast majority of real code out there doesn't have any formal specification at all whatsoever. Not even an informal one, written in a natural language. Most of what you want from the code has not even been articulated. It's more that the a buggy code does something that surprises you (or that the state or some data turns out to be surprising), and you feel displeased. So most of the bugs out there are purely subjectively defined.
    – user432557
    Commented Jul 20, 2023 at 18:31
  • 1
    The manager attitude on display in the last comment is the main contributor to bad dev cultures that I have observed in my 10 years as a consultant who was brought in to fix projects that were in trouble. Developer turnover is already a managerial difficulty of life. Leaning into it by increasing the turnover (barring the exceptional circumstance, but you phrased your comment much broader than that) is the opposite of good management. "Meat on the pile" management inherently does not value long term business knowledge, nor does it focus on mentoring employees on their personal trajectory
    – Flater
    Commented Jul 20, 2023 at 23:14
  • 1
    I want to take a moment to point out very clearly that your comment talks about firing and replacing someone when they don't/can't learn by themselves. It further suggests that the concept of mentoring is just not present in this work environment. This is starting to explain why your advice originates based on a binary bad/good label and not one of nuance and growth.
    – Flater
    Commented Jul 20, 2023 at 23:18

I think that this question is really about the amount (if any) of help that you as a junior developer get from the testers on how to correct bugs identified by them. I trust that you appreciate that the essential sense of why bugs found by reviews of X's code (or indeed in the code allocated to X for maintenance) should be fixed by X: how else may X learn to write less buggy code ?

I say this as the phrasing of your question suggests an allocation of bugs to developers but no mention of how to write the bugged code better is passed on to the coder in your company. Just sending problems back to its coder without good feedback is useless.

A facet of many of the more recently established software companies is that junior developers are given little or no guidance. For the most part they are left to get to grips with the software system, the company's stated and unstated preferences in coding, the customer's needs and everything else all on their own. Some companies almost seem to intentionally create a Darwinian situation where it's every coder for him/herself and no help or mentoring is offered to new employees.

Maybe this is sometimes for saving money on software tester time/salaries - which cost much more than developer time/salaries. But maybe there is also a sort of predisposition among those ex-senior developers running such companies that disdains the human communication side of mentoring and training junior staff. Or disdains the concurrent need to listen to other perspectives from the junior staff - some perhaps a lot more potent than those applied in the company's existing code base.

But at any rate this no-guidance/DIY management is a fact of life within many software companies today and, despite the notable success that some tech companies implementing a better expertise <-> action/observation exchange process, this trend seems to be unchanging.

If I were you I would seek out a dev job in a company with a more positive approach to low-key mentoring of junior staff, even if this means working on a software product that is less "exciting" than others. That way you will learn your software engineering craft better. And, with the good example of senior devs/testers around you, you would also become a more inspiring developer yourself.

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