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.

The obvious reason it exists is to prevent people (a lot of who are analysts or data scientists - not professional programmers) from shooting themselves in the foot by pushing code to their personal repos in error.

It's annoying to work around if you need to say push a contribution to an open source project and you could rage at the infosec for enforcing it - but it obviously exists because stupid errors would have happened.

This principle is also called Chesterton's fence

https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...

I said I'd prefer to have something smaller with less Christmas lights.

"Policy is everyone has to have the same laptop, and some people need more graphics power than the one you're asking for."

Turns out there'd been some big thing back and forth already about size and performance and this was the compromise that nobody liked.

"But why does everyone have to have the same laptop?" I asked.

"Well, it's just policy. Every desk has a docking station, and we don't want to have to buy different ones."

So I flipped the selected monstrosity over to reveal the extremely lacking docking connector at the bottom. There were some awkward laughs and I got my Thinkpad.

https://en.wikipedia.org/wiki/The_Littlest_Hobo

https://en.wikipedia.org/wiki/The_A-Team

Like a professional user advocate paid to convince developers that the users do have a point and the request is not impossible.

It never is after you've done it once.

It's hard for people to scope an unknown task - especially dealing with bureaucracy. Is it going to be easy peasy, or will the rabbit hole just keep getting deeper.

Additionally, the ROI for an employee to investigate things like this is not very high, or could be negative. Imagine a poor H1B person - whose life and future depends on a company - trying to chase little things like this down. ("it's ok, I don't need " an ssd; an ergonomic chair; a 17" monitor is fine; etc...)

you're doing good work.

And yes, everybody should read it.

I then proved to management that there was about 5 hours a week being completely wasted for me waiting for my machine to open applications after they crash. So after that we all got new MacBooks that were properly spec'd out for game development. I got to pick the specs :)

You're making iOS games?

laughed at and told to stay later and work weekends.

At far too many companies.

There isn't enough pushback, unfortunately.

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.

Put me in front of a Linux desktop, and I can just start working.

Put me in front of a Windows desktop, give me 30 minutes to set up what I need, and I can start working.

Put me in front of a Mac, and come back to me still yelling at it five hours later.

I'm sure I could learn if it was worth the time to me, but I definitely wouldn't argue that it's superior (for me personally at least).

This confused me a lot as even though I wasn't even close to his level at that time I had no problems living with my Linux machines while my Mac laptop used to drive me crazy every day with some nonsense.

Turns out it is extremely individual. Maybe it is because I'm a keyboard person. When I work efficiently I feel I rarely touch the touchpad. I use fullscreen a lot, I sometimes use virtual desktops a lot etc.

I've always used i3/Sway/Pop!_Shell, or just dealt with windows subpar tiling. I'm picky about terminals as well, so that may have something to do with it. Although Mac's shell is nicer than windows (obviously), I can't stand the built in terminal app.

  |          22  <- linux
  |        22
  |  1111121111  <- macos
  | 1   22
  |1  22
  |122
  |000000000000  <- windows
  -------------

The only good news would be... if apple decides to "reverse course" questing for non-discerning-consumers, all the "crazy ones" will breathe a sigh of relief and buy a pile of new hardware.

I remember when apple gave up on its "apple-inward-looking" powerpc hardware and shipped intel machines. All of a sudden apple machines could run windows too, people could see more possibilities buying apple and the market for apple hardware became much larger very quickly.

Speaking as a web dev on a company-issued Mac, running my local dev environment inside a Parallels Linux VM. I asked to switch to Linux but was turned down.

(Now if Microsoft released LSW, i.e. an Ubuntu-based distro with Windows syscall support via a KVM-hosted NT kernel, I very well might opt for that instead.)

It's not all roses, there is a noticeable performance hit with the filesystem in both WSL and the windows layer. I wouldn't use it for production, and why would you, but for development, it's fine and largely not a problem. If you had to regularly deal with a large numbers of files, say log parsing or compiling, it's probably not going to work.

Besides recent OS X SSL library issues, I've haven't ever run in problems developing on a Mac and have used one for the better part of 10 years now. Can't say the same with developing on Linux (almost exclusively on the graphics side of things, but that's a problem when it's your primary machine).

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" to requirements would also help. 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.

It's terribly demotivating to have to argue with people enforcing policy they do not understand and erodes any willingness to engage with those policies instead of seeing them as theater and working around them.

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 when web companies disable your account and won't say exactly why. Not gonna take the risk you prove them wrong, are they?

It would be nice though if all laws had a purpose included.

In my Mega Tech corp, we have security team that has created hodge podge of conflicting policies. For example, they ask some applications to be internal network only and other are accessible via web. But they can never provide their reasoning and get annoyed when we ask any details.

The worst part is that some of their policies directly contradict with each other. For example, policy is to never run as root inside docker container but then there are some applications provided by them that runs as root in docker. And every time you use it, you have to remind them that these are their apps or else they will ask you to stop running it as root.

Finally, I had pleasure of talking with one of their Security and Compliance expert. They could not even knew how to list file perms in Linux, and other a lot of basic ideas. This person clearly had memorized interview questions but had clearly no understanding of those concepts.

Only way to hide their incompetence is act elite and don't explain their reasoning.

The fact that policy sponsors are more than anything looking to a single answer to end debate and establish uniformity is why policy writers can copy and paste stuff from the web and get it adopted as policy without a clear rationale connected to the organization’s particular circumstances. They aren't conflicting, alternative explanations.

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. What matters are the group 2 reasons, and they were probably never known in the first place.

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.

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.

Full disk encryption is a fair response because it won't be feasible to enumerate every type of situation that results in sensitive data being put on the laptop (such as temporary files or source code). If someone was going to just add tax numbers to a list it leaves a lot out; if they say "sensitive data" it leaves a lot open to interpretation; if they list everything they can think of it'll be impossible to properly comply while still getting work done.

So perhaps it was a heavy handed approach handed down mindlessly, but it could also have been someone looking at the bigger picture. Knowing the intent as others said would help.

Mandating full disk encryption is easy for IT to enforce. A policy of not putting sensitive information on laptops is valuable, but difficult to enforce. Encryption is a sound way to reduce the risk of harm when that policy is inevitably broken.

Full disk encryption also been the company-wide policy of everywhere I've worked in recent memory, fwiw.

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

A policy's expected outcome is correlated with why a policy was put in place.

As an examnple: If an HN disclosure leaks passwords and email addresses into the public domain, imposing a policy control is _meant_ to have the effect that such a disclosure would not happen again, or if it does to have a limited scope.

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 with better ideas.

* clear, concise, and flexible polices invite a lot of noise from people who think they know more than they do (e.g. can I use my own custom password hash I invented? It has more bits so it must be more secure.). Enforcement is also harder, since now you have to track exceptions.

* policy reasoning is harder to communicate, may never get read, and may actually discourage reading the policy.

Very often part of the purpose of the policy is to end debate about how to handle an issue, and to get the “crackpots and geniuses” to STFU.

That's not a motivation that policy sponsors usually want in print, though.

That's still a significant trade-off: putting together a book with the reasoning would be a lot more expensive than just creating the pamphlet. Your organization might not be able to afford the cost, period, or your boss may not agree to spend all that money just to make a minority of engineers happy in a few narrow cases. Then there's the question of how many people would actually consult the book of rationales; maybe it'd only be a handful.

I'm guessing most organizations tend to pursue a "minimum viable policy" tradeoff: spend as little effort as possible to create a policy that addresses a particular set of high-priority problems (since that is easily justifiable), and ignore more theoretical concerns like worker education and the personality preferences of certain kinds of individuals.

>Then there's the question of how many people would actually consult the book of rationales; maybe it'd only be a handful.

Well, it's supposed to only be a handful: the handful of people who know more than the policymaker.

Policies very often have official reasons for just this propaganda purpose, but it's worth noting that the reasons cited for the purpose of motivating compliance are often chosen for the specific purpose of how well they are anticipated to motivate compliance and not how well they reflect the actual reasons the policy is adopted, and thus they often are not in practice a good tool for understanding how to challenge the policy effectively.

I used to think this was a rebellious streak but perhaps it's just from that desire to know how things work. Absent a reason, I'll find my own.

A lot of people don't care either way, rules make life simple so there's no need to complicate it further.

And if you talk to people directing policy efforts (who are often not the ones writing, or even actively choosing, policy but generally are the ones formally signing off), you often don't have to dig very far to find that settling discussions is as important of a rationale for the policy as any of the others. This obviously conflicts with ideals like continuous improvement, but it's true lots of places including those with nominal commitments to continuous improvement.

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.

The auditors' policy? Are you sure? An auditor's job is to check if you're doing what you say you should be doing. If you're arguing with an auditor then you're essentially arguing with your own organisation without any hope winning the argument.

An auditor's job is often to check if you're doing what an external standard says you should be doing (SOC 2 => AICPA trust principles; FedRAMP => NIST 800-53, etc.).

Unfortunately, these external standards may be written vaguely and while you may have policies that define X as Y, the auditor doesn't have to accept your answers. For example, when PCI requirement 5 says "Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).", your policy may say "antivirus is not required inside containers that run on platforms like GKE, as these are not commonly affected by malicious software." It's very likely you'll have a discussion about your interpretation of that requirement.

I don't mean to just single out CIS as bad, but recently I learned that Ubuntu CIS docker images contain Aida, cron, and sysctl configuration. Yes, you pay for that. I'll be making fun of that for a long time.

Are they hiring?

You dont have to claim that you follow some standard that actually makes you less secure, you are just not going to be able to sell to clients who are also sheep in this manner (read: everyone.)

In essence, the auditors are there to evaluate whether certain assertions are true. E.g. the company is asserting that they are doing X because they have a policy that X must be done. If it turns out that the internal communication within the company is screwed up and some teams are following the policy and some are not, then the claim is false and the core job of the auditors is to detect and note this. Detecting such discrepancies the main reason for why such an audit (often external,, and if internal, then mostly independent, not reporting to the audited departments) is requested. It's not their job to fix this or decide who's in the wrong - the initial claims are found to be false, and that's not okay no matter if the policy should be changed or will be changed. It does not matter how (and if) the company negotiates changes to the policy, it does not excuse the misleading claims of "X is being done" if actually the company is doing Y instead of following the stated policy. When the management has fixed this (or claims to have fixed this) one way or another, then the auditors should re-evaluate whether the claims are true now.

I’m not going to tell you how to accomplish the goal, but I’m going to tell you what we are trying to do and the manner in which we want to get there.

You can comply without downgrading by just applying the SHA2 hash after your time-hard hash.

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.

Why? What would this mean? You have a flow like this:

1. User sends "password".

2. Time-hard hash processes "password" into some hex value, HASHT. No comparison is done.

3. SHA2 processes HASHT into some other hex value, SHAHASH. You compare SHAHASH to the user's stored hashed password.

But even in step 3, you don't need constant-time comparisons. What purpose would they serve?

Assume the attacker knows your full hashing algorithm -- they can compute SHAHASH for any input password. (Maybe your salt is equal to the username, say.) That's enough to use a standard timing attack against early-abort comparison to learn the first byte (or other comparison unit) of SHAHASH.

But to learn the second byte, you need to provide a large number of hashes which all have the correct first byte. This can't be done. (It can, but you'll have to generate around 256 times as many hashes as you can use.) To learn the third byte, you need to provide a large number of hashes which all have the correct first two bytes. This is even more impossible. (In fact, you may recognize this problem as being the proof-of-work that Bitcoin requires.) The whole point of using a cryptographic hash in the first place is that we can't predict the outcome of a hash! Constant-time comparisons are something you need when you're comparing an attacker-controlled value to a secret value, but that never occurs here.

