Dear marketing readers: hang in with me here. I have a point. Promise.
I started programming as a kid, writing multiplayer games for dial-up bulletin board systems (BBSs) — a precursor to the web and social media as we know it today. It was the late 80’s, early 90’s, and I mostly wrote in a language called C, with some occasional high-performance components written in 8086 Assembly language.
For those of you who aren’t software developers — or for you younger developers who grew up thinking Java was a low-level language — this is what assembly code looks like:
You are literally spelling out individual instructions to the CPU, moving bytes from memory to registers, executing simple mathematical operations on them, and creating program flow with primitive logic gates of AND, OR, XOR.
While acknowledging the cosmic power of that low-level foundation upon which all software has been built, let me just say that writing Assembly sucked.
As a game designer, I had storylines in mind, new worlds I wanted to create, interactions between players I wanted to enable. Translating that down into code, especially the parts in cryptic Assembly instructions, was like diving from the heights of Mount Everest down to the depths of the Mariana Trench. One’s head could explode.
A few things I recall about that experience:
First: it was tremendously time-consuming. A set of game mechanics that I could explain to you in 30 seconds — one of my games let players mix different potions to create new, more complex ones, laddering up to ever more powerful magical elixirs — would take 30 days to develop. Yes, coding enabled these things to be created. But the high cost of coding was also a barrier to materializing many other ideas.
Second: it was very error-prone. Even great programmers end up with “bugs” in their software. I was, at best, an average one. So I had a lot bugs in my code. Discovering them was hard. In more complex programs, like a multiplayer game, even being able to test all the possible ways in which something might go wrong was an exponential task. Fixing them could be even harder.
Relatively few of my bugs were flaws in the game design. Almost all of them were accidental mistakes made in the coding process, translating a perfectly valid conceptual flow into thousands of lines of code, where a simple typo could crash the whole thing. Code is fragile, my friends.
By the way, there is no Lake Wobegon. Half of all programmers are below average. And the below average ones can write such bug-infested code that if the program were your house, your friendly Orkin professional would recommend gasoline and a match.
Third: it was easy to lose the plot. 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, dangling pointers, memory leakage, the impact of modifying the base pointer, and address access out of scope errors.
However, despite all of that resulting in mediocre code, the games themselves became quite popular for their time, played by over a million users on BBSs around the world. Their success was in spite of my deficencies as a software developer.
The moral of this nostalgic walk down memory lane: code and coding have always been an imperfect means to an end.
Back to the Future to Really MOVE CX, DX
Fast-forward a few decades to today — and the proliferation of no-code tools.
There continues to be debate about the wisdom or folly of letting non-IT employees build workflows, apps, agents, or composed customer experiences with no-code platforms. Whenever I publish an article about growing no-code use in marketing and martech — such as last week’s Every marketer a data analyst and an engineer… delusion or destiny? — I get an earful from people who insist that non-developers don’t have the skills to build anything good.
With all due respect, they’re wrong.
First of all, code is not inherently better than no-code. The history of programming has been a steady march to higher levels of abstraction. We started with punch cards. I came along with Assembly language, which I’ll reiterate was as much fun to work in as a salt mine. Then higher-level languages like C, C++, and Java. And then higher (and safer) languages yet, such as Python, with over 350,000 packages you can use to “compose” amazing programs in a fraction of the time it used to take back in the salt mines.
No-code is the next step in that progression of abstraction, where more than ever, it’s about understanding what you want to build and your ability to describe it — visually or with a natural language interface (thank you, gen AI). Not having to concern yourself with things like uninitialized pointers and segment faults is a pretty big improvement to a builder’s quality of life. Most non-code tools have excellent guardrails that raw code doesn’t.
“But even in no-code, it’s about logic and programmatic thinking,” critics will respond. And they’re right — about that first part. But then they finish that sentence by adding, “And only software developers and IT professionals have those skills.“
Sorry, but that’s incorrect in both directions.
On one hand — reflecting back on my sloppy code slinging days — being a software developer doesn’t inherently make you great at logic or programmatic thinking. No offense, but there are a lot of below average developers out there whose grasp of logic and programmatic thinking is not great. Just because you bring in a “software developer” to build something, doesn’t mean it’s going to work as intended (or at all).
On the other, not being a software developer doesn’t mean logic and programmatic thinking inherently elude you. Finance. Operations. Legal. Many business professionals have great skills with logic and programmatic thinking, even if a screen full of Javascript would be as indecipherable as sanskrit to them. (Quid pro quo: have your average Python programmer try to grok the mechanics of an Excel budgeting spreadsheet from a senior financial analyst at a public company. Then have them explain it to me.)
Marketing ops, sales ops, rev ops — these disciplines thrive on logic and programmatic thinking. Customer journey maps, orchestrated by marketing automation tools, handed off to algorithmic sales sequences driven by conditional triggers and actions… these are savvy software “programs” that are crafted by experts in their domain.
“Experts in their domain” is key. A good marketing operations professional can build excellent programmatic workflows with a no-code automation tool first and foremost because they deeply understand the context of what they’re building. It’s not just that they are proficient at designing a logical program flow. They know what those triggers and actions actually mean. They know what outcome they’re trying achieve. They know what can go wrong with the business process.
In an age when no-code tools — and even gen AI “copilots” for building with code — are making it easier and easier to do the technical implementation work of creating an app or automation, the real value is knowing what app or automation to create. What does it need to do? Why? How (from a process perspective, not at a raw code technical level)?
Domain expertise is the linchpin here.
No-code tools empower people with deep domain expertise — and perfectly fine logic and programmatic thinking skills, whose only “flaw” is that they didn’t learn to code in pythonic Python — to quickly and efficiently turn their knowledge into better digital operations 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? Sadly, yes. But it’s not that different from the chaos a software developer who doesn’t know what they are doing can sow.
Don’t conflate knowing how to code with knowing what you’re doing.
The greatest benefit of the no-code era is the disentanglement of those two things.
And now, a word helpful data from our sponsor…
As the costs rise for publishing this blog and newsletter, I’m experimenting with ways to accept sponsorships that are non-interruptive and hopefully useful to you, dear reader. One idea that I’m trying today is highlighting a report from a sponsor that I believe has data and insights that you might find valuable. I’ll only share it if I genuinely think it’s good, but I am getting paid for including it. You can help support my writing by checking it out.
Our inaugual sponsor is MoEngage, who just released their 2024 State of Cross-Channel Marketing Report. A study of 700+ B2C marketers, it includes useful data about marketing channels and priorities, challenges and solutions. For instance, this distribution of the channels B2C marketers are currently using:
What are the top challenges marketers face in 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.
