Soft skills for Software Engineers

Whether you’re a junior Software Engineer or senior architect (and also, whether you like it or not), soft skills are a part of your job. Some people are naturally gifted on this area but for most of us less socially adept, it’s something that has to be developed. The good news is, soft skills can definitely be learned and you’ll get better with practice. And the better your soft skills are, the better you’ll be at the rest of your job.

I’ll discuss a few soft skills that I see as essential for any Software Engineer. These things should help you to more effectively do what you’re really paid for; developing great software systems.

Don’t be afraid to speak up

We engineers are a timid bunch. Put us behind a computer and we work magic, but put us in a room full of people, and we quietly nod when the project managers ask us if we can deliver three web applications and a mobile app by next week.

You have to realize that, whatever your level or experience, you hold a certain power, far greater than those fast-talking executives. That is the power of creation. You are able to make things real, to build things and change the course of a company (for better or worse) with every line of code you write. Now I’m sure all those other people look very impressive, but when it comes down to it, they’re all grasping in the dark about a subject you are intimately familiar with; your code.

So you’ve got to help them. The thing is, they are working very hard to keep up their appearance of being important and making decisions, but in reality, they don’t, and can’t, know what they’re talking about, as you‘re the one who creates. Whether they admit it or not, they need you.

Next to your company, you also have a responsibility to yourself to speak up. You have to cover your proverbial ass, because no-one else will. While it sounds heroic to work nights and weekends to get the release done, it’s really no fun. Or rather, it’s no fun when it is forced upon you. If you want to do it then that’s fine, but make sure it’s on your terms.

So speak up. Tell them that it is impossible to make that deadline, or that you can’t start the next project as the current one isn’t done yet. Or, on a more positive note, tell them how they can add another feature to the release by only two lines of code that they considered would take another month. Explain them the realities in the world of code, and the impact their requests have. Give them a glimpse of your world and invite them in to take a peak. Show them if you have to.

You’ll quickly find however that you’ll feel like you mostly have to be telling people “no”. And while saying “yes” is easy, saying “no” can be hard. It creates a tension between the requester and you. And while it might be unfair of the other to make the request, you might feel like you’re the bad guy for creating the tension.

So what we’re going to do is change the conversation from being a request to a problem solving session. The person making the request is probably trying to solve a problem. For example, he wants to have a feature before a deadline so he can show something to his bosses or clients, which will lead to increased whatever or other. If the other person is on your side, your goal is now to help him solve this problem.

Step one is to figure out what the problem is. So you’ll say something like “I’m sorry, I don’t think we can make that deadline. What did you want to achieve at that date? Perhaps we can find another way.”. And ta-da, now you’re solving the problem with him. Perhaps you can offer him another, much easier feature, or perhaps a non-functional mock-up is sufficient.

The thing is, you’ve changed a potentially annoying situation to a puzzle, and if there’s something we like to do, it’s solving puzzles isn’t it? And to top it off, they’ll love you for it!

Small side-note: If you do speak up and get barked at, it’s probably time to think about another job.

Disagree with your intellect, not with your emotions

I considered writing this header about using your head instead of your heart, but that sounded a little too cheesy.

Engineers often feel very strongly about their opinions and preferences. So strongly even, that arguments have a tendency to quickly become emotional. Never let this happen. There’s nothing emotional about these arguments. Emotional arguments only make sense with people you have an actual emotional relationship with, such as a girlfriend or a cheeky parakeet. Not with a colleague.

Enter every argument with the idea that you are possibly wrong. Depending on the other person, this might even be quite likely. Don’t get married to your opinion, and distance yourself from it mentally. Changing your mind should be a cheap operation.

Start by considering the other person. Is he an idiot? If he is, why is he working with you (or why are you working with him)? If he’s not, he probably has a reason for his point of view. Is he more senior than you? Then you’re probably wrong, so put yourself in the shoes of the apprentice and start learning.

Thoroughly figure out what his opinion is about. What is his actual opinion? How does it differ from yours? Where is it similar or the same? How did he get to this opinion? Does he have information that you don’t have, or vice versa?

Discuss the reasons for his opinion. Why did he reach this conclusion, given that you’ve now established that you both have the same information? Can you understand why that is? If not, ask more questions and clarifications. Or does he simply consider other things to be more important than you do? Is performance for him more important than maintainability but is the reverse true for you?

Finally, after making sure both of you thoroughly understand each other but neither has changed his mind (or you both changed your mind, it happens), consider how important this issue is. If it’s not, consider yielding to the other. This should be easier now that you understand his reasoning. If you feel it is still important, either pull in more brains or find a referee to make the call. But do this together, as at this point you should be on the way to find the right way forward, instead of figuring out who’s right.

A very important side effect of all this is that you will learn much faster. You already know about your opinion and how you approach problems, there’s not so much to learn there. People who stick to what they know stagnate. Others however are a big mystery; listening to the thought patterns of others can be a great source of inspiration. Dive into their points of view and you’ll grow much faster than you can do by yourself.

Don’t be an ass

I’m not sure what it is with engineers, but we are a snarky bunch. We like to point out issues in other people’s work, often in front of others. And sometimes even in front of clients. After all, it was kind of obvious that they should have checked on Unicode characters in the input, right? So why shouldn’t everyone know that he didn’t?

The thing is, it’s often not that simple. In retrospect, everything is easy. But perhaps he was actually planning to fix that glaring bug, when someone interrupted him because of an issue on production, or to “take a quick look” at something which ended up taking the rest of the day. Or he was in the middle of crunch time and wrote this code at midnight in a caffeine induced high. Or he was just lazy and incompetent.

Whatever the reason however, ridiculing the other will not help him. Negative feedback works demotivating and alienating; repeat it often enough and he will stop trying and won’t ask for help anymore, because what’s the point.

And don’t even pretend that you’re trying to help. What you’re doing is for your own sense of self-importance; you want to show others that you can do better. If you really want to help someone in such a situation, it’s far more effective to talk with them privately, understand the situation and find out if there’s something you can do to help. For example, you could link him a relevant article or do some pair programming with him. It’s less visible, and less glamorous, but it’s better. And we strive to become better, don’t we?

So recognize when you’re being an ass, and don’t be. It’s as simple as that.

To conclude

So we’ve talked about speaking up, disagreeing constructively and not being an ass. This gives you the ability to influence decisions regarding the code you’re writing, helps you to create a constructive and positive work environment, and in general should position yourself as one of the engineers everyone wants to work with.

If you manage to get this down consistently, you’re suddenly not a guy who only writes code, but rather an asset to your team and company. You’ll be involved in more projects, because all project managers want you around; you don’t just write code, but you solve problems and make their lives easier, without even so much extra work. And because of your attitude, you’ll be able to learn and grow much faster than other engineers who consistently stick to their opinions. Whatever your goal in your career, these things will help you out in the long run.