It wasn’t easy, either. Everything I had known and valued was being turned upside down. From taking pride in my code quality, or the long hours spent to solve a very difficult task (especially before the Stackoverflow era). I was now going into a space that did not value complex coding and elegant OOP anymore - it valued results and, more importantly, fast results and fast time-to-value.

At that time, the term low-code didn’t even exist. Explaining what I did to my programmer friends, recruiting other low-code engineers and ‘converting’ them from conventional programming to low-code was especially challenging.

So here’s what I’ve learned during my 12-year journey in this discipline:

Low-code isn’t easy. If you think that conventional programming is tough and that drag-and-dropping a bunch of nodes on screen will make it easier, you’re in for a surprise. Software engineering is, and will remain, the process of engineering software, no matter what tools you use. I don’t agree with the latest trends of citizen developers and disposable apps. We might get there, eventually, but we’re not there yet. It might be very easy to develop something that you will only use yourself, but it will still be very challenging to develop an enterprise application. On top of that, conventional programming has so many design patterns that you can just google the pattern’s name plus the OOP language of choice and there you have it. With low-code, you will have to re-invent it yourself or go directly to the platform’s developers to find out. When’s the last time you emailed a Microsoft employee to find out how to implement a Singleton in C#?

Low-code is fast. So if it’s not easy, what is it? Well… It is fast! Blazing fast, if you compare it with any other type of software development. It helps you get to market faster and stay ahead of the competition. An added benefit is that the business analyst can now look into the diagrams (what used to be code before) and understand it. You no longer need so much designing, because the software itself becomes the design. That point where the software architect would stop designing and hand it over to the coders to start their work has now become the point where development is almost finished. I’m not saying that you no longer need designs, but they will be more high level and faster to create.

Low-code isn’t for everyone. If you’re getting your work satisfaction from being sucked into solving a complex technical problem, then low-code is not for you. These problems still exist, but they appear less often. Instead, you should draw your satisfaction from quickly delivering a much higher amount of value and a faster feedback cycle. If you like interacting often with your customers and wow-ing them with how fast you can build the next feature they requested, that’s when low-code is for you.

Low-code isn’t for everything. Not every software can get built with low-code and you’ll have to select the right platform for your exact need. Next to that, low-code doesn’t work for huge applications. It’s made for small to medium apps that will get built quickly. Be prepared to learn multiple platforms over your career. The platform might change with every new type of application that you build, but rest assured that you will be able to use your experience when moving from one to the other and adapt quite easily, because they all follow similar guidelines.

Low-code doesn’t make your life easier. It actually makes your customer’s life easier. For you… You will have to figure out many things: CI/CD pipelines with quality gates, automatic documentation, peer (code) review, automatic code scanning, and unit testing. Some of the platforms out there do offer this, but it’s not enough.

Everything else starts to seem slow. Most of us are used to estimating the effort of programming and, afterwards, adding everything else on top as small percentages, like: testing, documentation, deployments, overhead and others. Despite the programming part being fast, everything else still takes the same amount of time, and you will see yourself becoming a part-time tester and a part-time technical writer. It takes just as long to do those things as it takes to build the software. When it takes you one week to write the program, it’s acceptable to test it for one day. But when it takes you one day to build the same program, it’s not so much to take one day to test it.

Overall, low-code makes you a better professional. Because you will be doing so much more than just programming, low-code actually makes you more complete. You are not the proverbial coder anymore. You are now a low-coder who deeply holistically understands the full lifecycle of software engineering and seeks to address business needs, rather than solving a complex technical challenge.