欠陥をデザインし、それからの屈辱に対処する[非公開]

あなたが提案したソフトウェア設計において常に根本的に正しいのですか？基本的に間違っているデザインを提供すると、仲間のチームメンバーの尊敬を失う傾向があります。その後、あなたが何をしても、あなたはその事件の後にあなたが提案するすべてのものについてクロスチェックされることになります。これは、チームの初心者であり、彼らがあなたの過去の成功事例を知らない場合、特に悪化します。

たぶんあなたが悪いデザインを与えた理由は、その分野での経験や知識、あるいはその両方の不足が原因でした。そのような状況に直面したあなたはどのように対処しましたか？これはあなたのキャリアの中で一度きりのようなものですか、それともオンとオフで起こりますか？これを後回しにしているのですか、それともそのような状況にある人は新しい仕事を探す必要がありますか？正直なフィードバックをお願いします...

ありがとうございました。

かつて、フォーチュン500のvpにより、企業に100万ドルの費用がかかり、ビジネス上の決定が下されました。CEOに辞任したとき、彼の返事は、「教育に100万ドルを投資したばかりで、今は辞めようとしているのか、受け入れない」というものでした。

誰かが新人であるか、または彼らが無能であると思い込んでいるとすぐに間違いを責めるマネージャーや他の労働者にうんざりしています。優れたデザイナーになる方法は1つしかありません。それはf @ $％を少し上げることです。従業員が間違えても気にしません。同じことを複数回してもかまいません。問題は、あなたはどれほど謙虚で、どれほど教えやすいですか？誰かがあなたにあなたの誤りを提示したとき、あなたは最初に自分自身を弁護しますか、それとも聞こえますか？あなたが彼のプライドを飲み込んでそこから学ぶことができる希少な人の一人なら、あなたはそれに固執する価値があります。一度エラーを犯したことで尊敬を失う人は誰でも、あなたの尊敬に値する人ではありません。

個人的には、少なくとも2回設計した最初の2つのプロジェクトを書き直さなければなりませんでしたが、何を知っていますか？たくさんのことを学びましたが、そのとき雇用主は動揺していましたが、それは私の過ちから学びたいと思うことで時間の経過とともに得た効率によってすぐに相殺されました。

屈辱の側面と回復方法については、2つのアドバイスがあります。まず、人々は時間の経過とともに忘れます。また、他の誰かが彼らにスポットライトを当てると、彼らも台無しになります。その後、すべてが再び平等になります。第二に、他人が正直、学習、間違いを犯したときに、他人に嫌がらせにならないでください。実際、彼らが本当にお尻をしっかりと蹴る必要がない限り、あなたは彼らを奨励すべきです。正直な間違いを犯したときの気持ちを思い出すことで、時間の経過とともにチームの文化を変えることができます。最終的には、人々をより良いプログラマー、デザイナー、そして人間になるように促します。

私はこれを長い間（15年以上）行ってきましたが、まだ最初は正しく動作しません。最適な設計は、反復的な共同プロセスから生まれます。しばらくの間デザインに取り組んできたとき、それがそれができる唯一の方法だと考えるのは簡単です。新鮮な視点は、見逃しているものを見るのに役立ちます。

これが機能するためには、チームは互いに信頼する必要があります。欠陥があるかもしれないデザインを人々に示すことを恐れることはできず、デザインに対する批判を受け入れることができる必要があります。次に、チームの他のメンバーは、設計の欠陥が設計者に反映されていないことを理解する必要があります。これは、設計の期待される部分です。また、チームメンバが自分自身の間違いや他人の間違いから学ぶ方法や改善する方法でもあります。

このように機能しない機能不全のチームにいる場合、2つのオプションがあります。

1. チームを修正しよう
2. 新しいチームを見つける（社内または新入社員）。

私の知る限り、私は常に根本的に防御可能でした。それは根本的に正しいこととまったく同じことではありません。多くの場合、状況は、「x」を決定しなければならない時と、「x」が後知恵で間違った決定であったことが明らかになる時との間で変わります。

米国の所得税を準備するようなものです。多くの人が答えがあると考えています。ありません。あなたの意見があります。あなたの税理士は彼女の意見を持っています。IRSは彼らの意見を持っています。

