View profile

The No-Code Misnomer

Before we get into it, I wanted to share the fact that I've joined the Airtable Customer Success team
The No-Code Misnomer
By Aron Korenblit • Issue #18 • View online
Before we get into it, I wanted to share the fact that I’ve joined the Airtable Customer Success team in NYC! New job, new city! Couldn’t be more excited. I’m sorry if I missed your DM/email/Airtable Q recently, trying to get through the backlog!
Now, you would think this means I’m going to share great insights about Airtable here. And you’d be right that I do have some insights! But I won’t be sharing them since, you know, I legally can’t! That said, working here definitely colors how I view the world and that’s what I tend to write about, so there’s that.
That said, if you’d like to work at Airtable, that’s something I may be able to help with. We’re hiring in every department in NYC, SF and Austin (and some roles remote US). Reach out if any of the open positions fit your profile.

I’m just going to come out and say it, I hate the no-code moniker (or nocode or no code). I have many gripes about how we’ve decided to name our section of the internet. It seems like I’m not the only one, see the replies to the tweet below.
Aron Korenblit
Risky but I think this is the week I write about why I hate the fact that we've named our corner of the internet "no-code"

So here goes.
The problems with “code” have nothing to do with “code”
Although, we can say that’s not the case, the name certainly feels like we’re trying to edge out, even exclude, programmers. It makes it sound as if there is no place for code in our space (forgetting the irony that code is what we output).
How we feel about code and why we want to avoid it— has in fact nothing to do it with code itself. Code is a language that helps us tell inanimate objects what to do so we don’t have to do it. Our real frustration lies with what usually comes with software projects: overblown budgets, long delays and expensive maintenance costs. That’s what we’re saying “no” to, not code.
These issues have nothing to do with code per se but are due to scope creep, poor planning and underestimating difficulty of a task. Issues which, let me tell you, are also very very present in projects using visual development tools (doesn’t have the same ring to it, that’s for sure…).
If what we’re trying communicate is that no-code helps get things done faster, we should elevate that fact in how we name ourselves instead of objecting to code itself.
NOTE: A few of the replies of the above tweet suggested RAD for Rapid App Development. Although it sounds like something out of the 90s (which I think it is), at least it has the benefit of communicating what no-code stands for: speed, simplicity and prototyping. That may be a good place to start!
No-code pits us against those from whom we desperately need buy-in
Imagine if Quickbooks’ tagline was “accountants are useless” instead of “Organize and Manage your Business” (and variations thereof). Buy in from the accountant department, which is necessary in order to automate that work, would suddenly become much harder!
Ultimately, crucial processes in most departments are owned, approved and developed by developers and/or product managers even if they’re imagined (or requested) by all departments. The fact that the marketing teams can plug into APIs, for instance, via 3rd party tools is new! Before that, developers and PMs had two routes: point solutions to solve their problems or, bar that, building it themselves from scratch. Now there’s a gray area between the two that’s opened up. It’s no longer an either/or proposition.
How I envision the future of collaboration among developers, PMs and visual developers (hehe) is where we position “no-code” as either additive to existing tools or a product in and of itself. It creates a middle ground between custom code and point solutions on that a spectrum with writing custom code on one end and purchasing a point solution on the other and a middle that looks like:
  1. point solutions augmented by automations tools to extend their functionality to our workflow
  2. a horizontal solution that patches together a few automations tools to get to a workflow that works for our use case
  3. a custom build that scope out parts that can be taken on by no-code tools (and therefore don’t require developer time)
All of these should be considered before “let’s build it from scratch” or in tandem with purchasing a tool. But ultimately, if we position ourselves against “code”, one of the two predominant options today, and the people who’s approval we need, we’re doing ourselves a huge disservice. Instead we should communicate the fact that no-code is narrowing down the solutions that need to be built from scratch to situations in which it’s truly necessary (and so we can do a good job when we do build from scratch)!
So what should we call ourselves?
Huh… good question! I don’t know! But I hope it’ll have the following characteristics:
  • Be inclusive of developers and everyone else (don’t start with the word no)
  • Communicate that we’re here to help developers get more done faster so they can focus on higher value tasks (no more dev tickets for text changes on the website or simple API integrations).
What I hope is that we take a hard think of what we call ourselves because with every day and every new tool it becomes harder and harder to switch. And frankly, I think we’re stuck with no-code whether we like it or not. So what I truly hope is we over compensate for our title by being more inclusive and thoughtful about how we fit in the broader tech world.
PS No links this week since I am still figuring out my life in New York and have had no time to peruse the no-code interwebs. I appreciate your patience!
Did you enjoy this issue?
Aron Korenblit

A weekly long form newsletter about working harder not smarter written by Aron Korenblit

If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue