Hacker News Reader

"I find that position to be very hard to understand - devtools live or die by their adoption"

Some of the time, that is true, but not all the time, maybe not most of the time -- you are putting the cart before the horse. In fact, I would argue that this is an anti-pattern. Yes, you might use (e.g. to pick 2 unrelated domains) Hadoop or Python because they are popular, but consider how they got popular in the first place.

Devtools exist to solve a problem. You should not evaluate devtools based on the webpage or how many people are using it. That way lies Oracle enterprise. :-)

The problem with Docker's website is not that it exists. It is that it substitutes sales & marketing for just simply explaining what it is to a developer. While one could classify this under the category of "marketing", it would be a mistake -- kind of like classifying man pages as sales pitches. Just tell me what the fuck it does for god sakes and I'll decide! I could give a rats ass whether Facebook uses it, etc...

To be clear, I find Docker, the tool, useful, I just think it doesn't need "Marketing", it needs a useful webpage.[1]

Ruby was not adopted because of its webpage or its user base, it was adopted because one person bothered to look into it, liked it and decided to build a very popular web framework around it. Others saw the value in that domain and it exploded. Similar situation for Linux, which started from an FTP site and usenet posting. :-)

"The nerd-centric viewpoint that tool should succeed entirely on their own merits, with no affordances for the user, is crazy."

Unrelated to what I was talking about entirely. Affordances to the user is a merit of the tool itself. Docker could be considerably easier to use in some regards, and that would improve it's usefulness as a dev tool. However, this has nothing to do with attempting to gain marketshare with no direct relation to merit.

[1] But then Docker, the organization, is selling something, aren't they?

> To be clear, I find Docker, the tool, useful, I just think it doesn't need "Marketing", it needs a useful webpage

What exactly do you think Marketing is? It's not all about BS, it's about communicating a message. If that's a simple webpage, then so be it. Often an idea or product is far too complicated to explain through 2-3 lines of text and needs more.

> Devtools exist to solve a problem. You should not evaluate devtools based on the webpage or how many people are using it.

That sounds rational and it's what I used to think, but I think this talk (https://www.youtube.com/watch?v=FzzL_QDKv0c) makes a good case that fuzzy human factors always play a role in technical decisions, and that's not necessarily bad.

Eg, which is better, Angular or Ember? Ruby or Python? Go or C++? Haskell or Common Lisp? You can accomplish the same things in either tool. Which you like better has a lot to do with what you already know. And popularity may seem like a shallow measure, but it affects whether you can get questions answered, find blog posts and books, locate a library to do something for you, and hire developers who already know the technology.

Popularity is probably also weakly correlated with stability. If my custom jQuery code doesn't work, there's a 99.999% chance that it's the fault of the code I wrote (used by 1 person) rather than of jQuery (used by thousands). When jQuery was new and used by tens of people, there was a higher chance that it was jQuery's fault.

"Ruby was not adopted because of its webpage or its user base, it was adopted because one person bothered to look into it, liked it and decided to build a very popular web framework around it."

dhh is a brilliant marketer.

That one-liner won't work (for me), it's missing a slash in the awk command. I have this aliased as `docker-rmi-junk` since it's so common.

    docker rmi -f $(docker images | grep "^<none>" | awk "{print \$3}")

I agree with everything else you're saying completely. Although messaging a value prop is hard when you have so many use cases. We faced the same issue and ended up trying to segment users as quickly and high up in the funnel as possible so we could speak directly to their needs.

Or the marginally shorter:

    docker images -f "dangling=true" -q | xargs -r docker rmi

Looks like my `docker-stats-all` alias:

    docker ps -q | xargs docker stats

You can actually go even shorter:

  docker images -qf dangling=true | xargs -r docker rmi

Along with:

  docker ps -aqf status=exited | xargs -r docker rm

You've got two essential Docker aliases for cleaning up your dev environment.

A clear understanding of what a tool does is critical to its adoption.

The definitions of "clear" differ depending on who the target audience is. If you're assuming a heterogenous group of unknown faces, then you aim for colloquial and simplified language.

When marketing to programmers, however, the use of technical jargon and specific concepts is an absolute necessity for something to attain clarity. It's the avoidance of such that obfuscates meaning.

Here's an example of a good software overview: http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar...

The nerd-centric viewpoint that tool should succeed entirely on their own merits, with no affordances for the user, is crazy

This is a straw man. Introductions can be concise or detailed, but they must convey some of the technical intricacies and underpinnings regarding the software. Using marketing language, clouds of buzzwords and too many dumb copy-paste examples leads to cargo cult development and people who jump on bandwagons as opposed to surveying for what is technically superior.

Furthermore, there's nothing wrong with your one-liner.