Ask Slashdot: Old Dogs vs. New Technology? 515
Posted
by
Soulskill
from the tips-from-an-all-star dept.
from the tips-from-an-all-star dept.
xTrashcat writes "I am 22 years of age and have been working in the IT field for over a year. I try to learn as much about technology as my cranium can handle; I even earned the nickname 'Google' because of the amount of time I spend attempting to pack my brain with new information. Being 22, it is, I speculate, needless to say that I am the youngest of my coworkers. If there is a piece of software, hardware, a technique, etc., I want to know everything about it. On the contrary, nearly all of my coworkers resent it and refuse to even acknowledge it, let alone learn about it. For example, we just started buying boxes from a different vendor that are licensed for Win7. A few months later, we decide that a computer lab was going to get an XP image instead of Win7. After several days worth of attempts, none of our XP images, even our base, would work, and it left everyone scratching their heads. We were on the verge of returning thousands of dollars worth of machines because they were 'defective.' I was not satisfied. I wanted to know why they weren't working instead of just simply returning them, so I jumped into the project. After almost 30 seconds of fishing around in BIOS, I noticed that UEFI was enabled. Switched it to legacy, and boom; problem solved. My coworkers grunted and moaned because they didn't have to do that before, and still to this day, they hate our new boxes. So in closing, I have three questions: What is the average age of your workplace? How easily do your coworkers accept and absorb new technology? Are most IT environments like this, where people refuse to learn anything about new technology they don't like, or did I just get stuck with a batch of stubborn case-screws?"
Are most IT environments like this? No (Score:4, Interesting)
Whatever, your work place is like, the answer is "No." Different workplaces are different. If your workplace is terrible and you can't make it work for you, leave. But be warned, your new place might be worse, maybe a lot worse.
Re:Good for you. (Score:4, Interesting)
"You're really missing the point. He's not patting himself on the back (much). He's wondering why nobody he works with seems even to want to adapt to changing tech. He KNOWS it was an easy fix, and the fact that nobody else could get it is boggling his brain."
It's not as simple as that. If you've a shop with thousands of workstations deployed and you add another point of failure (simple bios setting in the TFA's example) on PCs that may be deployed for years, you've got yet ANOTHER thing that can go wrong if the bios settings get lost. I'd like to see $help_desk walk someone through changing the bios settings. That machine is going to need a visit from a $pendy tech. And, oh yeah -- update the SOP for new PC deployment and make sure everyone signs off and follows it.
In a SMALL shop, this isn't really a problem. It's not unlikely that there's as many different hardware flavors as there are total PCs. But in a LARGE shop, PC UNIFORMITY saves time and money.
It's enough to justify the groans from his co-workers...
Re:Not just age (Score:3, Interesting)
Anyone who thinks this attitude correlates to being middle-aged and older has never worked in a university computer lab!
Re:Another perspective (Score:5, Interesting)
[...] if you have to touch *every* box to make a change, that's a significant time sink and not a good use of personnel. [...] if the boxes you guys ordered don't work with the setup you want to use, something went wrong.
This is the important part.
It's good that you figured out what was wrong so quickly. Now, which is cheaper for the company: Having you go through 30 boxes today and however many boxes tomorrow and change the settings before they can be imaged with XP or return the 100 boxes to the vendor and have them change them? That depends on the situation--will those machines, in general, be running XP or is it just this lab? Will Windows 7 boot in legacy mode? Which is the best way to go so we don't have to configure each machine we send out separately, which takes valuable and expensive personnel time?
Fun example: My roomate works for a company that makes fishing reels. They have a policy that they will repair issues with their reels for the life of the reel--send in the reel that's dirty and broken and they will fix it or send you a new one. She briefly worked fixing reels, something she really enjoyed. She loved disassembling it and figuring out what was wrong, fixing the problem, reassembling the reel and making it work like new. She was a dedicated worker, coming in and working hard all day fixing reels.
The problem was that when a reel came in, she would set about fixing it. Sometimes she would take the entire day to do so. So the company, paying her $12/hr, spent $96 to repair a reel which cost $50. Sure, the cost in parts to the company was cheap: a penny screw or rubber washer or something like that. Meanwhile, only one reel was fixed that day and there were 9 more waiting to be fixed.
She would complain about her "lazy" co-workers who would "fix" five reels in a day by guessing that fixing it "would be too much work" and would just order them a new one. She would complain about her boss that was on her case about fixing more reels in a day--didn't they understand that tearing these things down and putting them back together took time?! Even when they explained it to her that she was costing the company more money by doing what she was doing, she just couldn't seem to understand that it was sometimes cheaper to send them a new one than to fix the old one and the ability to estimate how much time it would take to fix the reel was an important skill.
Eventually, the company moved her out of fixing reels and put her in a different position where she has excelled.
So the point is that figuring out what was wrong is a good thing. But, in the bigger picture, it might have been more cost-effective for the company to return the computers and get ones that were correctly configured for their needs than paying someone to reconfigure the machines themselves.
Re:It gets old--and so do we (Score:2, Interesting)
This is why the best approach, in my experience, is to nail the fundamentals, which do not change significantly over time. The rest can be looked up as needed or learned (and then discarded) as needed.
Is that as fast as simply knowing what you need to know outright? No, of course not. But it makes you far more adaptable.
Finally, when you learn that something doesn't work, it's important to learn why it doesn't work. Merely that it doesn't isn't terribly useful, because without knowing why it doesn't work, you'll have no means of evaluating whether or not it will work under different circumstances.
Learning without understanding is what I refer to as "cargo cult learning", and is to be avoided. Sadly, a lot of people engage in it, and as a result you wind up with people who are experienced but who lack understanding, and it's important to be able to distinguish between the two when hiring (this is why mere examination of a resume may largely be a waste of time -- there is no substitute for interviewing someone properly, and selecting someone for an interview based on their apparently massive or specific experience can, and often does, yield someone who will ultimately be less successful than would someone who has a solid grasp on the fundamentals but not as much and/or as directly targeted experience. All of which is to say that it's something of a crapshoot as regards resumes).
People make the mistake of buying into the notion that technology "changes quickly". It doesn't. The specific implementations do, but the fundamentals remain just that: fundamental. Understand those well and you'll be pretty much set for life, unless a sea change occurs on your watch (e.g., quantum computing becoming mainstream, and at that point you simply have new fundamentals to learn and master).
Re:Age (Score:5, Interesting)
Excellent topic. I went to work at a startup at 23, and had a similar mentality. I almost got fired on multiple occasions, but the uppers couldn't figure out whether to pat me on the back or get a restraining order. I originally applied to be a Unix administration because "I knew linux!!11" Actually I knew HPUX, and IRIX pretty well too at the time. The hiring manager kind of laughed and said I could work in tech support, and they would evaluate me. After a month in tech support I got tired of not having any documentation so I set upon documenting every damn thing on the planet, and then for good measure I used an open source search engine to make intelligent indexes of the docs, and provide relevant scored results. Sounds great right? Well the owner of the business actually sat on my desk for an afternoon just discussing how awesome it was. His conversation with me that day was longer than any conversation with any engineer or below employee he ever had. I was tickled pink, till the next day when the guy that hired me called me into his office.
He handed me my first write up. I had 1. Installed unauthorized software on company equipment without authorization. 2. Put project level hours into something that wasn't authorized as a project, and 3. unrelated to this I had also installed bash on the sco aquiring server, and compiled vim, gcc, less, and a whole host of tools to make SCO not suck tremendously, and he proceeded to blame the segmentation faults the server had been having weekly since before I was hired on my rogue freeware tools.
Now, at the time I was devestated, and thought he was the biggest douchebag on the planet. After all the owner had loved what I had done, and was pleased as punch, he even said he wished other people took that sort of initiative.
Ten years later, I understand at least a bit where the manager was coming from. They were trying to track down the problems with the server, and had implemented a code freeze, and at the same time everyone in support, and some folks in technology were starting to run bash as their primary shell, and put the path to my OSS utilities in their paths. Since the server was much easier to work in with these tools the server was being put under even MORE load. The project I created shorted everyone in the management chain all the way up out of the kudos, including my manager, his manager, and the guy that hired me. The project manager would have definitely approved the project since he was always griping about documentation, but I took him out of the loop, and made him look stupid when he didn't know the search engine existed when his boss asked about it, and made both of my superiors look like they didn't know what the hell was going on (even if that was the reality). Also the software I installed was on an old junky machine in the corner of the data center, but the problem was that it was on the primary network where PCI data flowed, not a great place security wise to be putting anything like that.
With that being said a week or so later I got promoted out of tech support and in to InsallShield developer(remember them?), and field implementation engineer. In retrospect I think this may have been because my project was too popular to fire me, but management wanted me as far the fuck away from their data center as possible.