The pains of debugging other people's code.

First, let me welcome you to my new blog. This blog will be mostly about web development with php and other php issue in general. I don't claim to be a php expert, nor do I have any sort of education in this area. However, I have been doing websites and coding PHP since 2001 or so (well, I didn't pick up PHP until maybe year or two later). So, I do have some experience in this matter.

This blog will consist of tutorials for coding php and how to do things properly. If you have any suggestions or questions, feel free to ask and I will try my best to answer them. However, rather than emailing me questions, I'd prefer if you either posted in comments or used a forum available at my website (which is still under construction).

But enough about me and this blog. Let me get to the first issue at hand, that is, the pains of debugging code for other people. Sometimes I feel like I'm being used as personal debugger for some people. Don't get me wrong, I don't mind that as much as you may think. In addition, I also help people with their php over few IRC channels.

At times, debugging can be quite fun too. If there's problem in the code that is not obvious at first glance, it provides some challenge and can be quite educating too, if some particular behaviour is result of unexpected results from functions or such. However, when it comes to randomly debugging other people's code, there is one particularly annoying problem: The human interface between me and the code. Let me explain.

1. People rarely grasp how to make proper questions. Quite often, you get people asking for "Whats wrong?" about their or saying "It doesn't work" while pasting their code, or at the worst case, only one or two lines of their code. The thing is, you're supposed to tell me what's wrong, and I'm just supposed to figure out why it doesn't work and how to fix it. Telling "It doesn't work" doesn't really tell me anything. You know more than that, so please, don't hide information.

I know error messages seem to be complete mystery to a lot of people, but for those who work with them daily, they are actually quite informative. So, if you ever get error messages, don't hesitate to include them in your description of a problem. However, if your problem isn't a simple error message, but rather a piece of code not doing what it's supposed to, then please also describe what your code is actually supposed to do. Usually the reason is because you have completely wrong approach to a coding issue. However, all I see is what the code actually does, so I don't really have clue what it's supposed to do, unless you tell me.

2. People are sometimes quite confident about what's wrong with their code. I don't know if it's some sort of pride issue or what, but quite often people only tell me, what they think I need to know. This is where things usually go downhill. For example, there are honestly people, that refuse to give other parts of their code, because they are so convinced that their error lies in one particular piece of code. Of course, you don't have to give your entire project to me to debug small problems, but there's a big difference between giving entire file than just few selected lines from it.

Another good example is generalising. You are often working with some very spesific problem and want to achieve very spesific things, so please don't try to generalise your problems. It's actually better to be quite spesific in what you want get done and give real examples of what's wrong, rather than attempting to produce a generalisation of your issue. The fact is, your problem is quite often assiciated with spesific problem in your implementation, rather than logical error in the general level. Remember, you're not trying to argue ideologies, you're trying to get your code to work.

3. Last but not least is the difficulty of getting people to actually do what you want them to do. Sometimes errors aren't obvious at first glance and study of code is required. Debugging in general is very mechanical process without really any sort of magic in it. Most "magic" is usually associated with making the intelligent guess about where the actual problem lies.

Usually the debugging is just putting var_dumps here and there and few echos at strategically chosen locations to determine the flow of execution (what happens and what doens't). However, sometimes even the simplest instructions get misunderstood and people are incapable of doing what told. Sometimes people refuse to do something, because they are confident their problem doesn't lie in some piece of code I want to inspect. The truth is, however, I don't believe a word you are saying about what works and what doesn't unless I see it with my own two eyes.

Truth is, there is nothing too hard about debugging. It's all quite logical and mechanical process. The only benefit of experience is being better at guessing where to start looking for bugs. But other than that, it's all about how much effort you are willing to put into it.