Live data from Hacker News

Most “mandatory requirements” in corporations are imaginary

nibblestew.blogspot.com

311–320 of 405 posts

Re: Most “mandatory requirements” in corporations are imaginary

#311

Playing devil’s advocate: Is it possible that, yes, of course you can work from home, and you must do that during lockdown, but is it as efficient as working in the office? I think that’s why many don’t like remote: They can’t see you working and they’re not as comfortable video-chatting. I’m a remote-only developer, but if I could, at any time, turn to my coworker and ask about something, I’d be more efficient.

>if I could, at any time, turn to my coworker and ask about something, I'd be more efficient

Haha, I remember when I was in the office before this all started, I had multiple coworkers who would do exactly that. I can't tell you how jarring it is to have headphones in and be in a focus state implementing something, just to have someone imagine they are able to trample on that time for their own efficiency and ask me questions. Doubly worse was they wouldn't even think thru their questions properly

Now, we're all remote, and I just hit back at their impromptu questions with "can you give me more context?" and half the time they solve it themselves. Imagine that

Re: Most “mandatory requirements” in corporations are imaginary

#312

Earlier quoted context omitted.

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

> I was faced with a password "security policy" that pretty much only whitelisted SHA2 + salting for password hashing. We were using a time-hard (not memory-hard though) password hashing function instead and several levels of auditors were effectively asking us to downgrade to comply with their policy without even understanding the difference. You can comply without downgrading by just applying the SHA2 hash after yo…

That's possible but it would mean unnecessarily changing security-critical code. I'd again have to make sure to use constant-time comparisons of the different output, migrate the existing data or require users to reset their passwords and so on. All to tick a box.

Ultimately we pretty much did that, switched to scrypt which is based on sha2 and pointed to the standard saying it's sha2-based. But that does not change the fact that the policy imposes incorrect requirements on teams. SHA2 is not appropriate for password hashing.

Re: Most “mandatory requirements” in corporations are imaginary

#313
post #211

Earlier quoted context omitted.

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 did almost exactly the same thing at my last job. I'm a game dev and they provided us all with woefully underpowered MacBooks that didn't even have a dedicated GPU. The game engine was constantly crashing while working and making it very difficult to get anything done. I recorded the amount of time wasted on these crashes over the course of a week. I then proved to management that there was about 5 hours a week bei…

> So after that we all got

laughed at and told to stay later and work weekends.

At far too many companies.

Re: Most “mandatory requirements” in corporations are imaginary

#314
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…

Side issue, but I have cause to mention Chesterton's Fence so often that it's become a real frustration that there is no Wikipedia article about it — only this essay about why Wikipedia contributors should honour it. I wish there was an actual article I could point to when I want people to know about it. (Why don't I just make one? I have basically given up on making substantial contributons to Wikipedia since the De…

Farnam Street has a good write-up: https://fs.blog/2020/03/chestertons-fence/

Re: Most “mandatory requirements” in corporations are imaginary

#315

Earlier quoted context omitted.

> 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) n…

Thinking about the policy in terms of punishments and fairness isn’t the right approach. Something happened that cost the company a great deal of resources, so the company is trying to prevent such a thing from happening again.

It may be doing a poor job at that, but it isn’t punishing you and it isn’t about fairness. It’s trying to prevent a future mistake. And because the company is a single entity, it is the company choosing to bear the cost.

It may make your job harder and they may not modify its expectations properly after imposing this cost on you, but that isn’t punishment or fairness. It is poorly thought out systems.

Re: Most “mandatory requirements” in corporations are imaginary

#316
post #15

Earlier quoted context omitted.

Even the best manager is faced with a bandwidth problem. It's impossible to collect accurately everything that the engineers are doing. And each layer of management is applying its own compression on what information they get from the levels below. What is frustrating when having the feet on the ground (or in the code), is that we clearly see the issues on our level. But conveying that in a understandable and nuanced…

A complementary phrasing is to apply the subsidiarity principle ("the principle that a central authority should have a subsidiary function, performing only those tasks which cannot be performed at a more local level" – OED) to companies, which would be the antithesis of micro-management. When your boss is an enabler first and a decision maker second, they are already following a variation of that principle. I wish th…

thanks. you just gave me the wording for a principle I was trying to verbalize.

