Re: this earlier post: https://mastodon.social/@mhoye/110991950899025738

One of the things I'm most proud of in my last gig was adding notes to our getting-started docs saying explicitly "if this process fails for you, this is a bug and we want to hear from you."

Granting explicit permission to file bugs against the _get-involved process_, quickstart docs particularly, is another way of saying "we care about the details of the experience of getting involved in this project and community", and it is very powerful.

There is such a thing as community accessibility, of the ergonomics of getting involved. It is _extremely common_ for smart, determined people to hit failure after failure during an install process, and decide this project or community just isn't for them. Open Source projects often end up self-selecting for people who coincidentally have not just hardware or software but _cultural expectations_ identical to the primary developers, because all of those failures are completely invisible.

As one example - a bunch of our docs said "copy and paste this command:"

> command whatever blah

... and people were copy-and pasting "> command", with the caret and it was failing because of course it was.

Absolutely trivial to fix, but a completely invisible non-problem to anyone who's grown up in a console. But what designer, or technical writer, or translator or or or, would reflexively understand the problem wasn't them?

@mhoye I think about this all the time. What rarely if ever happens: the author of the doc is forced to watch a designer/writer/translator fumbling around making those mistakes. Or the creator of a web app is forced to watch people trying to enter phone numbers into forms. Or really any designer or builder of a product is forced to watch people struggling to use it.

I'm not talking about focus groups. I'm talking about chaining builders to chairs, gagging them, and making them actually watch.

@judell My friend Blake once said this about the critical importance of not just user feedback, but actually watching humans use your site or tool or thing or whatever. His line was, "you'd think to yourself, users do what? But then you find out they do nothing _but_ 'what'. 'What' is 90% of all they ever do."

@mhoye Ideally of course the developer /is/ a user. That works out beautifully for programming tools but not much else.

Paul English once told me that he made the Kayak devs rotate through front-line customer support so that, the nth time they heard the same complaint, they'd be like "Screw this" and just go fix it.

@judell I disagree that devs-are-users is a net good. My experience is that it can just as often mean “muscle memory forms to work around problems I don’t want to own” as it can to ownership.

That said, I strongly agree that devs should be required to spend time subjected to the same things they imposed on other people. If Facebook engineers had to spend three days a quarter doing the moderation work they foist off on contractors, the world would be a much better place.

@judell @mhoye working on a small company as a dev means that I also deal with customer support all the time and this makes me end up fixing a lot of small annoyances that would otherwise be left there for a long long time
@lilongueti @judell The core insight of "devops" as a practice, before it morphed into "service contract management through a console" - was that if you have to carry the on call pager for the software you wrote, you write better software. I've long believed the same is true of front line support, and that if anyone in the org takes support calls, the people who wrote the code should spend a few days every quarter doing the same.
@mhoye The project director for a previous job led the devs on a tour of the support group office across the street to ensure that we got the point about usability, especially after seeing how much ad-hoc tooling the support staff used as workarounds for bad support UI.

@judell @mhoye

I often think of Reaper in this context (music software). The way you can use the mouse wheel to expand the timeline, the ease of setting up keyboard shortcuts, the way there nearly always is a way to do the thing that you logically might want to do. I definitely have the vibes that there's a link between that smoothness & its coders (or at least some of them) using it for their own music.

@unchartedworlds @mhoye Yeah, when the developer happens to be a user scratching their own itch it makes a huge difference.

@judell @mhoye Federated Wiki's meeting today discussed how effective video game onboarding is, as a model for embedded tutorials and skill transfer. (and embedded bug reporting!)

We presume dev-as-user to some extent but there are cases like collaborative coursework better matched to a gentle and direct introduction to how things work.