There are no shortcuts

Successful people. Senior programmers who can debug without looking at code. Children who can beat the whammy out of you in chess. Secretaries who can spot the missing L in “pubic announcement”.

All of them have shortcuts. All of them use shortcuts. But they’re not successful because of using the shortcuts. They’re successful because of the knowledge gained through hard work, and as a result of that hard work, they created shortcuts.

There’s a difference between using a shortcut and understanding a shortcut.

The ternary operator

This is how the ternary operator looks like

condition ? value-if-true : value-if-false

In code, this will look like

int i = (100 > 90) ? 23 : 57;

and the variable i holds the value 23, because (100 > 90) is true.

Do you know its longer equivalent?

int i;
if (100 > 90)
{
   i = 23;
}
else
{
   i = 57;
}

Quite a bit to type isn’t it? My point isn’t about which is better, since both are useful and more readable depending on the programming context. My point is, do you know how they’re equivalent, that they work in the same way?

Using the ternary operator without understanding how the if-else construct work can be disastrous, particularly for new programmers. Debugging can take on a whole new level of slap-your-hand-on-forehead-why-me’s. Knowledge without understanding can be dangerous…

Most make-money-online people don’t make it

After you get over your retort impulse, let me say that the successful online entrepreneurs, businessmen and Internet marketers are great at what they do. The techniques they teach will make you money. It made them money didn’t it?

I’ve read a fair bit on these techniques. I’ve been to their seminars. Hey I’ve even bought some of their products. I came to a stunning conclusion. For all the tips, techniques and shortcuts they gave, it’s still hard work.

The usual situation is that they’ve found the simple solution to solving your problem (making money). They’ve identified the {insert your favourite number below 15} easy steps to making your dreams come true. You buy their product or service. You get zero to dismal results. They tell you that you just have to follow their method a little bit more, a little bit longer. In the meantime, how about some personal coaching to help you in whichever area you’re stuck in. You buy more. Ad infinitum.

That situation may not be true for you. I’m not condemning this process. All teachers do this. I’m sure their product works fine. The problem isn’t with them, it’s with you. Following their shortcuts isn’t enough. You must also understand why and how they used those shortcuts. There’s a lot of hard work behind those shortcuts.

Think about why some lottery millionaires go back to the way they were very quickly. They took the shortcut of lotteries and gained a million dollars. They didn’t understand how hard it was to make a million dollars, and so they lost the million dollars.

Taking shortcuts is easy. Understanding shortcuts is hard.

Ctrl-A, Ctrl-C, Ctrl-V

Can you guess what they are? In the Windows environment, they are the “select all”, “copy” and “paste” shortcuts respectively. Did you know that there are still people who don’t know the shortcut to copying?

There was this one time where I had to walk a user through some setting up of stuff. One of the steps required him to copy everything from one folder to another. And that’s what I told him over the phone, “copy everything from this folder to that folder”. Apparently I should have been clearer in my communication to him, because he didn’t know what to do.

Edit menu ctrl-c

So I told him to click somewhere empty in the source folder without clicking on any of the files and folders, do a Ctrl-A, do a Ctrl-C, then go the destination folder, and do a Ctrl-V. Otherwise he could still be searching under the [Edit] menu, and using the mouse to click on *shock* the “Copy” menu item.

That user might not have to understand the hard work that went into programming that shortcut. He only had to appreciate how that shortcut could make his life easier. Then use it!

Shaving off 20 years

I remember watching this movie where this young man of 14 years old committed some crime. It was quite petty (and I think a misunderstanding’s involved), yet the law in the movie dictated that he be sent to jail. For 20 years.

And it’s not just any 20 years. The technology in the movie was such that a human body could be placed in stasis indefinitely. Here’s the terrible part. The body itself would continue to grow, yet the mind was locked in time.

So this young man emerged from his time prison, 34 years of age, yet 14 years of mind. The time prison was created explicitly to take away prisoners’ life, in terms of memories that could never be formed, and the time that could never be gained.

The law in the movie took away a prisoner’s time, but never gave the prisoner time to repent. There’s no time to learn, to grow and to understand. Only the shortcut of time fled past.

Blink-of-an-eye transportation

