Our lives as programmers are a never ending series of one problem after another.

If we are lucky, our daily slog at the keyboard is occasionally punctuated with brief glorious moments where it all "just works" and we feel like gods.

If we are really, really lucky these serendipitous interludes also happen to coincide with events like "product demos" and "production releases".

In between these glorious moments we toil through the frustration of one problem after another. We are not programmers, we are just hacking out the first solution that works.

This post will describe a bunch of different problem solving strategies. I would update the thread daily. Here are the first 8.

[size=14pt]The Prime Directive[/size]

1. Don't write defects in the first place. The best defect to fix is the one that you never wrote to start with.

- Nicely unit tested code
- Enforce database constraints
- Use an input validation framework
- Avoid unimplemented "else" conditions
- Understand how to use something in isolation before you use it in the main application
- Pepper your code with exceptions for situations you don't expect to happen

[size=14pt]Logging[/size]

2. Print Statements. The ye-olde print statement is still as useful after thirty years of programming as the first time I used one in high-school. Think carefully about the problem and often one or two lines of extra output will help to isolate the problem.

3. Switch to Fine Logging. Sometimes when an underlying library or product is not telling you why it is failing then increasing the verbosity of the logging can uncover additional clues.

4. Search the Logs. If there’s too much logging to read easily, search through the log files for keywords or error codes.

5. Wrap on, Wrap off. Controlling the logging viewed with word wrap on or off can also be helpful. Sometimes you want it on and sometime you want it off.

6. Search different logs. The main server log might not be the only useful log to search through. Java application servers often produce other log files that might be useful.

7. Windows Event Log. Another source of log files might be from the operating system itself.

8. Craft useful logging. Sometimes if you are not getting any useful logging then you might need to write it yourself. For example if you have a complicated data structure to deal with you might include carefully crafted “dump” statements at strategic points in order to get the visibility you need to solve the problem. This can also be quite handy when dealing with multi-thread problems. Sometimes half the problem is just “seeing” what’s actually happening.

For Logging you forgot:

File-Based logging : This is something that should be implemented from the start.
Whether it be by globally rerouting all print statements to a [rolling] file or by utilizing logging libraries.

^^^^ Thanks Boss...

[size=14pt]Talk to Someone[/size]

9. Ask someone who might know. If the problem is something that you think someone else on the team might know about then ask them. When you join a new project or team there are going to be dozens of things that you just won’t know about and someone else on the team will. Don’t be afraid about looking dumb. It’s far better for the team as a whole to get the work done efficiently and get you up to speed as quickly as possible. The only sin is to keep asking the same question over and over, so when someone tells you the answer that you make a note of it somewhere and don’t ask the same question twice.

10. Ask dumb questions. You might think they’re dumb questions but they probably are not. If you don’t know the answer then it probably isn’t a dumb question.

11. Explain the problem to a teammate. They might know the answer or be able to suggest things that you haven’t thought about.

12. Explain the problem to your dog. It really doesn’t matter who you explain the problem to it’s the act of explaining that gets your brain to analyse the problem from different angles.

hey. javanian.. great thread and great job.. I wan send u mail abeg...

musKeeto: hey. javanian.. great thread and great job.. I wan send u mail abeg...

No P.

Nice thread..i almost always avoid log files..bad practice..@muskeeto..are you a programmer?

Creatrixity: Nice thread..i almost always avoid log files..bad practice..@muskeeto..are you a programmer?

hehehehe
yup...

musKeeto:
hehehehe
yup...

Cool../* sorry for that bit of derailing */

[size=14pt]Writing[/size]

13. Write a problem statement. Write the most accurate and precise problem statement you can. By being precise you are challenging your brain to accurately describe the problem which in turn helps you to think of possible solutions.

14. Write a problem diary. Create a text file with a bunch of notes to yourself about the different things you have tried. Include snippets of code or configuration settings and also any errors produced

