4 ms·

> The RTFM philosophy combined with a wall of single-file manpage with no tutorial is something that I really wish died already. With respect: what do you do f

> The RTFM philosophy combined with a wall of single-file manpage with no tutorial is something that I really wish died already. With respect: what do you do for the tools you use to help this situation? The software is open source and accepts patches, and I'm sure they'd love to accept a patch that adds user-friendly documentation to the tool.

d33 6y ago
It sounds like a loaded question, but a perfectly valid one :) If you're asking whether I actually change the tools I complain about then the answer is "no". The reason is that if you hate how, say, coreutils works and have a strong vision of how it should be restructured, it will boil down to being off-putting to the mainteiners at best and - at worst - becoming a rewrite anyway. This is why I see my role as more of a propagator of tools that want to dethrone the current defaults: I look out for new exciting projects that have wildly better ergonomics than what's most common and I recommend them to my friends. And given that I'm running a hackerspace in my city, I have a bit of a reach so I think that this strategy might be a net good. I also try to share knowledge on how to code and keep in touch with FLOSS communities, so while I might not be contributing code directly, I (hopefully) end up bringing contributors anyway. And while we're talking about spreading the word when a project has good ergonomics, here are some examples I personally love: 1. "glances" - a tool that combines a couple of tools like top, iftop, iotop and various other monitoring programs into one CLI dashboard. It's a bit chunky, but its functionality justifies it. 2. "fd" (cargo install fd-find) - a simpler version of "find". instead of crazy "find -iname 'something" you can just do "fd something". It's also faster. 3. "ripgrep" - like fd, but for grep. Defaults to recursive grep and skips .gitignore, so you can just type "rg variableName" and see all occurrences of it within files in your directory tree. But you're right, I love to complain and quite frankly, in many cases I'm disappointed by priorities some projects choose in terms of ergonomics. Disappointed up to the point that I gave up sending patches - or even filing issues (example: GitLab). Perhaps a solution to the problem would be to have something like a GitHub badge signalling "UX feedback is welcome" or "RTFM", depending on one's design philosophy? That would help developers reach their target audience, regardless of which side of the argument they prefer.

d33 6y ago

It sounds like a loaded question, but a perfectly valid one :) If you're asking whether I actually change the tools I complain about then the answer is "no". The reason is that if you hate how, say, coreutils works and have a strong vision of how it should be restructured, it will boil down to being off-putting to the mainteiners at best and - at worst - becoming a rewrite anyway. This is why I see my role as more of a propagator of tools that want to dethrone the current defaults: I look out for new exciting projects that have wildly better ergonomics than what's most common and I recommend them to my friends. And given that I'm running a hackerspace in my city, I have a bit of a reach so I think that this strategy might be a net good. I also try to share knowledge on how to code and keep in touch with FLOSS communities, so while I might not be contributing code directly, I (hopefully) end up bringing contributors anyway. And while we're talking about spreading the word when a project has good ergonomics, here are some examples I personally love: 1. "glances" - a tool that combines a couple of tools like top, iftop, iotop and various other monitoring programs into one CLI dashboard. It's a bit chunky, but its functionality justifies it. 2. "fd" (cargo install fd-find) - a simpler version of "find". instead of crazy "find -iname 'something" you can just do "fd something". It's also faster. 3. "ripgrep" - like fd, but for grep. Defaults to recursive grep and skips .gitignore, so you can just type "rg variableName" and see all occurrences of it within files in your directory tree. But you're right, I love to complain and quite frankly, in many cases I'm disappointed by priorities some projects choose in terms of ergonomics. Disappointed up to the point that I gave up sending patches - or even filing issues (example: GitLab). Perhaps a solution to the problem would be to have something like a GitHub badge signalling "UX feedback is welcome" or "RTFM", depending on one's design philosophy? That would help developers reach their target audience, regardless of which side of the argument they prefer.