> Critical thinking is required to come up with a solution to a unique, never solved before, problem.
1. Perhaps I'm being slightly too liberal with my use of the word rote. But by "rote programming", I mean the sort that requires no understanding of anything beyond CS1 concepts, the domain and your toolset. The programs are very simple and sometimes hacky, but get the job done (e.g. "Move all those files over there and then watermark them using this snippet I found on SO and then add them to the database so they show up on the website").
2. Even for many professional software engineers, often times most of the critical thinking is probably about the domain as opposed to the programming. Most people aren't (or shouldn't be) coming up with truly unique algorithms/approaches; rather, they are mapping new problems to tried-and-true techniques usually already implemented as libraries.
So it's possible to solve new problems (in the sense of your domain) with rote programming (of the sort described above), if all the critical thinking is about modeling the domain as opposed to the software.
Of course, every once in while, the "tried and true" technique is a piece of CS that only an educated engineer has heard about/knows how to correctly use. But my point was that there are lots of problems you can solve without getting to this level.
> Most people aren't (or shouldn't be) coming up with truly unique algorithms/approaches
Rote approaches to solving problems are great when the problem is very well defined and repeatable (need to fill an order for a coke and two fries). However, as soon as the mapping changes even slightly, Rote learning[1] and, in my opinion, Rote programming don't work so well.
Even if every tool ever required to implement a software solution (algorithms/approaches/etc.) was available we still need to map a given problem to one or more solutions. This is why I wrote "Writing a program very rarely has the exact same context by which a rote learner can map a solution to."
When I lectured, students could "get" what tools were available to them. If I asked them to describe a sorted list, they could in great detail. However, when given a generic problem, it was a lot harder for them to select from the tools available to them ("Oh, so to speed up this programing, I could use a sorted list"). That is the critical thinking part.
[1] "Umm, I've already told the register that you are giving me 10 dollars so you will need to give me that instead of $10.50". - This happened to me and is a big signal that the person had done rote learning their whole life.
1. Perhaps I'm being slightly too liberal with my use of the word rote. But by "rote programming", I mean the sort that requires no understanding of anything beyond CS1 concepts, the domain and your toolset. The programs are very simple and sometimes hacky, but get the job done (e.g. "Move all those files over there and then watermark them using this snippet I found on SO and then add them to the database so they show up on the website").
2. Even for many professional software engineers, often times most of the critical thinking is probably about the domain as opposed to the programming. Most people aren't (or shouldn't be) coming up with truly unique algorithms/approaches; rather, they are mapping new problems to tried-and-true techniques usually already implemented as libraries.
So it's possible to solve new problems (in the sense of your domain) with rote programming (of the sort described above), if all the critical thinking is about modeling the domain as opposed to the software.
Of course, every once in while, the "tried and true" technique is a piece of CS that only an educated engineer has heard about/knows how to correctly use. But my point was that there are lots of problems you can solve without getting to this level.