Soft Skills for Software Engineers: Which to Adopt and Which to Avoid?

As a software engineer, I see a lot of people around me focus on growing their hard skills, but not on their soft skills. In reality, soft skills are just as important as hard skills. If you are curious about why they are important, keep on reading.

What is a soft skill?

A “soft skill” is an ability that you use in your relationships with other people, that defines your personality, your habits, and your emotional intelligence (EQ). In short, hard skills define what you can do and soft skills define how you can do them. People with good soft skills also tend to have higher EQ.

The value of a soft skill might change based on your occupation. For a software engineer, some need to be adopted and some that need to be avoided.

Me (right), Sherief (middle) and George (left) discussing a project.

Skills to Adopt

There are several skills that a software engineer must adopt to get higher on the career ladder. The most important ones, in my opinion, are the following;

1. Collaboration: Great software is a product of teamwork. Minimum team size advised by the latest Scrum practice is 3 and it can go up to 9. This means that you will have at least 2 other people in your team while you are doing development. You need to collaborate with your teammates to improve productivity and the quality of the code. For example, when you are writing code, you would want to name your variables properly, order files logically, and document them. So, nobody will lose time trying to understand what is going on. Also, you will expect the same from the others. A good collaboration is recognized by the fact that every part of the code looks like written by a single person.
2. Communication: The most effective way to achieve collaboration is through communication. If you are having a hard time discussing with people with different opinions, you will face difficulties in your work environment. In your daily work, there can be arguments about implementation details, class hierarchies, architectural decisions, etc. Because, in software engineering, there are several ways of doing a task. This causes people to have different views on subjects. To agree, you need to speak your opinion freely with no hesitations and respectfully without any contempt to others opinions. To achieve this, you must first listen to your colleagues and try to find out why are they thinking that. Are they lacking knowledge? Maybe they already know that your idea is better, but they have no time to implement that. If they speak nonsense, it is still better to listen to them. Because effective communication comes through effective listening. If you listen carefully, you can find the strong and weak points of their arguments. Then, you can propose an alternative or maybe find out that their solution is better. In the end, the team finds a mutual solution which everyone agrees on.
3. Problem-Solving: Next skill that a developer must have is problem-solving. During a workday, you will face several small problems along with some big problems. “A good software engineer might know a solution to a problem, a better engineer, however, is the one that can find a solution to a problem.” The reason behind that is simple. An engineer without problem-solving skill will encounter difficulties with problems which never occurred before. There is a really good book that I advise on this topic which called “Think Like a Programmer”. If you read it, you will understand that problem-solving skill is trainable, and you can improve yourself by simply studying it. Another part of the problem-solving skill is the ability to effectively search sources like “Google”, “Stack Overflow” etc. You must effectively deduce to the problem, divide it to smaller chunks and seek correct answers through the sources. As I mentioned before, software development is a collaborative process and there is a great chance that you will find help or a spark to the solution online. As a problem-solver, you just need to know where to look and how to look it up.
4. Being Eager: Next trait that a software engineer should have is being eager to learn new technologies. New topics and technologies come out every day and you must be open to learning them. For example, some years ago “DevOps” was not a popular term, there was no “Docker” or “Kubernetes”. There were “developers” who write the code, then there were “operation engineers” who handles the deployment process. In the past years, this has changed to a term called “DevOps” and now every developer eventually requires some knowledge such as “AWS”, “Azure”, “Docker”, “Kubernetes” etc. In the coming years, everything will evolve to “serverless architecture”. If a developer is not open to change, they will quickly be outdated and it will be harder to follow up with the changes around them or to change a job. Thus, a developer must always be hungry to learn new stuff.
5. PEC (Plan, Estimate, Commit) Skill: The most followed practice in our day is “Scrum Practice”. According to Scrum, the development process should have iterations that add value to the product in each iteration. An iteration is from one week to up to a month. They are called “Sprints”. At the beginning of each Sprint, developers do planning for the Sprint, make estimations on how many tasks they can complete and finally commit to them. In the best practice, the scope of a sprint can’t be changed and developers must deliver their commits. To do this, you require abilities to plan well, estimate accurately and commit to what you promised. I call this combination “PEC Skill”. Even though it seems easy, having a good PEC skill is harder than you think. In a Sprint, you come up to some impediments or tasks that have more priority all of a sudden. You must consider in your PEC, not only tasks that you can do but also stuff that might get into your way. Improving this skill takes time and you get better with every PEC you complete.

