I think you may be doing it backwards then. Trial-and-Error, or mental modelling were working out fine for me when I was just starting to learn how it all worked. But now it's down to critical and logical thinking processes.
I don't build models until I know which actors in the system they represent. And I only do that because OOP is built to deal with this kind of system-building.
I try not to fulfill the requirements but to require fulfillment; build, define the problem in the terms of a solution. That works for me.
Sometimes you need to break down the problem into smaller problems to do that.
I'm really not following that - can you clarify please?
I'm not sure which concepts your words refer to e.g. what is it in "how it all worked"? which models do you mean in "I don't build models until" (in the article, models are mental models, and it uses the term representations for their representation in code or notation.
Refers to building systems in general. How do you build a solution to a problem? This is a skill, and it is learned and taught.
> …don't build models…
Refers to mental modelling, correct. I don't do that until I have broken the problem down into mentally tangible pieces, and then – only to accommodate for the particular tool that I'll be using – i.e a programming language/famework/hardware of this kind or another.
I don't build models until I know which actors in the system they represent. And I only do that because OOP is built to deal with this kind of system-building.
I try not to fulfill the requirements but to require fulfillment; build, define the problem in the terms of a solution. That works for me.
Sometimes you need to break down the problem into smaller problems to do that.