7 ms·

The curse of being good in IT

61 points by BiteCode_dev 4y ago

aschearer 4y ago
> 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!
- batmansmom1 4y ago
  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
  - icedchai 4y ago
    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.
    - nickt 4y ago
      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.
      - jochem9 4y ago
        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.
    - deceptionatd 4y ago
      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.
    - opportune 4y ago
      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.
  - than3 4y ago
    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.
- BiteCode_dev 4y ago
  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.
hot_gril 4y ago
What taught me the most about this was managing my parents' home internet from a distance. If it went out, they could hardly even communicate with me to fix it. I quickly learned just how many things can go wrong with Ubiquiti wifi APs or other more advanced tools sitting there. The final working setup: Basic ISP-provided modem/router/wifi combo, cheap near-zero-config wifi APs to reach distant rooms, entire setup on a lamp timer to cut power for 30min a day at 4AM. The thing is, that solution is decent even if you understand the more advanced stuff. Now at work I see how many SWEs are, in a way, too smart for their own good. I keep telling them, make your solutions less galaxy-brained. No you are not making another custom DBMS-type thing just to serve a few kinds of requests from adjacent systems. If random other people can't understand it, it'll get rewritten in 2 years tops.
- namaria 4y ago
  I'm a big fan of straight out of the box solutions. I make a point of starting projects often and from a clean slate and learning to use the tools in their default config. If defaults aren't good, change tooling. Customization is super fun but it's just another layer of complexity at the end of the day. I love that fresh VM smell...
  - Gigachad 4y ago
    Every time people say that you need to first install 30 pluggins before you can use gnome I just think “uh no, you don’t. It works just fine out of the box.” Rather than turning a bunch of preferences and habits in to hard requirements, I prefer to just go with the flow. If the gnome design team says workspaces are now horizontal instead of vertical, I just go with it instead of building a plug-in or fork to turn them vertical again. Same with Apple products, they are designed well, so just go with it.
    - deleted 4y ago
      [deleted]
    - BeFlatXIII 4y ago
      I'd trust Apple's design changes over Gnome's.
