Debug like a CSI

It is a morning like any other. You’ve got your tunes, you’ve got no one around in the office yet, and you are cranking out code like you’re on fire. Until some industrious user calls you and drags you out of your zone. You smile and nod as you listen to her explain that there’s been a tragedy, a terrible program error has occurred and she desperately needs your help. Time to debug like a CSI.

Document the scene
You ask her what exactly happened and you listen attentively as you jot down notes of her concerns, providing gentle affirmations and guiding her to the answers you seek. She’s practically in tears and just manage to tell you some name of the program she was using and a brief mention of the error itself. Then you ask her to provide you the most powerful piece of evidence she has: the screen shot of the error.

Gather evidence
So you’ve got an image of the error, and whilst you have every confidence in her statement, sometimes users just don’t see the difference between “An error occured” and “A Error occurred”. Her statement is probably something short like “I click Save button and there’s the error!”, so you don’t really have much to work on. She also probably sent you a 3 megabyte attachment of the screen shot and practically blew up your inbox. You note down the exact error message, and from her statement and the screen shot, find out the pertinent program responsible for making her life (and yours) miserable.

Evidence analysis
You open up the program code and use the Find function of the editor to track down the places where the exact error message occurred. You also retrace the steps taken for her to get that error. Hopefully, the error is documented in the code. If it’s a system error, then you’ll have to rely on her statement to pinpoint the exact location of the offending line of code.

You find out why the error occurred and if it’s actually correct that it happened, according to the business logic behind the program, then you give the user a call or an email to explain that everything’s fine and the error is supposed to happen. You might get more questions, such as the reasoning behind the business logic. But that’s another story.

Crime scene reconstruction
If you can’t find anything wrong, it’s time to reproduce the error. You have got to do exactly what the user is doing. It can be tedious when it’s production data you’ll be handling, and you have try out on a test environment. The test environment may not be identical to the production environment, some database tables might be missing from the test environment, and you’re starting to get cranky.

Somehow, you reproduce the error, and finally figure out the reason. You correct the error, recompile the program and send it to the user. You sigh as you are reminded of how poorly your department fails in the software management test you’ve read about, but that’s life.

Postmortem
Taking in a deep breath, and another swig of coffee, you settle back anxiously into your rhythm, half-expecting the user to call you to say that the error came back. After a few minutes, you slip into your zone again, the error forgotten like an ephemeral whisper…

Master your development tool of choice

Following the spirit of “Master your programming language of choice“, is the skillful use of your favourite development environment or IDE (integrated development environment), such as Microsoft Visual Studio or Dev-C++. You need to know the shortcuts, keyword highlighting and anything else that will make your programming job easier.

For example, if you deal with strings a lot (say SQL statements), it will help if your IDE makes it easier to find on the screen. The standard seems to be red colour for strings. The default colour highlighting for Visual Studio 2003 is black. How can you find any string literal in your code quickly if the string literal is the same colour as your code?

With all the advancements in development tools (such as Intellisense), you should be focusing on the one thing that computers cannot do for you: thinking. Thinking of the algorithm that will implement your business logic. Thinking of the different possibilities that your logic can succeed or fail, and handle them. There are lots of code generation tools out there to make your life easier. That said, there will be instances where you have to do the actual coding yourself.

Your greatest asset is your ability to think.

It’s not about you. It’s about results.

Recently, something happened that shook my confidence a little. Before I get to that, let me say that I’m a fairly competent in web applications, in particular, .Net web applications. I have done image creation/processing, CSS validations, and making sure the web applications are as cross-browser as possible. I have made the user interface as simple and as easy to use as possible. I’ve read up tons of security measures and implemented many of them on the web server and in programming too. I follow any sensible coding guideline. Database tables are designed to be relevant and scalable for as long a time as possible. I’ve even released two public web sites, all single-handedly done by me.

Now, in between doing new projects, I also try to improve existing ones. So I have this pet project. Being that it’s a pet project, I let my creativity fly on the web application. I tried out my own 3d rendered graphics. I pushed my CSS skills in managing display. I even tested out what was to me very new, AJAX, to make the web application more lively, more “real-time”.

Then one fine day, it was decided that my pet project is actually going to make a difference in the team’s overall productivity. So it became a full-fledged project. Suddenly there was a deadline. Suddenly people are going to see it and use it. I mean like really see this project of mine. And then it happened. My deluge of “change this”, “that’s not right” and “I want it that way” came.

For the first few seconds, I was like outraged. I mean who are they to comment on my work? I was enraged. I was indignant. Then, I calmed down. Because I realise that it doesn’t matter what you think. Ultimately those people who said “do this and do that” are the ones who will use your application. Accept that.

It’s not personal. (Ok, sometimes it is…), so I want you to concentrate on the results. What is it that the users ultimately want? Your code can be the most elegant piece of creative work there is, but if it doesn’t do what the user want, it’s useless.

Focus on the user. And yes, sometimes, you have to let go of your code.

Master your programming language of choice

I have gone through many a program where I would stare at a section of code, trying to figure out what it’s doing. After a while, a light of understanding would flood my consciousness, and I would ask, “Why did someone write like this?”

The problem? The task at hand required a certain function, say formatting output (quite common) for displaying a string of a length of 4 characters from a number between -999 and 999, inclusive of the negative sign. I would then see code checking if the number was negative (to determine if a minus sign was required), string trimming and left/right alignment of the number and so on.

Why did anyone go through all this when there’s a perfectly functioning formatting ability within the standard library of the language? (I’m thinking C at the moment, but most other languages are still applicable) I came to one conclusion: the programmer didn’t know about it.

You can be a better programmer by simply knowing more about the language you’re using. You don’t have to remember every single function available. You just need to know where to look. Albert Einstein said something to the effect of “I don’t remember anything that’s written in a book.” There are online libraries of programming languages. Use them.

As a programmer, you are paid to think up solutions and implement them via code, not reinvent something that’s already done and then code the business logic. Your creative abilities are more important than your memorisation skills.