How to avoid humiliating newcomers: A guide for advanced developers(opensource.com)
opensource.com
How to avoid humiliating newcomers: A guide for advanced developers
https://opensource.com/article/18/3/avoid-humiliating-newcomers
79 comments
I've had the same experience. There's a bright line separating people who want to learn from those who want to offload the hard work of learning onto someone else.
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.
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.
This is the point I was trying to make in my top-level comment, although you expressed it much more eloquently.
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.
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.
My solution to this problem is (1) avoid instant messaging at all costs, and (2) delay responding to any mail that is either (a) a contextless plea for handholding ("I have a problem, do you have some time?"), or (b) best solved by the asker taking some time to educate themselves.
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.
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.
+1 to not logging on to the company’s IM. Emailing somehow feels more ‘persistent’ so it’s unlikely that conversation like the one above would have happened in an email thread. Or, people have to come and talk to you in person; in which case they will probably think twice first and maybe solve the problem on their own in the process.
"Avoid instant messaging at all costs" is definitely good advice. I usually forget to take three breaths before answering there, but I usually remember before I answer an email. Plus, I have GMail's "undo send" feature enabled so I have a few more secrets to repent before my message cannot be untyped.
That person lacks some pretty basic development skills. You can roll your eyes or you can teach coding 101.
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.
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.
It's good to have one or two people in your project community that are willing to help people that don't have much experience at the type of problem-solving and methodical thought that fixing code requires. I am not the most knowledgeable person when it comes to any particular project, but I'm happy to help newbies get steady footing.
I had this problem as well. The same trivial shell scripting problems came up over and over.
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!
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!
Thank you for the great tool! I use it.
Cool! It's also written in Haskell. I always wanted to take a closer look at that language and this project seems just about the right size!
Just be aware that this was my first proglang project as well as my first Haskell project.
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.
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.
Yeah, I'm not sure if I'm going against the grain here, but
I think it's more than reasonable to say, "you really need to spend some time reading through <name of specific piece of documentation>". Even if they don't like it, and even if they end up not liking you, in many cases, that really is the best - and only - advice that will ever help.
Indeed, and the first example in the article is a little like this. "What is the ticket number" roughly translates to "go search the bug tracker for me, even though I could do that just as easily (or could do with the practice)". Maybe sarcasm wasn't warranted, but at best the answer is "I don't have that to hand, and couldn't find any quicker than you could".
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.
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.
> 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 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 have had plenty of dialogs like this with people who have no ability to look up something or, I often suspect, are too lazy. If this happens a more than a few times and it's clear they have no grasp of fundamentals ("I got this error "someVariable is not defined". What's it mean?") I send them a link with a tutorial or a book and tell them to read it.
Chapter 1: hello world
I'm willing to admit that maybe I'm not the best at social interaction. I think this article is on point though.
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.
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.
I mostly work on audio and video codec projects. You would not believe the number of people in this domain who come to us trying to do something insane that shouldn't be done in the first place. Of course, telling them that and dismissing them isn't helpful. But pretty much all you can do is ask, "Why are you trying to do that?" and work backwards. With luck you can set them back on the path towards success.
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.
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.
So then say "Do x, y, and z. But this is usually the wrong approach. Tell me what you're trying to do."
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."
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."
> So then say "Do x, y, and z. But this is usually the wrong approach. Tell me what you're trying to do."
And never hear from them again, but later hit the shitty code you have just helped to producfe.
And never hear from them again, but later hit the shitty code you have just helped to producfe.
If we continue a bit further down that path we come to:
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.
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.
> 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.
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.
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.
Well, on the flip side - I've had similar experiences to cosban's, and it usually goes like this: I'm neck-deep in a complicated scenario, and I'm stuck and can't figure out what to do next. I can ask for help, but it will take pages of explanation just to describe how I got where I am. Recognizing that everybody's (myself included) attention span only goes so far, I try to describe just the problem I've run into in as few words as possible without going through the whole epic story. Then somebody comes along and says "what you're doing doesn't make any sense, you shouldn't be doing that"...
Many questions come from beginners - and they are often trying to do the wrong thing. The developer who is answering you don't know who you are nor what you tried before, it makes sense for them to eliminate most common scenarios first before advising on something complicated.
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.
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.
> when I deal with open source […] there is always a retort by someone saying the help is free and that I should be grateful.
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.
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 would be helpful if there were levels of open source:
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.
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.
> 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.
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.
> 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.
It's absolutely true that you should be nice to people, but let me also issue a similar warning to newcomers not to ask questions in a way that inspires rage.
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.
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.
I guess I don't understand the scenario where you're being forced to answer this guys question. Why can't you come back to that question when you're not spending a week trying to move a button on a browser?
So you advocate for less communication?
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.
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.
My experience: If you come with a question and the steps you've already taken, the research you've already done, you will rarely if ever get a poor response from developers (or at least those who are decent human beings).
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).
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).
Agreed. I'm not saying don't ask questions. I said "not in a way that inspires rage." Just make sure you do your due diligence first. That's important.
[deleted]
New programmers usually don't have any exposition on what's an acceptable amount to ask and adding snark just deters them from sticking with it.
Excuse me if it comes off as snarky, but my main point is only to say that development is about three parts frustration and one part progress (and I'm being generous with the progress). You can't skip the frustration; it is what you are paid to do. Newcomers should be made aware of this, not to deter them, but to be transparent about what the job actually entails.
But if you constantly get frustrated with newcomers, and another guy is always helpful and calm, the newcomers will gravitate to that other guy. If those newcomers advance, who are they more likely to help out with things? If they go to other companies, who are they likely to give a reference to?
Getting frustrated is an emotional response, you don't have to get frustrated.
Getting frustrated is an emotional response, you don't have to get frustrated.
Eventually Mr. Always Helpful And Calm is going to get frustrated, too. It's about instilling the right mindset in newbies and not nurturing dependent work relationships. I like being Mr. Helpful, too, but I also like to see new devs persevere through all the frustration and bust through to the other side. Teach a man to fish, and all that.
This is simply not true. Not everybody looses patience and not everyone finds programming frustration. Not everyone ends up yelling at newcomer.
Also, it is possible to communicate reality of programming and "right mindset" without loosing control in the process.
Also, it is possible to communicate reality of programming and "right mindset" without loosing control in the process.
It is easy to stay calm if you do not care.
Yes, some level of detachment can help when advising strangers and caring too much may make people act in counterproductive ways. That holds true in other contexts too. But, that is not the only thing in play.
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.
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.
No, I mean I care. I just don't let people make me frustrated. With the exception of people who are manipulative or assholes, I don't make other people responsible for my feelings. I try not too. It's not healthy to be like "I'll be calm if you learn to act in ways to not me angry."
I guess I just don't have those situations where people keep coming to me and asking me for help over and over again, but even then if there are those people you can sit them down and explain to them to not do that without snapping at them.
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.
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.
There’s great wisdom here from an obviously enlightened crowd, but I will say, as a php dev for 9 years, permissive attitudes toward bad advice about programming did hold me back as an engineer.
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.
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.
I recently had a choice between being an ass or being nice to a guy asking a really basic question about my open source project[1]. At first I was going to tell him to read the docs and that I didnt have time but I decided to help the guy out.
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.
[1]: https://github.com/mkoryak/floatThead/issues/408
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.
[1]: https://github.com/mkoryak/floatThead/issues/408
[deleted]
I wonder if the underlying reason for this emotional response is guilt which goes hand-in-hand with altruism. In the case of the Santa and the homeless man, the Santa didn't want to give the man $5, but did so presumably out of guilt, then felt angry. In the case of the author getting angry about low-value questions, I wonder if that's because of a guilty feeling that they must answer. Personally, I can't really empathise with the author's anger, yet I'm arguably less generous than them; I don't feel much drive to spend my free time on Stack Overflow et al. answering stangers' questions.
The author is completely missing the point of his own feelings: his unconscious mind is telling him to stop wasting time answering questions and do something more useful.
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.
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.
I don't even care if this is arm chair psychology, from a literary standpoint this really ties the piece together. The Santa example doesn't make much sense otherwise.
With many things in life, it’s good to assume other people are not in the same situation as you. Just because you have all day to work on something doesn’t mean that the whole Internet has all day to help you.
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.?
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.?
It takes less time to ignore question then to be sarcastic, intentionally misleading or jerk about it.
Those Stack Overflow answers are awfully contrived. In my experience answers like that are quickly down-voted and deleted by the community. That being said, if you ask how to parse HTML with regular expressions, or post some SQL with injection vulnerabilities, they'll be closed as duplicates.
Yeah, I believe him when he says it happens, but I've never encountered hostility on SO, and I've asked some really stupid questions (and in each case, I really ought to have known better and done my homework, so in my case I would have deserved a bit of condescension).
It's fine to humiliate newcomers as long as you're fine making enemies. As a recent university grad, most people entering CS today are not geeks or nerds or whatever--they're more and more the high IQ people who just want to make money. These people have higher social skills and self-esteem then traditional geeks. The truth is that most programming done today is pretty easy and does not require deep technical skills, so these guys can really advance without problem anyway. Being an asshole means that you're 2-10 years out from people with better social skills than you and hate you advancing into management. At least that's how I read the current trends.
"most people entering CS today are not geeks or nerds or whatever--they're more and more the high IQ people who just want to make money. "
Hey, that's what we said in the 90's as well ;-) Well, tbh, we left out the 'high IQ' part.
Hey, that's what we said in the 90's as well ;-) Well, tbh, we left out the 'high IQ' part.
Well, it's even more true than ever now.
I think what's worse than lazy newcomers wanting someone to hold their hand through a problem, is newcomers who try and argue for a truly terrible idea, or worse yet, call into question an idea that is as old as time.
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."
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."
I've been the organization administrator for a library that participates in Google Summer of Code for many years now. Of the questions that we typically see and the requests we typically get, some are high-quality and constructive---and are people legitimately asking for help.
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...)
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...)
Slightly off topic. In big non IT corps I have worked with people whose title was developer but they couldn't do a thing on their own. I am not talking newcomer here, but people mid career. They basically mastered, I am helpless look and would rotate whom they ask for help. My turn would come every third week. Great people but just not interested in programming.
If I am a great guy but not interested in cooking maybe I should not work in a kitchen?
Things I've found to help situations like this:
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.
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.
This is endemic with SO. Particularly, I am not happy with the Python community of SO either. Couple of months back, my wife who is a student and very new to Python (and had to quickly prototype an intermediate part of a Genome Assembler as a PoC, before she could recreate it in C++ and MPI) asked some question in SO, and met with sarcastic comments by an experienced user. She didn't have time to read up a book on Python, since she had a time crunch to finish the work within a couple of days. So the day she posted the question, she told me that she fears snide comments, and that's exactly what happened. If you are in a position to criticize someone's sarcastic comments, then please take the time in doing so.
Not only on the web but it’s an issue in workplaces as well. FPS style humiliation, and it’s not about knowing the basics but when learning the project or questioning some quirks or weird architectural decisions (so easy to trigger someone right here). Listen, the world is small, professional environment is not an online game, and your experience in a particular project can be surprisingly worthless during the next job search.
What a pretentious piece of writing, I can't stand this kind of goody two-shoes attitude.
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.
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.
What is unhealthy about deciding to pause before responding harshly to someone?
That's not what's being discussed... the author gets themselves into situations that can easily turn irritating, like hanging out on StackOverflow or answering noob questions on chat. The solution is for them to take time out from that, not become a zen monk.
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.
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.
Totally agree, I actually thought his response was pretty funny. If people can't take a joke like that they need to lighten up/harden up a bit.
Your right that you shouldn't be fixated on past mistakes, but remember you can't take back what comes out of your mouth.
I absolutely adore the ambiguity in this HN title. Perfectly crafted. Well done.
[deleted]
How about we start with condescending blog titles?
sigh
I really, really try to be nice, but there's a limit on how many situations like this I can handle before losing my sanity.