Replies

It’s like trying to use a shortcut to drive through an unfamiliar city. That short cut might work, but you won’t know it without having known the longer way first.

I’m not sure I agree...this is about the age where I figured out that 9 * x = (10 * x) - 9. So I skipped 9 when I memorized the multplication table. I’m not sure that was a good thing, but it hasn’t done me any real harm.

Now...I admit I couldn’t have written it as (10 * x) - 9 in the fourth grade...and I sure couldn’t have provided a rigorous proof (not sure I could do that even now.) But I could understand the general idea.

You can only really learn the short cuts when you’ve mastered the topic.

As an educator having to teach this garbage, I agree with you.

For example, if a student can see how "make a new ten", then they can already see how to solve the problem the easier, "old fashioned" way!

Teachers at our school don't like CC at all!

You can only really learn the short cuts when you’ve mastered the topic. Using shortcuts before that inhibits the learning process because you have no way to verify if your shortcut is a valid one because you cannot compare with the longer method.

This gets at the core of why there are so many stinky computer programmers.

One must first understand exactly "what" is being done by an algorithm.

Then one can reduce the algorithm to its simplest form, i.e., get "what's done" done in the fewest possible steps.

Most of the time in the business world programmers jump in and start coding without "getting it", the "big picture" of what they are actually trying to get to happen.

This is ALWAYS going from A -> B. It's a transition from one "state" to another, final state.

What is normal today ? We would have a set of programs, starting with an initial input of some data, which is then mish-mashed six ways to Sunday to wind up with various results.

A -> C -> D -> R -> Q -> Z -> M -> W -> B

I ask them, what are you doing ? Why are you writing program R ? What is the point ?

Well, R is the flux capacitor, we have to R every D. The D's all have to be R'd.

I ask, do you understand the whole process ? Yes, they know that there are many steps to the whole process. But rather than question anything, they dutifully focus microscopically on their D -> R program. And even at that, they struggle mightily. They write some code. Their changes don't work. They are baffled by the code they just wrote.

The whole key, of course, is really understanding, having a completely clear picture, of what it means to A -> B. Exactly what IS A, exactly what is B, exactly what are the differences. Then how do we most efficiently make the transformation - hint, there may be intermediate steps that are very efficient, that provide for a robust program that can restart anywhere in the middle, that provide a full record of the A -> B transformation, but these need to be no more than absolutely necessary to do the transformation.

Learning programming "tips & tricks", gimmicks, the latest language du jour, that's all waste and confusion. The way to become a competent programmer is to really understand the basics of math very well. Only when one really understands the "what" can one simplify the "how".