The Downside: ...
Systems administrators are rarely customer-facing unless you count as customers the staff that use the systems that you keep humming along.
You consider this a downside? Customer-facing IT Support is an absolutely nightmare. It's part of my job, and by far my least favorite part of the job, as the customer is more often an impediment to solving their problem than an asset.
It depends, of course, on the users. Some of them are angels, some of them are... not very smart regarding technology. ;-) Also, some are just plain mean, at least if they are having a bad day.
At any rate, I much prefer dealing with users to dealing with printers. Printers are evil. I remember the time one of our engineers wanted to print a PDF file, and the result looked superficially the way it was supposed to, except every single letter was incremented by one (so "ABC" became "BCD")... Or the time two printers were configured with the same IP address - due to ARP caching lifetime, every couple of seconds, clients would switch which printer they would send pages to, so print jobs ended up literally being all over the place. ;-)
Printers are the first robots that were mass-produced. It's the first robotics experience most companies get. And we've been buying their learning experiences, because that's been the state of the art of robotic printing.
Interestingly, the hardware side has not given me that much trouble. There were cases of busted drums in laser printers, but compared to the software issues I have seen, the "robot" part usually works remarkably well.
There's a saying about dogs, that one should not be scared of the dogs, but - if at all - of the owners. I guess that kind of applies to printers, too. ;-)
We have a laser printer at work, with an upwards-facing laser (eg, under the drum).
Because of gravity, toner eventually falls onto the laser lens, and causes low-quality prints.
Thus, it has a manually runnable "self-clean" procedure, in which an internal squeegee runs over the lens, cleaning it. For a bit.
If they had made the laser downwards-shooting, it would have avoided this problem altogether. The printer company's service technician, who showed us the self-clean, tells me that this would make the packaging larger, however.
The printer is a gargantuan office printer. (Kyocera TaskALFA 5550ci)
I don't think packaging size for merely the laser should have been a concern...
That is good to know, most of our printers are Kyocera TaskALFA printers, too. They are rather large, indeed.
But like I said, hardware-wise, they haven't given me much trouble (except for a power supply with very slight fault, causing it to make kind of chirping noise every once in a while - it drove our accountants crazy - our field service guy tried replacing the hard drive, the heater, and some other thing (I forget which one), before finding the faulty part). Also, trying to print on paper that is just ever so slightly wet can be... interesting, if one happens to need to print out some one hundred pages. sigh
A couple of years back, when I was still working as a programmer, I was once given the task to write code controlling a specialized printer, the kind used in factories for printing bar codes on things. The printer used a continuous stream of ink that normally went into a tube feeding it back to the ink tank. The ink contained tiny iron particles and went through a magnet that could direct it to the position it should land.
When powering off the printer, the software controlling it had to make sure to first send the command to move the ink-catching tube right up to the nozzle before shutting down the pump, or else the printer would ... kind of soil itself. ;-)
Of course, the first time I tried to actually print something with that printer, I forgot to shut down the printer properly, and it soiled itself in a big way. Specifically, the stream of ink went through a teeny-tiny hole in a small diamond platelet; when I shut down the printer impromperly, ink stuck to that platelet and dried up, so that tiny little hole was no longer perfectly circular. As a result, whenever I tried to print something, the machine would soil itself some more.
After talking to the manufacturer's customer support repeatedly (in their defence, they were friendly, helpful and competent), a support technician told me to remove the platelet from the printer and put it in a bath of MEK (industrial-strength solvent) over the weekend to dissolve the dried remnants of ink (after I had cleaned that platelet manually several times).
The solvent was fairly volatile and highly flammable, so I put it in a small jar, dropped the platelet in the jar and screwed the top on as tightly as I could.
When I came back on Monday, the platelet was indeed clean and gave me no trouble whatsoever after that. The plastic coating covering the inside of the jar's top, however, had "molten" almost completely.
I agree about your description about printers, but I wouldn’t call them “evil”. I’m trying to think of the best word to describe them… haunted? bizarre? chaotic? random? mysterious? No wait, I know; the perfect word is opaque. They do weird stuff and you don’t know why, and you can’t look inside them and find out why. Hmm, now that I’ve come to this conclusion, the answer seems to be the same obvious one that we already have for the similar problem of opaque software and operating systems. Free software, so you can actually look inside and debug the things when your system/printer has found some new way to confound you.
I seem to recall that the original story about how Richard Stallman was inspired to create the concept of free software was that he was stymied by proprietary software in a printer, so this would simply bring the concept back to its roots, so to speak.
The way I read it, the author was saying that it is a problem of recognition: Because you are not customer-facing, you are more invisible in the system and with it comes the lack of job satisfaction one may get from a pat on the back of a job well done via the customer interaction.
Certainly it' s a double-edged sword but that's how I read it at least.
I dunno. The staff when I did internal customer IT treated me like royalty. It helped that I could solve just about anything within minutes rather than hours like the previous guy. It also helped that I enjoyed learning the ins and outs of the software they used. Most of the IT staff did not like to RTFM. But that's IT. It's probably much different for sysadmins though I did a bit of that too.
That is indeed a strange comment, but not for the reason you gave. I’ve only worked as a sysadmin on and off for closer to 20 years rather than 30, but I have only ever had perfectly amiable customer contacts. Even though there have been some of them (there’s always a few) that have been very upset about something that my employer did, I seem to recall many of them apologizing to me for being so upset and saying that they are angry about the situation, and not upset about me. This have happened at many different companies in different fields, both technical and non-technical. I don’t know why people have this experience that “Support is an absolutely nightmare”. I mean, I can believe that people have that experience, I just don’t know why. I can understand someone in general not wanting to talk to people; I am myself somewhat reluctant to talk to people if I don’t actually have to. But I have learned to do it. It’s a bit like driving – some like it, some don’t, but if you need to do it, you learn how to do it and that’s that. (The only thing I have against customer contacts is that being the primary person who answers the phone is distracting when you’re doing other sysadmin stuff.)
No, the reason why that comment is strange is that if I’m a sysadmin, the users who use the systems that I keep running are my customers just as much as customers of the company. Why would you not count them as customers?
Maybe the article author liked having contact with people outside the company, as a sort of social interaction substitute? If that’s the case, I can only say that if I needed social contact that badly, all I needed to do was to go outside after work, where I could socialize on my own terms with people I could choose for myself. But I can only speculate about what the author actually meant by that comment.
Yes, some of us love to solve the problems others are having and make their day. If you're looking for a place where you can do high-level customer-focused technical support and system administration, contact me, we're looking for more good senior admins to do cloud support. My email's in my profile.
I worked as a Unix systems administrator 20 years ago, 15 years ago, 10 years ago, 5 years ago.
20 years ago, in 1995, a tech startup would usually have the programmers do the systems administration, until about four programmers or so had been hired - by then the code would be in shape to put on the Java application server, traffic was picking up, and they needed someone to deal with it full-time, who knew what they were doing. The servers would often be on-site, on the company's T-1 line, or sometimes would be at a colocation facility.
Nowadays, how many people are hired at a tech startup before they hire someone to deal with installing Red Hat on HP rack servers? It can be a while - nowadays if you need 500 servers quickly, and have the money, you can spin them up (and down) on EC2 in a few minutes. Plus there's Linode, Rackspace, Ramnode - I have a personal VPS on each of them. Why not? It's only $10-$20 a month each. It's hard to justify the cost of hiring a sysadmin, a backup person to the sysadmin, pay for colo space, leasing a server etc., when you can get a pretty nice Linode VPS for $10 a month.
> It's hard to justify the cost of hiring a sysadmin, a backup person to the sysadmin, pay for colo space, leasing a server etc., when you can get a pretty nice Linode VPS for $10 a month.
Once you have hundreds or thousands of instances, especially ones with reasonable amounts of resources, the sticker shock starts to make owning and hosting your own servers look pretty tantalizing.
There's a lot to like about IT, but I found plenty to be frustrated about as well.
I spent four years with an IT consultancy piecing together 40 hours working for clients who didn't need a full time IT department. Not having enough hours to transform their operations, running around the city putting out fires, and dealing with old hardware was a bit miserable. Looking around the job market showed a lot more of the same, along with a few high-stress and non-specialized positions working for financial or legal companies. Maybe that's just the scene in New York, I don't know, but the dream of being a company neckbeard did not pan out.
Reading slashdot in the 90s made IT sound amazing, but I've found that geek dream much easier to fulfill in the software industry.
Young whippersnappers. I actually had one of those TEAC reel to reel tape drives, maybe not that exact model---I don't remember it being able to auto-reverse, but I wouldn't have cared about that---but otherwise the same controls. It was a good device for its time, as were the reel to reel 7- and 9-track computer tape drives I used later and concurrently: https://en.wikipedia.org/wiki/9_track_tape
(7 track was the standard for 36 bit PDP-10s, 6 bits of data and one of parity, and some earlier IBM machines as well.)
The above describes a typical transport system; however, manufacturers engineered many alternative designs. For example, some designs used a horizontal transport deck where the operator simply set the tape reel in the supply reel bay, closed the door and pressed the load button, then a vacuum system would draw the tape along the path and onto a take-up hub within the mechanism.
Back in the day, I used a 9-track tape drive like this. It was quite the thing to watch it mount the tape. A while ago I found a video of it[0].
It always fascinates me about how things were being doing,back then, with respect to programming languages and system admin.Back then,there was no such things as ansible,chef,puppet,Docker and stuff.Still,System admins were about to get things done.Pretty interesting.
The job of sysadmin is to recognize how systems have been designed, based on which first principles and what are the alternatives. This is how one ends up with Postgres instead MySQL (or Informix instead of Oracle) with Scala instead of Ruby (because you do understand principles Scala is based upon), with Erlang instead of Java (you do understand the differences and principles),etc. Basically, sysadmin is a system (or service) designer and architect.
Nowadays the term sysadmin is used to describe a job of issuing memorized commands to AWS or some "containers" without any deep understanding of what dynamic linking is, what is libraries and API visioning, how to compile from sources and run several versions of some sets of libs, how to recompile a source package disabling unnecessary features, and so on. This is the same nonsense as to call an auto-mechanic an engineer. Most of moderns sysadmins does not know what the ./configure; make; make install sequence or a syntax of Makefiles or how the mess they called cmake works. (how many here knows how to write RPM's spec?))
Old school sysadmins are engineers, not mechanics. They do understand access patterns, data-structures, memory allocation techniques, what are shortcomings of posix threads and its naive usage, and, of course, programming paradigms, so they could reason (more objectively than managers or other laymen) about behavior of a system.
They think that running a Hadoop on AWS (from ready images) is a big deal.
btw, in my 20 years of being sysadmin (since SCO Open Server and FreeBSD 2.0) everything worked.
Your description of a sysadmin sounds much more like the role of an architect.
btw, in my 23 years of being a help desk tech, sysadmin, architect, consultant, manager, and finally owner of my own business, nothing has ever just worked.
You consider this a downside? Customer-facing IT Support is an absolutely nightmare. It's part of my job, and by far my least favorite part of the job, as the customer is more often an impediment to solving their problem than an asset.