People skills for developers

People skills for developers

Talk less, listen more, be humble

A team is not a group of people that work together. A team is a group of people that trust each other.
Simon Sinek

Okay, you’ve survived day one, so what now? Well, now comes the tricky bit: working with other people. Weirdly, that’s a skill you won’t learn at any bootcamp. But it’s the single most important factor in making your career a success, or… well, let’s not worry about “or”.

Instead, let’s talk about why the so-called “soft” skills are the hardest of all.

Social capital

A useful thing to understand about work, or any kind of group activity, is that you have a certain amount of social capital to play with. Being helpful and kind increases your social bank balance, if you like. Being honest, trustworthy, reliable, humble, and easy-going increases it, too. On the other hand, being arrogant or unpleasant will drain your capital rapidly.

And it’s not just about being a good person, though you should certainly care about that. You need social capital to do your job. When you’ve got a problem you can’t solve and you’re under pressure to get it fixed right now, you can draw on your capital by asking a co-worker for help. Needless to say, if you haven’t helped them in the past, they won’t feel much like helping you now.

Social capital is what makes people listen to your ideas, or give weight to your opinions. It’s how people see you as a team player. It’s what makes them want to help you, even when that’s not strictly their job. It’s the currency of trust. And trust is what makes the whole thing work.

Managing your commitments

To be trustworthy, and earn social capital, it’s important to prioritise your commitments. In other words, if you say you’ll do something, you need to do it.

If you don’t, people will gradually stop trusting you, and your social capital will dwindle away. The most dangerous thing about that is that you may not even know it’s happening.

People don’t tell you when they stop trusting you.
—Jerry Weinberg, “Secrets of Consulting”

The biggest threat to your trustworthiness is probably not that you’re a horrible, deceitful person who tells lies. It’s that a perfectly natural desire to please causes you to over-promise and under-deliver.

We all want to say “yes” to things. It makes everyone happy, until you realise you’ve taken on far too much, and you have to belatedly tell them you won’t be able to do the thing after all. Now they’ll be unhappy, not just because you made a promise and then let them down, but because it’s probably now too late for them to find someone else to help.

Saying “no” is a superpower

While ill-considered promises might earn you a little temporary capital, your failure to deliver will cost you more later, resulting in a net deficit. On the other hand, saying “no” now might cost you a tiny bit of capital in the short term, but in the long term you’ll gain much more, because you’ll be known as a good commitment manager.

When someone asks you for a commitment, they don’t really want you to say yes unless you’re actually going to deliver on it. So think carefully about your answer. It’s fine to say “Let me get back to you when I’ve checked my schedule.”

And, if you eventually conclude that this isn’t something you can be 95% confident about delivering on time, you should say “I’d really like to help, but it just doesn’t look like it’s going to be possible to fit this in with my existing commitments.”

That’s a nice way to say no, because it underlines the value you place on your commitments, and how seriously you take them. The person you’re talking to knows that, even if you can’t help this time, when you do say you can, you will.

Finding your feet

One thing that’s guaranteed when you join any new organisation, division, or even team: they’ll do things differently from what you’re used to. There will be unfamiliar and unexpected rules, some written, most unwritten, and you will break them without even meaning to.

That’s okay. If you listen more than you talk, and pay close attention to what everyone else is doing—and even more importantly, how they’re doing it—you won’t get yourself into too much trouble.

But there will be friction at some point and about some things, so how do you deal with that?

Fitting in with the way others work is hard, and it takes some time and patience. You have to be sensitive to what’s going on, and tolerant of things that aren’t the way you like them to be.

When you go from working largely by yourself to working in a team, especially a big team, you’re likely to encounter lots of things that you find hard to understand, or even laughably wrong.

Coding standards, patterns, and practices vary widely: even the layout of brackets and whitespace can be a point of debate, in languages that don’t have a canonical standard format.

gofmt’s style is no one’s favourite, yet gofmt is everyone’s favourite.
“Go Proverbs”

All teams have a house style that you need to learn and abide by. You may not like or agree with all its choices, but then, your fellow team members probably feel the same. The point of standardising practices like this is not to do everything perfectly, but to stop people wasting time arguing about trivialities.

Don’t rearrange the furniture

A codebase is a little like someone’s house: they’ve probably lived there for a while, and they have things mostly the way they like them. Also, they’re used to the arrangements. It can be difficult to have someone new come in and start blundering around the place, falling over the furniture or breaking the crockery.

And you wouldn’t be too pleased if your new roommate or partner started taking issue with your choice of decor or furnishings. You certainly wouldn’t expect them to just start rearranging things to suit themselves: “I’m used to having the couch face the window—I was sure you wouldn’t mind me moving it.”

You’d expect them to adapt themselves to your preferences, even if it’s not what they’re used to. Now imagine those roles reversed. You’re the guest in someone else’s codebase or project. Don’t complain, criticise, question, or move things around without asking. Things are the way they are for a reason, even if that reason is simply “we haven’t got around to fixing that yet”.

A little empathy goes a long way here. If something seems wrong to you, it might just be the way it is because other people have thought about it a little more carefully than you have. Or maybe they’re fighting a desperate battle that you know nothing about, and compared with that, this issue seems ridiculously trivial. And, if something seems a little half-finished, maybe that’s because it is.

Making the right first impression

Don’t look for problems your colleagues seem to have missed. Instead, ask them what problems they could really use help with. You could say “Do you have any little tasks kicking around that no one’s had time to get to lately? Tackling those would help me get familiar with the codebase, while still contributing something useful.” This is much more likely to get a favourable, or even rapturous, reception.

