自洽なプログラマー

1.1 第一性原理思考工作 - 自洽的程序员关于程序员职场和生活的思考#

何が第一性原理思考なのか#

第一性原理という言葉は、最初にアリストテレスによって提唱されました。しかし、もしマスクが毎日口にしていなければ、この言葉は今も哲学書の隅で埃をかぶっていたかもしれません。

簡単に言えば、第一性原理とは：他人の意見に流されず、二次的な結論を軽信することなく、最も基本的な事実から出発して問題を再考することです。

例を挙げてみましょう🌰#

マスクがロケットを作りたいと思った話は、皆さんも聞き飽きているかもしれませんが、これは本当に素晴らしい例です：

皆が「ロケットは高すぎて、作れない」と言っているとき、マスクは何を考えていたのでしょうか？ - 「待って、ロケットって一体何だ？」 - 「ロケットを作るのにどれだけのアルミニウムと燃料が必要なんだ？」 - 「これらの原材料は合計でいくらか？」 - 「なぜ組み立てるとこんなに高くなるのか？」

これは私たちがコードを書くときに似ています。Stack Overflow の回答をコピーするのではなく、このコードが解決しようとしている問題は何かを考え、ゼロから書くとどうなるかを考える方が良いのです。

なぜ第一性原理思考で働く必要があるのか#

職場では、私たちはしばしば「あなたは... すべきだ」といった様々な圧力に囲まれています：

「あなたは大企業に行くべきだ」（BAT はプログラマーの究極の夢？）
「あなたは管理職に転職すべきだ」（技術の達人はチームを率いるべき？）
「あなたは競争に巻き込まれるべきだ」（競争しなければ最適化される？）
「あなたは 35 歳までに P8 に到達すべきだ」（なぜ 38 歳ではないのか？）
「あなたは隣の老王のように努力すべきだ」（老王もあなたのようにのんびりしたいと思っている...）

これらの「すべき」はどこから来たのでしょうか？

1. 社会的圧力#

親の期待：「隣の家の小明を見て...」
同級生の圧力：「彼らは皆大企業にいる...」
社会的な世論：「35 歳危機...」

2. 業界の慣性#

「フロントエンドは React を使うべきだ」
「バックエンドは分散型を使うべきだ」
「フルスタックエンジニアだけが将来がある」

3. 個人の認識の限界#

「皆がそうしているから、私もそうしよう」
「古いやり方でやれば間違いない」
「不確実なことが最も恐ろしい」

しかし、第一性原理で考えると、最も基本的な問題は実際には：**「なぜ私は働かなければならないのか、なぜコードを書かなければならないのか？」** です。

仕事の認識の進化#

初めての職場：単純明快#

仕事を始めたばかりの頃、考えは非常に純粋でした：

お金を稼ぎ、自分を養う
技術を学び、経験を積む
独立し、親に頼らない
自分を証明する、私はできる！

実際のケース#

小辣条（そう、私です）が卒業したばかりの頃：

「月給が 1 万を超えれば満足だ」
「無料のスナックがある会社は良い会社だ」
「技術が学べればそれでいい」
「上司が私のコードを褒めてくれた、嬉しい！」

その頃の考えは単純で、生活できればそれで良いと思っていました。これには何の問題もなく、誰もが通る道です。

仕事を始めて 3〜5 年後：人生に疑問を持ち始める#

数年働いた後、コードを書くほど問題が増えていくことに気づくかもしれません：

「私は本当にコードを書くのが好きなのか？それともただ給料が良いからなのか？」
「なぜ私は毎日残業してバグを修正しているのに、隣の老王は毎日遊んで昇進しているのか？」
「この仕事は私が本当に望んでいるものなのか、それとも他の人が見ている「良い仕事」なのか？」
「35 歳危機は本当にあるのか？管理職に転職すべきか？」
「転職すべきか？起業すべきか？横になっているべきか？」

典型的な混乱#

「給料は上がったが、ますます無能になっている気がする」
「技術を学べば学ぶほど、製品から遠ざかっているように感じる」
「仕事は安定しているが、退屈すぎて居眠りしたくなる」
「収入は良いが、髪の毛がどんどん少なくなっている」

この時、私たちはより深い問題に目を向け始めます：

「私はあと何年競争できるのか？」
「転職すべきか？」
「公務員試験を受けるべきか？」
「故郷に帰って串焼き屋を開くべきか？」

より成熟した段階：物事を見抜くようになる#

何年もの試行錯誤を経て、多くの人がより透徹した状態に達します：

管理職に転職するべきかどうかを気にしなくなる（結局どちらも罠だ）
大企業に入るべきかどうかを悩まなくなる（大企業もリストラする）
自分のペースを見つける（遊ぶことと競争することは人生の一部だ）
自分の判断基準を確立する（上司が喜ぶことが最も重要ではなく、自分が喜ぶことが最も重要だ）

実際のケース#

辣条（また私です）が 10 年の仕事の感想：

BAT を辞めて小さな会社を選んだ（お金は少ないが、仕事は少なく、生活の質は高い）
いくつかの管理職のオファーを断った（私はやはりコードを書くのが好きだ）
家族と過ごす時間ができた（もう妻に残業の理由を説明する必要はない）
副業を始めた（暗号通貨に取り組んでいる）
心の持ち方がより穏やかになった（プロジェクトが遅延？遅れればいい、天は崩れない）

第一性原理を使って仕事を再考する#

すべての枠組みを捨てて、再び考えてみましょう：仕事とは一体何なのでしょうか？

1. 仕事は価値の交換#

API の呼び出しのように：