Re: Most “mandatory requirements” in corporations are imaginary

#317
post #220

Earlier quoted context omitted.

And you end up creating far more security holes as people work around it. Shadow IT is great, it makes companies actually work rather than go bust.

Please tell this to my companies IT department. They've finally moved to Azure and Onedrive with it, but are still forbidding any files downloaded to devices or email attachments being send to external addresses because otherwise it's unsecure. So everyone is still using WeTransfer/Dropbox/whatever like they were in the years before.

We keep a low profile. Separate network, very limited interaction with "corporate IT" (which is outsourced). We keep infosec onside by making our liason feel we are across things. Allows us to sidestep a lot of problems, because ultimately in a large company people don't have to

Took me 15 years to realise that incompetence is at worst ignored, and often leads to promotions.

I've spent 3 years telling corporate IT they have a problem with a router config that limits throughput, we got 3mbit rather than 1Gbit. They spent 3 years insisting it wasn't them, and it was the upstream ISP. I even managed to get read only snmp access, and generated cacti graphs of their router showing 400M (iperf2 in udp mode, so 400kbit/ms) going in on port channel 1, but not emerging on the ISP interface.

My shadow-IT deparement spent 3 years paying for a completely separate network connection to bypass the corporate IT one and meet our requirements (easy to do when it's a remote branch office in another country), other departments just suffered it. It was the backup link so only used about 1 day in 10.

Eventually a senior member of (non-tech) staff resigned over the issue and it started being taken more seriously.

The way this system is designed (giving the front door to corporate IT) was done over my objections, and the objections of many others, but on paper it was good. Corporate IT provide shiny SLAs (which mean squat).

Last week, 12 months after the resignation and the beginning of taking it seriously, it had been escalated through 4 different layers of corporate IT, and eventually they came back and said "we've found an errant access list and removed it, and it's now fixed".

That's it. 3 years telling them what the problem was, 3 years of being ignored, and what happens? Certainly no blame for the idiots that made the decision to use this, no comeback on corporate IT provider, but if people find out about shadow IT they kick up a fuss (so the trick is to keep quiet and keep good personal relations with potential pain points).

Oh yes, we outsourced our corporate IT. Obviously there's no money coming back, I suspect we'll get a bill.

Re: Most “mandatory requirements” in corporations are imaginary

#318
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…

True, there is probably a reason for some stupid requirement, but that reason might still be stupid.

Remember that upper management is people, and as people they have their own biases, fallacies, ignorance, etc. They are just as prone to make wrong decisions as you are. In fact in an area of your expertise, they are indeed more prone to make a wrong decision out of simple ignorance or bias. If you think a requirement from your area of expertise is stupid, it probably is a stupid requirement. If you can’t see a reason for that requirement, there probably isn’t a good one.

The fact that the decision to make this stupid requirement comes from people in power gives you even more reason to question the validity of the requirement. People that hold high position and a great amount of power often face less scrutiny and questionable decisions made by them are far less criticized, then similar decisions made by people of less power.

Re: Most “mandatory requirements” in corporations are imaginary

#319
post #160

Earlier quoted context omitted.

Mandatory additional detailed info: Division by zero in floating point equals to Infinity because in a floating point data structure there is space to represent such a value. For integers, there is no such information and therefore an exception should be thrown. For a 32-bit float, the following are true: Positive infinity: 011111111(and then 23 zeroes) Negative infinity: 111111111(and then 23 zeroes) NaN: x11111111(…

Mathematically speaking though, infinity is not the correct answer to x/0 anyway. It's just a usefully incorrect result in a lot of situations.

That's true for a lot of IEEE-754. 1/0 is defined in it in a useful way. Just as 1/3 is defined in a useful way that is not equivalent to its mathematical property.

Re: Most “mandatory requirements” in corporations are imaginary

#320

Earlier quoted context omitted.

That many people willingly moved to OSX? Why? Was it a graphics company?

It was before WSL

Yes, while WSL2 has some filesystem quirks, it works pretty darn well for what I do (ruby development). I picked up a 5 Y/O 2 CPU E5 v4 Xeon workstation for 300 bucks. I've sunk in an additional 400 for an SSD, RAM and GPU, and when paired with Microsoft Remote Desktop, I've got a solid setup that allows the best of all worlds.
Post reply on HN