Most “mandatory requirements” in corporations are imaginary
nibblestew.blogspot.com
nibblestew.blogspot.com
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...
That’s just not great ROI.
Stupidity is one of humanity's greatest renewable resources.
I realize the chances are a bit different, but it illustrates the point.
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.
The problem with using sharepoint is that now you have sharepoint, and people will start using it, with all attendant horrors.
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 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?
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?
1. https://aws.amazon.com/message/41926/?ascsubtag=e7c5af5933bd...
Also, do you expect mistakes of that magnitude to keep being made?
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!
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.
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.
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?
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.
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.
Furthermore this probably makes officially allowed open source contributions much more difficult.
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.
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.
Are they hiring?
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.
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.
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.
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.
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.
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.
You need two documents, minimum. One with rules, others to justify them.
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.
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.
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.
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.
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.
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.
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.
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".
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
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!
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.
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.)
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'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.
(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.
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.
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.
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).
Like a professional user advocate paid to convince developers that the users do have a point and the request is not impossible.
And yes, everybody should read it.
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.
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.
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 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.
>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.
- 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.
It's probably an overly complicated metaphor to use!
They also (ceremonially) hold a member of the Commons "hostage" while the Queen is in Parliament to ensure her safe return.
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.
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.
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.
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.
I just might be inexperienced in corp-land, but are management roles not leadership roles on a small scale?
> 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.
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.
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?
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).
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.
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.
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.
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.
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.
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."
I think the difference in what is reasonable and what is reasonable. If I question a reasonable start time “9am” that makes me someone that few want to work with. Whereas questioning forced, unpaid overtime is an entirely different, and I think reasonable question.
Reasonable rules like “be here by 9am” are not emotionally abusive to enforce. Perhaps you feel that way, but I think that’s unreasonable and will result in tons of emotional abuse as you go through the world.
Is a stop light emotionally abusive? Is not paying me $100k emotionally abusive?
I’m glad that we’re not actually under feudalism, but I think employment is not feudalism.
If there is no actual business purpose for it—beyond "I'm the boss and I want it that way"—then why shouldn't the boss be compassionate, and allow flexibility? Meetings with coworkers, as we've seen in the past few months, can work just fine being scheduled at times that actually work for everyone, rather than expecting everyone to be constantly available (and thus never able to truly focus on their actual work).
Unions are a horrible solution and should be avoided at all costs because they're a competitive disadvantage and will sink the company long term. The better solution is to pour money into creating more jobs and uplifting people out of a shitty job into one where there is more leverage.
Every industry should be a sellers market.
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.
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.
There's nothing inherently wrong with heavyweight bureaucracy. Roles, ceremonies, witnesses, signatures, tamper-evident seals, 2-man rules, split-knowledge safe combinations... the community loves this stuff. But we don't respect it because it's policy. We respect it because we were following along, trying to break it, trying to do better, and we couldn't.
"X is required" is shorthand for "we do not want to deal with the consequences of the lack of X". It's a decision. Sure, they could, but they wouldn't have resources to deal with other things.
That's basically all there is to understand here.
All the rest are corollaries:
- Sometimes changed circumstances require revisiting some decisions. Like COVID-19. - You can try and convince people to change their decisions. Your time to do that is limited too. Chose your battles. - Decision fatigue exists. People may not want to make new decisions and will prefer sticking to old ones or push the burden onto other people.
Saying it's "imaginary" is childish. Sure, policies may be arbitrary, but the constraint of only having 24 hours in a day is not.
https://www.tsa.gov/news/press/releases/2020/04/15/tsas-tips...
The whole restriction on liquids is fairly ridiculous, and even more of a security theater than most of the other checks. And I think the security guards know it, and use any excuse to look the other way.
This exception makes the TSA's policy more pragmatic and reasonable.
The harm of denying a baby milk or formula is worse than the risk of terrorism in this case. Not to mention is that it lowers the incidence of crying babies on flight.
The same logic could be applied to hand sanitizer restrictions in a global pandemic. Allowing people to carry a larger size could save more lives than the risk it poses. This is especially true when shortages can make it difficult to buy a travel size.
Why would that be the case?
Though I agree that's also besides the point.
Also see https://medium.com/incerto/the-most-intolerant-wins-the-dict...
Ideally, we wouldn't have to wait for a pandemic or other crisis to overcome this managerial hysteresis. Of course, if the rule is reinstated after a few months, or if a plane is brought down with 125 mL of liquid in a few years, then you're right - it's a rational rebalancing.
However, most TSA agents do not know this unless you tell them it's a medical exception, and then they will ask a supervisor.
>Tip 5: Place items from your pockets into your carry-on bag. Prior to going through the security checkpoint, take the items from your pockets and place them into your carry-on bag so that you don’t have to place them in a bin. Remove the keys, tissues, lip balm, loose change, breath mints, mobile phone and anything else from your pockets and place them right into your carry-on bag.
Batteries were dangerous and had to be removed until Apple started making devices without removable batteries then magically they are not dangerous anymore. Next you had to start turning your devices on as-if somehow it was impossible to make something dangerous that didn’t turn on. Security theater.
I used to have to take my belt and shoes off every time I passed through security but because I paid a $120 fee now I’m not dangerous anymore and can walk through security. I get to skip to the head if the line at the security checkpoints and coming back from international flights I get to breeze through the diplomatic lane at JFK (you can too! https://www.cbp.gov/travel/trusted-traveler-programs/global-...) Security theater.
I could go on for a while.
And then you have services like Clear which is basically legalizing corruption. Instead of slipping the agent $20 to go to the front of line, it's legitimized so that you can do it without any stigma.
Therefore, if you're a job seeker, and especially if you're a woman or a minority, you shouldn't let not having any of these imaginary requirements stop you from applying for whatever job you want, especially if it's a junior role.
HR was kind enough to redirect me to a newly opened junior position in another part of the company. Been with that company (directly or indirectly) for a total of 5 years now.
"I'd personally love to let X occur .. but it's not allowed due to company policy. This is mandatory."
I have always believed everything is negotiable in business. As people, we're subject to the rule of law, and obviously our businesses need to operate accordingly.
However, the policies that a company uses are really just a snapshot of current thinking. Nothing more than that; and thinking obviously changes.
Sometimes it doesn't - sometimes people vehemently insist on application of policies even though what they produce is ridiculous.
At a former employer I was quoted £70K (yes seventy thousand) for internal hosting of a not particularly business critical single static HTML page that would be accessed by maybe 100 people. I actually got a breakdown and it all made sense if you applied the policies the infrastructure team had invented - it didn't matter that the result was nonsense.
Turns out the internal infrastructure recharging model didn't scale down and as it was a "process" it couldn't be changed.
Was it basically "we charge more for stuff we don't want to do"?
Makes sense, like:
> When a customer asked if he could have chips with his lunch, White hand-cut and personally cooked the chips, but charged the customer £25 for his time.
-- https://en.wikipedia.org/wiki/Marco_Pierre_White#cite_note-o...
Policies without owners are a serious antipattern, since there's nobody to explain or refine them, or add nuance or grant exemptions.
Having only ever worked at a small company, I've enjoyed the absence of fear of blame. When the hierarchy is so minimal risk-vs-benefit seems to be easy to communicate and digest between both ends of the spectrum and accept with shared responsibility. I understand this doesn't automatically scale, but it feels unsatisfying to assume blame is as inevitable part of growth.
Can anyone think of a way to avoid it? Is it a necessary side effect of larger layered hierarchy or is it something else?
My pop-science (I learned about Dunbar's number from Malcom Gladwell's 'Tipping Point') theory for this is that we're wired to think of some small set of people (~150) as 'our group'/'my people', and that within that group we're more likely to forgive, and outside that group, we're more likely to blame.
On delivery of the produced cars, many rear wind shields were broken. Turns out they were transported from the factory on a train, faced backwards so they could fit more cars on the train.
(no idea if this really happened, but it's a nice little story)
The broader issue he’s talking about is simply the inefficiency of large organisations. There are many things that start to become much less efficient the more you scale up the size of an organisation, including risk management. This is because the feedback loops between decision and outcome starts to get much longer, the causal relationship between decision and outcome starts to become much more blurry, the distance between decision maker and impacted user gets bigger, and management starts to be comprised of less leaders and more bureaucrats.
Not only is this unavoidable, but it’s a good thing. Large businesses benefit from the economies of scale, but smaller organisations get to compete with them, because smaller organisations have the potential to be orders of magnitude more efficient than large ones. It also creates market opportunities for other B2B companies to come along and address some of their efficiency issues. I’ve done lots of consulting and contractor work, and one of the primary factors that drives demand for my services is enterprise inefficiency. Even if you put aside any consideration for how slow they are to adapt to new technology, a lot of demand for my contracts has been driven by strict corporate salary bands. The board sets the maximum rate that an engineer is allowed to be paid, and any team in the company that requires skills that the market has priced above that rate can only access them through external contractors/consultants. I’d bet the same is true for the OP, even if they don’t know it, so perhaps they shouldn’t be so quick to deride enterprise inefficiency.
Don't like the dress code? Dress however you want. Don't think the status meeting requires your attendance? Don't go. Mandatory office hours are 9-5 but you have better things to do with your morning? Show up at 11.
What are they gonna do, fire you? Not likely. It's hard to hire people, and it's risky to fire people who perform well but flout pointless rules.
Maybe some of your coworkers will resent you for thinking you're special and the rules don't apply to you, but don't let their jealousy stop you. If your company isn't going to treat you like an adult, you don't owe them anything.
PG wrote an essay recently in which he talks about “aggressive conformists” and “aggressive non-conformists”. You’re right in that being an aggressive non-conformist at a big company likely (though not definitely) won’t get you fired, but it certainly will rankle the aggressive conformists and not make you many friends from that group. And that may or may not be really bad for your career.
Corporate rules can be broken, but it should always been done in a savvy way instead of a brazen way. In most orgs, your performance is less important than people's perception and opinion of you. Find a way to show them the respect and deference they crave, even if you break their rules anyway.
I always showed up at 11, while they didn't fire me, they also didn't promote me.
It must be awfully hard to do this from home.
These rules/laws are Real
Wait, these rules/laws are made up/flawed
The whole thing is made up
Nothing is real
Lets make up our own rules/laws
These rules/laws have a functional place
We should build process around these rules
Every Generation washes rinses repeats forever. It doesn't matter if it's a corporate "requirement," government involvement or a scientific law, it's the same pattern.
"I'm in this photo and I don't like it".jpg
I'm afraid it might be true! This explains a lot for me.
I think the problem is that the company has found something that works in an acceptable manner and there is a big risk that any change will have unforeseen consequences so people stick to what works, no matter how badly.
There is another set of internal rules that clearly make life of one function easier at the expense of others. Again, these are very hard to challenge.
At some point there’s a limit where individuals become responsible for nothing and everything is a policy or process. It would be interesting to try to study or quantify this with different orgs and roles.
Do i think someone needs to tell me not to put every shitty tool on my work laptop which has a corp certificate? Access to vpn and corp network? With access to HyperScalers?
No.
What do my collegues? Everything. Oh there is a nice new shiny tool and it sends metrics to an external service, lets try this out...
Have you verified that every single application installed on your machines sends no telemetry, no crash reporting, and has no random web servers running that run arbitrary code? It's likely that you've missed one application. Now multiply that by 10,000 employees - all it takes is one application per person, and you have a massive amount of data being leaked.
I'm not seeing a problem with it and my default stack is not that big: chrome, intellij, shell etc. it is reasonable and someone has to do it.
Now that said, I personally have bristled being in a company which wasn't flexible at all! So the key is to find a balance between consistency and flexibility, and give all levels of management and employees empowerment to find the best way to do things.
Even questioning whether revenge should be shaping our decisions is likely to be met with a measure of it.
I work in this arena, in the public sector, and COVID brought massive fast changes to policy. But the public sector also already has mechanisms in place to regularly change it - regular board and city council meetings, specifically. And most organizations have a specific cadence on which they review and update their policies.
But the corporate world varies - sometimes the board sets policy, sometimes the execs, sometimes a compliance officer. Whomever it is, they need to not just write policy once and forget it - they need to treat it as a living body of documents, responsive to changes in their environment. Some companies are good at this, some are not.
I don't buy the conclusion of the article, though, that the leaders don't know enough to make decisions and policy becomes a way to entrench arbitrary rules and escape blame. Risk management and compliance are not about making life easy for the individual contributors. They are about looking at big picture risks such as litigation, regulatory compliance, and business continuity. They then set policy to be sure that well-meaning people who don't have visibility into those high-level concerns don't just make up their own rules. Yes, it puts some pain on us workers. But reduces risk. It is their job to choose those trade-offs.
That being said, not everyone is good at it, and there does need to be solid communication in the organization to let them know what problems a policy causes, so they can decide whether or not to adjust it. There also should be a communication path for people to ask why a policy exists, and start a dialogue about it.
A friend told me about his company where the IT decision makers were largely centralised, physically near their cloud servers and they frequently discounted the measurable and serious difficulties of internal tech consumers suffered in other locations for years, even though their architecture would have made it comparatively easy to rebalance things for a more global approach.
Early in my career we were told of a major reorganization of my then company's network shares, required "Because of Compliance" - only once it was underway and some key points still needed to be clarified did it become clear that Compliance was not even aware of the project! Nothing happened to the individual who had lied and diverted substantial resources needlessly. The individual was not even a member of the department, so saw zero benefit either.
Then one day the director of sales had a rather important call with a major prospective client while they happened to be visiting one of the regional offices. We were enjoying absolutely stellar-sounding phone calls within 48 hours.
None of this means you can necessarily axe all the requirements though. It entirely depends on your negotiating position. If a company wants to work with you badly enough they'll pay their lawyer the $500 hourly to modify the contract or approve your changes.
In the beginning of my adult life, I was under the expression that contracts were static and immutable. As I got more experience, I tried being more demanding (and my skills were also more in demand) when setting up contracts and I have at multiple points managed to change what was supposed to be "mandatory" and "unchangable" many times, from rental contracts to employment contracts and many other things.
This is usually the problem for many founders early on, if you already have a great product market fit then everything will bend to your demands and even turn down customers if they are not flexible enough. Most products do not have that very strong PMF early on.
The company reacted to changing circumstances. This is how things are supposed to work.
This cones very close to hitting the nail on the head but not quite. The crux of the matter is:
/Corporate risk aversion culture is only aware of the risk of change, and ignores the risk of stasis./
> Every time someone in the management chain has axed the proposal with some variation of ...
A comma is better used after "every time"
So I would assume malice rather than just fear of risk for any seemingly strange policy measures. The management is not your friend.
No one will change remote working rule just because of one or two outsiders' caprice (calling rule "stupid" shows just lack of understanding). World pandemy is obviously enough cause to change some rules.
And to make it clear, I love home working but I also know colleagues who work without screen protection in public places or leave their laptop unlocked when they are at home and have guests. That's potentially horrible for the company but absolutely unenforceable without physical presence.
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.
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
Corporate knowledge management requires effort to be done well.
Just because you think differently about a trade off it doesn't mean decisions you don't like are "imaginary."
Do you really want to be the one responsible for wiping us all out?
We have some imperfect system. Everybody knows about the problems it has. Somebody writes an article about how stupid and wrong those problems are. How does that help anybody?
The real question is how you fix those problems without introducing others. Passed a certain age and work experience you start to notice that the bureaucracy that stops you from doing quick smart fixes also stops a lot of people from doing serious damage to the company.
And yes, in some cases external factors will force a quick reevaluation of that bureaucracy. And you can say "I told you so all along!". But again, that's zero value to the business. The real value is in the work done to plan and execute a change is a way that assures no collateral damage and also to satisfy humanly needs/desires in the hierarchy.
People want to cover their asses, but guess what, when you put the responsibility of a change on the smart ass that always annoys coworkers with his brilliant ideas they tend to back away from it cause his ass is precious to him too.
TLDR: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
The bureaucracy stops idiots from being idiots. The logical solution is to not hire (or retain) idiots, not to add more bureaucracy.
To sum it up: try to talk about what you already did. So from experience, not what you would do in your ideal world.
There seems to be absolutely zero correlation between organisational role/level and ability, instead using years of service as a proxy.
I don’t really know how to fix this.
Or at least I’m generally in a position to do something about it.
Maybe it could stimulate reflection? Granted, my hopes are dampened too.
> Passed a certain age and work experience you start to notice that the bureaucracy that stops you from [...] doing serious damage to the company.
If you get even older, people might even stop you from running around without supervision to stop you from doing damage to yourself. Doesn't mean it should always be the case.
There will hopefully always be forces the evaluate practices. Bureaucracy can be good and it can be bad. It behaves just like french fries.
But I think the general trend that large corps seem to get a bit slow on innovation holds true. Doesn't mean it is not working well with lots of accomplishments.
And there are. The article itself contains such an example. On the other hand they ask why was it necessary for coronavirus to do so. The answer is in the question: there was no need to evaluate the practice until it was.
That is the problem - we treat everyone as equals, trying to put rules that work for everyone, so the lowest common denominator is who the rules are made for. So someone who can leverage their knowledge for the good of the company gets ducktaped with red tape because someone else is prone to fucking up.
Answer: the higher on the hierarchy you are the less the rules apply to you.
I suspect this answer is not satisfactory to you, in which case offer an alternative.
Yes and + the more you break/ignore the rules successfully, the less they apply to you.
But who gets to decide and on what basis is an organisation-specific question. Trying to answer it for "everyone" also gets you into lowest common denominator bucket where you can only give an answer that covers all cases. That is why a huge chunk of organisational/managerial advice is just a "how not to shoot yourself with that gun in your hand for idiots" guide.
In general, companies treat you are like a criminal trying to con them. Submit previous payslips, last company's relieving letter, contacting the previous company, stupid non-compete clauses, bond clauses and list goes on.
This is unlikely to change as most employees don't really have the bargaining power to question the rules, the workforce is abundant, they can just tell you to fuck off and hire someone else.
Fair enough if you already told them, but I'd make it clear they'd see the proof when the offer was otherwise certain.
What the author is describing here is poorly designed management incentives.
It leads to fun situations and enlightening conversations when its policy versus policy.
Who says which policy is more important?
If corona means i can't get my work done, i have a new risk.
Security risk for external consultants having full access at their home vs. no one can work -> i might choose the externals giving access.
Its not imaginary.
Also we are not talking about the person who is really smart about it we talk about the avg person. There are plenty of stories of laptops being stolen in coffee shops or from a train.
And its also a Network thing. Do i want you to be able to pull/push something into my corp network fromyour home network?
It's a risk assessment that suddenly tilted the other way.
I don't agree with "everybody should work from the office" sentiments, myself, but I have seen this happen very clearly in many organizations.