Long live code
There’s a wave of energy and investment going into “no-code” tools. The thesis is that working with code is intimidating and difficult, so removing it is the best way to empower the non-technical masses.
But the real problem isn’t that code is too difficult to learn. People are fundamentally curious and excited to build new skills. The internet is filled with resources, and kids are being taught programming as early as grade school.
The real issue is with the arcane, overly complex workflows required to do anything productive with code — the lived reality is that “code” itself is the least intimidating part of coding.
Imagine if to write an email you first had to install a bunch of obscure command-line tools, set up a multi-step local drafting environment, and then learn a whole new framework to actually send the message.
You would probably give up, and conclude that writing itself was hard; the friction of the experience would ruin the concept of communicating through the written word, and everyone would be looking for some low-text solution that lets you communicate with drawings.
This feels like where we are with coding. We make aspiring engineers and data scientists scale two mountains: first learning a new language, then figuring out the overhead of local environments and remote dependencies and obscure error messages that are required to actually apply their new skill [1]. It’s easier than ever to learn to code, yet as hard as ever to make it useful.
In the data space specifically, even those who learn languages like Python or SQL often have a hard time applying them at work. Just connecting to a database can be a multi-day sojourn through incompatible drivers, incorrect credentials, and irrelevant StackOverflow articles (and let’s not start on dependency management or version control).[2]
Conversely, “ExcelLang” is the most-used language in the world not because it’s simple to learn, or the best tool for everything it’s used for (my god, it’s not), but because it’s super accessible. It’s right there, in every cell of every spreadsheet on every computer in the world. People use it because it’s easy to get into.
And once they’re into it, they do some really complicated things! [3] I once worked with an airline that used a spreadsheet to optimize their entire flight schedule — billions of dollars of decisions flowing through one massive workbook. The logic was incredible and terrifying, and would have actually been more easily written in Python, but that wasn’t an option for the creators because Excel was the only “dev environment” they had.
It’s the accessible sophistication of Excel that makes it magic for the millions of “non-technical” users who spend their days basically writing code in it. The next generation of data tools should tap into that same “low floor, high ceiling” ethos.
Instead, there’s often a soft-bigotry-of-low-expectations dynamic implicit in the narrative about no-code, as if everyone who isn’t a proper engineer needs a dumbed-down, point-and-click etch-a-sketch. These tools want to protect users by eliminating code, which is built up as this scary thing, available only to the privileged few with CS degrees.
This is not productive. Too many no-code tools are setting their users up to be artificially constrained today (when they inevitably hit the limits), and disadvantaged tomorrow (when they haven’t learned any transferable skills).
Focusing again on the data space, there has been an explosion of libraries and frameworks for transformation, model-building, and visualization; the best way to make these accessible to more users is by making code-based workflows more accessible generally, not building rigid UI-based analogs.
Truly empowering users doesn’t mean getting rid of code, but embracing it. The beauty of code is its infinite flexibility, and the tools of the future should unleash, not constrain, a users’ creativity.
This may mean less code. But not none.
We think about this a lot at Hex, where we’re building a “some code” platform for analyzing, collaborating, and building with data. If this interests you, drop us a line at hello@hex.tech (we’re hiring!)
[1] true even for developers who just want to learn a new language
[2] The other major challenge is how to turn a data analysis into something actually sharable and useful — but that’s a topic for another post.
[3] the Excel video community is about as weird as I thought it would be, although this really is the perfect description of the the necessary mindset for working with dirty data.