リクエスト：
時間（毎日 8 時間、残業は別計算）
スキル（CRUD ボーイの自己修養）
創造性（プロダクトマネージャーの要求をどう実現するか）
体力（8 時間連続デバッグの集中力）
レスポンス：
給料（住宅ローンや車のローンの解毒剤）
経験（バグから学ぶ）
人脈（同僚、将来の起業仲間？）
達成感（このバグがやっと修正できた！）

2. 仕事は成長のゲーム#

スキルツリーが常にアップグレードされる
認識レベルが常に向上する
思考方法が常に進化する
社交能力が常に向上する

RPG ゲームをプレイするように、仕事はメインクエストですが、サブクエスト（副業）やリラックスのクエスト（生活）も忘れないでください。

3. 仕事は人生の一部#

全てではない（妻や子供、温かい布団もある）
バランスが必要（髪の毛と給料は両立しない）
境界を持つ必要がある（仕事が終われば仕事、仕事のグループは通知をオフにする）

自分の仕事観を確立する#

1. 「すべき」の束縛から解放される#

大企業に入る必要はない（小さな会社でも豊かに暮らせる）
リーダーになる必要はない（技術の専門家も魅力的だ）
自分のペースを見つける（誰かはスプリントが好きで、誰かはマラソンが好き）

2. 健康的な仕事の境界を確立する#

休むべきときは休む
努力すべきときは努力する
休息すべきときは休む

3. 進化と反復を維持する#

定期的に反省とまとめを行う（コードをリファクタリングするように）
方向を適時調整する（要求が変わったら計画を変更する）
開放的で学び続ける（新しいフレームワークを学び、新しい言語を理解する）

実践的な提案#

定期的に自分と対話する
毎月反省：今月の遊びは価値があったか？
気分を記録し、自分の感情を見つめる：今日はバグを修正して自殺したくなったか？
反省して得失を振り返る：このプロジェクトはどこが問題だったのか？
評価フレームワークを確立する
仕事は楽しいか？
技術は進歩しているか？
お金は足りているか？
適時調整を行う
不満があれば変える（もっと適した場所があるはず）
直感を信じる（心が疲れたら去るべきだ）
大胆に試す（最悪でも戻って CRUD を書くだけ）

最後の数言#

第一性原理で仕事を考えることは、既存のすべてを否定するためではなく、私たちを助けるためです：

本質を見抜く（仕事は交換である）
基準を確立する（楽しむことが最も重要）
選択を行う（人生は短い、損失を最小限に抑える）

筆者は強調したいのですが、あなたの仕事に対する認識は、年齢や経験とともに変化し続けるものです。これは非常に正常なことです。重要なのは、自分に「なぜ働かなければならないのか？」と定期的に問いかけることです。この問題を時折考えることで、コードの細部や仕事の煩雑さの中で、現段階で本当に望んでいるものを見つめ直すことができます。

結局のところ、人生は短い、コードは甘い。🍬

1.2 仕事の苦闘は常態 - 自洽のプログラマーによるプログラマーの職場と生活に関する考察

今日は苦闘しましたか？#

「今日の要求は三回変更された...」「このバグは一週間修正しても解決しない...」「プロダクトマネージャーがまた要求を変更した...」「リーダーが週末に残業するように言った...」

もしあなたもこのような感嘆をしばしば発するのであれば、心配しないでください、あなたは一人ではありません。すべてのプログラマーが苦闘しています。ただし、苦闘の仕方は人によって優雅だったり、狼狽したりするだけです。

プログラマーの日常的な苦闘#

技術的な苦闘#

「このフレームワークのドキュメントは天書のようだ...」
「このコードはどの祖先が書いたのか？注釈はどこだ？」
「なぜ私のローカルではうまく動いているのに、オンラインにすると壊れるのか？」
「このバグは一体どこから来たのか？」

ビジネスの苦闘#

「プロダクトマネージャー、私たちはちゃんと話せますか？」
「この要求は本当に誰かが使うのか？」
「また要求を変更するのか？あなたがコードを書くべきではないか？」
「この機能は本当に今週リリースする必要があるのか？」

チームの苦闘#

「コードレビューでまた指摘されたのか？」
「なぜ私のコードはいつも不規則だと言われるのか？」
「老王のコードは私には理解できない...」
「新しく入った同僚のレベルが少し低くて、指導するのが疲れる...」

なぜ苦闘するのか？#

1. 技術の進化が早すぎる#

昨日のベストプラクティスが、今日は逆の教材になる
Vue2 をやっと覚えたのに、Vue3 が出てきた
Redux を理解したばかりなのに、Mobx が流行っている
Docker を始めたばかりなのに、k8s が来た

まるであなたが買ったばかりの iPhone 13 の直後に iPhone 14 が発表されたような感じです。この感覚は、わかる人にはわかります...

2. ビジネス要求が不安定#

プロダクトマネージャーの日常的なセリフ：

「この機能はとても簡単だ、仕事が終わる前に終わらせられるだろう？」
「クライアントが少し変更したいと言っている、ちょっとした要求を変更するだけだ」
「この要求は非常に急いでいる、今日中にリリースできるか？」

「簡単」という言葉を聞くたびに、心の中でドキッとします。なぜなら、経験が教えてくれるからです。プロダクトマネージャーが言う「簡単」は、往々にして徹夜を意味します。

3. 人間関係が複雑すぎる#

プロダクトマネージャーは自由な発想を求める
テストはゼロ欠陥を求める
オペレーションは迅速なリリースを求める
ボスはコスト削減と効率向上を求める
私はただ静かにコードを書きたいだけ

これはまるでマルチプレイヤーオンラインゲームをプレイしているようで、誰もが C 位になりたいと思っていますが、最後に責任を負うのは往々にしてプログラマーです...

苦闘の本質は何か？#

実際、仕事の中での苦闘は、いくつかの状況に過ぎません：

1. 能力と要求の不一致#

