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

「眠りが必要」のような疲労ではなく、「もう悩むことはできません」のような疲労は、通常、作業中のプロジェクトで障害物にぶつかったときに始まり、一般的に締め切りに近づきます。 仕事のプロジェクトでも個人のプロジェクトでもかまいませんが、最近ますますヒットしています。私はアイデアを得て、それに取り組み、いくつかの本当に良い日を過ごして進歩を遂げます、そしていくつかの厄介なことが私をつまずかせます、私はあなたが望むように物事を得ることができません、私は制限に達しましたフレームワークでは、ドキュメントを見つけることができないなどの問題があり、イライラするだけです。 それとも私はこれで一人ですか？

48 productivity 

では特効薬、フレッド・ブルックスは最高でまとめソフトウェア工学の将来に関する予測、さまざまなになります： 技術または管理技術のいずれにおいても、それ自体で生産性、信頼性、シンプルさの1桁の改善さえ約束する単一の開発はありません。 彼の議論は非常に説得力があります。ブルックスは1986年に書いていた：彼は正しかった？2014年の開発者は、1986年の開発者の10倍未満の速度でソフトウェアを生産しますか？いくつかの適切な指標で、生産性の向上は実際にどのくらいの大きさですか？

45 productivity 

Stack Overflowを日常業務のリソースとして使用することについて、職場で短いプレゼンテーションを行うことを考えています。 これを行った経験は何ですか？ 同僚にそれを伝えるのに有効なリソースだと思いますか、それともリソースとしてGoogleについて話すのに似ていますか？ それを行うより良い方法はありますか？ Stack Overflowの質問側に答えるのではなく、質問をすることに傾倒していました。 フォローアップとして。 もともと、私は質問を自分のケースに限定しすぎたくはありませんでした。私のプレゼンテーションは、わずか4分間の簡単なトークで、1時間かけてさまざまなグループに繰り返します。 Stack Overflowの講演の前に質問をして、プレゼンテーション中にそれを参照することがあります。うまくいけば、1時間の間にいくつかのアクティビティがあります。 また、すべての開発者ではないため、視聴者に適した他のStack Exchangeサイトについても簡単に説明します。スーパーユーザー、サーバーフォールト、プログラマーはうまく機能すると思います。 プレゼンテーションのスケジュールが変更されたため、今後2か月間はプレゼンテーションを行いませんが、更新方法を更新します。

45 productivity  communication 

私は自分で「停止点症候群」と呼ぶ行動に気付きました...それは、「停止点」に到達するまで（または疲労するまで）作業を停止できないことを意味します。言い換えれば、機能の完了に取り組んでいるゾーンにいる場合、それが完了するまで停止しません。私が取り組んでいるバグの場合、この効果はさらに顕著になります。修正されるか、少なくとも理解されるまで停止しません。私はラップトップで仕事をしていて、VPNを持っているので、その夜遅くに家に帰って仕事に取りかかることができますが、その事実は仕事を辞めるのに役立ちません...バグを見つける前に死ぬのではないかと心配しています。 これを家族に説明するのは非常に苦労します。家族には、なぜ私が仕事から帰ってこないのか、時には午後11時に家に帰るのかを理解できません。マネージャーでさえもこれに戸惑っていて、同僚のほとんどが毎日同じ時間働くことに問題がないことに気付きました。 他の誰かがこの問題を抱えていますか？これを心配したり、変更したりする必要がありますか？もしそうならどのように？

44 development-process  productivity  time-management 

