BlogicBlog: View from the trenches

The blog about Java and XML with focus on troubleshooting issues and tools.

Monday, September 19, 2005

My take on "problem solving skills"

Permanent article link

cynicalman asks what the "problem solving skills" in a job description actually mean and then tries to discover and blog the answers.

I do not actually agree that his first discovered rule is actually "a skill" (I think it is more of a test procedure), but the question asked does require a thought.

I was frequently told that I have good problem solving skills. So, here is my quick take on what those skills are:

Being able to quickly deduce a structure and meaning from the given examples or behaviour
For example, my co-worker was having a problem with a Fortran program. I haven't seen Fortran before, but was able to figure out the control structure rules on the fly and see where the bug was. Another example would be to take a program with an unfamiliar menu structure (or a familiar Microsoft one) and quickly find where a particular option could be.

Knowing how to ask question - of yourself and others - that would partition the problem space
So, you say the server has crashed? is not a good question. How about When you say the server crashed, did the program exit completely? If not, was it rather just very slow and/or returned to normal a while later? It is really a couple of questions here, but the idea is to split the possible problem space into segments and decide which segment to keep working with. Similarly a good question would be: If this was caused by a network problem, how/where/when would it show up? Which log or trace file do I need to check to confirm or reject this?

Knowing how to convert data into information
Getting a 3 page long java thread dump is a (bad?) luck. Knowing how to read that thread dump to identify what the program was doing at the time and what it was _not_ doing is a problem solving skill.

Being able to manipulate large datasets and extract required individual entries
To me, this covers not being scared by 2GBytes access logs when I search for a problem behaviour pattern. It also covers knowing the tools to slide/dice/reconstruct the data sets.

Having a toolkit and knowing it well
At the moment, my toolkit is Vim with couple of plugins for editing and RegExp work, Ethereal for network, FileMon/RegMon/TcpMon from SysInternals for Windows troubleshooting, XMLStarlet for XML files, and, of course, Cygwin for its full toolchain. I have also written custom programs, mostly for complex data extraction. Finally, I use GraphViz for visualization of my extraction results. One of the things that frustrates me most is a person reading a log file in Notepad. What can they do with it except looking at it one line at a time? No highlighting, no place marks, no way to interactively clean it up by regexp deleting some unrelated sections.

And, above all, not giving up
Most of the situations can be troubleshooted successfully. Especially if you can reproduce it, insert trace statements or do other developer level modifications. If you think you hit a writer's block of troubleshooting, use the same techniques writers do (try anything, switch attention, define next action, etc.)

Comments, thoughts, references?

BlogicBlogger Over and Out

0 Comments:

Post a Comment

<< Home