A few weeks ago, I interviewed someone who wants to become a developer. He was concerned about the fact that he wasn’t good enough technically and that he will never be. “What makes a great developer in your opinion?” he asked me. I answered briefly: “A great developer must have technical skills, it’s undeniable. But what really makes you great are your soft skills”.
This answer surprised him. And it may surprise some of you. But I insist: soft skills are important, more important than technical skills. Because once you get the right soft skills, technical skills come naturally. Let’s see which skills and why.
Let’s start with curiosity. That one is important since it will open new gates for you. Being curious means being willing to learn continuously and discovering new things. Never stop asking why things behaves the way they do or what’s going on under the hood. And when you learn, be sure to do it publicly, even if you can be wrong. It’ll bring many opportunities to you.
You surely have heard that perseverance is the key to success and this is especially true in development. We can quickly get demotivated by the amount of work or things to learn. There will be times when you’ll feel like you won’t progress anymore, when you’ll spend hours on that silly bug, when you’ll think you need to stop that side-project. But, you need to be patient and perseverant. Hang in there, you’ll gain more and more experience as you learn and build new stuff. Hard work always pays off.
(I’m not saying you should spend all your time coding. Breaks are important too 🌴)
In the end, solving problems and finding new ways to look at things is the core of our business. So it’s important for us to find new solutions and to look at things differently, to have another perspective on how things work. By improving products, creating new libraries or making things faster, we face new challenges and we get better at solving problems. And who knows, you could create the next big thing.
Finding such solutions require you to be proactive. Don’t be passive and wait for work. Take the lead of particular topics, it’s usually appreciated. However, when you do it, it’s important to always keep the big picture in mind. You should know what are the trade-offs to these solutions and where you’re going.
As an example, you could suggest to create an open-source library as part of your project. This would raise awareness around your project (or company) in the open-source world. Thus, you would be seen as proactive and accountable. One warning though, it’s not because you’ve taken the lead of a subject that you need to over-defend it and be too pride of what you’ve done.
Raise your hand if you ever met that person who is too much pride of his code, makes fun of others and doesn’t accept any critics. ✋
It’s not because you don’t know something that it means you’re incompetent. It’s not because you have a question that it means you know nothing. It’s not because someone else know less things than you that it means you’re superior to him. Take a look at this list of things Dan Abramov didn’t know in last December. Does it make him a bad developer? I don’t think so. You can be a successful developer and not know many topics as long as you have a domain of expertise and the right attitude.
You need to be humble, accept criticisms positively. If one is giving you legit feedback on your work, don’t take it as an offense. Learn from it and get better. If you’re working in team, introduce pair-programming and code reviews, you’ll gain a lot from it, provided you know how to communicate…
The hardest and most important skill to get in my opinion. It’s easy not to understand each other. On one hand, what we say can be different from what we think or what we wanted the other to understand. On the other hand, the other person can understand something different from what he wanted to hear and what he actually hears.
Furthermore, a vast majority of people don’t like listening to others. They just pretend they’re listening and prefer to talk about their stories, what they think or what they’ve done.
However, as a developer, you can’t behave that way. You’ll work with other developers but also with product owners or managers. So you’ll have to explain clearly why you disagree about that technical choice. You’ll also need to explain to non-technical people why setting up reminders and push notifications are not just “if statements”.
I noticed a recurring pattern when developers onboard on a new project. Some of them usually start with a refactoring which makes sense because it’s a good way to ship something and learn how things work. However, the refactoring process turns out to be a rewriting of the original code in another code style. The code is neither more performant nor more readable. And this kind of “refactoring” usually go along with a bunch of remarks like “What the f***?” , “But who wrote that?”, “Oh, we need to use that framework.”, “I don’t understand anything, that code is s***”.
Of course, a new look on the code is a great opportunity to make it evolve, but do it in a smart way. Provide feedback in a kind way. Be empathetic and be comprehensive. Put yourself in the shoes of the previous/current developers. Maybe they had to deal with deadlines, maybe they didn’t have the time to modify this legacy code or maybe they didn’t have the knowledge you have right now. There are plenty reasons why one can write awful code.
When you are able to empathize, it means that you can feel what others could feel, that you already think of what they could think, what they could face. Thus, it makes you more trustworthy since we know you are that kind of person. And it makes you a better communicator since you think about the expectations of your audience. The same goes for your app users.
I’m sure you know someone to whom you never ask help because you know it’ll be annoying for him. How do you feel in these kind of situations? I feel both idiot and stuck in these moments. Coding is hard. We encounter bugs everyday and it’s normal to reach out for help. So, be helpful. Take time with other team developers to help them in their tasks. Help people on Stack Overflow, write technical posts, be there for others.
It’s also a great idea to mentor someone when you have the knowledge. Not only you gain a deeper understanding of what you teach at that time but you also offer the opportunity for another person to grow. Be careful though, helping others can be time-consuming.
Would you give a task to someone unreliable? Constantly late? Overwhelmed? I bet you wouldn’t and that’s totally understandable. Well, you don’t want to be that person. It’s essential to be trustworthy. If you do your tasks in time, it means one can trust you and give you more responsibilities. But doing your tasks in time means being organized. For that, you can use to-do apps such as Todoist.
However, you should know when to say no to something. And that’s where communication is important. If you think you’ll lose your time in that meeting where you won’t even talk anyway, say it and make sure you are being understood. As an example, don’t say “That meeting is useless. I’ve got other things to do.”. You’ll be seen as agressive and overwhelmed. Instead, explain yourself and be opened to discussion: “I have the feeling my presence isn’t necessary to that meeting and I would like to fix that bug by the end of the morning. What do you think?”.
Getting all these soft skills deeply change the way you work. Once you get curious on a topic and get the mindset of a continuous learner, you get better at understanding how things work and you get more experience because you actually care about learning. Be creative and proactive, don’t just wait for work, take the lead. Sure, tasks can be daunting and the amount of work can demotivate you, but you need to be perseverant to succeed.
A developer usually work in team so it’s important to be egoless: accept criticisms, always seek feedback and learn from your mistakes instead of rejecting them. You also need to know how to communicate with others. Be empathetic, understand others’ point of view, truly discuss things. Whenever you can, help people and teach things, give workshops, tips, write articles even if you’re not an expert. Working in team implies that you expect things from your colleagues and we expect things from you, so be organized.