stackoverflow.com

April 18, 2008 By

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/

Filed Under: Curiosita Tagged With: ,

Telescopic and infrared vision

April 16, 2008 By

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?

Filed Under: Programming Tagged With: , ,

Cannot endure programming hardship

April 14, 2008 By

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?

Filed Under: Programming Tagged With: , ,

Featured demo – Concentrate

April 11, 2008 By

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!

Filed Under: Curiosita Tagged With: , ,

Human-first software development

April 9, 2008 By

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.

Filed Under: Curiosita Tagged With: ,
« Older Posts
Newer Posts »