rektide 4y ago
The topic of information disparity is highly interesting to me. Knowledge workers in general have very interesting challenge relating to other workers at different expertise levels, & to others in the org. Each person is somewhat rather isolated in their own knowledge domain & that is the highest loss transmission medium I can think of. I think there's a lot good points for consideration in this article. It mainly favors a KISS approach. Reciprocally, I hate to say it, but I also feel like there's an overly compulsive YAGNI behavior (you ain't gonna need it). Developers are drawn like hawks to a possible whiff of over complexity, & will descend for the kill. Ambition is talked down & avoided by many voices in most orgs, even when the plans can be quite sound. What can be really sad is that some devs will convince themselves of doing all kinds of absurd highly compromised labor that they know is a better choice than a slightly more adventurous route that requires some discovery & exploration of known unknowns. The last principle engineer we had kept demanding to make Api calls for a migration because they didnt feel very comfortable with sql, but my heavens the work we went through to do the job thousands of times slower to bend to that was staggering. People will tool away doing things poorly, slowly, repetitively, glued to the safe path, and not advancing. Becoming a really great developer is hanging in the balance, between letting yourself spiral & lose traction/understanding/focus/being-overwhelmed, and between being relentlessly curious & hungry to learn all the options, how each option works. Finding stuff out is the job, at least as much as doing the work, but training ourselves towards initiative is the hardest practice of all. There's plenty of other ways to be a very fine developer too. Not everyone has to sign up to contort themselves, to a predisposition of being always staying slightly uncomfortable. But those that can start to lean in & appreciate the endless possible quest-opportunities about us, & who can latch on & dive deep on an option, courageously go find out and see: those folks tend to do very very well. (If placed in an environment where this let's say "ideal" behavior isnt resisted by the org.) It's an amazing life.
- physicles 4y ago
  > Developers are drawn like hawks to a possible whiff of over complexity In my experience, juniors tend to pick solutions without considering complexity and people factors — at least, I did. There’s a very good reason to avoid over-complexity: if you have too much of it, it kills your velocity. > to a predisposition of being always staying slightly uncomfortable I love that feeling of always moving forward. Tech that you didn’t know about a year ago, is now part of your normal workflow. That feeling when you start exploring something totally new and it takes a week to get comfortable with hello world, and a month (or years) to learn exactly where it should fit and what the sharp edges are.
davidgerard 4y ago
This makes a simple point I've needed to hear for the past thirty years. Thank you. I was just saying today how realising you have absolutely no idea what you're doing is a prerequisite for competence in tech, and you need to watch out for the ones who don't realise that. "I know only that I too am a dumbass," as Socrates said.
charlie0 4y ago
Man, this article hit me hard. Years ago I wanted to blog about more complex subjects to a beginner audience. As I built my mini blog series, I started to realize there was so much to explain. It took me much longer than I thought to write it. I decided it was way too much work and decided to never write tutorials again. Kudos to those who do.
- than3 4y ago
  Well that is a very common trap with writing, not choosing an appropriate audience for what you are writing about will send you down a rabbit hole. There are some things you simply cannot explain to a beginner audience because they lack the fundamental context for comprehension. Some may ask questions, and give it a good go, but really without that context its an unproductive use of both parties time. Some will misunderstand this as being a gatekeeper but it really has nothing to do with that. Its a problem you only really accept and learn through experience.
faeriechangling 4y ago
This hits home quite hard. I get depressed sometimes working on teams where I'm the most technically proficient on the team and I want to solve a problem in a way which will save everybody not just a little time, but probably save us enough time that we could remove one or two staff. But then I remember how I got the skills to do such things. Hours of work a day for years at work. Hours of interest a way in my personal life. I did that for decades and I had a natural knack for such things. So it turns out the solutions I build would fall apart without me holding them together. As soon as I leave whatever I make will be thrown out. I'm not good enough to unilaterally make so tools that they are easily maintainable, debuggable, extendable, and so on by just anybody you hire off the street. The more I understand how to reconcile these problems, the more I understand managers and architects.
asdfman123 4y ago
Often the people who are worse than average are giving all the online advice. You often comment on the internet about things you want to learn more about. When you gain experience, you get tired of answering the same beginner questions over and over again, so you go somewhere else.
than3 4y ago
In all fairness, to me this reads as more of a rant man-splation for why thing's aren't productive, and largely misses the point. Its also fairly niche and specific to developers that have a very developer-only mindset. Anyone who has spent time and designed systems with the bare-minimum feature sets needed to make operations supportable understands that most of the examples provided are very brittle, and purely opinion with little backing them. Its an overbroad generalization with a poorly thought through hypothesis that doesn't really match observations I've seen. I've worked as a System Admin and System's Engineer over the years, most of the issues are solved when you follow good documentation practices. If you aren't generating documentation in a way that others can read and understand, you simply aren't doing your job. A proper IT Operations team understands this, the developers in general that I've met seem to think these rules don't apply to them, this includes the supervisors managing the business unit, and then they raise holy hell when SHTF like it wasn't a completely predictable outcome. There are exceptions but they are just that, 'exceptions'. Average people should be able to read, and comprehend documentation needed for their position. If you can't do that, you aren't doing your job and deserve to be fired for misleading business about your skill set. If you don't have good documentation for an existing system, you need to generate that first before you can really do anything new, its deferred maintenance that needs to be paid. Its impossible to put any reasonably accurate scope of work together if you have no documentation on a system, and only generalized requirements. Documentation is often a critical part of the initial requirement scope/process (before any work gets done). You skip this phase, and you are tacitly approving a project that either will never complete, or will complete egregiously over budget.
- BiteCode_dev 4y ago
  You are a great example of the too good to be helpful crowd. "Things should have a good doc and you should read it". I could not have come up with a better example in the article. This is just perfect :)
  - than3 4y ago
    Honestly, based off what you said, in my opinion you clearly lack credibility. The very least you could do is properly quote what I actually said instead of poorly paraphrasing, and then holding that paraphrase up as an example (with a different context). That's no better than putting words in other peoples mouths, its just flawed reasoning, and the tactic comes off as plainly manipulative and biased. If you read and comprehended what I said, and knew what good documentation practices are, you'd agree if you had the experience. Every single time I've seen a developer say differently and get their way, its resulted in project cost overruns by integer scaling factors greater than 1, many times in the double digits, assuming the project even completed (some don't). Availability of good documentation on existing systems makes and breaks project budgets. I really don't see how you can reasonably think this is a good example, let alone a great example. You of course are free to think what you want. Fundamentals are covered in Chapter 31 of the Limoncelli books (TPOSA) covers the broad strokes, and Redhat Documentation pre-IBM takeover are examples of good end-product from proper documentation practices.