プロジェクトの要求：分散アーキテクチャに精通していること
現実の状況：CRUD に熟練していること
最終結果：毎日残業しても終わらない

2. 期待と現実の不一致#

期待：心を無にして優雅なコードを書くこと、世界を変えること
現実：毎日バグを修正し、あらゆる方向から要求に対処すること
結果：毎日人生に疑問を持つ

3. 努力と報酬の不一致#

努力：毎日 12 時間働く
報酬：給料の上昇は物価に及ばない
収穫：髪の毛がどんどん少なくなる

どうやって優雅に苦闘するか？#

1. 心の持ち方を調整する#

バグを得点問題として扱う
残業を充電時間として扱う
要求の変更をトレーニングとして扱う
責任を負うことを経験として扱う

（まあ、これは「精神的勝利法」のように聞こえるかもしれませんが、本当に役立ちます！）

2. 能力を向上させる、苦闘が激しいほど成長が早い#

毎日新しいスキルを学ぶ
問題に直面したらまず自分で解決する
反省とまとめをしっかり行う
知識体系を構築する

3. 防御線を築く#

技術的に：
少なくとも一つの分野に精通する
少なくとも一つの方向に深く入る
少なくとも一つの特技を際立たせる
ソフトスキルにおいて：
プロダクトマネージャーと交渉することを学ぶ
テストと理論を話すことを学ぶ
リーダーに「ノー」と言うことを学ぶ
同僚と助け合うことを学ぶ

苦闘の中での成長#

1. 技術的成長#

「このバグはどう修正するのか？」から「なぜこのバグが発生したのか？」へ
「このコードはどう書くのか？」から「このコードはどう設計すべきか？」へ
「コピー＆ペースト」から「ソースコードを見て答えを探す」へ

2. 思考の成長#

「タスクを完了する」から「問題を解決する」へ
「コードを書く」から「計画を書く」へ
「バグを修正する」から「バグを防ぐ」へ

3. 職業的成長#

「受動的に要求を受ける」から「能動的に提案をする」へ
「ただコードを書く」から「意思決定に参加する」へ
「単独で戦う」から「チームで協力する」へ

最後の数言#

仕事の中での苦闘は、人生の必修科目のようなものです：それはあなたのせいではありませんが、あなたが解決しなければなりません。あなたが制御できないことですが、あなたが責任を持たなければなりません。あなたが望んでいないことですが、あなたが直面しなければなりません。

苦闘を嘆くよりも、苦闘を成長の機会と捉えましょう。コードをリファクタリングするように、苦闘のプロセスも自分をリファクタリングするプロセスです。

最後に、苦闘は常態ですが、喜びもまた可能です！あなたは仕事の苦闘の現実を制御できませんが、現実に直面する自分の心の持ち方を制御することはできます。

1.3 仕事はあまり多くの意味を持たないが、仕事の虚無主義に陥ってはいけない - 自洽のプログラマーによるプログラマーの職場と生活に関する考察

仕事に関する二つの極端#

最近、プログラマーのグループで、二つの極端な声をよく見かけます：

極端 1：仕事は生活のすべて#

「残業しなければ進歩できないのか？」
「競争しなければ成功できないのか？」
「仕事は生活の意味だ！」
「多く働かなければ未来はない！」

この人たちは仕事を人生のすべてと見なし、まるで働かなければ生きていけないかのようです。毎晩深夜まで残業し、週末も仕事を考え、SNS には技術記事ばかり...

極端 2：仕事は生命の浪費#

「仕事はお金を稼ぐためだけだ」
「結局、すべてはボスのために働くことだ」
「仕事は生命の浪費だ」
「遊べるなら遊ぶべきだ」

これらの人々は仕事に全く意味がないと考え、働くことは生命を消耗するだけで、稼ぐこと以外に何の意味もないと思っており、すぐに辞職して放浪したいと考えています。

なぜこの二つの極端が存在するのか？#

1. 社会的圧力#

住宅ローンや車のローンの圧力
35 歳危機の不安
同年代との比較
親の期待

2. インターネットの拡大効果#

成功学の洗脳
躺平学の誘惑
様々な極端な意見の拡散
逆境の蓄積

3. 個人の認識の限界、もちろん現在の主流の仕事倫理も#

仕事を生活と同一視する
仕事の努力を最高の道徳と同一視する
収入を価値と同一視する
地位を能力と同一視する
忙しさを進歩と同一視する

仕事は結局何を担っているのか？#

1. 最も基本的なこと：生存の必要#

食べること（これは最も基本的なこと）
家（住む場所）
車（移動手段）
医療保険（万が一に備えて）

2. 進化したもの：成長の必要#

スキルの向上
視野の拡大
人脈の蓄積
経験の蓄積

3. より高いレベル：自己実現#

達成感
価値の認識
社会への貢献
個人の影響力

仕事の真実は何か？#

1. 仕事は全てではなく、虚無でもない#

それは生活の一部だが、全てではない
それには価値があるが、唯一の価値ではない
それは真剣に取り組む価値があるが、あまり真剣になりすぎてはいけない
それには投資が必要だが、無限の投資ではない

2. 仕事はバランスである#

理想と現実の間で
努力と報酬の間で
個人とチームの間で
仕事と生活の間で

3. 仕事はプロセスである#

終点ではなく、旅である
結果ではなく、経験である
負担ではなく、選択である
束縛ではなく、機会である

どうやってバランスを見つけるか？#

1. 仕事に適切な位置を与える#

それを重く見すぎない
それを軽く見すぎない
自分が快適なリズムを見つける
健康的な距離を保つ

2. 多様な生活を築く#

仕事以外に趣味を持つ
職場以外に友人を持つ
技術以外に興味を持つ
収入以外に追求を持つ