I’ve also watched this drama series called “Earth: Final Conflict” where Taelons, an alien race, came to Earth. One of the coolest things in the show was this near-instantaneous transportation device. With a device in the North Pole and another one in the south, you could move between the two poles in the blink of an eye (though I couldn’t fathom why you’re in the poles in the first place…).

We used to have to walk five kilometres. It was hard work. We sweat, our legs tired, our lungs out of breath, and a whole lot of time was gone.

Then came wheels. Shortcut. Man-powered wheels advanced to wheels powered by fossil fuels. Shortcut. It came to the point where you could stand in place waiting for a bus, get up that air-conditioned bus, sit down, not having to do anything, and you still travelled five kilometres. No sweat, no muscle cramps, easy breathing and lots of time saved. Shortcut.

Do you even know how hard it is to walk five kilometres? Can you appreciate the shortcuts our modern transportation have provided?

When we have understood, appreciated and used the shortcuts, maybe, just maybe, we could understand how to take it to the next level and realise that Taelon technology. Where we could move from here to there, in the blink of an eye.

In closing

It’s ok to take shortcuts. You should also understand the hard work that went into those shortcuts. Only then do you not just stand on the shoulders of giants, but be the shoulder for the next giant to stand on.

Otherwise you’d be stuck at the level of using Ctrl-C, and never progressing to implementing a better way of copying stuff.

The people who succeed in using shortcuts, are people who understand the journey and the hard work behind those shortcuts. And if you know a shortcut to understanding shortcuts, let me know.

The barber paradox

Suppose there’s a barber who shaves only those who do not shave themselves. The question is, does the barber shave himself?

That was the question I posed in a previous article. The hint to the answer was actually given in the article: “What if your original assumptions were wrong?”

So let’s begin, with two fictitious men, John and Ricky. John has this unfortunate streak of accidental cuts, so he doesn’t shave himself if he could help it. Ricky has this inexplicable fear of people wielding sharp objects around his face (ever watched Sweeney Todd?), so he shaves his own beard.

It’s actually a mathematical question on logic. So forming the statements, we have:

If John does not shave himself, the barber shaves John.
If Ricky shaves himself, the barber does not shave Ricky.

Here’s the interesting part. Let’s substitute “John” and “Ricky” with “the barber”.

If the barber does not shave himself, the barber shaves the barber.
If the barber shaves himself, the barber does not shave the barber.

Either way, the statements don’t make logical sense, each contradicting itself and creating a paradox. So what went wrong?

The statements were correctly formed. It’s our original assumption that’s wrong. What’s our original assumption? That

there’s a barber who shaves only those who do not shave themselves

So the correct answer is, there’s no such barber.

P3 Newsletter launch

I’ve started an email newsletter called Polymath Programmer Publication. Yes, it’s a mouthful, why do you think I shortened it to P3? *smile*

It contains mainly programming tips and articles, and is delivered on the 1st and 15th of every month. I plan to include a mixture of programming and non-programming topics, such as for loops and painting with light. Or functional specifications and X-rays. Non-programming topics are derived from the arts (writing, drawing, photography and so on), the sciences (math, physics and others) and maybe a bit of news.

The main purpose is to expand the knowledge of a programmer beyond just programming. Yet because of the mixture, even a non-programmer might find the newsletter useful or interesting to read.

Side effects of reading the newsletter include increasing your intellect, thinking skills and generally making you a better person. *smile* So go sign up now!

Jumping to conclusions

In this age of information overload, our brains do a fantastic job of protecting us. By filtering and making assumptions. By jumping to conclusions. The thing is, sometimes they’re wrong, because the assumptions were based on past information, and may not apply to the present or the future.

We need to take rein and maintain a questioning mind.

Do you season before you taste?

I people-watch. When I’m having meals, or a cup of tea, I notice people. Their facial reactions, body movements and hand gestures. Their speech patterns. What they’re wearing. Any accessories such as laptops or wooden paddles (students in dragon boat racing).

I noticed something when people eat. Most of them reached for seasoning and condiment, and added them into their food before even tasting it. I’ve seen people sprinkle chilli flakes on their pasta. I’ve seen a child scooping grated cheese and plopping it on his pizza. There were people who dump packets of sugar into their coffee or tea. My friend, the classic case, squeezed four packets of chilli sauce on his burger (and mayonnaise and tomato sauce if he could get away with it).

