2.6. Learning to Solve Problems

This section might have been placed earlier, but by placing it here, you should realize that you will have a lot of data to deal with.

The manner in which you deal with all the data and ideas is very important for effective learning. It might be rather different than what you needed if you were in a situation where rote recall is the main important thing.

Different learning styles mean different things are useful to different people. Consider what is mentioned here and try out some approaches.

The idea of this course is not to regurgitate the notes, but to learn to solve problems (generally involving producing a computer program). In this highly connected and wired world you have access to all sorts of data. The data is not an end in itself, the question is doing the right things with the tools out there.

In this course there is a lot of data tied into syntax and library function names and .... It can seem overwhelming. It need not be. Take a breath.

First basic language syntax: When learning any new language, there is a lot to take in. We introduce C# in chunks. For a while there will always be the new current topic coming. You do NOT need to memorize everything immediately!

• Some things that you use rarely, you may never memorize, like, “What is the exact maximum magnitude of a double?” At some point that might be useful. Can you find it? It happens to be in a table in Miles. It is also in online .Net documentation that you can Google or bookmark.
• Some things you will use all the time, but of course they start off as new and maybe strange. Knowing where to go to check is still useful but not sufficient. For much-used material that you do not find yourself absorbing immediately, consider writing down a summary of the current topic. Both thinking of a summary and writing help reinforce things and get you to remember faster. Also, if you have the current things of interest summarized in one place, they are easy to look up!
• If you need some syntax to solve a simple early problem, first try to remember the syntax, then check. With frequently used material with this sort of repetition, most everyone will remember most everything shortly. If there are a few things that just do not stick, keep them in your list. Then go on to new material. The list of what you need to check on will keep changing as you get more experience and get to more topics. If you keep some of the old lists, you will be amazed how much stuff that you sweated over, is later ho-hum or automatic.
• Earliest exercises should have the general steps needed pretty apparent, and you can just concentrate on translating simple ideas into C# syntax (likely concentrating on the material most recently introduced). In this case the focus is mostly on syntax.

Memorizing syntax is not going to directly get you to solve real problems. In any domain: programming, construction, organizing political action, ..., you need to analyse the problem and figure out a sequence of steps, knowing what powers and resources you have.

For example with political action: if you know demonstrations are possible in front of City Hall, you can make a high-level plan to have one, but then you have to attend to details: Do you need city permission? Who do you call? ... You do not have to have all that in your head when coming up with the idea of the demonstration, but you better know how to find the information allowing you to follow through to make it happen.

With programming, syntax details are like the details above: not the first thing to think of, and maybe not things that you have memorized. What is important to break down a problem and plan a solution, is to know the basic capacities you have in programming. As you get into larger projects and have more experience, “basic capacities” will be bigger and bigger ideas. For now, as beginners, it is important to know:

• You can get information from a user and return information via keyboard and screen.
• You can remember and recall and use information using variables.
• You can deal directly with various kinds of data: numbers and Strings at this point.
• There are basic operations you can do with the data (arithmetic, concatenating string, converting between data types).
• At a slightly higher level, you might already have the idea of basic recurring patterns, like solving a straightforward problem with input-processing-output.
• You will shortly see that you have more tools: decision, repetition, more built-in ways to deal with data (like more string operations shortly), creating your own data types....

At slightly more detailed level, after thinking of overall plans:

• There are multiple kinds of number types. What is appropriate for your use?
• There are various ways of formatting and presenting data to output. What shall you use?

Finally, you actually need to translate specific instructions into C# (or whatever language). Of course if you remember the syntax, then this level of step is pretty automatic. Even if you do not remember, you have something very specific to look up! If you are keeping track of your sources of detailed information, this is hopefully only one further step.

Contrast this last-step translation with the earlier creative organizational process: If you do not have in your head an idea of the basic tools available, how are you going to plan? How are you going to even know how to start looking something up?

So far basic ideas for planning a solution has been discussed, and you can see that you do not need to think of everything at once or have everything equally prominent in your brain.

Also, when you are coding, you do not need to to have all the details of syntax in your head, even for the one instruction that you are dealing with at the moment. You want to have the main idea, and you want to get it written down, but once it is written down, you can make multiple passes, examining and modifying what you have. For example, Dr. Harrington does a lot of Python programming, where semicolons are not needed. He can get the main ideas down in C# without the required semicolons. He could wait for the compiler to stop him on every one that is missed, and maybe have the compiler misinterpret further parts, and give bogus error messages. More effective is having a list of things to concentrate on in later rounds of manual checking. For example, checking for semicolons: Scan the statements; look at the ends; add semicolons where missing. You can go through a large program very quickly and efficiently doing this and have one less thing to obsess about when first writing.

This list of things-to-check-separately should come from experience. Keep track of the errors you make. Some people even keep an error log. What errors keep occurring? Make entries in things-to-check-separately, so you will make scans checking for the specific things that you frequently slip up on.

This things-to-check-separately list, too, will evolve. Revise it occasionally. If Dr. Harrington does enough concentrated C#, maybe he will find that entering semicolons becomes automatic, and he can take the separate round of semicolon checking off his list.

What to do after you finish an exercise is important, too. The natural thing psychologically, particularly if you had a struggle, is to think, “Whew, outa here!!!!”

On something that came automatically or flowed smoothly, that is not a big deal - you will probably get it just as fast the next time. If you had a hard time and only eventually got to success, you may be doing yourself a disservice with “Whew, outa here!!!”

We have already mentioned how not everything is equally important, and some things are more important to keep in your head than others. The same applies to all the steps in solving a possibly long problem. Some parts were easy; some were hard; there may have been many steps. If all of that goes into your brain in one continuous stream of stuff that you remember at the same level, then you are going to leave an awful lot as just unimportant and basically useless (so why do the problem anyway?), or have a brain very stuffed with things you want to recall.

What is important? The most obvious thing you will need at a higher level of recall is what just messed you up, what you missed until doing this problem: After finishing the actual problem, actively follow up and ask yourself:

• What did I get in the end that I was missing initially? What was the connection I made?
• Does this example fit in to some larger idea/abstraction/generalization in a way that I did not see before?
• How am I going to look at this so I can make a similar connection in a similar (or maybe only partly similar) problem?
• Is there a kernel here that I can think of as a new tool in my bag of tricks?

Your answers are the most important things to take away. The extra consideration puts them more in the “priority” part of your brain, so you can really learn from your effort. When you need the important ideas next, you do not need to play through all the details of the stuff you did to solve the exact earlier problem.