3. 明晰な認識を保つ#

自分が何を望んでいるのかを知る
自分が何をしているのかを理解する
自分が何ができるのかを明確にする
自分が何をすべきかを理解する

具体的な提案#

1. 仕事の時間#

普通に仕事が終わったら帰る
週末はできるだけ残業しない
休暇はしっかり休む
遊ぶときはほどほどに

2. 仕事の態度#

真剣に取り組むべきときは真剣に
リラックスすべきときはリラックス
拒否すべきときは拒否
妥協すべきときは妥協

3. 仕事の方法#

効率を上げるが、時間を延ばさない
質を追求するが、数量を積み上げない
成長を重視するが、純粋な努力ではない
方法を重視するが、無謀にやらない

最後の数言#

仕事は人生の一つの次元のようなものです：それは重要だが、唯一ではない。それには投資が必要だが、度が必要だ。それは真剣に取り組む価値があるが、あまり執着しないでください。

仕事はより良い生活のためであり、生活を仕事の付属品にするためではありません。

私たちの目標は：真剣に働き、楽しく生きることです。仕事の奴隷にも、生活の逃げ人にもならないことです。

最後に、皆さんに一言：仕事と生活はコードと注釈のようなもので、どちらも欠かせないが、比率は適切であるべきです。

2.1 心の持ち方を開放することが、あなたの職場での第一の授業 - 自洽のプログラマーによるプログラマーの職場と生活に関する考察

なぜ心の持ち方を開放することが重要なのか？#

新しいフレームワークに初めて触れたときの感覚を覚えていますか？新しい概念が画面に溢れていると、あなたは私のように、すぐにエディタを閉じて、自分の「快適な巣」に戻りたくなるかもしれません。これは、海を見たことのないカエルが突然太平洋に投げ込まれたようなものです —— 慌てふためくのです。

しかし、知っていますか？この「慌てふためく」感覚こそが、私たちが成長の機会に出会ったことを示すことが多いのです。

固定的思考 vs 成長的思考#

思考のパターンについて言及する際に、心理学者のキャロル・ドウェックが提唱したこの二つのタイプを無視することはできません：

固定的思考の仲間たちは次のようです： - 「この新しいフレームワークは難しすぎて、私は学べない」 - 「私はバックエンドのプログラマーで、フロントエンドのことには触れたくない」 - 「私は 10 年間 Java を書いてきたので、この習慣を変えることはできない」 - 「新しい技術？他の人が失敗した後に考えよう」

聞いたことがあるように感じませんか？これは、挑戦に直面すると頭を砂の中に埋める頑固なダチョウのようです。「見えなければ存在しない」と考えています。

成長的思考の仲間たちは次のようです： - 「理解できなくても、なんだか面白そうだ」 - 「一つのスキルを多く学べば、道が増える」 - 「試してみよう、最悪でもエラーが出るだけだ」 - 「失敗も経験の一部だ」

これは、好奇心旺盛な猫のようで、新しいものを見ると触ってみたくなり、新しい大陸を発見するかもしれません。

なぜ心の持ち方を開放することが第一の授業なのか？#

想像してみてください、あなたがカップだとしたら：

固定的思考は水が満杯のカップのようで、新しいものは入らない
成長的思考は空のカップのようで、新しい知識を受け入れる準備ができている

職場では、技術の更新があなたのスマートフォンのシステムよりも早いです。今日あなたが精通している技術は、明日には「伝統的な技術」となっているかもしれません。もし心の持ち方を開放しなければ：

新しい技術を学べない
新しい方法を使えない
新しい機会を逃す
新しい発展を見逃す

まるであの古い言葉のようです：「SELECT * FROM world WHERE 心の持ち方 = '開放'」—— まあ、これは私が作ったものですが、あなたは私の言いたいことを理解しています。

開放的な心の持ち方を育てる方法#

1. 「知らない」ことを受け入れる#

プログラマーに転職したばかりの頃、知らないことを他人に見つけられるのが非常に怖かったことを覚えています。質問する前に、半日我慢して、たくさんの資料を検索し、「これすら知らないのか」と言われるのが怖かったのです。

今思うと、これは公共の場で突然おならをしたくなるようなもので、我慢して自分を苦しめ、他の人に気づかれないように装う必要があるのです。実際、「知らない」と認めることは全く恥ずかしいことではありません。恥ずかしいのは：知らないのに知っているふりをすること（これは最も簡単に見破られる）、知らないのに学ばないこと（これは最も早く取り残される）、知らないのに質問しないこと（これは最も時間を無駄にする）です。

2. 「リセット」を学ぶ#

一定の期間ごとに、自分を「フォーマット」する必要があります：

既存の経験の偏見をクリアにする
仕事のやり方を再評価する
より良い解決策があるか考える

私たちのコンピュータのように、時々再起動してキャッシュをクリアし、システムを更新する必要があります。そうしないと、あなたはまだ IE ブラウザを使っていて、これが最良の選択だと信じているかもしれません。

3. 好奇心を持ち続ける#

好奇心は私たちの「スキルポイント」のようなもので、常に投資する必要があります：

新しい技術を見たら、「これは面白い」と考える
新しい方法に出会ったら、「なぜそうなのか」と尋ねる
新しいツールに出会ったら、「どう使うのか」と考える

ある同僚が言ったことを覚えています：「私は天才ではないが、好奇心旺盛な心を持っている。」そうです、職場での進歩は時にはこの「好奇心」の精神によってもたらされます。

4. 「試行錯誤」のメカニズムを構築する#

多くの人が新しいことを試すのを恐れるのは、間違いを犯すことを恐れているからです。しかし、考えてみてください：

テスト環境は間違いを犯すためにあるのではないか？
コードレビューは問題を発見するためにあるのではないか？
バージョン管理は後悔するためにあるのではないか？

