Be flexible like bamboo

This is another lesson I learned from a comic book (man, that artist had deep meaningful ideas!). I actually wrote about the hero from that comic book in another article. Yes, it’s amazing what I can learn from comics and adapt them to programming. *smile*

Retreat at Bamboo Grove

Swinging his staff just short of his sparring partner’s head, Chen Min breathed a sigh of triumph. He had just picked up the skills in wielding the staff, his callused hands the result of training with the wooden stick. There’s the exhilaration of winning and being better than his other fellow students. And he hadn’t trained with them for very long.

Chen Min’s master sensed a growing arrogance, and asked another student to spar with Chen Min. That student was tall, large, and looked menacing enough without a staff as a weapon. The fight was short. Despite Chen Min’s agility, he was forced into defeat by the sheer strength and power of his opponent.

The master, watching Chen Min’s fallen expression, sent him to meditate in the Bamboo Grove.

Asian bamboo forest by Robert Churchill at iStockphoto
image by Robert Churchill

And that’s how Chen Min came to be on the porch of a small building surrounded by bamboo. A small pond was in front of the building. Soft breezes whispered across the water, creating small ripples and waves. Tree leaves rustled. Bamboo shoots swayed. Birds sang. And it’s been like that for 3 days.

Chen Min’s been meditating on why the master sent him here. And why he lost that fight. Just when he’s getting frustrated, the sky darkened. Clouds closed ranks, and the wind picked up speed. Lightning flashed and the first sheet of rain fell.

Chen Min was getting to his feet to retreat back into the building when he thought of his master. He was sent there to learn something. And he’s not giving up because of some drizzle. He’s still moderately sheltered from the storm, so he sat resolutely on the porch.

The winds howled and the rain pelted everything. Chen Min was startled by the ferocity of the storm, and was beginning to question his decision when there was a crash. He turned towards the direction of the crash and saw that a tree was felled. By the wind.

He was preparing to scramble back into the safety of the building when his eyes focused on the bamboo around the fallen tree. The bamboo bent under the strength of the wind. And bent. And bent. The wind abated for a while and the bamboo sprang back into place. The wind resumed blowing with renewed energy. And the bamboo continued to bend in the wind’s direction.

Chen Min realised that even though the tree was sturdier than bamboo, going head-on with the wind ultimately decided its fate. The bamboo on the other hand, gave way to the wind, and survived the wind’s onslaught.

The torrent of rain weakened. The wind lost heart. And the clouds opened up to let the sun in. Soon, the pond was still again, with an occasional ripple travelling across the surface. The storm had disappeared.

Chen Min stood up and stretched. He breathed in the fresh clear air and felt excited again. He felt this was the lesson, and he was ready to go back to his master again.

Handling ambiguity and unknown

Some people think putting off a decision makes them look weak and indecisive. That’s nonsense. Making a decision without enough consideration is worse than not making a decision. And if you’re the philosophical type, deciding to wait and think through is also a decision.

For simple and familiar programming tasks, you can certainly decide what to do and how to proceed immediately. For more complex tasks, it’s ok to give yourself time to think and plan. Give yourself permission to think and plan. You don’t have to react immediately.

Be flexible like the bamboo (not too much though). Give way to the task and requirements first, letting them wash over you, while you decide how best to tackle them. Once you get over the shock of what you need to do, spring back into balance and unleash your solution.

It comes down to how much you can handle ambiguity and the unknown. How long can you stand not knowing what to do? When you’re struggling to come up with answers, your brain starts throwing ideas at you. The first one might be good or it might not. Some might be useless. Some ideas have possibilities for further investigation.

Once you gather enough ideas, the fog of ambiguity lifts. You feel better able to tackle the tasks and requirements. This feeling of clarity is stronger than the feeling you get from reactionary solutions. Because you’ve thought through the situation and came up with a solution (possibly several), despite the fact that you knew very little about the problem at hand from the start.

Cannot endure programming hardship

Youngster climbing wall by ccaetano at iStockphoto

