There are tech skills and there are soft skills. Every programmer knows that. Tech skills are about algorithms, operators, classes, objects, and everything else they teach us in tech schools. Soft skills are about something else. What exactly? Difficult to say. Let's try to clear the air.

Here is a non-exhaustive list of soft skills I managed to find on the Net^{1, 2, 3, 4, 5,6}: empathy, open-mindedness, a willingness to learn, effective communication, teamwork, approachability, helpfulness, listening, patience, responsibility, critical thinking, problem solving, mentoring, attunement, clarity, curiosity, strategizing, lifelong learning, business mindedness, work ethic, judgment, ego management, commitment, accountability, creativity, adaptability, big-picture thinking. Phew!

Do you really understand exactly what these words mean? I don't.

I would actually suggest we replace them all with the "do the right thing" mantra and call it a day.

Smiling in the office and not cursing at a stupid boss helps, but this is not what soft skills are about.

I have my own list of soft skills though. I also strongly believe that tech skills are just a small part of what makes a good programmer, but being empathetic and ready to learn is not what the other part consists of. Of course, smiling in the office and not cursing at a stupid boss — helps. But this is not what soft skills are about.

They are about our ability to exchange deliverables. Tech skills produce deliverables, soft skills turn them into a final product, which is working software. Here is a short list, in no particular order:

Drawing. Talking works great when you're discussing your next vacation with your partner. In a software team your ability to explain your thoughts with a diagram seriously increases your usefulness.

Writing. Again, talking is great, when you have a chaotic team and an incompetent boss. In a more disciplined environment, your ability to put your thoughts in writing does make a difference for mutual success.

Reporting. A good programmer knows not only how to fix a bug but, more importantly, how to report it the right way, so that the project benefits. An ability to describe a technical problem in simple words is a crucial soft skill.

Volunteering. Open source is an important part of any software project. You have to know how to work with an open source community, by giving them something back for the software they provide. Sometimes you will have to report problems to them, sometimes even submit pull requests, and maybe even create your own open source products. You will need a lot of non-tech skills to do that.

Charging. Programmers make money by writing code. Very often projects fail because important people quit due to a money conflict. They don't know how to resolve that, how to manage their financial objectives, how to ask for a raise, or how to change the paying schedule. I blame programmers for that. We, technical people, have to know how to manage our financial relationship with our projects.

Relaxing. Many projects fail because its programmers burn out. This happens, very often, because they don't know how to manage their time right: when to work and when to relax. Again, I blame programmers. We have to know how to manage our own peace of mind.

Asking. Not your friends, but StackOverflow and other public sources. The software development world is getting global and the knowledge your project team possess is just a tiny fraction of what the world knows about the problem you are solving. You have to know how to ask the world. This is the soft skill you need to have to be a good developer.

Tweeting. Here comes your ability to share your thoughts and achievements in social networks. If you stay mute and net-social-phobic, you are not really helping your project. This is the skill you won't learn in a few days. I would suggest you take a look at my 256 Bloghacks book.

Testing. Here I mean not only writing automated tests, which is a tech skill, but an ability to communicate with testers, to make sure their feedback improves the quality of the software under development. There is a well-known developer-tester conflict, which good programmers know how to deal with.

Branching. Still working in a single master branch? Still an amateur. You have to learn how to use multiple branches, how to resolve conflicts between them, and what is the difference between merge and rebase. This is a soft skill, since it doesn't have anything to do with the quality of your code, but it seriously affects your professionalism as a software developer.

Failing. Most projects fail, one way or another. Technical failures are not the primary source of our troubles. We fail due to management incompetence most frequently. Good programmers know how to deal with failures, by provoking (aka Fail Fast), predicting (aka Risk Management), and embracing them.

Delivering. Continuous integration, delivery pipeline, build automation, staging, green/blue deployments, etc. — if you think that all these things concern the DevOps department only, you are wrong. You have to understand how your lines of code reach your users. The bigger the product, the longer the pipeline, the more people it involves, and the more soft skills it requires to be smooth.

Playing the Game. Any project is a part of a bigger political game, one way or the other. If you isolate yourself from intrigue, claiming that your job is to write code, you are not a good programmer. A good programmer understands where the money is coming from, who the primary shareholders are, and which ass to kiss and when.

Did I forget anything important?