BiteCode_dev 4y ago
As usual late to the party, but author here. AMA and all that.

61 points by BiteCode_dev 4y ago

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

batmansmom1 4y ago
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
- icedchai 4y ago
  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.
  - nickt 4y ago
    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.
    - jochem9 4y ago
      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.
  - deceptionatd 4y ago
    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.
  - opportune 4y ago
    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.
- than3 4y ago
  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.
BiteCode_dev 4y ago
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.

hot_gril 4y ago

What taught me the most about this was managing my parents' home internet from a distance. If it went out, they could hardly even communicate with me to fix it. I quickly learned just how many things can go wrong with Ubiquiti wifi APs or other more advanced tools sitting there. The final working setup: Basic ISP-provided modem/router/wifi combo, cheap near-zero-config wifi APs to reach distant rooms, entire setup on a lamp timer to cut power for 30min a day at 4AM. The thing is, that solution is decent even if you understand the more advanced stuff. Now at work I see how many SWEs are, in a way, too smart for their own good. I keep telling them, make your solutions less galaxy-brained. No you are not making another custom DBMS-type thing just to serve a few kinds of requests from adjacent systems. If random other people can't understand it, it'll get rewritten in 2 years tops.

namaria 4y ago
I'm a big fan of straight out of the box solutions. I make a point of starting projects often and from a clean slate and learning to use the tools in their default config. If defaults aren't good, change tooling. Customization is super fun but it's just another layer of complexity at the end of the day. I love that fresh VM smell...
- Gigachad 4y ago
  Every time people say that you need to first install 30 pluggins before you can use gnome I just think “uh no, you don’t. It works just fine out of the box.” Rather than turning a bunch of preferences and habits in to hard requirements, I prefer to just go with the flow. If the gnome design team says workspaces are now horizontal instead of vertical, I just go with it instead of building a plug-in or fork to turn them vertical again. Same with Apple products, they are designed well, so just go with it.
  - deleted 4y ago
    [deleted]
  - BeFlatXIII 4y ago
    I'd trust Apple's design changes over Gnome's.

rektide 4y ago

