Hacker News Reader

Comment by seb1204 | Hacker News Reader

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

View on HN

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?

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.

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.

That sounds extremely accurate. I'm a little ashamed to admit that I've caved and started to play the game. I haven't been very productive for over half a year but my scores are off the shelf because I'm doing precisely what they've asked of me.

Actual example from my experience:

Trying to figure out the correct AD groups/permissions I needed to use an internal web app to schedule patching for some servers I managed.

After stepping through the app's js, I realized they were doing user group retrieval and validaton client-side (!!).

Wrote a quick POC that patched their check and gave me admin permissions, then sent it and a description over to a friend on the internal app security team.

Not my job, but apparently the service account backing that app had permissions to reschedule patches on any internal server. (including f.ex. domain controllers)

So probably something that it was worth having someone spend a couple hours figuring out and reporting, despite it not showing up in my OKRs.

Why?

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

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?

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.

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.

How do you prevent that from recursing infinitely?

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.

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...

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"?

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.

that makes sense. I hate Jira enough though I don't really like cluttering it.

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.

Reply on news.ycombinator.com