「試行錯誤」を学びの一部と考えましょう。ゲームをプレイするように、何度か死ななければ地図を覚えることができるのです。これは非常に正常なことです。

開放的な心の持ち方の実践的提案#

1. 小さなことから始める#

最初から最も難しい骨を噛む必要はありません。次のようにできます：

今日は新しい IDE プラグインを試してみる
明日は新しいショートカットを学ぶ
明後日は新しいデバッグ方法を試す

ゲームをプレイするように、新人村から始めるように、一歩ずつ進んでいきましょう。

2. 学びの仲間を見つける#

同僚と学習グループを作る
技術コミュニティに参加する
技術の達人のブログをフォローする

仲間がいれば、一人で戦っていると感じることはなくなりますし、仲間は新しい視点やアイデアをもたらしてくれ、一定の監視の役割も果たしてくれます。

3. フィードバックループを構築する#

学びの成果を定期的にまとめる
遭遇した問題をタイムリーに記録する
自分の経験や体験を共有する

コードを書くときにユニットテストが必要なように、学びにもタイムリーなフィードバックが必要です。これは非常に重要です。なぜなら、フィードバックがあってこそ、自分の学びの効果を知ることができ、学びの方向が正しいかどうかを知ることができ、学び続けるモチベーションを持つことができるからです。

結論#

心の持ち方を開放することは、あなたを意見のない「風に流される草」にすることではなく、試すことを厭わない探求者、学ぶことを楽しむ追求者、変化を恐れない行動者になることです。

優れたプログラムのように、安定したコアロジックを持ちながら、十分な拡張性を持つことが必要です。開放的な心の持ち方を保つことは、自分の「プログラム」に十分なインターフェースを確保し、新しい更新やアップグレードをいつでも迎え入れる準備をすることです。

結局のところ、この急速に発展するインターネット時代において、唯一不変なものは変化そのものです。抵抗するよりも、受け入れる方が良いでしょう。開放的な心の持ち方で、職場の新たな旅を始めましょう！

2.3 助けを求めることは高度なスキル - 自洽のプログラマーによるプログラマーの職場と生活に関する考察

ある気まずい話から始める#

「えっと... 老王、このエラーはどう解決するの？」「自分でグーグルしてみた？」「ええと... まだ...」「......」

すべてのプログラマーがこのような気まずい経験をしたことがあると思います：問題を調査せずに同僚に尋ね、結果として嫌われる。しかし、逆のケースもあります：

「このバグは一週間も調査しているが、どうしても解決できない...」「なぜ早く言わなかったの？この問題は先週私が処理したばかりだ！」

これは非常に馴染み深いですよね？実際、この二つの状況は、私たちが助けを求めることができない、あるいは正しく助けを求めることができないことを示しています。

なぜ私たちは助けを求めることができないのか？#

1. 面子の問題#

「こんな簡単な問題を聞くと、私が無能に見えるのではないか？」
「もうこんなに働いているのに、これすらできないなんて、恥ずかしい...」
「万が一同僚に見下されるのではないか...」
「リーダーは私の能力が足りないと思うのではないか...」

2. 誤った認識#

「自分の問題は自分で解決すべきだ」
「優れたプログラマーは何でもできるべきだ」
「他人に尋ねるのは無能の証だ」
「独立して問題を解決することが真の能力だ」

3. 性格的要因#

内向的でコミュニケーションが苦手
他人に迷惑をかけたくない
拒絶されるのが怖い
社交不安症

助けを求めないことの結果#

1. 時間コスト#

経験豊富な同僚が 5 分で解決できる問題を
あなたは一日中模索することになる
プロジェクトの進行が遅れる
仕事の効率が著しく低下する

2. 心理的負担#

ますます焦りが募る
焦れば焦るほど詰まる
自信を失う
仕事への熱意が低下する

3. チームへの影響#

共有できたはずの経験が共有されない
避けられたはずの落とし穴が避けられない
チームの協力効率が低下する
同じ落とし穴を繰り返し踏む

いつ助けを求めるべきか？#

1. 自分で解決すべきとき#

基本的な文法の問題
簡単な設定の問題
一般的なエラーメッセージ
明確なエラーメッセージがある問題

2. 助けを求めるべきとき#

いくつかの方法を試したがうまくいかない
たくさんの資料を検索したが手がかりがない
長時間詰まっていて進展がない
歴史的な問題が関与している
ビジネスに関連する文脈が必要

助けを正しく求める方法#

1. 助けを求める前の準備#

問題を明確に説明する
どのような状況で発生したのか
どのような方法を試したのか
現在どのステップで詰まっているのか
関連情報を準備する
エラーログ
環境情報
再現手順
関連するコードスニペット

2. 適切な相手を選ぶ#

この分野に詳しい同僚
類似のプロジェクトを経験した先輩
関連する経験を持つ友人
特定の技術コミュニティの専門家

3. 適切なタイミングを選ぶ#

他の人が最も忙しいときに尋ねない
仕事が終わる直前に尋ねない
相手が会議中のときに尋ねない
できれば事前に時間を予約する

質問の技術#

1. 良い質問の仕方#

「XX 機能を実装する際に問題に直面しました...」
「A、B、C の方法を試しましたが、うまくいきませんでした...」
「おそらく XX が原因だと思いますが、あなたはどう思いますか？」
「この考えが正しいかどうか見てもらえますか？」

2. 悪い質問の仕方#

「これってどうやってやるの？」
「なぜ私のコードはうまくいかないの？」
「どこが間違っているか見てくれ」
「このバグはどう解決するの？」

3. 質問時の注意事項#

表現は明確かつ具体的に
態度は謙虚かつ誠実に
相手の時間を尊重する
まとめと感謝を忘れない

