My favorite anecdote, and the one I trot out every time this comes up, was the time I was asking for help in golang-nuts and on the IRC figuring out a few thing

My favorite anecdote, and the one I trot out every time this comes up, was the time I was asking for help in golang-nuts and on the IRC figuring out a few things about unsafe/uintptr. I was participating in a code competition with performance as a primary metric and learning Go at the same time. Trying to get somebody to answer very straightforward questions about casting was worse than pulling teeth; everyone wanted to work their way into a back-seat architect role on my "real goal". "Hey, here is this task/problem I'm solving. Is this solution okay or is there a better solution?" is a very different question than "I'm trying to cast this pointer back to this slice of types but I'm seeing this error; what am I missing?". A somewhat related pet-peeve of mine is when software authors bake assumptions about how somebody "should" be doing something into their projects at a low level causing it to become unnecessarily inflexible and often time inconsistent with what you would expect. I've run into this with a lot of Gradle and gradle plugins.. My first big experience was perhaps trying to convince NTFS3G to allow the user to clear or override the dirty bit for certain resize operations. It can take a lot of convincing to get people to expand their concept of a "valid use case" and create escape hatches and flexibility for those atypical situations.