The UX of coding is broken

The developer experience of coding is broken. As a designer trying to learn coding, I’m surprised by how the UX of the coding activity itself is not built to set us up for success.

A designer's perspective on the experience of coding

In design, we have this thing called bodystorming. Basically, if you have an idea for a new product/service or improvements to an existing one, rather than talk in the abstract about it and imagine how it would be like, you get up, get out and try it out with your own body.

Bodystorming is the act of physically experiencing a situation in order to immerse oneself fully in the users’ environment, in order to develop empathetic understanding of the painpoints and high points that users face.

It’s a technique that’s similar to what consumer/marketing research calls mystery shopping. As a designer myself, it had become second nature to constantly observe and evaluate how I can design better experiences while experiencing the thing itself. Call it an occupational hazard.

So that’s what I found myself doing while learning how to do programming (mainly front-end web development using HTML, CSS and JS). I was bodystorming the activity we call coding. And boy, does the user experience of coding feel broken. As someone new to it, there’s things we do in coding that just bewildering to me. One thing is the way we code and check our work.

The UX of writing and checking code is broken

I don’t particularly enjoy the workflow of writing code on the text editor and refreshing the browser page to see if the page turned out as you wanted it. What happens is very often you go back and forth between 2 or more screens - the text editor and the browser - tweaking tiny changes until everything lines up the way you want it.

It’s like we’re trying to paint a Picasso, but writing down extremely detailed and specific text instructions to micro-manage someone else to paint it for us, down to the angle of how they hold the brush, how many strokes of a specific colour to dab on, at which specific millimetre square of the canvas. Just that in the case of coding, the painting is the website, that someone else is the computer, and text instruction the code. It’s the wrong way round! If I need to do spatial layouts on a web page, I do it right there on the browser, by drawing the shapes or placing the elements where I want them, spatially. Not type text! Typing text to do that is a counterintuitive to a human user and sets up an additional layer of complexity and difficulty to achieving what you want. Visual and spatial work should have visual and spatial tools, not text. It was frustrating having to learn coding using such tools, when as a designer I’m used to using tools like Sketch and Photoshop.

A visual way to code is more human-centered

The tools we have now for coding are mostly computer-centric, not human-centred. What I need is to code a website, visually.

I later learned that there are tools like Pinegrow and Webflow that allows you to do just that - drag-and-drop a website together visually, while the auto-generating clean and semantic code for you to be exported. Thank god! But that made me even more confused:

• If such tools are available, why are we still learning/doing (front-end) development the old way?!

• Why aren’t these tools more popular and commonly used?

• In fact, if we can do it this way, what’s the value of learning the syntax then?

Caveat though: I’m only at front-end web development (HTML, CSS, JS) so far. I can’t speak for the experience of doing back-end development, whether it’s broken too, etc. More learnings to come!

Follow my daily writings on Lifelog, where I write about learning to code, goals, productivity, indie hacking and tech for good.