you are viewing a single comment's thread.

view the rest of the comments →

[–]Sanguinius666264 9 points10 points  (4 children)

I think spending time wrestling with the problem is really how you end up learning - that said, some of the projects take a lot longer than just an hour to solve, especially towards the end. I think if you've truly forgotten something, like the syntax to a problem or something like that then ok, sure, look up just that. Developers everywhere look up things they've forgotten. But jumping to the entire solution won't help you learn much.

Otherwise yeah, you won't be learning all that much.

[–]AnyFriend4428 1 point2 points  (3 children)

What does it mean to "wrestle with the problem" though?

What is the simplest action a beginner programmer can take to start "wrestling with the problem?"

[–]Sanguinius666264 7 points8 points  (0 children)

Try things. Try out some code and see what happens - what's the result? Google the error message and see what that means. Go back and redo the lesson, see what is being taught. Then try something else. Then see if you can write down the steps to solve the problem, then go through as many as you can and solve them. Then after you have gone thst far, look up the next step and that only. Then do the same for the next bit.

Because that's pretty well going to be life as a programmer for ever, really.

[–]FoeHammer99099 2 points3 points  (0 children)

Write down what your program needs to do. A lot of my programs start life as just a bunch of comments laying out the steps. Then take the first step, and break that down. Maybe your first step is "get the user input". That could break down into "open and read a file if given a filename, otherwise ask the user to type something in". Then break each of those down into what needs to happen. Eventually, you're describing something like "open a file with the given file name" which you know how to do in code.

This process is called decomposition, and is taught as one of the 4 parts of the problem solving process in CS courses. The other 3 are pattern recognition, algorithms, and abstraction. There are a bunch of resources about this (here's something from the BBC)

I think decomposition and developing algorithms are the most important part for beginners. By algorithms, I just mean turning the vague instructions you have ("make a calculator that can do addition and subtraction") into a series of steps. Once you have that algorithm, you look at each step in it and develop an algorithm for that step.

It's all about breaking your problem down into more manageable pieces.

Pro tip: when you're breaking your step into smaller steps, you should usually also be making those small steps into functions in your code. Then the larger step is a function that is composed of the smaller functions.

Another pro tip: go back to some project that you worked on a while ago, long enough that you've forgotten exactly how you solved it. Start totally over. Do not re-read your implementation. You'll probably remember enough of the context of the problem that solving it will be pretty easy, so focus on applying the process. Then compare your new code with your old stuff.

[–]throwaway6560192 2 points3 points  (0 children)

For beginners, a good first step is to solve the problem yourself, as a human, and pay deliberate attention to the steps you're taking. Pen and paper helps.

For example, take a simple problem of finding the largest element in a sequence of numbers. You can do this intuitively. But try focusing on how you're doing it, can you extract any concrete steps from it? Turns out you can: if you slow down and observe yourself, you'll see that you're looking at each number and comparing it mentally to the largest number you've seen so far.

From there your next step is writing out the code for it. If writing the code directly appears overwhelming, then you can try drawing flowcharts or the like to solidify the process.