Jim Nielsen’s Blog
Preferences
Theme: This feature requires JavaScript as well as the default site fidelity (see below).
Fidelity:

Controls the level of style and functionality of the site, a lower fidelity meaning less bandwidth, battery, and CPU usage. Learn more.

Empowering the Few

While going through some old text files, I stumbled on this old draft of a blog post. How old? Well, in it I talk about having read something from Readability, a now (unfortunately) defunct service. So probably about 2014? Nonetheless, I liked re-reading and it still feels relevant. In fact, my friend Michael Flarup recently expressed a similar sentiment when he released his app icon design course for free:

I understand how little this does & how insignificant it is, but if I can take even one persons mind off a difficult situation momentarily then I'm happy.

So despite it being a draft from ~6 years ago, I’m still posting it. You might ask, “but Jim, isn’t this just a ploy to reach your self-imposed quota of 50 blog posts this year?” My response to that:

Image of nervous monkey puppet meme.

Here it is:


I was recently browsing through my recommended reads on Readability and I stumbled on this:

Screenshot of a recommended article on Readability from thegaw

When thegaw recommends something to read, it’s worth reading. If he recommends something worth printing and taping to every wall in my office, well let’s just say I took notice.

The article is titled “How to be a Great Developer” and is written by Ed Finkler (a.k.a. funkatraon). There are a lot of really good insights in the article, I suggest you take a look. However, I want to focus on one particular point made in the article:

Don’t worry about how many people use what you make. Empowering 5 people is incredibly special. They will remember what you did for them.

As far as I know, I’ve never created anything which has been seen and used by millions people. I have, however, created and written a few things seen by a few people. I generally have no idea how my handiworks are perceived by others. I simply hope their experiences with them have been pleasant.

Occasionally, however, I do get small insights into how my projects are received and experienced. One example is teamcolors, a weekend hackathon project I pieced together when I worked at Arc90. It’s a simple compilation of HEX color values for professional sport teams.

Screenshot of teamcolors.arc90.com

Since its launch, the product has received a few changes and updates, most of them courtesy of people who willing contribute pull requests for the project.

One day Github issue #28 came in: a request to fix the way the web page was being printed. Honestly, I had never given any thought to the site being printed. When asked about his usage scenario, the guy who submitted the issue said this:

I was working on a local little league web site and wanted to color some text to match the team color…If printing had worked I would have printed up a "booklet" to stuff in my reference files.

I would have never thought someone would use this weekend hackathon project in such a way. I submitted a fix, though who knows how many other issues exist on this project that simply haven’t been discovered yet.

My point is: you never really know how one tiny project might help someone out in an odd way you never imagined. I wouldn’t even go so far as to say this guy was “empowered” by my tiny project. More likely it was simply the resolution to a tiny problem he was facing, but that’s good enough. I’m going to go ahead and state the obvious: empowerment or kindness doesn’t have to be at scale to be of value.