Live data from Hacker News

Most “mandatory requirements” in corporations are imaginary

nibblestew.blogspot.com

261–270 of 405 posts

Re: Most “mandatory requirements” in corporations are imaginary

#261

This is why managers need a high level of emotional intelligence, the ability to empathize and quickly place themselves in the position of others. Without those three qualities management is ill equipped to handle these kinds of things sensibly. Sadly the above traits are more deemed leadership qualities rather than management qualities and so often missing in management. Leadership skills are far harder to teach tha…

> Sadly the above traits are more deemed leadership qualities rather than management qualities and so often missing in management.

I just might be inexperienced in corp-land, but are management roles not leadership roles on a small scale?

Re: Most “mandatory requirements” in corporations are imaginary

#262

Earlier quoted context omitted.

Had you already told them your previous salary?

Yes, that happened a few years ago

Ah, so they wanted to verify that.

Fair enough if you already told them, but I'd make it clear they'd see the proof when the offer was otherwise certain.

Re: Most “mandatory requirements” in corporations are imaginary

#263
post #211
post #25

In BigCorps, if there's a stupid requirement, there's usually a reason for the stupid requirement to be there in the first place but getting to the reason might require un-peeling a few org layers to since the people enforcing the policy will not be the people who wrote the policy. A more productive use of time would be to understand the reason for the policy, document out why it doesn't apply to your case and then a…

About five years ago, a place I was working at was selecting a new laptop for all employees. Mine was up for replacement, so I was interested in what they were picking. They'd arrived at some god-awful Lenovo gamer model. It fit the performance and price point they'd decided they needed. I said I'd prefer to have something smaller with less Christmas lights. "Policy is everyone has to have the same laptop, and some p…

I had the opposite experience once: at my previous company we were all issued mid-tier ThinkPads. Completely out of the blue we all received an email saying we'd be given a set budget and would be able to choose any machine we wanted. We went from 100% Windows to about 80% OS X within a week. They ended up giving the old ThinkPads away. (I put Ubuntu on one and gave it to my mom.)

This was in 2012 or so, and because of that I was able to learn Objective-C and go on to work on the first version of our native app. It made me a stronger engineer, and allowed the company to have developers who were already familiar with the product and backend services work on native. It was win-win.

Re: Most “mandatory requirements” in corporations are imaginary

#264
post #218
post #105

Earlier quoted context omitted.

So the company I work for made the front page of HN last year for a security breach. I won't go into details, but I will say one factor was a particular instance where security was overlooked for many years due to convenience. In response, the company has now sort of swung the other way: lots of things that have a perfectly valid reason and are reasonably safe have been forbidden or suddenly have needed to be justifi…

Was it the Twitter internal account management tool?

Nope. :-)

Re: Most “mandatory requirements” in corporations are imaginary

#265
post #196

Earlier quoted context omitted.

> The issue is that all the policy documents often only contain the One True Way to achieve their goals, while the goals remain unstated. The documents should always come with a rationale. A reason can be argued against while a policy must just be followed. It's probably by design, because as soon as you put a reason that becomes a target and people start to get ideas about why it doesn't apply to them. Much like whe…

> It's probably by design, because as soon as you put a reason that becomes a target and people start to get ideas about why it doesn't apply to them. There's more to it than that. There are two separate groups of reasons: 1. The reasons a policy was put in place. ("Why did we do this?") 2. The reasons a policy succeeds. ("Why is this a good idea?") You can know the reasons in group 1. But nobody cares about those. W…

I was working in a throughout computing problem domain. About the time I got there, some asshole in HR had everyone’s (current and former employees) tax information on their work laptop and lost it. Tens of thousands of people, because there was no policy against putting such information on portable equipment.

And as far as I’m aware there still isn’t. No, within the year (might have been a lawsuit, I can’t recall) new policy became everyone’s machine has whole disk encryption. Including engineering. So my software was instantly 30% slower, and a half a day added to setting up any new machine. I don’t know how many times I had to explain that it’s not our code that got slower, the whole company got slower. It took me months of work to get us back to zero.

That person should have been run off and anyone in their dept caught doing the same should have been put on probation. I don’t know how you figure that it’s “fair” for everyone to suffer for the mistakes of one member. In a small team setting? Perhaps. But not for something like this.

