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…

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.

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?

Are you conscientious

My friend is thorough in his analysis and coding. Once, he remarked that he thought about solving a work problem while driving home. While bathing. Just before closing his eyes to sleep.

You could call him obsessive, a workaholic. Actually he isn’t. He arrives on time and leaves maybe half an hour after the official work hours.

He did it beyond the requirements of a paycheck. He cared about the work. Yet he’s not passionate about programming. At least not as much as I am anyway.

He did it because he’s conscientious. Because he’s responsible. Because he cares about the people he works with. And so when the situation requires it, he puts in a little extra effort to make his program better, more robust.

Are you conscientious in your work? Do you choose the right way, or the easy way?

Lines of programming experience

I’ve written and sent resumes before. Looking at the job requirements listed by some of the companies, I will never meet many of the job descriptions. 5 years of C and C++ programming experience? 3 years of programming experience, involved in at least 2 complete development life cycles?

I daresay I’ve done more in a year than some ideal candidate of theirs with 10 years of experience. Alright, 7 years. Ok, maybe 5 years of experience.

The point is, programming is different from other jobs. The years of experience don’t count in the traditional sense. A manager of 5 years of experience is highly likely to be better than one with 1 year of experience. This doesn’t scale with programming. A veteran programmer with 5 years of experience can very well be worse off than a brilliant programmer who’s been coding only a couple of months.

It’s not the years of programming experience that count. It’s the number of lines of code you write that never see the light of day. And I’m not talking about superfluous stuff like

int
i
=
2
*
7
;

I mean, you might be paid by the number of lines of code you write, but seriously…

It’s that chunk of code you wrote to test out a concept in a for loop. It’s that printf statement you wrote to check how the output would look like. And those lines of code never make it to your final product. They never get migrated to a production environment. They were probably written to help you, and only you, to automate some task on a temporary basis (generating SQL insert statements come to mind).

I practised till my fingers bled

I was 13, 14 years old. I was in my school’s Chinese orchestra, and I played the zhong ruan. It’s like a guitar, just with 4 strings instead of 6.

I had a lot to learn then. I don’t have a music background, and I wasn’t familiar with Chinese orchestral music or instruments. Luckily, the musical scores were in numbers instead of what’s affectionately known as the “tadpole script”. So a 1 represents “doh”, 2 represents “re” and so on. A dot above the 1 means it’s a “doh” on the next octave. I just find numeric scores easier to read. *smile*

Anyway, one of the hard parts was learning the finger placement. The left hand was to hold down the strings on certain ridges on the instrument, while the right hand held the pick to strum the strings. The strings were taut and thin, and the string with the normal octave was the third one (and the second thinnest).

So after practising for a few weeks, my fingertips on the left hand started to hurt. I could see grooves forming, and there were red patches around them. It’s especially bad for my index and third fingers, since they pressed down the most frequently. And then it happened. The strings cut into my third finger.

I just put on a plaster and continued practising. I couldn’t quite feel the string anymore, which made playing harder. It depends on the sense of touch, since I don’t know if I’m pressing down hard enough. But I practised strumming instead. Did you know using the pick to strum a string back and forth in a consistent manner is very hard?

The point of telling you this entire experience was how determined I was to learn how to play zhong ruan. I knew after a while, the skin on my fingers would harden. I just needed to be patient. I was encouraged to borrow the instrument back home to practise, and I did. I remember lugging that huge instrument case around, and taking a taxi back home. I was just a young boy then, a bit on the thin side, and that case was very large and heavy.

Then I started to appreciate the music. I can follow the 4 beat pattern. After a while, sometimes when I was walking, I would feel the music in my mind, and I would walk to the beat.
1, 2, 3, 4, 1, 2, 3, 4
Right leg, forward, left leg, forward, right leg, forward, left leg, forward

I was living and breathing the music. Then I looked at the scores for the other instruments. I learned how they blended into the overall music, how they fit in. I could visualise in my mind that at a particular point, the cello would come in, graceful and mellow. Then the stringed instruments (that includes me) would bring up the main tune. Then the flutes would fly to the high notes. It’s just beautiful.

Learning how the entire orchestra works made me a better player.

The blood, sweat and tears

