5 ms·

Stupid question but when digging into a potential security vulnerability, should that not be a ticket already that can get tracked?

p1esk 2y ago
Of course. Same as helping a colleague (unless it’s a few minute task). Whenever there’s something that I can spend my time on, it’s going to be converted into a ticket.
- jachee 2y ago
  How do you prevent that from recursing infinitely?
  - happymellon 2y ago
    If you are measuring tickets, then you can't. Your job is to create tickets to close them. If you generate productivity along side that, then thats a bonus.
  - djtango 2y ago
    Because we're humans, not robots and a human manager with human managees should be capable of working within a process without abusing the most obvious of edge cases. When building software you have to be precise to the nth degree but with human processes you can afford some degree of ambiguity and judgment...
- exe34 2y ago
  you create tickets for helping colleagues? I would understand "add this feature for me", but do you also have a ticket to "take x through this unfamiliar neighborhood of the codebase"?
  - ryandrake 2y ago
    I've seen tech companies that strongly encouraged that: Open a "task" or "process" ticket describing what you're doing, then do it, then close the ticket. Not all tickets are bugs and features. During review time, if you expended effort not described in a ticket, it's as if you never did it. When in doubt, open a ticket.
    - exe34 2y ago
      that makes sense. I hate Jira enough though I don't really like cluttering it.
    - Arrowmaster 2y ago
      I've worked at a tech company that explicitly avoided that. They refused to allow me to even open tickets for things not actively being worked on but were important enough they needed to be looked at in the next six months. The reasoning? Any internal ticket could be picked for review by the SOC2 auditor so all of our tickets must follow all procedures just like client tickets. It was more important to use templates, follow processes, and resolve tickets quickly than to allow us to use the tools to do our job efficiently.
madeofpalk 2y ago
Why? "Tickets" are a means to an end, but not the end itself. If it helps you, create a ticket. Otherwise don't.
- deleted 2y ago
  [deleted]
- 8n4vidtmkvmk 2y ago
  If there's no ticket, how will anyone know you did anything at all? How will submit your code change without a ticket # to satisfy the validator?
  - madeofpalk 2y ago
    Sarcasm is hard to detect online, but... usually I say I did something and colleagues believe me. If there's a code change, and I think creating a 'ticket' would be beneficial to provide more context, maybe I might create one, but usually I find it less faff to explain in the PR itself.
macNchz 2y ago
I read this something like: I’m working on a feature, I notice something curious in some adjacent code that could maaaybe let someone bypass the UserAuthorizationAdapter with a carefully crafted request, but I’m not familiar enough with that code to say for sure. It’ll take me at least half an hour to figure out whether it’s a complete misunderstanding on my part (I’m pretty sure it is…but it might not be…) or a real issue worth raising as a security ticket. Even just pinging someone about it will break my flow. It seems, however, that 100% of the decision making about whether I have a job next quarter and how big of a raise I might get is made based on three metrics on a productivity dashboard my boss is obsessed with. Should I take the time to learn more about the UserAuthorizationAdapter, or just assume it’s fine, finish my feature and move on to the next?
- 8n4vidtmkvmk 2y ago
  That hits too close to home. Except for us it's all about OKRs. You get one or two tasks for the quarter, and anything that isn't working towards that be damned. Which basically translates to launch your [AI] feature and fix nothing.
  - deprecative 2y ago
    Every single place that I've worked at that's introduced any sort of goal based metrics has immediately become, in real terms, unproductive and unsatisfying organizations. As soon as you have a metric, even self-defined, that you will be graded on you optimize for it as the ol' Law dictates. As soon as that happened support of existing services crumbles. Innovation tanks because risk means you might miss the target. It means the best engineers no longer mentor or build team based expertise. It means everyone becomes solos to hit their number or target and everything else falls away. I'm sympathetic toward the want to measure employee quality but by doing that you tend to only punish the underperforming engineers, regardless of reasons, rather than rewarding the best engineers or an increase in quality of engineering. It creates hostility when one person's metric may be impacted by another person or org within the company. It sabotages everything the powers that be claim to care about.
    - 2y ago
