Trust

19 April 2018

I recently found the time to reflect on the factors that allows us to grow – both as software developers and as persons. The one factor I want to concentrate today is trust. First, why is trust important for growth? It is because growth only happens when you are out of your comfort zone, doing stuff that you’ve never done before. In such a situation, you will be dealing with uncertainty. Uncertainty without trust begets fear, and fear paralyzes.

In the sixties, Stanford Prof. W. Mischel created a series of experiments, the most famous of which is known as the Stanford Marshmallow experiment. The premise of the experiment is simple: Give a kid the choice of having one marshmallow now or two later (the actual test was a bit more complex, but this is the gist).

The researchers found that trust was the main differentiator for the outcome of the test. Which is not surprising: If you suspect that the alternative outcome of the experiment would be zero marshmallows, you’d take the one now, too.

Fast forward – you are now an adult. Perhaps you work for a company, or perhaps you have your own)? In any event, your livelyhood depends a lot on whether you can trust your environment – bosses, coworkers, clients, etc. Not only because of the ability to delay gratification. A different angle is that if you cannot depend on your environment, you’ll live in a constant state of worry, and thusly preoccupied can hardly do your best work. You won’t feel safe enough to move out of your comfort zone. You’ll stagnate.

Which is why “Managers” who belittle their subordinates are all the more infuriating. By creating uncertainty, they sabotage their subordinates, then make them personally responsible in case of failure.

The same goes for communities (say, of a programming language or operating system): All the gatekeeping, the “can’t stand the heat, get out of the kitchen” posturing, the toxicity will generate an environment of distrust, in which you “need a thick skin” to get anything done. The anti-SJW like to overlook this problem when decrying code-of-conducts. No wonder the Rust community is so productive.

Let’s make a simple thought experiment: Assume for the sake of the argument that skin thickness is a spectrum. Some people have very thick skin, others very thin, and most something in between. For each community (or company or other organization), the requirement of thick-skinnedness will also vary between princess bride and military-grade.

Let’s also be very generous to the anti-SJWs and assume that thick-skinnedness positively correlates with programming acumen, say, with a correlation coefficient of C=0.7 that I just pulled out of somewhere you won’t want to know. The actual correlation is very likely much lower, but bear with me here.

As I argued above, the ability to be productive is impeded with distrust. This will of course affect thick-skinned personalities less than thin-skinned (but the effect will still be measurable). So let’s work out a few examples:

For a very toxic project, we will have but a few thick-skinned contributors, who per our correlation assumption above will score good on programming acumen, but will still be somewhat impeded by distrusting their environment, doubly so for tasks out of their comfort zone. They will thus fail to unlock their full potential, so some may leave for more friendly projects. Others, never having experienced the benefits of a safe environment, will stay.

On the other hand, a friendly Code of Conduct-bearing project will attract a broader spectrum of people. There will still be thick- and thin-skinned folks (remember that thick skin doesn’t preclude seeking out friendliness), and as per our correlation assumption a mixture of great and mediocre programmers. The welcoming environment begets trust, so everyone will work at their peak productivity, often outside their comfort zone. This is where growth lies, so not only will they be more productive, they will become more productive.

Does this effect cancel out the relative mediocrity of the friendly project’s contributors? I argue that it does. First, the project is as likely as the toxic project above to attract top-notch contributors, so their contribution is not lost. Even better, their contribution is amplified by being able to trust the environment, and they can help get less experienced contributors get up to speed, thus avoiding any negative effects that less-than-excellent contributions might have.

So if you are a developer, seek out companies and projects you can trust (the former are unfortunately harder to find than the latter). Whenever you join a project, try your best to earn and keep your co-contributors’ trust. Grow and help others grow.

If you are a manager, your first and foremost task is to create a safe environment for your subordinates to trust. Never betray their trust, no matter the payoff or risk. I once almost lost a job because my direct supervisor wanted someone fired (how stupid is that?) because of some mistake and I wouldn’t let him at my subordinates. I still think I made the right call. (That supervisor found himself overruled when trying to fire me, and later found that no one would want to work with him).

If you are a project maintainer, make sure your project is open as in welcoming (borrowing a phrase from Manish Goregaokar’s great RustFest Kyiv keynote). Be proactive, tag your issues, mentor, etc. I think I’ve done a rather mediocre job of this with mutagen (I’m new to this, too), but I already have two competent co-maintainers and various contributors; the project is moving faster than I’d have imagined even when I’m not working on it.