Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is a great attitude because it moves the locus of control from outside of yourself ("I'm a helpless victim of everyone else") to inside ("this is my fault"), which is generally a more productive mindset since it puts you in control of your life. Obviously if you then translate that control into guilt, it breaks down badly, but I don't think that's what he's advocating.


You offered two possible attitudes: "nothing is my fault" and "everything is my fault", then stated that the second was a "generally more productive mindset". It doesn't matter, because the most productive mindset is this:

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.


Actually a pragmatic will see step 3 as unnecessary - you get to step 4 faster if you skip it, and assigning blame doesn't help solve the problem. After the problem is solved you have all the time in the world to think about the meta-things like assigning blames and congratulations.


I think that when speaking about small teams or individuals you are generally correct - it is generally faster to skip step 4, and always branch from step 3 to step 5. But like everything, there are edge cases: sometimes assigning blame actually does "help solve the problem". I would totally agree with your comment without question if you had written the first sentence like this:

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.


Wow, effective flowchart. I should try following this. Is this something you came up with?


I would be shocked if I was the first person to put this into a flowchart. There are some very reasonable people who claim that it is very rare that anyone ever really "comes up with" anything. One of these people put it into the old testament : Ecclesiastes 1:9 - "there is nothing new under the sun". That chapter is a good starting point in a rather detailed argument, and a fun debate.

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


I think this article has laid it out a bit easier for those that havent heard this concept before:

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.


You're right about how feeling guilty is counterproductive. Personally I tend to feel guilty all the time so I have to do the opposite -- sometimes it's not really my fault/it's all in the head.

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.


It is the same concern my sister brought up. I think the first step to making this work is to create an environment that does not treat a "fault" as a negative emotion but rather an opportunity to achieve progress via objectivity.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: