7 ms·

Point 3 is very true. In my company at the time, they had a million rules and processes, but everybody had to drop everything because the son of an influential

Point 3 is very true. In my company at the time, they had a million rules and processes, but everybody had to drop everything because the son of an influential client could not get toy cars (!) into the new enterprise retail procurement system because of some incorrect logistical data. Normally you would get a ticket, analyze etc. But he was the loudest/most influential, so everything else was unimportant. No Jira, nothing, just one angry email. Fix it for him alone, NOW! Billion-dollar company, thousands of clients but a dude with 20 toy cars won. The issue was resolved (we removed the validation rules that were implemented before because "this is the filter for incorrect data, and we want to clear our data by restricting them") and everything went back to normal. Jiras, process and so on.

commandlinefan 4y ago
> everything else was unimportant, no Jira, nothing Well, until review time - then, "why didn't you make any progress on your Jira tickets?"
- klodolph 4y ago
  One of the reasons why I would just open a Jira ticket anyway, process be damned. If I’m suspending work on a P1 because of this ticket, I’m gonna mark this ticket at least a P1. If management wants me to complete it within X hours, then I can find the priority level that matches the X-hour turnaround time.
  - commandlinefan 4y ago
    I usually do. I once worked for one company that was so dysfunctional that they implemented a rule that made it impossible to open a ticket and assign it to yourself to prohibit that.
  - tharkun__ 4y ago
    I have found that many many developers are averse to tickets and complain about having to create tickets (like we see in a sibling of yours). I don't see why. It's really not that hard in most places to create one. Even in large and bureaucratic ones. I always found that tickets are protection. When you're being asked to "drop everything for X", my first thought is to create a ticket for my own protection. At the least I can track the fact that I had to spend N hours on this thing X and I can refer back to it. At best I can document the stupidity of the whole thing w/ the ticket contents. If you're in a place like my sibling where they ban creating a ticket yourself and assigning yourself: run. That's so stupid for so many reason that it's not even funny any longer
    - klodolph 4y ago
      Yes, agreed. I think many developers have a vague understanding of how companies work and how their role fits into the company at large. I know a lot of developers who want to focus only on solving technical problems, want to be given the freedom to make technical problems, and want to have the other problems solved by everyone else. If you’re focusing on technical problems, a ticketing system is a burden imposed on you by management. If your priority is the success of your entire team rather than the success of your own technical decisions, then you’d understand that visibility of your work, your thought process, how you justify decisions, is all critical knowledge that a ticketing system serves to record and disseminate. I can’t count the number of times where I found a reference to a bug in a piece of code like: // Release gadget early to avoid starving froopy pipeline, // see bug #12345. And the ticket turned out to be super damn enlightening. You get to go back in time and relive, vicariously, a debugging session from two years ago by a team member who left the team.
      - commandlinefan 4y ago
        > want to have the other problems solved by everyone else In other words, do their job and not do everybody else's job for them? Or conversely, get paid everybody else's salary since we're already doing all of their jobs?
        klodolph 4y ago
        Are you trying to make a point? Could you make the point directly, rather than make some vague, sarcastic comment? If I’m interpreting your comment correctly, there’s a lot wrong with what you’re saying. First, the “job” that computer programmers do is much more than just writing code and designing systems. Computer programmers are expected to prioritize work, advocate for work that they think is important, gather requirements from stakeholders, make decisions about who holds various responsibilities, document and communicate the process to team members, and disseminate knowledge about how systems work to others. Just for starters. Second, > Or conversely, get paid everybody else's salary since we're already doing all of their jobs? 1. Computer programmers are paid generously, at least where I live. One of the reasons we are paid generously is because computer programmers are very efficient at getting work done that may otherwise need many people. 2. It’s not somebody else’s job to follow you around and document what you’re doing and justify it. It never was. It was always your job. “Keep your head down and just do good work” is a kind of hyper-individualistic fantasy. It’s the fantasy where you’re some kind of powerhouse getting work done in your own world, and you do not need to advocate for what you feel is important. That’s what I’m arguing against. The technical part of our jobs is only one part of it, and you can’t make a good team out of several highly skilled programmers if they only have technical skills.
