How to cope with error

A problem is a gift that will take me to an unknown area.

Read error log meticulously

In many cases, clues are here. I could go search hard in wrong field, if I look over the error log and presume the problem.

Try to get a specific and deep error from the source.

Search the log, others would have faced the same situation.

Surely an error log is not perfect. It's from a human that developed the program. But that doesn't mean it's not important.

Separate the problem

Split the process into small steps. Check if each step is right.

If I split enough and each step seems to have no problem. Then the step I think is right is wrong.

Reassure each step by reproducing the step in other environments.

Think about a cause

Think what changed now if it worked before. An environment, machine, or version may differ.

In case of a project, go back to a past and run there.

In case of a cli command, think that I may not have recognized something running under the command, arguments, default values, environment variables.

Check out the command on other machine just in case. The command might be running on top of numerous dependencies that I can't think of.

Find a reason why it works and why not.

If an article says that it should work but it doesn't, compare the situations.

Check again that I missed something on the article.

An article was written in the past. Something might have changed and it affects. Find out what's different. An author presumed something at the time of writing.

An article can be misleading, having typo, partially updated or simply wrong. A human may have written it.

If I don't know well on an issue, it's hard to tell what's wrong. Need to learn.

If I have a mental model how it works, do a simple test to examine it.

Create a simple project that proves how it works. If it works that way, then add something step by step toward a final project.

There is a reason that it's not working. I just couldn't find it yet.

If I found something suspicious, simulate the problem.

Then I can assure that was the problem.

Too complicated, write down every move case by case.

Writing down makes it easy to narrow the problem scope.

It's hard to think complex conditions at the same time. It mixes things up. Outsourcing checking condition to a note, then concentrate on doubting each step.

Write down by case.

Additionally, if a problem goes several days, the note will be a big help.

Shorten a feedback loop.

If I don't know exact cause, I might need to do some experiments by different variables. Finding a way to shorten each experiment will reduce overall time.

If I found detour, consider it, but be cautious.

Some problems are simply too big for my current situation. A detour would be reasonable. If the detour doesn't feel quite right, make a note of the situation and any suspicions.

When using library or frameworks, it may not support anymore, or there may be a bug inside, or os problem.

However, don't jump to this conclusion so easily. Concluding it means closing an interest on the problem.

If I'm spending too much time without making progress, ask others.

Simply talking to someone else can be helpful. Sometimes the solution comes out while I'm talking. Organizing my thoughts to explain them to others may trigger a good idea.

A response from someone else might provide a new perspective.

Ask in verbal or in written depending on the situation.

Follow a guide below for preparing questions.https://susemi99.gitbook.io/howto-for-beginners/2

How much time should I spend for working on this alone? I think about 1 hour might be enough, although it depends on the problem.