On mocking

I just read a blog post on "The care and feeding of software engineers (or, why engineers are grumpy" [1] and I wonder if the points about appreciation towards the end aren't relevant here? I know a lot of FLOSS developers who've suffered burnout at various points and I do think it's partly due to an unnecessary amount of hostility. I also know folks who've tried to break into FLOSS who either gave up or didn't even try because of either they experienced or thought they'd experience rudeness and hostility. Maybe more visible appreciation for both the established developers and the potential recruits towards each other might help?

Another thing that stood out to me while reading this was its mention that there's some annoyance / bandwidth limitation on giving repetitious feedback on the same few issues / mistakes that crop up over and over again. I am sure it's already been considered and maybe even attempted, but it might help for the (understandably overwhelmed and probably time-starved to do something like this) developers to take note the next time they get a repeat mistake until they have a pretty full inventory of the issues that keep cropping up over and over again. Then, maybe post bounties or something for people who know what they're talking about to film screencast tutorials or write-ups to explain why doing x-and-y is the wrong approach or why z is a known bad solution. Maybe you could tell the person submitting an idea or code that you'll explain to them what the issue is thoroughly and kindly if they promise to take good notes and blog or screencast what you told them? Then, you could write some macros or something when responding to the issue when it inevitably comes up on list to point to the screencast / tutorial / etc automatically.

Nobody wants to be explaining the same thing over and over again - an engineer's time is better spent taking on new challenges and solving new problems. I think it is very understandable for someone to snark or otherwise lash out when stuck in this situation. But if you don't teach others to do what you already figured out how to do, it is going to be harder to find people to take over the work you're bored with so you can move on to new & exciting territory. So I think the teaching part is important. While aimed at sysadmins, I think Emily Gladstone Cole's talk from WiAC'12 this past week [2] is pretty relevant here.

[1] http://www.nczonline.net/blog/2012/06/12/the-care-and-fee...

[2] http://blog.linuxgrrl.com/2012/06/13/wiac-12-staying-happ...