そして、あなたは自分でバーンアウトをプログラムしませんか?

画像






プログラマーは他の職業よりも感情的に燃え尽きやすいですか? もしそうなら、どのようなリスク要因が存在し、それらにどのように対処しますか?



このテキストは、材料と議論の選択において科学的な深さと徹底したもののふりをしていません。 これは、興味深いトピックに関する著者の議論です。

この記事は、英語のブログの投稿の翻訳です。



最近、私の良き友人が私を訪ねてきました。 彼は専門職による精神科医です。 会話の中で、彼は最近、燃え尽き症候群(燃え尽き症候群)の診断でますます多くのプログラマーが彼に目を向けていると述べました。 私の友人は、彼がプログラマーの仕事の本質を少し理解していることを認めましたが、彼には他の多くのものよりもストレス要因はないようです。

「あなたの職業は、プログラマを頻繁に燃え尽きさせる他の職業とどう違うのですか?」と彼は尋ねました。



会話の後、私はインターネットで少し調べましたが、プログラマは燃え尽きる可能性が他の人よりも高いという友人の経験的仮定の統計的証拠を見つけませんでした。 しかし、彼はドイツでの燃え尽きの発生率の大きさに関するいくつかの恐ろしい事実を見つけました。 詳細は元の投稿にあります。



プログラマーはどこからストレスを感じますか?



私は精神医学からはほど遠いですが、40年以上にわたってソフトウェアシステムのプログラミングとアーキテクチャに携わってきました。 私の同僚の何人かは燃え尽きました。 したがって、私は質問に興味がありました、プログラマーの間で燃え尽きを引き起こす特定の専門的要因は何ですか?

これが私の推論の流れです。



プログラマはどのように眠りますか?



私たちの生活は、睡眠と覚醒に分かれています。 睡眠から始めましょう。

人々は1日の異なる時間に交代で勤務し、異なる期間の交代や一定の準備状態での睡眠をとる多くの職業があります(英語の用語はオンコールで、ドイツ語はBereitschaftです)。 これらの職業には、私たちに近いシステム管理者の職業があります。 新しい種類のプログラマ(いわゆるDevOps)は、「クラシック」プログラマよりも影響を受けます。 また、後者は、システムの新しいバージョンを起動するときに、オンコールモードで短時間のスリープを経験する可能性があります。



しかし、一般的に、プログラマーの職業は、乱れた睡眠または劣った睡眠のリスクを負いません。 夢ではありません



非コミュニケーションプログラマー



私たちの起きている時間は、働く時間と休む時間に分けられます。 私たちはまず、非就業時間-仕事の後の夜と週末に対処します。



人々はこの時間を親しい人の輪で、または一人で過ごし、趣味に専念し、インターネット、書籍、テレビ、スポーツ、ウォーキングなどから情報を消費します。

私の推定では、プログラマーは他の職業より社交的ではありません。 これは、プログラマーやマネージャーが出席する会議やコンピューター展示会でもはっきりと見えます。 これら2つのグループの代表者は、油と水と同じように混ざり合いません。 ミーティングの合間や夕方のイベントでは、マネージャーは積極的に新しい連絡先を作成し、古い連絡先を更新し、いちゃつくか、ただ人生を楽しみます。 プログラマーはすぐに、そしてイベントの終わりまで小グループに分類され、集合的に沈黙を保つか、専門家の問題について話し合います。



この観察であなたは私に同意すると思います。 そして、低い社交性がストレスにつながり、燃え尽きる可能性は低いことを認めなければなりません。



そのため、リスク要因の検索では、空き時間も破棄します。 今から仕事に取りかかります。



みんなのように



仕事に関連するリスク要因は2つのグループに分けられると考えられます。1つは同僚に関連し、もう1つは「作業材料」に関連します。



問題はチームにありません



プログラマーチームでは、労働者集団で生じるすべてのストレス要因が発生する可能性があることは明らかです-モブ、孤立、過小評価、シェフのお気に入りの支配など。 しかし、プログラミングチームには、法的な階層(軍隊など)を持つチームに固有の特別な側面はなく、限られたスペース(船のチーム、ドリラーのシフトなど)に長時間一緒に滞在します。 したがって、これらの側面では、プログラマーの仕事は他の「通常の」職業と大差ありません。 この側面も破棄します。



物質的な問題



したがって、「材料」は残ります。 これは、これまたはその専門家が彼の仕事で扱うものを意味します。 外科医には人体があり、教師には生徒がおり、整備士には金属があり、プログラマーにはプログラムコードがあります。



素材に関連して、次の側面を強調したいと思います。





したがって、これらの側面を順番に検討します。



エラー不可逆性



錠前屋は、それ自体の集中力や制御できない理由により、高価な材料から部品を不可逆的に「ねじ止め」することができ、前の処理段階で多大な労力と資金が投入されました。 外科医の間違いはさらに悲劇的なものになる可能性があります。 プログラマーはこれを持っていません-間違ったコード行を書き直し、世界は順調に戻っています。 この側面は破棄されます。



エラーの発現の必然性



