5 ms·

The problem is not that they "message themselves" (gross) wrong, but that they feel like they have to "message" at all. Sales & marketing mumbo jumbo has no pl

by ezy 11y ago

The problem is not that they "message themselves" (gross) wrong, but that they feel like they have to "message" at all. Sales & marketing mumbo jumbo has no place in devtools -- it is at best, obfuscation -- at worst, misrepresentation.

akanet 11y ago
I find that position to be very hard to understand - devtools live or die by their adoption. A clear understanding of what a tool does is critical to its adoption. Look at, say, the homepage of Ruby: https://www.ruby-lang.org/en/ https://www.ruby-lang.org/en/. There's a clear, two sentence explanation of what it is: A dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write. There's an example embedded on the page. There's also recent news that intermediate users might be interested in. On Docker's website, there's a huge amount of confusion about what Docker even is. A platform? A runtime? Both? Which is the one I should care about? The nerd-centric viewpoint that tool should succeed entirely on their own merits, with no affordances for the user, is crazy. It's that attitude towards UX that has lead to the following one-liner to being the only way to do something so mundane as "removing all your untagged images": docker rmi $(docker images | grep "^<none>" | awk "{print $3}") Any business that interacts with other humans needs to concern itself with messaging, and I don't think computer industry types are exempt in any way.
- anonfunction 11y ago
  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.
  - Leynos 11y ago
    Or the marginally shorter: docker images -f "dangling=true" -q | xargs -r docker rmi
    - anonfunction 11y ago
      Looks like my `docker-stats-all` alias: docker ps -q | xargs docker stats
    - curun1r 11y ago
      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.
- vezzy-fnord 11y ago
  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/Softwares/nosh.html 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.
- ezy 11y ago
  "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?
  - NeutronBoy 11y ago
    > 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.
  - nathan_long 11y ago
    > 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 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.
dragonwriter 11y ago
Devs are people. Getting people to use things requires communicating to them what the things is for, and how it is better than other alternatives, and how to use it to realize that benefit. Therefore, devtool adoption requires messaging related to what the devtool is for, how the devtool is superior to other alternatives in the same space, and how to use the devtool to realize that superiority. Actually having the tool is a start, but its not the ballgame if no one can understand what its for, why they should use it over other things that serve the same purpose, and how to use it.
- ezy 11y ago
  I get that you want to make people aware of the tool and its advantages because you think others might find it useful. But what part of that requires any attention to the condescending idea of "messaging" vs just straight up telling people (a) what it does and (b) why you created it. Anyway, perhaps I'm being a grumpy old man late in the workday, I'll leave it be :-)
  - dragonwriter 11y ago
    > But what part of that requires any attention to the condescending idea of "messaging" vs just straight up telling people (a) what it does and (b) why you created it. "messaging" isn't a condescending idea, its simply having clear, coherent means of communicating some message, with awareness of the audience that message is directed to. Like, what your product is for and why people should (and how they can) use it.
  - carapace 11y ago
    You are correct, and the people downvoting you are wrong. Technical engineering decisions should be made on the basis of concrete analysis and not popularity contests. The noisy kids will come around sooner or later.

by ezy 11y ago

akanet 11y ago

I find that position to be very hard to understand - devtools live or die by their adoption. A clear understanding of what a tool does is critical to its adoption. Look at, say, the homepage of Ruby: https://www.ruby-lang.org/en/ https://www.ruby-lang.org/en/. There's a clear, two sentence explanation of what it is: A dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write. There's an example embedded on the page. There's also recent news that intermediate users might be interested in. On Docker's website, there's a huge amount of confusion about what Docker even is. A platform? A runtime? Both? Which is the one I should care about? The nerd-centric viewpoint that tool should succeed entirely on their own merits, with no affordances for the user, is crazy. It's that attitude towards UX that has lead to the following one-liner to being the only way to do something so mundane as "removing all your untagged images": docker rmi $(docker images | grep "^<none>" | awk "{print $3}") Any business that interacts with other humans needs to concern itself with messaging, and I don't think computer industry types are exempt in any way.

anonfunction 11y ago
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.
- Leynos 11y ago
  Or the marginally shorter: docker images -f "dangling=true" -q | xargs -r docker rmi
  - anonfunction 11y ago
    Looks like my `docker-stats-all` alias: docker ps -q | xargs docker stats
  - curun1r 11y ago
    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.
vezzy-fnord 11y ago
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/Softwares/nosh.html 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.
ezy 11y ago
"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?
- NeutronBoy 11y ago
  > 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.
- nathan_long 11y ago
  > 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 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.

dragonwriter 11y ago

Devs are people. Getting people to use things requires communicating to them what the things is for, and how it is better than other alternatives, and how to use it to realize that benefit. Therefore, devtool adoption requires messaging related to what the devtool is for, how the devtool is superior to other alternatives in the same space, and how to use the devtool to realize that superiority. Actually having the tool is a start, but its not the ballgame if no one can understand what its for, why they should use it over other things that serve the same purpose, and how to use it.

ezy 11y ago
I get that you want to make people aware of the tool and its advantages because you think others might find it useful. But what part of that requires any attention to the condescending idea of "messaging" vs just straight up telling people (a) what it does and (b) why you created it. Anyway, perhaps I'm being a grumpy old man late in the workday, I'll leave it be :-)
- dragonwriter 11y ago
  > But what part of that requires any attention to the condescending idea of "messaging" vs just straight up telling people (a) what it does and (b) why you created it. "messaging" isn't a condescending idea, its simply having clear, coherent means of communicating some message, with awareness of the audience that message is directed to. Like, what your product is for and why people should (and how they can) use it.
- carapace 11y ago
  You are correct, and the people downvoting you are wrong. Technical engineering decisions should be made on the basis of concrete analysis and not popularity contests. The noisy kids will come around sooner or later.