If you're arguing against that, then you're part of the problem.
It's also what we call a "false dilemma" to suggest that your proffered interpretations for this "trend" are the only interpretations for it.
It's basic self-interest. If you believe that you're unable to sell your hard skills to an employer, it's in your interest to try to convince people that what you offer (superior generosity, motivational speaking, equality and empathy) will be more likely to bring success to an employer.
People don't need to literally call for hard skills to be replaced because that's not the end-goal. The goal here is that employer's realise that soft skills are more important so that the status of these careers is higher than that of software engineers.
[1] https://twitter.com/joelgrus/status/945114254922825730But I'm probably biased to read it more generously than someone else might be; I was a philosophy major in undergrad, and actively repudiate the ludicrous notion that a broader, more liberal education is somehow wasteful. So YMMV.
EDIT: Look at it this way: you can be the most brilliant technologist in the history of ever. If you're impossible to work with, you're a liability, not an asset. You drive away anyone who tries to work with you, and/or your bus factor is, give or take, ∞.
Once again, "if you're arguing against that, then you're part of the problem."
A broader, more liberal education isn't a waste, but I don't think that such a thing would lead anybody to call out nerds for social deficiencies while singing one's own praises. If it does, then yes, that is a shocking waste of an education.
Not being able to see this and trying to throw people under the bus with unfair stereotypes in order to get ahead is just as bad as having strong hard skills but being devoid of empathy. (It is practically a mirror image: having strong soft skills but being devoid of empathy.)
So I'll freely own that I may have a small chip there. But at the same time, while the plural of anecdote isn't data, an existence proof is an existence proof.
I've met rockstar asshole programmer's before, but I think it is overblown -- I do not think there are as many as everybody thinks there are. Far more often I've met great engineers that were well-rounded, kind and decent people. And yet the myth persists...
> I'm not absolving anyone of anything,
> and I'm curious what I might have said
> to suggest I am.
This perspective is utilised by people that want to raise their own position in relation.
I'm not suggesting you're purposefully letting people off the hook -- I guess the term 'absolving' made it seem conscious. What I'm saying is that people in tech are normal, and so the whole conversation about bringing empathy and other soft skills into tech is fundamentally disrespectful and abusive, and that people are doing this for selfish reasons.
Honestly, to me, the whole conversation about people in tech feels corrupted by ridiculous caricatures: 'The Tech Bro', 'The Socially Unaware Autist', 'The Rockstar Asshole', etc. This isn't a normal state of affairs: it's an effect of the constant tech tabloid media cycles. We're basically left with a mess of unreflective stereotypes that distort everything they touch.
Let's agree to just treat people as people and stop with this idea, implicit the whole conversation, that we need to value people who aren't technical more because they automatically possess skills that these technical nerds lack.
Well, sure. If that's a premise you bring to the discussion, your position makes sense. And to the extent it is, I reject it (as a generalization), too.
It's also, however, the first I've ever heard of its being a premise to the discussion, so I hope you'll understand why I wasn't discussing this as if it were.
You do not need a STEM degree to be an outstanding technologist, or even a competent one. Far and away, the most valuable skill for this kind of work is critical thinking, and I've never seen classes teaching that offered outside the "liberal arts".
Reality is the opposite of your assertion: critical thinking is largely dead outside STEM, and that's because only in STEM does reality punish you for indulging sweet-sounding nonsense.
I've also met good developers over the course of over 20 years writing software. Many of them had no degree or an irrelevant degree. I respect them tremendously, but they're exceptions.
The kind of thinking that today's liberal arts departments encourage is contrary to the rigor needed to solve real engineering problems, and it's rare that you find in a single individual both a knack for the cold logic of engineering and the social sensitivity needed to succeed in a world of post-modern, post-logic quicksand.
It also tells me we are utterly talking past one another here. I have better things to do with my afternoon than refute yet more straw-men.
It's amazing that the academic departments that talk up their critical thinking in the most produce nothing that resembles a workable theory of the world.
Maybe what you wrote was true at one time, but these days, "evaluating ideas...for flaws" in large parts of academia is the process of finding logical contortions that, in the death-of-the-author spirit, twist texts and make them say the opposite of what they say. It's essentially formalized trolling.
That mode of thought has no business getting into the same building as real engineering.
Critical Theory is about the opposite of critical thinking.
> ...but these days, "evaluating ideas...for flaws" is the process of finding logical contortions that, in the death-of-the-author spirit, twist texts and make them say the opposite of what they say.
Wow.
Learn how to work people like a psychopath manager? Unlimited earning potential. Learn hard skills? Pigeonholed as "too valuable" to promote while being taken advantage of by those psychopaths until you connect enough dots to expose them or are deemed no longer necessary to their evil plan.
That's in incredibly dangerous and irresponsible thing to write. We need to entertain all arguments, not enshrine some things in untouchable dogma. Calling people personally awful for stating an argument --- instead of addressing the argument --- is the reason that today's public discourse is bonkers.
The line I quoted above turns disagreement into a witch hunt.
> That's in incredibly dangerous and irresponsible thing to write.
Also quite ironic, in context of an article advising to "make sure that everyone’s voice is heard, and that important warnings don’t get lost because someone didn’t feel safe saying so". Because this is how the warnings get silenced.
I also, you'd do well to note, never called anyone "personally awful" (more specious hyperbole, hmm?). I said, paraphrased, that certain behaviors and positions are contributory to ("part of") "the problem", which we've already established is pretty narrowly defined.
I have spent more than a decade working with brilliant technologists but haven't found anyone impossible to work with. As in technology, I have found some compatibility issues among/with technologists, but that can be worked out.
Also I have seen some technologists are unable to put forth a strong defense verbal or written when accused wrongly and thus becoming aunt Sally, people find them easier to put blame on.
they imply that soft skills are more valuable than hard skills at Google
Yes, hard technical skills are absolutely necessary for "building the thing right". The necessary level of skill depends on what that thing is.
But there's also "building the right thing", and that is a completely different set of skills. Many of which get lumped into the "soft skills" bucket.
Actually, I think Zunger makes the explicit point that they are not completely different skill sets. I'm inclined to agree with him.
Yes, just like letting the technical people do the design.
Good design uses a separate set of skills, which few people have because few people realize they're important. There is very little correlation between having this set of skills and having the usual set of "hard" technical skills.
I wrote a design program for [thingys] that were basically rectangles, but could have circular arcs instead of straight line edges. A user could fake a circle using two semicircles joined by zero length edges.
The PM saw this and wanted a circular [thingy] feature. He could not understand that it was only a fake circle, such that when the user started changing things, (literal!) corner cases would crop up. Over time, he kept demanding new features that implicitly relied on non-fake circles. And of course this just kept throwing up more confusing corner cases that he kept trying to paper over with new features.
This is one example of a HUGE class of problems that come down to managers just wishing away a mismatch between the way data and code actually work, and the features that they would like to have.
I think if you had both those videos and a convincing explanation of how they can both be truthful, the combination would great training material for everyone on a product team.
A healthy team would have that conversation. I'm not sure the PM needs to understand so much as defer to the engineering side if they decide a change is needed.
I don't think deference to engineers is useful in this sort of thing. There is a class of people (PMs) who have the hard job of aligning user expectations with the engineered reality. They do this by guiding both the customers and engineers, and to do that, they must understand the real landscape they are guiding people through.
[1] I don't want to imply here that everything was the fault of the PM, it wasn't. But there was definately a class bad things that happened due to this particular kind of non-technical thinking.
As a result, they completely missed that the continued growth of the Internet would make hand-curated approaches infeasible. And so they got their lunch eaten by Google. And then they started losing traffic on other properties to Google, who could leverage their massive technological infrastructure that Yahoo had largely copied and open-sourced but wasn't really integrating into their product design. Eventually they brought in an ex-Googler as CEO who tried to stem the tide and re-emphasize Yahoo's technical capabilities, but she was 10 years too late and fighting a whole culture by then.
One example I have seen a lot is the "exactly as I want it" design. What that means is foregoing using any standard web components (like Bootstrap, jqueryUI, ...) because they don't work exactly as the product designer wants, so you have to build something from scratch. Then you run out of time because building a complex web site without relying on any ready-made components is a lot of work, leaving the web site in a decidedly half-assed state.
As you can see, in my opinion "being technical" is not only about programming. It is also about YAGNI, being lazy and very much being a realistic pessimist.
I would dare say this mechanism has been in trouble for the past decade or so and that's the root of the problem. If you're a large company with a sizable share in an established market, technical quality becomes secondary. It's customers' habits, compatibility and your sales budget that run the show. Until the market turns and you go bust, of course.
If you're quickly growing startup, the budget you can spend on growth (i.e. the amount you can raise) far outweighs the technical side. Efficiency? Investors don't care about that, they care about you making enough buzz and getting acquired (or IPOing) while you're still hot. They will get a return even if you never had a single profitable quarter.
Unfortunately, as much as we technical people hate this, I don't see any reason for the "IQ -> EQ" trend to be reversed anytime soon. Not in the current market. The only way out of this circus is making your own bootstrapped business.
Part of the problem is the increased intolerance to conflict in the workplace. Employees these days get fired for merely having self-respect and conviction.
> There always remain various hard [technical problems], of course, which are critical and which can’t be solved by any number of inexperienced people except by them getting experience; that’s why we need to continue to build and grow our technical skills. But if you continue to grow your skillset, you’ll quickly discover that the amount of time that needs to be spent on these extremely difficult technical problems tends towards significantly less than a full-time job; instead, the crucial (and incredibly hard) problems that affect a system have more to do with how that system interacts with the outside world — which is, more and more, people.
> Interestingly, there’s a lot more crossover between hard and soft skills than many people realize: when you start to see your system as a component of a larger system which includes humans as elements, and you start to ask how humans interact with each other and what their behaviors are, then many of the same “hard skills” systems design approaches not only make sense, but can provide even better answers to traditionally purely “soft” questions.
Eric Raymond said something similar recently[0]:
> Whole-systems engineering, when you get good at it, goes beyond being entirely or even mostly about technical optimizations. Every artifact we make is situated in a context of human action that widens out to the economics of its use, the sociology of its users, and the entirety of what Austrian economists call “praxeology”, the science of purposeful human behavior in its widest scope.
Also see Pieter Hintjens' book _Social Architecture_[1].
This is a sensitive issue, because it comes down to the question of who is at the top of the hierarchy, and it's part of human nature to be highly sensitive to our relative position within a given hierarchy. For those of us who have technical skills and an analytical temperament, we naturally want to be in an environment where those qualities are most advantageous in moving up the hierarchy.
I think Zunger's point is that, even within such an organization, there certain skills (which are not specifically technical) which are necessary to being maximally effective at the top of the hierarchy.
[0] http://esr.ibiblio.org/?p=7745
[1] https://www.gitbook.com/book/hintjens/social-architecture/de...
Let's dispense with a strawman: of course interacting with other people is necessary. But there are lots of people out there who said the "tech stuff" is easy and it's the coordination and empathy and stuff that's the real challenge. That's a dangerous perspective no matter which of the two ways you interpret it.
One interpretation is that you really don't think that technical quality is important. In this case, you'll end up getting complacent on quality, ship crap, and open yourself up to competition. You'll be in good company if you go this route: it's part of the reason big companies inevitably decay and get outcompeted by smaller, newer ones. (Notice how a lot of this "soft skills only" crap comes from big companies with products having enough inertia to last a while at a low quality level?)
The other interpretation is most insidious: you do recognize that technical excellence matters, but want to redirect credit to non-technical managers. This phenomenon is a huge problem outside tech; it goes back at least as far as Edison. We shouldn't be in a hurry to import this problem into our own field.
The truth is that in our field, there's a wide distribution of skill levels, and some technical problems go from "impossible" to "routine" once your technical people pass a certain skill and quality bar. Soft skills do not get you over this quality bar. Actual technical knowledge does.