ISO 26262 includes the requirement to prevent “implausible values, execution errors, division by zero, and errors in data flow and control flow” (8.4.4). I'm confident the division by zero aims at integer division because the result is undefined. For floating point, division-by-zero is perfectly fine and well defined by IEEE 754.

Nevertheless, our safety folks require us to enable the traps and shut down the device in case a floating division by zero occurs. This is stupid because a division by a very small number has the same effect as division by zero. However, since it is explicitly mentioned in ISO 26262 nobody has the balls to allow it officially.

I don't even want to estimate how many man-months have been burned to fix such "defects".

I would argue that dividing by very tiny numbers is also something that you should probably be catching, since the output very large numbers are likely not going to do what you’re expecting...

There are some cool videos of wrist flips online, and I’ve heard of a pickup truck being thrown by an articulated arm on a factory floor due to it.

Sounds worth the precaution, given the right context!

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(and then anything except all zeroes)
    ... x being either 0 or 1.

So, below, the first one is defined, while the second one isn’t.

    lim_{x->0+} 1/x == +Infinity
    1/0 != (anything)

So in general, assuming anything like \infty for a division by zero is wrong wrong wrong.

     lim_{x->1+} (x^2-1)/(x-1) == 2

More formally, if you have a potential division by zero and get an Inf (or NaN in case it's 0/0), you have to show what impact this will have. Can it result in a safety violation? If yes, what ASIL level would this result in? Based on this, you define your mitigation. It seems the safety folks have defined the mitigation to be "shut down the device". If you can show that there is a simpler mitigation, or that a mitigation is not needed (i.e. has no safety impact), then they should back off. This mitigation does need to be noted and documented, though.

Of course, this could be an organizational issue: Perhaps the safety folks are being the safety gatekeepers as a small portion of their job, so they are not willing to spend time to deal with nuances. I was the guy responsible for safety for my team, and it sucked - but I was doing it full time so I could analyze scenarios. The challenge was that the developers were not well versed with the ISO standard (had never read it), and it was a small portion of their job, and so they kept arguing.

> This is stupid because a division by a very small number has the same effect as division by zero.

As others have pointed out, this is not true. There is a big difference between a very large result and Inf. And of course, if a very large result could lead to a safety violation, then you need to handle it.

> For floating point, division-by-zero is perfectly fine and well defined by IEEE 754.

Keep in mind that conformance to the IEEE 754 standard is often not complete. Don't assume your language (or your libraries) are fully conformant, unless they are advertised as such.

Even if the ISO 26262 standard seems to have definitive language, I seem to recall there is a portion of the standard that allows you to waive requirements if the requirement makes no sense in your use case. There is a procedure to do it (documenting, etc).

FWIW, we did not handle Inf or NaN or divide by zero anywhere. We were writing a general purpose library for auto manufacturers, and it was up to them to decide where/how it would be used (called "Safety Element Out of Context" in the standard). Since we did not know the context, we argued that we can't assess if a division by zero would be hazardous, and merely noted in the documentation where it could occur. It's up to the folks who buy our libraries to then do that analysis. We only took care of things like showing there were no known crashes or hangs.

You are correct that it is possible in general. However, in this specific project, the decision was to shut down the device for safety reasons if the CPU detects a floating point division by zero. In my opinion this reduces the availability of the functions unnecessarily.

It doesn't, it cannot ever return NaN.

I'd also say that when I worked on a program for a big company that interfaced with alot of small companies and startups a few years, the startups in particular had really awful practices. The "bullshit" compliance checklists for security revealed awful practices that present real risks. The big company was more vulnerable to systemic risk due to inflexibility, the small companies are more vulnerable to individual risks due to employee action or lack of controls.

This is incredibly well said and worth highlighting.

Yet creating processes and systems is the expected task of management -- it's a key way to scale.

I'm fairly much averse to process myself, but have been occasionally involved.

In my, academic, world, the core problem is that there is no overarching mission against which the process/system can be evaluated. We have 5-10 important goals of the institution/system and multiple sub-organizations with wildly different emphasis on each goal.

Is there a "reverse" version of this where you do understand the reasoning, explain clearly why it doesn't apply anymore, but the other side just refuses to think for themselves and just sticks with the status quo because it must've been done with good reason and they don't want to second-guess it?

The point of the article is that's kind of correct - the cost (risk) of deregulating is concentrated, but the benefit is distributed. There needs to be some way to capture the value-add of removing a rule.

But if you do that the easiest way - turning the global metric of productivity into a target - then managers will asset strip, fire security (ahem, Mozilla), and walk off with a fat bonus (short-term productivity is up!) before people realise what's left is a the empty shell of a company.

And that's why good management is hard.

Yes, but that doesn't mean it was ever a good reason, or that the reason still applies.

In a very large number of cases—like the one mentioned in the article—the primary reason is to let the company's management feel more "in control" of their low-level employees.

In a lot of (closely related) cases, it's straight-up racism, sexism, or classism. (Frankly, one can easily make a case that the working-from-home prohibitions fall into that category—they derive from an assumption that low-level employees are lazy and want to avoid work as much as possible, because they're analogous to the assembly-line employees of yesteryear, and thus assumed to be lower-class...which means lesser beings.)

