"For Humans" makes me cringe

for chodes

When Kenneth Reitz created the requests library, the Python community rushed to embrace the project, as it provided (finally) a clean, sane API for making HTTP requests. He subtitled his project "Python HTTP Requests for Humans", referring to the fact that his API provided developer-friendly APIs. If naming things "for humans" had stopped there, that would have been fine with me, but instead there's been a steady stream of new projects describing themselves as being "For Humans" and I have issues with that.

It is an empty signifier

People use the for humans meme so frequently on projects that it's original intent and meaning have been obscured, leaving only a meta-meaning -- which is no meaning at all. When I see it today, I only see the other person trying too hard to signify that they are "in". It is the opposite of some people's tendency to obscure things in jargon, but they both derive from the same underlying impulse.

There's also a whiff of self-deprecation implied, "X is difficult, so here's something for humans". But of course in order for a project to be useful, the maintainer must have a command of the subject, so it comes off as a show of false modesty.

It is dismissive of other packages

When a new project comes out describing itself as X for humans, it somehow implies that any other libraries existing in the X space before were somehow not for humans. Since for humans is meant to connote sympathy for the developer, this label implies that other packages were not developer-friendly. In other words, it's a bit of a backhanded dig at other libraries for having bad APIs.

The audience for any Python project is always going to be a developer somewhere. To call your project For Humans is just a pretentious way of saying that you see your project as having a superior API to other projects in the same space.

Let the library speak for itself. Let others be the judge of it's quality.

Fixing the situation

Let's fix the situation by describing our projects based on what they do. I know the HTTP situation back when requests came out was pretty bad, and Kenneth was making a nice point back when he released his project, but I think it's time to move on.

I don't mean to pick on Kenneth, but:

Sadly these are real examples. PEP8 is itself a standard that describes making code more user-friendly, and Markdown is a markup language that is already designed to be readable by people. SQL was specifically designed to be easy to use by people...

I would ask the Python community to drop the whole humans thing. If your project has an awesome API, then show us, don't tell us. If your project is an improvement over other projects in the space, then show how they compare. But just labeling your project for humans is both disrespectful and honestly a bit cringe-worthy.

Comments (2)

lethargilistic | mar 13 2016, at 08:31pm

I've also started to notice and grow weary of this. I remember listening to a Reitz talk or reading something he wrote, where he talked about the original tagline of requests. I don't remember exactly what it was, but it was something like "HTTP that isn't stupid," and the intent of the change to "For Humans" was to avoid the negativity you're complaining about in this article. In that respect, it was a great idea, and its influence as a guiding principle and reminder of the need to consider an API's usability from the start shouldn't be underestimated.

That said, I think the world would have been much better served if the actual use of "For Humans" was left to be Reitz's own tagline. It has definitely reached a saturation point and doesn't actually help describe what a given package is about.

requests fanboy | mar 13 2016, at 07:44pm

I would mostly agree with you but some authoritative libraries, like requests, ARE better than their counterparts and I think it's perfectly reasonable to describe requests as "http for humans."


Commenting has been closed, but please feel free to contact me