@freakazoid LOL, Captain Sean with the BROLIC take.
Hahaha, I understand what you mean, but I like things being accessible too. Being unfamiliar with the command line shouldn't exclude people from using a particular tool.
So yeah, people should learn, but I don't think they should be excluded if it takes awhile.
@Are0h I'm a very strong believer in mentorship and good documentation. It's not being unfamiliar with the command line that's an issue, it's refusal to use it. My own employer has ended up with an awful bespoke alert definition system that requires exporting JSON from Grafana because the person building out our monitoring didn't feel that developers would be willing to learn to write Kapacitor rules.
GH are not interested in accessibility; they're interested in lock-in.
@freakazoid Ah, I hear you. Having experience with working with systems that are built on the whims of an inexperienced dev making bad decisions, agreed.
@ajroach42 @Are0h Speaking of UIs and usability, last week's risky.biz interview was with Sally Carson of Duo Security talking about how they employ a designer for every 5 developers, which is why I expect them to wipe the floor with everyone else in the space. Usability is inseparable from security.
@Are0h I've said the same about programming languages: they should lift people up, not dumb themselves down.
Git's fairly well documented, but it does have the problem that people need a certain "a hah" moment before they can get themselves out of tight spots. A UI that showed the actual repo structure rather than just the branch structure might be really helpful for getting people to that point. Like, show the objects, trees, stash, index, and reflog!
@freakazoid Git had this really weird elitism based on how esoteric and often indecipherable it was unless you understood the inner workings of shit no one cared about. That kept me away from it for a long time.
Once I dove in and saw how it works, it's actually pretty slick, but when one wants to talk about it, it's usually JUST READ THE DOCUMENTATION.
Looking back, I would imagine people managing git simply didn't have social skills, including Linus.
And we know how toxic that becomes.
@Are0h IMO the most important Git documentation doesn't talk about the internals at all but the underlying metaphor. http://tom.preston-werner.com/2009/05/19/the-git-parable.html
@Are0h I would say they didn't have social skills, ESPECIALLY Linus - he was really setting the tone for a lot of open source software development.
@freakazoid Definitely agree.
@freakazoid I WISH documentation was written like this. We can have the technical tidbits too, but this makes it understandable to just about anyone, which increases adoption.
Git eventually won out because it's a good tool, but imagine if their docs mimic'd this from the start.
@Are0h I think for that to happen we'd need for more people to be involved in open source because they wanted to help people and build communities rather than to prove how smart they are and get people to worship them.
@freakazoid HARD. AGREE.
Most open source projects are initiated simply ego and wanting to replicate pre-existing systems in their own image rather than being fresh and innovative and try new idea.
@Are0h Right, so any criticism a developer gets, up to and including "stupid questions", ends up hurting the developer's fragile ego, since in their mind their software and documentation are perfect, or they're doing everyone a favor by putting the software up so they should all be grateful. Granted, users can act plenty entitled, too, but at the end of the day it does no damage to be helpful. One can always include a link to the relevant part of the docs with a request for feedback on it.
@Are0h Even an acknowledgement that one is bad at writing documentation would go a long way toward making people feel supported, even with a request to edit it if one is so inclined. Which is a reason to always use wiki-based or at least easily-editable-by-non-developers documentation. Or even just have an easy way for users to add comments or open documentation bugs.
@freakazoid WHAT? ADMITTING YOU'RE NOT PERFECT AND EVERYTHING??
Ha, can't have that.
@Are0h It took me a while to figure out that people's respect for me tended to *increase* when I talked about things I was bad at. It also turned out to be instrumental in getting over imposter syndrome because it gave others the opportunity to clarify their expectations of me, so I was able to realize that they weren't, in fact, overestimating my abilities.
@freakazoid I feel you. We're taught not only as devs, but as men, that we're supposed to have answers for everything, or at the very least put up a strong front that makes people think we do.
But this kind of dehumanization is at the heart of society and culture we live in, so it permeates our chosen profession as well.
Building cool shit is just easier and often better when we're honest about what we can do and where we need help.
That context is just counter to what we're taught coming up.
@freakazoid And this stance directly feeds into how toxic these communities become. They turn into cults for personality rather communities building cool shit.
It's generally one of the reasons I just tend to build my own stuff. It just isn't worth assuaging some random person's ego to get a handful of issues that aren't that big a deal to be addressed.
A social network for the 19A0s.