Hard and Soft Skills in Tech(medium.com) |
Hard and Soft Skills in Tech(medium.com) |
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.
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/945114254922825730Yes, 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 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...
1. Author observes that he's witnessed a lot of emotional backlash to the suggestion that soft skills may outweigh hard skills in tech; suggests the emotionality of the reaction is indicative that engineers worry it just may be true.
2. Justifies the importance of soft skills by citing personal experience of teams of 100s+ people needing to be coordinated
3. Proposes that a [software] system's interaction with the outside world is a larger problem than the system itself [i.e. UX tougher than code]
4. Offers a metric to assess management by: if people dislike managers then those managers must have very low soft-skills. Proposes the traditional approach to management is a large failure in tech.
5. Describes soft-skills but gives no hard examples
6. Proposes creating vocabulary to represent soft skills such as requirement-gathering so that people can care more about these skills
---
My aside: I think 1/2 largely depend on the product, some products are almost entirely technical (alpha go, bitcoin), we'll only ever reach agreement by not oversimplifying the question.
I agree on 4, but I really think 5 is crucial. I think everybody has a very different idea of what "Soft skills" are and how well other people think they do at those skills. For example, I think somebody who creates laughter at work is a huge asset, others may not.
I wish that a certain ex-Googler could have been educated in these skills rather than being shown the door.
0. http://scholar.harvard.edu/files/mickens/files/thenightwatch...
Sound engineering judgment typically implies a good understanding of the full context of the problem ("is this a good tradeoff?"), which often involves things beyond the merely technical. And without all of the other things you mention, which are definitely in the category normally called "soft skills," the best engineering judgment in the world will go to waste.
They’re anything but soft, and no less important to a team.
You're associating the word soft with easy and hard with difficult -- which is part of the problem.
Soft skills are difficult for many.
I try to use communication or personal or interpersonal skills, etc.
Mistakes in communication happen easily, so it's good to be skilled enough to avoid them or recover quickly.
This is tied to one of the core categories of soft skills: getting a group of people to work together as a team and trust each other.
I think you have to admit that a manager who can make the team care about work, enjoy it, feel like a team, feel like they're working on an important problem together (even though none of this emotional stuff is objectively true/false or valid/invalid) is an asset to the company.
Money attracts assholes, I don't think many people would argue with that (although I'd honestly be interested in hearing arguments against this). So if your goal is to keep them away, then just make sure to never monetize your product.
We always knew about the former, and it's in every industry. The latter is the more recent (and relevant) phenomenon.
engineer w/ hard skills = solid;
engineer w/ hard + soft skills = powerful;
engineer w/only soft skills = useless;
An engineer with soft skills, but no hard skills, isn't an engineer – but their soft skills may be usable elsewhere. (I find that engineering managers need to have a decent amount of engineering skill to be at all effective)
An engineer with hard skills, but no soft skills, is somewhere between unproductive and an active menace. The bare minimum soft skill is the ability to work effectively with others in a team. Someone who lacks this skill contributes more negative value, by harming the operation of the rest of the team, than any one person is able to create, no matter how good they are. And a system built by one person in angry isolation (which is where people quickly end up if they lack those skills) is a disaster from other perspectives: for example, production maintenance and operations, where ultimately only one person understands what they've built.
An engineer with enough hard skills to function in a team, but only that, is a net positive, but I'd hesitate to describe them as "solid" – rather, I'd say that gets them to be an effective journeyman, but means they'll never be able to lead anything, even something small.
Conversely, the "engineer" with lots of soft skills but minimal hard skills can be a manager – but not of anything too complex. Again, their career is permanently limited.
So there's a real law of the minimum at play here. But notably, the place you drop to at zero soft skills is way worse than the place you drop to at zero hard skills. The latter, you can find a use for; the former, you need to get out of your organization as quickly as possible, because they do active damage every day.
A better set of characteristics to look for might be: sympathy, compassion, consideration, honesty.
‘Empathy’ as a term actually has a shaky and very recent etymology which reflects some of the contradictions it plays into. A loose translation of it’s origins is to express sympathy, which has a slight technical from what it means now, because it has been widely adopted as dignified form of sympathy. The difference from the classical term sympathy is that empathy is more correlated with communication than intention. Why has it gained in popularity? A socio-cultural argument might center on the fact that empathy carries less vulnerability than sympathy. There are some serious implications here.
The general problem with the focus on empathy is the loss of a bigger picture concern with being sincere. It’s analogous to short-term concerns vs. long-term concerns, where short-term concern is to provide immediate comfort and long-term concern is to provide sustainment and survival. A highly social workplace will value immediate social relations like expression of compassion while overlooking important long term values like honesty and less-empathetic forms of sympathy.
Ideally, we would maintain both, but these simplifications of the issue are unlikely to support that outcome.
Thus the phrase "Soft skills" gives a veneer of objectivity to something to personal dynamics that are incredibly subjective and unscientific. The term is potentially a weapon for the politically-savvy to punish those who oppose them with an unfalsifiable attack.
On (3) -- not just UX! Interaction with the outside world is a feature of every aspect of how people will use (or misuse) the system.
(5) Totally agree that this is crucial. I did give a few examples (later in the article) but I think that coming up with a good taxonomy of these skills, and patterns for learning and teaching them, is a huge challenge going forward.
Many intuitions are useful: for example, you note that some people want more laughter at work, others don't. A good leader should be able to make that meta-analysis, figure out what the team needs, and create that. But needs to do what? How do we describe the (positive) effects of laughter that you're trying to capture?
> 3. Proposes that a [software] system's interaction with the outside world is a larger problem than the system itself [i.e. UX tougher than code]
I hate this mindset that tries to divorce UX and code. If you're making a CRUD app, don't think of it as a tiny pure nugget of reusable API goodness surrounded by an unfortunate layer of messy UI that has to deal with the real world. The app IS that messy UI code. The rest is just a database schema. Don't try to abstract away your job.
Of course UX and code are different, but I think they're inseparable and anyone doing either should have a firm grasp of the other.
"instead of hard skills coming from years of practice and suffering"
Kinda like you did there? ;-)
Anyway, this is an essential soft skill to have, and one that I suspect more techies exercise than they give themselves credit for. But the response to it is pretty simple: "Alright, if this organization doesn't value the skillset I have, I'll go work for an organization that does, doing a favor for both you, me, and that new organization." After all, why waste resources on something you don't need? The whole point of a market economy is to self-organize so that everyone gets the maximum amount of value out of their skills & talents.
I've pulled this card a couple times (not even as a negotiation tool, but because I honestly wanted to know if I should be spending my time on something else) and gotten back a "No, no, this is actually really important to us, please don't leave or stop doing it."
Soft skills are important especially in programming. Open source projects for example, live and die by how much and how well they can engage their community, an inherently soft skill.
But one of the things I figured out a while back is that even jobs that aren't particularly hard sometimes still need dedicated time and attention. Division of labor can help with that. And if you try doing one of the "easy"/soft jobs for a while, you might find that it requires a certain set of subtle skills that don't all come naturally to you.
For example, I tried being an account/project manager and sometimes-front-end-dev for a startup years ago. And I found out really quick that the former is (partly) about paying attention to lots of little pieces of information and trying to push them between people quickly and managing human expectations and keeping everybody oriented around the important next step and a bunch of other things which didn't require years of study but still needed work. Development, by contrast, required a stacked set of skills in dealing with a cooperating set of abstractions and lots of time in singularly focused attention. Doing both at the same time is not something I'd recommend to most people, btw -- dev work is focus-driven, management work is interrupt driven and there's an inherent conflict. So... division of labor makes a lot of sense and you might need someone to do the things involved here to keep the enterprise going as much as you need developers. This stuff "actually matters" even when it isn't rocket science.
It also does happen that there are people who are outlier-good at "soft" tasks. Not as often as people claim, but it does happen.
> trying to hack other people to believe that their skills are what actually matters instead of hard skills ... it actually often works, which is sad.
If they're successful, isn't that more or less proof of the utility of those skills? Being able to persuade people to adopt a given point of view -- or least to be able to negotiate to an agreement -- strikes me as one of the most useful skills there could be. It's essentially hot-swapping code in someone else's brain! :)
I think what most of us technical folks get frustrated at is watching perceived value (and with it, authority and compensation) accumulate outside of our reach. But if this is a perception problem, perhaps the soft skill of persuasion is the answer.
...you mean like pretending that only the easy stuff (interacting with the machine) matters, and all the complicated hard-to-understand things about interacting usefully with other humans are completely irrelevant? :)
instead of hard skills coming from years of practice and suffering
Um, no, the "hard" skills come from playing with the machine and solving puzzles for fun. They're not "hard" as in "not easy", it's as in "not fuzzy".
Due to "nerds being clueless", it actually often works, which is sad.
I do not appreciate your insults to my status as a competent adult.
Are you sure you're as much on the side of the "nerds" as you pretend to be?
...until he was forced out when none of the departments succeeded, that is.
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.
Sympathy requires you to feel the emotions of others which is often done to an unhealthy degree. Understanding how someone feels and feeling how they feel are different and should be treated with different words. It's good to work to understand others, but that doesn't mean you have to become them. And just because I don't share your feelings it doesn't mean I don't think they're valid. It just means I'm not you and I'm free to make my own choices.
I will often still choose to help you, but I'm not taking ownership of your problem.
feeling sympathy != taking responsibility
The difference between the terms’ meanings is beyond mere emphasis, but it still falls short of occupying the subject’s bodily consciousness.
Look at the spectrum of bonds between family members for reference. Caring for one another to varying degrees is not so strange for most people. It is just becoming less common in public and business relationships.
Perhaps 'simpatico' is closer in meaning to the desired emotion.
You appear to be falling into some logical fallacy here.
But most importantly, on the single average engineer level, which is more relevant, there are plenty of companies with backstabbing culture or individual bad actors in companies with otherwise good culture. For example, I have seen engineers badmouth other peoples work not because it would be bad, but to make themselves look good in comparison. Etc.
Bosses were aware and managed operation. That is true.
> It's hard for many techies, by nature idealists, to fully grasp how the world truly works
Not all techies are idealists and it is not necessary to be idealist to have good hard skills. Also, idealists tend to be focused a bit less on those hard skills then pragmatics (being attracted to ideals). While some techies (on the spectrum) have hard time to grasp world, many many don't. Those who do were less likely to get goodies.
Techies aren't idiots (any more so than anyone else).
It doesn't take much to poke holes in the way things are - it's a lot harder to do something about it, other than 'raising awareness' aka complaining.
So, those small online stores didn't used to all be on Amazon or Ebay. Which means those platforms must be providing something that the store proprietors think is worth losing some of their independence over.
What is that "something", and what does the blockchain do to provide it that just getting an account with a payment processor doesn't do?
But 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.
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".
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
IBM had child company in Germany Dehomag, but transported machines and cards from outside too (including during war through not whole of it). The book however deals more with management and non-German citizens guilt which is harder to show. That people of all sorts in the Germany, including technologistics, were contributing to Nazi plans is easier to believe. It was just first example that came to my mind.
I'd be interested in reading more detailed first-hand descriptions of this, but searching for some key phrases from your description is just bringing up irrelevant product links. It's seemingly at odds with the rampant counterfeiting and listing spam (to confirm that my experience isn't outdated, I just went to the "Unlocked Cell Phones" category, sorted by lowest price, and found a listing for "Example Product Title" by "Example Product Brand", available from 3 sellers) on Amazon. I guess it's conceivable that Amazon is good at logistics/infrastructure but flagrantly awful at the "marketplace" component.
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.
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.
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.
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.