Great point, I could totally see the "skill of an IT person" being skewed towards the majority being "bad" and a few being "good". If nothing else, simply due to the fact that there are fewer people with more years of experience

After reading this article, is it strange that I've always considered "IT" a separate discipline from "software development/engineering" ? In these parts, the connotation of "being in IT" means you're managing networks, servers, fixing people's email, etc.

I think you're right, depending on how you define "IT".

The operational part of IT wants zero change and high levels of predicability to maintain reliability. It thinks long term.

The development part of IT wants to add features and functionality to satisfy business requirements, which means lots of changes. It's forced to think shorter term.

We still lump these two disparate parts together. I wonder if having the operational part report to the COO, and the development part report to a CIO (who ideally is a peer of the COO), would work better. I've seen a lot of organizations, but never seen this organizational structure.

This is why DevOps became so popular: throw the two types of people in one team and make them responsible for the whole lifecycle of the products they develop and maintain. Report to whomever requires those products.

I don't think so, that's the connotation I usually see. I've always found that dichotomy rather odd though; I work in systems design/administration and I think a lot of common development mistakes could be avoided if devs had more extensive support experience.

I frequently see line-of-business software that's likely self-explanatory for a 20-something developer, but that's nearly incomprehensible for the target audience. In terms of basic computer literacy, most developers are far above average.

For example, a friend of mine had to teach his elderly coworker at a machine shop about copy/paste. Not the keyboard shortcuts, not how to do it, literally the concept of the system clipboard. He had learned computing on DOS, and had learned everything since by rote memorization.

That's a rather extreme example, admittedly, but it does illustrate just how unpredictable the skill level of end users is. Even a minor UI redesign can throw off someone like that for weeks, and I don't think most devs fully appreciate that.

I think this is a cultural distinction that depends on where you are. I have seen many Europeans group both engineering and “operations” stuff like help desk into IT. Whereas in the US we limit IT to only operations and in practice may also exclude highly technical operations like SRE or devops from the “IT” bucket.

I see it as like distinguishing the engineers that design cars from the mechanics that help people with their cars. The distinction blurs when your “mechanics” are operating on bespoke and highly complicated machinery that may have maintenance that includes extensive engineering knowledge (like race cars, or large backend production systems) or requires the operations to be done by the same engineers that created it. But being an IT person that specializes in printers, or internal networks, or Windows configuration and policies is more firmly in the “mechanics” area. Which is not to devalue their skills as setting up a big network can be very complicated and difficult; just as being a mechanic on something like a nuclear submarine is also probably pretty complicated and difficult.

It all really depends on your definition of IT person.

Some IT Helpdesk people are most definitely not IT, they just have a knowledge base they look things up, assuming they can' understand what you are saying.

Many companies offshore this to places like Jakarta, and you are left with really dismal service many times, and non-existent escalation paths almost guaranteeing corporate escalation for important issues.

Nassim Taleb has a great bit on it: characteristics of "natural" systems tend to settle on gaussian distribution on a long enough time frame. Weight, life span, force, height, skills... On the other end, systems that we have created have metrics that tend to not follow the normal law: money, electricity consumption, size of houses, etc.

It's not a perfect match and I'm not trying to write a white paper on anything. It's just a way to warm up the reader to the essay point.