There’s been a clear trend going on for many years now known as ‘No code’ or ‘Low code’.
This essentially describes tools or platforms that provide you with a GUI that abstracts away the underlying technicalities so non-technical users can use powerful software.
Doing this has been a huge benefit to business since the addressable market for Excel-like tools is 1000x greater than Coding-like tools. Business users benefit as well since they effectively leverage their skills and become a more valuable employee.
So Why Learn to Code?
It’s simple. When we talk about No Code or Low Code it just means that someone else has written the underlying code and abstracted the problem into a more easily understandable form. This usually ends up in the form of a component, tool or function you can use in the platform.
This is great for maybe 70-80% of use cases. It’s fast to develop, simple to use and has a quick learning curve using pre-built components.
However as you become more experienced you’ll discover the more problems you encounter the greater the chance that your particular use case has not been covered.
The solution tends to be adding complexity while trying to work within the constraints of your particular tool. Which in turn defeats the object of using the tool in the first place, since the whole idea is they are easy to use and understand.
This leads to the red area in the chart shown here, the part I called Platform+. This is a dangerous area as you’re pushing the limits of what your tool can do while making the solution overly complex.
Platform - safe Platform+ - might want to rethink Code - just code it
But how do you know when you’re ventured into the red area? A few pointers.
- An colleague experienced in your tool of choice can’t understand what you’ve done in 10 minutes
- You rely on a patchwork of external tools, batch files, scripts, other executables linked together
- Linked dependencies and applications become a spaghetti like construction
- You end up using brute force on problems (parsing html and xml like it’s a string…)
- Your solution is hard to update
- You think the solution should be easy but it proves very difficult to achieve
For me the last point is probably the most telling sign. If I know how to solve the problem from an architectural point of view but find it really hard to actually create the solution then it’s a warning flag in my head..
The Happy Medium
You should use no or low code tools as much as possible. Development time is reduced considerably and ease of use means they are a huge benefit.
Having aid that I do think it’s important to recognize the limits of whatever tools you’re using and consider if it’s really the best solution or just the best solution you’re able to make with this tool.
Knowing how to code effectively gives you superpowers and increases the surface area of possible solutions.
Consider coding to be like an extended toolbox, you don’t always need to open the big toolbox but it’s great to know if you do you’ll always find the tool you need to fix the problem.