一部の職業では、間違いは「独力で」排除されます。 より正確に、間違って参加することなく。 患者の体は、不適切に処方された薬にもかかわらず回復する力を見つけることができます。 悪い教師の生徒は、教材を独自に学ぶことができます。または、両親は彼のために家庭教師を雇うことができます。



プログラミングでは、これはほとんど起こりません。 例外は、同僚がエラーに気付き、それを事物間で修正する場合、または外部条件が変化してエラーが発生しない場合です。



ほとんどの場合、遅かれ早かれ、エラーが明らかになる瞬間が来ます。 もちろん、後よりも早くする方が良いでしょう。 プログラマはこれを知っています。 そして、それは常に彼らを悩ます。



そこで、プログラマーの職業に固有であり、他の職業ではめったに見られない最初のリスク要因を見つけました。



「ダウンロード」できない



一部の職業では、「問題が自動的に解決される」まで待つのが賢明です。 官僚はこれを知っています。 また、タスクまたは責任の領域が明確に定義されていない場合は、「スイング」することができ、他の誰かが作業を行います。 一部の管理教科書では、これを意図的に使用することを推奨しています。 例:新しいユニットをリードするために送られました。 多くの人がいますが、そのうちの何人かは明らかにオフロードしています。 委任する必要がある非常に緊急のタスクがありますが、誰にわからない。 レシピ:最も忙しくて生産的なものを見つけて、彼に任せます。 ネットはケースを圧倒する可能性がありますが、これは確かにそれを行います。



優れたプログラミングチームでは、同様のタスクに取り組む個々のプログラマーのパフォーマンスは、すぐに他のユーザーに対して透過的になります。 したがって、中長期的には、「上陸」は従業員に対する態度に悪影響を及ぼします。 JiraやGitのような最新のツールは、この件に関してチームとマネージャーを「容赦なく」支援します。



短期はさらに悪化します。 プログラマーなら誰でも、必要な決定が集中力と創造性を備えた状態になることを知っています。 それらが到着した場合、パスは明確であり、それらを実装し、テストを作成します(または、最初にテストを作成してから実装する方がよい)。 しかし、創造的な状態がない場合、一日中自分自身を拷問することはできますが、結果は達成されません。 休日の直後にバージョン管理システムに書き込まれ、配置されたコードは、後で他のコードよりもはるかに高い確率で書き換えられるという統計に出くわしました。 すでに理由を推測しましたか?



そのため、結果を生成するために、プログラマーは高い集中力(他の職業では必要)と絶えず新しい問題を解決するのに十分な創造的な気分(他のほとんどの職業ではあまり必要ありません)で就業日のかなりの部分に滞在する必要があります このリスク要因をリストに載せてください。



「計算」の開始の速度



この指標によると、プログラマーの職業は非常にユニークで、プロスポーツに匹敵します。 プレーヤーがボールを誤って打った場合、そのプレーヤー(および観客、チームメイト、対戦相手)はすぐにそのことを認識します。 最新のプログラミング方法とツールは、IDEが即座に構文エラーを示すようなものです。 正しく動作している場合は、コードをテストでカバーすると、テストは数分以内に次のテスト実行時にアルゴリズムエラーを示します。 フットボール選手とは異なり、プログラマーは「ミス」のために聴衆からブーイングされることはありません。 しかし、フットボール選手が1時間半の間スタンドに向かって話し、試合ごとにそれほどボールを打たないことを忘れないでください。 プログラマーにとって、これは1週間続きます。



歴史的隠れ家:70年代の実話



この点で、私は物語を思い出しました。 アカデムゴロドクにある科学アカデミーのシベリア支部のコンピューティングセンターで仕事を始めたばかりの頃、コンピューティングリソースは「タイムシェアリングモード」で部門間で共有されていました。 そう見えた。 各部門には、いずれかのコンピューターに一定の時間(たとえば、30分)が割り当てられました。 (そして、彼らはコンピューターと呼ばれていました)。 パンチカードデッキの形でタスクを準備しました。 時間枠が近づくと、研究室のアシスタントがスタックから最初のデッキを取り出し、カードパンチリーダーに入れました。 コンピューターはそれを処理し、電球で信号を出しました。 プリンターは結果を紙テープに印刷しました。 ラボの技術者は次のデッキを取りました...そして、時間枠が終わるまでそれを繰り返しました。



ウィンドウが終了すると、現在のタスクを強制的に停止でき、対応するデッキは、未処理のまま、次のウィンドウの部門デッキのキューに最初に配置されました。



微妙な点は、前の部門にデッキがほとんどない場合、または迅速に処理された場合、当社の部門のデッキがより早く処理される可能性があることです。 これは非常にまれにしか起こりませんでしたが、体系的に「幸運」であることに気付いたときは。



目の前に並んでいる予定だった部門では、Fortranのサブセットに似た複雑な言語のインタープリターをデバッグするために多くのコンピューター時間が計画されていたことがわかりました。 (現在、DSL-ドメイン固有言語と呼ばれています)。 通訳は、同僚と話し合い、プログラムが初めて機能するように作成することを主張した有能な開発者によってプログラムされました。 この紛争に関するリソースを計画した当局は知らなかったため、数ヶ月前に彼のために窓を開けました。 知らずに使用したもの。



