Long Live Code

There’s a wave of energy and investment going into “no-code” tools for data work. 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 had to install a bunch of obscure CLIs, configure a local drafting environment, and then learn a new framework to actually send the message. You might give up, and conclude that writing itself was hard; the friction of the experience would ruin communicating through the written word, and everyone would be looking for low-text solutions for communicating with drawings.

This is where we are with coding. Aspiring engineers and data scientists need to 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 ¹.

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).²

Conversely, “ExcelLang” is the most-used language in the world because it’s super accessible. It's not simple to learn, or the best tool for everything it’s used for, but it is 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! 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. It would have been easier to write in Python, but that wasn’t an option for the creators: Excel was the only “dev environment” they had.

It’s the accessible sophistication of Excel that makes it magical for the millions of “non-technical” users who spend their days writing code in it. The next generation of data tools should tap into that same “low floor, high ceiling” ethos.

Instead, there’s a soft-bigotry-of-low-expectations dynamic, 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. But pure 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 bring these 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.

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.