Intensive Coaching

I'm going through an intensive coaching experience. The idea is that I spend a full ten weeks with a single team.

I'm a little surprised with the outcome. I knew there would be an impact but the team is progressing a lot faster than I, for one, anticipated.

I don't have enough data to attribute that to the intensive experience, yet. It's also a really engaged and interested team and I suspect that has a lot to do with the progress being made.

I think people have a tendency to be a little superstitious in assigning reasons for success or failure. I don't want to contribute to that but, it's easy to see why someone who went through an experience like this one might be convinced it's the only way to coach software developers.

Connectivity

Connecting with people is one of the hardest parts of helping people change how they do things. At least, it is for me.

I've identified three major reasons why you might be having trouble making a connection.

• They don't understand something.
• They fear something.
• They don't feel like they have power over something.

I'm sure there are more but these easily cover the majority of the resistance I meet. All three cases demand, for me, the same approach. Try to turn it around and make yourself the person who can help the person you are trying to help the way that they perceive help.

If they don't understand something, explore it with them. If they are afraid of something, face it with them. If they feel powerless over something, help them reconcile that feeling either by creating power or banishing responsibility.

Helping someone with the problem that they can see makes you their friend. Do it a few times and some of them will start to come to you to help them find the problems you can't see.

But Will it Work Here?

It happens with alarming regularity. Everywhere I go; almost every team I meet; with the majority of the people whom I have mentored, there is always this question: "Yeah...but will it work here?"

The implication is that this place is special. This place has a different set of circumstances which exempt it from needing to learn TDD, design patterns or refactoring.

Yet these techniques are established. They are proven beyond any reasonable doubt and on a broad scale. There might be something better coming in the future but it's not a resurgence of the old ways.

Those three disciplines work, largely, because they aren't sensitive to where they work. There's nothing special about any environment.

Your circumstances aren't special.

Test-driven development, design patterns, and refactoring are what software development is. If they don't work in your environment, it's because software development doesn't work in your environment.

Cultural Momentum

I have a friend who is going through The Fountainhead. That's as of the time of this writing. He reads fast, so it probably won't be true when this post is published.

Without debating the merits of this book, there's a particular part that he was discussing with me, recently, which I think is relevant to everything.

Near the beginning, the main character (Howard Roark) is chastised by the dean of his college for not doing what has always been done. This is done in a very ham-fisted way where the dean basically explicitly states that we have to keep doing what our ancestors did.

My friend's objection to it was the fact that the conversation seemed hyperbolic (my words, not his), not to the point being made. Yet, the problem is actually a very common one.

Though it's typically presented more subtly, culture does exhibit inertial properties. This is as true for corporate cultures as it is for national ones.

What does that mean for us?

It means we have to slow down. A lot.

It's easy to know where we want a culture to go. It's possible to personally adopt skills, disciplines, or even a new mindset pretty quickly.

What's hard is to alter the culture of a large body of people faster than that population will accept.

If you chisel away at a culture, you can make a cumulative difference. If you try to be an iconoclast, you're more likely to be ousted or ignored than you are to make a real impact.

The Final Advice for Suffering Fools

I've been writing a little bit about various ways of dealing with people whom you consider to be too foolish to be able to succeed.

I have one last piece of advice on the subject, for now. I guess it's not really like a piece of advice. It's more like a flag in the distance. If you're not there, now, you probably won't be there, tomorrow. You can work toward this goal, if you want to, though.

Like all problems, this one is best solved at the root. Just make it so there are no fools, then you won't have to wrestle with yourself to suffer them.

How do you do that?

I've found the most effective technique is to simply remove "foolishness" from my model of the world. So, for me, there are no fools because there is basically no such thing as a fool.

Maybe it's a bit revisionist, but it works for me.

Another Trick for Suffering Fools

Previously, I wrote about a trick you can use to deal a little more effectively with someone you consider to be foolish.

I have another one for you: Consider what else could be the problem.

A Trick for Suffering Fools

As I wrote, previously, I don't think there's a lot of reason to believe humans are extremely intelligent. We're smarter than everything around us but that doesn't mean we're a lot smarter.

Maybe you're smarter than everyone around you. Maybe you can usually see the solution to someone else's problem. Maybe they don't listen to you or, worse, they listen but have the audacity to fail when attempting to take your advice.

If this is difficult for you, I've got a...ahem...piece of advice.

The Readability Lament and How to Handle It

This week, I've written a lot about readability. It isn't really a property of code. It's actually a quality of an observer's experience when working with code. Yet it's very, very important.

The combination of potency and interpretive license provides a potential exploit for developers resisting the adoption of technical excellence. Just say "that's not readable".

Code Quality Deficiencies Demand Root Cause Analysis

Looking for code quality problems and then fixing them is really just another form of trying to test quality into a product at the end of the development process.

This simply doesn't work. Problems have root causes and. So long, as those causes are allowed to persist, new problems will continue to arise.

How Do You Know People Are Smart?

How do you know that someone is really that intelligent?

I mean, maybe you know that they are smarter than you or you are smarter than they are. That's a relative assessment.

How do you know how smart someone is in the absolute sense?