4 ms·

What I am hearing is that is that it is not practical to expect network admins to be in control of their networks and sub-sequentially it is not practical to en

What I am hearing is that is that it is not practical to expect network admins to be in control of their networks and sub-sequentially it is not practical to ensure no malicious devices are plugged into enterprise networks. Just because it’s difficult to do doesn’t mean it shouldn’t be done.

IggleSniggle 5y ago
What you should be hearing is that it’s not necessarily irresponsible for somebody not to know something when they are inheriting a system, and that it’s totally reasonable to expect to encounter poorly done systems in the real world that need someone to fix them. It’s often the case that somebody slapped something together in an area that wasn’t their expertise, it’s been noticed that it’s a real problem, and someone has been hired to fix that problem. The “not knowing” is often the reason they’ve been hired. Trying to sort out a real world scenario (while also handling other needs of the org) is almost definitionally Taking Responsibility. So let’s not shit on people trying to cleanup a bad situation by calling them irresponsible for not knowing.
imwillofficial 5y ago
Suif, you have a lot to learn my friend. First is speaking in such absolutes. The more senior I get, the more I realize there are often a multitude of reasons things are the way they are, and many times those are valid reasons, when seeing something that is broken. Taking a beat before pontificating and making a fool of yourself will save a ton of heartache in your career. When you see something so broken, ask yourself why? Then ask somebody else. Some highlights from my career: 1) Last guy got cancer in the middle of a build. 2) Last guy worked his way up from one man help desk to Linux guru over 15 years all on his own, but was so busy putting out fires, he never had the chance to improve things. 3) Project started out as a proof of concept and was intended to be torn down. 4) Due to government contracts, the system has to be maintained exactly as delivered, no labels even allowed, and obviously no IT staff(?!) To make spreadsheets. Everything was paper notes by operators. 5) Pure laziness and incompetence as you alluded to. All this to say, more often than not there is a good reason something is fucked up, finding out why may help you fix it (like in the case of politics, budget issues, firefighting, priorities, etc..)

IggleSniggle 5y ago

What you should be hearing is that it’s not necessarily irresponsible for somebody not to know something when they are inheriting a system, and that it’s totally reasonable to expect to encounter poorly done systems in the real world that need someone to fix them. It’s often the case that somebody slapped something together in an area that wasn’t their expertise, it’s been noticed that it’s a real problem, and someone has been hired to fix that problem. The “not knowing” is often the reason they’ve been hired. Trying to sort out a real world scenario (while also handling other needs of the org) is almost definitionally Taking Responsibility. So let’s not shit on people trying to cleanup a bad situation by calling them irresponsible for not knowing.

imwillofficial 5y ago

Suif, you have a lot to learn my friend. First is speaking in such absolutes. The more senior I get, the more I realize there are often a multitude of reasons things are the way they are, and many times those are valid reasons, when seeing something that is broken. Taking a beat before pontificating and making a fool of yourself will save a ton of heartache in your career. When you see something so broken, ask yourself why? Then ask somebody else. Some highlights from my career: 1) Last guy got cancer in the middle of a build. 2) Last guy worked his way up from one man help desk to Linux guru over 15 years all on his own, but was so busy putting out fires, he never had the chance to improve things. 3) Project started out as a proof of concept and was intended to be torn down. 4) Due to government contracts, the system has to be maintained exactly as delivered, no labels even allowed, and obviously no IT staff(?!) To make spreadsheets. Everything was paper notes by operators. 5) Pure laziness and incompetence as you alluded to. All this to say, more often than not there is a good reason something is fucked up, finding out why may help you fix it (like in the case of politics, budget issues, firefighting, priorities, etc..)