間違いを犯しても、誰かの尊敬を失うことはありません。（私の知る限り）。それは、部分的には、自分の間違いを常に認めているからだと思います。（実際、私はしばしば自分の間違いを見つけます。）また、ほとんどすべての重要な設計上の決定には、複数の人がサインオフします。これらの決定の間違いは、グループ全体が所有するものであり、完全に単一の個人が所有するものではありません。

間違いを認める限り、能力と経験を積むと簡単になると思います。私の経験では、設計と開発が新しいほど、間違いを認める可能性は低くなります。

それは何度も起こり、あなたのキャリアを狂わせてはなりません。重要な責任を負う立場にある人は、常に正しい決定を下しません。実際、重要な責任を負う立場にある誰も、常に防御可能な決定を下すことはできません。

しかし、ほとんどの場合、不完全な情報に基づいて防御可能な決定を下せるはずです。娘が言うように、「それはただの人間です」。

誰もが時々物事を間違えます。間違いは避けられません。あなたが間違っているときは自由に認め、あなたの間違いから学び、あなたが実際に間違っていたと最初に確信していない場合は特に謙虚さを示します。

「屈辱」は決して起こらないはずです。人のパフォーマンスを改善する可能性はまったくありません。

私の会社では、厳しい決定に首を張り続けたいが、間違っていることを認め、必要に応じて行動を調整できる人々を尊重する文化を開発しました。

あなたが提案したソフトウェア設計において常に根本的に正しいのですか？

ええ、私は超人です！もちろん、そうではありません。

基本的に間違っているデザインを提供すると、仲間のチームメンバーの尊敬を失う傾向があります。

番号！その場合、チームの精神に何か問題があります。

誰もが間違いを犯します。解決策の中には、良いものもあれば、悪いものもあり、その中間にあるものがほとんどです。成功と失敗の両方を、あなたとチームの他のメンバーがレッスンとして理解する必要があります。

最初の間違いは気分が悪いかもしれませんが、何百もの間違いを犯した後は、仕事の一部のようです。

それは皆に起こります。主なことは、あなたの過ちから学び、それが二度と起こらないようにすることです。また、それはあなたの側の間違いだったことを認めてください。たとえば、かつて、データアクセス層（SubSonic3）の使用を間違えていました。決定を下した時点では、手作りのSQLクエリを避けたいだけでした。そこで私は、その時点で最も簡単に始められるものの1つと思われるものを選択しました。私もDALの経験はあまりありませんでした。さて、いくつかの問題を解決した後、なぜ一部のクエリに少し時間がかかりすぎたのか疑問に思い、SubSonicが正当な理由もなくテーブル全体をプルダウンしていることがわかりました。

だから、私は上司に話し、間違いを犯したと説明し、それを修正する計画を彼に与えました。私の上司はもちろん、数日間の純粋な移行を必要とするかなり大きな間違いを犯すことに熱心ではありませんでした。しかし、彼はまた、私が同じ間違いを二度としないようにしました。彼は、私が移行することを提案した次のデータアクセスレイヤーの概念実証プロジェクトを作成し、それが要件を満たし、テーブル全体をプルダウンしないことを確認しました。全体として、それは私にとって良い学習経験でした。そして今、プロジェクトの重要な部分が要件を満たし、大きな問題がないことを確認します。

基本的にあなたがすることはこれです：

1. あなたが間違いを犯したことを認める
2. 修正する計画を立てる
3. 計画が実際に機能することを確認してください
4. もう一度確認してください。
5. 修理する！

修正方法がわからない場合は、他のチームメンバーを入れることを恐れないでください。

最後に、リラックスしてください！誰でも間違いはある。初めてそれを完璧にする人はほとんどいません

これはオタクの放尿コンテストのものであり、良い状況ではありません。誰もが常に正しいわけではなく、誰かがそれを行うためのより良い方法を思いついた場合、または彼らが問題を見つけた場合、恥ずべきことは何もありませんあなたがやった方法。

あなたは自分のソリューションから感情的に自分自身を引き離し、最良のソリューションを見つけるために時間を費やす必要があります。そうすれば、たとえ誰かが解決したとしても、問題が解決したときに満足することができます。

あなたの質問で言っていないことはたくさんあります。「デザインを配る」ためのあなたの設定が何なのかわかりません。それはあなたの計画されたアプローチについてのピアとの最初の議論ですか、それともあなたが最終的なコードであると期待するものの配信ですか？

前者の場合、気分が悪くなる理由はなく、同僚が将来あなたを疑う理由はありません。