そのため、トップレベルのプログラマーは、平均的なピアよりも1 桁以上優れたコードを生成できると一般に受け入れられています。 また、プログラマーにとって、コードで発生するエラーの割合は比較的一定であることも一般的に受け入れられています。 代わりに、コードの作成時およびコードの作成後に使用されるプロセスの影響を受ける傾向があります。（私が理解しているように）人間はかなり一定の割合で間違いを犯す傾向があります-優れたプログラマーはそれらの多くに気づくだけで、より迅速に修正します。 上記の両方の主張は、Steve McConnellによるCode Completeからのものであることに注意してください。したがって、異なる観点の問題ではありません。 だから私は最近、私のコードでこれを見始めました。私は、（チームが推定したストーリーポイントで測定して）同程度のコードの約4〜5倍のコードを、より高い品質（パフォーマンスメトリックとチェックイン後に行われた変更の数に基づく）で打ち出すことができます。しかし、私はまだ間違いを犯します。優れた単体テストと、コードが何をしているのかをよりよく理解し、コードレビューを行う際の問題に対するより良い目との間で、4〜5倍の数のバグを生成していません。 しかし、QAが発見したバグは、チームの他の開発者の約2倍です。ご想像のとおり、これはメトリック測定を行う技術者以外の人々にいくつかの問題を引き起こします（私のボスを読んでください） 私は、ピアの半分の割合でバグを生成している（そして2倍修正している）ことを指摘しようとしましたが、2倍のバグを生成しているというグラフがあると、それは大変な売りです。 それでは、生産性の向上がバグの増加につながるという事実にどう対処するのでしょうか？

43 productivity  code-quality  bug 

Rob Coneryによるこの投稿（スラッグに注意）は、開発環境は仮想マシン内で実行する必要があると述べています。私は彼が言っていることを見て同意する傾向がありますが、それでも少し不安を感じます。仮想化が非常に成熟しているため、VM内で運用システムを実行する場合でも、速度はほとんど問題になりませんが、ここで何か気になる点があります。 開発マシンの仮想化についてどう思いますか？すでにそうしましたか？そうした場合、道路に落とし穴や落とし穴がありますか？

41 productivity  configuration  development-environment  virtualization 

私はもう2年近く大企業（8000人以上の従業員）で働いており、学習コースを終えた直後に採用されました。 ここの誰もが、しばしば非常にひどく設計されたハックに満ちたレガシーコードを毎日処理しなければなりません。最初は、物事をあまり批判しないように、目立たないようにしました。しかし、現状では、この状況に耐えることは非常に難しくなっており、私たちが使用するツールを改善/交換しようとする人は誰もいないようです。 より明確にするために： 廃止されたソース管理ツール（Visual SourceSafe） 完全な再構築のみをサポートするプレーンな古いメイクファイル .def すべての既存のアーキテクチャに対して手動で個別に維持する必要があるファイル モノリシックヘッダーファイルと非常に少数の異なるファイルを含むプロジェクト（ただし、それぞれに約3000行のコードがあり、非常に異なるタスクを処理する場合があります） 「新しい」言語機能std::stringは使用しません（まあ、それほど新しいものではありませんが、私以外は使用していません） 数か月前に、新しいコンパイル環境を設計することで、それについて何かをすることにしました。インクリメンタルビルドを確実に動作させ、コンパイル時間を短縮し、構造化されたプロジェクトを改善し、.defファイルを自動生成することができました。さらに、GitとVisual SourceSafeの間のブリッジを作成しました。 いくつかの同僚や上司に自分の成果を見せましたが、誰も気にしないようでした。それらはすべて「まあ...人々は今それをそのようにするのに慣れています。なぜ私たちは物事を変えるのですか？」 私が提案した変更は、古いシステムから新しいシステムにソフトに移行できるように設計されたものです。それぞれの改善は個別に安全に適用できます。 同僚の何人かを変更に参加させようとさえしました。しかし、これまでのところ、成功していません。 あなたはすでに同様の状況に直面しましたか？「例によるリード」が機能しない場合、何ができますか？

40 architecture  productivity  changes 

職場では、かなり仕様のマシン（デュアルクアッド2GHz、4GB RAM、160GB 7200RPMドライブ、Win7）が与えられましたが、いくつかの場所（HDD / RAM）に欠けていました。ITスタッフはハードウェアを自分のハードウェアに交換しても問題なかったので、SSDと8GBのRAMを追加しました（複数のVisual Studioと仮想マシンを実行できます）。マシンを選択するのは会社のビジネス上の決定でしたが、ハードウェアの高速化により仕事での満足度と生産性が向上しました。 私の質問は、生活の質を向上させるために自分の仕事用ハードウェアに個人的なお金を費やす意思があるのは私だけだと思いますか？遡及的に「ハードウェアでこの500ドルを払い戻すべきだと思う」と言うことは可能ですか？

40 performance  productivity  hardware 

