I keep hearing more and more that as a software developer you still need soft skills, that soft skills are more important than technical skills and so on. But no one really has any concrete ideas about what these soft skills actually mean as a developer. Everyone just keeps talking about them but I don't see anyone actually going into details about them with concrete examples.
Not to mention that a lot of people are just trying to make money out of these things and when they say that soft skills are important it is usually followed by some self advertising about their soft skills trainings. And to make matters worse, some of these preachers, pardon people, don't have a lot of experience in the development field. Some of them are not that good developers and then they say, that not only technical skills matter but also soft skills. Maybe they are not so great developers because they also don't have good enough soft skills also.
Now on to the concrete part of soft skills. One of the most used abilities that I noticed everyone more experienced in this field had, was drawing/sketching ideas/concepts/workflows on a whiteboard for other people to understand. I worked at a project for 5 years, and pretty much any new feature implementation design or architecture started out like this, some geometrical figures on a white board with some text and lines between them. Ideally they should be well drawn, so a little bit of drawing skills are required.
But drawing them is not enough. You have to explain how the components on the whiteboard interact and evolve over time. For this, you kind of require a bit of storytelling skills with clear steps/chapters that follow each other logically. Surprisingly, this is actually required more than I could ever realize and I ran into storytelling in some interview some time ago.
Another soft skill that is useful is the ability to pitch an idea/technology to other people such as other developers. This one is actually asked pretty often during interviews too, not exactly in this form but usually is pretty much boils down to this. This one was one of my biggest weaknesses during the course of my jobs so far. Sometimes I had good ideas that at the time the team didn't agree with them but later realized they would have been really helpful to everyone. Now if you want people to buy into your idea, it involves getting a lot of things right. And I don't think it's always straightforward.
Even with a lot of experience it's still a bit of a hit or miss. You might be unprepared to pitch some kind of ideas that you don't normally try to sell to people. For example, if you mostly designed and implemented backend things and then you learned frontend, you will have more trouble trying to convince people to follow your frontend idea than a backend idea.
And to get it right it usually involves a lot of things that you need to get right. Firstly, people need to understand what you are trying to explain to them. For this you have to use the right vocabulary and terms that everyone understands and is familiar with. Sometimes, especially when you are trying to explain some new technologies, they might have different names for the same things that developers are usually familiar with. Or just a different way of saying things than people are used with. You also really need the storytelling/whiteboard skill mentioned above.
After everyone understand your idea, you need to explain it to them how it will make their day to day lives better during development. Like for example if you are trying to get people to use a new front end framework, you could tell them that it already has defined a set of well make UI components that they can use instead of wasting time making them from scratch. Or another example would be, when trying to implement a new feature, that we already have another kind of similar feature which can me made a bit more generic and with some new components, it can do what we need. This will make us write less that half of the code that we need otherwise if we start from scratch. And some things would have already been tested and we know that they work. The hardest part here is figuring out how an idea will make the rest of the developer's lives easier with concrete examples. We say a lot that something is better, but when we are asked to explain why an idea is better with concrete, quantifiable arguments, things become much more harder.
Finally another important soft skill that I noticed recently is the ability to make an introduction to other people into something which can be a technology, feature of an application, service, separate application and so on. Lets say you pitched a new technology that you are familiar with to the rest of your team and they agreed to use it. What then? You still need to introduce the rest of the team to work with the new technology. Knowing about it and actually using it are different things. For example one way to introduce people to a new technology and how to use it, is to use pair programming.
You can take the lead and develop a new feature using that technology and document the steps live as you are doing them with another developer watching as you do it. You can explain and demo some things to that developer as you are coding, then let him code after that under your guidance. You can prepare even small exercises for this. If there is more than one developer, then you can develop a feature with that technology, then so a small presentation about that feature. Then other developers can develop new features using that technology having as an example the feature you just developed and presented to them. And there are lot of more way to do this. The better you do this exercise and the better teacher you are, the faster
Or in some cases you might need to introduce a new colleague to your project. This is really important because the time a developer spends learning the project and ramping up to actually start working in that project, is lost time. So this can be tricky to get right. Honestly, I still make mistakes here. You need to know how much to present to the new colleague, not to overwhelm him with information. There is a limit on how much information anyone can process and assimilate at once.
Secondly, you need to know what details to present from the beginning and what details to leave for later. Some details if presented too early will only confuse him. Also some learning material could be prepared for individual study that can be reused for other people too. Like for example, if you work on a bigger system with various components, a diagram of that system, the relationship between its components and a short summary of what they do, does wonders. These should actually be part of the documentation for the system. And the documentation plays a big role here, it's one of the main reasons it is made. So that new developers can study an application individually so that they don't use up too much time from the other developers.
So in a nutshell, you also need to be a teacher but a specific kind of teacher, a teacher for other developers. These developers already have some previous understanding of things that you can take advantage of.
Finally, I already mentioned it but knowing how to document things is something really important for bigger projects. This involves surprising things, like knowing English well or another widely known language in the company. And it's actually more than this, it's called technical writing and there are dedicated people for this sometimes. It involves knowing how to split the knowledge of the application into separate chapters/modules/features in the documentation. Then the knowledge of the application should be explained in a way that makes sense for the reader. I think something like an entry point should be identified which summarizes in simple words what the application does. Then from that point of entry, the reader should be slowly introduced into further details. There should be a natural and logical flow of things in the documentation. For example, if you write about feature A then jump to feature B which has absolutely no relationship to feature A, then jump back to feature A then this is a break of continuity and is bad for the user.
The documentation for each feature of the application should not be scattered all over the place, so if a user wants to understand a feature he needs to read in 10 completely separate places. Chances are he will even miss some of those places and he won't read about some of the important and required details of a feature.. This happened to me when the documentation was scattered everywhere.
When documenting something, you might use some specific terms that a new user might not be familiar with. You might need to explain some specific words that correspond to the domain of that application. Like for example if you have a medical application, then you might need to explain what an analyzer is and what it does before using it in the documentation.
And documentation should not just include text but also all sorts of diagrams such as a diagrams with the components in the application. Or workflow diagrams that explain the exchange of messages between components inside an application and what they mean in the context of that workflow. I think these are called sequence diagrams but a lot of people use other names for this.
In the end, there is a bit if misinformation about soft skills in this field of software development and it seems to me that no one has any concrete ideas about what soft skills mean, probably including myself.
Not to mention that a lot of people are just trying to make money out of these things and when they say that soft skills are important it is usually followed by some self advertising about their soft skills trainings. And to make matters worse, some of these preachers, pardon people, don't have a lot of experience in the development field. Some of them are not that good developers and then they say, that not only technical skills matter but also soft skills. Maybe they are not so great developers because they also don't have good enough soft skills also.
Now on to the concrete part of soft skills. One of the most used abilities that I noticed everyone more experienced in this field had, was drawing/sketching ideas/concepts/workflows on a whiteboard for other people to understand. I worked at a project for 5 years, and pretty much any new feature implementation design or architecture started out like this, some geometrical figures on a white board with some text and lines between them. Ideally they should be well drawn, so a little bit of drawing skills are required.
But drawing them is not enough. You have to explain how the components on the whiteboard interact and evolve over time. For this, you kind of require a bit of storytelling skills with clear steps/chapters that follow each other logically. Surprisingly, this is actually required more than I could ever realize and I ran into storytelling in some interview some time ago.
Another soft skill that is useful is the ability to pitch an idea/technology to other people such as other developers. This one is actually asked pretty often during interviews too, not exactly in this form but usually is pretty much boils down to this. This one was one of my biggest weaknesses during the course of my jobs so far. Sometimes I had good ideas that at the time the team didn't agree with them but later realized they would have been really helpful to everyone. Now if you want people to buy into your idea, it involves getting a lot of things right. And I don't think it's always straightforward.
Even with a lot of experience it's still a bit of a hit or miss. You might be unprepared to pitch some kind of ideas that you don't normally try to sell to people. For example, if you mostly designed and implemented backend things and then you learned frontend, you will have more trouble trying to convince people to follow your frontend idea than a backend idea.
And to get it right it usually involves a lot of things that you need to get right. Firstly, people need to understand what you are trying to explain to them. For this you have to use the right vocabulary and terms that everyone understands and is familiar with. Sometimes, especially when you are trying to explain some new technologies, they might have different names for the same things that developers are usually familiar with. Or just a different way of saying things than people are used with. You also really need the storytelling/whiteboard skill mentioned above.
After everyone understand your idea, you need to explain it to them how it will make their day to day lives better during development. Like for example if you are trying to get people to use a new front end framework, you could tell them that it already has defined a set of well make UI components that they can use instead of wasting time making them from scratch. Or another example would be, when trying to implement a new feature, that we already have another kind of similar feature which can me made a bit more generic and with some new components, it can do what we need. This will make us write less that half of the code that we need otherwise if we start from scratch. And some things would have already been tested and we know that they work. The hardest part here is figuring out how an idea will make the rest of the developer's lives easier with concrete examples. We say a lot that something is better, but when we are asked to explain why an idea is better with concrete, quantifiable arguments, things become much more harder.
Finally another important soft skill that I noticed recently is the ability to make an introduction to other people into something which can be a technology, feature of an application, service, separate application and so on. Lets say you pitched a new technology that you are familiar with to the rest of your team and they agreed to use it. What then? You still need to introduce the rest of the team to work with the new technology. Knowing about it and actually using it are different things. For example one way to introduce people to a new technology and how to use it, is to use pair programming.
You can take the lead and develop a new feature using that technology and document the steps live as you are doing them with another developer watching as you do it. You can explain and demo some things to that developer as you are coding, then let him code after that under your guidance. You can prepare even small exercises for this. If there is more than one developer, then you can develop a feature with that technology, then so a small presentation about that feature. Then other developers can develop new features using that technology having as an example the feature you just developed and presented to them. And there are lot of more way to do this. The better you do this exercise and the better teacher you are, the faster
Or in some cases you might need to introduce a new colleague to your project. This is really important because the time a developer spends learning the project and ramping up to actually start working in that project, is lost time. So this can be tricky to get right. Honestly, I still make mistakes here. You need to know how much to present to the new colleague, not to overwhelm him with information. There is a limit on how much information anyone can process and assimilate at once.
Secondly, you need to know what details to present from the beginning and what details to leave for later. Some details if presented too early will only confuse him. Also some learning material could be prepared for individual study that can be reused for other people too. Like for example, if you work on a bigger system with various components, a diagram of that system, the relationship between its components and a short summary of what they do, does wonders. These should actually be part of the documentation for the system. And the documentation plays a big role here, it's one of the main reasons it is made. So that new developers can study an application individually so that they don't use up too much time from the other developers.
So in a nutshell, you also need to be a teacher but a specific kind of teacher, a teacher for other developers. These developers already have some previous understanding of things that you can take advantage of.
Finally, I already mentioned it but knowing how to document things is something really important for bigger projects. This involves surprising things, like knowing English well or another widely known language in the company. And it's actually more than this, it's called technical writing and there are dedicated people for this sometimes. It involves knowing how to split the knowledge of the application into separate chapters/modules/features in the documentation. Then the knowledge of the application should be explained in a way that makes sense for the reader. I think something like an entry point should be identified which summarizes in simple words what the application does. Then from that point of entry, the reader should be slowly introduced into further details. There should be a natural and logical flow of things in the documentation. For example, if you write about feature A then jump to feature B which has absolutely no relationship to feature A, then jump back to feature A then this is a break of continuity and is bad for the user.
The documentation for each feature of the application should not be scattered all over the place, so if a user wants to understand a feature he needs to read in 10 completely separate places. Chances are he will even miss some of those places and he won't read about some of the important and required details of a feature.. This happened to me when the documentation was scattered everywhere.
When documenting something, you might use some specific terms that a new user might not be familiar with. You might need to explain some specific words that correspond to the domain of that application. Like for example if you have a medical application, then you might need to explain what an analyzer is and what it does before using it in the documentation.
And documentation should not just include text but also all sorts of diagrams such as a diagrams with the components in the application. Or workflow diagrams that explain the exchange of messages between components inside an application and what they mean in the context of that workflow. I think these are called sequence diagrams but a lot of people use other names for this.
In the end, there is a bit if misinformation about soft skills in this field of software development and it seems to me that no one has any concrete ideas about what soft skills mean, probably including myself.
Comments
Post a Comment