最終納品まで他の人とデザインについて話し合うのを待っているなら、他の人の仕事を疑っていると非難しない。

誰もが自分の設計について他の誰かと話し合う必要があります。複雑さや重要度によっては、複数の人と何度も話し合う必要があるかもしれません。 誰もが間違いを犯したり、要件を誤解したり、特別なケースを見逃したりする可能性があります。

早期に特定された間違いは、修正が簡単で安価です。同じ間違いを何度も繰り返さない限り、彼らは非常に許されるべきです。ピアレビューにより、ミスを早期に発見しやすくなります。

チーム環境で一人のコーダーになろうとしている場合、他の人の助けを必要としないほど完璧だと思うという（ほとんど許されない）罪を犯しています。それがチーム環境であるという事実は、問題が十分に大きく、誰もそれをすべて理解しようとしていないことを証明しています。人々は互いに話し合う必要があります。そうしないと、間違いがリリースする前に（またはリリース後に）ユーグルの頭を後ろに近づけてしまいます。

私は常に、良い決定か悪い決定かを区別してきました。その他の正しい決定と誤った決定について。適切な決定とは、同じ状況で、同じ情報を使用して、同じ方法で行うことです。悪い決断は、あなたが違ったやり方で行うことです。正しい決定とは、後知恵と追加情報の恩恵を受けて、正しいことを証明するものです。そして逆に、間違った決定を下します。

間違った決定をしない人は何もしないとよく言われます。誤った決定は、学習方法です。意思決定者が意思決定に自ら投資し、その決定を遡及的に正当化しようとするか、結局それが良い決定であったことを証明しようとするため、悪い決定はしばしば悪化します（隠蔽は常に元の決定よりも有害です）。

私が行った設計上の決定の大部分は正しいことが証明されましたが、私はほとんどのことを学び、それらの誤った決定をさらに進めました。私の決定のほとんどが悪い決定ではないことを願っていますが、悪い決定に関する問題の一部は、決定が悪いことを認識し、それらから生じるしばしば好ましくない教訓を受け入れることです。

それらが「マンデーモーニングクォーターバック」でない限り。私は、デザインの議論のすべてを、何も言わずに、実際には機能しないとわかっていると主張するだけの人には役に立たない。建設的な文脈に置かれていなくても、批判を受け入れることができなければなりません。

おそらく、SOサイトの最も優れた機能の1つは、リスクを冒して解決策を提案し、不確実にすることができることです。これはあなたが学ぶ方法です。頭の中にたくさんのがらくたを置いて人生を経験するのは間違っていますが、それとは逆に言われたことがないのは、真の無知です。

彼らはあなたが知らないことを知っているかもしれませんが、すべてを知っているわけではありません。それを乗り越え、仕事に取り掛かり、何かを成し遂げてください。彼らはとてもスマートだと思って時間を無駄にさせましょう。

私はいつも良いデザインを提供しますか？番号！私はそれをしようと努力し、良くなろうと努力していますが、連続するプロジェクトごとに、私がいつもできることは、私が以前にやったことを振り返り、何らかの形でマークを逃した方法を縮めていくことです。

恒星以下のデザインを提案した人については、その人が間違いから学びたいと批判していることを示したなら、その人に対してそれを保持しません。その人が同様に良くなるよう努力しており、そうする適性を持っているという証拠を見るなら、悪い設計提案はただの学習の機会です。

それは時々誰にでも起こるので、最も良いことは、なぜ設計が間違っていたのかを理解し、そこから学ぶことです。知識が不足している場合、設計の失敗により、次回使用できる新しい知識が得られることが期待されます。がっかりさせないでください。誰もがこれをある時点で経験します。経験を積み、新しいチーム/環境でキャッチするための最良の方法です。

これは頻繁に起こります。私たちの業界は非常に急速に変化しており、決して間違っている可能性は事実上ゼロです。

しかし、あなたは彼らの異議よりも悪いデザインを彼らの批判に押しつけましたか？それが彼らが過剰反応している理由かもしれません。

間違いが大規模だった場合、もちろん尊敬を取り戻すには時間がかかります。同僚の1人があなたを悪い方向に導き、チーム全体に問題を引き起こした場合、近いうちにもっと自分自身を証明する必要はありませんか？

あなたができることは、あなたが間違っていたことを認め、正しい人に信用を与え、将来よく耳を傾け、より良い選択肢を研究するよう努めることです。

