Programming is good for you. Even if you don't program for a living, programming stretches your mind in ways that are very beneficial.

 

Think about it. Even if you're just working on something boring like a calculator program, your brain has to simulate what the computer is going to do so that you can construct your plan correctly. When something goes wrong, you again simulate many different possibilities mentally to form a theory about the bug - and to correct it.

 

Simulation itself is a very interesting special case of programming. Building a sim is like a multidimensional form of writing a story. You're not writing one story; you're construction a story space in which an huge number of different stories can happen.

- story: keep track of who did what when

- sim: keep track of who can do what and what new possibilities will emerge if they do it

 

Learning to simulate complex systems in your head is great practice for a lot of jobs - like running non-profit organizations, effecting social change, or running a car dealership.

 

And simulation, as we know, is just a polite word for gaming.

Academia is noticing. Two interesting events this year:

- The MacArthur Foundation awarded a grant to create a game design high school in New York

- CMU created the Center for Computational Thinking, to extend systems / simulation thinking into other domains

 

Programming - the fourth R?

My favorite rule from software design is a classic: defer detail.

 

This applies at the user interface level, object model, or to good old structured programming.

 

Painters do this too: rough in large areas of color and shape, come back over sculpting and tuning, and finally make a pass with the tweezers and the magnifying glass, getting every hair in place.

 

When you're in a well-funded organization, there is a huge temptation to do all these passes simultaneously. Nobody wants to be the deer in the headlights when B** asks about some obscure detail. Saying 'we don't know yet' is out of style.

 

But it's often the right thing to say.

 

Designing interesting things is largely a process of managing ambiguity. This is a very different thing from making decisions, although they are interrelated.

 

The thing with software is that any non-trivial system involves a good deal of discovery. Humans are not particularly good at simulating large complex systems in their head. The result is simple, but I'll give it its own paragraph:

 

You will learn more about the problem space as the code progresses.

 

Waterfall people will say that all the discovery should happen on paper, in the design document.

 

Should, sure. But won't. It's much better to understand and tolerate the right kinds of ambiguity in the design process.

 

Solve the solveable things first. Implement those solutions. Check if more things have become solveable. Repeat.

 

In large teams, where you can afford to assign a person to every unsolved variable, you invariably wind up deciding things too soon. These decisions don't last, because they were not based on enough data.

 

So the mature project manager sees his job as not making sure that every decision has been made as early as possible, but making sure that the right decision are being made at the right time and in the right order.

 

Every good design is a gigantic formula with hundreds of variables. Part of the formula is in the design, and part of it is in the code. As such, some issues will not be resolved until enough code has been written. We all know this, yet we ignore this crucial knowledge every day, and we are mildly embarassed when we say "I don't know yet - we'll have to see it working."

 

When you try to decide undecideable things to early, you are simply inventing values for unsolved variables and inserting them into the formula. This leads to propagation of errors through the design, leading to failure or backtracking.

 

Oh Great Code

Give Me the Knowledge to Decide the Decideable

The Courage to Defer the Deferable

And the Wisdom to Know the Difference

 

:)