Re: Most “mandatory requirements” in corporations are imaginary

#266
post #196

Earlier quoted context omitted.

> The issue is that all the policy documents often only contain the One True Way to achieve their goals, while the goals remain unstated. The documents should always come with a rationale. A reason can be argued against while a policy must just be followed. It's probably by design, because as soon as you put a reason that becomes a target and people start to get ideas about why it doesn't apply to them. Much like whe…

> It's probably by design, because as soon as you put a reason that becomes a target and people start to get ideas about why it doesn't apply to them. There's more to it than that. There are two separate groups of reasons: 1. The reasons a policy was put in place. ("Why did we do this?") 2. The reasons a policy succeeds. ("Why is this a good idea?") You can know the reasons in group 1. But nobody cares about those. W…

I’d add another that’s nice to have:

3. The outcome we expect. (“What will happen if this is working.”)

Re: Most “mandatory requirements” in corporations are imaginary

#267
post #217

Earlier quoted context omitted.

On the other hand, a reason can convince people, while a policy can be avoided, worked around or ignored while creating zero feelings of guilt.

> On the other hand, a reason can convince people, while a policy can be avoided, worked around or ignored while creating zero feelings of guilt. Though, I'd imagine that, in many cases, adding reasons would turn a policy pamphlet into a textbook. This seems like one of those areas where there are unavoidable tradeoffs: * clear, concise, and rigid policies are easy to communicate and enforce, but frustrate people wit…

It’s almost as if there is no single technique for reaching all members of a target audience...

You need two documents, minimum. One with rules, others to justify them.

Re: Most “mandatory requirements” in corporations are imaginary

#268
post #25

In BigCorps, if there's a stupid requirement, there's usually a reason for the stupid requirement to be there in the first place but getting to the reason might require un-peeling a few org layers to since the people enforcing the policy will not be the people who wrote the policy. A more productive use of time would be to understand the reason for the policy, document out why it doesn't apply to your case and then a…

> but getting to the reason might require un-peeling a few org layers to since the people enforcing the policy will not be the people who wrote the policy. The issue is that all the policy documents often only contain the One True Way to achieve their goals, while the goals remain unstated. The documents should always come with a rationale. And appending "exceptions may be granted for equivalent or better processes"…

There is also the concern of letting perfect be the enemy of good. For every developer that correctly integrates a better password storage scheme, there will be dozens that use something worse. Consistently standardizing on something that is good enough might be a net win and avoid the overhead and risk of verifying that other approaches are as good or better. Easier to evaluate/amend the policy periodically than to evaluate every single password storage instance.

This is a common issue in policies. If you try to accommodate every possible situation then the policy becomes incredibly complicated and difficult to understand let alone follow. If you have a simple policy that is easy to understand, there will inevitably be exceptions where the policy doesn't make sense.

Re: Most “mandatory requirements” in corporations are imaginary

#269
post #33

Earlier quoted context omitted.

I think the problem with this logic is it hinders a hundred people on a daily basis to prevent one person from doing something stupid once a year. That’s just not great ROI.

I've seen individual engineers make a mistake that caused 100 engineer's salary worth of damage.

The Knight Capital error really messed them up. https://www.reuters.com/article/us-knightcapital-results/kni...

Re: Most “mandatory requirements” in corporations are imaginary

#270
post #25

In BigCorps, if there's a stupid requirement, there's usually a reason for the stupid requirement to be there in the first place but getting to the reason might require un-peeling a few org layers to since the people enforcing the policy will not be the people who wrote the policy. A more productive use of time would be to understand the reason for the policy, document out why it doesn't apply to your case and then a…

> For instance, there's a restriction at my workplace (not a software company, a regular old industry fortune 500) which prevents git installs from pushing to any non corporate GitHub repo from our work machines. Oh my! As I have struggled with security incidents caused by people either accidentally publishing GitHub repos that are "public" rather than "private", or pushing corporate code to their own repos (that are…

I can report in on the container version of this. Docker would not accept patches from Red Hat about Docker Hub being the default push location. They wouldn't even accept to make this configurable. Our enterprise customers didn't even want it trying, regardless of if it was blocked at the network level.

Quay.io makes all pushes private by default, to protect from this type of behavior. If you accidentally typo, you are protected.

Post reply on HN