4 ms·

> Fixing a bug without filing a JIRA ticket is in itself progress. When I see comments like this I have to wonder if you've ever worked on a team with more th

> Fixing a bug without filing a JIRA ticket is in itself progress. When I see comments like this I have to wonder if you've ever worked on a team with more than one person on it. Without some kind of ticketing system—JIRA, Pivotal, heck Trello—How do you know a bug is getting worked on? How do you even know which bugs are a priority? Are the designs complete for the next feature I'm building? How does QA know to review your changes? (Yes QA is still a thing in some places and for good reason) When I was a solo dev, I would meet with the rest of the stakeholders weekly and establish what I was working on. But on a bigger team this quickly becomes impractical. Even with the 8 person team I work on now I'd have no idea who was working on what without having some kind of tracking system.

Closi 6y ago
I assume one of the use-cases for this is that they found a bug, quickly fixed and wrote a test case, and then pushed it to Git without raising a ticket themselves and then solving the ticket. With an 8 person team all sitting together, someone can just shout across the table and ask someone else to resolve an issue without raising a ticket too. Are you solving ticket A but need another person to help you with a bug you discovered in the API that the person across from you wrote and can fix in 2 mins? Sometimes they just do it and don't raise a ticket. If management likes to mark you on tickets, you might as well raise the ticket. I work at a big company, and every time the IT Helpdesk does a password reset they open a ticket, then mark it as closed, every time they do a password reset (because they get marked on how quickly they close tickets). Believe it or not, median resolution time for a raised support ticket is in seconds, despite it usually taking days if you open a ticket for anything yourself! 8 person teams are usually the recommended max team size anyway under Agile (two pizza team).
- ogre_codes 6y ago
  > someone can just shout across the table and ask someone else to resolve an issue without raising a ticket too. I rarely see my team-mates in person at the moment to shout at them. If I did, they would likely tell me to fuck off because they are busy with some other task. The only sort of issues where it's appropriate to drop what you are doing and immediately fix it are the most severe issues which need to be fixed right now. > I work at a big company, and every time the IT Helpdesk does a password reset they open a ticket, then mark it as closed, every time they do a password reset (because they get marked on how quickly they close tickets). In general, if documenting an issue (of any sort) is more work than resolving the issue, you shouldn't bother documenting it. But as a developer, many of those easy to fix issues are found by people who don't have the skills or resources to fix them. The best way for someone to communicate those problems is usually some kind of ticketing system.
  - Closi 6y ago
    > If I did, they would likely tell me to fuck off because they are busy with some other task. Great team dynamic if one of the members is blocked or has an issue because of something that another person wrote, and they get told to fuck off.
    - ogre_codes 6y ago
      So... "shouting across the room" for a ticket which is so trivial it doesn't need to be documented is OK, but telling someone to "fuck off" for doing it is not? Your priorities are backwards. I would not work at a place where interrupting me during coding to fix a trivial bug is considered acceptable.
      - Closi 6y ago
        Each to their own, I wouldn’t want to work at a place where we were just working on our own stuff and if you need something from someone you have to raise a jira ticket before you talk to them even though you are in the same room. The best teams I have worked with tend to be more collaborative.
        ogre_codes 6y ago
        There are a lot of ways to communicate to someone without interrupting them. If you are communicating about a bug in code, a ticketing system is a good one because it communicates that something needs to be done, the person you are communicating to can handle the issue when it's not interrupting their current work, and gives them an effective way to let you know it's complete. In most cases the issue in question will get handled quicker because usually multiple people can take care of the task and the one who has free time first can handle it. An atmosphere where interrupting people randomly is commonplace is almost never good for productivity. > The best teams I have worked with tend to be more collaborative. Collaborating doesn't require interrupting people in the middle of a task.
        6y ago

Closi 6y ago

I assume one of the use-cases for this is that they found a bug, quickly fixed and wrote a test case, and then pushed it to Git without raising a ticket themselves and then solving the ticket. With an 8 person team all sitting together, someone can just shout across the table and ask someone else to resolve an issue without raising a ticket too. Are you solving ticket A but need another person to help you with a bug you discovered in the API that the person across from you wrote and can fix in 2 mins? Sometimes they just do it and don't raise a ticket. If management likes to mark you on tickets, you might as well raise the ticket. I work at a big company, and every time the IT Helpdesk does a password reset they open a ticket, then mark it as closed, every time they do a password reset (because they get marked on how quickly they close tickets). Believe it or not, median resolution time for a raised support ticket is in seconds, despite it usually taking days if you open a ticket for anything yourself! 8 person teams are usually the recommended max team size anyway under Agile (two pizza team).

ogre_codes 6y ago
> someone can just shout across the table and ask someone else to resolve an issue without raising a ticket too. I rarely see my team-mates in person at the moment to shout at them. If I did, they would likely tell me to fuck off because they are busy with some other task. The only sort of issues where it's appropriate to drop what you are doing and immediately fix it are the most severe issues which need to be fixed right now. > I work at a big company, and every time the IT Helpdesk does a password reset they open a ticket, then mark it as closed, every time they do a password reset (because they get marked on how quickly they close tickets). In general, if documenting an issue (of any sort) is more work than resolving the issue, you shouldn't bother documenting it. But as a developer, many of those easy to fix issues are found by people who don't have the skills or resources to fix them. The best way for someone to communicate those problems is usually some kind of ticketing system.
- Closi 6y ago
  > If I did, they would likely tell me to fuck off because they are busy with some other task. Great team dynamic if one of the members is blocked or has an issue because of something that another person wrote, and they get told to fuck off.
  - ogre_codes 6y ago
    So... "shouting across the room" for a ticket which is so trivial it doesn't need to be documented is OK, but telling someone to "fuck off" for doing it is not? Your priorities are backwards. I would not work at a place where interrupting me during coding to fix a trivial bug is considered acceptable.
    - Closi 6y ago
      Each to their own, I wouldn’t want to work at a place where we were just working on our own stuff and if you need something from someone you have to raise a jira ticket before you talk to them even though you are in the same room. The best teams I have worked with tend to be more collaborative.
      - ogre_codes 6y ago
        There are a lot of ways to communicate to someone without interrupting them. If you are communicating about a bug in code, a ticketing system is a good one because it communicates that something needs to be done, the person you are communicating to can handle the issue when it's not interrupting their current work, and gives them an effective way to let you know it's complete. In most cases the issue in question will get handled quicker because usually multiple people can take care of the task and the one who has free time first can handle it. An atmosphere where interrupting people randomly is commonplace is almost never good for productivity. > The best teams I have worked with tend to be more collaborative. Collaborating doesn't require interrupting people in the middle of a task.
        6y ago