Jim Ankenbrandt wrote:
I would agree with this. From my experience programmers want to try new things use new functionality. Most experienced sysadmins "fear" new things. If you are answerable to others for their team's productivity there is a tendency to be conservative rather then break new ground. That responsibility begins to make you try to keep the most people happy and productive as you can. And that is the mark of a good sysadmin On 1/30/08, Christophe Kalt <sage-members@xxxxxxxxxxxxxxx> wrote:i think the problem is more of clear job responsability. Either you're a programmer, or a sysadmin. People who are trying to be both usually think of one of their responsability as primary, and the other one suffers from this. I think that most of what you've seen are probably cases of programmers having to do some SA work because they have the skills and someone need to get the job done.
Lot of commentary. I'm responding in general to a number of things said along the thread.pigeon holing, bell curve, . . . . This is an issue in many aspects of society and life. We take short cuts and trust gut reactions. There may be some substance in some generalizations; but, when we actually have to make a decision based on them, such as hiring, it's best to look beyond the generalization. In some instances (although most probably not the one under discussion here) it might even become a legal concern. To make the best decisions in hiring, we need to look beyond the generalizations and carefully examine each applicant as an individual. Yeah, I know, in the 1990's we advertised job openings and got maybe 20 applicants. After the bubble burst, the same job opening would get 200 applicants. Still, best to beware of generalizations.
once someone is hired, clear job responsibilities are very important. Hire someone as a programmer and then ask them, by the way, to also be sysadmin for your network of servers -- now you're just asking for trouble. In such cases it is the hiring manager who is at fault. If the sysadmin responsibilities are considered important, then hire someone to do them. If not, then don't complain.
I worked for Specular for a few years (Infini-D 3D modeling software on the Mac). They had some of the hottest programmers around. I had been a programmer, but I was hired to handle their customer database, backups, network, etc. My job was to support the programmers and the rest of the company. Previously, their chief programmer was responsible for the network and backups. It was a total mess. He was absolutely brilliant, and could certainly have done a good job of it; but it was far more important to the livelihood of the company that he focus his attention on the programming. When they got big enough that it made sense, they hired me.
knowledge, attention, focus . . . . I think it is important for real programmers to know how hardware works -- to have some idea of how cpu, memory, i/o channels, etc. interconnect and communicate. Too many programmers today write bloated and inefficient code, at least in part because they have no clue or respect for what their code is going to do in terms of demand on hardware resources. Serious programmers ought to at least spend some time playing in machine code or assembler. Back in the bad old days programmers could write time sharing operating systems that could serve 200 simultaneous users out of 16K core memory. They had to understand the hardware. OK, they didn't have GUIs, they didn't process jpegs, and etc. But, still, depth of knowledge and understanding is almost always beneficial.
Going back to Specular, one of the seemingly inexplicable hires (initially) was a young woman from Taiwan. She could program, but some of the programmers weren't impressed. Turns out she was an absolute wiz at mathematics and projective geometry. When she looked at the code, she wasn't seeing the code structure the way the other programmers did, she was extracting the mathematical algorithms being used. Change the algorithm, put it back in, and magically, the code ran twice as fast, or even better.
Bringing that back around to sysadmins, understanding programming and software development as well as hardware is almost always beneficial. It can make the difference between seeing your way through a problem to a relatively quick, concise solution that's stable, versus thrashing your way through to a messy hack that seems to be working, but you don't really have much of a clue what's going on.
So, back to the hiring question. Pick the person with the best depth of knowledge, the willingness and interest to take the job with the specified responsibilities, and who seems to have good attention and focus. Give them clearly defined responsibilities. One of the best hires we made (in a previous job) was a guy who had been a Unix software developer and C programmer. As his company shifted toward Windows, he managed the conversion of the Unix software to run on Windows. The ownership of the company had changed, he was unhappy with how they were managing it (post bubble burst), and he wanted something more stable with better benefits to support his family. We felt incredibly lucky to have the opportunity to hire him. He came in as a Windows sysadmin and was immediately solving longstanding problems. Been happily on the job for maybe 5 years now.
--------------- Chris Hoogendyk - O__ ---- Systems Administrator c/ /'_ --- Biology & Geology Departments (*) \(*) -- 140 Morrill Science Center~~~~~~~~~~ - University of Massachusetts, Amherst
<hoogendyk@xxxxxxxxxxxxx>---------------
Erdös 4