良性の循環を築く#

1. 迅速に記録しまとめる#

解決策を記録する
問題の原因をまとめる
関連する知識を整理する
他の同僚に経験を共有する

2. 他者に積極的にフィードバックを行う#

類似の問題に直面している同僚を助ける
自分の経験や教訓を共有する
技術的な議論や共有に参加する
チームの知識ベースに貢献する

3. 学びの体系を構築する#

一般的な問題を収集する
解決策を整理する
知識体系を構築する
経験を蓄積する

最後の言葉#

プログラマーという職業において、助けを求めることは能力不足の表れではなく、責任を回避するための言い訳でもなく、効率を向上させる方法であり、問題を解決する手段です。

コードの再利用が重要であるように、経験も再利用可能であり、知識も共有可能であり、成長も相互に助け合うことができます。

助けを求めることができるプログラマーこそが、本当の達人です。彼が何でもできるからではなく、彼が問題をより早く解決する方法を知っているからです。

2.4 対立を直面することが怖い、どうすれば立ち上がれるか - 自洽のプログラマーによるプログラマーの職場と生活に関する考察

「老王、あなたのコードは本当にひどいですね？」「何ですって？私のコードはどうしたの？」「あなたの変数名、このコードの構造、これが人に理解できるものですか？」「私はそれが良いと思っていた、動けばいいじゃないか...」「動けばいいって？！後で誰がメンテナンスするか分かっているのか？」

場面は一度非常に気まずくなりました。

コードレビューの現場での失敗は、多くの人が経験したことでしょう。しかし、私たちの反応は多くの場合：

静かに「受け取りました」と言って、再び遊び続ける
心の中で相手が細かすぎると悪態をつきながら、口では「分かりました、修正します」と言う
修正が終わったらすぐにプロダクトに文句を言う：「この要求はもともと不合理だった！」
職場のグループで反論できず、すぐに相手をブロックする

正直なところ、誰もが最初は臆病だったのではないでしょうか？私自身、仕事を始めた頃は、本当に臆病でした。プロダクトマネージャーが要求を変更すると、静かに受け入れ、テストがバグを指摘すると、静かに修正し、リーダーが残業を言うと、静かに残業しました... ある日、我慢できなくなりました。

なぜ私たちはこんなに臆病なのか？#

伝統文化が「良い人」を教えている#

私たちは小さい頃から「和をもって貴しとなす」と教育されてきました。小学校の頃から：

「同級生と仲良くしなさい」
「我慢すれば何も問題ない」
「損をすることは福である」これらの言葉を耳にタコができるほど聞いてきました。

職場に入ると、この考え方はさらに強まります：

「皆は同僚だから」
「和気あいあいが財を生む」
「一事を多くするより少なくする方が良い」

結果として、職場には「良い人」がたくさん生まれました。

誰かを傷つけるのが怖い#

これは私たちが臆病であることを責めることはできません。実際には：

テストを傷つければ、あなたのバグは通過できない
プロダクトを傷つければ、次の要求はあなたを疑うことになる
リーダーを傷つければ、あなたのパフォーマンスが危うくなる
同僚を傷つければ、コードレビューで問題を指摘され続ける

さらに厄介なのは、今では「チームワーク」が重視されています。誰かを傷つければ、群れ全体を傷つける可能性があります。誰もが食べていくために頑張りたいのですから。

技術的な自信が不足している#

実際、多くの場合、私たちが反論できないのは：

コードが本当に良くないから
技術的な深さが本当に不足しているから
プランに本当に穴があるから
経験が本当に不足しているから

非常に気まずいです。相手が言っていることが完全に正しくないと知っていても、理由を説明できないのです。

臆病でいると、問題が発生する#

技術的負債がどんどん増える#

今日、妥協して悪いプランを使った
明日、妥協して悪いコードを書いた
明後日、妥協して悪い要求を変更した最終的に？プロジェクト全体がドロドロになる。

以前、ある「一時的なプラン」を 2 年間使ったことがあり、最後にリファクタリングするときには、触れることすらできず、システム全体が崩壊するのが怖かったのです。

責任を負う人が本当に責任を負う#

テストがバグがあると言えば、静かに修正する
プロダクトが要求を変更すれば、静かに修正する
オペレーションが機能を追加すれば、静かに修正する
リーダーが最適化を求めれば、静かに修正する

結果はどうなるのか？何か問題が発生すれば：「このコードは誰が修正したの？」「ああ、小王だ、毎回彼が修正している...」

職場で透明人間になる#

長い間：

技術的な議論で発言できない
プランのレビューで反対できない
アイデアがあっても言えない
提案があっても我慢する

最終的にチームの中で透明人間になり、存在感は毎日の出勤だけになります。

対立は実際にはそれほど恐ろしいものではない#

職場での対立は非常に普通のこと#

コードを書くときと同じように：

異なる人は異なるコードスタイルを持つ
異なるチームは異なる技術スタックを持つ
異なるプロジェクトは異なる要求を持つ

意見の相違があるのは普通であり、意見の相違がない方が不自然です。

対立を機会と捉える#

コードレビューで指摘されることは、コードの質を向上させる機会である
プランが疑問視されることは、設計を改善する機会である
意見が一致しないことは、思考の衝突の機会である
要求に相違があることは、ビジネスを深く理解する機会である

どうやって強気になるか？#

まず技術力を向上させる#

要するに、自信が不足しているのは実力が不足しているからです。

学ぶべきことは：

コードを書くときは、なぜそう書くのかを考える
要求を受けるときは、どんな落とし穴があるのかを考える
プランを作るときは、同業者がどうしているのかを調査する
時間があればソースコードを見て、CRUD だけではなく理解を深める

正しく表現することを学ぶ#

