There are two basic ways of teaching programming -- or pretty much anything, come to that. You can either start with the building blocks and build up, or you can start with some self-contained problems and then pull them apart. In practice, of course, you need to do both, so it comes down to a question of emphasis.
My preferred approach has always been to start by solving problems, as far as possible. Here are my reasons.
Problems are more interesting
Problems don't have to have global consequences to be interesting. A maths problem like "John has 9 sweets. How can he share them equally between himself and his two friends?" is intrinsically more interesting (and more challenging) than "Divide 9 by 3".
In the same way, a problem like "Check if this person is over 13 years of age" is more interesting than "Get the computer to deduct someone's date of birth from today's date."
Obviously, at some point you will need to teach your students how to perform that calculation. I am simply contending that by starting with a problem, you are giving them a reason to actually want to.
Students achieve something meaningful right away
Obviously, we can discuss what is meant by "meaningful", but if you take a problem like the one about age, above, it involves students applying programming methods to an actual problem. You could start them off by spending a lesson or two on how to use dates in calculations, but even if they understand it fairly quickly, I'm not sure whether they will have the same sense of achievement.
Problems provide hooks
It's very hard to learn abstract concepts straight away. Although when Piaget talked about concrete learning he was referring to very young children, I believe that the concept applies to anyone of any age when they are starting something they are not familiar with.
Having a problem-to solve is a way of providing a mental hook, or set of hooks, on which to hang the concepts you intend to use.
Abstraction, Decomposition and Pattern Recognition are easier
These three components of computational thinking are easier to apply, and to teach, if you start with a real problem. Take the age problem, above. A problem for a small business like "Should I issue a reminder to pay my invoice?" is, essentially, the same problem. It involves calculating whether the difference between today's date and the date that the invoice was issued is greater than 30 days (or whatever the business's payment terms are). I think it's easier to draw this out from a problem-solving approach than with just dealing with the raw components.
Problem-solving provides building blocks
The main strength of starting with the raw components, as it were, is that you can use them to build up more complex programs. But you can do the same by starting with a problem-solving approach, and in my view it makes it much more interesting. Take the age problem (again). An interesting extension would be to say. "How could you make the program handle a situation in which, at the time of filling in the online form, the person is under 13, but by the time they actually start, they will have turned 13?"
Pseudocode is easier to apply
In my experience, it's easier to write, and to teach kids to write, pseudocode if you have a real problem in mind than if it is simply an abstract, academic, exercise.
Problem-solving makes it easier to use a spiral curriculum approach
Bruner's concept of the spiral curriculum refers to the revisiting of problems at a deeper and more complex level. It's much easier to do so if you have a reasonably meaningful problem in the first place. In fact, the second problem introduced under the heading of building blocks, above, is a simple example of the application of the spiral curriculum.
As I said at the start, you have to teach both the raw components and how they might be applied, but I think that starting with a problem makes it much easier to learn.
For more articles like this, along with how to's, competitions, freebies, and other good stuff, sign up to the Digital Education newsletter, which is now in its 16th year!