My take on "problem solving skills"

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

Weblogic 9: support aspects

Vinny Carpenter reviews Weblogic 9. He mentions many features, but forgets what I think will be a very interesting supportability aspect: Diagnostic Service

Up to the 9.0 release, one of the big support headaches was that for many of the subsystems, the running state was not exportable for analysis; that a transaction running through the system would have different IDs in different subsystems with no way to associate them.

Basically, it was often impossible to tell what the system is actually doing without writing custom patches, which the customer may or may not be willing to install in the production system.

The Diagnostic Service was designed to solve exactly that. I don't think it provides for it all out of the box, but the hooks certainly are there and I am hoping to see a community form around this service within or outside of BEA.

Technorati Tags: WebLogic

BlogicBlogger Over and Out