自洽なプログラマー

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

何为第一性原理思考#

第一性原理这个词，最早是亚里士多德提出来的。不过要不是马斯克天天挂在嘴边，这个词可能现在还躺在哲学书的角落里吃灰呢。

简单来说，第一性原理就是：不人云亦云，不轻信二手结论，而是从最基本的事实出发，重新思考问题。

来个栗子🌰#

马斯克想造火箭的故事可能你们都听腻了，但这真的是个绝佳的例子：

当所有人都在说 "火箭太贵了，造不起" 的时候，马斯克在想啥？ - "等等，火箭到底是啥玩意儿？" - "造个火箭要多少铝合金、多少燃料？" - "这些原材料一共才多少钱？" - "为啥组装起来就贵了这么多？"

这就像我们写代码，与其复制 Stack Overflow 上的答案，不如想想这段代码到底要解决什么问题，从零开始写会是什么样。

为什么要用第一性原理思考工作#

在职场里，我们经常被各种 "你应该..." 给包围了：

"你应该去大厂"（BAT 是程序员的终极梦想？）
"你应该转管理"（技术大牛就该带团队？）
"你应该卷起来"（不卷就会被优化？）
"你应该 35 岁前达到 P8"（为啥不是 38 岁？）
"你应该像隔壁老王一样努力"（老王也想像你一样清闲...）

这些 "应该" 是从哪来的？

1. 社会压力#

爸妈的期望："你看隔壁家小明..."
同学的压力："他们都在大厂..."
社会舆论："35 岁危机..."

2. 行业惯性#

"前端必须会 React"
"后端必须会分布式"
"全栈工程师才有前途"

3. 个人认知局限#

"大家都这么做，我也这样吧"
"按老方法来准没错"
"不确定的事情最可怕"

但是，用第一性原理思考的话，最基本的问题其实是： "我为什么要上班，为什么要写代码？"

工作认知的演进#

初入职场：简单粗暴#

刚开始工作时，想法特别纯粹：

赚钱，养活自己
学技术，长经验
独立，不啃老
证明自己，我行的！

真实案例#

小辣条（没错，就是我）刚毕业时：

"月薪过万就满足了"
"有免费零食的公司就是好公司"
"能学到技术就行"
"领导夸我代码写得好，开心！"

那会儿想法简单，就想着能糊口就行，这没啥不好，都是必经之路。

工作三五年后：开始怀疑人生#

工作几年后，你可能会发现，代码写得越多，问题越多：

"我到底喜欢写代码吗？还是只是因为工资还不错？"
"为啥我天天加班改 Bug，隔壁老王天天摸鱼还升职了？"
"这工作到底是我想要的，还是别人眼中的 ' 好工作 '？"
"35 岁危机是真的假的？要不要转管理？"
"要不要跳槽？要不要创业？要不要躺平？"

典型困惑#

"工资是涨了，但感觉越来越菜了"
"技术越学越深，但好像离产品越来越远"
"工作稳定，但无聊得想打瞌睡"
"收入可观，但头发越来越少"

这时候我们开始关注一些更深层次的问题：

"我还能卷几年？"
"要不要转行？"
"要不要考个公务员？"
"要不要回老家开个串串香？"

更成熟的阶段：开始看透#

经过多年摸爬滚打，很多人会达到一个更通透的状态：

不再焦虑要不要转管理（反正都是坑）
不再纠结要不要进大厂（大厂也裁员）
找到了自己的节奏（摸鱼和卷，都是人生的一部分）
建立了自己的判断标准（老板开心不是最重要的，自己开心才是）

真实案例#

辣条（还是我）十年工作感悟：

从 BAT 离职后选择了小公司（钱少事少，生活质量高）
拒绝了几个管理岗位（我还是喜欢写代码）
有时间陪家人了（再也不用和老婆解释为什么要加班）
开始做副业（加密货币搞起来）
心态更佛系了（项目延期？延就延吧，天还没塌）

用第一性原理重新思考工作#

让我们把所有的条条框框都扔掉，重新想想：工作到底是个啥玩意儿？

1. 工作是价值交换#

就像 API 调用：

Request：
时间（每天 8 小时，加班另算）
技能（CRUD boy 的自我修养）
创意（产品经理的需求该怎么实现）
体力（连续调试 8 小时的专注力）
Response：
工资（房贷车贷的解药）
经验（从 Bug 中学习）
人脉（同事，未来的创业伙伴？）
成就感（这个 Bug 终于改完了！）

2. 工作是成长的游戏#

技能树不断升级
认知水平不断提升
思维方式不断进化
社交能力不断提高

就像玩 RPG 游戏，工作就是主线任务，但别忘了还有支线任务（副业）和休闲任务（生活）。

3. 工作是人生的一部分#

不是全部（还有老婆孩子热炕头）
需要平衡（头发和工资不可兼得）
要有边界（下班就是下班，工作群设置免打扰）

建立自己的工作观#

1. 摆脱 "应该" 的束缚#

不是非要进大厂（小公司也能过得很滋润）
不是非要当领导（技术专家也很香）
找到自己的节奏（有人喜欢冲刺，有人喜欢马拉松）

2. 建立健康的工作边界#

该摸鱼时摸鱼
该努力时努力
该休息时休息

3. 保持进化和迭代#

定期反思和总结（就像代码要重构）
及时调整方向（需求变了就要改方案）
保持开放和学习（新框架要学，新语言要懂）

实践建议#

定期和自己对话
每月反思：这个月摸鱼摸得值得吗？
记录心情，看见自己的情绪：今天改 Bug 改得想跳楼了吗？
复盘得失：这个项目坑在哪里？
建立评估框架
工作是否开心？
技术是否进步？
钱是否够花？
及时做出调整
不爽就换（总有更适合的坑）
相信直觉（心累就该走了）
大胆尝试（最差也就是回去继续写 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. 職業的成長#

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

最後の数言#

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

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

最後に、苦闘は常態ですが、楽しさもまた可能です！あなたは仕事の苦闘の現実をコントロールできませんが、現実に直面する自分の心の持ち方をコントロールできます。

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. 学習体系を築く#

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

最後の言葉#

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

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

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