This is how I write bug free software - I do all of these practices. Do you?
This scale can be used to measure an individual or the whole development team's professional strength and quality of work.
Yes
I quickly searched around and there is no such scale (or I could not find one) online. But that was not the reason I came up with it (I found there is none like it after I was done with it). Mark the date - October 18, 2017.
Software development industry has grown very quickly over the course of the last couple of decades. Back when I started, there was no big difference between developers, there were no different kinds of developers. There were not too many skills that a developer had to have to get the job done. There were not too many ways to get the job done. In simple words, our job was called "software development", and we all were called just "developers".
If you ever needed to hire a developer, it was always coming down to the same question - number of years in the industry. As long as the answer was satisfactory, you could rest assured that your expectations would be met. I call this - there was no choice.
Nowadays, with the highly evolved technology choice, on par with broad choices of architectures and concepts, we can distinguish different kinds of developers from each other. One can do a good backend coding, one can do good database design, one can do a good front end, one can do a good CI/CD, one can get your app into a cloud, one is a good technologist, and one is a good architect. Interestingly, developers are making these choices themselves, allowing to distinguish them from each other. But we are still in the middle of the evolving process of the industry, so there are many untapped territories yet to be refined, such as (among others more interesting to me) - how the consumers of the industry can leverage it better. There is a confusion on how to find or choose the right developer to get the job done. Furthermore, there is a confusion among developers too, thinking they are all the same and everybody can get the job done. But from what I can say - not in the same way, not within the same time, not of the same quality, and not for the same money - trust me on this, I'm a professional.
So, the purpose of the scale is to clarify what it means to be a good developer today, and to help consumers make the right choices (or better ones by knowing more). It may sound as a very subjective matter, but this all is based on well known best patterns and practices honored in the software development industry. The more of these are followed by the developer, the better the software delivered by the developer will be.
Without too much into the weeds - choices are picked completely based on my experience and opinion. I'm considered a top notch software developer and architect by many, so I know what I'm talking about. I personally practice all the items present on the scale, and I have made a difference for many teams and companies, like day and night.
In other words, in my opinion, if an engineer is good at these skills, that engineer is one of the best you can find on the market, regardless of what other skills (such as technologies) he/she can bring to the table. More about technologies below.
Yes, it's difficult to be a pro in all of these skills, it takes time and efforts, learning curves and a constant hard work. That's the reason most of the software developers I've met can hardly brag about half of these. There are pleasant exceptions and those individuals shine in the industry.
If you know all of these, you are a top notch. If you know at least half of these, you are not too bad already. But pay attention to the points they add to the strength when you select them on the scale. More about it next.
Points for choices are assigned based on factors such as difficulty level to learn how and to actually do it; and most importantly, return on investment in terms of the overall quality of the delivered software. All skills are measured in relative to each-other manner.
For example, Domain Driven Design (DDD) has the highest impact on the accumulated strength because it is directly targeted towards tackling complexity in the software, which is the strongest contributor to low quality of software, slowing down development pace early, and turning the software into a legacy sooner than later. Besides, it covers many patterns and advices which outweigh many others on the scale in size by 5-10 times. So, more strength points achieved by practicing DDD is absolutely deserved and understandable.
I didn't want to make the scale tailored to specific technologies, because then it would not be useful for all kinds of software developers and teams.
Besides, concrete technologies are just a matter of a choice and time, they come and go. Strong software developers (those obtaining high measurements on the scale) should be able to move from older technologies to other newer technologies over time without significant difficulties. Hence the set of skills on the scale that won't become stale - they are always needed and they are the most important asset.
It's still somewhat tailored to applications that have a professional intent - to solve complex tasks and not a quick code that can be written in a day or so. But that must be obvious without further explanations - otherwise nobody would ask for a better developer.
There are no items on the scale that every developer does.
For example, if you cannot write a code, then you are not a developer - you don't need a scale to say that.
This scale is to measure developers who do basic and obvious stuff, which does not require to be mentioned in any special way, and thus there is no credit for that.
Morale - just "writing code" is not enough.
The simplest way is to google each skill and learn about it as much as you can. It takes time to master so many things, but there are specific accelerators that you can use. e.g., hire experts who already know most or all of the mentioned skills, and learn from those experts. Alternatively, take training to educate the entire teams and organizations at the same time.
I have mastered all these skills and teach groups of individuals via my training courses: click here to find out more. If you need my help or advice, never hesitate to reach out to me.
Either way, it's through the dedication of time and energy that you can master all the mentioned skills over time.
The author of the above content is Tengiz Tutisani.
If you agree with the provided thoughts and want to learn more, here are a couple of suggestions: