30 April, 2008 | Written by Vincent 2 Comments

Real money, RPG money

I’m careful with the way I use my money. Once in a while, I splurge a little, maybe a book as a reward. I’m moderately thrifty and have a balanced lifestyle.

All this goes out the window when I play a role playing game.

In a computer/console RPG, I take unimaginably stupid risks. If there’s a piece of armour priced at 2000G (gold pieces), and I had 1950G, I’d go out there and kill a few more monsters to gain the remaining 50G. Even if all my magic were depleted. Even if my healing potions were low on supply. Even if my characters were practically dying. If there’s a better than 50% chance I’ll survive another battle, I’d do it.

If a night’s stay at an inn costs 150G, and my characters are like 70% healthy, I’d skip the inn. Even if I hadn’t rested for like 4 virtual days.

Sometimes, I’d go into an item store and buy 20 herbs (replenish stock), 30 antidotes (next boss specialises in poison attacks), 20 ice crystals (next area monsters vulnerable to cold) and a dozen odds and ends. Then I left the store with zero money. Every single gold piece I had was used up. No savings, no bank, no backup.

Then I’d realise my characters weren’t fully rested. It would be a waste of herbs and potions to restore them to full health. Better to rest at an inn. Oh right, no money. Off to slaughter a few more monsters and earn just enough gold to rest at the inn. Then off to the next adventure.

I would hoard money obsessively to buy some high priced weapon while in virtual mortal danger. I would also spend everything to buy and restock items, to the point of ignoring virtual personal safety. I just don’t handle money in RPGs the way I do in the real world.

There’s no real point I’m trying to make. Just wanted to write about this observation…

28 April, 2008 | Written by Vincent Leave a Comment

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.

25 April, 2008 | Written by Vincent 5 Comments

How to prioritise your tasks

I follow just one simple rule. This rule comes from the culmination of 3 job changes, more than 5 years of experience in programming, administration, technical assistance and interactions with users and peers. And it goes something like this:

Given similar levels of urgency, first do that task which has the most number of people irritating you.

Feel free to substitute “irritating” with “bothering”, “unhappy with” or “angry with”.

What a young king taught me

Garion was a nice young man, raised as a peasant boy in a farm. He’s polite and modest, had a good sense of what’s right and had great friends. He’s also destined to be the king of an island, protected by powerful friends, and guardian of a precious orb. (find out more from the Belgariad series by David Eddings).

I’m going to skip the part about how he grew from just a simple peasant boy to overlord of the western seas. Now, as a king, he knew it would be very hard to get feedback from his people. Just his title alone scares the living daylights out of the lords and ladies, let alone his people.

So what he did was to have a confidant who’s among his people. I wouldn’t call the confidant a spy, and even if you think it is, I’d advise you not to say it to Garion’s face. He could do a lot of damage even if he’s only mildly irritated.

So, this confidant was a glass blower in town. Every once in a while, Garion would make some excuse about needing to buy some glass ware and go meet this glass blower. Then he’d talk with the glass blower and get some idea of what his people were doing or saying. This way, he’d be able to improve the situation. Coming from a peasant background, Garion really didn’t know how to run a kingdom, so he desperately needed feedback on how his laws and actions affected the common folks.

So, there’s this one time where the glass blower mentioned about a particular tax law which made taxes too high for the commoners and too low for the lords. The people were complaining, but no one dared say anything, even though Garion had repeatedly shown his kindness and fairness.

Garion told the glass blower he’d change the tax law in favour of the commoners immediately. The glass blower was surprised, so he asked his king what’s the reasoning behind it.

“It’s actually based on a selfish motivation.” said Garion. “How many people are affected by the high taxes?”

“About five hundred or so.” replied the glass blower.

“Well then, I’d rather have 5 people hating me than 500.”

How does this apply to me?

Let me give you an example. Suppose you have on your task list, in the following order:

  • Development work
  • An email query that you know is going to take an indefinite but probably long time to check
  • A simple data patching that’s an update statement which takes less than half an hour, including verification

Even though development work came first, you have to put it aside because the other 2 are more urgent. Now, you are already half way through the email query, finally understanding what the user was trying to ask in the first place. Then the data patching request comes in.

This is how I see it. Either way, you’re going to have the user who sent the email query, and the user requesting the data patch waiting for you. There are 2 people “unhappy with” you already. Even though the email query came first, and is slightly more urgent and important than the other one, you should complete the data patching first.

Your goal is to have as few people waiting for you to complete whatever they’re asking for. Can you imagine having 10 people waiting for you? You could have completed 9 very fast requests and have only 1 breathing down your neck. Whatever that long task is, that user is going to wait a long time anyway.

The side effect is that you’re perceived as super efficient by 9 people. 10, if that last user understands the length of time needed for his request. Everyone is happy, and at the end of the day, you still completed 10 requests. The trick is in gauging the urgency level.

Anything involving customers (and thus revenue and thus bottom lines) are top priority. Your users (other than direct customers) are next. Users such as sales personnel, customer support officers, marketing personnel and managers.

And you know what? Development takes the last priority. I’m like an all-in-one, so I handle a lot. Luckily, I’ve taken these constant opportunities-to-learn into my project estimations.

Getting burnt out from an overwhelming number of tasks is not fun. People breathing down your neck is not fun. So how do you prioritise your tasks?

Next Page →