What kind of hardship am I talking about? Not knowing what to do next when faced with a programming task. This isn’t the hard part though. The hard part is enduring through this uncertainty, trying and testing concepts, and figuring out code design. It’s about enduring long enough for a solution to surface.

Some people just can’t endure hardship. The notables are the new programmers. At the Dream In Code forums, I see people posting threads asking for help in a particular area. The classic cases begin with the title as “I need to do such-and-such, and I need it urgently”. The body of the thread? “Thanks”.

It’s obvious the person never even gave a thought to the problem. The moment the problem became too hard for them, the moment the problem fell out of their known skills, they resort to asking someone else to do it for them. Only senior programmers and managers get to do that. It’s called delegation. You as a lowly programmer at the bottom of the food chain don’t get to do that.

Game guides

Back when I was younger, I was an enthusiastic gamer. Role playing games were my favourite, and in my opinion, produces more profound “stuck” moments. What are stuck moments? The point in the game where you were unable to proceed further, and you’ve exhausted every possible interaction you know.

Puzzle games offer the most direct stuck moments. You don’t solve the puzzle at this level, you don’t get to the next level. For action games, this could be unable to win a boss fight. The solution could be as easy as upgrading your weapons to deal massive amounts of damage to that stinking, butt-faced-ugly ogre. It could be as hard as executing a certain sequence of actions with a certain timing on your game controller with the agility of a ninja.

Role playing games involve story plots and character interaction. Is it because you didn’t talk to that small fellow crouching in the corner of that tavern? So you missed out an important clue, because that small fellow happens to be the prince in disguise and escaped from the palace (because his father’s forcing him to marry an ugly countess) through the sewers (it always seem to be sewers), and so happens to know the very route you need to sneak into the palace.

So some people, being unable to bear the uncomfortable “stuckness”, finds their solutions in game guides or the Game FAQs site (if someone’s kind enough to have written something). Instead of muddling through, and enjoy the game as the game creators designed, these people just trash through the problems.

I prefer to try and figure out the problem, for example in this situation in Chrono Trigger (it’s somewhere near the end). Buying a Japanese to English dictionary isn’t cheating. Looking up the solution in a game guide feels like one to me.

Ok, I do buy game guides, such as after I’ve completed the game, and want to find out other secrets or stuff I’ve not experienced in the game. Or I’m stuck for an unhealthy amount of time, and I gave my best shot at it. Plus I like looking at the pretty screenshots. *smile*

The search engine problem

Search engines are both a boon and a bane to programming. You can find the solution to your programming problem almost instantaneously, with the expectation that someone has already solved your problem, and you just need to find it. This is useful because you can learn a lot from someone’s experience.

It can also teach us to not think.

Without sufficient discipline on our part, we may form the habit of relying on other people to solve our problems. Of unconsciously depending on other people. And then original thinking goes out the window, and so does creative problem solving skills. And we’ll never get better at programming.

All we need is to use search engines and programming forums wisely.

My hypothesis is that when you suffer, you tend to remember the lesson better. The thing is, you can remember the lesson even if you’ve reached for the game guide, or asked for help in forums, or searched on the Internet. The question is when have you suffered enough. When have you muddled through the problem (and failing miserably), testing out code concepts (and failing miserably), flipped through reference books in search for a clue (and failing miserably), and suffered enough that you’ll remember the solution and lesson if ever offered to you?

My advice is, if you think you’ve suffered enough, go suffer a bit more. If you’re not in a hurry, suffer a day or two more. I’m not advocating masochism. It’s just that the more you suffer initially, the more you’re able to handle ambiguity, uncertainty, and the unknown, the better you become at programming. Your ability to endure hardship speeds up your learning curve, and I can guarantee you’ll suffer very much less in future.

With the speed of technological advances, businesses and thus programming problems are going to get harder and more complex. It’ll be extremely difficult to find standard solutions, because you’re given a unique problem to begin with.

Can you handle ambiguity, expect uncertainty and embrace the unknown? Can you endure programming hardships?