What kind of developers are these?

10 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.

Choosing the right tool and approach for the job is key. Getting this wrong can result in pain. Pain for your users who will have to employ workarounds to make up for poor user experience or broken and missing functionality. Pain for your workforce who have to develop on a constrained solution, creating and maintaining workarounds themselves to plaster over the gaps. This is technical debt accumulating, something normally associated with bespoke software development. Here it can happen because a not-fit-for-purpose COTS solution turned into a chimera.

This can also happen by choosing a fully bespoke build for a problem which didn’t need it. The cost of running and maintaining a bespoke service can be a drain preventing you from working on things of genuine value to your organisation and users. Monetary as well as opportunity cost. It can also lower the confidence in software development as an approach and discipline within your organisation, preventing you from creating or retaining an essential capability.

Poor choices create a legacy which makes the technology toxic to your organisation, something which Dave Rogers, former CTO at Ministry of Justice UK, covers in his series on toxic technology, explaining how insidious and corrosive it can be.

This can lead to a number of problems. “Failure demand” can generate unnecessary workloads in other parts of your organisation, as they rush to meet needs unmet by a poor solution. Not fixing the underlying causes and addressing the needs which were initially overlooked perpetuates a legacy of poor decision making. Doubling down on methods which have proved to be ineffective and opting for “quick fixes” are simply new coats of paints — especially when only making cosmetic improvements. This is all a legacy of debt with compound interest creeping up. All building pain.

Pain leads to an increasingly unhappy workforce spending most of their time fighting fires and keeping barely held together mission critical systems running, with no exit strategy in sight. Or following processes such as rekeying data, tabulating spreadsheets and other manual tasks which most people would prefer not to do. In that kind of climate, new ideas and innovation cannot exist. Transformation is not talked about. This can compromise the most important aspect of your organisation: its culture. It can lead to a breakdown in cooperation, siloed working, tribal behaviour and a blame culture.

Chances are if the initial solution choice and approach were driven by cost optimisation, it has now ended up costing far more and has proven to have been a false economy from the start. Not to mention the harder to measure cost to the overall performance, morale and health of your organisation and its people.

So how do you avoid these pitfalls? Or if you are experiencing some of this already, how do you improve things?

To begin with, the decisions around which approach and solution to apply should be made by those closest to the problem. It is very common in traditional, and even some otherwise modern organisations, for these decisions to be made by those on a board or committee — so those furthest away from the problem.

Next you want to think about capabilities. What capabilities does your organisation have? What capabilities does it need in order to make effective decisions about how technology should be used? Do you have the right capabilities for this or is the hard thinking being outsourced to a vendor? If you have the right capabilities, what ways of working do you need to empower them?

There are good answers to these questions, proven methods adopted by successful companies and organisations:

Working in user/customer focused ways. Working in small batches. Releasing early and testing assumptions. Iterating. But most of all, having long-lived multidisciplinary teams to own and solve problems. And then improve them. This is a long-term investment in capability — funding teams rather than projects.

It’s all about having options. Options to explore possibilities and solve a multitude of problems in many different ways. Which brings us back to developers. Software developers are key to this. Developers give you more options.

Having developers in your organisation will multiply your options for solving problems. Add to this agile ways of working, strong service design and a user centred approach with long-lived teams and you have the widest array of choices available. Which can still include healthy, sustainable and well informed usage of COTS solutions.

We live in an era of test automation, continuous delivery and cheap cloud hosting as a utility. All of that allows for cheap, safe and fast software development and deployment. Code can be released multiple times a day and is disposable, enabling experimentation. Developers can prototype and test unique solutions in code with real users.

The options are only limited by the development capabilities you’ve built in your organisation and how you have empowered that community. This is about owning what differentiates you, as James Stewart from public.digital describes in his post on why internet-era CTOs hire developers.

Building and growing a polyglot developer community pays in dividends. Having technologists around levels up your organisation and increases its reach.

What kind of developers are these?

Written by Mohiddeskit