The topic of information disparity is highly interesting to me. Knowledge workers in general have very interesting challenge relating to other workers at different expertise levels, & to others in the org. Each person is somewhat rather isolated in their own knowledge domain & that is the highest loss transmission medium I can think of. I think there's a lot good points for consideration in this article. It mainly favors a KISS approach. Reciprocally, I hate to say it, but I also feel like there's an overly compulsive YAGNI behavior (you ain't gonna need it). Developers are drawn like hawks to a possible whiff of over complexity, & will descend for the kill. Ambition is talked down & avoided by many voices in most orgs, even when the plans can be quite sound. What can be really sad is that some devs will convince themselves of doing all kinds of absurd highly compromised labor that they know is a better choice than a slightly more adventurous route that requires some discovery & exploration of known unknowns. The last principle engineer we had kept demanding to make Api calls for a migration because they didnt feel very comfortable with sql, but my heavens the work we went through to do the job thousands of times slower to bend to that was staggering. People will tool away doing things poorly, slowly, repetitively, glued to the safe path, and not advancing. Becoming a really great developer is hanging in the balance, between letting yourself spiral & lose traction/understanding/focus/being-overwhelmed, and between being relentlessly curious & hungry to learn all the options, how each option works. Finding stuff out is the job, at least as much as doing the work, but training ourselves towards initiative is the hardest practice of all. There's plenty of other ways to be a very fine developer too. Not everyone has to sign up to contort themselves, to a predisposition of being always staying slightly uncomfortable. But those that can start to lean in & appreciate the endless possible quest-opportunities about us, & who can latch on & dive deep on an option, courageously go find out and see: those folks tend to do very very well. (If placed in an environment where this let's say "ideal" behavior isnt resisted by the org.) It's an amazing life.

physicles 4y ago
> Developers are drawn like hawks to a possible whiff of over complexity In my experience, juniors tend to pick solutions without considering complexity and people factors — at least, I did. There’s a very good reason to avoid over-complexity: if you have too much of it, it kills your velocity. > to a predisposition of being always staying slightly uncomfortable I love that feeling of always moving forward. Tech that you didn’t know about a year ago, is now part of your normal workflow. That feeling when you start exploring something totally new and it takes a week to get comfortable with hello world, and a month (or years) to learn exactly where it should fit and what the sharp edges are.

davidgerard 4y ago

This makes a simple point I've needed to hear for the past thirty years. Thank you. I was just saying today how realising you have absolutely no idea what you're doing is a prerequisite for competence in tech, and you need to watch out for the ones who don't realise that. "I know only that I too am a dumbass," as Socrates said.

charlie0 4y ago

Man, this article hit me hard. Years ago I wanted to blog about more complex subjects to a beginner audience. As I built my mini blog series, I started to realize there was so much to explain. It took me much longer than I thought to write it. I decided it was way too much work and decided to never write tutorials again. Kudos to those who do.

than3 4y ago
Well that is a very common trap with writing, not choosing an appropriate audience for what you are writing about will send you down a rabbit hole. There are some things you simply cannot explain to a beginner audience because they lack the fundamental context for comprehension. Some may ask questions, and give it a good go, but really without that context its an unproductive use of both parties time. Some will misunderstand this as being a gatekeeper but it really has nothing to do with that. Its a problem you only really accept and learn through experience.

faeriechangling 4y ago

This hits home quite hard. I get depressed sometimes working on teams where I'm the most technically proficient on the team and I want to solve a problem in a way which will save everybody not just a little time, but probably save us enough time that we could remove one or two staff. But then I remember how I got the skills to do such things. Hours of work a day for years at work. Hours of interest a way in my personal life. I did that for decades and I had a natural knack for such things. So it turns out the solutions I build would fall apart without me holding them together. As soon as I leave whatever I make will be thrown out. I'm not good enough to unilaterally make so tools that they are easily maintainable, debuggable, extendable, and so on by just anybody you hire off the street. The more I understand how to reconcile these problems, the more I understand managers and architects.

asdfman123 4y ago

Often the people who are worse than average are giving all the online advice. You often comment on the internet about things you want to learn more about. When you gain experience, you get tired of answering the same beginner questions over and over again, so you go somewhere else.

than3 4y ago

In all fairness, to me this reads as more of a rant man-splation for why thing's aren't productive, and largely misses the point. Its also fairly niche and specific to developers that have a very developer-only mindset. Anyone who has spent time and designed systems with the bare-minimum feature sets needed to make operations supportable understands that most of the examples provided are very brittle, and purely opinion with little backing them. Its an overbroad generalization with a poorly thought through hypothesis that doesn't really match observations I've seen. I've worked as a System Admin and System's Engineer over the years, most of the issues are solved when you follow good documentation practices. If you aren't generating documentation in a way that others can read and understand, you simply aren't doing your job. A proper IT Operations team understands this, the developers in general that I've met seem to think these rules don't apply to them, this includes the supervisors managing the business unit, and then they raise holy hell when SHTF like it wasn't a completely predictable outcome. There are exceptions but they are just that, 'exceptions'. Average people should be able to read, and comprehend documentation needed for their position. If you can't do that, you aren't doing your job and deserve to be fired for misleading business about your skill set. If you don't have good documentation for an existing system, you need to generate that first before you can really do anything new, its deferred maintenance that needs to be paid. Its impossible to put any reasonably accurate scope of work together if you have no documentation on a system, and only generalized requirements. Documentation is often a critical part of the initial requirement scope/process (before any work gets done). You skip this phase, and you are tacitly approving a project that either will never complete, or will complete egregiously over budget.

BiteCode_dev 4y ago
You are a great example of the too good to be helpful crowd. "Things should have a good doc and you should read it". I could not have come up with a better example in the article. This is just perfect :)
- than3 4y ago
  Honestly, based off what you said, in my opinion you clearly lack credibility. The very least you could do is properly quote what I actually said instead of poorly paraphrasing, and then holding that paraphrase up as an example (with a different context). That's no better than putting words in other peoples mouths, its just flawed reasoning, and the tactic comes off as plainly manipulative and biased. If you read and comprehended what I said, and knew what good documentation practices are, you'd agree if you had the experience. Every single time I've seen a developer say differently and get their way, its resulted in project cost overruns by integer scaling factors greater than 1, many times in the double digits, assuming the project even completed (some don't). Availability of good documentation on existing systems makes and breaks project budgets. I really don't see how you can reasonably think this is a good example, let alone a great example. You of course are free to think what you want. Fundamentals are covered in Chapter 31 of the Limoncelli books (TPOSA) covers the broad strokes, and Redhat Documentation pre-IBM takeover are examples of good end-product from proper documentation practices.

BiteCode_dev 4y ago

As usual late to the party, but author here. AMA and all that.