How to pretend you have social skills

This time I decided to do something uncommon. I have asked Martina Cantaro, a psychologist that works for our company Lambdaclass, to write about the work she is doing training young developers. I hope you find it useful.

My role at Lambda is to help young developers train their social skills to perform their best. Soft skills are not secondary to technical knowledge — they are what makes knowledge shine by making it useful to the human beings with and for which we work. A lot of good technical developers tend to underestimate the need of social/soft skills.

First of all let’s define what social skills are. According to wikipedia social skills involve:

• Coordination — Adjusting actions in relation to others’ actions
• Mentoring — Teaching and helping others how to do something (e.g. a study partner).
• Negotiation — Discussion aimed at reaching an agreement.
• Persuasion — The action or fact of persuading someone or of being persuaded to do or believe something.
• Service Orientation — Actively looking for ways to evolve compassionately and grow psycho-socially with people.
• Social Perceptiveness — Being aware of others’ reactions and able to respond in an understanding manner.

Since many people have asked me how to develop soft skills and which are the most common problems, I thought I’d share a few vignettes of what I do at Lambda. I hope you find them as interesting as I do.

Don’t kill the dog

Two programmers had received a message from the client via Slack. The message seemed pretty straightforward. It said: “Feature X isn’t working”. Next, the tech lead of the client listed a series of detailed steps to solve this problem. This client was pretty new so we needed some help to understand how to solve it since the issue was related to business rules we didn’t know. The diligent programmers followed the steps carefully and once they were done reported back to the client: “There! It’s done”; and went on to fulfill the tasks that were awaiting them in Github.

A few hours later, the programmers were shocked to hear that the client was not happy at all. “Feature X still isn’t working!” the client demanded. “But we followed the instructions you sent to the letter!”, the programmers cried out. They repeated this defense to me when we talked about the issue a few days later in our weekly workshop.

Well, I said, and paused, trying to come up with a metaphor that would put things into perspective for them. Then I saw Simon, our office dog. “If I take Simon to the vet because he has a stomach ache, and I tell the vet to please anestesize him, cut him open, swap his liver with his bladder and stitch him up, the vet will promptly stop me and tell me we need to find an alternative solution. Alternatively, if she does exactly as I said, and Simon dies, I will know I need to find a better vet”.

The client described a problem to you. The fact that they helpfully provided you with a path to a solution doesn’t mean that they just wanted you to blindly follow the steps and call it a day. The primary goal is always fixing the problem.

The takeaway here is: your job is to find solutions to problems. Test your solutions. Make sure you provided a solution for the client’s problem. Their suggestions may help but it’s not their job to spell out the solution for you. Otherwise it would be program-by-numbers! Always remember your goal. Test what you just did to see if you met that goal. If the provided solution didn’t work, try another one. If you don’t have permission to modify something, report back: the client needs to know it couldn’t be fixed by you and why.

The truth in your heart

I was coaching programmers before an interview with a client. One of the topics we expected would come up was their opinion on different programming languages and tools. We didn’t know the interviewer’s style, so the interview could be more structured or more like a casual conversation on programming. I began with some basic, open-ended questions, like “what programming language do you prefer and why?”.

There are two types of wrong answers to this question. I call one the “dogmatic” answer and the other the “judgement day” answer.

The Dogmatic knows exactly how to answer that question because there’s only one possible answer. There is only one language to conquer all languages, and it is usually the one they happen to use. This language has every feature that matters, and none of its disadvantages are really that important. It can do almost anything. Most problems can and should be solved using this language. And all naysayers are stupid.

On the other hand, we have the Judgement Day answer. One programmer just couldn’t make up his mind. He’s a very centered person, who likes to be precise and think through issues before taking a stance. Great qualities for a critical thinker, but in an interview setting his hesitation could be taken the wrong way. He hummed and hawed and only after pressuring him a bit he came up with “Haskell”. Very well, I said, why do you prefer it? He quickly made two or three very valid points and also mentioned its downsides — he had clearly thought about the pros and cons of the language before — and then paused and said candidly: “but I’m not sure Haskell is really my favorite programming language”. Well, I told him, when Judgement Day comes, you better think it through 100%. There are many pros and cons to each language and entire books could be written about why each one is better than the others. But for now, we’ll settle for a 90% accurate answer. Because the question is not really about that.

I mean, sure, the interviewer does want to know which programming language you prefer. But what they truly want to find out, if they are decent interviewers, is the analysis behind your choice. Why did you choose that language? Are you aware of its downsides? Do you know which situations it’s best for? So there’s not one correct answer. Haskell would have been as good an answer as Erlang, as long as you are able to justify it.

