Will Developers Use “No Code” Tools?
Many attempts to simplify programming lead to visual interfaces that provide approachable settings for common tasks. These simplifications may appeal to non-developers, but they send experienced coders running for the command line. Yet, no code tools are rapidly expanding. Zapier, Integromat, and Workato are becoming more popular options and some believe developers won’t be needed for most integrations in the future. However, it seems unlikely that coders will adopt these tools in their current forms, as they are not looking to fully automate away their creative autonomy. This raises the question: which parts of currently available no-code tools are useful for the future developer? Furthermore, how can developers influence the production of these integrations so that they’re compatible with the true coder’s workflow?
Developers may be able to strike a balance between automating appropriate responses while still leaving space for them to impart creative nuance upon the end product. Certain patterns can be brought into a typical developer’s workflow which can streamline the way apps are built, deployed, and tuned.
Developers Don’t Want Drag-and-Drop Interfaces
Slick user interfaces with plug and play features do worlds to bring new layman users into the fold. However, these aren’t necessarily good for app developers. Modern coders want to be able to control their code down to the line, while still automating away repetitive maintenance processes. When drag-and-drop is a requirement, developers can’t have as much control or efficiency. As a result, the creative development process is interrupted and you’re unlikely to end up with the most innovative applications.
Tools like Scratch (and similar, more professionally-oriented, tools) are great for learning and simple projects. They are typically not granular enough in their controls to create meaningful business applications. And they usually slow down professional developers.
Developers thrive on the command line. They want to be efficient and automate away the stuff that keeps them from moving quickly. Part of what makes that possible is they can “see inside” and tweak things at a low level. Developers are likely to always want to design the components of their systems themselves, rather than dragging them out of a panel in a UI.
However, this is not to say there is nothing to learn from these no code tools. For example, repeatable workflows are useful if a dev can plug in their real code. This permits developers to write individual components of a stack, but with assistance from a system that automates the redundant parts.
Since much of the coding process is devoted to editing and retesting, there are plenty of pieces that can be streamlined. This becomes especially clear when you look at everything involved with backend maintenance.
Developers Don’t Want to Babysit Servers
No code integrations aren’t all bad. They can be extremely useful for developers when properly employed. They are a boon to company efficiency in two key cases: when they can save labor hours and when they can save server capacity. Developers of varying skill levels would surely benefit from automating much of their backend maintenance. Periodic functions could happen in the background without taking up valuable time coders could spend building.
Some unnecessary developer time stealers include:
- Cost optimizing servers
- Wiring up continuous integration
- Connecting tools around incident response
- Auditing cloud security permissions
Cost optimization is the elephant in the room for cloud computing. How companies acquire, build, utilize, and adapt their server space can hugely impact the efficiency of their spend. Currently, companies spend a boatload on labor hours for developers to monitor their systems.
It’s important to keep in mind that there are two kinds of jobs for developers, and indeed anyone selling a product: those that make your product more unique and routine functions which must be kept up in order to be a responsible administrator. Clearly, developers should focus as much of their energy and resources on advancing the company’s core value proposition. The less time developers spend getting distracted with mundane maintenance tasks, the better. This brings us to our next efficiency factor, minimizing interruptions.
Developers Do Want to Automate Their Interruptions
A tap on the shoulder. Expanding Slack notifications. Unnecessary pages for non-incidents. These are some of the things that keep developers from doing their best work. These can’t all be avoided, but automation can help limit them.
For example, a developer might get a notification when their cloud development servers have been running idle for too long. Those messages are well-meaning, but they are a distraction from focused work. The actions taken during these times may only take minutes, but then it takes time to get back into a productive flow. Perhaps most maddeningly, the actions needed here are always likely to follow the same considerations. It’s a perfect opportunity for automation.
Or consider code review, an important part of working on a dev team. The reviewer should not need to manually create a staging server with running code. Nor should they need to worry about shutting it down when they’re finished. Between continuous integration tools, code repositories, and a way to describe the ideal flow, you can limit the time a developer is interrupted.
The rise of “no code” gives development teams an opportunity to look where they’re wasting developer time. The answer is not to give drag-and-drop interfaces to developers. Let them use the tools they know best and connect those pieces with real code.
Using a combination of event-based triggers and automated protocols, Relay listens to signals from your existing DevOps tools and then triggers workflows to orchestrate actions on downstream services. Developers can get a taste of no code without giving up their code. Be efficient with the things that can be automated and get your team to get back to building out your organization’s core value.
Get started today with our single platform for all your cloud automation use cases.
Top comments (0)