That’s just not great ROI.

1. https://aws.amazon.com/message/41926/?ascsubtag=e7c5af5933bd...

The flip side is the insurance argument: given a big enough organisation, a mistake like that will happen, even if the probability of each individual mistake is very low. So assuming one of these will happen, what can you do to reduce the impact or to reduce the latency of fixing such a mistake?

Also, do you expect mistakes of that magnitude to keep being made?

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 justified in the face of extreme skepticism.

That wasn't a case of a single engineer causing 100x engineers worth of damage, but it was the case where something made hundreds of people's jobs a tiny bit easier for two decades, then caused a massive public loss of face and who knows how much reputational damage.

And I'd be willing to bet that a fair number of HN readers work at a company which has at least one system with similar properties (a bit more convenient, a bit less secure) to the one implicated in our security breach; but failure is a once-a-decade event, and their company isn't nearly that old yet. Would those engineers defend that setup using the argument from this article?

You might be right in some special instance, but generally you are not. One example: Sending files via Email is a security problem. So you prohibit this via settings, virus scanners, appliances, etc. Now you've solved the emailed worm problem. However, you've just created a "how do we move files/data/screenshots/..." problem for the whole company. Now everyone will need their own special solution for everything, support will need a screenshot upload tool because you cannot just email them screenshots anymore, marketing won't be able to do images in mails anymore, external people won't have access to internal file shares, etc.

