Updated: Aug 19, 2020
Programming is one of the best, most versatile skill anyone can have nowadays, second only to communication skills. It's the ultimate problem-solving skill; software can solve almost any problem if you're creative enough. Employers know this and are actively hiring software engineers. The software engineering job market will grow by 21% between 2018 and 2028.
At the same time, there is an emergence of no-code software creation tools, like Robotic Process Automation (RPA), or workflow editors like Microsoft's Power Automate, or people like me creating no-code tools (https://koupi.io), hitting the market. Those tools allow people with very little if any, programming experience to become an expert.
It begs the question: Will no-code programming be the death of software engineering?
If you are a programmer of any kind, you probably think that programming is too complicated to be packaged and converted to no-code, and you would be correct. Bundling code is hard, I would know, I spend a vast portion of my time doing just that. Every time you create something, there is always a new use case that breaks everything, no-code can't be just set-it-and-forget-it. It will need software engineers to support, maintain, and develop.
The barrier to entry into software gets lowered by no-code software. Users can now create full-blown applications, even enterprise ones, without any code. That's an attractive option for companies; they can develop solutions that fit their needs without technical debt and code maintenance at a fraction of what big-box solutions would cost.
One important thing to keep in mind, though, is that software is a potent tool. Software is the only "employee" that never stops working, and costs almost nothing, compared to the equivalent number of employees needed to do the job. So for no-code to win right now, it doesn't need to replace a software engineer who can write code for anything a company would need, it just needs to chip away at office worker's workloads.
On the other hand, as mentioned above, no-code has its limitations. For one, it can't quickly adapt to new use cases. Vendors of no-code need to review every new use case, decide if it's worth working on, work on it, and then implement it. Sometimes those use cases are something software engineers can whip out in an hour but would take days for a no-code company to develop.
As I use Koupi, I keep a list of features and use cases that I need to implement. It's a long list, but, as I mentioned above, every one of them I ask myself: is it worth my time to work on this? Now, I know that if I worked on the same problem, strictly with code, it would take me a couple of minutes to solve it, but it would take over an hour, if not more, to implement in Koupi. That's the added burden of perfection imposed on no-code software.
Ultimately, I think that the emergence of no-code software will split software engineering into two tracks. On one side will be the software engineers who write quality code to create a complete solution to a problem. On the other hand, the prototypers will use no-code solutions to solve targeted internal issues quickly. The former will probably work for software companies, and the latter will work for everyone else. I hope that no software company will run on an entirely no-code stack, but relish the day when it becomes possible.