Search This Blog


Saturday, October 4, 2008

Search, Ask and only then Code

Writing software is expensive; it requires time and mental effort. Writing software can be nasty as well; the code written more often than not contain bugs, hideous bugs. Fixing these bugs are difficult and expensive.  Worse still, the bugs will only surface when you are no longer actively working on that portion of code. 

In order to save the trouble, a programmer should always try to write as little code as he can. This means that he should always search, ask and only then code. Don't know how to look for urls and convert them into clickable links? Don't code-- yet. Instead, search the Internet for a solution. Don't know how to export pictures from Microsoft Word to images? Search Google. Forget the algorithm ( or the API) to convert all the strings to uppercase? Instead of flipping MSDN from page to page, just search Google! In fact, the search engines nowadays are so powerful and sophisticated compared to early 2000 that one can easily obtain the answer in a split second.

I remember the time when I started programming, the default programming experts were the ones who already have years of experience into a particular language or platform. Of course, given the years they had worked with the languages, they knew better than other people. So, we the novice had to consult them whenever we hit a roadblock ( and endured an angry stare in exchange for the service). If we forgot the APIs, they were the ones we turned to. There were a lot of times when we had to rewrite the same algorithms again and again for different projects simply because we couldn't really find the old algorithms and it was much faster to reinvent the wheel. Also, search engines back then weren't as useful as they are today. I was learning, but at a much slower pace than I can today.

Now, with Google and a big programming community online, I can easily get to the answers of my question. Not to long ago I dabbled into Python and Google App Engine . I didn't know a single thing about Python and Web App framework back then. But when I ran into a problem, I took the trouble to search for solutions instead of hitting the IDE and churning out the code. I also worked on an Office Add-in project. Instead of flipping through pages and pages of reference books, search was all that I did when I needed help, or when I need a quick fix.

If the solution is still elusive after an extensive search, asking is the next thing to do. For the time being StackOverflow is the best place to ask questions and get answers. The response time is short and the answers are usually helpful ( except for Visual Studio Tools for Office questions, that is ). I know there are developers who are afraid of asking questions because they can't express their queries well. To them, I have one advice: learn how to ask! It is a skill that is as valuable as knowing how to code. True, you can eventually get to your answers without asking, but how much time you have to waste for that? Sometimes you can just get cornered in the thinking, unable to see the obvious light in front. But other people don't have the same blind spot as you, and they are more likely to see the obvious point you miss.

When, and only when all the external helps fail, you should resort to coding. But even as you type along, you should always remember to turn back to search, and ask mode if you find that the coding exercise doesn't turn up as well as you anticipated. Maybe your little coding exercise will help you to see the picture clearer, and hence, you will know how to rephrase your question so that Google can turn up a better solution. From time to time, take a step back, and ask yourself: Do I really have to write all these code? Have other people solve the same problem? Can I use their solution?

Search, ask and only then code.

1 comment:

Bill Potter said...

Sometimes you write some insightful articles. Other times complete dross.

OK, you may save time by copying and pasting code off the 'Net but then again, you may find the code doesn't work.

You are also suggesting indirectly that it doesn't matter that you don't know how to do things. How are you supposed to grow as a programmer?