Changing the outer world

by Max Galkin

Coders’ work is all about the inner world: ideas, concepts, logic, abstractions. Mindfulness. It’s difficult not to be sucked into “the Zone” after you’ve learned programming: it feels magical how a snippet of text typed into a machine can cause it to do something cool. The inner world is neat and tidy, and you’ve practically built it from nothing, and you know how it works, and you can change it at the speed of thought. That’s why coders don’t like slow build systems, slow unit tests or slow third-party libraries — because they stand in the way of building and running The World!

“Some people look at the world through rose-colored glasses. Programmers like you and me tend to look at the world through code-colored glasses. We assume that the better we make the code, the more our clients and customers will like our software.” — Steve McConnell, Code Complete, 2nd ed.

Sometimes coders get so over-obsessed with the inner world, they forget that the outer world is still here. There is time and place for unconstrained art and pure abstract research, but I’m talking about us, mortals, working for a company, which exists for a purpose and makes a product to sell. Making a product, which someone wants to pay their money for, isn’t an easy task, and it involves a lot of efforts to understand, influence and change the outer world. And here’s the main “problem” with the outer world — it is very slow compared to the inner one. It has inertia. And it has other things to pay attention to.

So instead of learning the mechanisms of changing the outer world, coders start to ignore it. It’s too slow to work with. It “lags” too much behind the “cutting edge”. It’s not under control. That’s when coders lose touch. They start working on something that has no real value: refactoring without purpose, optimizing unused parts of the program, discussing the benefits of placing a curly bracket on a separate line. It’s like that tree that falls in the forest, when no one is around to hear.

Don’t lose touch. Think about the lifetime of your code. How is it supposed to unfold? How will your customers learn about the new feature? Who is going to demo it? Do they have all the documentation they need? Is there a clear shared understanding of the new feature, or are there several different views?

More can be done while the feature is shaping, than after it’s gone public. Fewer have to be involved and it’s easier to reach a consensus and coordinate your work. Others will help you, but make sure the forces are applied in the same direction. As author and designer, you have a great deal of influence on how the feature is documented, presented, explained, demoed. Do what’s in your power to help get the right message out and change the outer world. Next time you’re cutting down a tree, make sure there’s enough media coverage for the event and that everyone on your team agrees on which tree is supposed to fall.