Shadow IT is great, it makes companies actually work rather than go bust.

So everyone is still using WeTransfer/Dropbox/whatever like they were in the years before.

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.

The problem with using sharepoint is that now you have sharepoint, and people will start using it, with all attendant horrors.

I realize the chances are a bit different, but it illustrates the point.

Stupidity is one of humanity's greatest renewable resources.

To mitigate this issue, on paper, an (usually) HR policy writes "do not do non-work related stuff with your work computer". And since many people ignore this rule, because "why have a second laptop?", the next best thing is to route all traffic from your laptop through the company, and weed out the GigHubs and GitLabs of this world (in the same manner that they block all sex-drugs-rocknroll stuff).

You can't blame a company for wanted to protect itself against a disgruntled employee that wants to push the (example - not applicable to your company) ebanking software code out in the open.

That said.. why would a person use the corporate computer for their (allow me the use of the word) 'hobby'? Unless it's for charity work, most companies don't appreciate spending resources (time, money, equipment) on other things.

Re: Chesterton's Fence - didn't know it had a name, thank you for this!

The thing is, they can't, not if my PC is still usable for day to day work. For a legitimate user, the ways to extricate data are endless (e.g. tunnel out via DNS, embed into video streams (for customer training or something), hell, even simple stuff like embedding data into the monstrous modern MS Office files should fly under the radar). The real value comes from making certain that a) only those that need access, get access (e.g. why do I have read/write access to the sales file folder as a developer?) and b) minimize the result of a breach ahead of time, which often coincides with doing good work in general. For instance, don't lie to your customers on a regular basis, treat your employees respectfully, and – regarding your example – write closed source software as if it was open source the whole time. It's not as if attackers need the source code to fuzz your software for vulnerabilities.

