すべてのプログラマーが "Lessons Learned"ジャーナルを保持する必要がありますか？
私がプロジェクトを完了するたびに、私は常に学んだ何かがあります（そうでなければ、私はそれが非常にモチベーションになるとは思いません）。しかし、すべてを思い出すことはできません。以前のプロジェクトで遭遇した同じ問題に遭遇する可能性がありますが、解決方法（または少なくともどのような試みをしたか）はわかりません。
それで、これをある種の日記に書くことは良い考えでしょうか？何かを書き留めることは、ドキュメントを書くようなものです（誰もが楽しんでいるわけではありません）。必要なときに私たちの記憶が役立ってくれることを願っています。しかし、それを文書化しておけば、他のプログラマーと共有して、彼らが学んだ教訓を学ぶことができます。
それで、あなたはどう思いますか？
統合されたエクスペリエンスを得るには、テクニカルブログが最適です。これでも世界中の人があなたの過ちから学ぶのに役立ちます:)
プロジェクトの最後に行われたことと発生した問題を確認し、それらの問題の原因と回避方法を確認することは良い考えのようです。それをジャーナルに書いておくことも良いアイデアです。思い出すのが簡単になり、後で再び同じ問題を回避できるからです。
一方、共有は慎重に行う必要があります。もちろん、他の開発者やプロジェクトマネージャーにとっても役立ちますが、顧客と協力して、それらの顧客が過去に経験した問題について読むことができれば、彼らはあなたと一緒に仕事を始めたり続けたりする傾向が少なくなります。
- 彼らはあなたが他の人よりもプロジェクトで多くの問題に遭遇したと感じます（たとえそれが間違っていても）、
- 彼らはあなたが彼らのプロジェクトで遭遇する最終的な問題についての情報を公開することを望んでいません。
Elder Scrollsyジャーナルを持っています。何か新しいことを学ぶたびに書き留めます。ご想像のとおり、かなり大きく、情報が豊富です。
実際、私はメモを書いて、SEサイトが質問で行うのと同じようにメモにタグを付けることができるソフトウェアを作成することを考えていました。
できるでしょう：
- 日付で投稿を検索します。
- タグで投稿を検索します。
- 難易度で投稿を検索します。
これは本当に役に立ちます。
私は一度やってみました。自分がやったことの毎日の日記をつけて、もっと上手くいったことと、次に何を試すべきかを振り返ってみました。これは技術的なものではありませんでした。これは、チームの他の人々とのやり取り、会議での決定などに関するものでした（そうです、この会社には、私が毎日書くための十分な会議がありました！）。
最終的に、ジャーナルは書き込み専用の記憶であることがわかりました。おそらく、それを書いた経験が私の考えを整理したり、やったことを評価したりするのに役立つかもしれませんが、約6週間後、戻って自分の書いたことを確認したことがなかったことがわかりました。書いたので、それを維持するのをやめました。
テクニカルノートに関する限り、会議やクライアントにプレゼンテーションする必要がない限り、実際にそれらを保持することはありません。それ以外の場合は、Pinboard.inのブックマークのセットで十分です。
絶対に、人は学んだ教訓と学んだ教訓の日記をつけるべきです。前者は、直接的な経験によって得られた最も高価なタイプの学習を統合します。後者は、積極的な学習を必要とする/拍車をかけます。
ジャーナリングは、知られている最も古い自己開発ツールの1つであり、さらに古い方法である（自己）反射を促します。両方が必要です。
もちろんです。実話：この質問を読んだ直後、私は問題にぶつかりましたknew以前に解決しました（問題がある場合は、構成の問題）。 「Lessons Learned」ノートブック（紙とペンのエディション）をざっと読み、解決策がありました。ファイルaを場所bにコピーしました。
このノートブックは、2つの点で私に役立ちます。1つは以前に尋ねた質問と解決された問題への回答を見つける場所を提供すること、もう1つは書き留めて知識を強化すること（他の人に説明するようなもの）です。
もちろん、私は時々上記のノートブックを置き忘れます...
これは、TRAC、Jiraなどのプロジェクト/問題管理システムの目的です。職場では、TRACとJiraに詳細なコメント、手順、依存関係を配置し、以前に見られた問題に直面したときに簡単な検索で答えが得られるようにしました。