- makestuff 4y ago
  Then in your retro meeting the manager/TPM/etc. talks about how we need a better process which results in nothing changing apart from more tickets to create.
- twblalock 4y ago
  In those cases you open the ticket and assign it to yourself, "for tracking purposes."

commandlinefan 4y ago

> everything else was unimportant, no Jira, nothing Well, until review time - then, "why didn't you make any progress on your Jira tickets?"

klodolph 4y ago
One of the reasons why I would just open a Jira ticket anyway, process be damned. If I’m suspending work on a P1 because of this ticket, I’m gonna mark this ticket at least a P1. If management wants me to complete it within X hours, then I can find the priority level that matches the X-hour turnaround time.
- commandlinefan 4y ago
  I usually do. I once worked for one company that was so dysfunctional that they implemented a rule that made it impossible to open a ticket and assign it to yourself to prohibit that.
- tharkun__ 4y ago
  I have found that many many developers are averse to tickets and complain about having to create tickets (like we see in a sibling of yours). I don't see why. It's really not that hard in most places to create one. Even in large and bureaucratic ones. I always found that tickets are protection. When you're being asked to "drop everything for X", my first thought is to create a ticket for my own protection. At the least I can track the fact that I had to spend N hours on this thing X and I can refer back to it. At best I can document the stupidity of the whole thing w/ the ticket contents. If you're in a place like my sibling where they ban creating a ticket yourself and assigning yourself: run. That's so stupid for so many reason that it's not even funny any longer
  - klodolph 4y ago
    Yes, agreed. I think many developers have a vague understanding of how companies work and how their role fits into the company at large. I know a lot of developers who want to focus only on solving technical problems, want to be given the freedom to make technical problems, and want to have the other problems solved by everyone else. If you’re focusing on technical problems, a ticketing system is a burden imposed on you by management. If your priority is the success of your entire team rather than the success of your own technical decisions, then you’d understand that visibility of your work, your thought process, how you justify decisions, is all critical knowledge that a ticketing system serves to record and disseminate. I can’t count the number of times where I found a reference to a bug in a piece of code like: // Release gadget early to avoid starving froopy pipeline, // see bug #12345. And the ticket turned out to be super damn enlightening. You get to go back in time and relive, vicariously, a debugging session from two years ago by a team member who left the team.
    - commandlinefan 4y ago
      > want to have the other problems solved by everyone else In other words, do their job and not do everybody else's job for them? Or conversely, get paid everybody else's salary since we're already doing all of their jobs?
      - klodolph 4y ago
        Are you trying to make a point? Could you make the point directly, rather than make some vague, sarcastic comment? If I’m interpreting your comment correctly, there’s a lot wrong with what you’re saying. First, the “job” that computer programmers do is much more than just writing code and designing systems. Computer programmers are expected to prioritize work, advocate for work that they think is important, gather requirements from stakeholders, make decisions about who holds various responsibilities, document and communicate the process to team members, and disseminate knowledge about how systems work to others. Just for starters. Second, > Or conversely, get paid everybody else's salary since we're already doing all of their jobs? 1. Computer programmers are paid generously, at least where I live. One of the reasons we are paid generously is because computer programmers are very efficient at getting work done that may otherwise need many people. 2. It’s not somebody else’s job to follow you around and document what you’re doing and justify it. It never was. It was always your job. “Keep your head down and just do good work” is a kind of hyper-individualistic fantasy. It’s the fantasy where you’re some kind of powerhouse getting work done in your own world, and you do not need to advocate for what you feel is important. That’s what I’m arguing against. The technical part of our jobs is only one part of it, and you can’t make a good team out of several highly skilled programmers if they only have technical skills.
makestuff 4y ago
Then in your retro meeting the manager/TPM/etc. talks about how we need a better process which results in nothing changing apart from more tickets to create.
twblalock 4y ago
In those cases you open the ticket and assign it to yourself, "for tracking purposes."