Why Developers Should Embrace No-Code Solutions

Why Developers Should Embrace No-Code Solutions

by | 4 min read

The best line of code is the one you didn’t have to write.

As developers, we love writing code. At the end of the day, it is what we are paid to do. Isn’t it?

Whenever we see an opportunity to write code, we take it and usually bypass the more efficient solution.

Even simple things like parsing a file, instead of using a tested library, we create our own implementation. We might come up with some excuse that the library doesn’t have the feature that we need but in reality we just like coming up with our own solutions.

What most developers fail to realise, is that every line of code you write is a liability.

People get confused between an asset and a liability.

“Most people struggle financially because they do not know the difference between an asset and a liability.”

From the book “Rich Dad, Poor Dad” by Robert T. Kiyosaki

For most people, their biggest “assets” are their house and their car. However, just because they cost you the most money, doesn’t make them an asset.

An asset is something that puts money in your pocket. However, a house and a car both cost money, both in terms of bills, such heating and petrol, but also in maintenance costs. They are liabilities disguised as assets.

🚀 Are you looking to level up your engineering career?

You might like my free weekly newsletter, The Curious Engineer, where I give career advice and tackle complex engineering topics.

📨 Don't miss out on this week's issue

Your code is also a liability.

Every line of code you write requires more lines of code in the form of unit tests. It requires maintenance over time as more features are added to it. Even though you might put it off, it also requires you to write documentation.

Every line of code also has the potential to produce bugs which will waste your time, your team’s time and may even lose the company money and put your customer’s data at risk.

Every line of code you write adds to the complexity of your application. Sometimes we consider this as technical debt. The code was quick to write but adds to the overall complexity and makes maintaining the application a pain.

Some of this can be mitigated by writing better code. Writing code to the rules of the SOLID principle will help.

  • Single Responsibility Principle - Your code is only doing one thing, which means less code and no complicated branching logic.
  • Open Closed Principle - most bugs occur when making changes to an application. How many times have you added a new feature but inadvertently broken something else?
  • Liskov Substitution Principle - derived classes should be compatible with their base classes. This can help avoid unexpected consequences (bugs) in your code and reduce the maintenance needed in the future.
  • Interface Segregation Principle - by having smaller interfaces, you aren’t forcing developers to write more code (liabilities) for the methods they aren’t using.
  • Dependency Inversion Principle - decoupling modules will help when it comes to fixing bugs, as you are less likely to cause unintended consequences.

You might argue that the code is also an asset, as it produces an outcome that is desired and in some cases produces money as well.

The code however isn’t the asset, the solution is.

As I hinted at the beginning.

Our job as developers isn’t to write code, but to solve problems.

In some cases, the best solution is to not write any code at all.

There are so many no-code solutions coming out that it is getting harder to justify writing a solution from scratch any more.

IFTTT and Zapier can help with some of the simpler integrations between cloud services. The alternative would be to write a “simple” AWS lambda to perform the task.

However, you then not only need to write the code and deploy it, you also need to maintain it. Inevitably, API contracts will change or get deprecated and you will need to make updates which you wouldn’t have needed to do otherwise.

If you are worried about security and need a self-hosted solution there are quite a few available such as:

  • n8n - has a great UI and is easy to use.
  • huggin - a very popular open-source alternative good for basic scripting.
  • beehive - has a lot of ready-made integrations.
  • node-red - not the simplest to understand, but very extensible.

I am currently using n8n to republish my blog posts (like this one) to different platforms. It would have taken me a week to write an AWS lambda function attached to an API Gateway for the incoming publish webhook. Instead, I put the whole thing together in a day. It is not completely no-code, I still have some “code nodes” that format the JSON payload for the requests, but it is certainly less code.

No-code tools aren’t just limited to backend solutions, either. There are also tools such as Retool, which can be used to build out complicated UIs in minutes (and can be self-hosted).

Tools like these might not work for customer facing products, but they are great for replacing internal applications, which often require just as much work as the public facing applications but are often neglected by companies.

There is always going to be a need for developers to write custom code, but when thinking of a solution, not writing code might be the best option.

🙏 Was this helpful? If you want to say thanks, I love coffee ☕️ , any support is appreciated.


Idempotency - What it is and How to Implement it

Idempotency - What it is and How to Implement it

  • 22 September 2023
When designing an API it is easy to think about the happy path of our applications but if you want to build a robust application and keep…
5 Design Patterns That Are ACTUALLY Used By Developers

5 Design Patterns That Are ACTUALLY Used By Developers

  • 08 September 2023
High-level programming languages have been around since the 1950s and since then programmers worldwide have been using code to solve all…
Domain-Driven Design: Simple Explanation

Domain-Driven Design: Simple Explanation

  • 28 April 2023
When you are trying to build complex software it is important that everyone is on the same page. Even though most of us prefer to work alone…
Monolithic vs Microservice Architecture - Which Should You Use?

Monolithic vs Microservice Architecture - Which Should You Use?

  • 17 March 2023
If you are starting to build a new application or you are working on an existing one you may be wondering whether you should be building a…
Hexagonal Architecture: What Is It and Why Do You Need It?

Hexagonal Architecture: What Is It and Why Do You Need It?

  • 17 February 2023
We all do our best to try and write clean code that is going to be easy to maintain in the future. As time goes on and the application gets…
Snake Case vs Camel Case vs Pascal Case vs Kebab Case

Snake Case vs Camel Case vs Pascal Case vs Kebab Case

  • 06 February 2023
Coming up with names for things when writing software is hard. You need to come up with a few words that neatly describe everything you have…
What is CRUD? CRUD Operations in APIs

What is CRUD? CRUD Operations in APIs

  • 01 February 2023
90% of software that you use every day are what we call CRUD applications. Most of the time we are using them without even realising it…
Adding Inline Javascript to a React App

Adding Inline Javascript to a React App

  • 11 February 2022
Let me start this with a disclaimer, I am not a React expert and I am sure there are probably other ways to do this. If you know of a better…