趣味でプログラムを始めたいと思っています。

いっちばん最初は３でしょ。
でもね。
他のプログラマのコードを読む方がいいよ。
アプリのソースコードを晒してくれてる方も結構いる。
ただ、他人のソースコードを読もうとしても読めない。だから３でガリガリやって、自力をつける。
１とか２とかなんて、その後でもいいんだよ。何しろ他人のコードを読んで他人のアプリの仕組みを知れば、１にも２にもものすごい技術力が使われているのがわかるから。

1)は企画書の段階ですね。
2)はフローチャートの事でしょう。

多人数でやるプロジェクトなら1)は必須だけれども、
1人で作成し、内容を把握しているなら無くてもいいと思います。

2)は処理の流れの整理。なんだけれども、プログラムに慣れてくると、
隅から隅まで理解している事をわざわざ手間隙かけて書き出す事になるので、
面倒で省きたくなるんだけれども、
多人数のプロジェクトの場合は省略しないよう上から言われます。
フローが無いと他の人が問題点を見つけにくくなるので、
結果としてデバッグ作業の足を引っ張る事になりかねないからです。
でも1人の場合、やはり不用なんですよね。
いくら書き出したところで自分の能力以上の判断はできないわけですから、
デバッグ作業に有効に活用できるとも思えませんし。

だから、よほど大規模なプログラムを組むなら話は別ですが、
趣味レベルのプログラムを1人で組む場合、やはり3)だけでいいと思います。
綿密な設計が必要なプログラムを組むような段階になれば、
1)や2)についても自然と必要と感じるようになると思いますよ。

あと、1号さんの書いてるとおり、他人のソースを解析するのが上達への近道ですね。
興味の無いソフトのコードは解析するのも苦痛でしょうけど、
動作に興味のあるソフトなら、解析も楽しんで行えると思いますよ。

　こんな感じじゃないでしょうか。
①まずは自分の作りたいアプリのソースを本やネットで見つける。
②ソースを解析して理解する。
　ここで、他言語に翻訳してみるのもいいかも知れません。たとえば、Cで数独のソースを見つけて、それをJavaやVBなどに翻訳してみるとか。
③自分の好みに合わせて改良する。