Soft Skills in Software

Definition

If we have technical skills on one hand, soft skills would be on the other hand in the spectrum of necessary skills in software or in any occupations in general. Technical skills deal with the tool while soft skills deal with people. In most of software fields, there will always exist some factors of human in it. That is why I believe soft skills can be on par with the need for technical skills. Specifically, soft skills can be how you deal with conflicts in designing a new feature or project; it can also be how react to criticizes from your engineering manager; it can even be how you write your comments so the next interns can try their best to fix your buggy code. In other words, whenever there's some kind of human to human interactions, you'll probably need some kind of soft skills. You can understand it as the EQ (Emotional Intelligence) in software engineering.

The importance

Engineer like Gergely Orosz and John Ousterhout both agreed on the idea that the difficult part of software engineering actually comes from the people. Conveying your code to stakeholders, product mangers, peer coders, or intern is a highly difficult task to keep everyone on board with your ideas via just code. You maybe a "10x" productive engineer that can produce thousands lines of code in just a few days but if no one on your team can actually understand your ingenious implementation of this new distributed databases, it is unlikely to be a long-term meaningful product. Focus on the term "long-term", yes, your new database may be valuable for decreasing the latency of the current mass transactions load the product is suffering. However, you're unlikely to be working on it alone for the next 10 years; someone should be able to step in and improve and add new features to the code. Thus, this is a great example of both technical and soft skills. You'll need to be both highly technical to refactor your code into a better design so your team can understand it and you should get started on writing the docs and also the necessary comments to explain your code. I frequently see how developers consider technical and soft skills as mutually exclusive while I think they should be highly coupled together. Every technical decision should have some thoughts about the liability of this code in the future and the developers that have to endured them. In contrast, you should not always agree to the developer that tell you that he/she is going to rewrite our build system since it is too slow justt because he/she is a good person. You should consider the technical magnitude of the rewrite project and its revelancy to the product in general.

Resolving conflicts is also a common issues in software engineering and I am not talking about git conflicts in this case. The question about to write this tool from scratch or to use a software vendor; the question of to self-hosted or to use cloud services; the question of PostgreSQL or MySQL. Those are the constant polarizing discussions that developers may have among each others. Therefore, you can not just yell at the other person and tell them that they're dumb though that's the case sometime. Finding the middle ground should be the priority for every party. Whenever we're deciding between two or more options, I try to make a pros/cons chart with tradeoffs. This make the team see the clearer image since we're not always open minded people until the facts are right in front of us. Software engineering is sometimes really opinionated and subjective. That is when we need something like a mathmematical proof to settle the debate and contention. Just using tangible analysis of costs and tradeoffs can make any engineer be reasonable.

Conclusion

As software engineer, it is hard to talk to a human without start showing them your terminal setup and features demo but I think we should always try to write code with some future intern in mind. Ask this question, what if 5 years from now, an intern read my code and submit a pull request with the title "Legacy code got mogged" and he/she rewrite your code in the most elegant and simple way you can think of. I would feel proud but somewhat shameful too.