2004年、私はケーブルテレビ会社の請求およびサービス部門の大規模なチームでジュニア開発者として働いていました。 すべての大規模システムと同様に、これはいくつかの比較的独立したコンポーネントで構成されており、個々の従業員または小グループが作業していました。 デジタルテレビシステムとアナログテレビシステムはほぼ完全に分離されており、各チームには独自のチームがありました。
アナログテレビチームは、システムを以前のバージョンのMicrosoft BizTalkに展開しました。 4人のスタッフとマイクロソフトのチームがシステムを開発し、立ち上げました。 彼らは皆一生懸命働いたようです。 彼らはしばしば夜間や週末に職場に留まりました。 彼らは仕事の問題を解決するために問題を投げかけ、しばしば同じテーブルの周りに混雑し、何が間違っているのか、そしてそれをどう修正するのかを提案しました。 彼らは常に何かをしていましたが、一目見れば、一生懸命働いている緊密なチームがあることが明らかでした。
デジタルテレビチームは非常に異なっていました。 コードは主に一人の男によって書かれました。彼をデイブと呼びましょう。 私はチームのジュニアメンテナンス開発者でした。 最初は、コードを理解するのが困難でした。 最も重要な場所には長い手順はありませんでしたが、それらの代わりに、多くの小さなクラスといくつかの行のメソッドが使用されました。 私の同僚の何人かは、デイブがあまりにも混乱していると不平を言いました。 しかし、彼は私を彼の管理下に置き、オブジェクト指向プログラミングに関するいくつかの本を読むことを申し出ました。 彼は、デザインパターン、SOLID原則、および単体テストについて教えてくれました。 すぐにコードを掘り下げ、作業を重ねるほど、そのエレガントなデザインが気に入りました。 それは正しく機能し、ちょうどその仕事をしました。 コードを変更することも比較的簡単だったため、新しい関数は非常に簡単に接続できました。 単体テストを使用すると、本番環境に到達したバグはほとんどありませんでした...
その結果、私たちが一生懸命働いていたということではありませんでした。 私は5:30に家に帰り、週末は仕事をしませんでした。お互いのテーブルの周りを何時間も混雑しませんでした。 私たちの仕事はアナログTVチームの仕事よりもはるかに簡単であると人々に思われたに違いありません。 実際、私たちの要件は非常によく似ていて、ソフトウェアの作成と実装の改善と、特に単体テストのサポートインフラストラクチャの改善が必要でした。
当局は、業績に基づいて賃金を引き上げたいと発表した。 上司と話をする番になったとき、彼は非常に一生懸命働く人が増えれば公平だと説明し、特に夕方を犠牲にしたヒーローと比べて、私たちのチームは会社についてあまり心配していないようですそして週末。
ケーブル会社との話は特別なケースです。なぜなら、ソフトウェアの良し悪しとチームの行動の結果を自分の目で見ることができるからです。 ほとんどの企業はそのような比較を見つけることができません。 人が一生懸命働いて、週末遅くに働いて時間がない場合、彼が本当に非常に難しい仕事をしているのか、または多くの間違いを犯しているのかを言うのは難しいです。 同じ問題を解決するために2つ以上の競合チームを雇うことができない場合（そして誰がそうするのか？）、確実に見つけることはできません。 そしてその逆に、角に座って、9時から5時まで働いていて、インターネットに長時間座っているように見える人はどうでしょうか？ 彼は安定した、信頼できるコードを書くのに多くの経験がありますか、それとも彼の仕事が他の人より簡単なのですか？ 横から見ると、1つ目は非常にうまく機能しますが、2つ目はそうではありません。 一生懸命働くのは良いこと、怠inessは悪いことですよね？
ハードワークはしばしばエラーを示していると思います。 あなたがプレッシャーをかけられ、常に邪魔されていると、良いソフトウェアを開発することは困難です。 残業はあまりよくありません。 時々、複雑な問題を解決するために、それについて考えるのをやめるか、散歩に行くか、またはあなたの潜在意識がそれを理解できるように良い夜の眠りさえすることが最善です。 私のお気に入りの本の1つは、 数学者の謝罪 G.H.です。 ハーディ（GHハーディ）、20世紀のイギリスを代表する数学者の一人。 その中で、彼は毎日の仕事を説明しています。午前中は4時間、午後はクリケットを見ています。 彼は、1日4時間を超える重度の精神作業を行うのは無意味で非生産的だと言います。
私はマネージャーに、人がどれだけ懸命に働くかではなく、結果によって、働くソフトウェアによって人々を判断することを勧めます。 直観に反して、開発者と一緒に座っていない方がよい場合があります。通常の/直感的なインジケーターに依存しない製品のより完全な画像を取得できるためです。 リモートワークは特に有益です。 作業量で従業員を評価できます。1日8時間、テーブルに座っている様子をじっと見たり、統合開発環境をいじったり、「役に立つ」アイデアを提供して「役に立つ」アイデアを提供したりする必要はありません。
