Thoughts on Unicorns are People Too

In which I appreciate Abinante's Madison+ Ruby 2014 talk Unicorns are People Too: Rethinking Soft and Hard Skills and share the points I took from it.

Summary

• "Soft skills" are important. Call them something better than "soft skills". How about "human skills" instead.
• Human skills are important, are a competitive advantage, and are part of being the best human beings we can be.
• It is easy to be a unicorn (exhibit proficient robot skills). It's hard to be a person (exhibit proficient human skills). It is worth it to be a person.

Watch the video

You can grab the slides linked from the Lanyrd page.

Stop calling them "Soft Skills"

The problem with calling "soft skills" soft is that soft has weakening connotations (mushy, flaccid, squishable, comfy, plush, ...).

People with "soft skills" are not stuffed animals. They are human beings. When exercising soft skills they are exhibiting humanity.

I am a person who likes working with other people.

This is not soft and flimsy -- this is essential, core, and a tremendous competitive advantage.

However. Dichotomies like soft vs. hard seem attractive and cognitively useful, so if you like, use a dichotomy that says something more true, relevant, useful, interesting about these human-interaction skills. It is counter-productive to be reminded that these skills are fluffy. It is more helpful to be reminded that these skills are human or social.

Abinante suggested a few such dichotomies.

My favorite (and I think the speaker's as well) is "Human vs Robot".

The skills we often call "hard", technical skills, those are "robot" skills, and that should give you a little pause. There are aspects of those skills amenable to automation. Once upon a time human programmers wrote assembly language. Now mostly assembly language is written by automated systems. You might be the nerd who knew how to stage and deploy the software -- and Jenkins or Hubot or Travis-CI or Drone might take on those tasks and free you to do something else. Some of those technical skills that are today valued will be automated tomorrow, and that is often okay -- good technical skills move forward with the relevant technology. If your sole source of value is that you are good at robot skills, well, then you are providing less value than if you are also adding value using human skills.

And then there are human skills, those not amenable to automation, those that are necessarily human and human-being-involving. While we can and should build software and automated systems that are kinder than they are today, ultimately only human beings can bring kindness, compassion, human understanding to bear on their work (at best the robots reflect the kindness of their maintainers).

Code reviews as example of task requiring all kinds of skills

Abinante advanced code reviews as an example of an activity requiring all kinds of skills. Robot-flavored skills are required in being technically correct and insightful, in understanding the code being reviewed, envisioning how it could be different, evaluating those potentials.

I would draw another insight that was not in the talk: that code reviews are more valuable the more human they are.

If a code review is mostly mechanical and robotic, that means there is missing automation. Yes, I could have the insight that a class is missing a JavaDoc comment or a variable could have been final or the test coverage looks to be roughly zero or the code does not adhere to project style regarding use of linguistically optional braces. All of that is a waste of a human's time trying to be a robot and risking the costs of interpersonal interaction to be that robot -- what do you flag and what do you let go? How do you give that feedback as kindly as you can? At what point does it feel like nagging? What does it cost you the reviewer in effort, in risk, in cognitive load doing something that could have been done by a robot? This is poisonous. The essential move here is to automate away the technical aspects of code review that are better undertaken by automated systems so that the human aspects of code review can be undertaken by humans, necessarily exercising their human skills.

Email is broken

I attended my employer's Respect in the Workplace training yesterday.

One of the examples given via a skit was that of one employee having emailed another a request, that email having been ignored for a couple of days, the emailer feeling put out by this and inappropriately barging in on and demonstrating lack of respect for the recipient of the email.

I think the intended point of the skit was about setting better expectations via email, giving benefit of the doubt, not barging in on and yelling at one's colleagues, etc. All good stuff, of course. Human beings should communicate better and have more care and empathy and respect. Of course.

I took another message from that skit. The skit was an example of a broken system. While we can recognize that people are responsible for their own behavior and respect in the workplace is everyone's responsibility, it is simultaneously the case that environments and systems encourage different kinds of interactions and failure modalities.

Part of the problem played out in that skit is using broken communication tools. Email is expensive in the load it puts on human beings to compose effective communication. The author's task is to write something that is at once concise yet sufficient, that includes sufficient context and detail yet is not dismissed out of hand as "too long, didn't read it".

The answer is not necessarily to have a face-to-face conversation instead -- that is expensive too in its interruption, in its opportunity to go sideways, in its lack of artifacts to support followup.

Sometimes the answer is to use tools more effectively. A good issue tracker can track a task to completion, communicating its urgency and expectations and its progress without requiring human beings to manually communicate directly with one another, and prompting for the needed metadata in a structured way from the get-go.

Be Kind

In considering the folks I've worked with, of various technical and interpersonal-relation levels of talent, I do think the Unicorns are People Too talk resonates -- what is valuable, and is in shortest supply, is kindness, thoughtfulness, ability to communicate and empathize, not technical talent. I do not actually do much that requires tremendous technical talent -- this is low-volume Web application development after all -- but every single project requires thoughtfulness and interpersonal interactions.

However, not every single moment of every project requires interpersonal interactions, which for many of us human beings are, well, exhausting and fraught with opportunity to miscommunicate. Effective tooling and appropriate processes and systems can focus the human skills where they have the most to add and allow robot skills and even better automation to have its best effect as well.

Unicorn photo CC-BY-NC: https://flic.kr/p/bpQFTw