Did you know footballers (or soccer players) do weights training? You’d think they’d concentrate on foot work and stuff. It’s about balance. The entire body needs to be trained. Abdominal muscles to stop an airborne ball passed to them. A strong upper torso to maintain balance while the right leg strikes the ball. And I’m starting to get out of my league here… someone more qualified please cite me a scientific reference…

I watched a commercial featuring athletes. A tennis player (Maria Sharapova?) was doing balancing training and “crab dances”. You know, the moving from side to side part. What do you mean you didn’t know tennis players move from side to side a lot? Tsk, tsk… And there’s a Chinese hurdler, lifting his right leg just over a hurdle, then moving his leg back. He’s practising how much to jump and lift, to minimise the energy used for jumping, and funnel it back to running.

Sure, these athletes practise their sport. They also supplement that with complementary training, training that involves other muscle groups and skills. Because having a balanced body, a more responsive body makes them better at their core sport.

So what’s the real experience?

It’s the things you do behind the scenes. So what if you’ve got 5 years of programming experience? A dunce could maintain applications for 5 years and never create anything new or exciting or beneficial.

So start learning about the business surrounding your applications. Then you’ll be able to spot edge conditions that business people never saw. Try out code concepts in small chunks or applications. Then you’ll understand more of what your programming language can do. I mean, changing an integer to a string, then parsing it back into an integer so you can assign it to an integer variable is just stupid.

I practised for months before a music competition or school performance. Athletes practised for months for a sporting event. And all that practice, never really gets noticed.

Using years of programming experience as a benchmark doesn’t work anymore. Technology moves fast. You could get hired and sit tight without contributing anything substantial. 5 years go by and boom, you’ve got 5 years of experience.

Or you could practise the things that speed up your learning curve, that prepare you for a balanced programming skill set, that allow you to face a fast-moving world with uncertain problems. And create something that’s actually useful to the world. So how many lines of programming experience do you have?

stackoverflow.com

Based on what I can gather from the founders, Jeff Atwood and Joel Spolsky, stackoverflow.com is going to be a programming community, functioning primarily as a question and answer site. The solutions will be sifted organically by the members (through some kind of voting mechanism?), until the correct answers float to the top. The idea is for correct stuff to be more prominent than incorrect (or out of date) stuff.

Why should prominence matter? So that Google and other search engines rank the correct stuff better. Which makes the correct stuff more prominent.

I just listened to their first podcast, and the driving force behind this was how programmers are ditching the paperbacks and hardcovers for the Internet searches and forums. I haven’t thought much of this, since my department is a little, uh, tight around budgets. Training courses and reference books cost money, so I turned to the Internet to help me solve problems.

My problem then became “How should I phrase my search terms so the correct solution will come up on say, the first 5 search result pages?”. Yes I’m patient. I can go 5 pages, 10 if I’m really desperate.

The good point of the Internet is that it remembers everything. The bad point of the Internet is that it remembers everything. Every good article, every bad article. Every correct solution, every wrong solution. And search engines have a hard time telling them apart.

Forum pages come up a lot, so I’ve done some research on programming forums and communities. Here’s a few that I found.

Code Project was the original site I joined. I found their articles useful when I first started. I don’t frequent the site so much now. Now, I Google. *smile*

I will scan through the search results, and open any interesting, potential answer link in a new browser tab, and continue scanning. And I realised something. I hate it when I open up the page, and find only the question, or a discussion on the question without really solving the problem.

I think I gained a new level of hateness when I opened up a page and the discussion and solution was obscured. The site in question (there’s something with an “exchange” in it), used to have Javascript and nifty CSS to blur out the post thread content. Now, the content is replaced by text telling you to sign up before you can view the answer.

I’m searching for an answer, and I’m a little pressed for time, and I don’t know your site. You want me to jump through hoops, think up a login name and password, sign up, before I find that the answer is not what I want? No thanks. The Internet is a big place. There’s got to be someone out there who has the answer. Now, I skip any search result with that site’s address in it.

That said, I found Dream In Code. Somehow, it gives off a “homey” feeling to me. I wrote more about it here. I also realised that the future of better programming lies in the younger generation, and Dream In Code’s high proportion of students fits this perfectly. That’s why I’m there. My handle is “orcasquall”.

Oh, and thanks to Chris (Dream In Code’s founder) for publishing the article I submitted to his forum newsletter! You can read about it here.