On a principled basis, I really dislike the world view where the employees have to be constantly prevented from getting the better of the company. If you don't trust me enough to surf on news sites during my time off at work, you should not trust me with software development, where laziness has often far worse consequences than not doing any work at all.

But most employees would never know how to do this and even if, the threshold is high to go to such lengths. Most companies primarily want to prevent users from sending out data by mistake or via malware, since these are probably >99% of the reasons for data loss.

I also dislike companies restricting employees. But I also know people from our IT department and the incidents they have to fight on a daily basis. If you don't restrict your network and company computers, you'll very quickly end up with malware, randsomware, leaked data etc.

The original scenario HenryBemis painted involved source code being leaked, so I think it's fair to either assume the employee is technically competent, or should not have access to it in the first place. Also, their scenario involved disgruntled employees, so on the other end of the spectrum, if you have, say, sales representatives which want to take out their customer database, then it's well in their motivation spectrum to snap a few hundred smartphone pictures of Excel or Outlook with a pdf "scanning" app to get a nicely printable address book. Sure, it's not perfect, but it can still be damaging as hell. Basically: Don't rely on data exfiltration to fail.

But the reason I've bothered to write the first comment, is that it's such a huge productivity drain to develop software on a locked down machine. I'll think twice or thrice before taking on a position where I don't have root access to my computer.

I concur most non-technical employees don't need (or should have) more than the equivalent of a Chromebook.

Because my work computer is around 100 times faster than my personal one.

There certainly is a logic around not wasting money where it'd do no good - but companies that are tight with employee capital expenditures make me really nervous. It's a thing I've avoided consciously in employers since my thirties - if you don't value me enough for a decent keyboard, a chair, and a sufficiently performing computer - then you don't have anyone who is sane at evaluating RoI at your upper echelons.

Which helps avoiding working late as partner expects you to be on time for dinner, and as you don’t need the work laptop at home as it’s not shared also as a personal laptop :)

I swear that’s main reason employers allow you to use your work laptop for personal use too. As you will have your work laptop with you at home so they can let you easier work weekends etc

It's pretty dumb to block gitlab when you employee can just... copy the codebase to an external drive?

Doesn't have to be hobby. A lot of corporate code these days is based on open source libs. What if you fix a bug and want to push upstream?

