This post about the passion for coding (and fear of loss) is the third in a multi-part series that examines the negative reactions developers like myself feel when introduced to low-code platforms. If you’re a completionist like me, you will want to read the previous posts before you continue: Low-Code Replaces Developers and Low-Code is a Black Box Solution.
We've crumbled the threat of job loss, and we've pulverized the fear of black box solutions – so what's left?
The fear of losing passion surpasses them all. When developers leave the office each night, they walk out with their skills in-hand. Some are perfectly content to leave those skills unused until the sun rises again. But the rest, those passionate hackers, they claw their way to personal time in which they tinker with side projects.
They patch open-source code. They learn a new framework. They ask and answer questions on StackOverflow.
They love coding because it solves complex problems, it builds products out of thin air, it is the alchemy of a modern age. And this capability imbues them with power and respect. Their source code is lead, and their software is gold. And low-code threatens to pull this rug out from right under them.
One can learn low-code development in a fraction of the time required to master software engineering. To accept one of these platforms as their primary tool is to take a cut in prestige.
And these platforms solve the majority of complex problems in advance: load balancing, resource allocation, encryption, and others. That leaves them with precious few hurdles to overcome in their day-to-day lives.
So what do we say to this?
Coding vs. Low-Code: There's No Getting Around It
For a growing number of business concerns, low-code is the way forward. It's a streamlined development process faster than any that's come before it. Why is this speed so important? Business, encouraged by modern instantaneous desires, needs to move and change at a rate that keeps up with competitors, vendors, and customers. How can it do that while sitting on a cache of legacy software that upgrades at a snail's pace?
Code is the bottleneck now. It’s an arduous, slow task prone to human error. And in my experience, there's an exponential relationship between the speed at which an engineer writes code and the number of bugs they introduce. So coding faster is not a viable option.
The Big Picture: It’s Not Just Coding
If you force your team to work in a low-code environment, they won't abandon ship, at least not immediately. Those passionate developers have families to feed, roofs to keep over said family's head, and debts to pay off. But are you prepared to deal with a discontented workforce just to save a few bucks?
Personally, if I had to work in low-code all day, I wouldn't mind. And that's because I'm a leader, not a developer. And I use the term leader as defined by Robert Steven Kaplan in his book, What You Really Need to Lead, which I discovered in his Harvard Business Review piece, To Become a Leader, Think Beyond Your Role.
Kaplan believes that leaders look at the big picture, and as the title suggests, beyond their role in the organization. Leadership isn't limited to those in leadership positions; everyone can and should participate.
The big picture we developers need to see is that we don't, "solve complex problems," "re-factor solutions," or, even "hack" – we ship products. And I believe the pride in this work should originate from the people whom it most greatly affects, not the work itself.
I'd rather have a low-code base with an endless stream of satisfied users than my own hand-written, proprietary source code coupled with a bag of mixed reviews. And if your team members can't agree with that and they aren't focused on the big picture, they aren't leaders.
Inspire Them to Lead
Not everyone was born to think beyond their personal responsibilities, but everyone can understand stakes and empathize with the goals of an organization. And once they acknowledge that the goals are larger than they are, you can provide them with leadership tools.
By having them participate in big-picture thinking and incorporating their feedback on topics beyond their role, you give them room to branch out. In Kaplan's article, the student who sought his help received no guidance from his peers or his superiors – don't be like them.
Recognize when your team members feel isolated and irrelevant beyond the minutiae of their day-to-day work. Ask them for their opinions on topics outside their zone of mastery. I think their responses will surprise even you.
Bit by bit, they will begin to see how a low-code platform fits into the grand scheme of things. And they will come to understand the pivotal role that only they can play in the future of your company.
Do your developers act as leaders? Let me know in the comments.
Next post in this series: Why Developers Fear Low-Code #4: Move Fast Break Things.