I have a lot of sites that I enjoy reading. Just a short time ago, relatively speaking, I would have to bookmark them all and visit each one independently to see if they had any new content. This can be time-consuming.

These days, though, most sites have RSS feeds. For those of you who are less technically inclined, consider it a fancy way of saying that the site’s content is available in a format available to other programs. You click on the little icon or text link to subscribe to the feed. The icons tend to be orange or green, and look like this.

Never mind the complicated explanations about XML - all this really means is that you can get the site’s content (feed) in special programs or websites that are set up to read it. Personally, I get all my feeds using Google Reader. So anywhere I go, if I have access to the internet, I just go to Google and sign in, and there are all my feeds, ready to go.

Instead of having to check a bunch of websites for new content, I go to one site, and it tells me which of my feeds have new content. I can read it at my leisure. All in one place.

Just sign up with Google (it’s free), and when you see a site you like, click on their feed button, click on the option to subscribe via Google, and you’re done! So easy. It’s still a bit of a hidden gem - a lot of people aren’t very familiar with it yet, but it’s rapidly growing in popularity as more people discover how convenient it is, and how much time they save doing it.

You definitely don’t need to be a geek to appreciate RSS!

You never really learn to swear until you start to code.

“Any given program, when running, needs debugging. Any debugged program is obsolete.”

Programs have bugs. It’s just part of being human - we make mistakes. A program is only as good as its authors. Yet surprisingly enough, when you take programming classes, they rarely spend time teaching you how to efficiently debug code.

Yet in the real world, once you start working on actual applications, you will spend most of your time enhancing, testing, and DEBUGGING. Every step of the way as you write code, you will be debugging it when it does things you don’t expect it to do. Or when users do things you didn’t expect them to do. Or when you write an enhancement and it inexplicably breaks existing code.

You get the picture.

The last thing you want to do is waste even more time debugging than you already spend doing it.

I’ve learned a lot of things about debugging code and writing code that is less likely to have bugs in the first place. Here are my favorites that I’d like to share with you, in no particular order.

1. Leave your assumptions at the door

“The code that is hardest to debug is the code that you know cannot possibly be wrong.”

If you are tracking a bug down, don’t make assumptions about what is causing it. You will only see what you look for. You can spend hours overlooking the real problem. Pretend it’s someone else’s code if you have to. Just drop your assumptions about what values are in your variables, what objects can’t possibly be null, or anything else.

2. Breakpoints are your friends

After you’ve ditched those assumptions, make breakpoints all along your code and narrow down exactly where the bug is. There’s no point in tracing through a bunch of code that is working just fine, now is there?

3. Watches are also your friends

Once you’ve narrowed down your problem to one section of your code, set up your watches. Check the value of every one of your variables as you step through your breakpoints, even if you think you know what it should be (see #1).

One of the most common things I see is people assuming a loop is even iterating to begin with when in fact it never runs because the condition isn’t met. A collection is empty that they were sure had to have values in it, or a counter wasn’t set properly. This is especially frequent in languages that let you shoot yourself in the foot, like VB running without Option Strict on, Perl, and Javascript. Those will all just go ahead and create an empty variable if you make a simple typo!

4. If all else fails, print a trace

Not everyone has the luxury of an IDE to set breakpoints and watches with. So log print or echo statements! Alert things out if you’re using Javascript. Stick enough print statements in there and you can trace an awful lot of code. It’s better to spend some time typing out a metric crapload of echo, print, or console writelines than to spend days banging your head on your desk.

Those who have had to debug an SQL stored procedure or classic ASP code will understand.

5. Write small chunks at a time and test them independently

The more code you have that isn’t tested, the more you have to trace and watch to debug. Write your code in small, manageable chunks and test as you go. Write it so that you can easily take out a chunk and stick it in a little test program - most languages these days support methods and functions - modularized code. Take advantage of it.

Don’t write an entire object with all its methods and properties, and a consuming application, without testing a thing. That’s just asking for trouble. I have a ton of tiny little applications just for testing chunks of code. I write a chunk, test it, then integrate it into the whole. I can’t tell you how much time I’ve saved doing that.

6. Don’t throw away your exception stack trace

Some languages have a certain syntax for exception handling that will create a new exception without retaining the original exception. Be careful that you don’t accidentally do that!

And for your sanity’s sake, don’t catch an exception and do nothing with it. It is not worth the minor saving in execution time or resources that it takes to do proper exception handling.

You can spend hours (even days) trying to trace an exception source when had you just popped out the original stack trace, you’d have seen the problem immediately. This is especially common when you’re enhancing an existing application and it breaks something in the original code base.

So those are my top suggestions. Debugging lessons earned the hard way. Please share your hard-earned lessons in the comments!

LifeHacker.com posted a Top 10 Obscure Google Search Tips a couple weeks ago that included a couple of my favorites, such as searching for similar words and currency conversion.

The readers proceeded to post a metric crapload more, including how to get weather, movie listings, and track your packages. There’s apparently a recipe search as well. Go figure.

Go give it a read if you do much searching on Google.

A question came up over on an ASP.NET forum about how to create an enum class for the days of the week. Several people replied, telling the poster how to create enums and how to use them. To my surprise, not one person pointed out that the .NET framework already has a class for this right in System. It’s called, oddly enough, System.DayOfWeek.

RTFM is an acronym that has been around for nearly as long as programmers. Put succinctly, it means to go look it up. Most of the time it’s used when someone asks a basic question that is easily answered by reading the documentation for the language of choice, but it can also address the fact that a simple internet search would have yielded the answer without wasting people’s time.

If you are going to code, you need to read the documentation. Be familiar with the base classes, functions, and/or libraries available for your platform. If you use Perl, you get familiar with the most common Perl libraries for what you’re trying to do. If you code .NET, you check out all the base classes for System, the data classes, and the configuration classes, at a minimum. If you’re coding for the web, you check out all the web controls. If you’re coding for Windows, you check out the Windows Forms controls.

If you want to know how to use your remote, you read the manual that came with it. You don’t immediately go searching the internet and posting to message boards. The same goes with programming. If you want to know how to do something, the first place you check is the documentation and examples provided with any base install.

If you can’t be bothered to RTFM, then you shouldn’t be a programmer.

I don’t know too many people in IT who don’t frequent message boards and online forums. It’s a great way to increase your skill set and flex your brain muscles. Helping other people with their problems gets you experience, and in IT, experience is everything.

Newbies love to post that they have a “simple” question or an “easy question”. The thing is, they’re NEW. They don’t realize that the question that appears to very simple, isn’t. On the flip side, they may overcomplicate the hell out of what they’re trying to do and post a “hard” problem that isn’t hard at all.

Message boards are great places to get help with programming, but stay away from judging how easy or hard something is. If you want to get help, you need to be as specific as possible about WHAT you’re trying to do, but you also should post WHY.

Why post why?

Because you may be limiting yourself, or overcomplicating the problem. Sometimes we get our minds all boxed into a complex solution (that causes us grief later) and miss the simple fix. Or we get our brains focused on one specific way of doing something just because it’s how we know to do it, when in fact someone else may have found something much easier and more efficient.

Programmers need to be flexible and open-minded to be good at what they do. Start practicing early by omitting judgments on how simple, or difficult, something is.