Skills to Avoid

1. Perfectionism: One of the worst skills you can have as a software engineer is perfectionism. As a perfectionist myself, I sometimes struggle with the development process. The reason for that is software development is a trade-off between time, quality and budget. Especially, if you are working in an agile environment, you constantly need to decide on what to trade-off. A perfectionist only cares about “quality” and under the restrictions of time and budget, they feel stressed. They always feel that they are not delivering that perfect code with 100% coverage. In real-world, nobody has time for that. At the end of the sprint, stakeholders won’t care about that perfect chain pattern mashed with a strong architectural design but lacking some functionality. They will ask questions like “Can users filter the products that we sell?” or “Do we have a great user experience?”. If you answer these questions with “No, but we have a perfect backend now, it will take very short to do those.” or “No, but we solved our problem with the deployment.”, I am sorry but you should start looking for a new job. They will give the project to someone who delivers what they want within time. Thus, avoid being a perfectionist and become an “optimal perfectionist” who finds the best outcome under given restrictions.
2. Being Specialist or Generalist: The best position you can achieve as a software engineer is becoming a “Trusted Advisor”. That means becoming an expert in a specific area such as “Java”, “JavaScript”, “Jenkins”, “AWS”, “Kubernetes” etc. So, whenever people have a specific problem, they will say: “Okay, we should ask this to Okan, he should know the best.” This builds up your reputation as an engineer and you will be a wanted person by companies. However, the downside of this is that you will have a hard time dealing with problems that require other skills then your area of expertise. It is called being “I shaped”. The opposite of that is being “ — (dash) shaped” (known as Generalist or better called; Jack of All Trades). Dash shaped people will have knowledge of many things but will never be sought for anything specific. The final choice is becoming a “T shaped”. As its symbol represents, it means that you have a shallow knowledge of many things but a deep knowledge of something. Thus, you will be sought for specific problems and have some knowledge of many other things. Even though you can select one of the first two, it is better in my opinion for a software engineer to become T shaped.
3. Staying inside the Comfort Zone: One of the worst things you can do as a developer is staying inside your “Comfort Zone”. In the software world, iteration never ends. It means that new languages, frameworks, tools, environments, etc. are being published continuously. If you don’t like or scared of learning or have a job where you don’t need to learn new technologies because you do the same things every day, it will affect your growth drastically. Opposite of that is trying to learn many topics at the same time and entering into “Stress Zone”. If you are a person who thinks that “Oh my god, there are so many stuff in the software world and I need to learn a lot!”, you are right. However, that doesn’t mean you should try to take on everything at the same time. Being a senior is a process. To achieve that goal, you need to use a famous algorithm called “Divide and Conquer”. You must separate what you want to learn into small chunks but not so small that it should keep you in between “Comfort Zone” and “Stress Zone”, which is called as “Growth Zone”.
4. Being Passive: People tend to call software engineers too much introvert and awkward. We have a bad reputation like that but in reality, it is the opposite. You need an ability to freely speak your opinions on subjects to take part in the development process. I am also an introvert. However, if think that the architecture doesn’t look promising and you have a better solution, instead of saying “Okay, this is not good. Why are they doing this?” when nobody hears, say it louder and explain your reasons. If you do that, either they will realize something new and you won’t continue working in a project that you hate or you will understand why they are doing it like that with counter-arguments that they propose. Nevertheless, it is a win-win status.
5. Bragging: As I mentioned in the first section, developing software is a product of collaboration and communication. This includes that you should never take credit just to yourself and never brag on anything you developed. Always remember that software development in our day is a collective history of the people who worked on and contributed to it. Therefore, you are building on a foundation. That history itself deserves the credit and you are a valuable part of it. If you fix a bug, tell them how you found the problem and how you fixed it but never say things like “Okay, I fixed that stupid code.” or “Thanks to my architectural design the application looks better.” Try not to use the words “I” or “me”, instead use “we” or “us”. Don’t forget that you are also a developer and you can make mistakes too.

Conclusion

Next time when you are doing a task, applying for a job or even when talking to a colleague, consider these skills in your mind and see if you have improvement points. Try to spend some time on improving those by reading articles, practicing or even talking with a professional.

Of course, these alone won’t be enough. You will also need hard skills and you must mix them in a harmony but don’t discard one for the other. They are both equally important. Nevertheless, I hope you do your best and see you in another post!