81–88 of 88 posts
Moral of the story (and very applicable to individual HN members): don't be a cost center.
IT is a cost centre. there's no way around that. telling IT not to be a cost centre is like telling building operations not to be a cost centre.
Earlier quoted context omitted.
I'm also a programmer, and agree completely - I think devs should have admin rights on their boxes, and at the very least access to VMs for testing Ultimately, it's an issue of trade-offs: I guarantee that since you're allowed to go wild on your machine, the IT cost to support devs is higher. It's not right or wrong, simply a matter of trade-offs. It's up to an individual organization to determine an acceptable trade…
I think devs should have admin rights on their boxes I no longer support dev desktops, but I do admin the systems they use - servers, databases. I'm cool with what you say in principle. If we're talking your own desktop, sure, no problem. As long as you're responsible for cleaning up your own mess. But root on 'my' dev servers - no way, Jose. Those guys don't know unix, don't know what they're doing with root. They g…
A lot of my problems with IT departments would be solved if the IT folks recognized that people with degrees in computer engineering and computer science tend to be able to take care of their own machines. Also, if they would quit telling me that I can't run VLC because it's not secure, when they have 3 year old versions of the Java Runtime Environment installed on everyone's PC.
Earlier quoted context omitted.
Let's see.... The skills you need to do IT aren't something you can really learn in school in any way shape or form. These include customer service skills, understanding the needs of a business intimately and learning how real business are run. The people that are passionate about doing IT in that context are far and few between. Since it's seen as a service job, it forces a lot of people into other disciplines after…
Some excellent points I hadn't mentioned in my reply in this thread. People often forget that keeping things up is a constant battle. Your opening paragraph says it all though. When developers talk about how difficult programming is, I always explain IT like this: "Imagine you have N sections of code you have to support that someone else has written. They may/may not be documented, whatever documentation you have may…
"You know the 30-60 minute spin-up time it takes to get your head into coding? Well imagine someone interrupting you every 15 minutes to ask you how to insert a table into MS Word (I'm sorry, didn't your fucking CV say you had MS Office experience?). Now imagine how long your replies would remain welcoming and friendly."
Earlier quoted context omitted.
Technical skill isn't that important for front line staff. Most IT shops will have a bunch of $10/hr types handling "how do I fix this excel formula?" questions. And they have a phone number for the big guns when they need it. Please don't interrogate people who probably know they are relatively unskilled. It's like talking about weightloss to someone who already knows they are fat. The $150/hr techs you will rarely…
"The $150/hr techs you will rarely see are super nice, and would absolutely love a problem they haven't seen before" This is kind of what I was trying to get at. The guys who know their shit, relish a challenge.
the simplest reason that everybody hates the IT department is because there's such a huge competency disparity. during the average workday, the people you interact with during the course of your duties will be roughly at the same competency level as you, and you can talk to each other as roughly equals even across vastly different fields. The IT guy, however, could be at the complete opposite end of the spectrum (eit…
he resents you (for good reason) Disagreed, IT should not be given a pass to resent people just because they don't understand and have as much time and training with computers. Nor do I agree that the IT person will be the smartest person in the room. Everyone has their own set of skills that they are good at. Put the IT guy in sales, if he fails miserably what good are his technical smarts? If it's the role of the I…
There are three big problems with IT departments (IMHO): 1. Anyone who is sufficiently skilled to be good at his or her job in the IT department is almost certainly overqualified so the system self-selects out good people; and 2. Like any other support role people only tend to notice you when things go wrong; and 3. My general experience with DBAs, sysadmins, techs and the like is that they generally resent you for a…
> My general experience with DBAs, sysadmins, techs and the like is that they generally resent you for asking them to do things, making the entire experience unpleasant. I'm not sure if such people are attracted to such positions or such positions end up making such people but whatever the case, "surly" is a commonly appropriate adjective to use.
I've spent 15 years working in a variety of positions in IT, from tech support, to developer, to sysadmin, to supervisor, to architect/design engineer. My experience with DBAs and sysadmins is that they rarely resent you for asking them to do things. However, they may very well resent the way you ask them to do things.
Much of modern society is very me-focused, impatient, and with short attention spans. This goes double for the corporate business world. When many people run into a technical problem, they tend to want an immediate response and an immediate resolution to their problem, expecting everyone else to drop everything and attend to them. Their problem affects them, therefore it is the most important problem around right now.
What they fail to appreciate and understand, is that many DBAs and SysAdmins are supporting systems and infrastructure that has importance much greater than you. Yes, you have a problem, and yes, they want to help you. But they have visibility into things with potentially much greater impact than you, and those things may have a higher priority and importance than your problem.
An example I saw just a few weeks ago. I had a problem that needed attention from a sysadmin. I went to the guy who could fix it, and there was someone already at his desk. I waited outside his cube, and listened to the guy already there bitch at him. Apparently the guy had an application that was having issues, and he couldn't work on his report until the application was fixed. He wanted the sysadmin to drop everything to fix it, and he wasn't happy at being told that the sysadmin was busy with something else, and couldn't help him until it was fixed.
After yelling guy finally left, I ducked my head in and asked him if something was blowing up. He nodded distractedly and said that the server a PostgreSQL database ran on was misbehaving, and that the DB was utilized by an application used by 3 different business units and dozens of people. I offered my sympathy, told him I needed his help, but it could obviously wait until he fixed this problem, and said I'd e-mail him the details.
He thanked me for being understanding (twice), and called me as soon as he'd fixed the server issue to help me out.
> The cliche of the bearded UNIX purist exists for a reason.
I'm afraid you're going to have to explain the reason for this one. The bitchiest guy I know at work is clean shaven, and the nicest guy I know has a full beard. Exactly what reason is there behind your negative beard perception? ;-)
Earlier quoted context omitted.
I think devs should have admin rights on their boxes I no longer support dev desktops, but I do admin the systems they use - servers, databases. I'm cool with what you say in principle. If we're talking your own desktop, sure, no problem. As long as you're responsible for cleaning up your own mess. But root on 'my' dev servers - no way, Jose. Those guys don't know unix, don't know what they're doing with root. They g…
That's why I preach VMs. They can go wild on those - just teach them how to create and revert to snapshots. They'll love you forever :)
One problem with VMs is they would not work very well with the dev environments I support: JDE and ancillary applications.