All software systems sometimes crash. Certain software languages leave behind a core dump an image of the state of the program when it went wrong - allowing programmers to debug the program and find the fault. We must examine our own core dumps if we wish to improve ourselves.

When everything is working you dont think about self-improvement. This makes sense because youre happy, everything is as it should be, so why stop and think. If it aint broke, dont fix it. We only think about improving our self in some way when we know there is something wrong. But its no good just thinking that we must change because something is not right: we must think about what is wrong. We must look inside our self and examine our thoughts, behaviour, and aspirations. We must be critical. We must be honest.

When you fall down from some crisis in your life it is not enough to pick your self up, dust your self down and continue your journey. The software program contains a bug. Sooner or later, youre going to fall down again. It does take strength to pick your self up each time, and one can applaud such strength, but we admire people who can learn, adapt and succeed from a personal crisis. But where do we begin to look for answers: to learn lessons from our mistakes? We must look at our personal core dumps.

In software a core dump is a computer binary left behind on the operating system when a software program stops running in some unexpected or catastrophic way. Software programmers examine the binary to find the answer to why the program malfunctioned. The reason a programmer finds the core dump so beneficial, is because the binary is an exact record of the state of the program as it was when it crashed. It also contains the history if the program; the steps that caused it to crash. If some function of the program isnt in the core dump, then it can be known for certain that the function didnt cause the problem, but all functions found in the core dump must be looked at. The programmer starts at the end-point and will work his way back from there. He will find out which function called what other functions. Eventually hell find the function that didnt work as it should have. Most often, the function at fault is some little piece of code that someone wrote but thought so trivial that he thought it didnt need testing. Furthermore, the function at fault is often relied upon by many others functions of the program.

So how does this relate to real people? The term "core dump" is not just some computer jargon. Before computers, the term "core dump" meant complete account of a human's knowledge on some subject. We all have a core dump. Its our brain, our thoughts, our emotions and our dreams. Of course, being human beings, our core dumps are far more complex than any software written today.

To examine your core dump you need to examine your inner self. But how to find it? The answer is provided by the paragraph or so above: a core dump is an exact record of the state of the program as it was when it crashed. For human beings, exact record equates to honesty. Computers never lie: they report things as they are. You must not lie to your self. Begin by asking the question Why was I not happy? Dont give an answer that youd like to hear, or you feel will let you off the hook. Be critical and dont lie to yourself: find the real answer. Once you have that answer then look further back. What led to this unhappiness? Again, be truthful. Keep going back until you can go no further. Once there, you have found the malfunctioning "function". Only when youve found the real problem can you begin to fix it. And just like a complex, million-line piece of code youll probably find that fixing that one small function will prove beneficial to many other parts of the system.