Anyway, I’m still unsure how stackoverflow will be like. So go over to the site and listen to the podcast first. Here’s the site again:
http://stackoverflow.com/

Telescopic and infrared vision

When you debug code, you shift between two modes, telescopic and infrared. When you’re pinpointing errors, you’re in telescopic mode. When you have no idea where’s the error, only that there’s an error, you’re in infrared mode.

Telescopic vision

With the advancement of compilers, syntax errors are becoming easier to spot. Chasing down that elusive semicolon is a thing of the past. I learnt to code in a text editor. On a Unix machine using the vi editor no less. I didn’t get syntax errors until I compiled my program. I didn’t get segmentation faults until I ran my program and found out I hadn’t malloced enough memory for my matrices.

So I was very careful with syntax. Every = sign and == signs. Every ;. Every * for pointers. With monochromatic editors, no squiggly lines and no Intellisense, I developed hawk-like abilities to spot syntax errors before the compiler does. With practice, this extended to even logic errors. The compiler cannot tell you if

int i = 4 + 5;

is correct or this

int i = 4 * 5;

With modern compilers, simple syntax errors are caught easily. Now there’s a different problem, embedded code. Specifically, SQL statements in a string variable. For example, the compiler can’t tell you this is an error

comm.CommandText = "updte WrongTable sett columdesc = you rock' wear user_id='beerkeg'";

You’ll only know something failed when you run the code. Unless you have telescopic debugging skills of course.

Infrared vision

Do you know someone who can “feel” a spelling mistake a mile away? Do you know someone who can read paragraphs and paragraphs of text, and then singling out phrases such as “please bare with me”, “just loose that pen” or “that man is stationery”?

They have infrared vision. They see a blurry image and something in the text just doesn’t seem right. Their “spider sense” tingled and they just stop at that error.

Expert programmers do the same thing. Since syntax errors are highly unlikely (because of modern compilers), that leaves subtle coding quirks or logic errors. Somehow, something about this chunk of code doesn’t feel right…

int i=0,sum=0;
for(i=1;i<=10;++i);
sum+=i;

The inexperienced programmer would be looking at sum += i; and wondering why sum doesn't contain the sum of the first ten integers. The expert programmer would be wondering about the use of adequate whitespace, why the for loop doesn't use curly brackets, and why the for loop ends with a semicolon... hey, that's the error!

Getting super vision

The thing about telescopic mode is that you get tunnel vision in the extreme case. You blithely ignore large parts of code and focus on a line of code which may not be the source of the error. And you spent half a day wondering why that line of code isn't working. It is. It's the other parts of code that gave the wrong context, and so as a whole, that chunk of code doesn't work.

The thing about infrared mode is that everything's blurry. To make sense of things, you need to have some experience in recognising recognisable stuff. Such as automatically checking the structure of the for loop for the 3 parts (initialiser, terminator and incrementor). The operative word is "automatically". It doesn't do you good wearing infrared goggles in the jungle and spend 5 minutes figuring out that, yes, that bulbous reddish-orangish mass is a human (and not too friendly at that). So it's no good stopping every so often while scanning code.

To get better at debugging, you need to learn to combine both. Use the infrared mode to scan lines of code. Stop briefly when you feel something's not right. Switch to telescopic mode to find out why you don't feel right. If you find any error, go ahead and correct it. If not, switch back to infrared mode and continue scanning.

This gives you the advantages of quick scanning and the tight focus of pinpointing.

