Developers are better with No-Code

A short while ago, one of our customers asked me to dive into their middleware and integration tool (Xentral Connect) to have more redundancy in people that can maintain the existing workflows. The first look was quite pleasant. I was already familiar with the general idea of enterprise middlewares and have lots of experience with using message queues like RabbitMQ and databases. With such a middleware software, you can connect to various sources, pull data (or receive pushes from source systems), persist them in a centralised location and publish them to various target systems (or allow targets to pull the data).

Automatically, my brain started thinking about the implementation details of the software: How are datastructures persisted after users create them in the UI? how are joins between data structures executed? What might hide behind UI flags like "index" and how would they affect the existing data in a data structure once the flags are toggled? After playing around a bit, the answers became obvious: Datastructures become tables in some database and using filter operations is translated into standard SQL-like `WHERE`-queries. The index flag on a column becomes a database index that allows much faster filtering on the given column.

As a result, this knowledge allowed me to build a more performant workflow that uses indexed columns for lookups and that uses standard best-practices from system design like idempotent messages, at-least-once-delivery and delta-loading. Could a non-developer have achieved the same result? Maybe. However one thing is certain: These No-Code tools have a limit. That's why all of them offer the escape hatch of custom code steps. And as soon as someone uses these steps, they more or less become developers, even if they are not using an IDE and have to make the same experiences to learn the craft.

This experience made it clear to me why I, as a developer, am not afraid of No-Code tools or AI or other buzzwords that promise the demise of the need for developers. As developers we learn principles that apply across programming languages and software solutions. And by still understanding these principles we become better and more efficient users of approaches that hide these details under abstraction layers. So maybe in 20 years, our job will look a bit different, maybe we will no longer be typing characters and words of specialized programming languages into an editor, but we will still use our understanding of modelling the real world in technical systems.