タグ付けされた質問 「communication」

ライブショーをできないミュージシャンのように感じることもあります。プログラミングは非常にクールなスキルであり、非常に広い世界ですが、その多くは「カメラから離れて」発生します。頭の中、オフィス、観客から離れています。 もちろん、他のプログラマーとプログラミングについて話し合うことができ、ピアプログラミングがあり、人々に見せることができるものを作成することができますが、非プログラマーにそれが何であるか、またはどうだったかを説明することになると仕事でのあなたの一日は、ちょっと難しいです。 あなたの人生で非プログラマにどうやってあなたが何をしているのかを理解させるにはどうすればいいですか？ 注：これは、プログラマ以外の人に開発プロセスを理解してもらうことの繰り返しではありません。なぜなら、その質問はクライアントの期待を管理することに関するものだからです。

43 development-process  communication 

私は金融工学の分野（BA MathとBA Computer Scienceの後）で約5年間（20％分析/プログラミング、80％コミュニケーション）しており、人々とコミュニケーションを取り、技術的な問題について議論する能力に誇りを持っています。チームと）。仕事のこの部分が大好きです。ホワイトボードに行き、抽象的なアイデアを描き、ブレインストーミングを行います。 しかし、多くの理由で、キャリアをテクノロジー企業（ソフトウェアエンジニアリング）に移行したいと考えていますが、プログラマーが大きなヘッドホンを付けてコーディングするという定型的なプログラミングの仕事に落ちることを深く恐れています。私は確かにこれが単なるステレオタイプであることを知っていますが、以前（スタートアップで）同様の環境を目撃しました。 コーディングとアルゴリズム的思考が大好きですが、人とのやり取りをあきらめたくありません。コミュニケーションスキルを身に付けることは前向きなことだと理解していますが、ソフトウェアエンジニアリングに移行することで、キャリアハッピーの失敗に備えています。明確化やアドバイスを聞きたいです。

40 education  communication  career-development 

先日、チームの誰かが書いたコードをレビューしました。ソリューションは完全には機能せず、デザインは複雑でした-不要な情報の保存、不要な機能の構築を意味し、基本的にコードには金メッキのような不要な複雑さがたくさんあり、存在しない問題を解決しようとしました。 この状況では、「なぜこのようにしたのですか？」 答えは、他の人がそのようにしたいと感じていることです。 次に、これらの機能のいずれかがプロジェクト仕様の一部であるかどうか、エンドユーザーが使用できるかどうか、または追加データがエンドユーザーに提示されるかどうかを尋ねます。 答えはいいえだ。 そこで、不必要な複雑さをすべて削除することをお勧めします。私が通常得る答えは、「それはすでに終わっています」です。 私の見解では、それは行われておらず、バグがあり、ユーザーが望むことを行わず、メンテナンスコストは、私が提案したより簡単な方法で行われた場合よりも高くなります。 同等のシナリオは次のとおりです。 同僚が10秒以内にResharperで自動的に実行できたコードを手作業でリファクタリングするのに8時間かかります。当然のことながら、手作業によるリファクタリングは疑わしい品質であり、十分にテストされていないため、信頼できません。 繰り返しになりますが、私は「既に完了しています」という応答を受け取ります。 この態度に対する適切な対応は何ですか？

37 code-quality  code-reviews  communication 

私は質問（チームのコードカウボーイ）を見つけましたが、それは私が抱えている問題よりも「Ninja Coder」に関連していました。 「カウボーイコーダー」の純粋に生きた例であるチームメンバーがいます。人を変えることはできないことを理解していますが、彼が「カウボーイコーダー」のように振る舞うのをやめる方法ですか？ 彼はチームの意見を聞くことを拒否し、最近、コードレビュー、ユニットテスト、実装の詳細の共有などを停止しました。 はい、彼は高速に「コーディング」しますが、彼のコードは単なるバグ生成プログラムです。他のチームメンバーと私は「バグ修正フェーズ」にあり、バグの80％は彼のコードに起因しています。私は彼のバグを修正したくありません。そして、経営陣は盲目であるか、これを見たくないか、多分彼らは彼の「スピード」を好む。 私（彼の上司ではなく、年齢の若い同僚として）がそれについて何かできる方法はありますか？ このカウボーイコーダーを武装解除するにはどうすればよいですか？ 私はこのプロジェクトを本当に気にかけている最後の人だと感じています。

37 development-environment  teamwork  communication  cowboy-coding 

多くの大規模なOSSプロジェクトでは、IRCチャネルを維持して、その使用法や開発について議論しています。Webで情報を見つけようとして失敗したため、プロジェクトの使用にこだわったとき、何をすべきかを判断する方法の1つは、IRCチャンネルにアクセスして質問することです。 しかし、私の質問は、チャンネルの人々によって常に完全に無視されます。入室時に沈黙があったとしても、沈黙は続きます。進行中の会話がある場合、それは動揺しません。チャンネルを数時間開いたままにして、誰かが最終的に私に関与することを期待していますが、何も起こりません。 だから、どういうわけか私が理解できない失礼な態度をとったり、暗黙のルールを破って無視されたりするのではないかと心配しています。私は質問を丁寧に、要点まで、文法的にし、明白な解決策を試みたのか、なぜうまくいかなかったのかを示しようとします。私は明らかにチャンネルの人々にとって完全に見知らぬ人であることを理解していますが、これを修正する方法がわかりません。何も言わずに、1週間だけチャンネルに潜む必要がありますか？それもばかげているようです。 私が送信する典型的なメッセージは、「こんにちは-Fooを動作させようとしましたが、BarExceptionを取得し続けています。Quuxをリセットしようとしましたが、これは何もしません。私が何を試すことができるかについての提案？」

36 open-source  communication 

5年前、私は長期に集中する能力を失い、したがって、プロの効率でコーディングする能力を失いました。 私はそれがなぜ起こったのかを知っており、それがどのように起こったのかを理解し、冷静でリラックスした焦点を再現できることに加えて、当時の全体的な状況に心が傾いた元の（子供時代に根ざした）理由を克服しました; 私の理解は、心理学者が私に言った言葉に根ざしていない、私は実際にそれらを直接手探りした。私は生産性を大幅に向上させることができると確信しています。おそらく、事前バーンアウトよりもさらにそうです。 また、コードへの興味を失うことも、自分の能力を取り戻そうとすることから外れることもありませんでした。私は知識を最新に保ちました（コーディングに関連することを常に比較的簡単に学ぶことができ、それらを適用するだけではありません）、したがって、その年の平均LOCカウントが非常に小さい場合でも、以前よりも優れた開発者であると言えます低い。 一方、今では、仕事よりもドールでの時間を多く含む伝記があります。 雇用主として、私の申請にチャンスを与えるためにあなたを納得させるものは何ですか？トピック全体を除外する必要があるとは思わない。 編集：私は子供の頃から原因を探し始めていなかったと付け加えるべきだと思います。それが原因を私に示した解決策でした。残念ながら、会社を修正するために最善を尽くしていません（退職してから1年後に完全に解散しました）は、幼少期に、ある時点で、親の関係の修正をあきらめて、彼らが完全に絶望的なケースである代わりに、共感で私自身の失敗にそれを、そして私は子供時代に言及することなくそれを説明する方法を本当に見ません。とはいえ、涙を流すことなく完全にそれを言うことができます。 そうは言っても、はい、私はあなたに雇用主ではなく友人として書いていることを知っています、それが私がワンタイムアカウントを使用してあなたに不信を示す理由です.oO（...） はい、どこにでも応募する前に、OSSコードをリリースする予定です。 編集2：私はドイツ人であり、ドイツの会社に応募するつもりなので、「創造的な真実」は間違いなく選択肢ではありません。 選ばれた答えについて：ピエールよりもレネシスを選んだのは、後者がやる気を起こさせ、それを乗り越えて社会的スキルのセクションを強化するためのポイントを与えるのに素晴らしい仕事をしていたので、レネシスは実際に私の質問に答えたからです関連する主要な要因を合計することにより。

36 productivity  communication 

私が抱えていた問題の解決策を記録するために主に使用するブログがあり、その答えを見つけるのに苦労しました。私がグーグルで検索したオンラインドキュメントがあまりにも多くの情報を提供し、3回目のグーグルヒットの5ページ目で私の質問への答えを見つけたほとんどの問題。 （または、ここで質問をした場合、答えが得られなかったか、「答えは簡単にグーグルで検索できる」という質問をしたことで非難されました。） 私は頻繁にこのブログで何かを調べて、自分がどのように問題を解決したかを思い出し、他の人からもかなりのヒットを得ることができます。 とにかく、履歴書でこのブログに言及することは、就職活動で私を助けたり傷つけたりするのではないかと思っていましたか？トピックはすべてマップ上にあります。 それが示すことを望みます 私は問題の解決策を見つける人です 私は仕事で多くの異なる技術を使用しました 私は挑戦に取り組むことを恐れていません 私が心配しているのは、それが示すことです この人は簡単なものに問題がありましたか？ なぜこの人はこのようなことをブログに記載するのを悩ますのですか？

34 communication  skills 

当社では、製品設計文書を使用していません。合計3人の従業員がいるため、製品設計に関するすべての議論は直接、またはSlackで行われます。（最新のメッセージの表示のみを許可する基本的なSlackパッケージも使用しています。） 当社の製品はまだ初期段階にあり、数か月前に決定された設計要素を頻繁に再検討しています。 私たちが悲惨なほど頻繁に直面する問題は、製品設計の決定が下された理由を忘れることです。これにより、同じ地面をリトレッドするのに何時間も無駄になります。 設計決定の背後にある理論的根拠をどのように効果的に記録できますか？ ワークフローはPivotal Trackerに基づいています。私に起こる解決策の1つは、関連するすべての設計決定の理論的根拠をユーザーストーリー自体へのコメントとして記録することですが、これは信頼できないようです。 100％明確にするために：私はコードの設計について話しているのではありません。私は、コードによって実現される製品の設計について話している。言い換えれば、「多重継承ではなく構成を使用してこのクラスを構成すべきか？」などの決定について話しているのではありません。「ログインする前に、ユーザーにメールアドレスを確認してもらう必要がありますか？」などの決定について話している。 ドキュメントの目的は、ビジネスが意思決定が行われた理由の記録を表示できるようにし、同じトピックに関するさらなる意思決定を支援することです。

30 design  communication  design-decisions 

解決する必要がある問題があるとき、それを解決する最も簡単な方法は、小さなプログラムを個人的なツールとして書くことです。使用するのは私だけなので、使いやすくしたり堅牢にしたりすることはありません。 その後、同僚はプログラムを見て、同じ問題にぶつかり、ツールが役立つ可能性があるため、それを要求します。私は彼に「それはきれいではないが、仕事をやり遂げるだろう」という免責事項を与え、彼にそれを手に入れました。 私が知っている次のことは、上司が私に電話して、クライアントのコンピューターでソフトウェアを動作させようとしているが、Xエラーメッセージが表示されていると言っていることです。WTF ?? そのソフトウェアはリリースの準備ができていません。また、リリースの準備が必要だとは言われませんでした。しかし、何らかの理由で、上司はそれが十分であると考え、元の開発者に伝えることなくそれをリリースしました。 現在、この特定の問題はを使用して簡単に修正できますMessageBox.Show("DO NOT GIVE TO CLIENTS!");。しかし、この問題はより深い問題を示しています。当社の企業文化はずさんです。ずさんなソフトウェアは問題ありませんし、ずさんなプロセスは問題ありません。将来について心配する必要はありません-現在はほとんど動作しないように十分な努力を払い、バイナリを.zipファイルに入れて、出荷してください。政府の仕事には十分です。 これは、10人の正社員を抱える小さな会社で、成長を続けており、しばらく前から存在しています。誤解しないでください。ここで働くのが大好きで、会社が大好きです。走るように言わないでください。私は会社をより良くするための一部になりたいです。この種の文化にどのように良い変化をもたらし始めますか？

28 development-process  communication  business-process 

私は、一般的な英語の意味で「最適化」とみなされるものに対して独断的に多くの人々に出会いました。そして、彼らは非常にしばしば「部分的な」引用「早すぎる最適化はすべての悪の根源」です彼らのスタンスの正当化として、私が話していることは何でも「時期尚早の最適化」であると解釈することを意味します。しかし、これらのビューは非常に馬鹿げているため、最も純粋な「単純な」実装からのあらゆる種類のアルゴリズムまたはデータ構造の逸脱、または少なくとも以前のやり方からの逸脱を排除します。「パフォーマンス」や「最適化」について聞いてからシャットダウンした後に再び「耳を開く」ように、このような人々にどのようにアプローチできますか？「この男は10行のコードに2週間を費やしたい」とすぐに思わせることなく、パフォーマンスに影響を与える設計/実装のトピックについて議論するにはどうすればよいですか。 さて、「すべての最適化は時期尚早ので、悪である」かどうかのスタンスがいるすでにここにカバーされてだけでなく、ウェブの他のコーナーで、すでに議論されている最適化は時期尚早ので、悪の場合に認識する方法が、残念ながら、現実の世界には、反最適化への信仰への挑戦に対してあまり開かれていない人々がまだいます。 以前の試み 数回、「時期尚早の最適化は悪い」↛「すべての最適化は悪い」と説明するために、ドナルドクヌースから完全な引用を提供しようとしました。 私たちは小さな効率を忘れてはなりません。約97％の時間です。早すぎる最適化はすべての悪の根源です。しかし、その重要な3％でチャンスを逃してはなりません。 しかし、見積もり全体を提供するとき、これらの人々は実際に、私がやっていることはPremature Optimization™であると確信し、耳を傾けて拒否します。それはまるで「最適化」という言葉が彼らを怖がらせるかのようです：数回、「optimiz（e | ation）」という言葉の使用を単に避けることで、拒否されずに実際のパフォーマンス改善コードの変更を提案することができました（ 「パフォーマンス」も同様です-その言葉も怖いです）代わりに、「代替アーキテクチャ」や「改善された実装」のような表現を使用しています。このため、これは本当に独断的であり、実際に私が言うことを批判的に評価し、それを不要であるか、費用がかかりすぎると却下するのではないようです。