ゾーンに入ることは、楽しく実りの多いプロセスです。優れたソースコードを作成し、ゾーンにいる間に行われた作業から多くの満足を得ています。しかし、どのようにして「ゾーン」に入るのでしょうか？特定のプロセスに従っていますか？メールシステム、モバイル、その他のありふれた非生産的なアプリケーションの切り替えとは別に、他にできることはありますか？

40 productivity  experience 

時々、仕事のためにやらなければならないことが面白くて魅力的です。時々、そうではありません。時々、そうではありません。 あなたの脳がやるべきこと以外のことをやるとき、特にインターネットと興味深いSlackの無限の機会が手に入れるとき、それらの鈍いストレッチに対処するための特定の戦略またはトリックがありますか？

39 productivity  time-management 

デスクトップの使用は日々の生活の中で日々減少していますが、コーディングの目的でラップトップよりもデスクトップを使用する理由はありますか？

39 productivity  coding 

すでにプログラマーとして働いていたときに、タッチタイプを覚えましたか？もしそうなら、それは生産性にどのように影響しましたか？または、あなたはまだタイプに触れることができず、それがあなたを阻むと思いますか？ スティーブイェッジによると、それは不可欠であり、 個人的には、実際に入力する作業時間の25％未満しか費やしていなかったために、大きな違いに気付きませんでした（当時私は大規模なレガシープロジェクトに取り組んでおり、既存のコードの読み取りとデバッグにより多くの時間を費やしていました）。

38 productivity 

私はプログラマーが睡眠なしで2日間コーディングし、コーヒーとRed Bullを飲むことを聞いたことがあります。また、The Social Networkのような映画では、Mark Zuckerbergが36時間プログラミングを行っているシーンを示しています。また、Facebook、Google、foursquareなどの企業では、24時間以上睡眠なしでコーディングできることも読んでいます。 これは本当ですか？睡眠不足の場合、実際に高品質のコードを生成できますか？ レッドブルのようなものは睡眠を補うことができますか？

37 productivity 

私は、大規模な既存のコードベース（すべてC＃）と大規模なエンジニアリングチームを持つソフトウェア会社のCTOです。コードの特定の部分をF＃で書くのがはるかに簡単になり、開発時間の短縮、バグの減少、並列実装の容易化など、基本的に私のチームの全体的な生産性の向上が見られます。ただし、F＃を導入する生産性の落とし穴もいくつかあります。 1）誰もがF＃を習得する必要があり、たとえばJavaからC＃に切り替えるほど簡単ではありません。F＃を学習していないチームメンバーは、コードベースのF＃の部分で作業することはできません。 2）現在（2010年12月）の雇用可能なF＃プログラマーのプールは存在しません。さまざまなソフトウェアエンジニアの履歴書データベースで「F＃」を検索します。履歴書の1％未満がキーワードを含んでいます。 3）現在（2010年12月）のコミュニティサポートはあまり利用できません。C＃のほとんどすべての問題をグーグルで検索し、F＃でではなく、すでにそれを処理した人を見つけることができます。サードパーティのツールサポート（NUnit、Resharperなど）も大ざっぱです。 私はこれが少しCatch-22であることに気づきました。つまり、私のような人々がF＃を使用しない場合、コミュニティとツールは決して実現しません、など。しかし、私は会社を経営しています。最先端ではありません。 私が検討していない他の落とし穴はありますか？または、私が言及した落とし穴に反論したい人はいますか？これは重要な議論であり、このパブリックフォーラムでの反論を聞いてみたいと思います。反論は、業界によるF＃の採用を増やすのに大いに役立つかもしれません。

37 functional-programming  productivity  maintenance  f# 

オブジェクト指向プログラミングの概念が何年も前にプログラマーに紹介されたとき、それは興味深く見え、プログラミングはよりきれいになりました。OOPはこんな感じでした Stock stock = new Stock(); stock.addItem(item); stock.removeItem(item); わかりやすい名前を付けるとわかりやすくなりました。 しかし、データ転送オブジェクト、値オブジェクト、リポジトリ、依存性注入などのパターンを持つOOPは、より複雑になりました。上記を実現するには、いくつかのクラス（例：抽象、ファクトリ、DAOなど）を作成し、いくつかのインターフェイスを実装する必要があります。 注：コラボレーション、テスト、統合を容易にするベストプラクティスに反対するわけではありません

36 design-patterns  productivity  programming-practices  object-oriented-design