デキるプログラマになるぞ！1つ目 難しいタスクから先に片付ける
プログラミングにおいては「簡単な問題は後に回し、最も難しい問題から片付けていくべきである」という原則があります。
これは何故でしょうか？
私はこの方面の専門書を読んだことはないので正確なところは分かりませんが、自分なりに考えてみましたのでそれを書いてみたいと思います。
ポイントは「簡単な問題は難しい問題の部分問題となっていることが多い」ということです。
難しい問題というのは往々にして大きな問題であることが多いですし、小さな問題というのは簡単な問題であることが多いです（問題の規模と難度には正の相関があります）。
そして、大きな問題というのは通常これ以上分割できない1つの大きな問題という訳ではなく、より小さな問題に分割できることが多いです（大きな問題には分割統治的アプローチが使えることが多いです）。
そして、もう1つよくあるのが、大きな問題を構成している小さな問題が別のところにある小さな問題と類似しているというパターンです。
とすれば、どういう戦略で問題に取り組むのが効率が良いでしょうか？
難しい問題から片付けるか、簡単な問題から片付けるか。
簡単な問題から片付ける、これは駄目ですね。
こうすると、簡単な問題に対処し始めた時点では、難しい問題への理解、分析は殆ど進められていない訳です。したがって、難しい問題がどのような簡単な問題に分割されるかも分かっていません。
この状態で、簡単な問題を片付け、難しい問題に取り掛かります。そうすると、そこで初めて難しい問題の一部がその前に片付けていた簡単な問題に類似していることに気付きます。
しかしながら、簡単な問題に対処した時点では、簡単な問題に対する解法が難しい問題の一部にも適用できそうであるということには気付いていなかったため、簡単な問題に対する解法がその簡単な問題でしか使えないものになっていたり、他の類似した問題を解決するためには使いにくい（使うには効率が悪い）ものになっていたりして、結局その簡単な問題に対する解法を難しい問題の解決にも利用しようとするとある程度の修正が必要になってしまうというのはありがちなことです。
逆に、難しい問題から片付ける場合はどうでしょうか。
この場合は、難しい問題に取り組む過程で難しい問題が簡単な問題に分割されていきます。しかも、このようにして得られた簡単な問題はある程度の汎用性があったり、自然に汎用性を導入できる形であったりします（もう少し分かりやすく言うと、問題を分割する過程で問題の構成要素が綺麗な形に整理されていくのです）。
そのため、このようにして得られた簡単な問題に対する解法も自然にある程度汎用性のあるものとすることができます。
難しい問題が片付いたら簡単な問題に取り掛かります。
この時点で簡単な問題の一部が難しい問題の一部を構成していた簡単な問題と類似していることに気付きます。
そうすると、既にある程度汎用的な解法は得られているので、後はその解法を簡単な問題に適用してやれば良いだけです。
という訳で、難しい問題から片付けた方が問題解決の効率が良くなりやすいと思います。
これが「簡単な問題は後に回し、最も難しい問題から片付けていくべきである」という原則の根拠の1つなのではないでしょうか。
