Most of the time I have seen beginners struggle with compiling programs that use package names. Generally when you are learning java, you write everything in one program, compile and run the program. This means that you would never start practicing using package names. These days most of the junior developers directly start working on a IDE. When you start with IDE you miss out certain stuff which is fundamental. If you are a developer try writing a simple program using a package name and compile and make it run in the DOS prompt. If you are successful, well and good.

The point here is not about packages but when you get into a compilation error that says that a particular class is not found, and interestingly the class that the compiler is looking for might be under the same directory as your other classes might be or from where you are compiling. Wait a minute, did you check if you had a CLASSPATH variable set? If yes did you also include the current directory in that path? OK you might ask, how to add the current directory? Today it might be c:\java, tomorrow I might run another program in another location. Well if you didn’t know one of the basic information that a OS recognizes . (dot) as a current directory then know it now. Include . (dot) in your CLASSPATH variable, the java compiler looks into the directory where you are trying to compile from as well. The class not found issue occurs when you have a CLASSPATH variable set that does not include the current directory and a class refers to other classes in the same project under different package structure.

Couple of developers came to me yesterday, that they were unable to solve a problem. They have been cracking their head for more than a day with no feasible solution. I asked them to go through the program and asked them to explain me step by step what the code did and what was expected. It turns out that one api did not support a feature that another api provided. The developers searched in the net, a site provided an unguaranteed plugin, that altered the core api code, and few sites took right in telling them to change the requirement.

As I went through the requirement and the code that they had written, it struck my mind the solution is round the corner and was a real alternative to the actual solution of worrying about inconsistency between the api’s. Ofcourse the solution was not very straightforward and deviated from the traditional approach, but at the same time it was an excellent alternative with no side effects and/or no change in the expected output. The point here is api inconsistencies and incompatibilities are certain to happen, particularly when you are working with more than one technology and trying to make them work together. Rather than trying to fix the api look around and look for alternatives and workarounds. You will find that its not that bad when you can accomplish what you want with simple workarounds. Mark a comment in your code about the alternative. And as a homework you should always keep watching the api patches and new versions and whenever the api inconsistencies are fixed you should set right your code with the straightforward solution.

Many of the times when you are working on a dynamic presentation layer technology such as JSP or RHTML, it is very difficult to debug the code because the HTML is intermixed with the language code. Some IDE’s attempt to help you by providing debugging of presentation layer code but it may not be very effective most of the times. Usually when there is a problem in the presentation layer code (not syntax error but logical error that causes misbehavior of the display) you might scratch your head trying to locate the problem. The best solution would be to diplay the code/value generated by the dynamic code inside HTML comments and view the source to see what is getting generated.

Most of the dynamic presentation layer technology these days have simple API’s that can generate what you want and reduce a lot of HTML code to be handled by yourself (for example the Java Tag Library or the rails API etc.). In such cases troubleshooting would be much more difficult. That’s when you just have to put the code within an HTML comment. And once you are viewing the page in the browser you just have to do a view source and look at the commented HTML to see what the dynamic code has generated. You might get a lot of clue and answer to your problem very easily.

The presentation layer developers get into lot of trouble when they work on a web based application. After the advent of dynamic presentation layer technologies (such as JSP, RHTML, ASP etc) HTML components and the language code gets nested with each other. Usually after some time the code becomes messy particularly if you dont have separate code for every layer in the page. But however loosely coupled your code is, the resulting page may not be what you expected and most likely you will miss something not appearing or not appearing the way you want.

I have seen developers trying to probe their dynamic code and trying to locate the problem. But a best place to start would be from your browser and view the source code generated. Here is the reason why. However complex your system is and whatever be the technology that you use for the server side application, everything has to ultimately get transformed into one single HTML file that comes to the browser. So it is better that you study the resulting HTML layout of your program(s). Most of the time you know which part of the HTML is causing the problem, and you would definitely know which program/code generates that section of the HTML.

The troubleshooting of a problem ends once you exactly locate where the problem is. If you know what the problem is then it is a matter of finding out list of solutions available and picking one that best solves the problem, or it could be taking a different course of action. Most of the time people tend to lose focus and look at outside of the real problem area. Most of the times the solution to a problem is already available over the net, people have faced it and experts have answered the solution or they would have suggested the alternative. The following is the list of ways to effectively use the net for troubleshooting.

1. Use the right phrases when you search in the search engine. The best way to get the right phrase is to look at your problem very carefully. Probably what you see as problem may not be the root cause of the problem. It could be something else that is triggering the chain of reaction. Study the trace carefully and try various error messages that form the trace.
2. Use the search engine effectively. Most of the times we do not get into the advanced search, where you can filter the search result and narrow it down to the core area of the problem. This will save a lot of time by not going through a lot of links that are irrelevant.
3. Search in the groups. This is where most of the solutions will be available.
4. Nowadays, blog is where lot of people post their problems and solutions. Use a blog tracker and blog search site like Technorati.

I am sure every one of us would have tried one or the other of above options, but not a combination of them, so it is best to mix and match the above options in various ways to be more productive.

Troubleshooting is an important skill that any developer should build from the beginning without fail. It is an important skill that can save a lot of time if you just know where to look for the problem. When do you find out that you have to troubleshoot something? This is my definition of troubleshooting. When you are into a trouble, and you know that it is not a syntax error that is causing the problem, you know that it is not the logic that is causing the problem, and you start to sratch your head or keep your hands on your head and start thinking, why is my machine acting weird, then you are in trouble and you have to shoot it. Be aware though, sometimes you think too much while you actually made a careless mistake and a typo that is causing the program to misbehave. I am not talking about this type either. What I am talking about is a problem where the solution is not around quickly and you need help, either from experts around or from experts over the net in the form of forums, groups and blogs.

I had been grooming fresh college students into IT professionals over last 7 years and this is what I tell them. The most important skill that you have to hone yourself so that you can start climbing the ladder faster is the troubleshooting skill. Think about this, when you are working on solving a problem, you dont start working with the intention that you want to run into hell lot of problems and not complete it. Everybody wants verything to be working perfectly the first time. And we know that practically its not the case most of the time. Even experts get into a mess and have to struggle a lot to get out of the problem. While you cannot avoid problems, but you can keep a watch over yourself to make sure that you are cutting the time that you spend on finding where the problem is. Here is a neat exercise that I suggest to the new folks.

Create a word document that contains a table, similar to below.

Keep this document open every day and start adding the details as and when you start troubleshooting something. This document helps in two ways,

1. It helps you keep track of how effective you are in troubleshooting. If there are more negative values in the troubleshooting scale then you are improving in your skill.
2. You are not just recording the time, but also recording the problem and solution, this becomes a valuable respository and can help save a lot of time in the future not only for you, but for your team as well as the company

Ofcourse this exercise will need some discipline, you have to keep setting benchmarks and compete with yourself to be effective.