Problem Solving for Programmers: a Neglected Topic?
How often have you heard this story... it may be you, or someone you knew in class... This person has no problem picking up syntax of a new programming language and even got the quirks of the language down. But when it comes time to write an actual program for an assignment, s/he has ZERO ideas about how to proceed. Just completely blanks out. Attempts to help with hints like "you need a loop", "you need a variable for X" results in one or two lines of code... and nothing else.
Sounds familiar? This programmer never actually learned to problem-solve. S/he can learn things by rote, knew all the syntax, keywords, commands, etc. But has no actual understanding of the material. S/he would do great in a quiz or test, but fail completely on projects (or essay questions, if it's not programming).
To badly paraphrase Sherlock Holmes' "You see but you do not observe", what we have here is a case if "you recall but you do not comprehend".
I taught myself BASIC when I was about 11 and I have the curiosity to basically teach myself and continue experimenting with programming and accomplish some things in the decades since. I can problem-solve. Maybe not like lightning-fast for programming contests, but well enough to pass a few problems on Hackerrank and such.
But back to the problem... Can you teach someone to program? But as the example above shows, that's the wrong question to ask. What we should be asking is... can we teach people to problem-solve via programming?
And let's just say, a lot of non-programmers don't understand programming, or what programmers do, at all. They expect programmers to be given a specification or even a vague idea, close their eyes for a few seconds, have an "aha!" moment, and start to furiously type on a keyboard... and minutes, hours, days, or months later, EUREKA! A finished app.
That's completely horse puckey.
A problem solver will 1) understand the problem (or ask for details if something was not clear), 2) break the problem down into solvable pieces, 3) plan how to accomplish each piece, and 4) able to combine them into an overall solution to achieve the task/goal. There will be MANY failures along the way. Dozens, hundreds, or more of bugs, typos, and more will be squashed before the code is finished, and even then, there will be improvements later.
The difference between a novice problem solver and an expert problem solver is the speed at which some steps were performed. An expert problem solver can probably do a few of the steps in his/her head. An expert problem solver already knows how to approach a problem, how to break them down, how to solve individual parts, or at least, get started. So to a novice, it would appear as if the expert already has the solution and is ready to start coding. That is a misunderstanding. The expert problem solver simply has more tools in his or her toolkit for problem-solving. But the process is the same.
Most of "programming" is actually spent on "planning", probably to the ratio of 4:1 or even 5:1. That's right, actual programming is only 25% or even 20% of overall time spent. Though that does not include debug time.
Keep in mind that programming is an iterative process. You run something, it doesn't quite work. You take that feedback and you change a few things, try again. And you will repeat this process dozens, even hundreds of times, until you get the right result. Even expert problem solvers probably won't be able to create a perfectly running program on the first try unless it's extremely simple.
So what's the takeaway from all this blabbing?
FAIL FAST, SUCCEED FASTER. (yes, I know it's more about management, but programming is the same idea... iterate faster)
Do not be afraid to fail if you learn from it. Experiment with programming, play what-if scenarios. What if I change this, what does this do, can I combine this and that... With a computer, you get the results almost instantly. It is the only way you will gain "more tools" in your problem-solving toolset... by solving problems.
But how to get started? Apply G. Polya's problem-solving principles. Remember, we are looking for the PLAN to obtain a solution, not the solution itself just yet.
And we will run into failures along the way. MANY of them.
And we will get feedback quickly. And iterate to a better plan.
And we will solve it.
AND LEARN FROM IT.
Don't be afraid to fail... if you learn from it.
Sounds familiar? This programmer never actually learned to problem-solve. S/he can learn things by rote, knew all the syntax, keywords, commands, etc. But has no actual understanding of the material. S/he would do great in a quiz or test, but fail completely on projects (or essay questions, if it's not programming).
To badly paraphrase Sherlock Holmes' "You see but you do not observe", what we have here is a case if "you recall but you do not comprehend".
I taught myself BASIC when I was about 11 and I have the curiosity to basically teach myself and continue experimenting with programming and accomplish some things in the decades since. I can problem-solve. Maybe not like lightning-fast for programming contests, but well enough to pass a few problems on Hackerrank and such.
But back to the problem... Can you teach someone to program? But as the example above shows, that's the wrong question to ask. What we should be asking is... can we teach people to problem-solve via programming?
And let's just say, a lot of non-programmers don't understand programming, or what programmers do, at all. They expect programmers to be given a specification or even a vague idea, close their eyes for a few seconds, have an "aha!" moment, and start to furiously type on a keyboard... and minutes, hours, days, or months later, EUREKA! A finished app.
That's completely horse puckey.
A problem solver will 1) understand the problem (or ask for details if something was not clear), 2) break the problem down into solvable pieces, 3) plan how to accomplish each piece, and 4) able to combine them into an overall solution to achieve the task/goal. There will be MANY failures along the way. Dozens, hundreds, or more of bugs, typos, and more will be squashed before the code is finished, and even then, there will be improvements later.
The difference between a novice problem solver and an expert problem solver is the speed at which some steps were performed. An expert problem solver can probably do a few of the steps in his/her head. An expert problem solver already knows how to approach a problem, how to break them down, how to solve individual parts, or at least, get started. So to a novice, it would appear as if the expert already has the solution and is ready to start coding. That is a misunderstanding. The expert problem solver simply has more tools in his or her toolkit for problem-solving. But the process is the same.
Most of "programming" is actually spent on "planning", probably to the ratio of 4:1 or even 5:1. That's right, actual programming is only 25% or even 20% of overall time spent. Though that does not include debug time.
Keep in mind that programming is an iterative process. You run something, it doesn't quite work. You take that feedback and you change a few things, try again. And you will repeat this process dozens, even hundreds of times, until you get the right result. Even expert problem solvers probably won't be able to create a perfectly running program on the first try unless it's extremely simple.
So what's the takeaway from all this blabbing?
FAIL FAST, SUCCEED FASTER. (yes, I know it's more about management, but programming is the same idea... iterate faster)
Do not be afraid to fail if you learn from it. Experiment with programming, play what-if scenarios. What if I change this, what does this do, can I combine this and that... With a computer, you get the results almost instantly. It is the only way you will gain "more tools" in your problem-solving toolset... by solving problems.
But how to get started? Apply G. Polya's problem-solving principles. Remember, we are looking for the PLAN to obtain a solution, not the solution itself just yet.
And we will run into failures along the way. MANY of them.
And we will get feedback quickly. And iterate to a better plan.
And we will solve it.
AND LEARN FROM IT.
Don't be afraid to fail... if you learn from it.
Comments
Post a Comment