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.
Top comments (2)
Thank you for the article! I will try to answer your questions from point of view, as a frontend developer for over 5 years and mainly working on bigger applications for administration, document management and finance. I also have to mention that I don't have much experience with Pinegrow or Webflow.
Because those tools do not cover the entire area of frontend development. For a 'simple' website it will be excellent. But when you get data from multiple API-endpoints, or your frontend will be rendered as micro-frontend in a bigger system, or the need for 'complex' components (editable tables, graphs, etc) most of these tools are not enough as they offer a wide variety of 'simple' components. So we still need developers who can build more complex applications.
A lot has to do with pricing I guess. If you can get a 'simple' blog online with WordPress for only a few dollars per month (WordPress is free and hosting will cost you a bit), while the CMS option of Webflow is $ 16 per month that makes quite a difference.
Secondly I think it has to do with customization of your website. With those tools you are bounded to the limits the tool has set for you. If you want something different you have bad luck, or have to pay more.
Nothing, if you are not going to use it. It all depends on the needs of the application you are working on. Is it a simple website these tools (as many others) are good and reliable. The provide you with a ton of support, you don't have to worry about backups, SSL-certificates, diskspace, etc.
But if the application is in need of authorization and authentication, complex components and more customization you need a different tool: frontend development. In the end it all comes to: using the right tool for the right problem.
That does not mean that these tools (Pinegrow, Webflow) are useless, in the contrary they play a vital part in make web development more easily done by none or beginner frontend developers. You can easily make changes and update your website. But when the application grows and the requirements become more complex the role of the frontend developer becomes more important, as is the role of the syntax.
Thanks for your detailed reply. As a beginner and a non-enterprise dev, I don't have insight to how companies work, so your points about needing this as the app grows in scale and complexity makes sense.
Non-visual tools works for experienced devs since they are used to it. Thinking about your points, I think my main complaint is how visual tools should be more commonly taught for 1) beginners who would benefit from learning faster from a more visual approach, 2) designers, or non-technically inclined folks who just want to learn some frontend dev, and not keen to be a professional fullstack dev.
Learning syntax and all still has value, just not for everyone.