Shift-Enter-Shift-Enter-Shift-Enter (Optimizing for developer happiness)

Why developer ergonomics is the quiet obsession driving the best tools in web development

Good Monday Morning everyone

This week, I felt like reflecting a bit about a subtle cultural value that is very valuable among web devs, a value with great strength, that is often overlooked, and whose side-effects are often ridiculed or derided. I myself has have even done this during the years, before I understood it fully.

Web Developers place an exceptionally high value on Developer Ergonomics, in particular within the SSR culture.

What do I mean by ergonomics? It's funny with word definitions - if you look at the definition in Merriam-Webster, it says:

ergonomics. noun . ˌər-gə-ˈnä-miks

1: _an applied science concerned with designing and arranging things people use so that the people and things interact most efficiently and safely (_called also biotechnology, human engineering, human factors)

2 or the design characteristics of an object resulting especially from the application of the science of ergonomics

And when I asked Claude Sonnet:

"The study of the design of tools, devices, and environments to optimize human well-being and productivity."

To be clear, I'm not referring to physical office ergonomics like chairs or standing desks, I'm talking about language, library and platform ergonomics here. But it is in a way its the same - I'm talking about applying that same thoughtful, optimization-focused approach to developer tools. I.e creating an environment where developers can work efficiently and comfortably, but in the digital realm of coding and development.

I intentionally use the term Developer Ergonomics here, and not Developer Experience because the latter term has become quite appropriated and diluted, most likely because that term is quite broad and doesn't really describe the essence of the value, and can be turned into meaning anything. Such as "AI" or "Web".

It's the little things, a lot of them

There are many, many examples of this, and it is something that I've taken for granted over my many years in web dev, but coming back to it as part of rebooting FFF and seeing the incredible improvement in ergonomics made it clear how much faster ergonomics improve in web dev compared to other fields.

I have talked before about the impact of the incredibly fast hot reloading that Vite offers. In Thinking Fast and Slow-terms, I find that the ultra fast rebuild and lack of manual steps between save and browser reload allows my bran to offload work to System 1 that would otherwise be done by System 2, that is slower and more expensive to run. I code much more fluidly and get less tired when my environment has fewer unnecessary steps or delays.

Good ergonomics often necessitates extensive efforts on a deep level

A VERY subtle principle that has enabled a lot of the ergonomics in web dev is an obsession around dependency graphs, which enables a lot of things upward in the layers.

Most development environments and ecosystems have dependency graph thinking of course, but in web dev, probably caused by the fact that we have to send stuff over the network, we are obsessive about their sophistication, which is what allows things like Vite to compile only the parts of the codebase that change, instead of doing full compilations.

But this dependency graph thinking is also extended to data. The JavaScript community absolutely did not invent FRP, but the JS community is a voracious, and uniquely practical adopter of it. Ever since React introduced the concept of reactivity that was enabled by a discipline of strict, functional unidirectional data flow, we have been able to constantly evolve this, and now I see it really flourishing out with Signals being beautifully leveraged by projects like Solid and Motion Canvas, even though they are rather different in nature.

Signals take you a little bit of time to wrap your head around, but once you get used to working with them, they have incredible ergonomics compared to say Redux/ReSelect that I thought was the most elegant thing ever back in the day, but Signals are SO MUCH easier to work with.

That they both happen to use Signals, that is very good ergonomics is not really a coincidence, because both of them as projects are very ergonomics-centered, so it makes sense that they both converged on the same thing.

Motion Canvas and SolidStart are two extremely good examples of projects with very good ergonomics. They are young, and have their weirdnesses and bugs and quirks like everything, but they make me HAPPY to work with, I'm productive and it comes with a sense of ease - the opposite of pulling teeth, kind of. A fluidity.

The ergonomics of Data Analytics tooling improves a lot slower, at least historically

The reason that I am thinking about this at this particular time is that the first episode that I am working on is an episode that throws you (as a webdev) into the realm of Interactive Data Notebooks.

The video series I'm working on is about diving into data with Observable Framework. Framework isn't strictly speaking a notebook but more like a Next.js/SolidStart but for Data Apps.

