Can someone help me understand this segfault I'm getting? I don't understand it, and my debugger isn't providing any hints. I've narrowed the problem down to this part of my code...
It's 4 PM on a Wednesday. You're tired, having just got done with a 30-minute development meeting that took two hours. Your mind has been turning over the situation with a rather pesky bug in your code, and you've been wanting to try out a couple of possible solutions all afternoon.
Getting back to your desk, you tapped the bookmark for your favorite programming Q&A site rather out of habit, and found this question. As far as new posters go, this guy isn't half bad, actually. He just doesn't know what a segmentation fault is. Most people would probably just assassinate him for asking such a n00bish question. You can definitely help him, but you really don't want to be bothered right now.
It's a situation many of us are familiar with: we're in a position to help, but we really dread the effort or time commitment. Doesn't social decency dictate that you drop everything and help this person?
The answer might surprise you: not necessarily.
Your energy and attention are limited resources. We programmers like to call it "bandwidth": you can only do so much before the signal quality and connection speed drop.
Maybe I've got it worse than most, on account of my traumatic brain injury (2008). If I fundamentally don't want to do something, and hadn't planned on doing it anyway, no amount of effort will enable me to get it done. I've literally spent two hours staring at a blank document, trying and failing to muster up the willpower and focus to accomplish a task. It isn't a lack of self-control - if I've had a full day's notice, I can generally muscle through - it's just how my brain is wired now. I've had to learn to live with it.
That said, I also know I'm not alone in this. The average person may be able to do things they don't want to, on a moment's notice, and get something done, but there are still consequences. I've had to learn how to be far more jealous with my "bandwidth". I only have so much, and a lot of people are angling for a piece of it.
Overextending one's bandwidth is especially contraindicitive (I've always wanted to use that word in a sentence!) to teaching and mentoring, including answering questions online. This is because mentoring requires empathy, patience, time, and attention, and those are all in short supply when one's bandwidth is taken up.
As much as we want to help, "pushing through" isn't going to do anyone favors. At that point, it's like trying to use video chat on a 56Kbps modem; you're wasting time, and the other person can't understand you anyhow. In the end, both parties just wind up frustrated.
I believe there are three specific conditions that preempt being able to help others effectively. These conditions are best summarized in the acronym TPS.
The Lumburghs of the world may have to disagree, but your bandwidth is valuable.
Stupid things happen when we're tired. We try to pour coffee into travel mugs with their lids still on (true story). We write for-loops without semicolons, and then spend two weeks debugging (also a true story). We retype our password fifteen times, never spotting that we misspelled our own name in the login field (uhm...yeah, also true).
How much help do you think someone can be in this condition? The answer might be right in front of us, and instead we lead the confused asker down a completely irrelevant and unhelpful rabbit hole.
And yes, that's also a true story.
Besides the obvious, we tend to have shorter fuses when we're tired. We get impatient more easily, stick our foot in our mouths, and generally burn bridges without meaning to. The mental brakes we call our frontal lobe aren't at peak performance, meaning our emotional control and inhibition are impaired. (By that same token, it's not a good idea to try and help if you're under the influence of any substance which suppresses the frontal lobe.)
Don't let anyone fool you: teaching is one of the hardest endeavors on earth. It requires energy to express that much patience, empathy, and technical prowess. If you're not in condition to do it, the best thing you can do is leave it to someone else.
Effectively helping someone requires your undivided attention, even if it's just for the ten minutes they need you. You have to tune in to the other person to ascertain where their knowledge and understanding has gaps. In general, they don't know what they don't know; that's your job!
So, what happens if you have something else you want to get to?
You can't rush the learning process. If the other party doesn't grok the answer, they'll just be back for more help as soon as they encounter it again in a slightly different form. Our goal should always be to help the asker become more educated and independent, but if we're in a hurry, we can't do it.
This has been a hard one for me to learn, especially as it relates to the IRC rooms I occupy. I see a question I can answer, but I really really really don't want to be bothered right then. I've had to learn to do one of two things:
"I really can't stop and help right now, but I can at least point you in the direction of this documentation/resource/article which might help you, at least in part. If that doesn't solve it, hang in there - someone will be along shortly to assist you!"
Keep my mouth shut and move along.
You'd be surprised how often #1, politely stated (this is NOT an "RTD" or "LMGTFY"!) is helpful to the asker. It also sometimes attracts the attention of other coders who are equipped to help.
If I don't have the time to even do that much, I just say nothing. Technically, no one knows I'm actually there and/or equipped to answer, so if I don't say anything, no one will ever miss me.
I don't even know if I need to explain this one.
If you're already angry, frustrated, impatient, or stressed, guess who's going to feel it as soon as they ask a "stupid" question? Yup - the person you're helping!
When evaluating whether to help someone, you should imagine how you'll feel if the other party turns out to be very, very slow on the uptake. If you're already intensely unhappy, explaining a seemingly obvious concept seven different ways isn't going to make you feel any better.
Once you've established that you can't help, the next course of action is to walk away. Let someone else with more energy, patience, and tolerance answer the question.
However, we're not in a perfect world. Questions sometimes go unanswered. People can be rude. Explanations can be vague. It's important to remember, "not now" doesn't mean "never"!
If I have a small amount of bandwidth, one strategy I find particularly doable is to serve as an advocate for the asker. This requires far less attention and energy, and yet can be quite helpful!
Keep an eye on the question, coming back to it periodically until it's resolved.
If you know someone else who can answer the question, draw their attention to it.
Support constructive actions: upvote good questions, answers, and comments. Consider indicating consensus with helpful responses.
Assist in defensive actions: flag (and possibly confront) offensive content, downvote harmful answers.
If it's gone unanswered by the time you're up to the task of answering, answer it!
Even if you can't help directly, you can still take a few moments to increase the chances that the question will be constructively answered.
Remember, your time, attention, and energy are a limited resource. Being selective with how you use it isn't selfish; in fact, it's good stewardship! Having healthy boundaries ensures that you make the most of your bandwidth; you are maximizing the number of people can you effectively help.
Conversely, bad help is worse than no help. Wrong information, or even right information in a demotivational package, does far more harm than good. When it comes to adding content to the community, quality is far more important than quantity. Besides, if you burn yourself out, everyone loses.
In the end, sometimes the best help we can give is to just keep walking.