I had an interesting conversation with a programmer yesterday about programming. Halfway through our conversation about how much complexity we have to handle when writing programmes, she said something that captivated me: “my friend is a very experimental programmer”. How fascinating!

In my short programming career so far (some might say it’s not even a career yet), I’ve come to know of two modes of programming. First and the more straightforward and common is the problem-solving mode. This is the state of mind that we get into when a specific problem has been handed to us or that we have identified for ourselves to solve. We then proceed to hold the problem in our mind’s hands, turn it around to examine it, get a feel for it, and devise a way or multiple ways to crack it. Most programmers are in this mode most of the time, because to write good, useful programmes, we need to literally consider every potential use case under which it will work, and if it breaks, fix it.

While it’s certainly an engaging state to be in, the problem solving mode is inherently restrictive. Programming is the act of solving one big problem by breaking it down into its tiniest constituents, but when we choose to enter a room, the others are forfeited. Once we set our mind to solving a specific big problem, it can be extremely difficult if not impossible to zoom out and be experimental.

The experimental programmer

What exactly does experimental mean in the context of programming? Broadly, it means being in a state of mind of imagining things, of making things up, and then trying them out to see if they yield any interesting outcomes.

The lady I met yesterday gave me an example of this in action. She described her friend, who wrote a Tetris programme, as someone who is very experimental. When I asked what she meant by that, she replied comfortably as if it was a natural thing, that her friend was someone who would write a whole bunch of different code just to see what happens each time, and later, combine them to see what kind of effects can be achieved.

I told her that that’s what most programmers do, but then I realised a crucial difference between her friend and most other programmers bent on problem solving on my own, before she has to explain. Her friend, the experimental programmer, was only letting the big problem he was trying to solve (how to create a two-player Tetris) sort of guide him in a very loose way. Being experimental, he mostly tried things for the value of discovery, and trusted that some of these will lead to a potentially better game design. There’s an important difference between the higher plane of experimentation and the lower, on-the-ground plane of thinking - dwelling on the higher plane can potentially prevent a programmer from coming up with a brilliant solution to the wrong problem. It is also a lot more fun.

Pacing around higher, experimental plane is the key to finding what Tim Ferriss likes to call “the lead domino” that will easily topple all others along the way. Better to find the right domino to kick than to go straight to kicking dominoes.

(image: Mr Cup)