15. Keep a record of your problems and solutions. Have you ever had a problem where you know you've solved it once before but you can't remember how? Once you have a problem and then solved the problem, document the solution somewhere that's easy to search (preferably across your team) like a wiki, defect tracker, or just email it to yourself.

Did u get my pm?

Morning..

musKeeto: Did u get my pm?

Morning..

Yes and i replied you....

Javanian:

Yes and i replied you....

Didn't receive it..

musKeeto:
Didn't receive it..

Check your email, also you can check your Spam folder....

[size=14pt]Support[/size]

16. Read the FAQ. Check the Frequently Asked Questions before submitting your support request if there is one.

17. Submit a support request. If you have support available for a product or library then use it. Often the support desk is in a different timezone so when you get to the end of the day put together a support request and let someone else work on it overnight for you.

18. Before you Click Send. What you will also find is that the act of writing the support request will prompt you to think about the problem again and you often solve the problem or come up with new things to try before you even hit the send button.

19. Support. Breakthrough 1st and 2nd level support and talk to the real developers directly and preferably in real-time, chat/skype/screen sharing.

[size=14pt]Move Away from the Keyboard[/size]

20. Go for a walk . Taking a break from solving a problem is a good way of generating fresh ideas of things to try. Walking by yourself is a good way to put yourbrain into neutral and let it swirl around the problem.

21. Sleep on it . Likewise sleeping on the problem is also good for letting your brain come to grips with the key aspects of a problem.
22. Reset the Priority . The other good thing about taking break from a problem is that it lets your reevaluate how important a problemis. The issue might be a CSS/Layout issue that just simply isn’t worth spending
16 hours on solving, so be careful that you are spending your time effectively.
23. Ignore the problem . If you ignore the problem what you find happens is that you will be hypersensitive to related keywords forthe next week or so. What will happen is when you are reading something like Stackoverflow all of these keyword related articles will suddenly jump out you and mightcontain useful information.

[size=14pt]Isolation[/size]

24. Which line of code . Are you sure you know which line of code is causing the problem. Sometimes it helps to temporarily insert additional print statements between each line of code with nothing more than a “line x” statement. Watch carefully and you might be surprised that sometimes the flow through the code isn’t what you thought it was.

25. Break out into an example program . If you are having problems with a library or product then sometimes it helps to break out the related code into a program separated from the main application. This might take a little time to setup but often dealing with an isolated example program is easier to deal with than your project’s overall build process.Once you’ve got “something” working then itgives you a basis for comparison with the main program.

[size=14pt]Change the Code[/size]

Even if you don’t know how to solve the problem changing the code anyway can be an effective technique for problem solving.

26. Write New Unit Tests . Since you have to spend time with this code anyway, write some new unit tests. It’s helpful to get your brain thinking about the code in the same way that the computer is.
27. Refactor it . Problem code is often messy code. Tidy-up the code by applying simple refactorings like renaming variables, or unwrapping nested if/then/else blocks.

28. Find Bugs . Another code tidy-up technique is to look at any “Find Bugs” reports you have for the related code and start working with those first. Get the code into a tidy state first because;
It’s an easy cost-effective way of getting your brain focused on the code The problem may become more apparent

29. Rewrite It . One technique is to dump all of the related code and rewrite it from scratch. A fresh perspective may avoid the problem altogether.
30. Comment out unnecessary code - or at least what you "think" is unnecessary. You may discover that your understanding of the flow through the code isn't quite what you thought it was.
31. Experiment. If you are not sure how the underlying product or library is working thenit can useful to introduce little experiments particularly around boundary conditions.
32. Periodically go back to a clean state . If you have been making lots of different changes either in the code or with configuration settings it’s important to periodically go back to a clean slate. Otherwise side-effects from experiment number “3” might affect the “right” answer and so you never actually discover the right solution.
33. Switch Technologies . If you are having problems with one particular technology it might be worth dumping it and switching to a different technology.