Hacker News Reader

Comment by aschearer | Hacker News Reader

> It's important to keep in mind that most of us sit not far from the middle of the bell curve. Most people are, by mathematical definition, close to average, as skill distribution is not from Taleb’s Extremistan.

Is this true? Why should I believe it? Certainly unclear to my sub-average brain why it's a "mathematical definition." I'd call it an empirical fact, but has anyone bothered to measure? Logically speaking, the curve's hump could be biased one direction or the other, or bi-modal, or whatever else...

Also unclear to me why it follows that "top of the curve" people can't explain things to their lessors. Sure some may not possess that skill, but you're telling me there aren't good teachers/tutorials out there? My brain's too soft, so pack it up? Seems presumptious.

Anyway the message of "know yourself and your limitations" is fine and well.

PS. Thanks for noticing I'm a tad above average, statistically speaking!

View on HN

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.

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 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.

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 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.

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.

Reply on news.ycombinator.com