26 performance  teamwork  optimization  communication 

私がより良い開発者になったので、私の設計スキルの多くは、機械的分析よりも直感から来ていることがわかります。これは素晴らしい。これにより、コードを読んで、すばやく感じられるようになります。これにより、言語と抽象化の間でデザインをはるかに簡単に翻訳できます。そして、それは私がより速く物事を成し遂げることを可能にします。 欠点は、特定の設計が有利な理由をチームメイト（さらに悪いことに、経営陣）に説明するのが難しいことです。特に、ベストプラクティスの時代遅れのチームメイト。「この設計はテスト可能です！」または「継承よりも合成を優先する必要があります。」彼らの頭を真っ直ぐに行き、最後の10年のソフトウェアエンジニアリングの進歩に誰もが手がかりを与えようとする私のうさぎの穴に導かれます。 もちろん、練習すれば良くなりますが、その間に多くの無駄な時間や悪い設計が必要になります（後で修正するために無駄な時間がかかることになります）。利点が視聴者に完全に明らかではない場合、特定のデザインが優れている理由をよりよく説明するにはどうすればよいですか？

26 design  communication 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 私の顧客は最近、URLリライティングとは何か、それがどのように機能するのか、そしてその長所と短所を完全に理解することなく、それを発見しました。現在、彼は、現在のプロジェクトの実際の要件の多くの奇妙な変更と古いプロジェクトの変更を求めて、URL書き換えと信じているものを実装します。 一方では、実際の仕事をする代わりに意味をなさないことをするように頼まれてイライラしています。一方、顧客が興味を持っているにもかかわらず、その主題について何も理解していないことを顧客に伝えることはできません。 多くの人がマネージャーや顧客が新しい流行語や新しい技術を学んだばかりで、すべてのプロジェクトで、どこでも、この新しいコードを使用するためだけにコードベース全体を書き直したいというよりも、彼がそれをとても気に入っていたと思います物など また、私は最近、Programmers.SEに関連する記事を読みました。そこでは、XMLに大きな話題があったときの経験について人々が語り、一部のマネージャーは、XMLを使用したことを皆に示すために、すべてのプロジェクトにXMLを導入するように頼みました。 それで、同様の状況にあった人々、あなたはどのようにそれを管理しましたか？

24 communication  customer-relations 