All of them added seasoning before taking a bite, a sip, a taste of the food.

After watching this phenomena and thinking it over, I realised it. All these people had already decided that whatever food that’s in front of them needed more seasoning, whether the food was great or not. Their ingrain habits of pre-seasoning had blinded them to the case where the food was great in the first place.

The missing cursor

There’s this suite of Windows programs written in PowerBuilder that were passed down to me. There’s this quirk where the textboxes were too short in height. Because of this, even when the textbox was in focus, such as using the mouse to click on it, the familiar blinking cursor was still missing.

I had users who told me they could not edit the data in a textbox. I clicked on that textbox and hit the backspace button, the delete button and a random sequence of keys such as “asdf”. The textbox worked fine. The only thing missing was the blinking cursor and highlighted text to indicate the textbox was in focus.

There’s this particular case where I asked the user if she tried actually editing the data, like pressing the delete button. She said no. She had already assumed that because the blinking cursor was missing, that not only was the textbox not in focus, that it was also not editable. She didn’t even try editing in the first place.

Debugging errors

Jumping to conclusions based on weak assumptions is dangerous when debugging program errors. Faced with an error, you already made the assumption that most of the program was working fine, that hopefully only a small part of the code was wrong. Then you slowly trace back to hopefully one line of code, fix that and be on your merry way.

Debugging is like mathematical proofs. Proofs start with assumptions. Once you’re convinced the assumptions are correct, you move on to getting further assumptions based on the original ones. You deduce results, come up with findings and finally a conclusion.

What if your original assumptions were wrong? Then the proof becomes useless other than an exercise in logical reasoning.

Closing

Just to make it clear, I am for jumping to conclusions. Within reason of course. With experience, one can quickly come up with plausible causes for bugs, and act on correcting them. Sometimes I get an intuitive sense of trying out a solution over a few others. What you need to be aware of, is that you choose to be open to possibilities before closing in on your conclusions.

I understand that in French cuisine, it’s considered an insult to the chef if you add, say, tomato sauce to his dish. It doesn’t matter what you added. Just the act of adding something is an insult. It implies his food is not up to your standards, that it’s so tasteless that you need to enhance the food by adding something. Taste the food first. Don’t insult the chef by jumping to conclusions.

Pop quiz: See if you can figure this out. I found it in my math textbook in university.

Suppose there’s a barber who shaves only those who do not shave themselves. The question is, does the barber shave himself?

Answer to pop quiz here.

Be consistently wrong

If you’ve been maintaining code and legacy software as long as I did, you would have your fair share of horror stories. Some obscure program error would happen, and you would spend insane amounts of time tracing an elusive line or lines of code to find the pertinent root cause. Then you’d correct the offending code and send the new-and-improved program back on its course.

Sometimes, after you’ve tracked that bug, you were only able to correct the error. I believe it’s called data patching. Basically, the program completed, and there’s only this teensy weensy little piece of data that’s just a tad out of place.

You scoured the original data for telltale signs. You pored over reams of printed code. You debugged, you inserted printfs to look at output and you even tried flailing your hands wildly in the air, asking skyward “Why me?”. All to no avail.

Since time’s a-wastin’, and you’re short-handed, you did the only thing humanly possible. You changed that piece of data so it became correct. Then you ran the other programs that were held up by this unfortunate incident.

The next time this particular error came up, you knew what to do. Since time’s still a-wastin’, and you’re still short-handed, … well, you know what happened.

And it always came up. Consistently.

Actually, my point isn’t to encourage you to let bugs triumph like this. My point is that, when you make a decision like this, you have weighed the consequences and consciously, rationally and logically decided that the bug can stay. Fixing the bug costs more than fixing the error in the short term. And you’re willing to take the responsibility of long term costs.

Basically, you’ve decided to be consistently wrong. The keyword is “consistent”. Don’t go fix that bug, find that there are other bugs, and then you’re too lazy to go fix those bugs.

If you want to fix it, really fix it. Don’t give it a halfhearted attempt. Make up your mind. Give it your all. Either be consistently correct, or be consistently wrong.