3 ms·

Just curious to know if you see the following trend: As a codebase matures, the amount of time spent of code maintenance increases and with bug fixes, it gets

Just curious to know if you see the following trend: As a codebase matures, the amount of time spent of code maintenance increases and with bug fixes, it gets harder to spot them and the amount of code that is required to solve them is little.

ruraljuror 2y ago
Yes. We have at least one team dedicated to identifying bugs and maintaining technical quality. For example they statistically analyze our CI runs to identify regressions. They find some subtle bugs that would be difficult to identify through one's own experience. https://lethain.com/managing-technical-quality/ https://lethain.com/managing-technical-quality/ discusses when it makes sense to build such a team.
- scarface_74 2y ago
  This is a team that no one interested in their career progression should ever be on. This is usually a dead end and almost impossible to spin in behavioral interviews.
  - ruraljuror 2y ago
    Well, not my experience at all and combining that with the link I posted, I suspect you are mistaking what I am referring to. What are you basing your statement on?
    - scarface_74 2y ago
      Let’s say I am interviewing two people with the same technical skills. One says that they have spent the last couple of years fixing bugs and analyzing the CI builds. The other talks about leading major new initiatives or being responsible for a major new feature and I dig into it. Guess which one I’m going to hire? In the terms of promo docs, which shows more “impact”, “scope” and “dealing with ambiguity”? https://www.levels.fyi/blog/swe-level-framework.html https://www.levels.fyi/blog/swe-level-framework.html
      - ruraljuror 2y ago
        It sounds like you would hire the one building CRUD apps. Perhaps I was unclear in my original post, technical quality teams don’t analyze CI and fix bugs. The team in my org builds sophisticated tools to analyze CI runs and teams self service the bug fixes. When you are operating at large scale and delivering products, there is no limit to impact or scope; ambiguity is inherent.
        scarface_74 2y ago
        That’s fair. Isn’t that more of a DevOps/SRE team then and a completely separate career track for most people than software development?

ruraljuror 2y ago

Yes. We have at least one team dedicated to identifying bugs and maintaining technical quality. For example they statistically analyze our CI runs to identify regressions. They find some subtle bugs that would be difficult to identify through one's own experience. https://lethain.com/managing-technical-quality/ https://lethain.com/managing-technical-quality/ discusses when it makes sense to build such a team.

scarface_74 2y ago
This is a team that no one interested in their career progression should ever be on. This is usually a dead end and almost impossible to spin in behavioral interviews.
- ruraljuror 2y ago
  Well, not my experience at all and combining that with the link I posted, I suspect you are mistaking what I am referring to. What are you basing your statement on?
  - scarface_74 2y ago
    Let’s say I am interviewing two people with the same technical skills. One says that they have spent the last couple of years fixing bugs and analyzing the CI builds. The other talks about leading major new initiatives or being responsible for a major new feature and I dig into it. Guess which one I’m going to hire? In the terms of promo docs, which shows more “impact”, “scope” and “dealing with ambiguity”? https://www.levels.fyi/blog/swe-level-framework.html https://www.levels.fyi/blog/swe-level-framework.html
    - ruraljuror 2y ago
      It sounds like you would hire the one building CRUD apps. Perhaps I was unclear in my original post, technical quality teams don’t analyze CI and fix bugs. The team in my org builds sophisticated tools to analyze CI runs and teams self service the bug fixes. When you are operating at large scale and delivering products, there is no limit to impact or scope; ambiguity is inherent.
      - scarface_74 2y ago
        That’s fair. Isn’t that more of a DevOps/SRE team then and a completely separate career track for most people than software development?