Programmers need to think in a certain way.
To create a computer program they have to reduce an idea, no matter how simple or complex, into a set of logical steps. They typically start with a higher level idea and then reduce it piece-by-piece with ever smaller granularity until it essentially becomes a list of questions and answers; inputs and outputs.
Unless you can break a concept down into smaller and smaller constituent parts, you'll never be able to translate that process into program code.
Over time, and the more experienced you get - the more levels 'deep' you'll be able to see - thus avoiding program errors and 'bugs' - which are often simply from areas where the programmer(s) hadn't foreseen an eventuality - either in the process or on the part of user input. At the start, you'll need to be conscientious and work through the steps slowly - there are no short-cuts - you need to have the experience with program bugs and errors to start to see how they can be avoided next time. In the real-world though, many programming tasks are so complex that it would be literally impossible to foresee even the majority of the issues that could arise - let alone all of them - which is why we need good error-trapping and handling to try and keep our programs on the right track.
A lot of potential errors can be avoided by good planning with plenty of restrictions in place on user input and file/database formats etc. It's better to build a good solid wall and hand-rail to keep people on a path, rather than spend time building fancy ways of putting them back on it if they veer off, or handling the fall-out from them falling off the edge! Tight and effective rules are incredibly important in programming.
Let's start with a very simple example to illustrate what we mean: A basic program to take a file of potential customers/enquiries and split it up between our team of sales rep's.
On the surface we just take the file, as a list, and divide it up equally between the number of rep's we have. But here comes the understanding (and 'peeling the layers') of the process: What rules define which rep's get which customers? How many customers should each rep have, depending on their working hours, patterns and geography? Do some rep's have the capacity for more customers? Are all customers the same, or are they broke into sub-sets, and can some clients only be handled by certain rep's? Are the customers to be broken down at the end of a period, or daily as they come in; and if daily, what weighting is to be used towards which rep's?
This is just the start of the analysis or breaking down of the program scope and functionality. Hopefully just those few questions have started to spark an understanding of how complex this program could actually be! Until we define all the rules of how the process is going to work, we couldn't hope to write that into code. 'Systems Analysis' is the term applied to this way of thinking, and Systems Analysts are generally senior/lead programmers with a lot of experience - because they can avoid a lot of the pitfalls right at the start, simply by way of been-there-done-that-and-it didn't-work-so-we-did-this!
Many programmers will tell you to just dive in and get on with it (and that's one school of thought,) but without some pre-planning you'll end up wasting a lot of time re-writing code and de-bugging it when it doesn't perform as planned. The time needed in planning is proportional to the complexity of the process. Many simple programs can just be started and allowed to evolve in their own way - and again, the more experienced you get, the more you'll be able to jump in the deep end. But, make no mistake, understanding the rules of your system are essential: You cannot write program code for rules you don't know or understand!
So, the programming mindset is essentially learning the techniques of 'framing' a task, and then breaking it down into more manageable parts; which are then broken down further and further until you reach a level of granularity that is comfortable to start the actual coding. It's a process-driven way of looking at tasks to break them down into a series of steps, loops and conditional statements (if this, then do this; if that then do that; repeat this until that happens).
Now of course, there is a lot more to writing a program than just understanding the steps of the process it is to handle. The language itself will have limitations and rules that have to be followed. There is a bunch of set-up and house-keeping that needs to be done, and you'll need to be messing around with I/O (Input/Output), file/database handling and also dealing with interfacing to the operating system (e.g. Windows or Web Server) and what are known as API's (Application Programmming Interfaces) etc. And all these things can be very, very 'picky' indeed! But that's the technicality of programming - and those rules have already been defined by someone else; your creativity comes in interpreting the process you want to program and defining the rules, boundaries and methods to achieve those results. And it can be an exciting, highly creative and brain-stretching ride to say the least!
For those that are at the start of a learning coding journey, simply understand that it'll often seem alien at first - and possibly counter-intuitive. And we're not saying that you shouldn't jump in, try stuff and play to your heart's content while you're learning; that's important too. But we ARE saying it's critical to start asking deeper questions as you go - and see the task as a process which needs to be methodically broken down into increasingly smaller parts. Only then will you become an effective programmer - and the cold, hard truth of the matter is: The better the quality and the more insightful your framing and questions are, the better the quality and the more useful your answers will be.