Tips on how to break down a programming problem
•Download as PPTX, PDF•
1 like•850 views
The document provides tips for systematically breaking down a problem into steps before attempting to solve it. It recommends identifying the overall problem and goal, breaking the problem into smaller steps, working through examples using pseudocode, coding each step individually while testing, and seeking help if stuck on concepts rather than searching for full solutions. The key is to think through inputs, outputs, necessary logic and tools to transform one to the other like a computer in a step-by-step manner.
Recommended
More Related Content
Similar to Tips on how to break down a programming problem
Similar to Tips on how to break down a programming problem (20)
More from Rona Chong
More from Rona Chong (8)
Recently uploaded
Recently uploaded (20)
Tips on how to break down a programming problem
- 3. omg
- 4. omg what does it all mean
- 5. omg what does it all mean
- 7. Solution: Go Google It “how to write a function to add a node c”
- 8. Solution: Go Google It “how to write a function to add a node c” NONO NO
- 9. ● You don’t get a chance to reach a solution on your own. ● You don’t necessarily understand the example you see.
- 11. Solution: Don’t Google the answer. Google the concept. (Google the answer as a last resort, and make sure you understand & can reproduce the answer on your own) (If you can’t, then ask for help.) “What is a linked list” “C structures” “Malloc” “memory” “How do you store a string in a node”
- 14. A set of steps: ● Identify: What is the problem? What is being requested, or the goal? ● Break the problem down into steps ● Pseudocode & work the problem out with example inputs. ● Coding: Go step by step. (Don’t code it all at once, and test each step). ● Something confusing you? ○ Do not look up THE solution. ○ Identify what you don’t know, then fix your knowledge gap. ● You’re stumped - but you’ve tried to break down the problem. Look up a solution and take stock of what you missed. ● Take the time to understand each line of code you write. ● After help or looking up the answer, make sure you can reproduce the solution on your own.
- 15. ● Think about input to output. What inputs do you have? What are their types? What outputs do you want? What are their types? What tools do you have to transform your input to output? ● Logic flow ● Mathematical operations ● Functions
- 16. A set of steps: ● Identify: What is the problem? What is being requested, or the goal? ● Break the problem down into steps ● Pseudocode & work the problem out with example inputs. ● Coding: Go step by step. (Don’t code it all at once, and test each step). ● Something confusing you? ○ Do not look up THE solution. ○ Identify what you don’t know, then fix your knowledge gap. ● You’re stumped - but you’ve tried to break down the problem. Look up a solution and take stock of what you missed. ● Take the time to understand each line of code you write. ● After help or looking up the answer, make sure you can reproduce the solution on your own.
- 17. Ask for help.
Editor's Notes
- In the spirit of peer learning, wanted to share my personal approach to coding problems. Everyone’s approach is going to be different, but thought it would be good to exchange perspectives.
- So this is an example of the type of awesome and cool projects we get at Holberton. It says to write a function that allocates a new node and link it to a list.
- So this is an example of the type of awesome and cool projects we get at Holberton. It says to write a function that allocates a new node and link it to a list. OK, that’s cool… So sometimes, we get a primer on a new concept, but we still may not understand everything, because we haven’t dealt with it in detail yet, like “what is all of this”, “dont really know what to do”
- When we’re new to a concept--maybe someone’s given us a primer on it, but we still haven’t gotten our hands dirty with it--it can seem a little overwhelming Pretty much like gibberish. Like “what does it all mean”? “Oh shit”
- So what do we do at this point?
- So what do we do? We can go Google it!
- We could google, actually, “how to write a function to add a node in c”, and get the answer… which is pretty cool.
- Except, I actually wouldn’t recommend doing this. Not because googling the exact solution is always absolutely wrong, but I would just be wary of Googling the answer right off the bat because there are a few pitfalls involved. Why: Googling the exact solution is not always absolutely wrong, but there are several pitfalls: You don’t get a chance to practice or learn how to reach a solution on your own. You find a solution but you don’t necessarily understand how it works.
- The first issue is that If you automatically look up the solution every time, you’re not giving yourself the chance to develop your solution by yourself. You can’t always depend on the solution or tutorial being available, so it’s important to be able to break a problem down yourself. The other part is you may look at some code and think you understand it, but without going through the nitty gritty of it yourself, you lack a true understanding of the code. And then you might not be able to do it on your own,which can really hurt you down the road. [In a job, you’ll come across problems that people haven’t done before. (For instance, some of us might have come across this when we did the shell). In a job interview, maybe you’ll be able to look online for a solution. But not being able to explain what your code does and how your code works will not impress. As a lack of understanding builds up, you will lose more and more time to randomly changing things in your code and crossing your fingers/hoping it works. If you force yourself to try to integrate of new concepts, the solution will come to you much more quickly. And, you’ll understand the solution, because you came up with it.]
- The “I don’t really know what I’m doing” syndrome: potentially lovable, but not advisable The goal is to move out of this zone, not stay in it.
- It can be OK to look up the answer But make sure you understand, then close the window and try it yourself.
- What this starts to get at is the idea that we should try to break the problem down into parts and understand the problem, instead of looking up the answer right away.
- So, Parse the problem Break it down systematically Like a computer Basically be like a computer, which is easier said than done, but we have a set of suggestions to help with that.
- The first step is to identify the problem. As in, Really try and understand first what is being asked of you. Then take that problem and break it down into steps You don’t necessarily need to know how to do each step now, but you need to know what you are trying to do conceptually. Pseudocoding helps define your plan of action (in a notebook). And then you can start to figure out the how each of those steps can be achieved: Something that I find helpful is trying to work out the problem with example inputs.
- So actually, whenever we are given a problem, we know some sample inputs. We can see them in terms of their type in the prototype; and we can see specific values our function is called with in the main function. Helps me to think about what we start out with and what we want to end up with. A lot of times a programming problem can be reduced to input and output, and a series of operations on the input to achieve the output. So: input = Pt. A, output = Pt. B, tools = our path to get from Pt. A to Pt. B. Input to output Problems in programming can often be reduced to what you’re given, and what you need to produce Try to think about input and output, and the series of operations needed to transform or use your input to reach the desired output. Think about what tools you have. What inputs do you have? What are their types? What outputs do you want? What are their types? What tools do you have to transform your input to output? Control logic flow Mathematical operations Functions
- Once you have the solution, start coding it step by step. Don’t code it all at once, and test each step before moving on. If something feels confusing: Try not to look up THE solution. You can look up minisolutions, as in solutions for each step you’ve broken the problem into. Take it as an opportunity, because when you’re confused, you can identify what you don’t know, and then fix your knowledge gap. Google concept queries. Finally, if you’ve tried to break the problem down, but aren’t able to piece it all together, you can go ahead and look up a solution. Because now you know what you’ve thought of and you can identify what you didn’t think of, which is good for you to recall in the future. A few more things: Take the time to understand each line of code you write. After help or looking up the answer, make sure you can reproduce the answer on your own.
- The last thing is don’t be afraid to ask for help - I think it’s easy to feel like you’re copping out if you ask for help, but what really matters if you ask for help to understand things, and not to reach the answer. There’s a difference in the goal.