Lets break things down a litte.... a little more still.

Project management. One thing I'm quickly learning is that projects big, small, or miniscule need concise logical foundations, not only to function, but to reinforce the design philosophy for that project and increase readability with a roadmap. I know there are no shortage of Project Management software solutions out there, but before I delve too deep into those, while I'm still working on the smallest of projects, I'm finding myself wanting to do the project management in my mind, or on my own as it were. That's pride talking, and pride has also had me in the position of slamming out minor changes to 'production' code until one or a few things happen; I've gone and mucked up the code beyond my own comprehension, I've made a logical error I cant wrap my head around and the product doesn't work, or worse, it DOES work, but not as expected. As I hopefully reach some form of success with the small works, and build myself up to larger projects, the hope is to have the mindset necessary to perform the following tasks:

-Dream up an idea - This seems simple enough, eh? Someday it won't be I'm sure.
-Convert that idea into writing or text - this is where the logical thinking begins, and this is where for now I begin to trip myself up.
-Mock up - The logical roadmap to the project. I'm trying to do this in my head at the moment. Not a wise idea I've found.
-Compartmentalize - Start at the beginning, build down before you begin to...
-Code! Whether this is done simply by myself or with others I expect to have a roadmap at this point, and a timeline. Tasks should be prioritized and assigned, progress should be tracked, revision history and change logging will be vital, which will lead to the ...
-Review phase slash Testing - I'm bundling these for the time being as I haven't even begun to reach this line of thinking, I will need to work on building good habits that will then allow me to review and test before...
-Deployment - Which right now consists of "File->Save / Tab to browser -> F5", and find break points. Changes come quickly and the code gets ahead of me. Pride. I need to get over my pride for wanting it to work now and focus on exactly what's happening. Take a step back. Break it down, further. Build good habits, build good code.

Oh, yeah. Code Optimization fits in there somewhere right? Right..? Again, my projects and work habits haven't even gotten me this far yet.

Self-reflection/scolding out of the way, I'll break down what I'm currently working with.

Rock. Paper. Scissors...Shoot!

I'm actively working on a humbling-ly simple Rock Paper Scissors program. It started with a CodeCademy course and blossomed into an Aptana Project. Slowly rebuilding and breaking as I've learned concepts along the way. Initially the plan was a prompt box seeking user input for rock, paper, or scissors, while another function spit out the 'computer' choice via a random number generator (0.00 - 1.00 divided into thirds and assigned an answer based on which third the number fell into), finally spitting out the results - e.g. "rock wins!" or "It was a tie!"

This grew into wanting input control and more meaningful output. So I devised a switch. It worked, sort of, if the user input a valid entry the code ran as expected and spit out some data: "You chose Rock! Computer chose Paper! Paper covers Rock. You lost this round." But what if the user input an incorrect choice the first time? It logged an incorrect choice and stopped, but what if I made it loop back to the beginning instead? What if the wrong input was given twice in a row? What if the field was null? How about if the user input a null value first, an incorrect value second, and finally the correct answer? The possibilities blossomed and I wasn't keen on all of the solutions without some major revision to the logic. Without the proper roadmap, I was quickly running into code that sort of sometimes worked, but not in every situation. Staring at a wall of code, I couldn't see the forest through the trees, I couldn't figure out WHY it did what it did in certain situations.

I was told previously when working helpdesk a good phrase that I've seen developers loose sight of:

"If you give the user a button. They're going to click it."

Why is not a factor, and it seems there is a consensus in the field that some or many developers are out of touch with the end user. I agree, I've seen it and experienced it, and already built it.

So I took a step back.

The idea of user input in the form of a prompt was put on the backburner. I'd like to explore this idea at a later time when I am better able to see the big picture before jumping into writing the code. Instead I've opted for simpler elements, three buttons that determine player choice on which was clicked. Computer choice, and the switch reside outside of the function that parses the user input. This has now caused a problem with the way logistics of how the script is executed, as the page loads, not when the button is clicked. There is also the issue of variable scope. Pride is telling me to keep plugging away, change a function, adjust the switch, DON'T look at this from a different angle, just keep going! That is until the confusion sets in.

So I've decided to take another step back...