My favorite teacher taught visual basic. I have barely used visual basic ever since. But what she hammered into our heads was flow charting, psuedocode and orga

My favorite teacher taught visual basic. I have barely used visual basic ever since. But what she hammered into our heads was flow charting, psuedocode and organization. I organize the features I want long term, I organize the technologies I want to use, I organize my file structure, I organize how I'm going to reach each goal, I flow chart out how to solve smaller goals. I'm not a teacher and I don't think I have a silver bullet. But here is what I would suggest 1) Write the program, but don't use any language. Use a language you've made up yourself (It sounds stupid I know) - Does it have a UI? - Make it. -Does the UI have squares? Where, what color -Does it animate? - Does it require information - Figure out where from -From the File system? -From a server? -From another peer? -Will information be pushed live or only retreived when requested? - Does it react to user input? - What kind? -Voice recognition? -Clicking on the UI? -Waiting to long? 2) Choose a language and figure out how to implement each one of these things -Look it up on a Search engine -I found the dumber my questions are, the better my search results are -Read documentation -Complain about documentation -Complain about the library being unintuitive -Promise yourself you'll never write something so terrible 3) Work until your tired, satisfied, bored, angry, had your fill or finished This is the kind of work flow I get paid to do. After reading the other comment, heres some more experiences. Your work will turn into spagetti code with plenty of errors and most likely unmaintainable. Making Abstract Classes and Using Object Oriented techniques will make your life much more easy. But I'm assuming you don't want to just keep hello world'ing and just build.