Hacker News Reader

Comment by macNchz | Hacker News Reader

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?

View on HN

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.

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.

Reply on news.ycombinator.com