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...
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.
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.
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.
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.
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.
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?
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.
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.
Because my work computer is around 100 times faster than my personal one.
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.)
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.
Furthermore this probably makes officially allowed open source contributions much more difficult.
"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.
- 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.
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...
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.
Though I agree that's also besides the point.
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.
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.
>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.
However, most TSA agents do not know this unless you tell them it's a medical exception, and then they will ask a supervisor.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.