Jibberish....

...should describe the output, not the code. --smg

I have documented my progress in svn text documents, but here's an overview of my versions, decisions, and conclusions thusfar:

history (Assignment 1)...
(will add this later....)

• Attempt 1 : FileName :         Identifiers : Universe of too many ambiguous classes
• Attempt 2 :
• Attempt 3 : 
• Attempt 4 : FileName :

print (Learned_Lessons ) -extra extra extra verbose

• Step 1 = Make it work. Iteration 1 - I overthought. I was trying to include elements I did not need. Rather than asking how I could split the actual task into managable pieces, I obsessed over extra features and reusability and efficiency and irrelevant frosting - creature feap. Creature feap before I had even begun. Needless to say, iteration 1 did not work. Did not compile. Did not make sense. Too many ideas. Entangled and messy and before long, I could not even remember the requirements of the original assignment.
• Step 0 = Plan it out. After strangling myself with iteration 2, I was sick of the 'wait,what-am-I-doing?' confusion that plagued me time and again about 50 lines of code into it. I decided that iteration 3 should be easy. Easy to read, easy to follow, easy to code. There should be no question as to whether I had already coded certain functionality or not. I should know. I needed a guiding map, so I created just that. A text file containing the specs, the intended versions/descriptions, and a section to log current progress.
• Step 0.0 = Plan it out again. Write pseudo-code. Just do it. Inevitably you will discover faults in your original logic. Change now or forever hold your frustration (at least until the next iteration.) 
•  Embrace Your One Track Mind. Between compiles, write with ONE goal in mind. I found myself changing the structure of my code while simultaneously trying to add functionality. (Changing from maps to vectors, for instance, while adding the Pick_Next_Word function. No way to tell where you're breaking.)
• Keep it Simple, Keep it NOW. Go in knowing you are going to iterate. You don't know what Future You will want in the code, so don't out-think yourself. Add functions as they become useful... In fact, ask yourself if they are useful, and specifically if they are useful in the current situation. Example - I went overboard with the idea of printing with functors in Iteration 1 (or 2?). Sure they would be useful... if I were coding a spike or writing a header/library/toolbox. Afterall, did I really need 6 different ways to print a set of words ("just in case")? I don't think so.
• Be Verbose, Descriptive, and Leave Comments. This is the easiest thing to do and the hardest thing to make yourself do. It's cake if you write pseudo-code beforehand. Comments? Check. Be verbose with variable names and take the time to describe the intended role of each new type as you create it.... or risk finding yourself in a world of god-Awful metaphors ("Okay, so each word has two neighbors, and they live in a list neighborhood, which is inside of a map City, which is part of a giant State object that has a population count and ..." --Right, got the picture? I'll spare you the details... -_-' )