There’s a bit of a movement afoot in the online design and development world: “no code” tools are on the rise. These are tools that allow people to create things that previously would have required programming skills; you know, old school typing and stuff.

Predictably there’s a healthy debate around the trend with fans raving about their ease of use and substantial capability but detractors bemoaning their bloat and inefficiency compared to custom coded solutions. Traditional developers point to monsters that have been cobbled together from no code tools that their adopters didn’t understand, creating complicated products that could have been so much better and simpler. Meanwhile no coders point to code developers reinventing the wheel a hundred times while they’ve been able to build a whole working car.

Well here’s my tuppence.

I like to think of it like this: there are basically two interdependent approaches to design: the architect and the engineer:

• The architect needs to know a little about many things. They have a vision and draw on engineers to fix specific problems.
• The engineer needs to know a lot about a few things. They are problem/solution oriented.

Now, perhaps the no code approach is more like that of an architect. No coders have a vision but draw on the “skills” of no code tools to write code for them.

The programmer’s approach is therefore closer to that of an engineer as they fix specific problems. They know how computers think and how complex systems interact but aren’t so often the driver of creative input. For them marketing and art direction is “the fluffy department” but programmers live in the more sane and linear world of x + y = solution.

Architects create good problems. Engineers fix them.

Here’s my plea to no code fans

No code designers who don’t learn how their tools work will make monsters.

Please take the time to learn at least a little of how your tools do what they do. Architects need to know the language and basic methods of the engineers they work with. By all means use tools that make life easier for you but know enough to not be completely reliant on them, then when you do use them they’ll be an efficiency power-up, not a crutch. I’m a strong believer we should do something at least once by hand (probably badly) before subsequently delegating out that manual labour.

Here’s my plea to detractors of no code tools

Adapt to survive. I hate Dreamweaver too but not all no code tools are crap. Face it: some are probably better than you, and cheaper.

AI is coming for you, human. AI is only getting better at doing repetitive tasks, is starting to take over some creative functions but is downright abysmal at replicating human connection and customer service. So if you’re a web developer with a very code-y approach you may need to start adopting more no code tools, shifting your role a little more to that of an architect. No code tools are getting better all the time and you’d do well to make yourself indispensable.

In conclusion

We should all be humble and teachable.

Every developer and designer relies on things they don’t understand, as I wrote recently – It’s Impossible for Anyone to Know How to Make a Pencil. So none of us should look down on the approaches of other designers and developers too critically. We all have our strengths but when I encounter other people using very different methods to those I’m used to I like to ask myself “what can I learn from them?”

Programmers shouldn’t be dismissive of the potential efficiency gains of no code tools, and no coders should be humble and take the time to learn what goes on behind the scenes every now and then. It may represent a wholly foreign way of doing things but you didn’t get to where you are by sticking with what you knew.

So now I’ve got that out of the way, I’ll be sharing my 8 favourite no code tools of 2020 in my next post.