以前の私の表現方法は：「これ... おそらく... 問題があるかもしれない...」

今の私の表現方法は：「このプランには 3 つの問題があると思います：1. パフォーマンスにボトルネックがあるかもしれない 2. 拡張性があまり良くない 3. メンテナンスコストが高くなると思います。私たちは...」

対立を協力に変える#

対立するよりも：

「あなたの要求はあまりにも頻繁に変更されている！」
「あなたのコードは本当にひどい！」
「あなたのテストはあまりにも細かすぎる！」

むしろ：

「まず核心的な要求を確認しましょうか？」
「一緒にコードを最適化する方法を考えましょうか？」
「テストケースは優先順位を付けることができるのではないでしょうか？」

最後に二言#

職場での対立は、コードのバグと同じです。出会うのは普通であり、解決することが重要であり、回避することはできません。適時処理することが必要です。

重要なのは、対立を避けることではなく、対立を処理することを学ぶことです。

覚えておいてください：

言葉に出すことは、心の中に留めておくよりも良い
問題を表に出すことは、裏でこそこそするよりも良い
意見の相違を直接議論することは、裏で愚痴を言うよりも良い

最後に、皆さんが職場での「強者」になり、対立を恐れないことを願っています。

2.5 職場の PUA にどう対処するか - 自洽のプログラマーによるプログラマーの職場と生活に関する考察

「小王、隣のチームの小張を見て、彼は週末も残業しているよ...」「この程度のコード量で、いつまでかかるの？」「あなたの年齢の時、私はもうシニアエンジニアだった...」「残業しない？あなたは会社に対する帰属意識がないのか？」

耳にしたことがありますか？これは普通の説教ではなく、露骨な職場の PUA です。

職場の PUA とは何か？#

簡単に言えば、さまざまな「一見合理的な」方法で、あなたの自信を打撃し、あなたの行動をコントロールすることです。

一般的な PUA のセリフ#

プロダクトマネージャー版：

「他の開発者はこの要求が簡単だと言っている」
「ちょっとした要求を変更するだけで、どうしてこんなに時間がかかるのか？」
「あなたは某某のように、できないとは言わない」

技術リーダー版：

「こんな簡単なバグをどうして犯すのか？」
「このコードがこうなっているのは、どうやって面接に通ったのか？」
「あなたのコードのレベルは、あまり進歩していないようだ」

HR 版：

「同期の小李を見て、彼はもう昇進している」
「あなたはこのパフォーマンスで、年末ボーナスがどれだけもらえると思う？」
「今は外の市場が悪いから、この機会を大切にしなさい」

なぜ PUA に遭遇するのか？#

1. 地位が低すぎる#

新卒で経験がない
技術的な深さが不足している
経歴が浅い
発言権がない

私が仕事を始めた頃、コードを修正するたびに十回も叱られ、要求を書くたびに八百回も修正させられ、「これすらできないのか？」と言われていました。

2. 手法を知らない#

多く働けば出世できると思っている
我慢すれば平穏でいられると思っている
努力すれば報われると思っている
正直であればいじめられないと思っている

結果として？正直であればあるほどいじめられ、我慢すればするほどつけあがるのです。

3. 反抗する勇気がない#

「万が一リーダーを傷つけたらどうしよう？」
「HR を傷つけたら、嫌がらせを受けるのではないか？」
「今は仕事を見つけるのが難しい...」
「我慢すれば過ぎ去るだろう...」

PUA の結果はどれほど深刻か？#

1. 身心ともに疲弊する#

仕事に情熱がない
睡眠がうまく取れない
出勤時に不安になる
特定の人を見ると胃が痛くなる

2. 職業的な成長が妨げられる#

自信が打撃を受ける
創造性が抑圧される
主体性が失われる
成長の余地が制限される

3. ますます競争が激化する#

今日：

「週末に残業しよう」明日：
「今月はもっと働こう」明後日：
「あなたを見て、他の人は...」

職場の PUA にどう対処するか？#

1. 目を光らせ、PUA を見抜く#

正常な批判：

「このコードは最適化できる、私たちで一緒に見てみましょう」
「このバグは次回注意してください、私は排除の考え方を教えます」
「最近進捗が遅いですが、何か困難に直面していますか？」

PUA 式の批判：

「こんな簡単なコードすら書けないのか？」
「こんな低レベルのバグを犯すなんて、どう考えているのか？」
「あなたの効率は、どうしてプログラマーになったのか？」

2. 自己防衛を築く#

仕事の内容を記録する
毎日何をしたのか
どの問題を解決したのか
どのような価値を提供したのか
証拠を残す
チャットの記録を保存する
メールのやり取りを保存する
重要な会議の内容を記録する
境界を設ける
仕事の時間には度が必要
残業には補償が必要
職務には境界が必要

3. 正面から応じることを学ぶ#

PUA：こんな簡単な要求を、どうしてこんなに時間がかかるのか？応答：

「この要求は A、B、C の三つのモジュールの変更が関与しているので、3 日間必要だと評価しています」
「私はすでに 70％を完了しましたが、どの部分を加速できると思いますか？」
「もし時間が長すぎると思うなら、一緒に何を最適化できるか見てみましょう」

PUA：あなたは小張を見て、週末も残業している... 応答：

「私は効率を重視しており、平日には仕事を計画しています」
「私の作業量と成果は要求を満たしており、問題がありますか？」
「私たちは成果で評価するのか、それとも残業時間で評価するのか？」

4. 後ろ盾を準備する#

技術を更新し続ける
人脈を広げる
市場の機会に目を向ける

特別な注意点#

1. PUA の変化を期待しない#

彼らは変わらないでしょう。なぜなら、PUA は彼らにとって効果的な管理手法であり、彼らも PUA に遭遇しているかもしれません。彼らはこのやり方が問題ないと考えています。