Of course, this is terrible if you're just starting out with zero experience, and scanning means you'll miss obvious errors because you're not trained to recognise them. Good news is, the more code you write and debug, the faster and more automatically you can scan, and the more obvious errors look to you. With practice, you'll also recognise good code faster too. This is important because much of what you read will be good code (or at least it'd better be...), and you need to quickly decide that it is good code and continue scanning.

So do you have both telescopic and infrared vision?

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?

Featured demo – Concentrate

I’m starting a series featuring demos. If you don’t know what demos are, bring yourself up to speed with 5 of them.

Demos are multimedia applications combining programming, art, and music. There might be a storyline, an artistic direction, a showcase of physics concepts or even a statement by the creators. Plus they’re just fun to watch.

2 facts I’ve gleamed from watching demos. Sometimes, if there are text in the demo, and you want to read them, be prepared to watch the demo over and over again. Because the text will generally appear for split seconds. Second fact, “greets” or “greetz” refer to greetings or salutes by the creators to other demosceners (or sceners).

We’re not going to just watch demos. We’re also going to analyse them. Let me just give you the demo first. It’s “Concentrate” by Adapt. It was submitted to the Breakpoint 2008 demo event. Download it. It’s about 15.4 MB in size and about 5 minutes in length.

Keep these 2 points in mind while watching:

  • The sparks waterfall – collision detection, physics, gravity.
  • Texture in texture.

The technique used in the 2nd point goes like this. You render a scene onto a texture. Then you add an object, map that texture onto the object, and rerender the scene. Let me show you an example. Say I have this scene:

Texture scene

I render the scene onto a texture. In this case, I saved it into a bitmap. In the demo, it’s saved in memory. Then I created a cuboid and mapped the texture onto it, and then rerendered the scene.

Texture scene mapped

One characteristic of demos is that you usually have to watch them a few times to truly appreciate the beauty, the art and the skill used to produce it. Feel free to space your demo viewings.

Then tell me your experiences in the comments. What did the demo make you feel? What did you notice? Can you recreate a certain effect? Can you figure out how you can code certain parts? This is like an open homework project, so let’s discuss!

Human-first software development

Aaron Falloon asked in a previous post if I could write something about the actual theory behind programming.

I don’t even know where to start. I have to assume that he’s referring to the non-coding aspects, because it feels like a philosophical question more than a technical one. So I thought hard. And I got an answer.

To fully explain the answer, I’m going to go deep in philosophy, so just bear with me for a while. Of all the species on Earth, humans are the only one actively and aggressively changing our surroundings. For the sake of argument, let’s take it that we do that to make things better, for us, for the environment, for every living creature.

Ignoring the Darwinian theory of evolution and the belief that we all sprang forth from the union of a single man and woman, Nature seems content to just let things go at their own pace. Have you seen a cat work hard? Albatrosses glide over miles and miles of open ocean, and they land only because of the need to procreate or to feed their young. Bristlecone pines live for millennia. Can you imagine doing nothing the entire day except grow a fraction of an inch?

Bristlecone pine by Jon Larson at iStockphoto

Where was I? Right, so not only do we humans do something about our surroundings, we do it at an alarmingly fast rate. Buildings spring up like mushrooms. Cars are built so we travel faster. And then came computers and the need for programmers. The Internet exploded the transfer of information, and software is part of the driving force.

I believe it’s our basic nature to want to better ourselves and in relation, our surroundings. In the software development world, this means writing better programs. Perhaps because of the ubiquitous nature of the Internet, this gave the illusion that anyone can program. Everyone wants to program, because there’s the satisfaction of creation and the element (or illusion) of control. That the program will make our lives easier. It does, just not one created by anybody

So how do we become great programmers? One way is the UI-first approach. Design your user interface first, because it’s the only thing your users care about. Then work backwards towards the code.

And so my answer to the actual theory behind programming?(yes, finally!) It has always been about humans. Programming languages come and go. Paradigms, methodologies and Internet fads. Software development life cycles, from design to coding to testing to launching. All these variables are nothing compared to the human factor. We are the most unpredictable, and paradoxically the most important part.

The human factor is involved in estimating project deadlines. It’s why I see fresh graduates struggling with the corporate environment. It’s also why I seem to write stuff about human behaviour, such as observing a hungry youth, or the reluctance for authentication. There’s the importance of understanding user queries, placing ourselves in the user’s perspective before we jump to conclusions.

The study of human behaviour greatly benefits your skills as a programmer. Because ultimately, you’re creating programs to be used by humans (The Matrix and robotic artificial intelligence aside). To create great music software, it helps if you’re a musician. To create great blogging software, it helps if you’re a blogger. To create great image editing software, it helps if you’re a graphics artist.

Program errors aren’t about the program itself. It’s about the human between the computer and chair. It’s about the programmer’s misunderstanding of human behaviour.

20 years from now, we might not have to write code at all. We might be shuffling stuff on virtual screens like in Minority Report or The Matrix. But the human part is always there. So use a human-first software development approach.