Skip to content

Learning can be a painful experience

Even for experts… Learning can be problematic, and painful!

Lea Verou, recently posted, a very honest, and open account of an interaction with contemporary JavaScript.

People also might not takeaway what you would like them to from a learning experience. This can be especially true, if they feel they know what they are doing, which it is fair to say Lea Verou does!

This seems, a perfect example of some problems people face. It is great someone with a platform is calling it out.

I would love for learners, to carefully call this out, if possible in a kind and empathetic way.

Problems we can experience

  • Subtly different syntax or language can be a barrier to discovery, or cause friction.
  • Changes, or nuance in API can remove cues and contextual awareness from even the most expert.
  • Teaching the what, but not the why, deprives learners of the ability to extend ability, and naturalize language.
  • [re]Definitions, that do not seem to match intention, or expectation may further confuse, provide a barrier to uptake.
  • Missing tests or ambiguity, even if only of intent may cloud or knowledge of what was.

Some of my own experience

Recently, when standing up a Python project, from a large communications business over my weekend; it was not JS that surprised me. It was how much time it had been since I had interacted with this code. How little maintenance it had received. How much I had inferred or improved when looking back.

It was not code I had ever contributed to, and thankfully I was not the author. That gave me some pride. Some of the issues I faced, were that Python 2 language has undergone a deprecation. That means, nobody should be creating more code in Python 2, and everybody, who has created code should be looking to communicate the information to others that Python 3 is the new syntax being used.

This is not just down to language vendors either. A Subtle change in your API at your workplace can be catastrophic for people who find your services and goods essential. It always pays to be more conservative if you have value in what you do.

If you do not have value, or do not believe you have value in what you do, I do not know why, or how you stay motivated

A Large vendor, making public code, that failed to invest in something that is core to their business disappointed me. It did not surprise me unfortunately.

I know and have met people that work there. They are wonderful people. The project has a nice intent when pushed out 7 years ago. I was shocked that in 7 years, with a corporate sponsor, the project had not seen 100 or more contributions.

What I did

Instead of ranting, making a post; I chose to fix-up the public code, documenting in a GitHub issue some of the things I found as I went through. I did this for a few reasons. One of which was that at a group I have invested time in; I had recommended this project to someone based on a fond memory of it.

Unless I was under mandatory COVID-19 lockdown, I would not have chosen to spend my time to do this. Everybody should not do what I did; even if it might improve outcomes for the end-users. It is unreasonable and even I would not have done it, if I could have been outside.

It should not be, for individuals to improve businesses during their spare time!

The business should feel a responsibility for what they put into the world, or take care to communicate their intent.


I would very much like for business to recognize that they need to drop the fetishization of owning IP that they leave to rot, or do not use for the benefit of their customers; and embrace a more collaborative model.

I managed to get the thing working, which included some as-yet non-standard techniques, to pass complex data via Environment variables, many guesses and unfortunately iteration on the few tests included.

I have bundled it in such a way, as to make it look like it is a single change. That is not an honest account. It was a process with a lot of change and disappointment.

I shared my code changes and communicated to a person I had evangelized this project to, just days earlier, that it needed work, but here was some things that I had done to help them.

It can be important to drop the baton sometimes. It can be cathartic, and instructive, to rant or retrospect.

I would love to get some contracting work to help organizations improve their public or private code as I thoroughly enjoy this process and find it can yield more value than greenfield efforts.