Speciality vs Generality

Creating software is no longer the small business where you could learn it all and be a full expert able to do everything yourself. The business has grown and has become mature, being an expert in every field has become impossible. This leads us to dilemma of either specializing in a subset, leaving you clueless about the rest, or should we generalize and learn a basic understanding of all of it. This will depend on what your responsibilities are, as the ICT offers a vast variety of jobs. In this blog I will talk about the advantages and disadvantages of both as a software developer.

You can specialize in two different things:

  • A library or technology.
  • Part of the software you are developing.

As a software developer you will automatically gain experience with both as you use them more and you write more code. For the first case, calling yourself an expert often requires a bit more work as just knowing how to use it is not sufficient. Knowing how to get the most of it, best practices and performance tricks is a requirement to call yourself an expert. But learning to use a new library or technology is more beneficial as it can be used on new projects or when changing job/company.

Becoming an expert in the code you write happens automatically, you designed it, you came up with it, so you know how it works. After a while the details may get a bit blurry, but you should be able to refresh your memory pretty fast. If not, then you didn’t write very clean code. A hindrance in being ‘specialized’ in the software you write is that you are probably not the only one writing code. As software development is a team effort in most cases, you can find that after a while the code has changed from your initial implementation. Staying up-to-date with the latest version can be done by being involved in every pull request, or by being the only person responsible for changing the code.

From a team perspective you often don’t want just one person knowing about your product code. Sooner or later things will go wrong: be it that the the developer is on a holiday, has left the company or for some other reason he is not available. In all these cases you end up with a piece of software nobody knows how it works and what it does, changing code without knowing this is asking for new bugs and regressions. Someone will have to invest time and effort in learning the software, causing delays in the project schedule. Knowledge sharing should be done to avoid this situation at the cost of some overhead of keeping everyone up-to-date.

The same holds for the first case. If you have a team where only one person is specialized in some library or technology and this person always does everything related to it, the same situation could occur. A team should always have enough people that are experience with the libraries and technologies used.

This sounds obvious, but there are a couple of reasons why this is harder than it sounds. Developer often feel responsible for the code they write, they are the owner of it. Letting someone else modify it can cause friction as opinions differ on how to implement something. If the new code does not fit into their initial design they can see the changes made as a degradation of the code. Having a team where people discuss the design will lead to more team-owned code, every developer will feel responsible for it as they have participated in the design. At the same time each developer has a clear understanding of the design choices and will less likely write code that does not fit in.

As there are too many technologies and libraries, it is impossible to be an expert in all of them. This means that a team has to have a good combination of people such that they have the right specializations, in smaller teams finding this combination often leads to one person being responsible for a set of technologies. A developer that is specialized in something will also solve those issues faster, which means a decision has to be made, should we let the expert do it good and fast, or should we let someone else try it and gain some experience? The expert will of course be involved during the process to assist. Essentially it is a choice between short term and long term benefits.

There is often a reason why the developers have specialized in some technology, most likely because they have a passion for it, it is just what they like doing most. Telling them to do something else to gain experience with it can lower the mood. Other developer just don’t like working outside of their comfort zone, but this is not a good situation as technology changes fast and hanging on to what you know will make you outdated really fast.

Having developer that can work with some technology and have some understanding of it instead of really being specialized in it, allows for a more freely use. They can have knowledge about more different technologies and can be used in more situations. A team of developer that have not specialized, but generalized in a lot of technologies makes it easier to spread the work load, as everybody can do every task.

In the end there probably isn’t a clear answer to what level of specialization you need. The best solution I can think of is that you specialize in a couple of technologies and generalize in a lot more. This makes you versatile, making you available for more jobs and projects, while at the same time your specialization can give you a critical advantage in the fields you are most interested in. You will be asked for your opinion and you can make big decisions.


Leave a Reply


WordPress.com Logo


Google photo


Twitter picture


Facebook photo


Connecting to %s