アリスとピーターにはそれぞれ4GBのUSBフラッシュメモリスティックがあるとします。ランダムに生成されたビットを含むalice_to_peter.key（2GB）およびpeter_to_alice.key（2GB）という名前の2つのファイルを両方のスティックに保存します。二度と会うことはありませんが、電子的に通信します。また、Aliceはという変数を維持し、alice_pointerPeterはという変数を維持peter_pointerします。どちらも最初はゼロに設定されています。 アリスがピーターにメッセージを送信する必要がある場合、アリスnは次のことを行います（メッセージのn番目のバイトは次のとおりです）。 encrypted_message_to_peter[n] = message_to_peter[n] XOR alice_to_peter.key[alice_pointer + n] encrypted_payload_to_peter = alice_pointer + encrypted_message_to_peter alice_pointer += length(encrypted_message_to_peter) （そして最大限のセキュリティのために、キーの使用済み部分は消去できます） Peterはencrypted_payload_to_peter、alice_pointerメッセージの最初に格納された読み取りを受け取り、実行します。 message_to_peter[n] = encrypted_message_to_peter[n] XOR alice_to_peter.key[alice_pointer + n] また、最大限のセキュリティを確保するために、メッセージを読んだ後、キーの使用済み部分も消去します。 -編集：実際、この完全なチェックと認証のないこの単純なアルゴリズムのステップはセキュリティを低下させます。以下のPaŭloEbermannの投稿を参照してください。 ピーターがアリスにメッセージを送信する必要があるとき、彼らは今度はとで逆をpeter_to_alice.key行いpeter_pointerます。 この簡単なスキーマを使用すると、今後50年間、毎日2GB /（50 * 365）=〜115kBの暗号化データを双方向に送信できます。より多くのデータを送信する必要がある場合、たとえば、今日の2TB HD（1TBキー）を使用すると、より大きなキーを使用でき、今後50年間で60MB /日を交換できます。これは実際には大量のデータです。たとえば、圧縮を使用すると、1時間以上の高品質の音声通信になります。 攻撃者がキーなしで暗号化されたメッセージを読む方法はないようです。なぜなら、彼らが無限に高速なコンピューターを持っているとしても、総当たりで彼らはすべての可能なメッセージを制限の下で得ることができますが、これは天文学的な数字ですメッセージの数と攻撃者は、それらのどれが実際のメッセージであるかを知りません。 私は正しいですか？この通信方式は本当に安全ですか？また、安全な場合、独自の名前を持っていますか？XOR暗号化はよく知られていますが、両側で大きなキーを使用するこの具体的な実用的なアプリケーションの名前を探していますか？私はこのアプリケーションが私の前に誰かによって発明されたことを謙虚に期待しています。:-) 注：完全に安全であれば、驚くべきことです。今日の低コストの大容量ストレージデバイスでは、高価な量子暗号より安全な通信を行う方がはるかに安価であり、同等のセキュリティを備えているからです！ 編集： これは、ストレージコストが減少するので、将来的にはより実用的になると思います。安全な通信を永遠に解決できます。今日、誰かが1年後でも既存の暗号を正常に攻撃し、しばしば高価な実装を安全でないものにするかどうかは確実ではありません。通信が発生する前の多くの場合、双方が個人的に会うとき、それが鍵を生成する時です。たとえば、大きなキーを持つHDを持つことができる潜水艦間の軍事通信に最適だと思います。また、軍の中央は各潜水艦にHDを持つことができます。アカウントを作成するときに銀行などと会うため、銀行口座を管理するなど、日常生活でも実用的です。

23 communication  encryption 

月末に、私が自分で取り組んでいるソフトウェアプロジェクトについてプレゼンテーションをしなければなりません。これは基本的に、私が一時的に雇っている会社でフルタイムの仕事を得るかどうかを決定します。今のところ。私の部門の社長と2人のVPにプレゼンテーションを行います。社長は他の2人のVPよりもプログラミングの知識が少なく、最終的に私が感心する必要がある人物です。 プレゼンテーションで伝える必要がある最も重要なことは何ですか？マネージャーから次のことを強調するように言われました。 私はこのプロジェクトを正しい方向に進めており、すべてを完全にコントロールしています。 私はこのプロジェクトを予定通り完了しています。 プレゼンテーション中に、他のどの点に焦点を当てて、自分を可能な限り雇用価値があるように見せるべきですか？ソフトウェアのリスクと不確実性を減らすために、設計レベルで行っている努力を強調することを考えています（私が想像する2つのことは、上級者にとって非常に重要です）。 私が特に心配していることの1つは、プレゼンテーションで技術的詳細と非技術的詳細の適切なバランスを見つけることです。技術的な詳細を含めない場合、部門の社長はソフトウェアに含まれる「内部」機能のすべてを知ることはできませんが、私が技術的すぎると、彼は迷子になり、理解できなくなる可能性がありますプレゼンテーションの重要なポイント。 任意のヒントをいただければ幸いです。

23 communication  presentation 

私たちは皆、マネージャーであり、10年以上前にセールスから来た人、またはコードを最後に見た人がいますが、コードの書き方を知っていると思います。 彼の介入に感謝しているという印象を与えるために私は何ができますか？ または、最新のコーディング技術と実践を使って教育するために、マネージャーともっと関与する必要がありますか？結局のところ、これらを理解しているマネージャーは、プロジェクトとそのタイムスケールについて議論するときに、クライアントや上級管理職と賢く話すことができるでしょう。

23 communication