It sends out a signal straight away that you’re not here to make them look bad. In fact, you’re here to make them look good. You’re not going to create extra work for them: instead, you’re going to lighten their load. Once you’ve established this idea, you’ll find your welcome a lot warmer.

Collaboration is your biggest challenge

The biggest challenges you’ll face at work won’t be build failures or the type system, they’ll be about trying to work with other people. If everyone were smart, nice, and competent, things would be easier, but you’ll have to work with plenty of the other kind too.

Even when team members trust each other and get along, there will be conflicts and difficulties. Collaboration is just hard. This is known. And no one is a born collaborator; it’s something you have to learn and practice to get good at. We’re all somewhere along that journey, and throughout your career you’ll meet people at every level of collaborative ability, from “zero” to “decent”.

People skills

While technical skills predominate in the job application process, once you actually make it into the workplace (whether physical or virtual), you’ll find that your tech chops are taken for granted. What’s going to determine your ultimate success or failure in this job is your people skills.

Unfortunately, not everyone realises this, and you’ll find a few people in every team or company who, while they may be super smart and experienced, are also anti-social jerks. Sorry about that.

You can do your little bit to redress this problem by learning and demonstrating how people should treat one another, at work or elsewhere: with respect, consideration, and kindness. Not everyone will reciprocate, but that’s not why you’re doing it.

Human relationships

We’re told we should act “professional” with our co-workers, but that shouldn’t be interpreted as treating them like robots. They’re just as human as we are, at least in most cases, and the secret to a good professional relationship is having a good human relationship.

LISTER: See, Rimmer, the trouble is you’ve never got time for people. You’re too busy trying to be successful.
RIMMER: I have got time for people. What about all the time I spent licking up to Todhunter even though he was a total gimp? And Captain Hollister? I went out of my way to simper round him.
—Red Dwarf, “Thanks for the Memory”

We’re all very good at knowing when people are just being nice to us because they want something. It only works when you actually mean it. But then it works magnificently.

Overcoming shyness

People are always astonished and dismayed to be told that they come across as unfriendly. Almost no one acts this way on purpose. Instead, they might just not have the knack of making light, friendly chat. By initiating the chat yourself, you’ll often be able to break the ice and turn a cool relationship into a warm one.

And no one expects sparkling conversation at work. Just making the effort at all is the compliment you’re paying them. “So, how about that local sportsball team?” won’t win you any prizes for originality, but it might win you a smile, and the next time will be easier.

Listening

Listening is another interpersonal superpower that’s often unwisely neglected. Most of us are pretty good at talking, usually at considerable length, but someone who knows how to listen is a rare and precious find.

We tend to think we’re listening to someone, when what we’re really doing is working out what we’re going to say next, and waiting for them to stop talking so that we can make our devastating point. And even if we’re paying attention on some level, that still isn’t quite the same as actually listening.

If you listen carefully to what someone tells you, instead of humming a tune inside your head and waiting for them to finish, you might learn something useful. Also, if you can keep quiet long enough for them to work through the process of turning their thoughts into words, they often learn something, too.

Experienced programmers call this rubber-ducking: sometimes, the simple act of explaining your problem to someone else in sufficient detail is enough to trigger the insight you need to solve it. Rubber ducks make better listeners for this purpose than most human beings, apparently.

What we can do that bath toys can’t, though, is to add value to the discussion by telling the speaker what we think we understand them to be saying. Our understanding may be right, or it may be wrong. Either way, it’s helpful for the speaker to know how we’re hearing them.

Reflection

True listening, then, is not a passive process, but an active one:

I recall a time when I was talking with someone who seemed to ignore everything I said. “You are not listening to me!” I accused. “Oh, yes I am!” he said. He then repeated word for word what I had told him. He heard exactly. But he wasn’t listening. He didn’t understand the meanings I was trying to convey.
—Robert Bolton, “People Skills”

Even if we’re showing all the signs of attending, the other person does not actually know that we’re listening unless we can show them that we’ve understood the import of what they said.

The simplest way to do that is to reflect it, by stating the essence of what they said, but in our own words. That usually means identifying the feelings they’re trying to communicate:

THEM: That code review comment really made me angry. It was like “You’re so dumb for making this mistake.”
YOU: You felt attacked.
THEM: Exactly.

When the speaker hears that we have successfully grasped their point, they usually say something like “Right,” or “Exactly”. If not, they will correct us. Either way, they are reassured that we’re at least trying to understand.

Don’t make it about you

The mark of someone who’s not listening, by contrast, is that they jump in as soon as there’s a pause. This is like saying “Never mind that, here’s what I think…”

A common fault among poor listeners is that they immediately try to relate what the speaker is saying to some experience of their own. “The same thing happened to me once when I was on the way to Shelbyville. Now, I was wearing an onion on my belt, which was the style at the time…”

The listener means well, because they want to let the speaker know that they understand exactly what they’re talking about, by drawing a parallel with their own lives. But by breaking the speaker’s flow and changing the conversation to be about them, they inadvertently did the opposite of listening.

Instead, just let the person say what they want to say in their own time, and in their own way. And if it seems that they don’t want to talk, don’t try to force it: just stay quiet. If they want to fill the silence, they will. Otherwise, you can just be comfortably silent together. Not all conversation has to involve talking.

In the final part of this series, we’ll look at what it takes to be a good co-worker, and why that’s something you should focus on if you want to succeed—not just in this job, but in general.

Previous: You can do this: surviving day one

Next: Being a good co-worker is your job now

Not a real developer

Not a real developer

My horrible career

My horrible career

0