Why I'm Glad I Got Fired

This coincides with that great article on "How To Ask Questions The Smart Way" (http://www.catb.org/~esr/faqs/smart-questions.html), because it is often the case that the most effectively a question is asked, the more effectively the question is mitigated (and subsequently discussed).

Yes! Helping people save face is more useful than jockeying for nerd dominance. Other approaches to do what you suggest:

"I think I read an article that compared a few different password hashing strategies, I'm interested in your thoughts..." (and then follow up with a good comparison that makes the point)

"Have you compared X, Y and Z?" Tone is important with this one, but it can be the most straightforward.

"At the last place I worked, the paranoid guy insisted that we do X because he thought it was better -- it was just as easy to implement, is that something you'd be open to?"

When all else fails, you can follow up in private!

I think the key in any of these exchanges is to offer new information in a way that doesn't question the judgement of the other individual. Basically, assume that everyone is rational and differences in judgement are due to differences in information/experience. Then, when someone makes a judgement different from yours, you are merely giving them the information that lead to your decision -- but leaving them to make up their own mind. Most people are more ego-identified with their judgement than with the information they have.

Indeed. Another method that I've had success with is framing feedback in questions.

Bad: This variable name goes against our naming conventions. Please change it.

Good: Why did you decide to go against our naming conventions here? Did they hamper readability?

Not only does it keep the other person from becoming defensive, you might actually discover that they have valuable insight.

I learned that lesson the hard way... Getting fired because your boss can't stand to hear "I told you so" another time is pretty humbling.

Bear two things in mind:

1. Sometimes the truth hurts.

2. People love to shoot the messenger.

We have this idea that teamwork is this beautiful thing where people always get along and nobody is ever mad at each other. That's bullshit. To do the right thing, you have to piss people off sometimes.

I really suggest you read the "No Asshole Rule". It goes into details about who's an asshole and how not to be one. And it's very clear about the idea that just because you disagree with people doesn't make you an asshole. A few relevant points:

1. Focus on the argument and not the person.

2. Argue like you're right, listen like you're wrong. In other words, really try to make sure that you really understand their point and that they understand your point.

Even if you do those things, you're still going to make people angry. Remember, being stubborn and argumentative is only a vice if you're wrong or you're doing it for your own personal enrichment rather than the good of the team. If it really is a simple case of you being right and them being wrong, and yet they're still arguing with you, is it really you that has a problem?

When you say that "people are idiots", it seems to assume that there is a thing called "intelligence." Well, there is no "g", or general intelligence that anyone can pin down.

Let's take the simple view and say that people's actions and judgements are a product of the information they have gathered, the habits they have, their ability to analyze and combine that information, their ability to optimize within constraints and their ability to recognize and evaluate constraints.

If someone is clearly wrong, then they have some bad information or bad reasoning. Learning their bad conclusion, many people then go on and do a "well, i'm right and if they heard my reasoning then of course they would agree with me!" That can work within relationships that have a high degree of trust and rapport (not most relationships.) Outside of those relationships, it is too self-centered.

Changing someone's mind is like fixing a bug in a foreign code base. You don't just look at the erroneous output in order to debug, you also look at the source and the input. Similarly, to effectively communicate with someone who disagrees with you, you should seek to understand the information and reasoning that lead them in a different path.

Understanding where they went wrong (in addition to their erroneous conclusion) gives you a great level of preparedness. When you know where they went wrong, you can usually get them to change their own mind by asking them to teach you about how their model of the world is consistent even though you have seemingly contradictory information.

For instance: "oh, how is delivery guaranteed if there isn't a confirmation echo?"

Basically, you take the stance of being wrong, and "use" them to teach you about where you are wrong. If their answer seems to ignore information you have, you can ask "How does this relate to the stats they released last week?"

This "please teach me" questioning approach doesn't undermine their judgement or threaten their ego while giving you control of their thought process (or at least more insight into it, which translates to having more control ultimately.)

This takes a long time, but when you start learning to model other people's reasoning ( a skill unto itself) you will get better at asking the right question that guides them to the right conclusion without telling them what the right conclusion is.

Eh, I dunno how much my experience confirms this. I worked for a pretty spastic, rudderless company for awhile. I'd make my case for the right direction. I'd be shouted down.

Months later, exactly what I described would be pitched as a new direction, as though it was someone else's idea (and it definitely was their idea, for all practical purposes – I wasn't listened to, so they got there independently). This repeated itself a few times.

Now I work somewhere else and it's much better. I'm still not a dick. But maybe the lesson is that if you're continually in disagreement and no one is listening, you're in the wrong place.

It depends.... critical decisions you need to be right for. 99% of decisions, it's probably better to listen to that advice.

> Now., I am preparing interview questions with twists & logic implementations.

Of course, I know nothing about the candidate, but...

Something tells me that fixing your hiring is going to require a little bit more than gotchas and hotseat questions.

Why not hire based on body of work?

Average skills? There was an article recently - I think by Joel on Software - that everyone thinks they're hiring in the top 1%. I have to admit I'm kind of curious as to what you were looking for in your team when you hired the guy, I can't tell unless you elaborate more. In addition, I agree with danilocampos: the problem might be in your hiring process. I'm not sure that throwing out puzzles or whatever will help you reduce your number of false positives.

Yesterday, I fired one of my Middle Manager. His coworker reported to me that "He got average english skills".

"average" compared to what? your own team? that'd mean you've got people even below the person you fired. 'average' compared to the team leader's experiences? That's a bit... dangerous.

Frankly, an 'average skills' developer in a strong, supportive team can still be a great asset. They can do the work, but perhaps don't always know the best way to do something. However, they may be fine with being given direction. Many people I've worked with aren't good at taking directions from others - I'm not great at it myself in many situations. So the 'average skill' developer can be a blessing in many circumstances. But perhaps not on your team, which may say as much about your team dynamics as that developer.