step 1 - Here is a problem. [goto 2]
step 2 - Do we need to assign blame at this moment? If yes [goto 3]. If no [goto 4]
step 3 - Assign blame [goto 4]
step 4 - Is this a problem I should be involved in solving? If yes [goto 5]. If no [goto 6]
step 5 - Help solve problem [goto 6]
step 6 - Problem does not exist. Do we need to assign blame at this moment? Go right ahead.
All of this should go without saying, since this is the essence of the engineering and hacker ethos, and we can therefore make the assumption that at a website called "Hacker News", everyone understands this intuitively. But if you look downthread, you will see that some people legitimately don't think like problem solvers yet.
Example: George Orwell's "5 Rules For Effective Writers". Did Orwell "come up with this" or was there "inspiration" from Hemingway's 5 tips for writers?
1. Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
2. Never use a long word where a short one will do.
3. If it is possible to cut a word out, always cut it out.
4. Never use the passive where you can use the active.
5. Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
6. Break any of these rules sooner than saying anything outright barbarous.
Another example, is Apple a design company? http://i.imgur.com/whMW7.jpg I bet you that Braun designers would happily take the credit for those very "inspired" Apple products. But I would also bet that the Braun people had some "inspiration" of their own, perhaps from a certain group of Greek folks... http://en.wikipedia.org/wiki/Golden_ratio
FTFY>>>Step 3(assign blame) is unnecessary if and only if assigning blame doesn't help solve the problem. A pragmatic will realize this, and skip step 3 when it is unnecessary to assign blame at that point in the process- you get to the solution on step 5 faster.
Upon careful reading of your comment, I imagine that this is what you meant, but some people will read your version and imagine that you are saying that "assigning blame generally doesn't help solve the problem". It's the problem of [logical AND &&] vs the English construction [ , and ] which can mean the start of a new semi-related clause. Note that I did try to hint at this in my description of (step 2) - Do we need to assign blame "at this moment"?
Completely agree with your second sentence.
One specific edge case for small teams or for individuals - the process of assigning blame can reveal toxic team members (one of which could be you). Getting rid of a bad team member has the potential to speed things up radically.
In large organizations, assigning blame can often be done in parallel with fixing the problem. I would imagine that the benefit of the fix would generally outweigh the benefit of the blame. However there can be good reasons for management to demand that you offer up the scapegoat(as opposed to a sacrificial lamb) before your team gets permission to fix a problem. One of them is the small team edge case that I mentioned.
http://www.fastcompany.com/1840496/how-your-locus-control-im...
The title of the original article is link-baity and it worked; but the whole idea of locus-of-control is that it give people a perception that they have control over their lives and it has them take actions that are consistent with that, which generally gives better outcomes.
Like Buddhism, it's about balance. Too much of focusing on blaming either side is neither constructive and may not reflect actual reality which is what we're trying to understand. I find the trick to deal with this is to recognise that we can sometimes feel guilty/blame someone and get so engrossed into exploring the scenario we forget the big picture.