[09:00] <Someone> Hi.
[09:16] <Me> Hey, what's up.
[09:23] <Someone> I have a problem, do you have some time?
[09:24] <Me> Sure, what's it about?
[09:27] <Someone> Have you worked with X thing before? I have to do Y thing but don't know how.
[09:28] <Me> So, I just googled "how to do Y thing in X thing" and got this blog entry explaining in detail, and also this other Stack Overflow answer with a very similar problem.
[09:29] <Someone> Sec, gonna try that.
[09:35] <Someone> I got this error "someVariable is not defined". What's it mean?
[09:36] <Me> You're trying to use a variable that doesn't exist. Can you paste the code you're using?
[09:37] <Someone> (Code)
[09:37] <Me> Replace "someVariable" for "someOtherVariable" and it should work.
[09:38] <Someone> It works, thanks!
The latter almost always ask simple questions serially - it's obvious they're looking for a sequence of steps to follow instead of sussing out the problem on their own. They want to use your problem solving abilities instead of developing and using their own.
The former usually ask pointed and precise questions - and after they get an answer they usually go away. I say this not to be anti-social (even though I am) but to simply note they go quiet because they're actually working the problem.
Practical programming involves dealing often with problems that are messy, obscure, and vague. They don't teach you that in CS101. Some beginners detest that class of problems because purism is trendy, but they still have the patience to work through them, and because those moments are what teaches you programming, they make progress despite their own objections.
Some people simply don't have the patience. They put up a lot of resistance to spending time on any problem that's not immediately recognizable to them. As a result, they never advance in the discipline.
It's a win-win, because either the asker learns they can solve their problems more quickly by Googling it themselves, or I can limit my responses to a rate that is below my daily (or weekly) annoyance threshold.
I actually like teaching coding 101. Not everyone has to, but I do. And I find people generally appreciate someone going back to the basics and explaining the tactics and theory behind a problem, rather than just giving the answer or the steps to find it.
I just think coding is neat, and I love talking about even the most basic ideas. I always find new little improvements on my understanding of fundamentals.
I have had the “even the most experienced programmers spend most of their time having no idea what’s going on. The job isn’t to always know what to do, it’s to always find a way to keep moving even though nothing makes sense” conversation dozens of times. Maybe I’m weird.
My solution was to write a static analysis tool (ShellCheck) that would recognize them automatically and with enough confidence would even auto-answer. It's gotten way more use than I ever expected.
Haven't made much progress on the plaintext question problem though. Some day!
In a real sense, someone acting like this is insulting. Rather than the homeless guy anecdote in the article, it's like someone asking you for money, not because they're desperate, but because they just think you're a sucker.
For the genuinely well meaning and self motivated learners, I agree we should try hard to be sympathetic and respectful.
I agree with this, but I think part of this is fighting the instinct to sarcasm or hostility even when people are looking for the easy way.
Whenever people start employing public hostility, the people who are deterred the most are the least confident and most well-intentioned people. If you're asking someone else to do your work for you, you presumably don't care much about their time and frustration. But if you're cautious and respectful and already worried about wasting people's time with dumb questions, then seeing someone who's annoyed and likely to snap at you is a huge deterrent.
"What's the ticket number" may not be a productive question, but I still winced at that answer - I can't imagine that a Slack where people are that hostile is one where people feel comfortable asking potentially 'dumb' questions and getting support. Better to stay silent, or say "that's something you can do as well as me", or politely say "their ticket queue actually has a great search feature". Calling out unjustified questions is hopefully less alienating, because it at least shows why you're annoyed, and that you wouldn't do the same to a question that's novice-level, but not rude. And if these questions are too common to handle politely, that's its own serious issue at the company.
I am unable to count the number of times I've gone to some random project community for assistance dealing with whatever problem I was having at the time to be met with someone telling me that what I'm doing is insane and shouldn't be done in the first place.
It's taught me that I should just use these outlets as a last resort. I'd rather struggle with whatever I'm attempting to solve and try to refine my searches beyond the amount of time for it to be useful than deal with very opinionated and unhelpful people in a chatroom/mailing list/forum.
The unfortunate thing is that this is generally something that happens when I deal with open source and when asked about why the interaction is the way it is, there is always a retort by someone saying the help is free and that I should be grateful. The feeling is certainly something that I could compare to what I imagine the receiving end of the santa scenario was.
Community - Fully open to discussion and contribution from everyone, decisions are made collectively and contribution / support responsibilities are shared by all.
Committee - Open to input, but decisions are made by the project leadership. Leadership is voted on by the community and provides support and contribution guidelines.
Ownership - There is a project owner or co-owners that make all decisions and offer support if available and set guidelines on contributions.
Visible - Open source in the sense of being transparent or usable by others, but little to no support offered and contributions may not be accepted.
I think many people think they're walking into a Community project when it's really a Leadership, Ownership or Visible project and feelings get hurt. Much better to set expectations early on in the README.
> Committee - Open to input, but decisions are made by the project leadership. Leadership is voted on by the community and provides support and contribution guidelines.
> Ownership - There is a project owner or co-owners that make all decisions and offer support if available and set guidelines on contributions.
Committee is the Debian Project, which has explicit governance and formal process, correct?
Ownership would be the BDFL model, like Linux or Python or most other projects I could name. Linux breaks down into subsystems, each of which are owned by a specific person, so it's a recursive form of the Ownership model.
I can't think of any project using your Community model off the top of my head.
> Visible - Open source in the sense of being transparent or usable by others, but little to no support offered and contributions may not be accepted.
I think this should have a different name, to make sure people don't confuse it with the non-OSS Viewable Source licenses some companies use: You can see the code, but you can't fork it and distribute modified versions.
Programming is, in a very abstract sense, a dirty job. We get paid well, have great benefits, perks, and mobility, but we are the toilet scrubbers of the software world. We spend whole days hunting semicolons, or trying to reverse engineer bug reports that no one remembers writing. I've spent a whole week trying to move a button over about an inch in all supported browsers just to make the product "pixel perfect". I've spent a whole month trying to figure out how to use a SaaS feature as advertised that had sparse documentation and no tech support.
Some newcomers really don't understand/believe that, and think it's acceptable to run for help every time something frustrates them... do everyone a favor and don't be that person, please.
Why not create a culture that embraces having new comers ask questions in a non disruptive way?
Something like a slack channel where experienced dev's can chime in if they have time.
I'd freak out on anyone on my team if they were telling new hires not to ask questions. That's just stupid.
So, don't start with Slack. Start with the docs, then google, and then end with Slack (even as just a confirmation of your researched solution).
I know php is the butt of many jokes about bad language design and bad architecture, but I wasn’t helped by the glut of terrible, outdated advice about php programming that just wouldn’t go away. I could have benefited from a forceful, constructive voice that not only helped me solve my problem, but taught me to seek a higher sophistication for the code I was writing.
And that’s where I think advanced developers turn into humiliating jerks. I would wager that most of them aren’t deliberately trying to excoriate junior devs, they just are frustrated that developers are repeating the same inefficient path to good practice that they may have trod. Instead of being short-fused and curt, they should take time to inventory the positive things that helped them, and pass those tidbits of effective advice along.
It’s very hard to pause and take note of resources or insights that made you much better as a developer. However, those who can are able to give junior devs a shortcut to excellence that is a net benefit to everyone around them, instead of just getting frustrated that the junior devs aren’t achieving enlightenment as fast as they themselves would have liked to.
He ended up running into an bug that had been open for almost a year but I never got around to fixing because of an existing workaround. Anyway, I was slightly embarrassed and ended up tracking down the bug and closing it out.
It pays to be nice.
But of course, the conscious mind knows better, one must behave nicely, be zen, suppress their feelings, etc. And 10 years later you're visiting a psychologist to deal with your burn out.
What percentage of your free time, for instance, will be spent compared to the percentage of free time of another person? And, what have you done to minimize time required: have you tried to succinctly describe your problem, have you Googled terms in advance, etc.?
Hey, that's what we said in the 90's as well ;-) Well, tbh, we left out the 'high IQ' part.
I have had more experiences than I can count where people keep trying to reinvent the wheel and poo poo an idea that Knuth himself would be proud of.
"I don't have time to explain to you why this idea is good, it should be common sense. It would take you learning programming principles for years before you'll get it, so I won't be able to convince you in a 30 minute presentation."
But the article here kind of glosses over the reality of the hard part: the low quality questions. The "please help me get started"; the "how do I get accepted"; the "please review my PR".
It's all well and good to say, hey, take a step back! Be nice! Don't respond when you're angry! But this is not the reality for an overwhelmed open source organization---and let's face it, most popular projects are completely overwhelmed. The reality is that to wake up every day to countless new issues and pull requests and other demands on your time is absolutely soul-sucking, and after years and years of this it grinds you down and leaves you with resentment and disappointment, and that's just absolutely not great for anyone.
I don't necessarily have any rebuttal to what the author is saying, and I think the intentions are great, but I think it's also important to point out what reality is for people who are trying to build community and help: everyone slowly burns out doing it. It's like social work.
(food for thought: Github has made this problems orders of magnitude worse for organizations, because lowering the barrier to entry means now anyone who doesn't know where to start can open an issue and clog up a bug tracker in just a few seconds, and anyone who thinks they can write code can open a low-quality PR in just a few minutes, and this is more to do for the maintainers...)
1. When a person is asking you for help, try to imagine a situation where you have needed help and asked someone for it. Imagine your responses to them as someone's response to you. Empathy and compassion are really great tools to use when communicating.
2. Do not sign yourself up for something you don't want to do. If you don't have time to help or don't want to, simply say so. There is no reason to make yourself upset, and then lash out at a stranger, if you don't need to.
3. Be a teacher. Teachers don't give the answers, they help give an understanding of how to solve the problem.
4. Don't continue a conversation if you feel you are angry, upset or annoyed. Try to redirect your energy. Talk to a boss, co-worker, or friend about the situation and ask for their advice. Go for a walk. Listen to music. Write out the experience and your feelings to a private journal.
It's ok to be human and get upset every now and then. Heck, you might even take it out on someone. Apologise and move on, you don't have to become a buddhist and take the three breath vow - it's useless and unhealthy.
In general it's a valuable skill to have self control, but it doesn't work perfectly, so it's best to avoid having to exercise it all the time and pressuring oneself to always react "correctly" through self-guilt.
There should be an explicit three-way breakdown for this:
1. You're having trouble because of a bug, either yours or ours. If it's yours, the helpful thing is to help you fix it. If it's ours, obviously all projects should accept bug reports gracefully and work on them in some kind of reasonable fashion.
2. You've hit a deliberate design limitation, which isn't a bug as far as we're concerned, but we're willing to acknowledge it's annoying. This might turn into a feature request.
3. This is out-of-scope for our project. You picked the wrong tool. Getting us to change scope probably isn't going to be done using a bug report. That should be stated politely and without denigrating you or your problem.
What should not happen is what you describe: Developers fitting problems into a Procrustean bed and cutting off the bits which don't fit the pre-designed mold, and then claiming that this cut-down problem is all anyone would ever need to solve. It's sometimes inevitable that you have to simplify the solution by simplifying the problem, but never pretend that a solution thus simplified is complete.
But a lot of people don't want to explain themselves or their reasoning, or get defensive when you imply that the time they just sunk into the approach they were taking was wasted.
It's helpful to remember that the people who have been working on a project for years might (but not always!) have a better perspective than someone who picked it up this week. If we're asking you "why", it's because we really are trying to help.
We're especially interested in figuring out how we can avoid leading other people down the path you went down (whether it's better documentation, or something else that would help). Because for every one who comes to us trying to do something insane, there's probably a hundred who are doing insane things and not telling us.
Don't be their babysitter. There's nothing more infuriating than "I know how, but I'm not going to tell you for your own good."
I'm never bothered just because some particular OSS project sucks (after all, they are free). Rather, it's the fact that I've been suckered into using a sucky project – by network effects or false claims – that grinds my gears.
It is not necessary personal nor lack of good intention, it is that experience with answering questions teaches you that it is overall most effective to check whether the problem can be solved differently as it often can be done.
What worked well was unit testing and Haskell. What didn't work as well was inventing adhoc solutions instead of standard compiler techniques like DFA/CFG, and not writing more and better DSLs (in the form of monadic APIs) since they're cheap and convenient.
And never hear from them again, but later hit the shitty code you have just helped to producfe.
Well, you never know if they're skilled or unskilled hackers, but they're probably not very skilled. Or at the least not as skilled as I am. So no matter what you tell them, they're probably going to write shitty code I helped produce. Even if they have some skill, why take that risk?
So it's better to not bother even with the initial "Why do you want to do that?" gatekeeping and to just ignore questions entirely. They're just going to screw it up anyway.
Getting frustrated is an emotional response, you don't have to get frustrated.
Also, it is possible to communicate reality of programming and "right mindset" without loosing control in the process.
I've had people snap at me occasionally (not because I was asking for help, more because they were assholes in the course of doing their regular job) and the only thing that happens is I avoided them and kept a written record of the times they'd been unpleasant in case we ever needed to talk to HR.
That being said, I don't think it's an eventuality that people will always get frustrated with other people. I've never had anybody inspire "rage" in me in work situations. Other than some times I was working on tv sets and people were screaming.
Some people find it easy to stay calm and patient, some much harder. And some are able to recognize that "I am pissed now, better not respond immediately". Yet others are able to be polite and nice even while pissed - e.g. have above average good emotional control.