It's the difference between being hit by a.50 cal sniper rifle, to 20 gauge bird shot. The second one will hurt, and might maim you, but the first one will kill you dead almost no matter where you get hit.
CEOs are employees. If their health records should be open for the investors, should all employees' records be open? At what level on the corporate ladder do you lose the right to have a private life, especially regarding your health?
Neither am I, though it seems more like arrogance and stupidity than laziness, to me. "We don't have to show up, they can't make us do anything! We're all the way up in San Francisco, why should we have to go to Los Angeles for this?"
The guy was only in there for a few weeks, it's hard to believe he was "institutionalized" in that short a time period.
What I think is more likely is, he was convinced (for whatever reason) that his family couldn't survive without him. That if he weren't around, they would be better off dead. That seems to be the usual rationale used by "family destroyers" (or at least that's what I learned from Law & Order).
So you've never worked in a shop where one or two guys did all of that? Seriously? In my professional life, I've been (at various times) the dba (Oracle, Informix, MySQL), the sysadmin, the sysengineer, the Windows guy, the Linux guy, the Solaris guy, the AIX guy, the mail guy (Qmail, Sendmail, Exim, Exchange, various anti-spam systems), the mainframe guy, the network guy (3COM, Cisco, Foundry), and the programmer (Python, C, Java, Perl, SQL). Not to mention all the times when I've worn the project manager hat, and the times when I've managed teams of admins and programmers.
None of those skills are orthogonal to each other, you can learn them all, and you can be good at them all, and excellent at (at least) several.
Oh please, engineering, accounting, and PR are completely different career fields. Linux, Windows, and Cisco aren't, and any decent sysadmin should be able to switch back and forth between those skill sets with relative ease.
'That's why the 5% to 15% really doesn't sit well with me,' Rodrigues writes. 'I suspect that larger companies are looking for developers with a mix of experience with proprietary and open source products, tools and frameworks,' as opposed to those who would work with open source for 90 percent of the work day.
So people with a mix of skill sets are considered valuable by employers, eh? And yet, in this post, where I advocated requiring IT staff to rotate in their job functions and learn Linux, Windows, Cisco, etc. etc. etc, people jumped down my throat saying "that's too hard" or "geeks won't like that".
Not to mention, despite all the evidence to the contrary, our society does value human life greater than mere money. Threatening someone with a gun for a twinkie shows complete disregard for another's life; embezzling brazillions of dollars simply doesn't compare, in the grand scheme of things.
Just a guess, but I'm thinking your computer systems officer or whatever you had wasn't rotated annually to the radio shop to expand his horizons.
Um, the Commo WAS my division officer. My work centers included LAN support, WAN support, satellite comms, crypto, radio comms, desktop support, and myriad other C4I systems. So not only were the computer guys also the radio guys, the jobs were considered to be interchangeable and everyone was expected to fill all of those roles, as needed. Sure, we had guys who were better at some jobs than others, and when we went to GQ the best guys were at their assigned stations. But short of that, everyone was expected to work in different work centers on a regular basis.
Not to mention that the officers were rotated in their jobs even more often than the enlisted, and much more drastically. My first division officer started working with us as an ensign; by the time he made lieutenant, he had served as the ship's legal officer, the damage control officer, and the assistant navigator. He managed to learn all of those roles just fine.
And no, there were no civilian contractors working with us, except for rarely training on new systems. The Navy doesn't get the luxury of the Air Force in contracting out all of their jobs to the lowest bidder, sailors are expected to work for a living.
True. Professionals also don't tell professionals from other fields how to do their jobs.
What other field? These are all IT jobs, I'm not talking about putting the accountants in charge of the firewalls. I'm not even suggesting you rotate the programmers and the admins, those are distinct fields. But if a Linux expert can't get up to speed on managing AD, or a Windows expert can't get up to speed on running Cisco firewalls, then they're both entirely too specialized to be truly useful to an organization.
You obviously haven't served
12 year veteran of the USNR. Served in both Gulf Wars. Left as an IT1 (Information Systems Technician 1st Class). When I was a Leading Petty Officer for my division, I would routinely rotate guys from one workcenter to another, to make sure they knew the systems in each one. Additionally, to be promoted in the Navy, you have to be certified that you know how all of the systems on your ship/unit/station work together. So I don't know which branch you were in, but in the Navy at least cross training is taken very seriously.
To reiterate: just because something is hard to do, doesn't mean it's not worthwhile.
Anyone who would receive the keys to operating a nuclear reactor would have to be on an approved clearance list. If your boss wasn't on that list and demanded the keys, you absolutely would not hand them over. If your boss demanded you hand the keys to someone who was on the list, whether themselves or not, and you refused, you would be escorted out of the building. And rightly so.
If I was working on designing and building a network, and I had it all up and running perfectly, should I destroy it because my boss tells me he has a better way?
You should take the steps I outlined above: 1: Document your objections. 2: Get your boss to acknowledge those objections, then document that acknowledgment. 3: Do what you're told. When things blow up, use your documentation to cover your butt (and fry your boss's).
The trained Linux admins hated the AD infrastructure
Professionals don't let their emotions dictate their responses to a given platform.
Windows guys couldn't log into the *nix boxes
Professionals know how to look up the answers, or get them from subject matter experts, to even the simplest of problems.
ome quack kept making small *minor* changes to the Cisco boxes that took down the whole network. (hmmm - we probably don't need this option - "Emulate ???? bug" - now off - hey why did I lose access to the EU office?)
Professionals don't toy with production to find out what does what, they set up a lab for that purpose.
Rotating Admins is a novel idea, but a better idea is to keep them closer to their areas of expertise.
Then why is the military able to do it without suffering outages? Guess they have more professionals than most IT shops.
I hope he rots in jail for a good long time. Not because I bear him any particular ill will, but so that he can be an object lesson to the legions of system/network/database admins out there (and right here, on this site) who think that just because they've been hired to maintain and protect an organization's systems/networks/databases, that they somehow own those resources.
They don't; you don't. Your employer does. If management is screwing up, you document their screw ups and document your objections to them. Then you do what they told you to do, anyway. When it blows up (and it will), you go back to your documentation and show anyone who will listen that you warned them. You absolutely do not refuse to turn over passwords when told to do so.
And for the management types who are reading this, start rotating your admins among different projects, at least annually. Take the Linux expert and put him in charge of Active Directory; take the Windows expert and put him in charge of the SAN; take the SAN guy and put him in charge of the Cisco and Foundry routers. Shake things up, force people to work outside of their comfort zones. Not only will it encourage your staff to constantly learn (which is a good thing with geeks, we like learning), it will make sure your documentation is top notch since everyone knows they're going to depend on that documentation to do their jobs. It'll also avoid single points of failure in your staff, like this guy became. Not doing this because it's "hard" is an excuse, not a reason; nothing worth doing is easy, that doesn't make it any less worthwhile.
As for poor Mr. Childs, I feel for the guy, I really do. But he has no one to blame for his situation but himself, and unless he has reams and reams of documentation of the many times he warned management not to do what he thought was so horrible (and unless the network does blow up, as predicted), he'll never work in IT again.
All of you young admins out there: learn from his mistakes, and don't repeat them.
One of the big reasons they're popular is security. Without stored procedures, to allow a program (or the programmer who wrote it) access to a given data set, you'd have to grant it SELECT privileges on the table(s) containing that data. With a stored procedure, you just grant it permission to run that procedure, which might only return a subset of the data in the table(s).
Quick example: you have two tables, employees and employee_reviews. The employee table contains a unique ID, the employee's name, their salary, their start date, and other data. The employee_reviews has a foreign key linked to the employee's unique ID, the score for their latest review, and the text of the review. Without using stored procedures, to provide access to a given program to display the employee's name and the text of the review, it would need SELECT access on both tables; that exposes the employee's salary, which (we'll assume for this example) violates company policy.
With a stored procedure, though, you don't have this dilemma. The procedure would just select the appropriate columns and return them. This protects the employee's privacy and abiding by company policies.
Slashdot Mirror
Even if all those stories are true, which they aren't
So Clinton didn't bomb an aspirin factory the day his former mistress was supposed to testify in court?
And he never preemptively attacked Iraq?
And he didn't launch a war in the Balkans without Congressional approval?
Interesting.
Is Google searching Google some sort of self-discovery process?
For some reason I'm reminded of this definition of recursion:
See recursion.
This is pretty much a solved problem.
As opposed to formatting comments on a discussion board?
It's the difference between being hit by a .50 cal sniper rifle, to 20 gauge bird shot. The second one will hurt, and might maim you, but the first one will kill you dead almost no matter where you get hit.
CEOs are employees. If their health records should be open for the investors, should all employees' records be open? At what level on the corporate ladder do you lose the right to have a private life, especially regarding your health?
I'm not surprised they didn't bother to show
Neither am I, though it seems more like arrogance and stupidity than laziness, to me. "We don't have to show up, they can't make us do anything! We're all the way up in San Francisco, why should we have to go to Los Angeles for this?"
Google "doctrine of complicity". You might learn something.
The guy was only in there for a few weeks, it's hard to believe he was "institutionalized" in that short a time period.
What I think is more likely is, he was convinced (for whatever reason) that his family couldn't survive without him. That if he weren't around, they would be better off dead. That seems to be the usual rationale used by "family destroyers" (or at least that's what I learned from Law & Order).
So you've never worked in a shop where one or two guys did all of that? Seriously? In my professional life, I've been (at various times) the dba (Oracle, Informix, MySQL), the sysadmin, the sysengineer, the Windows guy, the Linux guy, the Solaris guy, the AIX guy, the mail guy (Qmail, Sendmail, Exim, Exchange, various anti-spam systems), the mainframe guy, the network guy (3COM, Cisco, Foundry), and the programmer (Python, C, Java, Perl, SQL). Not to mention all the times when I've worn the project manager hat, and the times when I've managed teams of admins and programmers.
None of those skills are orthogonal to each other, you can learn them all, and you can be good at them all, and excellent at (at least) several.
Larry Flynt would like a word with you.
Oh please, engineering, accounting, and PR are completely different career fields. Linux, Windows, and Cisco aren't, and any decent sysadmin should be able to switch back and forth between those skill sets with relative ease.
From the summary:
'That's why the 5% to 15% really doesn't sit well with me,' Rodrigues writes. 'I suspect that larger companies are looking for developers with a mix of experience with proprietary and open source products, tools and frameworks,' as opposed to those who would work with open source for 90 percent of the work day.
So people with a mix of skill sets are considered valuable by employers, eh? And yet, in this post, where I advocated requiring IT staff to rotate in their job functions and learn Linux, Windows, Cisco, etc. etc. etc, people jumped down my throat saying "that's too hard" or "geeks won't like that".
Interesting.
Yeah, it's sad to see a hero go senile.
Don't worry, I'm sure he'll win the Republican nomination for President in 2012, if recent events are anything to go by.
We are judging the time is close when most of you will be acccepting [sic] of our revellation [sic].
You can travel the cosmos, but can't use a spell checker?
Not to mention, despite all the evidence to the contrary, our society does value human life greater than mere money. Threatening someone with a gun for a twinkie shows complete disregard for another's life; embezzling brazillions of dollars simply doesn't compare, in the grand scheme of things.
Just a guess, but I'm thinking your computer systems officer or whatever you had wasn't rotated annually to the radio shop to expand his horizons.
Um, the Commo WAS my division officer. My work centers included LAN support, WAN support, satellite comms, crypto, radio comms, desktop support, and myriad other C4I systems. So not only were the computer guys also the radio guys, the jobs were considered to be interchangeable and everyone was expected to fill all of those roles, as needed. Sure, we had guys who were better at some jobs than others, and when we went to GQ the best guys were at their assigned stations. But short of that, everyone was expected to work in different work centers on a regular basis.
Not to mention that the officers were rotated in their jobs even more often than the enlisted, and much more drastically. My first division officer started working with us as an ensign; by the time he made lieutenant, he had served as the ship's legal officer, the damage control officer, and the assistant navigator. He managed to learn all of those roles just fine.
And no, there were no civilian contractors working with us, except for rarely training on new systems. The Navy doesn't get the luxury of the Air Force in contracting out all of their jobs to the lowest bidder, sailors are expected to work for a living.
True. Professionals also don't tell professionals from other fields how to do their jobs.
What other field? These are all IT jobs, I'm not talking about putting the accountants in charge of the firewalls. I'm not even suggesting you rotate the programmers and the admins, those are distinct fields. But if a Linux expert can't get up to speed on managing AD, or a Windows expert can't get up to speed on running Cisco firewalls, then they're both entirely too specialized to be truly useful to an organization.
You obviously haven't served
12 year veteran of the USNR. Served in both Gulf Wars. Left as an IT1 (Information Systems Technician 1st Class). When I was a Leading Petty Officer for my division, I would routinely rotate guys from one workcenter to another, to make sure they knew the systems in each one. Additionally, to be promoted in the Navy, you have to be certified that you know how all of the systems on your ship/unit/station work together. So I don't know which branch you were in, but in the Navy at least cross training is taken very seriously.
To reiterate: just because something is hard to do, doesn't mean it's not worthwhile.
I don't know, I strongly suspect it's going to be more like A Beautiful Mind when everything comes out.
Anyone who would receive the keys to operating a nuclear reactor would have to be on an approved clearance list. If your boss wasn't on that list and demanded the keys, you absolutely would not hand them over. If your boss demanded you hand the keys to someone who was on the list, whether themselves or not, and you refused, you would be escorted out of the building. And rightly so.
I think you think too highly of yourself.
If I was working on designing and building a network, and I had it all up and running perfectly, should I destroy it because my boss tells me he has a better way?
You should take the steps I outlined above:
1: Document your objections.
2: Get your boss to acknowledge those objections, then document that acknowledgment.
3: Do what you're told. When things blow up, use your documentation to cover your butt (and fry your boss's).
How hard is that to comprehend?
The trained Linux admins hated the AD infrastructure
Professionals don't let their emotions dictate their responses to a given platform.
Windows guys couldn't log into the *nix boxes
Professionals know how to look up the answers, or get them from subject matter experts, to even the simplest of problems.
ome quack kept making small *minor* changes to the Cisco boxes that took down the whole network. (hmmm - we probably don't need this option - "Emulate ???? bug" - now off - hey why did I lose access to the EU office?)
Professionals don't toy with production to find out what does what, they set up a lab for that purpose.
Rotating Admins is a novel idea, but a better idea is to keep them closer to their areas of expertise.
Then why is the military able to do it without suffering outages? Guess they have more professionals than most IT shops.
That can also be easily accomplished with views.
Very true. Of course, Drizzle removed views, as well. :(
I hope he rots in jail for a good long time. Not because I bear him any particular ill will, but so that he can be an object lesson to the legions of system/network/database admins out there (and right here, on this site) who think that just because they've been hired to maintain and protect an organization's systems/networks/databases, that they somehow own those resources.
They don't; you don't. Your employer does. If management is screwing up, you document their screw ups and document your objections to them. Then you do what they told you to do, anyway. When it blows up (and it will), you go back to your documentation and show anyone who will listen that you warned them. You absolutely do not refuse to turn over passwords when told to do so.
And for the management types who are reading this, start rotating your admins among different projects, at least annually. Take the Linux expert and put him in charge of Active Directory; take the Windows expert and put him in charge of the SAN; take the SAN guy and put him in charge of the Cisco and Foundry routers. Shake things up, force people to work outside of their comfort zones. Not only will it encourage your staff to constantly learn (which is a good thing with geeks, we like learning), it will make sure your documentation is top notch since everyone knows they're going to depend on that documentation to do their jobs. It'll also avoid single points of failure in your staff, like this guy became. Not doing this because it's "hard" is an excuse, not a reason; nothing worth doing is easy, that doesn't make it any less worthwhile.
As for poor Mr. Childs, I feel for the guy, I really do. But he has no one to blame for his situation but himself, and unless he has reams and reams of documentation of the many times he warned management not to do what he thought was so horrible (and unless the network does blow up, as predicted), he'll never work in IT again.
All of you young admins out there: learn from his mistakes, and don't repeat them.
One of the big reasons they're popular is security. Without stored procedures, to allow a program (or the programmer who wrote it) access to a given data set, you'd have to grant it SELECT privileges on the table(s) containing that data. With a stored procedure, you just grant it permission to run that procedure, which might only return a subset of the data in the table(s).
Quick example: you have two tables, employees and employee_reviews. The employee table contains a unique ID, the employee's name, their salary, their start date, and other data. The employee_reviews has a foreign key linked to the employee's unique ID, the score for their latest review, and the text of the review. Without using stored procedures, to provide access to a given program to display the employee's name and the text of the review, it would need SELECT access on both tables; that exposes the employee's salary, which (we'll assume for this example) violates company policy.
With a stored procedure, though, you don't have this dilemma. The procedure would just select the appropriate columns and return them. This protects the employee's privacy and abiding by company policies.
Seems like sending her an MMS of her sister topless would make for a more interesting confrontation.
(Interesting for the rest of us, at any rate.)