It's a guy browsing the internet a bit. This is not some deep philosophical question. You're just advocating being the type of person we'd all hate to work with.
“It’s a guy browsing the internet a bit” can be game over from a security perspective. Some machines should never execute code from public web pages, full stop.
So it is a philosophical question of why the restrictions were in place in this scenario. If it was “employee productivity”, then sure, who cares. If it was an IRS computer with thousands of people’s tax returns on disk and access to millions more, then reporting was the right move.
If he was the most senior sysadmin it's already his responsibility to keep things safe anyway, so if you trust him for all the rest of the infra you can trust him for a proxy.
All I mean is he is the person paid to do this already so it's not extra dangerous. It's like a policeman doing a citizens arrest if they spot a crime on the off hours. It's frowned upon but you know it's the same thing they do in their job.
Our HN user, mr-wendel, worked at the company, but I'm not sure they said what their job was. It might have been sysadmin, but since mr-wendel talks about snitching on a senior sysadmin directly to the CEO, it's save to say that the sysadmin did not report to mr-wendel; and I presume that mr-wendel was a lot lower an the pecking order.
I don't think the senior sysadmin was paid to hide browsing from the oversight?
I'm not defending running rogue workloads on your employers infrastructure, that's obviously wrong. I'm just saying from the description, and the role of who did it, it probably wasn't super problematic in terms of security.
I think this thread highlights nicely that context is everything.
In this case, I think vasco's take is correct: the sysadmin was indeed trustworthy enough to exercise this discretion in response to overzealous employee productivity rules without at all undermining his primary responsibilities.
The proxy was definitely in a place to essentially trivialize it's impact. I'm pretty sure thats why it was placed where it was, as opposed to make it harder to find. If that was the chief concern, disabling logging would have obviously been the first thing to happen.
You never know... I've seen an instance where it turns out an employee was watching pr0n at work and downloading the materials to their shared profile directory. Discovered when the IT Admin was requesting a new NAS server because the current shares were full.
edit: to be clear, it wasn't the admin downloading the content.
I can't agree. By far the biggest lesson that you can verify even on this thread, is that the biggest tech problems are actually people problems. Even things like tech debt are all over the place framed as project/people management rather than tech stuff at its fundamentals.
The comment already established the senior sysadmin is generally a valuable person who does a lot to flourish the company. Going out of the way to be a encumbrance towards someone who is verifiably doing their job anyways, means you're actively creating a people problem. I;d rather people learn the correct, bigger lesson here.
> By far the biggest lesson that you can verify even on this thread, is that the biggest tech problems are actually people problems.
The opposite lesson is also useful: sometimes you can turn people problems into tech problems, and that's how you can 'solve' them.
Slightly hypothetical scenario: assume your team keeps all the source code on a shared drive. You are supposed to coordinate with your coworkers before touching any code. Sometimes that goes wrong, and looks like a people problem.
If you introduce eg git and automated-tests-before-merging, you can turn that into a technical problem.
My thesis is that organisations (and people in those organisations) can only solve so many people problems. If you lighten the load by automating some of the problems into tech problems, you have more levity on the remaining people problems.
(This happy state of affairs isn't always possible. And sometimes it can backfire.)
When I was young, I thought that being a man of my word meant that, as I'd given my employer my word that I would follow their security policy, I should follow it to the letter - for example, never holding the door open, even for a colleague I'd worked alongside for a long time.
And I thought that petty rulebreaking was a corrosive force, something that would snowball into bigger problems down the road. As a man of honour I would work precisely my contracted hours, never a minute less, I would consider it shameful if someone so much as stole a pen from the office. The rest of the team is heading to the pub at 4pm after a lengthy day of planning meetings? Sorry guys, I don't finish until 5:30pm.
Later in my career I chilled out a lot, and learned that the actual rules are often different (and a lot more nuanced) than the written rules. And that if you've worked with a guy for a decade you can, in fact, hold the door open for him and the sky won't fall down.
> I thought that being a man of my word meant that, as I'd given my employer my word that I would follow their security policy, I should follow it to the letter
This basically sums up my "cover story" nicely so I didn't have to admit to myself that it was more about scoring points for my own position.
Dressing up vanity as integrity is a dangerous thing.
Imaging to do different was only one part of the lesson. The other, and bigger, part is acknowledging the difference between wanting to do the right (for not just me) thing versus that was sure to score points with authority.
Getting into Haskell because I was bored and assumed doing Haskell would be far more interesting. And that code would be much better written in Haskell, almost perfect because it is math based.
Haskell is amazingly interesting but very hard. There are few companies using it and the one that did in my city got taken over and usual management shenanigans. I didn’t get a job with them.
Haskell meet ups went over my head and I couldn’t keep up. Didn’t have the time to play catch up with the talented people in this scene.
Realized writing software is an artform, no language necessary makes it better and more fun. Appreciate the common languages more like C# Python and Go.
Haskell has great ideas but there is value in designed language with language features over making everything in the higher type systems.
So in short humbled into realizing what makes good software is more than using clever languages.
I think almost all business people earned their stripes as employee. SV and furthermore SV stereotypes are very unusual in their young founders. Nothing against young founders though! Just saying it ain’t common. Family business being the exception (but that quacks like employment then business ownership later)
I like the intent but homeless people deserve better. Just make them meals from scratch like everyone else eats. And keep taking your doggy bag home. A $1 doggie bag “corkage” that goes to a homeless food operation would be better IMO.
If I rephrased the OP as “give the half eaten restaurant leftovers to be used as school lunches” people would say that is horrible but somehow OK for homeless people?
I must have phrased it poorly, because I never meant to imply half-eaten food. The idea is to portion it out before the food is brought to the table. ("half of their meal is then portioned out" should have been phrased differently; "first" instead of "then" is a better fit)