この才能のある人が書いた、パンチカードに入力、チェック(私たちはすべて、ロシア語より悪くないパンチカードの「穴」言語を読んで理解する方法を知っていた)数千行のコードを1回も開始しなかった。 しかし... ...彼は議論を失った。 最初の起動時にいくつかのエラーがありました。 そして、エラーを除去した後の2回目の起動でのみ、目的の結果が得られました。



豊富なコンピューターリソースと素晴らしいIDEに甘やかされて甘やかされている現代のプログラマーは、おそらく想像するのが難しいでしょう。 私自身は、数十行のコードを書いた後、段階的にプログラムし、テストを実行します。 これは一般的に、一日中考えてコードを入力し、1日に1回だけコンピューターで実行するよりも効果的だと思います。 しかし、最新の方法の利点は絶対的なものではありません。 コードをすばやくチェックする機能は、コードを深く多様に考えることに不慣れです。



しかし、私たちの側面に戻りましょう。 私の意見では、プログラマーの間での間違いの「計算の開始」の平均速度は、すべての職業の中で最高の1つです。 そして、これはストレスの主な職業上の危険因子の一つです。



まとめると



そこで、プログラマー向けの主な特定のストレス要因を定式化します。

プログラマーはほとんどの時間を自分の過ちと戦っています。 書かれたばかりのコードは、常にエラーを引き起こします。

プログラマーは、犯す間違いはほとんど遅かれ早かれ現れることを知っています。 これらの症状を待つと、それらが落ち込みます。



ご存知のように、人間の脳は穏やかな状態で全身で消費されるエネルギーの20%を消費します。 複雑な知的問題を解決するとき、その割合は40%に上昇します。 プログラマーは、高い創造力と心理的集中力を消耗するモードで常に働くことを余儀なくされています。


それで何? ストレスを避ける方法は? (または新しい年に新しい生活を始める方法)



すでに述べたように、私は心理学とは程遠い。 また、友人、彼の同僚、このトピックに関する数多くの本や映画の著者からパンを取ろうとはしません。 それでも、私はいくつかの簡単なヒントを与えるリスクがあります。 おそらく、私と同じように、私は新年がより正確に生き始めるための誓いを立てます。 その後、私のアドバイスが重宝するかもしれません。



  1. 病気のヒーローは誰も必要としません。 結果を達成するには、良好な身体的健康と創造的な回復が必要であることを忘れないでください。 そうでない場合、結果はありません。 あなたは一日中調子が悪く、コードは不完全に書かれています。 これについて夕方に苦しむことはありません。 自宅の温度計で日中行われなかった脇の下を仕上げようとしないでください。 蜂蜜入りのお茶を飲んで早めに寝る方が良い。
  2. 適切なミックス。 プログラミングは、ロングジャンプと比較できます。 ジャンパーのみが最初に高速で実行されてからジャンプし、プログラマーは洞察力のある解決策(ジャンプ)を持ってから、必要なルーチン操作を完了します。 8時間連続でジャンプすることは不可能です。 創造的な飛行と日常をミックスします。
  3. 仕事中にリラックスすることを学びます。 プロジェクトマネージャー、特に大規模なマネージャーは、プログラマーにとってほとんど役に立たない会議でやりすぎをする傾向があります。 避けられない場合は、会議の無駄な時間やおしゃべりな参加者に腹を立てないでください。 あなたの何かを考えて、意識の二次的な道でおしゃべりをしましょう。 あなたの顔に思慮深く興味のある表現を受け入れることを学びます。
  4. 毎日の成功を計画します。 タスクを1〜2時間でプログラムできると予想される部分に分割します。 最後の手段として、営業日の終わりまで何かを「四捨五入」する希望が残るように、その日の計画を調整します。
  5. 勝利で営業日を締めくくりましょう。 勤務時間の30分前または1時間前に問題を解決できた場合は、新しい問題を開始しないでください。 ほとんどの場合、頭の「バッテリー」はすでに「フック」されています。 たぶん、出張レポートなどのいくつかの組織的なタスクを蓄積しましたか? また、5分後に外出して電車に乗る必要がある場合は、コンピューターの電源を切り、別の行を書こうとしないでください。 書かれた線は何もしない可能性が高いですが、電車の通過のために、あなたはあなた自身に腹を立てます。 そして最も重要なことは、さらに2時間以上仕事を続けると、解決策はほとんどないでしょう。 しかし、家に帰る途中で、それは非常によく来るかもしれません。 自分で何度もテストしました。


繰り返します。 このテキストは、材料と議論の選択において科学的な深さと徹底したもののふりをしていません。



あなたの意見を知りたいと思います。 そのため、以下の質問にお答えください。



そして、私の議論が気に入らなかったら、記事のマイナスではなくコメントにあなたの反対を反映してください。 結局のところ、新年は鼻にかかっています。



「JavaScriptプログラマーの悪夢」の著者のイラスト



All Articles