blog|musings by johnfn. This is a github repository, generated from flat text files. It's pretty neat. And open source. Check it out!

You can't tell people what to do.
Written October 8, 2011.

Preface: Blah, this is crap. Maybe I will rewrite it somday...maybe.

In John's Introduction to Psychology class, the class gets assigned a chapter of reading every two days. The number of students who did all of the reading in John's class is vanishingly small, even though almost all of the students have tried to do some it. The professor caught wind of this, and to fix the problem he reminded the class at the beginning of lecture that the readings were mandatory and that the material would be on the test.

At Fred's current job, there is a problem: their old code is really sloppy. His work had a meeting, and one of the topics Fred's co-workers touched on was code quality. Their boss said that people should not be afraid of taking extra time to write code that was higher quality, and moved on.

These vignettes share a common theme. There is a group of people who need to improve their habits, and there's an authority figure that tries to help them fix their problem.

The problem is that in each example, the authority figure solves the problem in the wrong way. You can't tell people what to do. Most people believe that they are writing good code. Similarly, most college students really do want to do reading - they reason that they don't comes from somewhere else. Let's see how the authority should actually solve the problem, and then see what conclusions we can draw.

In the first case, students really want to do the reading, but they become disillusioned somewhere through reading the massive tome. The problem isn't that students don't care, it's that the material isn't being presented in the right way. The book is long, dry, and unengaging. (This is a question of willpower, but I'll get into that in another post.)

The crux of the issue though is that in an introductory Psychology class really doesn't need to bog down it's members with massive amounts of reading, because that's not really what Psychology is about. Psychology is about using experiments to better understand human behavior, and it's not true that students need to read a thousand pages and memorize hundreds of vocabulary words to gain a proper introduction. A better way would be to run actual practical experiments, get feedback, and see how Psychology is run in the world.

In the second case, none of Fred's co-workers really believe that they're writing bad code. They think that they're writing average code at worst. But we can empirically see that this is false since the overall quality of the code they've been working on is poor.

The reason that most of them write poor code is because coding is a rare profession where you can produce a lot more than you read. It's easy for me to believe that my own code is great quality since I've read more of my own code than anyone else's. But that means I have no basis for judging code quality at all, since I have bias.

The way to write better code is manifold and most of the theory is outside the scope of this post. But really, it boils down to ensuring that your code can be read by other people. One good way that the boss could work towards better code quality is to require code review for large chunks of code. In that way, each employee would gain an understanding for what makes good or bad code.

-----

In each of these circumstances, we've seen a group ostensibly choose not to do something that would benefit them. We've seen that incentivizing the activity fails to motivate people. In both cases, to get the outcome that we want, we have to find the root cause why people fail to do the activity. With Psychology, it's because the book is hard to read and people generally lack the willpower. With code quality, it's because people just don't know they're writing bad code.

Now that we've found the root cause, we can build infrastructure to make people stumble upon the desired result by doing something that they actually care about.

Other applications of this rule:

The customer is always right.

If you find yourself thinking that the customer is wrong, what that really means is that you've presented something to the customer in an incorrect way, and you should fix that.

You should follow me on twitter here.