THIS I find important. Basically, you build yourself a knowledgebase of code snippets so you know how to write a for loop, or a regexp that matches what you want. You keep a list of all commands in your head, so you know what you can do with them, and are able to query quickly the correct syntax (either in your head, from perldoc or from older scripts). This is your Perl ROM. This is "learning the language".

Now, you also need the structure of the program, the way it connects with other software or user, and be able to hold that in your head in order to "design" the complete flow, without going into details. THAT needs to go in RAM, and getting your brain fit enough to hold it all takes a while. And you have text/program editors that help with that (gives you a list of the subroutines you have defined, or the variables you have used so far; your RAM registers). Or hold the dependencies and requirements in mindmap software.

This RAM is generic and it's what stays with you when they say: "Learning another language is easy", because you interchange only the ROM part (which could be only a cheat-sheet of all functions). And, like muscles of a bodybuilder, this RAM part of your brain needs to stay lean. (analytical problem solving)

Sometimes, you step out and go prototyping to get something you want and do not do often: read a weird format, connect successfully to a database and encapsulate that in a function, which you can later use in your program. Learn the AT commands of your dialup. This research part if either brute-force coding (prototyping) or library hunting/testing (anyone dived into CPAN before, like this? It's a sea of modules). These new code snippets are then incorporated into your ROM, and now you can use your RAM to knit them together. If you have the time, this is also the moment to write test cases for these new things.

So. What is programming to you? The ROM part or the RAM part?

If it is the RAM part, you are good at high level design, and interfacing with the customer to get a list of requirements and balance these with constraints to come to a not-yet-coded software.

If it is the ROM part, then you like transforming the high level design into a detailed design and code away, loose yourself in the code.

If both... then, you are a candidate for automatic programming, where while talking to another person, the information is stored in a tree, and relations are matched and you are basically programming while talking.