We, Developers, are usually very smart people. We create things that revolutionize the world every day. We have to understand various industries in order to create valuable software that later helps people from these industries.
But there are a couple of important things to understand. We don’t do it by ourselves. We cooperate in order to achieve outstanding results that a single person wouldn’t ever do. This ability to cooperate with people from outside of our herd is something that distinguishes us from animals as Yuval Noah Harari wrote in his book Homo Deus. Moreover, we have to remember that we are knowledge workers. We spend whole days within our heads trying to fathom super abstract concepts, connecting the dots, and finding a way out of this maze.
Therefore, to be able to stay sane and to be famous for spectacular successes (instead of failures) we need to develop an additional set of skills, next to very technical skills like building web applications in React or creating Docker files. Let’s call them soft skills.
Oxford Dictionary describes soft skills as:
Personal attributes that enable someone to interact effectively and harmoniously with other people.
Although I would also extend this definition with
Personal attributes that enable someone to interact effectively and harmoniously with other people … and yourself.
There are many parts to the aforementioned definition. Therefore, I grouped them into specific areas, I believe can improve the way we as developers work, and listed them below.
1. Communication as the most important soft skill for developer
Communication is a very important part of proper cooperation. Without being able to clearly express our intentions we wouldn’t be able to work on anything together. The same applies to explaining our needs when we delegate work to someone else.
However, proper communication is very challenging. Probably all of us played Chinese whispers as a child, so we know how easily the original message can become distorted.
The process of passing a message from a sender to receiver involves encoding and decoding it to be able to pass it through a specific channel (let it be a voice or text message).
These two steps are where the message can become malformed. There are many communication barriers including differences in perception and viewpoint or cultural differences.
It’s crucial to make sure that both sides understand the message the same way. It can be beneficial to explain reasoning and intent of what you’re trying to convey, as Roger Schwarz wrote in his “Eight Behaviors for Smarter Teams”.
We can also improve clarity by using drawings and diagrams. An attempt to structure our thoughts into something tangible can be very beneficial for simplifying the overall message, but also can reveal gaps early in the process.
If the communication mainly goes in text, it may be very useful to simply call the person, or have a screen-sharing session. Or if that’s not enough, meet in person. There is a lot of information that is lost when using only text messages. The tone of voice, facial expression or voiced doubts.
For the cooperation to be efficient, we also need to remember about people on the other side of the communication channel. We can reduce a lot of friction when we keep in the back of our minds how other people can feel, and how we would like to be treated by them.
When we work on complicated problems that have many possible solutions, it is possible that we tackle the subject in a different way than our colleagues. We may have strong opinions about the approach and vice versa. It is important to listen to the other side with curiosity. This way we can give space for creativity as people are not afraid of being judged. And in some cases we can even learn something new, looking at the solution from different angles.
Sometimes our teams don’t function properly. There may be something in one of our teammates that irritates us. It’s worth giving him or her feedback. Many things are not obvious, so it’s good to say them aloud. And on the other hand, if we don’t receive any feedback, we can try to pull it from someone. This way we can be proactive about improving the quality of working together.
And feedback can also be positive so praise others when they deserve it. It is pleasant to hear nice words from time to time.
In a rapidly changing world in which we live, it is not uncommon to have remote teams spread across the globe. However, it is very easy to forget about those people when most of the team is located in a single office. We should remember to ensure they don’t feel alienated. When we have a call, let’s first make sure they can hear us well, when we have a question, let’s write it on slack, even though there are two people sitting next to you in the office. You give the remote guys a chance to answer, as their input is as valuable as others.
One thing that is very difficult for some of us is asking for help. When I started as a Junior dev it seemed to me that the seniors knew it all, and I should too. Or that I could deal with a problem by myself. But sometimes, this attitude can drive us crazy and cause to lose a lot of time. And the more you know, the more you actually see that it is impossible to know everything and asking for help is completely ok. And it should also work the other way round. We need to be patient and help others.
3. Task management
Our job is not simple. Almost all the time, we have to devise new solutions, solve problems, experiment, and figure out what to do next. Therefore, we need a sort of system to keep track of what is yet to be done. We can start simple with for example sticky notes, or a paper calendar, but as the list grows more and more, we’ll probably see a need for more well-thought-out tools working in the cloud so we can always be in sync wherever we are. Obviously, there is no approach that works for everybody, so we may need to test out different solutions first and see what works best for us. For instance, we can have a kanban board in Trello or use a todo app like Nozbe or Todoist. We can also combine them, so, for example, we can track tasks on a higher level in Trello, and break them down into specific day-to-day things to do in Nozbe.
But the tools aren’t a remedy for all the problems. We also have to use them correctly. We can apply techniques like for example GTD (Getting Things Done).
Basically, there are a few simple rules to follow to make the system work.
- We have to revise the tasks regularly,
- We have to keep a number of tasks as low as possible,
- We have to create the tasks so it is absolutely clear what is to be done
- for example when we add a task “create a blog” we are going to postpone it over and over again. But when we split it into 1. Do research on hosting, 2. Buy a domain, 3. Do research on a theme, etc, the tasks are more approachable).
- start the task with a verb like “do research”, “buy”, or “talk to”.
It is very common for us to complain about the management, to blame the project and to shrug saying there’s nothing I can do better with this crappy code.
But when we are in a project, we are a part of it. It’s us who create this crappy code. And if we see something not right in the project or we see a better solution and do nothing about it, we are complicit in the project deterioration.
We very often complain about multitasking and we end our work every day with a headache. But when we zoom in on the problem, it can turn out that it’s our fault too. We don’t make an effort to go into a state of deep work, and instead, we keep us busy all day with shallow work like answering slack messages. It’s very easy to blame everything around, that the requirements are not clear, and we don’t know what to do, but this is exactly where the work should happen. We should understand the problem, distill the knowledge, gather as many questions as possible, and break it down into actionable tasks.
Sometimes it is worth spending some time writing a human text instead of code, in order to understand the problem before we start smashing the keyboard with ifs and loops. Changing a word document is easier than ten thousand lines of interconnected code.
We also need to remember that we take responsibility for our words. If we commit to deliver something, then we need to do our best to actually do it. If we see that the plan is in danger we should bring the problem up early, so new decisions can be made. Other people rely on the commitments that we make, and vice versa. We should realize that next time we would like to complain that we cannot count on someone.
Oftentimes, we as developers feel that “business” has strange requirements, we don’t agree with them and feel that we would do things differently. But once we have our own thing to promote and take responsibility for it changes our point of view completely. Previously obsessed with refactoring code over and over, looking for a perfect solution for hours, now we see that the most priority is to ship something valuable, and to promote it so it can reach its audience. We can suddenly understand business requirements, see them and look at them from a different perspective.
5. Knowing yourself
Most of the time, our work happens in our heads. We have to think a lot. Because of that, it is easy to get stressed or even burnt out. It can be beneficial for us to understand our emotions. Asking simple questions like “Why do I feel like that?”, or “Can I do something about it?” can help us reduce our frustration and figure out some steps to take instead. These two questions are inspired by stoicism.
Another subtle detail that can reduce the frustration is when we switch the words that we use. When we start using “I want because” instead of “I have to / I must” we can quickly see the difference in our attitude. It releases the pressure we have in our mind as we knowingly take responsibility instead of constantly feeling forced to do something.
When we deal with a lot of mess in our heads when we are bogged down in our technical problems we should take a break and clear our mind. The simplest and quickest thing to do would be to just take a walk. And If we have a space for it, we can try meditation which can be very effective. Basically, everyone should find what works best for them.
Another thing that can be very helpful for us, is knowing how we think and tackle the problem. There are tools out there that make it easier for us. One of them is Gallup’s CliftonStrengths (formerly known as Clifton StrengthsFinder). It’s an assessment that helps discover our natural talents. They are not necessarily our strengths if they aren’t developed correctly, but having discovered them, we can work to improve them. Basically, they give us insight into how we come to grips with the problems naturally. This can be useful when deciding who’s working on what within a team as well as a better understanding of reasoning and intentions behind contradictory opinions.
When we are tired of chasing a perfect framework for building web apps or arguing about the microservice architecture, we can turn into other topics that are also very relevant to our profession, and that can let us grow not only as engineers but as team members. At the end of the day, we are just humans working with other humans. I hope this list will become useful for anyone who wants to broaden their interests and skills.