Skip to main content

Problem Solving - Refactored

I am going to outline how I approach problem solving. The relative importance and the amount of effort/time required for each is stated as a percentage beside each topic. I borrowed some idea from George Polya's How to Solve It

Thoroughly Understand the Problem (30%)
When encountering hard problem , you need to deeply understand the problem at hand. Take a paper and list down all known facts and data and what the question is trying to find. Sketch out the problem if applicable. Visualize the problem in your head. A lot of times, we only have to understand the problem well, then the solution will obvious.

Have a Plan (20%)
You need to have an outline of how you are going to tackle the problem. You need to have a logical pathway that will ultimate produce outcome (nothing to do with coding syntax yet). Without a plan, you are just randomly poking around and got lucky. No hard problem ever gets solved without a plan.

Plan using pseudo-code, pen & paper or flowchart. Use whatever that helps you state down the variables and logic flows.

Don't worry about building a lean/perfect solution yet. Go for the simple and most straight forward solution. Once you have a running code, only start to think about optimizing the code. Both are separate task.

For hard and complex problems that you not sure how to tackle the problem thoroughly, list down a few plan that maybe half way completed. Systematically cross out each plan that don't work. Its the only way I know.

Solve it (40%)
Here is where you turn your plan into running code. Below are some guidelines:

1. Test each logical chunks of code as soon as possible. This can let you trap any bug in as little area as possible. If you wrote a long statement without testing, one single bug requires you to debug that whole stretch of code. What if you have multiple bugs?

2. Use IRB to test check your ideas. Maybe you want to know how chars affect strings, or whether the method each is available for Strings. It is a handy tool that basically mimic the actual programs , but is isolated and more interactive.

3. Use binding.pry to know what is the state of the variable are in the middle of the code. Perhaps your variable is now a nil value. Only binding.pry can tell. Careful not to place binding.pry at the end a method or block statement, because it will be returned (ie. a nil value is returned)

4. I can't stress this enough. Take a paper and write down the variables, test condition , methods etc. Keep track of the data, condition and method as the code progress (especially useful in a loop). Try to break down problem one logical piece at a time. This significantly reduce the complexity of the problem, making it easier to solve.

5. Isolate logical chunk of code into a method, it will help your head get around the code. It is also good presentation for future readers.

6. Google for an answer online. Refer to ruby-doc.org , it is very handy.

7. Find a pattern in the potential solution. Sometimes when you write down the required solution one by one, for example, A[0] , A[1], A[2] and on and on, then you know you have to have a looping mechanism to solve your problem.

8. Once you found that the plan doesn't work , go back to step #2 and tweak your plan. However, sometimes it is better to scrap the whole plan and start over from scratch.

9. If you are stuck for too long and are frustrated. Take a break. Go for a walk or talk to people. Come back to that problem after a while. You may see it in a different way.

Review (10%)
Review your answer thoroughly as a whole. Read your code from top to bottom and picture all the working variables and methods in your head. It helps tremendously with your learning.

Think hard about how to improve your code and learn from the mistakes you made along the way. If possible, read other people's code and see how they approach the problem differently from yours.

Pitfall
Once you have become good at a topic, you tend to skip over the above steps when solving that particular topic's problem. You start to think you are a genius because you can do it in your head.
Then when progressing to something more advanced, you forget to apply all the problem solving steps. And the problem can't be solved. You start to get frustrated and give up. Don't do this. Always follow the necessary problem solving steps.

Conclusion
I think that you should only judge yourself by well you follow your own problem solving path, rather than whether the problem gets solved or not. That way, you will know , every time , that you are doing the right thing.

Problem solving is going to be painful and time-consuming. But it is worth because the learning so much more intense and lasting compared to just reading a book. I believe things will get easier as you mastered the skill of problem solving over time. Good luck !











Comments

  1. Excellent points of view. I believe I have been through all of your fails and most of your solutions. I especially have the coffee / lack of sleep dilemma. Thanks for the post.

    ReplyDelete
  2. Excellent points of view. I believe I have been through all of your fails and most of your solutions. I especially have the coffee / lack of sleep dilemma. Thanks for the post.

    ReplyDelete
  3. Great solutions! I find that exercising helps. I go for a 40 min swim and sporadically think about the problem. Frequently a solution just pops into my head.

    ReplyDelete

Post a Comment

Popular posts from this blog

My Burnout Experience

I want to share with you my experience of burning out. After registering with Launch School, I am extremely excited about my programming journey. I studied for 10 to 12 hours a day, memorizing fact, trying out practice problems, understanding programming concepts. It was fun and exciting and I love seeing myself growing from nothing in programming to something more.

After about 3 months, thing starts to change. I started noticing myself paying less attention to details. I find myself skimming through the course material. I skip "Further Exploration" in the practice problem. I am more interested to study just to pass the assessment rather than truly mastering the concept. It was a gradual burning out process but I continue to study for 10 to 12 hours a day through sheer grit. It felt like doing house chore or working a day job that you don't like.

One particular morning I woke up, and I remember this deep feeling of dread because I can anticipate that the next 10 to 12 h…

Sharing my Weakness

It makes sense to know about your weakness and do something about it. Here are my known weaknesses uncovered during my time in Launch School.

1. I don't like to refactor my code
- Your first draft will not be perfect. It works but it may not be efficient/readable/best practices. You final code will almost always be better than your first draft.
- It is easier to separate the task between writing code that works and refactor later to make it efficient/readable/best practices.
- If you refactor your code often, over time you will discover your bad habits and change it.


2. I don't like to read other people's code
- There are more good programming practices in other people than in you (especially for beginners like me).
- To be good , you need to know more than one pathways to solve a programming problem (and there are always more than one way). Then you can judge their merit.
- Reason for dislikes
   1. It is considerably harder to read code than to write one (because I can'…