My main motivation for this was to start you off at a position of strength and familiarity, and focus on dataviz, instead of going into Python and Jupyter. But as I'm getting more into this it dawns on me how little has happened in data, and how much Framework improves on things because web devs just think differently.

Jupyter is still prevalent, and Data notebooks in the wild is mostly derivatives of the original-gangster Jupyter that in turn extensively use Pandas. Even very modern tools that evolve heavily on Jupyter (Google Colab, Deepnote, Hex) follows the same basic pattern.

Innovation happens in analytics tooling, but we just don't see the same gear-shift innovation in the ergonomics of data analytics tools as we've seen between Angular->React->Solid. (Yes, LLMs has gear-shifted analytics, but I don't think it counts - just slapping an LLM on it did not really take genius innovation and through changes, it just happens to work really well there)

And when I said that Jupyter is an original gangster, I mean ORIGINAL. Jupyter is a spinoff of IPython. If your cat was born on the same day as IPython, your cat in not in a superposition of alive and dead states, your cat is just super-dead.

Pandas, why u no reactivity

This is quite frustrating to see. A killer feature JavaScript notebooks such as Observable or Evidence.dev introduces is reactivity - as soon as you changed one cell in an Observable notebook, the dependent cells updates, which is very nice for both dev and responsive interface controls.

This is what every web developer after React is used to, of course.

We expect signals and automatic dependency tracking of values, but in the Python playbook world, proper dependency graphs are not really a thing, running dependent cells manually to get things to update (shift-enter-shift-enter) is STILL the norm today, even in modern tools like Hex, that is incredibly sophisticated in other aspects, so it's jarring that it doesn't have proper dependency caching and updates.

That's not TOTALLY fair to say, Hex DOES try to have dependency tracking, but in the end it all rests on Pandas, and is not a functional paradigm with subscribe/publish mechanics - you constantly modify dataframes in-place, etc. so the dependency graph becomes nonsensical to try to track. If you do not switch to an underlying paradigm like Signals, you are to some degree, stuck with shift-enter-shift-enter-shift-enter-shift-enter.

Web devs would NOT take it 🙅‍♀️🙅🏾🔥

What I can't help but observe, living in both worlds, is that this would NEVER be accepted in web developer culture, because JavaScript programmers are very sensitive to ergonomics.

I think it might be part of SSR culture, that Rails started off back in the day, with it's stated design goal of "Optimize for Programmer Happiness".

The Python analytics community accepts shift-enter-shift-enter for a decade and counting, while SSR devs invents and quickly adopts things like Vite, to make hot reloading sliiiiightly faster and robust (among other things but that's the one that really sticks out).

The web dev culture has made the sacrifice to being in constant flux of ever learning and ever upgrading, in order to get the best ergonomics when you do.

And yeah, it means building a lot of build systems and the web dev community is often made fun of because we have a new build system every quarter**, but these ergonomics are VERY important in aggregate.**

I dare the data science community to calculate how many human data engineering lives have been spent on shift-enter-shift-enter-shift-enter-shift-enter in Jupyter without the community rolling up their sleeves in unison and solving it at the core.

But hey, I guess that why we're going in, isn't it?

This weeks sponsor: You?

If you find the chronicle valuable, and would like to support the video relaunch work, it would really help if you would Buy Me a Coffee. 🙏☕️💛

It is quite poetic because I'm funding the relaunch of FFF completely out of my own savings, focusing full-time to get it out, and keeping costs low by working out of a local coffee shop here in Stockholm - so buying me coffee is support in a quite literal way. 😅

In these early days, before I can get the regular production beat off the ground (getting theeeeere, but man it's taking longer than I thought!!) sponsor income is sparse, so buying me a coffee actually matters a lot amount for my stress levels over runway in this starving-author mode that I have cast myself in, hah! 😳

And if you do, please write a comment, it's one of the more delightful aspects of Buy Me A Coffee to get these little lovebombs 👇🥹

Dear you (and ganonbit and everyone else), I hope that you all run across a peculiar dog this week that brightens you day.

Keep on being curious.