I find this happens often with less experienced devs. Their hearts are too pure. They are eager to search their souls and hand you their deepest truth. Also, they are not sure what exactly is being evaluated by these interview questions.

Of course, if the company works with Erlang and you fervently praise Cobol, the interviewer might think you won’t be a good match. So, to sum up, as long as your answer is 1) relevant to them and 2) well justified, you’ll be forgiven for not plunging your hand into your chest, pulling out your heart and finding out what programming language is written in there.

So, young developers. of the world, don’t fret. If you feel paralyzed when an interviewer asks you how you see yourself in five years, remember she doesn’t want you to read the future, she wants to learn about your motivation and goals. The same thing goes for your favorite programming language. However also have in mind that the person that is interviewing you might lack social skills too! You can’t entirely control the output of the interview.

Communication

Most of the programmers at Lambda speak English as a second language — their first one being Spanish. Since communication between the programmers and the (often English-speaking) client is key to perform well, we devised a series of exercises to improve their communication skills.

In order for a client-programmer conversation about code to be effective, both have to have a similar representation of the code on their minds. Code is an abstract structure, and both have to build that structure in their heads in order to discuss it. It is also important to be able to clearly articulate and understand the transformations we want to make to that structure — often in a non-native language.

So we began with this exercise:

I built a series of increasingly complex structures using common office objects and photographed them. Then I scattered the elements on the table and instructed one person to look at the photograph of the structure and give out verbal instructions to another person to replicate the structure in the photograph.

This proved to be more challenging than it seemed. Trial and error were very frequent. I encouraged them to give out more and more precise instructions: “Rotate the spoon? How many degrees, in which direction?”. Ideally, sentences would be self-explanatory and steps should be followed without trial and error.

I then instructed the executor of the instructions to proceed as if they were deactivating a bomb — to make a move if they were absolutely certain the movement was going to be accurate. If not, they should ask for clarification

By the third or fourth iteration, their sentences had become longer and better structured, and their language more precise. The executor was also more alert and made sure they understood instructions perfectly.

Technical problems and people problems: know the difference

Sometimes personal issues are disguised as technical ones. For example, a worker repeatedly pointing out minor mistakes to a colleague in front of third-parties might not be motivated by a desire to improve the quality of work but to make the other feel uncomfortable.

When we first learned to identify these sorts of situations, one case popped up. Some programmers were working for a client in cooperation with another service company. The tech lead of this company had been on the project since the beginning and was not keen on having newcomers on it. He frequently withheld information the programmers needed to complete their tasks and was bent on chastising them for their mistakes on the general chat.

The situation was so bad that there was legitimate concern that this was an attempt to push our programmers out of the project, so the situation had to be handled with great care so as to not make matters worse.

So on one occasion where the chastising was particularly bad and unwarranted, our project manager intervened. He answered on the same chat channel that work was being carried out according to the plan and there was no basis for the criticisms being made, effectively standing between the angry tech lead and the programmers with a sword and shiny armor, ready to defend them against attacks.

One of our less experienced programmers, however, felt bad about the situation and wanted to placate Angry Tech Lead. He didn’t know what he had done wrong, but he wanted to make the situation OK.

So, following the epic defense of the project manager, he wrote an apology on the same channel. This opened a flank for the angry tech lead to continue his attack, rendering the project manager’s defense useless.

We analyzed this dynamic later. Here, the hierarchical structure of the company dictated that if your higher up was deflecting the attack, there was no need to take the hit. In fact, taking the hit could justify subsequent attacks by Angry Tech Lead.

Two lessons were drawn from this: first, to trust the higher-ups’ handling of the situation (or at least talk to them first) because they are probably protecting you. Secondly, we dissected the situation and distinguished constructive criticism from destructive criticism. Constructive criticism is given in a spirit of cooperation, with respect and it provides information on how to correct the mistake or avoid it in the future. It is also often dosed so that it doesn’t overwhelm the recipient, unless the matter is urgent. When it is about a task, it focuses on the problem and not the person. But in this case there was little cooperation since information was being withheld, criticism flowed like a cascade and there was no focus on how to accomplish the task more efficiently.

What at first had seemed to them a technical problem now revealed itself as a people’s problem. This took us a little further into understanding the complex relationship between both realms.

Like captain Spock, we combine the worlds of logical thinking with the human dimension, which may seem irrational when analyzed through the cold prisma of mathematical rationality but has its own logic and meaning. And we need to develop skills in both areas, because, ultimately, we are humans working for other humans — code is just our tool.