One common pattern of programming teaching – especially in books and other written material, but also in in-person teaching – is the focus on the product, rather than the process.
The usual structure is: (1) Here is a problem. (2) Here is a program (involving some new construct) to solve the problem. (3) Here is a discussion/explanation of the solution and the new construct.
The problem with this is that the solution appears – apparently in one step out of the ether – in its entirety.
In novice learners, this creates the impression that this is how experts work: If you know how to program, you will be able to think for a moment, and then just write down the solution.
They struggle with coming up with a working program, and even if they have an idea, they make mistakes, run into compiler errors, have bugs in their code, and think “I am just not a good programmer”.
The fact that we all work like this – write some code, discover mistakes, correct, change our minds, slowly build – must be one of the best kept secrets in programming.
For you as a teacher this means: Don’t just teach your pupils what the correct program looks like, teach them how to get there.
The expectation that good programmers can just think up a solution persists in junior developers as they enter industry. When talking about design and planning, people think they have to be able to go from problem to fully articulated solution, not realising that design and planning are also incremental and iterative. For all but the most simple programming tasks the design and planning must be influenced by prototype and experimental programmes.