(Why don't I just make one? I have basically given up on making substantial contributons to Wikipedia since the Deletion Police took over the asylum. There's a 90% probability that if I did spend a couple of hours writing a good article, someone would come along within a week and spend a couple seconds deleting it. It's out of control.)

https://en.wikipedia.org/wiki/Deletionism_and_inclusionism_i...

It cites a quote from Paul Graham (cofounder of Y Combinator) that begins "Deletionists rule Wikipedia."

You don't have to put it up on Wikipedia. You could put it on Neocities or Medium or wherever.

People love to use folksy stories to justify the former (the one about the monkeys for example - https://workingoutloud.com/blog/the-five-monkeys-experiment-...).

I really like Chesterton's Fence as a counter-story to it, not to stop meaningful change from actually happening but to neutralize decision-by-best-folksy-story from over-ruling other options unchallenged, and allowing case-by-case thinking to prevail.

Someone has to say it.

I’ll admit to accidentally pushing some of my employer’s code to GitHub.

The code was a fork of one of my GitHub repositories and I pushed to the wrong remote. I deleted the resulting commits afterwards and no PII was leaked but it’s a valid concern for employers.

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... you guessed it, "public"), I have long looked for another IT department that has grappled with this problem. GitHub Support hasn't helped, appealing to public forums hasn't helped. But here, a sign that my problem isn't unique!

Of course, the solution sucks. sigh

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

My experiences with big organizations is that the above is complete absolute waste of time, unless you are in some kind of high level position already.

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.

I disagree. I've worked in a BigCorp and many requirements were in place not due to reason but due to feelings and inertia. The "butts in seats" requirement was one of the main ones. Even after showing my boss that I could at the very least work equally as effectively from home, he still felt it wasn't OK for me to work at home more than once a week. And never underestimate the power of inertia. Things are this way, they've always been this way.

It kind of threw that whole “we are in this together. Accept your 10% pay cut.” bullshit out of the window. Especially when all of the management had separate offices.

Sometimes, this is to be able to hire the exactly one person they want to hire, but HR policies or some law requires it be an "open bid" system. So the tailor the requirements such that only the one person can qualify, and they can justify the hiring and the letter of the law.

"I want to do X" / "I am too lazy to do Y instead" becomes "We can't do Y, it's a mandatory requirement to do X"

Very high on your response agenda should always be to ask for details. Who mandated this and how? If there's a regulation, cite the exact text of the regulation. There's a good chance the person telling you it's mandatory either knows it isn't or has never actually wondered why, and you can divert them from insisting on doing X / not doing Y to an exciting journey through their bureaucracy to find out that indeed there is no such mandate and never has been.

Back when TLS 1.3 was being finalised EDCO and other groups trying to preserve RSA key exchange tried really hard to pretend that what they were doing was mandatory (it isn't and wasn't) and that their use cases were legitimate (most of them don't even appear to have a sound security rationale, let alone a legitimate purpose).

When we get to September and companies that were asleep at the wheel suddenly notice the 398 day rule (Apple unilaterally changed the maximum lifetime of new certificates in the Web PKI to 398 days starting in September) you can guarantee that some of them will insist that having longer-lived certificates is somehow mandatory.

[ Edited: It's the Enterprise Data Center Operators thus EDCO not ECDO ]

That's a rule that last made sense some time in the 90s, when it was feasible to format the system drive, reinstall windows, and then applications on a secondary drive letter would work as-is without any further steps.

In the era of 10 GB application installs that deploy several hundred system-shared components, this is a hilariously out-dated mandatory process.

Yet.

Everywhere I go. There it is: The D:\ drive with "Apps" as the volume name.

So I think it's just as, or more, important to apply this thinking to the business requirements which drive development. Half of solution architecture is asking why something is the way it is, and asking again and again until you're sure there's a real reason. A lot of the time the answer is because that's how it's always been and traces back to a technical constraint from long ago. I see this a lot with companies moving from decades old legacy systems to modern applications.

Same with processes, authorisations, security risks, etc... They tend to start when somebody mad a mistake and they stick around regardless of if they're still relevant, effective or blocking progress.

They also (ceremonially) hold a member of the Commons "hostage" while the Queen is in Parliament to ensure her safe return.

>but the efficiency metric is non existent in public administrations.

And both of these have very insidious downstream consequences.

The nature of government employment selects over time for people who are dedicated to process for process sake so of course there's nobody around who asks "why?" and nobody around to say "the tradeoff is worth it let's do X instead".

Politicians and high level bureaucrats control the resource streams. The less efficient the larger the resource streams and the more power they have. Not only is there no incentive for efficacy at a high level because "screw it's other people's money" but there is an incentive for inefficiency because it lets the people calling the shots preserve/grow their power.

The only time you get a push for efficiency is deep in the bowels of a silo/fiefdom where the teams are small and the organizational unit's resource inputs are static but their performance metrics are pegged to outputs. Of course this sentiment dies on the way up the org chart because resources are mostly a "use it or lose it" type thing.

One effect is that this drives away exactly the kind of results driven people who should be working as public service.

Another effect is that it cements the status quo such that it is basically impossible for a government or government unit to pivot from "being inefficient and generally sucking" to "decent use of taxpayer's money" without an existential crisis for the organization. Basically nobody says "hey, WTF are we doing" while the organization is becoming an ineffective graft ridden mess. Everyone just keeps their head down until a shock forces them to actually solve the problems.

This is why you never see government organizations in rich places like NYC, Boston or DC clean themselves up but you occasionally see government organizations in poorer places like Buffalo or Newark clean house because as painful as making do with less and cleaning your own house is to those kinds of organizations the alternative of having politicians do it for you to win brownie points is worse. The rich places can just paper over their organizational problems with money. The poorer places have to stay on task or clean house much more frequently if they don't because there's less money to float along on.

BigCos have some similarly bad feedback loops but it's much more common to see them lop off an org that's dead weight because when the metric the people at the top use is profit you get much more incentives value driven behavior.

It's probably an overly complicated metaphor to use!

- new people

- systemic change

all this means to me that experience is not passed along and that regularly the new team will just face a somehow new problem with whatever reflex solution they can come up with with whoever is in the lobby at the time. It has to be between 5 minute smalltalk to 1 meeting at the end of the day.

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 than management skills and also rarer in the population than the number it management roles there are to fill.

I mean you're not wrong, but it's akin to saying if we all loved each other there would be no war.

I've seen plenty of great emphatic leaders get bogged down in large corps.

Great leaders can be terrible managers if they don’t want to do the associated admin, fortunately management skills are much easier to teach than leadership skills. Generally the latter (such as officer training) is cultivated in people that show requisite qualities (hence the UK cultivating potential military officers from 16 like the program I was in).

Neither is a given for success but the most successful people in management structure have a good mix of both to navigate. Also, I think n being empathetic doesn’t always mean being nice, it just means seeing other view points and making decisions with that extra insight.

It’s a fascinating topic I think.

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 manner would require too much context.

IMO a good solution is to leave breathing room in the agenda and trust that the engineers will work on fixing those issues. By making them somewhat autonomous they can skip the politics and get right down to make their lives and the product a better place.

I wish there was a standard way to work against the institutionalized trust issues that creep up in larger companies. E.g. when managers can only take actions if they can show an issue exists using their (arbitrary) metrics, and not when their reports directly tell them about it.

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

In fact, even the meanest largest corporations have excellent managers peppered throughout the organization that watch out for their people and genuinely care for them even though the corp as a whole might be a greedy SOB-- I'm thinking places like Comcast and Oracle here. ymmv.

> Every time someone in the management chain has axed the proposal with some variation of "this policy can not be changed because this is our policy and thus can not be changed", possibly with a "due to security reasons" thrown in there somewhere.

That's circular, no doubt there. We've decided this rule must remain in place, because it's a rule. This decision-making process doesn't make any sense, but I still don't see the sense in calling the rule 'imaginary'.

Is the real point here that sometimes bad rules remain in place until some external event forces a change? Doesn't sound so profound.

Rules are agreements between people. They're binding in the sense that we value our reputations, and we value not having to pay the consequences - often formally recorded - of not abiding by them.

Did the people making the agreements imagine doing so, or did it really happen?

Are the consequences real, and enforced, or are they just words?

If the rule is enforced, it is not imaginary at all.

> We've decided this rule must remain in place, because it's a rule.

This is the sane default position. If you don't understand a rule enough to be convinced it is problematic, it's safer to leave it in place than allow someone to erode it. Certainly the people in charge of rules should be able to understand them, but I'll take people who don't understand the rules and yet faithfully follow them over people who don't understand them and throw them away.

No. The Laws of Football and the Laws of Australia are imaginary in the sense you mean, but the Law of Gravity isn't.

Mother Nature's rules are different than ours, stubborn far beyond all reason and not recorded anywhere for our inspection.

Video games are interesting because we make them, yet for the most part some of their rules are like Ma's rules not ours. Watching Mario Maker 2 troll levels, the fact is that even if the player, and the viewer, and even the people at Nintendo who made the game think that Skipsqueak can't jump through that platform, if the game was coded such that it does, it will anyway.

Anyway, I think part of what you're missing is that the people in this story often don't know the rule is imaginary. Sometimes it's an excuse, but sometimes they honestly just assumed there was a reason for things being as they are and never stopped to go find out why. Not everybody has the sort of inquisitive nature that would afford that, some lines of business crush that right out of you.

I'm not a scientist but should the law of gravity not be seen as a human understanding of what gravity is rather than the handed down from God definition of gravity?

I get the point you're making though.

The author's example shows the very glaring case focused on: a rule totally disconnected from security. He was told "no remote work for contractors." One would assume any reasons for this rule (valid or not) would also be reflected in reality. In this case, maybe only regular employees had filled the legal paperwork and passed whatever security checks.

But the rule disappeared in less than a day. So it only existed on paper and punishment. I doubt the security concerns disappeared or were fixed in less a day.

These kind of rules, when exposed, can have a big impact on how well people follow other rules. I should know: I started ignoring a bunch (and sometimes later learned the risks I pooh-poohed).

There's no circular logic there at all. The second "because it is wrong" is shorthand for more complex moral reasoning that most people don't need to know - who cares if they know it, when the goal is simply to cut down on the murdering?

Another one is AWS Workspace. I think its the same reasoning - that it is more secure and not having to deal with hardware. But that thing is horrible to use. Constantly getting Windows is on low memory, disconnections which can be recovered from only by a reboot that takes 40 minutes. Even on a good day, everything is slow, you can see the Window maximize/minimize in slow motion, run an IDE and try to debug to get 100% CPU. Join a conference call, can't even open any other Window without frustration. Once I am no longer working for this client, I want to give a piece of my mind to who ever is in charge of this.

I can't imagine someone hiring a person they have such disdain for. That's a pretty sad attitude on the manager's part.

Oof, that's painful to imagine the daily frustration. There must be a better technical solution - but, as long as the current setup is working (and generating value), probably no one with decision-making power has an incentive to improve anything. They can ignore the cost, the wasted time, effort, stress and loss of morale.

I tried to bring this issue up a couple of times, but got turned down saying no budget for laptop (though they must be paying more to AWS within a year or two, we all have been on Citrix VDI or AWS for 6 years), or that it is easy for IT this way, and recently manager just told me to reboot everyday when I leave (which seemed to have solved the low memory issues, but others still occur).

2 weeks ago, the workspace wasn't registering the key presses (it does this sometimes and I have to reconnect). I got so angry, next thing I know I punched the laptop keyboard. The laptop screen froze with lot of lines on it, and there was a loud sound (probably from something getting in between the fan). Fortunately, everything was fine after a reboot. I never knew I would respond like this. I probably need to see a psychologist soon before this becomes a major issue. My dad also had such angry outbursts and I used to hate him for that.

A way to stay optimistic may be, to see it like Kung Fu training, where they wear heavy weights around the feet for building strength and endurance. When the weights are taken off, they can jump high and run fast - as I imagine you would be when you finally transition to a workplace that provides an actual work machine.

And try not to worry about it. One trick that I use is trying to think if such frustrations will be important 2 hours, 2 days, 2 weeks or 2 months from now. Usually they won't.

Granted, it does seem to make sense that your employees are as happy and relaxed as possible, but this attitude doesn't seem to exist in other industries to the same degree.

For example, I have a friend who works in finance. He was allowed to work from home for the bare minimum amount of time during the pandemic, his company requested him to return to the office almost as soon as the government permitted it (despite his job being possible to do 100% remotely). He also wears formal clothes every day (another thing that is frequently viewed as ridiculous in tech). But, he makes probably 3-4 times what I do per year!

It seems that in tech people expect to be "looked after" by their employer more than in other industries, yet simultaneously undervalue themselves.

Caveat: this is a perspective from the UK where finance salaries are high, and tech salaries are (as far as I can tell) much lower than the USA.

Some of us just have that inherent urge to say "wait, wouldn't it be better if we did it this way" instead of quietly following the rules. My guess is that people with this mentality are more likely to want to be a programmer in the first place.

The salary is market thing, to large extend.

The cloth and home office do have more to do with cultural background of people who run and join both institutions. It has also to do with value systems - higher preference for hierarchy, higher expectation for conformity because people judge each other by different signals in financial institution. Financial institutions are among the most conservative institutions there are. The need for tie is all about that.

People who can bridge technical, business, marketing, and sales are extremely highly valued.

I've learned to adapt, and I have a choice of jobs spanning about a 10x salary range as a result.

The choice I made: I chose the job which was the most fun and fulfilling, while still paying enough to where I don't need to stress about money (so long as I live a modest life). At the time, I had an offer at 2x that salary, and was being recruited into jobs at 2x that in turn. I also had more academic job offers where I could financially scrape by, but /with/ financial stress, which didn't seem worthwhile.

Also: If financial institutions were so conservative, we wouldn't have regular meltdowns like the subprime mortgage crisis.

It was about finance people who could easily do their jobs from home.

There are entire classes of work, like digging ditches and driving equipment, that can be sweaty and rote. Not designed to be fun, but to get something done. For pay. This is becoming regarded as mentally or physically abusive.

It helps to consider the pay as recompense for whatever hardship you endure to deliver value to the employer. Which seems obvious but apparently is not.

An acquaintance of mine working in academia told me that her boss was being bullying and abusive. I was really concerned and asked what was happening. She told me that her boss and department were making her come into the office (pre-covid) at 9am despite that she assured them she could do all her research remotely. When she would not come in or come in late, her boss was verbally reprimanding her.

This scenario is certainly bureaucratic and not the funnest, but it’s funny to me that bullying is considered making people come into work at an established time.

An awful lot of corporate culture is abusive, and designed primarily to give managers a warm fuzzy feeling of absolute control over their subordinates. Much of it derives directly from the assembly-line era, and much of the overall philosophy behind it is just thinly-veiled feudalism.

"But everyone does it this way" is not a valid defense against "this behaviour is abusive and designed to squeeze the agency and will to be more than a drone out of me."