Dear marketing readers: contact me here. I have a point. Promise.
I started programming as a kid, writing multiplayer games for telephone bulletin board systems (BBS) — a precursor to the web and social media as we know them today. It was the late 80s, early 90s, and I was writing mostly in a language called C, with some occasional high performance stuff written in 8086 Assembly language.
For those of you who aren’t software developers — or for you younger developers who grew up thinking Java it was a low-level language — this is what assembly code looks like:
You literally spell individual instructions into the CPU, move bytes from memory into registers, perform simple math operations on them, and create program flow with primitive AND, OR, XOR logic gates.
While I recognize the cosmic power of this low-level foundation upon which all software is built, let me just say that the Assembly writing was crap.
As a game designer, I had stories in mind, new worlds I wanted to create, interactions between players I wanted to enable. Converting this to code, especially the parts to cryptic assembly instructions, was like diving from the heights of Mount Everest to the depths of the Mariana Trench. Someone’s head might explode.
A few things I remember about this experience:
First: it was extremely time consuming. A set of game mechanics that I could explain to you in 30 seconds – one of my games allowed players to mix different potions to create new, more complex, increasingly powerful magical elixirs – would take 30 days to develop . Yes, coding allowed these things to be created. But the high cost of coding was also an obstacle to the implementation of many other ideas.
Second: it was very error prone. Even great developers end up with “bugs” in their software. I was, at best, mediocre. So I had a lot of errors in my code. Finding them was difficult. In more complex programs like a multiplayer game, even being able to test all the possible ways something could go wrong was an exponential task. Fixing them could be even more difficult.
Relatively few of my bugs were flaws in game design. Almost all were random mistakes made in the coding process, translating a perfectly valid conceptual flow into thousands of lines of code, where a simple typo could ruin the whole thing. Code is fragilitymy friends.
By the way, there is no Lake Wobegon. Half of all programmers are below average. And below-average people can write such buggy code that if the program were your house, your friendly Orkin pro would recommend gasoline and a match.
Third: it was easy to lose the plot. With my head down in the code, trying to implement some crazy recursive function, juggling pointers to a mess of different data structures, I was no longer thinking about the game or its players. I was consumed by wild pointers, hanging pointers, memory leaks, the impact of base pointer modification, and out-of-scope address access errors.
However, despite all this resulting in mediocre code, the games themselves became quite popular for their time, being played by over a million users on BBSs around the world. Their success was despite my shortcomings as a software developer.
The moral of this nostalgic memory lane: code and coding have always been an imperfect means to an end.
Back to the Future for Real MOVE CX, DX
Fast forward a few decades to today — and the proliferation of no-code tools.
There is still debate about the wisdom or folly of letting non-IT employees build workflows, apps, agents, or composite customer experiences with no-code platforms. Every time I publish an article about the growing use of no-code in marketing and martech — like this one last week Every marketer a data analyst and an engineer…delusion or fate? — I get an earful from people who insist that non-programmers don’t have the skills to build anything good.
With all due respect, they are wrong.
First of all, code is not inherently better than non-code. The history of programming has been a steady march towards higher levels of abstraction. We started with punch cards. I came up with Assembly language, which I will repeat was as much fun to work with as a salt mine. Then higher level languages like C, C++ and Java. And then even higher (and safer) languages like Python, with over 350,000 packages you can use to “compose” amazing programs in a fraction of the time it took back in the salt mines.
No-code is the next step in this evolution of abstraction, where more than ever, it’s about understanding what you want to create and your ability to describe it — visually or with a natural language interface (thanks, gen AI). Not having to deal with things like uninitialized pointers and segment faults is a pretty big improvement in the quality of life of a constructor. Most no-code tools have great guardrails that raw code doesn’t.
“But even in no code, it’s about logic and programmatic thinking,” critics will reply. And they’re right — about that first part. But then they finish that sentence by adding, “And only software developers and IT professionals have these skills.“
Sorry, but this is wrong both ways.
On the one hand – reflecting on my sloppy code days – being a software developer doesn’t make you inherently great at logic or programming thinking. No offense, but there are a lot of below average programmers out there whose understanding of logic and programming thinking isn’t great. Just because you bring in a “software developer” to build something, doesn’t mean it will work as intended (or at all).
On the other, not a software developer it does not mean that logic and programmatic thinking inherently escape you. Financing. Operations. Legal. Many business professionals have excellent skills with logic and programmatic thinking, even if a screen full of Javascript would be as incomprehensible to them as Sanskrit. (Quid pro quo: ask your average Python programmer to try to figure out the mechanics of an Excel budget spreadsheet from a senior financial analyst at a public company. Then ask him to explain it to me.)
Marketing operations, sales operations, turnarounds — these disciplines thrive in logic and programming thinking. Customer journey maps, orchestrated by marketing automation tools, delivered to algorithmic sales sequences driven by triggers and conditional actions… these are intelligent software “programs” built by experts in their field.
“Experts in their field” is key. A good marketer can build great programmatic workflows with a no-code automation tool first and foremost because they deeply understand the context of what they are building. It is not just that they are adept at designing a logical program flow. They know what these stimuli and actions really mean. They know what result they are trying to achieve. They know what can go wrong with the business process.
In an era where no-code tools — even next-generation artificial intelligence “come along” for manufacturing with code — make it easier and easier to perform the technical implementation tasks of building an application or automation, the real value is in knowing which application or automation to build. What does he need to do? Why; How (from a process perspective, not a technical source code level)?
Domain expertise is the linchpin here.
No-code tools enable people with deep domain expertise – and excellent logical and programming thinking skills, whose only “flaw” is that they didn’t learn to code in Python – to quickly and efficiently turn their knowledge into better digital functions and experiences.
Can no-code tools also empower people who have no idea what they’re doing to make some really crappy workflows and automations? Unfortunately yes. But it is not that different from the chaos that a software developer who doesn’t know what he’s doing can sow.
Don’t confuse knowing how to code with knowing what you’re doing.
The biggest benefit of the no-code era is the decoupling of these two things.
And now, one word useful information from our sponsor…
As the cost of publishing this blog and newsletter increases, I am experimenting with ways to accept sponsorships that are non-disruptive and hopefully useful to you, dear reader. One idea I’m trying today is to highlight a report from a sponsor that I think has data and information you might find valuable. I’ll only share it if I really think it’s good, but I’m getting paid to include it. You can support my writing by checking it out.
Our first sponsor is MoEngage, who just launched theirs Cross-Channel Marketing Report 2024. A study of 700+ B2C marketers, includes useful data on marketing channels and priorities, challenges and solutions. For example, this distribution of channels currently used by B2C marketers:
What are the top challenges marketers face when adopting new technologies for cross-channel marketing? Well, the #2 answer is — surprise, surprise — “integration issues with existing technologies” (27.6%). The other Top 5 challenges? Well, you’ll have to get a copy of their report to find out.
