I write soft every day, I worked as a software developer, worked as a tech lead above other software developers, and saw different professionals with different attitudes to work, and different personality traits, and their differences rarely correlated with their professional level because of their skills.
Then what skills really should have for a mature software developer? We will dive in to find out.
Software Developer
In short words, a software developer - is a person responsible for transforming requirements into certain features.
This short definition can be uncovered to other responsibilities f.e.:
Every feature that is implemented by a software developer must be supported on the production - maintenance of the features
Every feature must be tested before it will be delivered - conduction of the software testing
Every soft and feature should be written in a specific programming language* and if you work in a team with other developers it leads to one thing - code review.
And much more.
Of course, you can add your own set of responsibilities that depends on the area of your work and it can slightly change the details but not the whole picture.
However, this isn't about the definition of the software developer but rather about the skills that a software developer must have to be a good software developer.
*There are possibilities to implement a feature without writing a code, it depends on the area of software development
Hard skills
There is no need for a long introduction to the description of the hard skills. Nevertheless, to be on the same page here is the short definition:
Hard skills are job-specific abilities or knowledge learned through education, hands-on experience, or training that are being used to perform a certain job, e.g. software development.
There is no doubt that a mature developer has to have a strong set of hard skills, although it can vary between different areas of software development, still it includes knowledge of certain programming languages, data structures, mathematics, databases, etc.
Possible to track, possible to set up goals, possible to determine a level of skill - all traits of hard skills.
Albeit hard skills are only a part of capabilities that should be known by the software developer.
Soft skills
Soft skills represent how effectively a person can interact and work with other people.
However soft skills lack most of the traits of hard skills.
One of the difficulties is the measurability of soft skills. It can vary just because of the people who measure the level of those skills and, in some cases, it looks like an arbitrary evaluation without a common scale.
Another difficulty is that this group of skills is harder to learn, improve and work with because of its amorphous nature. Nevertheless, without it, you can't effectively (and I may say you CAN'T) work as a software developer because good soft can't be made without effective communication and interaction in the team.
And one more thing:
It is easy to notice when a developer does have bad soft skills rather than when they are good.
Borderline skills
However, both of the previous terms don't cover borderline skills that can fall into the area of soft skills and in are of hard skills, simultaneously. There is a reflection of it in the next example.
Ability to effectively conduct a code review that will have a positive impact on the code*, where does it belong to? It is definitely not a soft skill because it can't be applied to any area outside of software development, nevertheless, it can't fully fall in the area of hard skills because you can't conduct a good code review without a sufficient level of communication skills.
This looks like a simple dilemma and, I found one solution for it, and that is why I reorganized skills into certain groups and named them Development skills.
*Through my practice, I faced different types of code review and there are some examples of when code review can make code worse
Development skills
Each of the furtherly mentioned skills deserves its own disclosing article with examples, descriptions, and much more but it will be in the subsequent articles.
Code review
Almost everywhere where software is being made exists a code review as a part of the development process. You can't avoid it, you can't skip it, you mustn't do it in a bad way, you just should do that.
Albeit what is a good code review? When comments fix performance issues, improve code readability, reduce code complexity, mark discrepancy between requirements and implementation, written without personal attitude with greatly stated arguments without water, and the reviewer spent as less time as possible?
All of these, together.
As a review, you must be drawn in the code that was written by someone else, read a task, understand a problem/feature that is stated in this task and dive deep into the mess that is made by someone else.
In my experience, good code review can save tons of time that will be spent because of bad code for debugging, and solving issues when it is already in production and it will take less time from the QA side to verify it.
Effectiveness
I can't avoid a definition of effectiveness, by original meaning, it means how much time you spent to (reach a certain goal)/(or complete a certain task). Less time is better, of course. But there is a lack of one thing - energy.
People, usually, don't work 8 hours per day, this is an ideal world where a person can effectively and evenly work during all 8 hours. We don't speak here about crunches because when you take away energy for a certain period there will be a time to pay it back and it costs more than you might think. Therefore, you have less energy than need to effectively work 8 hours a day and it is a skill to spend as less of your energy as possible to achieve a goal.
Then a definition of the effectiveness will be:
Effectiveness means how much energy a person spent to (reach a certain goal)/(or complete a certain task).
Responsibility
Responsibility has several descriptions: to be reliable, trustworthy, mental accountability, etc. But preferably for software developers define it as below:
Responsibility is the ability of a person to be reliable in a professional area and to be accountable for their own decisions.
To notice the lack of this skill isn't instant action but rather an accumulative thing, step-by-step small actions and decisions of the developer in critical situations with his own feature and attitude to mistakes can reveal it.
If a developer falls into an area of over-responsibility it can burn him out and he won't even notice it till the end.
As well as if the developer falls in the opposite - people won't trust him, and can't rely on what in the end leads to ineffective work with a team.
The developer's responsibility won't end at the moment when the code is merged in a development branch, work on this feature from requirements to production is the real responsibility.
Impact definition
Software developers as mentioned below aren't about working with tasks but rather work with impact. Yes, work with impact on every stage of the development of the product.
For certain requirements and tasks you can even say "Do we need that?" and don't implement a feature at all and still you will have an impact on the product because this feature won't be there.
And this is only the start of impact definition, but what about questions that you may and may not ask? What about impact evaluation on the post-deployment stage when you must understand what impact it took in the product*?
Without that, you won't do your job because working only through the philosophy "I did a task - I did my job" is a dead end.
*You can use analytics, internal metrics systems, feedback, or whatever to evaluate an impact on the post-phase.
Communication
The biggest part of our work, especially at certain stages of development.
Without effective communication, you can drown in long meetings, infinite correspondence, and wrong decisions. All of it leads to wrong answers to wrongly asked questions, and in the end, you won't make your job at all.
You must convey your thoughts, ideas, and decisions effectively, and spend less time on them as possible. And don't forget about the main tool you use - language itself.
The rightfully asked question is half of the answer.
Estimations
Easy to describe, hard to achieve.
Without accurately made estimations teammates can't rely on you, managers can't effectively plan sprints and synchronize teams and the whole process is suffering.
Wrong estimations work on both sides, if you are too optimistic, either you will crunch to complete your task right to the estimated point or you won't your work complete to this point at all, in both cases the whole development process may stuck.
On the other hand, when to be too pessimistic you can face a situation when you completed your task too early but there are no other tasks for you which also leads to problems for the development process.
Taking into account as many variables during estimation as you can is the only way to precisely make it.
Problem-solving
Out-of-the-box thinking, the ability to approach from different sides to the problems, knowing whom to ask and where to find information to solve a problem, and the capability to stay for 5 minutes and think about what you are doing right now, all of it are exists in the area of problem-solving.
An ability to effectively use Google, nothing more but nothing less.
Conclusion
While software development is an already established area, at the same time the clarification of the skill set that a developer should have is described in several ways.
Maybe this reorganization of ordinary skills will help you in your work, for software developers to understand your strengths and weaknesses and for the team lead or tech lead to pay attention to those and find points of growth for developers.
But what do you think? How do you prefer to group skills, evaluate them and improve?
Top comments (0)