[snip] Funny: in doing tech writing or instructional design, I have created tons of flowcharts to get ideas across, even have charted code snippets when writing about SQL, XML, etc. But I never really thought about using that approach for programming. [/snip] Don't feel badly here. I have often hired new, fresh out of college, programmers who have never seen a flowchart, use case diagram, or UML, save "for that one chapter sophomore year". Then I teach them the value. Start basic. Excel has drawing tools with flowchart symbols and connectors. They are really easy to understand and use. Heck, even a list works for an action; 1. set value a 2. set value b 3. does value a equal value b a. yes - do this b. no - do that Now 'do that' becomes a list 1. put data in database 2. notify client of success Or 'do that' becomes a list 1. notify client of failure Now, this is simplistic, but it is what you want to do even with a flowchart. OOP is different but not really any more complex. Flowcharting may reveal problems in logic or show you more elegant ways to do things. You wouldn't build a house without a blueprint, would you? It will also help with distraction. Each portion of the code becomes a module. You don't have to complete it all in one shot. Make mucho comments in the code to. (You will often see lists similar to above in my code and the code of programmers that I work with.) And don't be afraid to change the notes or the flowcharts as you go.