I don't know if you noticed, but my introducing sentence to this guide was "So you want to learn how to program assembly?", not, "So you want to program assembly?" To me, there is a distinct difference between the two. Put simply, there is a difference between a process versus a product. You should not try to restrict yourself to an end goal or style, which, in this case, is mastering assembly programming. Instead, you should try to see how you can expand and grow on your journey as an assembly programmer, while all the while expressing yourself.
Here's another topic that's important for developing the mindset: water. Ahh yes, water. "So what? What's so important about water?" Well, it, um, makes up a major percentage of your body and the world, and you drink it to rehydrate yourself? "Ok... so, is that it? Why did you bring it up?" I brought the topic of water up because you should become water - fluid and formless. Don't get it? Ok, here's a question: is the glass of water on the table half-full or half-empty? *pause for thinking on a decision on the question at hand* Oh, is it really? Ok, now, ready for my answer? It's neither half-full nor half-empty! The water is changing and adapting; it's fluid and formless. "Huh? WTF IS THIS B*LLSH*T? It is CLEARLY being still and the water is CLEARLY at the half-way mark!!! OMG N00B 413|27!!!" Ah, but you see, that's the beauty of water! It's ready to become whatever, whenever and wherever.
Here's an example (which I guess is not so really applicable to non-assembly-programmers, but whatever, it works :P): you're up late at night working on a game, and on a test run (that is, you execute the program), your program shows some sprites (they're portable graphics of sorts) and appears to work, but once you press a key, it crashes (fails), shows BLOD (blue lines of death, a play on blue screen of death (BSOD) on older versions of Microsoft Windows), and as a finale, the RAM resets. <now playing - tada.wav> Now what? What do you do? Do you resist and "F***ING SCREAM AT THE CALCULATOR WHILE SHARPENING A JOYSTICK INTO A DEADLY WEAPON TO STAB AT IT?" Or do you do the natural thing: adapting, isolating and identifing the problem, reassembling, and seeing if it works? Sure, the first reaction sounds funny, but in all practicality, it won't really help fix the problem. ;) Use whatever works, and take it from wherever you can.
Now, I don't claim to know everything and anything; no, not in any way. What I'm trying to do is set you up for this seemingly dauntless task of learning assembly programming, because I believe in helping others. Most programming guides focus on the technique, but they lack the tactic. It's all about the attitude. If you approach something with the wrong attitude, you will most likely get bad results. If you approach something with the right attitude, you will most likely get good results. Ok, so, yes, most of these ideas don't really make sense at first, but as you progress through the experience, perhaps then you'll observe and understand all this mumble-jumble.