After college, I lived with a friend who worked in the IT department at our college. He got called in on a Sunday once, and came back around lunchtime quite flustered.
"What's wrong?"
"Sam asked me what a traceroute was."
Sam was the longtime Novell admin. Yes this was a while ago...
"The worst part was, I patiently explained it to him, and he just asked me why that was useful?"
Just one example. There was more, of people of low competence who were very entrenched.
I'm a 'technician' in a company full of 'scientists', and I can say without question, the scientists need help, the technicians need knowledge, and neither of the two realms can really survive without the other.
Sometimes you need the guy who has burned his fingers repairing things, over and over, to review your design - he's going to tell you why you are going to burn your fingers. Other times, the guy doing things in a semi-glib fashion, needs to be pulled off the production line and enlightened as to why things have to be done a certain way.
To consider this relationship hierarchical is to weaponise the subject - instead, these are key relationships. A single great scientist with 2 or 3 good technicians can build amazing products.
3 scientists with no technician, rarely ever do .. but there is of course the odd exception where a technician, by making something really great, becomes a scientist, too - and scientists, without technicians and therefore having to get their fingers toasty, often make amazing technicians. (This is why the hierarchical subjugation of the subject must be resisted.)
Related:
The Wetware Crisis: the Dead Sea effect (2008) - https://news.ycombinator.com/item?id=23166786 - May 2020 (127 comments)
The Wetware Crisis: The Dead Sea Effect - https://news.ycombinator.com/item?id=22376468 - Feb 2020 (2 comments)
Internet Blogger A: "I'm super talented. Who are all these no-talent losers in every $BigCorp department I end up in? They take steps to entrench themselves and have no interest in innovating. The high talent people have more options and move on. Why can't I find a high-functioning place to work at?"
Internet Blogger B: "What is wrong with hiring process? We keep getting these clueless noobs showing up. They mess up every time we ask them to maintain prod. All they want to do is some random resume-driven development and then leave us with all the problems. Why can't we hire some real software engineers for once?"
I've job hopped a lot over the years and now i make about 30x what i did at my first software job. Now I'm sticking around though despite some of the craziness that i'd prefer not to deal with mostly just to prove to myself i can stick around at a job for more than 2 years.
> The IT hiring process is broken. Amen. Not only is the IT hiring process broken in many organizations, the entire approach to IT is often broken. (...), Ruby Raley and I wrote an article for Cutter IT Journal that stated that an approach modeled after professional sport teams could well be far more effective, but no one has yet hired me to try it out.
Does this approach also apply to age? E.g., older programmers either take some higher-ranking position (management, product owner etc) or they get replaced?
[2008]
TL;DR: more talented people tend to move on to more lucrative gigs, leaving less talented people behind. The title draws an analogy to the Dead Sea, where water evaporates and leaves salt behind.
Really, that's all the article has to say. You're welcome.
It's thinkpieces like this that make me believe that IT professionals specifically and white collar workers generally would benefit greatly from a mandatory 24 month stint on a construction crew. One of the most important lessons any job foreman can learn is that every crew needs at least one lame duck.
A single talented carpenter with an energetic but otherwise totally unskilled helper can accomplish more in a shift than two talented carpenters together. If you don't have someone to run to the truck for nails, hold shit, move ladders, etc. productivity suffers because your talent is wasting time on menial tasks.
Same thing applies to IT departments. The folks the author is busy sneering at are at least as valuable as the engineers they're actively trying to retain because (among other things) they soak menial tasks that would otherwise cut into their rockstar's productivity.