What kind of developers are these?

7 min readDec 5, 2020

There are many types of developers and developer roles. Programming language specific developers, e.g. Java developers, Python developers, Ruby developers, Go developers.

What differentiates these developers from one another is their programming language of choice, paradigm (object oriented, functional), preferences on the aspects of application and systems development they enjoy (UX, backend, APIs, infrastructure etc) and toolchain “lifestyle” choices, i.e working in IDEs or on the command line. There may also be philosophical leanings on software licensing, i.e proprietary or open source.

What unifies these various developers is their analytical problem solving skills and a deep understanding of algorithms, data structures and logic. Additionally they will have skills and good practice around testing, version control, architecture and infrastructure. The best developers tend to be well rounded “technologists.”

Seasoned developers end up being polyglot. They are able to work in more than one programming language and can pick up new ones. This is their superpower for having that grounding in algorithms, data structures and logic. The fundamentals of computer science are ingrained through a cerebral alchemy of experimentation, practice and experience. Preoccupation with specific code syntax and idioms recede as problem solving musculature develops.

Developers hone their skill and craft through experimentation, collaboration with other developers, curiosity and an innate passion for reading, writing and tinkering with code. Many started very early in life while others have discovered a new passion mid-career. Age and background are not limiters, there are examples of incredible developers starting at all stages of life.

The best developers underpin the great successes and achievements of the modern era. The dominance of the big tech companies is owed directly to developers, and many if not most, of the founders of those companies were also developers who wrote the code that propelled their companies to success.

So what about other developer roles? You may have seen other roles with “developer” in the title:

Dynamics developer. Sitecore developer. Wordpress developer. SharePoint developer.

What kind of developers are these? What do they do?

They also solve problems and develop solutions. They develop solutions using the features available in the commodity off-the-shelf, or COTS, software solutions they are specialised in. They do this with a deep knowledge of the features available in the product and how best to configure them to bring about a desired outcome.

They are product configuration specialists.

There are many sophisticated and highly configurable COTS solutions on the market which solve a range of problems. Good product configuration specialists will be able to develop solutions quickly and easily using these products. Many of these products can also be extended with custom code, so some specialists may also be software developers. This may be limited to a domain specific language, a small programming or scripting language designed for the purposes of customising the COTS solution, or they may be well versed in one or more general purpose programming languages.

Product configuration specialists are proficient in a particular COTS solution and its ecosystem of plugins and extensions. They may specialise in several products from a vendor’s vertically integrated offering. They could have a certification from the vendor or a third-party backing up their credentials for proficiency in the use of the COTS solution. There is an industry around training and certifying people for every market leading COTS product, delivering highly skilled, well credentialed professionals.

This is clearly beneficial. Well known and mature COTS solutions, established vendors with well defined support models and service level agreements along with a thriving market of skilled and certified specialists.

So which should you hire? Developers who write code in general purpose programming languages, or developers who configure COTS solutions?

It depends on what you are trying to do and the approach you are taking to do it.

Using a COTS solution may reduce time to market with “out of the box” functionality and minimal in-house expertise needed for operating the solution. Those can be positives.

On the negative side, COTS solutions will have certain limitations. Even the most sophisticated products can only be adapted to so many problems. They will be constrained by the range of features offered and the ways in which functionality can be configured or customised, and how expressive that means of configuration and customisation is.

You or your organisation may feel the need to compromise and choose configuration over customisation, limiting possible solutions to the scope of the features afforded by the COTS products you have selected. Actively limiting your options. This comes with some risks.

Sean Boots from the Canadian Digital Service talks about “Fake COTS” and the one-day rule. Chances are if a COTS solution takes months or more to configure to meet your needs then the “out of the box” promise may not be holding up as advertised. You may have to extend and customise the product to a point which renders it unrecognisable from the original vanilla product. Is it truly “out of the box” at this point or something bespoke requiring investment in order to maintain? “Big ball of mud” is normally levelled at solutions engineered in code, but the same can easily apply to COTS solutions over time.

If the COTS solution does indeed meet your needs, how closely does it do so? A common problem is the “last 10% trap” where most of your needs may be satisfactorily met, but that last 10% isn’t achievable due to some limitation of the product. That last 10% could be the essential functionality or element of critical user experience which makes or breaks the service for your users. This can result in creative workarounds by the users or your development team, which again leads to maintainability issues.

If the answer to any of the above is “yes” then you are likely operating in a complex and changing environment where requirements are continually being discovered. A COTS solution may not afford you the agility and flexibility to respond to those changing needs.

However, a well known and well defined problem could be solved by a COTS solution just fine, especially when you are confident needs are not going to change. An office productivity suite, a chat or collaboration tool, a payroll system. These are usually good examples of well defined problems which can be solved with effective out of the box solutions, for which many exist.

This is about recognising where the “heavy lifting” is. Where is it differentiated enough to need an experimental, iterative and bespoke approach? Where is it undifferentiated, well known, well defined and generically solved many times over? Recognising this is critical when making decisions around build vs. buy and whether to outsource or insource.

What kind of developers are these?

Written by Lulujibon safe