設計を間違えたと思わなかったことは何ですか？（ランダムではない例-行ごとに実行する既存のWebサービスを使用するインポートプロセスを設計する（コードの再利用と1か所でビジネスルールの変更のみが必要）インポートによっては数百万のレコードがあり、それから学び、将来これらのことを検討してください。

間違いが常にあります。誤ることはプログラマになることです。インターネット上の他の人、特に同僚から学び続ける。ここでの唯一の恥は、あきらめるか、これからこのような問題になると頭を砂に埋めることです。

それをあなたの後ろに置き、頭を下ろして、最善を尽くしてください。あなたが優れたプログラマーなら、あなたは自分の過ちを通して輝いていくでしょう。

自分のアイデアが強固な基盤の上にあると確信できない場合は、会社または部門全体に提案する前に、信頼できる同僚と話し合う必要があります。実際、あなたが確信していても、あなたが働いている人々、そしてあなたを最もよく知っている可能性が最も高い人たちとそれについて話し合うべきです。問題の早期発見に役立ちます。

それは私たちすべてに時々起こります。最初のデザインをプロトタイプとして使用します。何が機能し、何が機能しなかったのか、そしてその理由を正確に調べてください。その後、はるかに優れた最終製品を作成できます。

自分を正当化しようとか、防御的にしようとしないでください。間違いを認めて先に進みます。

基本的な問題は説明されていないようです。これは社会的な問題です。ほぼすべての職業でこのような行動を見ることができます。あなたが間違いを犯し、彼らが特定のものにあなたを「分類」するのが好きなら、それは永遠です。それは社会的行動です。賢くて賢い人でさえ、みんなに従う傾向があります。

プログラミングとは関係のない例を挙げましょう。以前の仕事では、皿を1〜2回洗うのを忘れていました。それ以来、すべての労働者は私が私の皿を決して洗わないような人間だと思った。そして今、流しに汚いものがあるとすぐに、それは私（他に誰がいるのか）です。

それはどこでも同じです。これは、どんな問題であろうと社会的な行動です。

あなたは正直なフィードバックが欲しいと言っていますか？唯一の解決策は、別の仕事のために辞めることです。チームの全員があなたの仕事が苦手だと思っているなら、すぐに変わることはありません。このように言って申し訳ありません。あなたはこの種の（愚かな私は告白しなければならない）社会的行動を決して変えないので、別の仕事を探してください。

重要なのは、どのようにケースを述べ、どのような変更を加えるかです。あなたが間違っていないプログラミングの第一人者であり、Jon Skeetよりも素晴らしいと主張するなら、ある時点であなたはそのために取り下げられるでしょう。重要なのは、解決策をどのように提示するかです。これにより、これはチェックすらするべきではない完璧な解決策ではなく、問題に対する合理的な解決策であることを示すことができます。

私の最も良い例はstatic、私がかつて働いていたWebアプリケーションにクラスを置くことの副作用を発見することです。1つのインスタンスを保持し、アプリケーションのすべてのユーザーで共有することがどれほど悪いかわからなかったが、それから学び、時間内に回復しました。何かが発見され、大きな修正が必要になる場合があります。私もそのキャンプにいましたが、そこで私はかつて働いていたメモリの問題を引き起こしている文字列の連結を減らすためにVBScriptの束をふるいにかけなければなりませんでした。1998年に、アプリケーションのその部分に〜20個のオプションフィールドがあったため、SQLを動的に生成する必要がある顧客のコードを見つけたときに、SQLインジェクションに対して脆弱なコードを書いたことを覚えています。

完璧主義は、ここでは両刃の剣のようなものです。これは、私がその3番目のコメントを見る方法であると同時に、私も時々いる方法です。悪いのは、これらの間違いがすべてあり、何も正しくないということです。良いことは、あなたができる限り最高のものを得るために、あなたが他人のあなたの期待を超えないなら、会うことができるということです。継続的な改善は、完璧主義を見るためのPCの方法である可能性があります。適度に保たれれば、これは良いことだと思います。ミスがすべてあった場合、コードは本番に入りますか？それは仕事を終わらせますか？それらは熟考するためのポイントであり、誰かが常に何かを修正しているのか、それともあなたがそれが完璧になるまで他のことをやらないようにひどく偉大になりたいのは良いですか？練習は、仕事をより良くするためのパターンを見つけるのに役立ちます。しかしながら、