すべてのプログラマーが「教訓」ジャーナルを保持する必要がありますか？[閉まっている]

プロジェクトを終了するたびに、私が学んだことは常にあります（そうでないと、やる気を起こさせられません）。しかし、私はすべてを思い出すことができず、ずっと後に以前のプロジェクトで遭遇したのと同じ問題に出くわすかもしれませんが、それをどうやって解決したか（または少なくとも私が試みたもの）はありません。

それで、ある種の日記にこれを書き留めておくのは良い考えでしょうか？物事を書き留めることは、ドキュメントを書くことのように感じること（誰もが楽しんでいるわけではない）を知っており、必要なときに私たちの記憶が私たちに役立つことを願っています。しかし、それを文書化すれば、他のプログラマーと共有し、彼らが学んだ教訓を学ぶことができます。

それで、あなたはどう思いますか？

テクニカルブログは、統合されたエクスペリエンスを得るための素晴らしい選択肢です。これでも、世界中の人々があなたの間違いから学ぶのに役立ちます:)

プロジェクトの最後に何が行われたか、発生した問題をレビューし、それらの問題の原因と回避方法を確認するのは良い考えのようです。それをジャーナルに書くことも良いアイデアです。なぜならそれは後で思い出すことと同じ問題を再び避けることをより簡単にするからです。

一方、共有は慎重に行う必要があります。もちろん、他の開発者やプロジェクトマネージャーにとっても役立ちますが、顧客と仕事をし、その顧客があなたが過去に抱えていた問題について読むことができる場合、彼らはあなたと仕事を始める/続ける傾向が少なくなります：

• 彼らはあなたが他の人よりもプロジェクトでより多くの問題に遭遇することを感じるでしょう（たとえそれが間違っていても）、
• 彼らはあなたのプロジェクトで遭遇する最終的な問題についての情報をあなたに公開してほしくありません。

Elder Scrollsyジャーナルがあり、何か新しいことを学ぶたびに物事を書き留めています。ご想像のとおり、それはかなり大きくなり、情報に満ちています。

実際、メモを書いて、SEサイトが質問で処理するのと同じようにメモにタグを付けることができるソフトウェアを作成することを考えてきました。

できるでしょう：

• 日付で投稿を検索します。
• タグで投稿を検索します。
• 難易度で投稿を検索します。

これは私にとって本当に役立つでしょう。

私は一度やってみましたが、これまでやってきたことの日誌で、何が良くなったのか、次回は違うことを試してみるべきかを振り返りました。これは技術的なものではありませんでした-これは、チームの他の人とのやり取り、会議での決定などに関するものでした（はい、この会社は毎日書くことができる十分な会議を持っていました！）。

最終的に、ジャーナルは書き込み専用メモリであることがわかりました：おそらく、それを書いた経験が私の考えを整理したり、やったことを評価したりするのに役立ちましたが、約6週間後、私は戻って行っていないことを確認していませんでした書かれたので、私はそれを維持することをやめました。

テクニカルノートに関する限り、会議やクライアントにプレゼンテーションする必要がある場合を除き、実際にメモを保持しません。そうでなければ、Pinboard.inのブックマークのセットで十分です。

絶対に、学んだ教訓のジャーナルと学んだ教訓を続けるべきです。前者は、直接的な経験を通じて得られた最も高価なタイプの学習を統合します。後者は、積極的な学習を必要とする/拍車をかけます。

ジャーナリングは、知られている最も古い自己開発ツールの1つであり、さらに古い方法である（自己）リフレクションを促します。両方が必要です。

絶対に。実話：この質問を読んだ直後に、私は以前に解決したことがわかっていた問題にぶつかりました（重要な場合は構成の問題）。「教訓」ノートブック（紙とペン版）をざっと読んだところ、解決策がありました。ファイルaを場所bにコピーしてください。

このノートブックは、2つの方法で役立ちます。1つ目は、以前に尋ねられた質問と解決済みの問題に対する答えを見つける場所を提供すること、2つ目はそれを書き留めて知識を強化することです（他の人に説明するようなものです）。

もちろん、私は時々ノートを置き忘れました...

これが、TRAC、Jiraなどのプロジェクト/問題管理システムの目的です。職場では、詳細なコメント、手順、依存関係をTRACとJiraに入れました。これにより、以前に見られた問題に直面したときに、簡単な検索で答えが得られるようになりました。