deleted 2y ago
[deleted]

p1esk 2y ago

Of course. Same as helping a colleague (unless it’s a few minute task). Whenever there’s something that I can spend my time on, it’s going to be converted into a ticket.

jachee 2y ago
How do you prevent that from recursing infinitely?
- happymellon 2y ago
  If you are measuring tickets, then you can't. Your job is to create tickets to close them. If you generate productivity along side that, then thats a bonus.
- djtango 2y ago
  Because we're humans, not robots and a human manager with human managees should be capable of working within a process without abusing the most obvious of edge cases. When building software you have to be precise to the nth degree but with human processes you can afford some degree of ambiguity and judgment...
exe34 2y ago
you create tickets for helping colleagues? I would understand "add this feature for me", but do you also have a ticket to "take x through this unfamiliar neighborhood of the codebase"?
- ryandrake 2y ago
  I've seen tech companies that strongly encouraged that: Open a "task" or "process" ticket describing what you're doing, then do it, then close the ticket. Not all tickets are bugs and features. During review time, if you expended effort not described in a ticket, it's as if you never did it. When in doubt, open a ticket.
  - exe34 2y ago
    that makes sense. I hate Jira enough though I don't really like cluttering it.
  - Arrowmaster 2y ago
    I've worked at a tech company that explicitly avoided that. They refused to allow me to even open tickets for things not actively being worked on but were important enough they needed to be looked at in the next six months. The reasoning? Any internal ticket could be picked for review by the SOC2 auditor so all of our tickets must follow all procedures just like client tickets. It was more important to use templates, follow processes, and resolve tickets quickly than to allow us to use the tools to do our job efficiently.

madeofpalk 2y ago

Why? "Tickets" are a means to an end, but not the end itself. If it helps you, create a ticket. Otherwise don't.

deleted 2y ago
[deleted]
8n4vidtmkvmk 2y ago
If there's no ticket, how will anyone know you did anything at all? How will submit your code change without a ticket # to satisfy the validator?
- madeofpalk 2y ago
  Sarcasm is hard to detect online, but... usually I say I did something and colleagues believe me. If there's a code change, and I think creating a 'ticket' would be beneficial to provide more context, maybe I might create one, but usually I find it less faff to explain in the PR itself.

macNchz 2y ago

I read this something like: I’m working on a feature, I notice something curious in some adjacent code that could maaaybe let someone bypass the UserAuthorizationAdapter with a carefully crafted request, but I’m not familiar enough with that code to say for sure. It’ll take me at least half an hour to figure out whether it’s a complete misunderstanding on my part (I’m pretty sure it is…but it might not be…) or a real issue worth raising as a security ticket. Even just pinging someone about it will break my flow. It seems, however, that 100% of the decision making about whether I have a job next quarter and how big of a raise I might get is made based on three metrics on a productivity dashboard my boss is obsessed with. Should I take the time to learn more about the UserAuthorizationAdapter, or just assume it’s fine, finish my feature and move on to the next?

8n4vidtmkvmk 2y ago
That hits too close to home. Except for us it's all about OKRs. You get one or two tasks for the quarter, and anything that isn't working towards that be damned. Which basically translates to launch your [AI] feature and fix nothing.
- deprecative 2y ago
  Every single place that I've worked at that's introduced any sort of goal based metrics has immediately become, in real terms, unproductive and unsatisfying organizations. As soon as you have a metric, even self-defined, that you will be graded on you optimize for it as the ol' Law dictates. As soon as that happened support of existing services crumbles. Innovation tanks because risk means you might miss the target. It means the best engineers no longer mentor or build team based expertise. It means everyone becomes solos to hit their number or target and everything else falls away. I'm sympathetic toward the want to measure employee quality but by doing that you tend to only punish the underperforming engineers, regardless of reasons, rather than rewarding the best engineers or an increase in quality of engineering. It creates hostility when one person's metric may be impacted by another person or org within the company. It sabotages everything the powers that be claim to care about.
  - 2y ago

deleted 2y ago

[deleted]