[ Previous entry: snippet . DbRepair ]
[ Next entry: NF . outsourcin' Star Wars ]
thoughts . problem solving
Sometimes, if not always, it is so hard to talk someone about systems and problem solving especially if that someone is lSensitive, lEmotional and cPersonality = STRONG. To make things even harder, these are the persons that are often close to us, persons we hold dear. Closeness is oftentimes quantified by emotions but the use of such in this discussion, stops there.
A great deal of our life lessons, we learn through our work. And in database-related programming, software development and system analysis humans can learn a lot. In fact the approach use in the whole software development process if applied to real life situations could make this greed-infested/disorganized/unsystematic world a better place to 'interface' and connect with.
One can view life as a big problem (but not necessarily negative) that needs to be solved or 'lived' if you prefer such word. In every step of your life, directly or indirectly, you create means to solve a problem, but first and the most important aspect of all; you must know what the problem _really_ is. This is where you question existence, the why's of things and in such thing as complicated as life these questions can stretch far beyond places Hubble's sight can even reach in 7 cybernetic lifetimes.
Most often, a big problem is composed of little problems branching out to another set of nodes and child problems.
Now, one's approach to solving such things would depend on how you, with your experience, view things. You can view it as 'cut-the-root-of-the-problem' and the nodes will be flushed as well .OR. you can do little node and leaves at a time until slowly and slowly you are tackling and conquering the problem subset before marching to the next level/node. That or the other or the combination of both or A then B or B then A, the combination is endless, can bring you to the doors of the solution. The process in itself can be views as a means of solution to start with.
Now let's go back to that arguing/talk with someone we first tackled on Paragraph-01. You can't expect to solve a problem if you're attitude is like this: while discussing Problem v1.117.1256725, and you feel like you with your intelligence cannot 'fight through' the parameters of that problem starts randomly accessing bits of information that will pull Problem v1.291.1837125, Problem v2.129.28341245 and countless others.
Solve problems ONE by ONE, it doesn't matter if you're doing it the LIFO or the FILO way, or the stack or queue approach. Even CPUs tackle each program line by line. Even Superman to be efficient follows this principle. Spiderman too, he rescued his girl first then maneuvered towards the dangling train. And I don't believe hyperthreading on a 512-bit computer with 7777500GHz could defy this principle.
Talking to someone who tends to bring all problems forward instead of dealing with it one by one frustrates me. Add more nFrustrationCounts if that someone gets too emotional, looks for other holes instead of concentrating on the problem at hand and too close minded enough to see things. We're talking about oOBJECTS here so things must be dealt with objectively and lEmotion should be set to .F.
Add the nCount(ProblemOccurence) too. If the problem keeps repeating and repeating all over again nFrustrationCount increases. There must be something wrong with the system that needs to be addressed instead of being to emotional and close minded to even discuss the problem.
And in every thing/activity/process they do, humans should learn to evaluate and reflect on things.
But that my friend is another story for now and I still have to work on how to prevent database corruption during power fluctuations.
In case you want to know what the problem is about... we'll I tell you it's about spoon and forks.
Yes really. No kidding this time. Such a 'near-to-null' related matter, right?
Disclaimers are for castrated EARTHLINGS.
Powered: GREYMatter | GM-RSS