2. 自分を守る#

自分の健康が最も重要です。自分のメンタルヘルスを重視し、自分のキャリアを計画し、去るべきときには去るべきです。

3. 自分が PUA にならないように警戒する#

リーダーになったらこの手法を学ばない
新人を理論で納得させる
コードレビューは事実に基づいて行う
仕事のコミュニケーションは理論的に行う

最後の注意：

仕事はただの仕事である
会社はただの会社である
リーダーはただのリーダーである
あなたの人生は PUA によって台無しにされるべきではない

職場の PUA は、コードの無限ループのようなものです：早く見つけて飛び出せば間に合いますが、遅く見つけるとシステム全体が崩壊する可能性があります。

2.8 仕事に疲れたら、クローバーモデルを試してみて - 自洽のプログラマーによるプログラマーの職場と生活に関する考察

「最近仕事がとても疲れる、仕事は墓参りのようだ...」「体が疲れているのではなく、ただ... やる気が出ない」「毎日遊びたい、仕事に対して全く興味が持てない」

もしあなたもこのように感じているなら、クローバーモデルを使って自分を診断してみてください。

クローバーモデルとは何か？#

クローバーモデルはキャリアプランニングモデルで、仕事の動機を三つの葉に分けています：

興味の葉：仕事に対する情熱と愛情の程度
能力の葉：問題を解決する技術と才能
価値の葉：仕事がもたらす報酬と意味

この三つの葉は相互に影響し合い、欠かすことができません：

興味があれば、学習能力が向上する
能力があれば、より多くの価値を生み出すことができる
価値があれば、興味を持ち続けることができる

三つの疲労タイプ#

1. 倦怠型（興味の葉が枯れる）#

表れ：

毎日早く帰りたいと願う
コードを見るだけでイライラする
何にもやる気が出ない
仕事は完全にタスクを完了するためだけのもの

私の同僚が言ったように：「以前は新しい技術を見ると興奮したが、今は新しいフレームワークを見ると頭が痛くなる」「仕事を始めた頃は、週末に自分でコードを書いていたが、今は IDE を開くことすらしたくない」

2. 不安型（能力の葉が不足）#

表れ：

常にペースについていけないと感じる
新しい要求を受けるのが怖い
同僚のコードが理解できない
技術の共有時に落ち着かない

典型的なシーン：「プロダクトマネージャーがこれが簡単だと言ったが、私は半日見ても手がかりがなかった...」「同僚が二日で書き終えた機能を、私は一週間かかる...」

3. 失望型（価値の葉が欠如）#

表れ：

努力に対する報酬がない
努力が認められない
職業的な成長が見えない
自分が道具のように感じる

よくある不満：「私はシステム全体のパフォーマンスを最適化したが、リーダーは『それは当然だ』と言った」「残業して完成させたプランが、翌日『要求が変わった』と言われて否定された」

倦怠を治す方法#

1. 倦怠型の治療法#

第一歩：興味の源を取り戻す - なぜプログラミングを選んだのかを思い出す - かつて興奮した技術ポイントをリストアップする - 最も達成感を感じたプロジェクトを考える

第二歩：興味を再育成する - 自分が興味を持っているサイドプロジェクトを試す - 新しい技術やオープンソースプロジェクトを研究する - 同じ志を持つ同僚と一緒に何かを作る

第三歩：興味を転換する - 単調な仕事をゲーム化する - 日常の仕事で小さな目標を設定する - 自分に技術的な挑戦を課す

2. 不安型の治療法#

第一歩：能力のギャップを直視する - 具体的なスキルの短所をリストアップする - 現実的な学習目標を設定する - 実行可能な計画を立てる

第二歩：体系的に向上させる - 毎日固定の時間を学習に充てる - 挑戦的なプロジェクトに参加する - 上級者に教えを請う

第三歩：強みを活かす - 自分が得意な分野に集中する - 既存のスキルを極める - 自分に合ったポジションを見つける

3. 失望型の治療法#

第一歩：価値を再定義する - 外的な報酬だけでなく - 個人の成長に注目する - 仕事の他の意味を探す

第二歩：価値を創造する - 重要なタスクを積極的に引き受ける - チームの痛点問題を解決する - 仕事の可視性を高める

第三歩：プラットフォームを探す - より適したチームを選ぶ - 自分を評価してくれるリーダーを見つける - 価値観が一致する環境を探す

特別な注意点#

三つの葉は相互に影響し合います。興味を取り戻せば、能力が自然に向上し、能力を向上させれば、価値が自然に現れ、価値を得れば、興味がさらに深まります。
倦怠を治すには時間がかかります。すぐに結果を期待せず、緩衝期間を設け、忍耐と信頼を保ちましょう。
選択権はあなたにあります。チームを変えることも、方向を変えることも、新しい機会を探すこともできます。

コードのデバッグと同じように：まず問題を特定し（どの葉が問題なのか）、次に原因を分析し（なぜそうなのか）、最後に問題を解決します（対症療法を行います）。

プログラマーとして、バグを修正するときにそんなに執着するのだから、自分の倦怠を修正する際も同じくらい真剣であるべきです。

2.10 職場での選択をどうするか - 自洽のプログラマーによるプログラマーの職場と生活に関する考察

「転職すべきか？」「管理職に転職すべきか？」「このプロジェクトを受けるべきか？」「スタートアップに行くべきか？」

職場は常に選択をするプロセスです。しかし、多くの場合、私たちはランダムなバグをデバッグするように悩んでいます。

選択に困っている日常#

1. 転職の選択に困る#

現在の会社は完璧ではないが、非常に安定している
新しい会社は給料が高いが、どれだけの落とし穴があるのかわからない
現在の同