Which soft skills do a software developer need today? Which make him a good one, which make him an IT professional that can take the next steps? The last twenty years of professional software development I did always raised the same skills. Let’s go through them, in order of significance. You may add your comments if you feel either the significance is wrong or there are any skills missing.
Responsibility
This is by far the most important skill. A developer may lack some technical skills, he may fail in communication the right information in the right time, but when he does not take responsibility the product or project is doomed to fail. There is a big difference between the pure technical skills a developer surely needs to have and the attitude he needs to have to make a piece of software successful.
Take responsibility to make your story a successful one.
Communication
All teams have issues. All teams do great jobs. Nobody knows any facts when communication is not done proactively and in a sensible way.
- The sprint takes longer than expected? Tell the people that fact that they are prepared and can change their expectations.
- A feature is far more complex than initially thought? Get into the discussion with the product owner.
- The team doesn’t work together like the members expect it to? Talk to each other.
- The problem is too hard to solve it and time flies? Get the right people in the right place.
Talk about facts. Keep the focus on facts.
It is great to be emotional, but not in terms of being negative. There was exactly one point in time where I was shouted at in my complete professional worklife. It was on the phone. You know the reason? A misspelled English translation.
I don’t mind too loud people having great humour. I don’t mind all the quiet productive focussed people. That’s all great. Some people feel the pressure, so they are more negative. Ensure to create something good out of it. Get the right wording for certain kind of people. Younger people may have a different wording than older. You may not want to kill some less experienced people with your knowledge about using design patterns or algorithms in machine learning. One of the biggest part in communication is to listen. Take your time and listen. I personally considered this to be one of the hardest parts. But actually, it is not. It is often much more valuable than talking.
Communication is the base key for pretty much everything.
Teamwork
You can’t do it alone. It doesn’t matter how good a single developer is, when he makes a team nervous, the whole product has a problem.
- When one developer is also the first and always the last in the office
- When one developer always knows it better
- When one developer is used to insist on his opinion
- When one developer always complains about any issues
the project or product has a big problem. The team will not be that effective it can be. It will always be forced to talk about issues that maybe are not that important when they wouldn’t be raised all the time. I personally would always prefer an experienced developer that is a great team player over a guru that nobody can work with.
Musicians need to function together. Work like the greatest band you know.
Fail fast and change direction – ego management
Developers tend to know it better. Mostly that’s true ;-). When an architecture is not robust enough, when the code is not understandable for the next guy maintaining it, when a common methodic doesn’t apply to the actual needs of the product, fail fast. When the problem is understood, the ego of the people should not taken into account. There is never a need for finger pointing who is the one to blame.
Be as hard to yourself as to all the other people. Understand the mistakes you do. Everybody does some. Make the best out of it. And move forward. In the right direction.
Keeping an eye onto the big picture
Great developers don’t just do what they have been told to. They have the complete product in mind, may be even the complete architecture. They will raise the right questions.
- Does this UI implementation will fit the overall UX?
- Does this feature fit into the architecture? Will it be robust and maintainable enough?
- Are that really all the requirements?
Understanding the big picture makes developers fast. And much more valuable.
Keep the pace, the willingness to learn
I recently wrote an article about a former colleague of mine. How can one keep his pace? Actually it is pretty simple. Get out of the comfort zone. Nobody needs the people complaining about they do a certain thing for the last thirty years so why should it be done differently today? Get used to do new things. When being used to do new things all the time, it will feel like an addiction. That means, if you don’t get news things, you will be bored and unsatisfied. You feel like you’re standing still. The best developer I got to know had an intrinsic motivation. They do want to know it. There is no need to push them. They pull you.
When not going forward, you go backwards. Because all the others move fast.
Teaching and monitoring
It is a completely different story to teach oneself some kind of capability than to do it to other people. People may be have
- a different attitude
- different experiences
- different success stories
- different mind set
- different cultures
- different wording
When teaching people and monitoring their work, the humble developer/ architect has the chance to understand if principles that do work well for himself also are accepted by other people. There will be a lot of feedback given, negative and positive. Both are valuable, the positive will be motivating, the negative will make the developer/ architect think. I always appreciated the feedback, it doesn’t matter what it is. When there is never negative feedback it is possible that people don’t move anymore.
Teaching improves communication, improves eloquence. Makes you open minded.
Service-based
The customer needs support? The consultant has some uncomfortable questions? It doesn’t matter what it is, great developers do the right thing in the right time. Support has probably the same significance than documentation to most of the developers. For the tech guys that isn’t fun. But that’s not entirely true. The greatest thing about doing support is direct feedback. Yes, as with teaching and monitoring, you may get negative feedback. The customer can be upset because he’s in a hurry and things don’t work like they should. And some of the customers are not standable at all. Seriously. But that doesn’t matter. We need to be professionell. We need to do the job. We are the experts.
The important feedback is like this:
- Does the product/ project does what it should?
- Does the customer thinks it looks as great as the team thought?
- Does it have the amazing performance the testers measured before?
- Is the customer satisfied? – I always loved to get some positive feedback. That happens often. Depending on the software 😉
- Customers have ideas. These directly coming out of the business. Best feedback/ new requirements you can get.
- Is the customer unsatisfied? Why? Is it understandable? Did the team talked about that before? This is going to improve the software like the ideas do.
Keep your customers satisfied. They pay for your work.
Economic
Everybody knows the kind of developer that has too much time.
- Thinks it is more important to have used a broad range of technologies over the easyness of installation of the product.
- Believes all critical customers need to wait after the interesting feature had been implemented
- Doesn’t care about how good the program is sold. Is that his problem?
- Doesn’t care about how much money it costs to maintain, prepare and keep the environment the developers works in. It can be more. Sure.
- Doesn’t care about how long customers wait without any improvements on the overall product. Can he does anything about it?
Great developers know how to treat customers. Great developers know what it costs to develop. They know how to cut feature to deliver fast. They keep an eye onto what makes this product attractive.
Awesome write up thanks for this