Get the problem right first

Show an engineer a problem and we start solving it before we’ve finished hearing it. Break it down, sketch the solution, lay out a roadmap, estimate the time, weigh the risks — that reflex is most of what got us hired, and it runs deep. What it skips is the one question that decides everything downstream: was this problem worth solving at all?

A couple of years ago, working through a strategy doc with my PM, I learned to slow down on that question. My early drafts went straight at solutions. The reply was always the same blunt prompt: what’s the problem to solve, is it the prioritized one, what happens if we don’t solve it? Round after round, the doc got shorter at the top and clearer underneath. Once the problem statements were right — a few tight bullet points — every solution, trade-off, and risk fell into place around them. I’d spent years believing the solution was the work. It turned out the problem was half of it. Back then it took a PM to force that pause; the rest of us were just too busy building.

Cheap building is a trap

Now anyone can get a solution off the ground, and that’s exactly why the deciding matters more. Someone who codes daily and someone who hasn’t in years can both point Claude Code at a problem and get something working; non-engineers sketch prototypes too. That moves the bottleneck: starting the technical work is no longer the slow step, so the scarce skill becomes the judgment around it — of the ten things I could build, which one or two are worth carrying through?

The trap is that cheap building makes us want to build everything. For years we couldn’t, and now we can, and it’s intoxicating. But building fast isn’t the same as launching well. A real launch still has to earn its way out: the refinement and edge cases for a product, the scaling and reliability for infra, the privacy and safety checks. That cost doesn’t shrink because the prototype came easy. So prototype freely — that part should stay wild — but when it’s time to commit, choosing what to focus on is the actual work.

Keep making the calls

A year ago the line going around was that AI won’t take our jobs, but a coworker who uses AI will — and there’s a quieter version of that I’d watch for in myself. If we lean on AI and stop critical thinking — hand off the building, ride the flow, quit pushing back — we make ourselves easy to replace. Not by the AI, but by anyone who still thinks deeply, independently, and critically. The flip side is what we get back: with the building offloaded, we finally have the mental capacity to reason about the whole product, not just our slice of it.

Thinking harder before building sounds like a recipe for never shipping, so I keep it on a clock. I’m not after endless deliberation — just a real second thought at one moment: when I’m about to build something, do I actually want it? Ten minutes now, ten tomorrow, ten in a conversation with someone else. Half an hour across a day is usually enough to know what to cut.

We already get this practice every day, with AI handing us a stream of choices to make. Every session with a tool like Claude Code is a chain of small choices: which path, which trade-off, which suggestion to wave off. By the end of most sessions, Claude has offered me more things to build than I came in with. The most useful calls I make are usually the NO’s.

Six years taught me how to operate here — how to shape a decision before it’s made, read what people actually want, lead a team. But the same years taught me something I’m slower to admit: it turns out all that control over the work around me was mostly borrowed. Below are the lessons from those years — some from where I had a real sense of control, and some from where I had none at all.

1. Most influence happens before the meeting, not in it

My biggest lever was the prep nobody sees — the work that quietly decides a meeting before it starts. I hate being pushed into things, so I over-prepared just to avoid it. Oftentimes, whoever frames the problem before alignment starts usually lands where they wanted, while everyone else spends the meeting reacting. Everybody knows this in theory; less people do the boring prep. It’s the subtle influence without any real power.

2. People run on incentives, not orders

The most useful skill I picked up was understanding what a person actually wants, which predicts what they’ll do. It’s tempting to assume people just do what they’re told. In practice, you see how hard someone runs when a project serves their goals, and how little they give when it doesn’t.

So part of the job became simple diagnosis: what does this person want, would the proposal get them closer to it, and if not, what else can I put on the table. This pays off even with people you’ll never work with — once you can see someone’s incentives, their choices stop looking irrational and start making sense, and a lot of friction just disappears - I simply stop wasting time forcing alignments. What actually moves people is the overlap between what needs doing and what they already want.

3. You can’t make everyone succeed

I tried to make everyone on my team succeed, and slowly learned I could only control where I put my own energy. I came prepared: I’d map out people’s projects for them, estimate their impact, try to keep things balanced across the team. Part of it was the TL role, but mostly I just wanted everyone I led to find a path.

What I learned is that energy spent on people who aren’t reaching for it is energy taken from the ones who are — I was helping people who hadn’t asked, while the quietly ambitious got less of me. Now I save the deep, long-term attention for the people who actually care. It sounds cold, but it’s the only thing that scales.

4. With AI, the rare skill is judgment, not building

After a year of building with Claude Code almost daily, I’ve landed on this: AI is shifting the value of an engineering leader from building to judgment. Knowing how to build something, or how to break it down and hand it off, still matters — but it’s no longer the bottleneck.

When anyone can stand up a working version in an afternoon, the question stops being “can we build it” and becomes “should we, and at what cost.”

The trap I watch good engineers fall into, myself included, is rushing to build because we can, without asking why, or what we’re quietly taking on. The more valuable work now is the judgment around the building — what risk are we baking in, how would we measure it, and is this even worth building. That pulls engineers toward instincts that used to belong to other roles: a PM’s sense of what to build, a designer’s eye, a data scientist’s habit of measuring the outcome.

For lack of a better word, it adds up to taste. And I suspect taste — knowing what to build, and what not to build — is the next big growth area for engineering leadership. When anyone can build anything, the only real control left is deciding what’s worth it.

5. To lead is to go first

Leading, unlike managing, means going first — and you can only do that when you’re not afraid of the fall. Going first means trying the new thing, making the new mistake, taking the first round of criticism.

Two rules I’d stand behind: be willing to be the dumb person in the room, and lift people up wherever you can — that’s what makes them follow you without being asked. But I have to be honest: I lead “fearlessly” mostly because I’ve had air cover the whole time. Manager, director, on up — sponsorship for things I tried. Take that scaffolding away, and I don’t know how far I would have gone.

6. The voice you build is on loan

At year six, the catch is plain: almost everything I’ve built here rests on a platform I don’t own. Most of us are replaceable. The illusion that I’m important, I’m needed is easy enough to drop.

The stubborn one is the illusion of control — the belief that I steer my own work, when a few decisions far above me, or the broader economy, could change everything overnight without asking.

My title gives my words weight in a meeting; I’d lose that voice the moment I step off the platform, because it was never mine — it was on loan. That’s not a complaint. I’m holding a genuinely good hand. But a good hand is still cards someone else dealt, on a table someone else can fold.

The questions I’m left with are the ones I still can’t answer. Where should I be in a few years, when this run inevitably ends? What’s the end game I’m chasing — versus the one the platform chose for me? Who am I, and what is my voice worth, without the title?

A week ago, these questions stopped being abstract. On 5/20 the layoffs came. I wasn’t touched; many people I respect were. It was humbling and I felt lucky. That also brutally reminded me that the control was never real.

All that above marked a special 6 year anniversary.

A year ago I stepped into a refreshed role to cover more areas in the 40-eng org. A break-through happened in trust building with folks: we had an external conflict with a different team; I ended up protecting my engineers’ scope, navigating through different org’s incentives, and putting off the fire. These in return rewarded me with more people’s trust. A few points to reflect:

1/ Ask noob questions, be willing to be the dummest person in the room. It does not matter if the person in front of me is junior or senior. If I let go my ego, my peer will lower the guard and actually share their opinions.

2/ Be willing to say ‘I was wrong’, ‘I am sorry’. This gives everyone permission to try new things and removes the false necessity of ‘perfect impression’. Growing a team of high agency engineers is invaluable. High agency usually means: they have the support structure to actually take actions on their own ideas.

3/ Craft opportunities for my ENG to shine when things go well; step up to take blame when things go south. A lot of great leaders do this unintentionally - they just love uplifting people, giving people credits, and enjoy seeing others grow.

These are not novel ideas. I’m just experiencing them first hand. With all changes happening in the industry and in my company, I think some of these simple traits can go a long way.

Jimmy Carr said: it’s not the pursuit of happiness — it’s the happiness of pursuit.

I heard this after about ten years in my career, and it clicked immediately — because I had already learned the lesson the hard way.

Back in 2020, I joined my company one level lower than I wanted due to an interview hiccup. So I chased the Senior title as hard as I could. I got there. And when I did, it was just... depressing. The goalpost moved immediately — Staff Engineer became my new reality overnight. I felt like I’d already exhausted everything I had and yet I was on this new marathon right away. I’m still behind because of that setback. I can’t rest or waste any time.

My life had centered around just that one immediate goal. I’d given up travel, given up exercise. After a 14-day war room stretch in late 2022, I tried to go for a run and my whole body hurt — I couldn’t breathe. Am I not supposed to chase after ambitious goals? Or am I just doing something wrong along the way?

I didn’t figure out the answer then. But I knew I didn’t want this to happen again. So when I started chasing my next career goal, I changed one thing: I set my goal to be two levels ahead instead of one. Staff became a milestone I knew I’d get to. When I did get to Staff, this strategy proved itself. I celebrated for about fifteen minutes, and moved on. No depression. No huge celebration. Just a milestone — I was perhaps 10k into the marathon. I took my water and energy gel, and kept going.

It was about three or four years after that first depressing promotion when I saw that reel on Instagram: “it’s not the pursuit of happiness — it’s the happiness of pursuit.” And I thought: of course. How else could this be? “Enjoy the process,” right? People had been telling me that since I was a child. But it had always been meaningless because it was framed as a consolation for losers. It’s okay if you lose the match but you enjoyed the process. I didn’t buy it. I wanted to win the prize, not just “enjoy the process.”

Now I understand it was just over-simplified framing. It’s not about winning or losing. It’s about the type of person you become going through the challenges, and the type of strength you gain on the journey. I care about everything I cared about five years ago, not any bit less. I just aim further.

Occasionally peers at work ask me — should I go for this next thing? I never have a smart answer in the moment, but I keep landing on the same thing: if you have to be there for 40 hours a week, you might as well make it something fun to chase after. Go after the next goal. You’ll become stronger through the chase whether you get there or not.

Anthropic recently published a study that put hard numbers to something many of us have been feeling. They ran an experiment where developers learned a new Python library — half with AI assistance, half without. The AI group finished a bit faster, but scored the equivalent of nearly two letter grades lower on comprehension tests afterward. The speed came at a real cost to understanding, especially around debugging. This isn’t a fringe concern anymore — even the companies building these tools are flagging the tradeoff.

On one side, you have the refusers — people who treat AI like a fad, convinced that if they just ignore it hard enough, it’ll go away. On the other, you have the surrenderers — people who’ve essentially replaced their own thinking with an AI subscription, copy-pasting their way through work they used to understand deeply. I’ve spent the last month deep in AI-driven coding, and I think both extremes miss the point. Here’s my take.

The Offloading Problem

Cognitive offloading isn’t new. We’ve been doing it for decades, and mostly we’ve been fine. GPS killed our ability to navigate cities from memory. Calculators made mental arithmetic a party trick rather than a survival skill. Smartphones mean nobody memorizes phone numbers anymore. Each time, we traded a cognitive ability for convenience, and each time, the trade felt worth it.

AI is the latest entry in this lineage — but it’s different in a way that matters. GPS offloaded a narrow skill. Calculators offloaded mechanical computation. AI offloads thinking itself: pattern recognition, problem decomposition, reasoning through ambiguity, synthesizing information across domains. These are the core machinery of how knowledge workers create value. When you offload navigation, you lose your sense of direction. When you offload thinking, what exactly do you have left?

I’ll be honest about my own experience. After a month of heavy Claude CLI usage — and I mean heavy, multiple sessions a day, sometimes three terminal windows running simultaneously — I’ve started paying attention to how my brain approaches problems. The “muscle” that used to kick in when I hit a hard bug or a complex architecture decision has gotten softer. Not gone, but softer. I catch myself reaching for the AI before I’ve even finished formulating the problem in my own head. For example, I use Claude pretty heavily for research, where I provide the points to investigate but I no longer go through the hard thought process of recognizing real knowledge vs noise during research. My cognitive endurance — the ability to sit with a hard problem for an extended period — weakens when AI gives me instant answers. My pattern recognition dulls when I stop building my own mental models. When AI always sprints for you, your stamina for sustained thinking quietly withers.

Your AI Is Your Team

Here’s the thing, though — this isn’t actually a new problem. It just feels new because of the AI technology wrapped around it.

Anyone who’s led a team of strong engineers has faced the exact same tension. When you move into a leadership role, you’re suddenly surrounded by people who can execute faster than you in most areas. The temptation is to delegate everything. And for a while, it works great — the team’s throughput goes through the roof, and you feel like a genius for assembling such talented people. But a year or two in, you realize something uncomfortable: you’ve been hands off for too long and can’t articulate the technical tradeoffs with real depth. You’ve become a project manager wearing an engineering title. The flip side is equally broken — the leader who refuses to delegate, bottlenecks the entire team and wastes the talent they hired.

I believe the best engineering leaders solved this by being intentional about which work they kept for themselves. They’d stay hands-on in the areas that mattered most for their judgment — the critical architecture decisions, the gnarliest debugging sessions, the parts of the system where deep understanding meant the difference between a good call and a catastrophic one. Everything else, they trusted to their team. AI is the same dynamic with a different “team member.” The question isn’t whether to use AI — that ship has sailed. The question is which cognitive work you keep for yourself, and which you hand off.

Think First, Then Collaborate

So what does a healthy relationship with AI actually look like? I think it comes down to one principle: AI should extend your thinking, not replace it.

The practical version of this is simple but requires discipline. Before you open the AI tool, think first. Form your own hypothesis. Write your rough analysis — even if it’s messy, even if it’s wrong. Identify what you actually need help with versus what you could solve with more time and effort. The goal isn’t to prove you don’t need AI; it’s to make sure your own cognitive machinery stays engaged. Then bring AI in — not as an oracle that hands you answers, but as a collaborator that stress-tests your thinking, fills gaps in your knowledge, and accelerates execution on the parts that don’t require your deepest engagement.

The other piece is knowing when to toggle intensity. Not every task deserves the “think-first” treatment. Some work is pure execution — boilerplate code, data transformations, refactoring tasks — where AI collaboration at full speed is the right call. The new skill here is knowing which mode a given problem calls for. Hard architectural decisions? Think first, AI assists. Migrating a hundred files to a new format? Let AI drive.

The Long Term Effect

The real danger isn’t AI itself. Tools are neutral; what matters is the pattern of use we build around them. And the insidious thing about cognitive atrophy is that it’s invisible in the short term. You won’t notice your thinking getting shallower this week, or this month. It happens over years, slowly enough that you can always rationalize it. “I’m being more efficient.” “Why waste time on what AI can do?” By the time the decay is obvious, it’s hard to reverse.

The people who will thrive in an AI-saturated world aren’t the ones who use AI the most, and they certainly aren’t the ones who refuse to use it at all. They’re the ones who use AI to amplify their thinking while deliberately — almost stubbornly — preserving their ability to think without it. We’re in the early days of figuring out what that looks like — there’s no playbook yet. But the direction is clear: not rejection, not surrender. Intentional integration. Our own brain is the one we’ll be working with for the next thirty years. That’s worth being deliberate about.

这些 Agent跟我们一样也是勇敢的打工人; 可能我们都活在模拟世界里.

灵感

最近用 Claude Code 干活, 经常同时开好几个 session.

每次都在想: 这些 Agent 现在在干嘛? 忙不? 是不是在摸鱼?

于是我造了个小工具 -- Claude Office.

一个像素风的等距办公室, 每个 Claude session 都是一个小人:

• 🔥 工作中 → 疯狂敲键盘, 汗流浃背

• 😴 摸鱼中 → 趴桌子睡觉, zzz

• 🚪 没任务 → Micro Kitchen聊天

看着一群小人在办公室里忙碌, 很治愈.

安装

三步搞定:

# 1. Clone
git clone https://github.com/awangdev/claude-office.git
cd claude-office

# 2. dependency
npm install

# 3. start
npm start

打开浏览器访问

http://localhost:3000

Dependency:

• Node.js 18+

• 正在使用 Claude Code CLI (session 文件会自动出现在 ~/.claude/projects/)

技术架构

┌─────────────────┐     WebSocket      ┌─────────────────┐
│  浏览器          │◄──────────────────►│  Node.js 服务器  │
│  (Three.js)     │   实时推送 session  |  (Express +WS)  │
└─────────────────┘                    └────────┬────────┘
                                                │
                                                │ 文件监听
                                                ▼
                                       ~/.claude/projects/
                                           *.jsonl

核心组件:

模块技术作用前端渲染Three.js等距视角 + 像素精灵动画文件监听Chokidar监听 .jsonl 文件变化实时通信WebSocket推送 session 状态更新

状态检测逻辑:

• 30 秒内有活动 → active (工作中)

• 超过 30 秒没动静 → idle (睡着了)

• 文件被删除或者很旧的session → exiting (下班走人)

所有动画都是用 Canvas 程序生成的, 没有外部图片资源.

开源

项目已开源: https://github.com/awangdev/claude-office

欢迎 Star ⭐️, 欢迎 PR!

那时候是盯着屏幕里的《传奇2》挂机打怪, 现在的我是盯着Claude 飞速滚动的出活儿. 时隔二十几年, 屏幕前的我早变了模样, 但那种进入心流的状态似曾相识.

• “外挂”般的快感: 以前打网游都要开挂. 现在用 Claude Skills, 本质上就是给编程工作开了外挂. 原本需要我吭哧吭哧写几个小时的枯燥代码, 现在 Claude 分分钟搞定, 这种多巴胺分泌的快感简直停不下来.

• “烧点卡”的紧迫感: 既然充了钱, 或者 Token 额度还没用完, 就总觉得如果不把今天的配额跑满就亏了. 这种心态像极了网吧的点卡, 非得要把每一分钟都榨干, 玩到精疲力尽才舍得下机.

从 VSCode 到 CLI

刚开始决定把工作流从 VSCode 迁移到纯命令行 (CLI) 的时候, 我经历了一两周缓慢的”戒断期”.

脱离了那些熟悉的按钮, 图形化的操作, 我发现自己就像一个突然被扔进原始森林的现代人. 很多底层的 Linux 命令我都手生了, 参数完全想不起来怎么敲.

但很快, 我意识到我不再需要去记那些命令参数. Claude 可以替我解决大部分的底层操作.

我只需要告诉 Claude: “帮我把所有后缀是 .json 的文件都找出来, 然后把里面的 id 字段提取出来存个新文件”. 它就会极其熟练地调用 find, jq, xargs 这些我不常用的工具, 帮我把活干完. 慢慢地, 这种”遗忘”变成了一种解放.

Skills & Commands & Plugins

适应了 CLI 之后, 我开始接触一些更流行的概念, 就像游戏里解锁了新技能树.

有了 Claude 的协助, 我开始尝试把一些常用的工具封装成 SKILL, 把复杂的工作流封装成 COMMAND. 最后还做了自己需要的 PLUGIN. 这感觉就像是给自己的角色打磨了一套专属装备, 用起来得心应手.

Claude配备Skills的感觉, 就像是美剧Heros里面的 Peter Petrelli, 可以无限的吸取新的技能, 逐渐变得无限强大. Claude在本体之外, 也通过跟电脑本身联系, 逐渐能够有更多更广的功能. 每次看到Claude的新用法 (subagent, multi-agent, ralph loop, etc), 都让人又惊又喜. 我们软件工程师的世界, 已经完全变了.

效率的代价: AI Fatigue

这一个月效率提升的背后, 是前所未有的 AI Fatigue.

这种累跟以前写一整天代码的累不一样. 以前写代码, 你有自然的思考间隙, 大脑有”垃圾回收”的时间. 现在不一样了, 三个窗口同时飞速生成代码, 我从一个”车间工人”变成了一个高频的”质检主任”. 这种高强度的决策密集型工作, 就像跑马拉松撞墙期一样, 是一种深层的精神透支. 爽归爽, 但真的还挺累.

尽管很累, 但我依然觉得这一切都值得.

Claude 带给我最核心的冲击, 是它填平了”想法”与”实现”之间的那道巨大鸿沟. 以前我想做一个功能, 大量的时间花在查文档, 试错, 写构架, 再慢慢手搓. 现在通过各种工具, Claude 直接帮我扫清了这些障碍. 而我只要清楚的知道自己想要什么, 想做哪些改变, 以及快速地想验证一些想法 - 一切尽在转瞬之中.

这也许就是我们这一代程序员面临的最大的机遇与挑战. 工具的门槛在无限降低, 而个人的行动力变得前所未有的重要.

轰轰烈烈的2025年度PSC (Performance Cycle Review, 年终评价)落下帷幕. 往年的我在这个时候特别忙, 像打仗一样写年终总结帖. 今年我患了拖延症, 到截止日期的最后一天才写完所有的feedback; 这一周我几乎所有的精力都花在Claude Code上, 学习一些流行的工作流程, 反省自己工作模式中值得改进的部分.

我的动力来自于肉眼可见的10x效率: 就这么一条船, vibe coding. 我不跟, 别人就以10x的速度飞快前进而我就原地站在尘埃里. 我自然选择站在历史正确的一边, 全身心地接受AI洗礼, 有什么新工具新手段, 都要耐心看看.

现在市面上流行的几个Coding Assistant派系, Cursor, Copilot, Antigravity, Claude Code. 其中Claude Code最不一样的是它主打CLI 界面, 而前三者都是主打IDE用户界面(并且三者都是基于开源的VS Code). 前三者也都可以用Claude模型.

这几周, 我感受到的不再是 “哪个模型更好用”, 而更多地开始趋向于: 哪些功能让人眼前一亮, 或极大地增加了效率. 举几个例子:

• 我在文章033里聊到过Antigravity. 后来我又做了一些小实验, 做了个网页版的小游戏pong, 把自己写的Google Review整理成网页. 这些后续的小实验都基于一个强大的功能, Antigravity: Browser extension. 它的功能听上去很简单, 就是代替你去操控网页, 点点鼠标, 滑滑网页. 这个功能等于给了AI一双从你的视角看出去的眼睛, 而更加容易帮你解决实际问题.

• Claude Skills 从2025年十月中旬发布, 就开始席卷全网. 顾名思义, 我们就是在给AI工具赋予一些简单的Skills(技能). 它存在的一个基本意义就是, 很多时候我们要解决的问题是重复性的, 那么我们一次性, 定义一个’技能’给Claude, 它会了之后就再也不用重新定义了. 这个想法非常直观, 简单; 就像我们人一样, 从最简单最小的技能开始掌握, 逐渐变得功能全面, 逻辑缜密. 在工作里面, Claude Skills的概念更容易普及: 很多人都会在工作中解决一系列一模一样的问题, 那么定义好Skills, 大家就可以直接拿来用.

我没有AI Research的背景, 除了理解一些基本问题(Context Window, Token Size)和解决方案, 我还没有认真思考过AI Coding在现阶段的绝对瓶颈在哪. 但就我的体验, 在我工作内容的这一亩三分地, 我完全可以利用AI在这个小领域做很多加速.

也许这是一种跟风, 但我觉得提高生产力是值得的自我投资. 我只是花少许订阅费用和时间, 我得到的是从拨号到5G的工具升级.

Q1 2026: 什么人会被AI淘汰?

这是个百花齐放的时代. 每个人都有机会去学习这些AI Coding的工具, 每个人都有能力产出. 没有业界经验可以做出产品, 有业界经验可以做东西更有效率. 在这个时代背景里脱颖而出的, 一定是那些极具行动力的人.

我认为第一批被淘汰的, 是不愿意使用AI工具的人. 这种心态非常容易理解: “1/ 我有一套过去非常成功的流程而我在这个流程里面的角色非常重要; 2/ 因此我个人对项目/团队至关重要”. 一旦AI开始重构#1, 在很多人心中, 就会直接威胁到#2, Job Security.

举个栗子. 在Software Engineer的领域里:

• 过去: 一个TL (Tech Lead) 带一个团队做项目, 他可以掌控全局, 用自己定义的流程, 带团队完成各个环节. 他熟悉每个环节, 可以做质量把控, 时间线把控, 更加可以彰显自己TL的水平.

• 今天: 同样的项目, 也许这个TL一个人用AI就能完全解决; 或者他手下的人用AI就能解决. 而且解决的速度可能会非常快, 或者迭代会相当高效.

• TL存在的意义会直接被挑战: 那这个TL是不是要去学习新知识, 做更大的项目, 重新接受更大的挑战?

  • 如果他愿意接受新的挑战接受新事物, 那是极好的

  • 但有些人会在这个时候产生抵触, 或者不由得困在过去的状态, 慢慢掉队

这是重要的转折点: 当个体的产量和理解能力变强, 那么大家很快都能变得似乎跟过去的TL一样强. 如果TL要继续领导一个技术团队, 那他必须跟所有人一起升级. 其实作为团队的技术领头, TL要带领的远比技术方面要多, 比如遇到紧急状况的处理经验, 拿捏风险的经验, 等等. 拥有这些原始技能, 如果能用AI加持, 应该会有非常好的结果. 相比一些比较junior的工程师, senior在AI工作的赛道, 是有先发优势的.

大家都很担心”被AI淘汰”. 我理解这种恐惧. 但是, 如果我们抵触AI工作模式, 比起AI, 我们更早输给的很可能是那些充分接受AI工作模式的同事们. 很简单嘛, 人家10x效率, 我在原地吃土, 不淘汰我, 淘汰谁.

也许过几个星期, 这个想法又会更新.

AI怎么看这个问题

我在没有输出观点的前提下, 单独问了Antigravity和Gemini: “什么人会被AI所淘汰“. 他们的答案都提到了我上面的观点: “拒绝接触和学习新工具的人”会被淘汰. 当然了, 这也可能是Google故意这么说的, 我不就继续用这些AI产品了么哈哈. 下面是AI的回答:

Antigravity说: 这是一个非常深刻且被广泛讨论的话题。与其说特定的“人”会被淘汰，不如说特定的工作模式和思维方式正在被边缘化。目前的共识倾向于认为：AI 不会直接淘汰人类，而是“会使用 AI 的人”将淘汰“不会使用 AI 的人”。具体来说，以下几类特质在 AI 时代可能面临更高的风险：

1. 拒绝接触和学习新工具的人

2. 从事“高重复性、低创造性”脑力劳动的人

3. 缺乏“鉴别能力”与“批判性思维”的人

4. 缺乏情感连接与复杂沟通能力的人

Gemini说: 在2026年这个AI技术已经深度渗透各行各业的节点，关于“谁会被AI淘汰”的问题，已经从科幻式的忧虑转变为现实的职场法则。目前的共识是：被淘汰的往往不是“人”，而是“只会把人当机器用”的思维和技能模式。 具体来说，以下三类人面临最直接的生存危机:

1. 技能单一且处于“标准流程”中的人

2. 拒绝使用 AI 提升效率的“工具排斥者”

3. 缺乏“人类独特性”的初级决策者

跟2025年1月1日期待的一样, 过去的12个月我过得比往年要充实得多. 在2025 开始的时候, 我做了一个 12 weeks year 的计划. 计划的理念是: “忘掉传统意义上的一年结束是12月31日，把12周当做一年. 因为只有12周去完成目标, 所以需要满打满算, 让能安排的时间都更有价值”. 把12个月的计划融进12周, 原本就是非常难完成的; 但是缩短的12星期, 让这些计划更加容易执行.

或许每12个星期更新一下计划才是最恰当之举. 我这种年终才想起来做计划总结的, 对自己的要求是有些粗糙了. 总体而言, 整个一年的进程还不错: 除了既定的目标, 我还完成了些额外的事情: 南非旅行, 夏威夷马拉松, 车库重装, 适应AI工作转型, 开始播客 (编译日志The Build Log), 把个人网站做出来 tuwang.ai. 生活里我最大的额外收获是完成了马拉松比赛和认识自己身体的极限. 工作里最大的收获自然是在AI转型这个赛道上起步了.

我最大的缺口是读纸质书的时间不足, 参与额外沟通活动很少. 回过头一想, 这都是短期不做也不会怎么样的事情, 可放着不管总觉得不合适. 在新的计划里面我打算把这两条变通一下. 读书的缺口, 我用听博客补充一下; 沟通呢, 其实过去大半年我在职场的沟通范围已经变广了, 因此就继续用1:1和编译日志代替.

2026的计划里, 我把工作那一栏去掉了. 工作的计划太复杂, 又不适合拿出来写, 干脆去掉. 新的计划, 大致分这个四个部分:

• 1/ 沟通成长: 主要还是继续1:1, 和做[编译日志]播客

• 2/ 健康&运动: 长跑, 准备比赛, 保持睡眠量

• 3/ 学习: 主要是AI的学习, 还有读书/播客的知识摄入

• 4/ 修整: 用业余项目, 或者组建乐队, 从工作的状态里短暂抽离, 恢复元气.

  • 这一条算是奖励项, 如果能做到, 2026肯定是额外加分的

  • ChatGPT告诉我说应该给自己找点恢复元气的计划, 因此我加了这条recovery stretch goal

漫长的2025

我很惊讶, 这一年过得很慢. 这是一件好事.

人一旦对外界事物熟悉起来, 就会相应地麻木起来并且忽略这些重复性的事. 就比如, 你一定不会记得这些小细节: 今天早上开车去办公室遇到了什么, 昨天吃了什么午餐, 上个周末做了什么.

但反过来, 你很可能会记得, 某个艰难的工作项目, 某次辛苦的运动, 甚至是某个困难的游戏关卡, 或者是某些”人生第一次”或者”人生仅此一次”的经历. 这种感觉很容易理解: 就比如学生时代, 尤其是早期, 我们总是在学习新的东西, 所以每一个学期都极度漫长.

2025年我有了许多艰难的或者全新的体验. 相对往年, 这一年的时间仿佛拉长了许多. 容我赘述一下时间线:

• 1月: 开始跑步训练, 第一次尝试10k

• 2月:

  • 第一次10K SF比赛, 下着雨天寒地冻, 非常痛苦地跑完.

  • 我拔掉了4颗智齿

  • 用ChatGPT, 自己琢磨修了房顶

• 3月:

  • 拆车库, 重装电线

  • 西雅图之行, 认识课代表

  • 工作换manager, 开始带新的scope, 学习新领域

• 4月:

  • 一号公路旅行

  • 重开播客: The Build Log 编译日志

  • LA之行, 准备南非旅行手续

  • Surfer’s path半马: 首次半马, 跑出不错成绩; 鼓励了我报全马

• 5月 - 6月:

  • 南非旅行honey moon, 密集漫长的3周旅行

  • 旅行结束后安排H2 2025工作计划

• 7月:

  • 尝试露营

  • 新的工作重心, 新的工作人群, 新的挑战

• 8月:

  • Tahoe mountain biking: 电闪雷鸣

  • Tahoe E-foil surfing: 困难的冲浪体验

  • 工作中: Reorg, AI转型问题, 同时开始

• 9月: 重新开始训练跑步, 为夏威夷全马做准备

• 10月: 工作里, 带动AI转型; 跑步训练

• 11月: 纽约旅行; 在纽约跑步训练; 工作里AI转型目标达成

• 12月:

  • Honolulu马拉松比赛: 大雨, 35k后肌肉极限, 5小时马拉松

  • Big Island火山喷发: 活火山, 晚上几个小时的喷发

  • Honolulu North Shore: 跟鲨鱼游泳

1月, 7-11月, 我下班之后更少有自己的时间, 大体上是被工作带着走的; 工作之外的活动减少了许多. 但是上半年, 也就是12 week year开始的那个季度, 因计划的充足, 我展开了更多活动, 也因为5月的honey moon旅行, 我在那一段时间有了更多经历.

每一年总有些记忆点, 让那一年的某个阶段变得’更漫长’. 有时候这些经历是旅行, 是工作生活中的挑战, 还可能是一些不快乐的事情. 特殊的经历会让我们觉得人生的这些阶段更加有意义. 我们甚至不需要去从这些经历中提炼什么感悟和成长, 这些经历的存在本身, 就是值得回味的记忆点. 在我们短短数十年的经历中, 能有更多地记忆点, 这个简单的结果, 已经是很有意义的.

2026 不尽全力, 更待何时

从个人的成长角度, 我觉得现在是个 ‘不现在尽全力, 还等什么?’ 的一年. 也许你可以说, 每年都是如此, 有什么不一样的. 我认为有几个特别的点.

1/ AI给给我们带来了前所未有的生产力, 而个人的行动力 (agency) 显得格外重要.

过去我们常常调侃的, “年纪大的程序员会被年轻程序员取代”, 这个规则正在被打破; 同样的, 一些简单的技术壁垒, 前端/后端/mobile/web, 也都逐渐在被打破. 我们逐渐进入一个任何人都可以用AI解决非常多问题的时代.

不论我们个人的目标是什么, 我们都站在这个历史的分叉路口, 有行动力的人和团体, 会在这个时代被赋予极强的创造力和生产力; 而缺乏行动力的人, 要面对被时代抛弃的压力.

2/ 36岁, 第三个本命年

我们的文化里是有些宿命论的: 三十而立四十不惑; 本命年之说; 先成家后立业, 等等. 2026是我的第三个本命年, 我觉得也是个人状态的一个分叉口: 从工作, 健康, 各个方面.

从30岁之后, 很明显地, 有了一点积蓄之后, 我开始关心起健康, 主动地解决一些大大小小的问题, 有规则地运动, 开始参与挑战身体机能的比赛. 我最想搞明白的就是, 不知道哪些事情, 是我现在不去挑战, 未来就更加没机会做的. 比如跑马拉松, 越野跑, 或者前几年开始的单板滑雪.

工作也是一样, 如果现在不去尽全力, 难道要等到40好几, 再去担心仕途么?

• 总体而言, 我还是一个相信深耕的心态, 在一个好的环境里面, 尽可能得成长, 看看能做到什么程度. 所以我近几年很少考虑转组或者跳槽. 当然了我对行业的认知也在逐渐丰满, 未来不应该剔除换公司的可能性; 我选择在原地成长也是一种机会成本.

• 我现在最感兴趣的, 是在这个不错的工作环境里面, 让我能知道自己能成长到什么样的状态, 能挑起多大的责任, 看看自己的极限是什么.

就目前而言, 跟上百人的团队合作, 我在自己领域技术和沟通, 都不是什么大问题. 我在2026会去发掘的方向, 应该是找到自己在更大团队里面的角色: 总有技术上比我强很多的人, 也总有沟通更强的人, 我在这其中, 应该在哪一个领域, 带领大家去哪一个方向, 如何跟帮助更多地人达到他们各自的目标, 如何让更大的团队一同成长起来.

2026, 我相信会有更多让人期待的成长.

3/ 对比上一代人

过去一年我在训练马拉松的时候, 经常想一个问题: 因为时代背景, 上一代人的经历比我困难许多, 不论是体力上还是精神上. 困难的时代造就更刚强的性格, 而舒适的时代造就更软弱的性格. 我一直担心我的性格处于软弱的一方, 所以想找到一些外力给自己锻炼的机会. 于是马拉松, 一个考验耐力和体力的运动, 就变成了最好的选择.

在这个思考的方向上, 我开始思考上一代人在36岁的时候, 在做些什么; 相比之下, 我是否落后. 但这个比较基本上不成立: 我们不同行业, 不同背景, 不同家庭状况; 我没有机会在他们的赛道超过他们, 我也很难用我现在的成绩来跟那时候的他们相比.

这个感悟其实早就应该有: 孩子也许一辈子都想给父母证明自己的成长, 得到父母的认可. 可是这种期待是一种小孩子的心态: 用别人的认可来证明自己的价值. 在年幼的时候, 这是个很不错的成长催化剂, 让个人的努力变得有意义.

• 在成年以后, 如果父母能够理解孩子在20, 30, 40 岁的成就, 那当然是一件双方都快乐的事情

• 如果父母不理解孩子后期的成就, 或者没有机会表达他们的骄傲, 这也是很正常的表现: 不是每一代人都能理解下一代人的成就, 也不是所有的成就都能用直观的金钱来衡量.

现在我觉得挺厉害的事情, 比如我做的功能能被上百万, 上亿人用到; 比如我跟多少同事建立的关系, 团队的发展, 工作中得到的认可; 比如我在他们没有经历过得领域里的体验, 比如滑雪, 马拉松, 等等; 在这些事情上, 我其实无法跟他们产生什么共鸣, 这也是正常的.

虽然有时候有些遗憾, 但这些我认为的成就, 原本也是为了丰满自己人生而去做的, 并不是为了得到别人的认可.

快36岁才想明白这件事情, 有那么点可笑, 一定要记录一下. 在2026我会尽力一搏的事情, 更应该是那些我认为对自己人生有意义的事情, 而不是那些需要别人, 哪怕是父母认可的事情. 这样子的人生, 会充满主观能动性, 充满挑战和活力.

说说首马的几个核心记忆点.

赛前准备 / ChatGPT

首马我做了全面的准备:

• 头部: Ciele Atheletics GoCap Hat, Meta Vanguard Glass

• 腰部: 跨带, 9个能量胶, 1包盐丸, 8个电解质胶囊

• 上身: 手机带, Garmin Forerunner 970

• 鞋: ON Cloudboom Max (比平时大1号!)

• 袜子: 五指袜(免得脚趾打架)

未来能够提高的, 应该就是自己带水杯的习惯.

值得一提的, 是所有的补给, 以及训练计划, 还有早期的装备研究, 都是用ChatGPT帮助的; 在过去的11个月里, 我跟ChatGPT有非常多的零碎咨询, 它知道我整个跑步的成长历程. 因此, 最后全马的计划和执行, 都有相当高的合理性.

因为大雨, Meta Vanguard Glass我大部分时间顶在头上; 它防水功能非常强大, 下雨天省去了我戴耳机的烦恼; 行进中我不用抄手机, 随时拍到比赛的瞬间.

磅礴大雨

早上3点多起来, 窗外就在暴雨; 这天Honolulu还有洪水预警.

我凌晨4点出门, 原本还想打车, 结果刚下楼就看到选手们成群结队, 啪叽啪叽地踩水, 紧接着我打的Uber也被司机取消了. 即便是夏威夷,凌晨4点的大雨, 走起来也凉飕飕的. 我们就跟着人群, 没几分钟, 全身上下, 连鞋子全部湿透. 走到赛场大概有30分钟步行距离; 到的时候雨小了一点, 我赶紧到屋檐下, 把袜子脱下来拧水. 旁边的大哥见我这样, 也坐下来拧袜子, 一脸苦笑.

马拉松的气氛, 还是能把大家带动起来, 就算是下着雨, 闹哄哄的几万个人站在街上, 没听到谁抱怨, 倒见到不少人拍视频介绍今天的情况; 加上音乐的渲染, 大家好像把坏天气给合理化了, 都不是事儿.

温度和湿度

因为暴雨, 潮湿度达到了90%; 日出之后, 气温在23摄氏度左右.

这是我第三次参加跑步比赛, 前两次也都是阴天后者下雨, 所以我并没有觉得特别难受, 反而有点庆幸: 大太阳的比赛我真没有试过, 阴天是比较好的情况. 但很多选手对于湿度的反应是消极的, 特别是习惯干燥天气训练的人.

我的5个小时里面, 前后加在一起大约有一个小时太阳全开了, 晒太阳确实有点煎熬; 我也是在那一段, 大约35公里的时候, 身体开始出状况. 但总体而言, 天气我带来的影响跟二月份那次10K差不多, 下雨跑步我也试过; 此外我在上海长大, 潮湿的空气我也能适应, 所以总体而言我占优势.

站位失误

我4点半走到比赛场地. 正式比赛5点开始, 但我直到5点35才跟着人群走到起点. 等我要开始跑时, 前面的第一波人, 都已经进入了下一阶段. 这一次因为下雨和拥堵, 我连控制配速的领跑人都没看到, 就跟在了人群后方.

原本我的水平也就是跟自己比赛, 而不是争抢名次; 但这个选择的最大影响, 就是比赛过程里, 我被迫要越过更多的人群. 比赛开始之际, 有一些组团来跑10k的选手, 上百成千地走路; 很多人吃着笑着聊着天, 一字排开, 堵着大家没有办法往前. 整个42公里, 我至少有37公里是在”障碍跑”, 剩下的5公里, 我也成了行走的障碍.

最后我的跑步路程是42.73公里, 比原定的42公里多出了0.53公里; 我预计这半公里中有一大部分是毫无意义的左右横跳, 至少是几分钟的差距.

肌肉极限

在训练时, 我在5K, 10K, 20K, 30K都分别遇到了每个阶段不同的问题. 比如说鞋子, 衣服, 装备; 后来是能量胶, 电解质水; 膝盖问题, 小腿酸痛问题, 抽筋问题. 这一切都顺利地通过姿势,装备,营养的升级而解决了. 比赛时, 我带足了装备, 并且完全解决了抽筋的毛病.

我没有预想到的, 是35公里以后的肌肉失控.

比赛前, 我的最长距离是30公里. 当天, 到30公里之后, 一路都是上坡, 我突然发现膝盖上面两腿内侧的股内侧肌开始紧绷; 这个感觉跟抽筋的前兆类似, 也碰巧是太阳出来最热的时候, 我开始加速补充电解质. 奇怪的是, 我过去抽筋的所有部位都没事, 唯独这两块股内侧肌, 不论如何都无法缓解.

由于对抽筋的恐惧, 我开始跟自己和解, 走一走, 拉拉筋, 再重新起跑. 最后的十几公里, 我就在这种肌肉失控的状态里面, 吃掉了所有补品, 几百米停一停地磨完了全程. 也是这十几公里, 导致我比原定的心理预期, 整整慢了32分钟.

事后我认真地查了查, 这跟健身重量训练的极限状态是一样的: 当肌肉经受长期高强度的使用, 并且超越了平时所承受的极限, 就进入了这种崩溃状态. 我有好几次想要忽视疼痛, 跑完再说; 但看到路上一两个倒在路边被救护车围绕的人, 我觉得还是低调一点, 完赛比强出头要重要.

灵魂拷问

跟我心理预期最吻合的, 就是最后这十几公里跟自己的灵魂拷问: 为什么要来跑这个鬼东西! 下次再也不跑了! 但是跑过终点的那一刻, 我一看, 离自己的目标仅仅2分钟之差: 就差这么点了, 要不, 再来一把? 这次我完成了整个马拉松体验, 也知道自己在那个阶段会出什么问题, 那么就有新的侧重点去训练.

同时, 我在跑步的过程中, 不再有年初2月份跑10k, 或者4月跑半马那时候的怒气值. 工作生活还是有不顺心的事情可以拿来当做动力, 但是我发现, 这些情绪并没有过去那么好用. 可能坏情绪只能当下用, 太久会过期; 而坏情绪所激发的动力, 可能几次就不管用了.

我也不知道是什么支撑我; 赛后琢磨, 我好像也没有那么痛苦不堪(是不是贱lol). 可能对我有些压力的是吹出去的牛; 我跟一些同事聊到夏威夷跑马拉松的计划, 我要是不认真完赛, 那就是笑话了.

I can do hard things

年初刚刚开始训练时, 我非常不确定自己能不能长跑.

我这几年的状态跟跑步是沾不上边的: 2019在洛杉矶城市里随便跑了几公里, 脚底板就肌肉拉伤; 2020年出门跑步, 膝盖疼; 2022年高强度加班两周以后, 出来跑了几百米, 就各种呼吸疼痛; 2024 在家门口跑步, 膝盖疼, 导致滑雪都暂停了. 跑步对我而言, 好像是个碰不得的事情.

后来的经历, 我在podcast有聊过, 我开始看到周围很多人, 包括老同学, 新同事, 都有长跑的习惯; 2025年初的时候, 我就琢磨着, 要不我慢一点, 科学一点的跑步. 就这样从5k, 10k, 一点点突破到全马.

在前一代的眼中, 我们总归是吃不了苦的. 很多人不需要经历非常辛苦的人生, 也没有机会养成刚硬的性格. 我在进入35岁的时候有一点中年危机的顾虑: 如果他们说的都是对的, 我是不是挺废的? 借着这股劲, 我得以证明, 自己也能完成困难的挑战; 只不过这些困难是我自己选择的, 没苦硬吃.

如果你都看到了最后这一句, 那不如你也试一试长跑. 谁知道, 也许练一练就能成呢?

I’m not even hiding my weaknesses or vulnerabilities; I’m just really good at not showing them at work. Navigating the workplace can feel like walking a narrow path. In recent years, I’ve often been the one setting expectations for a small cohort of peers, which leaves me with fewer opportunities to express my own struggles. Of course, I’m privileged to have support systems — a strong circle of managers and mentors. But even with them, I naturally position myself as someone with a high caliber, someone who has things under control. It’s hard to loosen up, if ever.

That’s why meeting a co-worker with a similar background and interests felt so refreshing. Suddenly, I’m not the only person who cares about speech quality and style; I’m not the only odd one trying to do things differently; and I’m not the only person with unpopular opinions who happens to favor alternative solutions. Maybe I’m still the guy who approaches problems from unusual angles — but now I know I’m not alone, and that makes me happier.

From another perspective, maybe I simply haven’t opened up enough to others or given myself the chance to build more allies. Something to learn to change.

1. AI 辅助全栈开发实战

概要

• 结合 Gemini 架构决策与 Antigravity IDE 智能编码

• 复盘如何利用 AI 工具(Gemini 和 Antigravity)在一个周末内构建并上线一个高性能的个人静态网站.

• 不算建站教程, 应该是 AI 辅助工程(AI-Assisted Engineering)的实践分享.

项目背景与目标

目标: 把substack还有podcast的内容,可以同时sync到自己的服务器上.

核心需求

• 高性能: 静态页面, 极速加载. 不需要复杂的网页功能

• 低成本: 零维护费用, 免费托管.

• 掌控权: 数据完全自有, 独立域名 (tuwang.ai).

AI 角色

• Gemini: 架构,做简单的research -- 负责技术选型与方案制定.

• Antigravity: 负责代码实现, 调试与资源生成.

2. Gemini 技术选型

架构决策: hosting static website

技术栈:

• 框架: Hugo (构建速度极快)

• 托管: Cloudflare Pages (全球 CDN, 自动化 CI/CD)

• 开发环境: Antigravity IDE

决策依据: 相比 Wordpress, 该方案在性能与迁移灵活性上达到最佳平衡.

3. Antigravity 实战

Phase 1 - substack migration

挑战: 将 Tuwang Substack 的非结构化内容迁移至 Hugo 的文件系统.

实施步骤:

• 数据清洗: 提取 Post 001-031 内容, 转成markdown file.

• 使用工具: 我特地做了一个工具 Substack Scraper 来转化文章

• 简化: 有些复杂的substack组件, 或者图片, 太过复杂, 所以我选择了重点转化文字

NOTE: 我们没有简单地复制粘贴, 而是利用 AI 将内容结构化, 然后整体地转化.

Phase 2 - podcast widget

痛点: 只有 Spotify 播客的主站链接, 如何快速生成结构化列表?

Antigravity 的高光时刻:

• 自动抓取: 直接扫描 我的Spotify主页, 自动提取单集元数据.

  • antigravity 的browser功能点击button还不太准, 所以最后完整的链接, 是我手动抓取html源码给他的

• 自动分类: 把最新的 ‘The Build Log’ 跟 ‘土汪遛弯儿’ 分别归类到不同的table (我完全没有指示)

• 布局演进:

  • 尝试 1: 3 列 Grid (信息过载, 拥挤).

  • 最终版: 2 列 Grid, 统一宽度 100% (清晰, 呼吸感).

技术细节:

• Embed 优化: 放弃默认大卡片, 强制使用极简播放器 (height=80px).

• 历史回溯: 自动补全 “土汪遛弯儿” Vol. 1-20 的 ID.

• Antigravity agent 直接帮我生成整个 podcast table

Phase 3 - 首页设计

设计理念: 拒绝整段的列表, 打造动态简约的preview.

技术实现:

• 模板覆盖 (Template Override): 创建 layouts/index.html 覆盖主题默认行为.

• 动态预览 (Dynamic Preview):

  • 逻辑: 自动抓取 letters.md 和 podcasts.md 的最新 2 条内容.

  • 实现: 在首页渲染预览组件, 而非全量列表.

• 视觉打磨:

  • Headline 颜色调整为浅灰 (Light Grey), 增加换行呼吸感.

  • “More...” 链接移至标题行并缩小字号, 优化视觉层次.

SVG 图标生成

场景: 页脚社交媒体图标 (Social Icons).

AI 高光:

• 需求: 将文字链接转为图标.

• 执行: Antigravity 自动搜索图标资源 -> 绘制 SVG 路径 -> 处理图片下载与上传 (我完全没有指导这个方式)

• 结果: 零手动素材处理, 直接生成可用代码.

4. 部署与填坑

Troubleshooting: Cloudflare 构建失败.

Gemini 帮忙错误分析:

• 问题: npx wrangler deploy eror.

• 原因: 在Cloudflare上, 我错误地将 Hugo 静态站 选错成了Worker (Serverless function).

解决方案:

• Build Command: 保持 hugo.

• Deploy Command: 重新配置 (关键步骤).

NOTE: 我个人完全没有相关经验, 所以完全靠Gemini的提示解决; 如果没有提示, 我可能要搜索很久.

5. 成果

项目成果

• 上线: tuwang.ai 成功运行.

• 性能: 极速加载, 在国内访问也没有问题

• 体验: 实现了高度定制化的 UI (极简播放器, 动态首页).

个人感想:

• 开发者角色转变: 从 Coder 转向 Architect + Reviewer.

• Antigravity 的 Planning 和 Context 理解能力极大地降低了全栈开发的门槛.

资源

• Tech Stack: Hugo, Cloudflare Pages

• AI Tools: Gemini, Antigravity IDE

• 转化文章: Substack Scraper

太慢接受AI工具的人, 会被淘汰. 但不是被AI取代, 而是被那些提高生产力的同事们取代. 最近的一期的’影视飓风’说到这个类似的概念, 下面这句夹杂了我的个人想法: 今后我们越努力地去手动做一些事情, 回报率就越低. 旧时代的“专业壁垒”正在崩塌. 过去, 我们依赖经验积累下来的“手感”和许多重复性但需要专业知识的劳动, 现在这些都在被 AI 极速贬值. 我大胆地预测, 没有公司会因为个人过去的成绩和努力, 而维持生产力落后的部件.

大厂社畜原本就有悲观的一面: 我这颗螺丝钉, 随便都能取代; AI just made sure of it. 把AI工具用的不错的人, 通常会非常注重记录有效的AI输出, 也就是context. 什么都可以是context: 对代码的理解是context, 做一个development plan是context, 上次AI犯的错和正确的选择是context…等等. 从某种意义上, 我们就是在培养一个记忆更好, 更一以贯之, 并且更能大幅度输出的’自己’. 不是说’别培养AI就行了’, 这不由得我们; 一个员工离开后, 让AI去复习一遍他的过往输出, 就能很快填补上他离职后的知识空缺.

AI coding assistant is a hyper-motivated intern; if you enjoy coaching intern to succeed, you will love working with AI. 这句话是我2025年初, 第一次用AI帮我写代码时候的感受, 也就是所谓的planning step, 做规划是必不可少的一步. 我给AI写的第一个task, 其实就跟我给实习生写项目简要一模一样: 写目标, 阅读资料, 详细步骤, 还有过去的例子. 转眼间将近一年, planning也很自然的变成industry standard. 如果在AI-first的工作环境里有层级的分别, planning也许就是最基础的一层. 不做planning, AI体验一定很差.

自我矫正和记录让AI coding变得极为实用. 就像我们软件工程师, 通常会做一个cheat sheet, 记录过去用过的命令, 记录过去的一些重要事情, 犯过的技术错误等等 - AI也一样, 在线自我矫正. 同样的错误很难再犯. 跟AI合作, 就变成了一个做笔记的过程; 用得越多, 做的越好. 尤其是在写代码这样的工作, 我们自己的AI工具, 很快会个人化, 帮我们输出更有价值, 更有个人风格的代码. 也就是我们的Digital Twin.

适应AI工具的过程, 有点武功尽费重新修炼的意思. 也就是说, 在有一些工作上, 有时候局外人能提出’反常规’的想法, 而就因为AI的生产助力, 那些过去反常规的, 天马行空的想法, 也许现在可以泥石流地解决很多实际问题. 我个人觉得, 人对新鲜事物的接受度, 或者对新鲜事物的好奇, 会随着经验和年纪的累积而递减; 所以打破原有习惯会特别难受. 因此, 从软件工程的行业来看, 那些经常活跃在不同技术领域的人, 或者被工作要求学习新东西的人, 眼下会特别自在 - 他们本来就要常常打破常规, 重新学习新领域, 而AI还帮他们学的更快.

我用的最多的是Claude Code; 最近开始尝试 Antigravity. 这些新工具让我突然有种要revisit十几年前笔记里的那些奇奇怪怪的想法 - 有些是embedded system, 有些是social network; 过去因为时间,精力,学习能力等借口而放弃的项目, 现在仿佛又突然可以给他们一些回炉的机会.

总体而言, 我非常期待AI industry的每一个技术飞跃; 那些年轻时候不切实际的想法, 也许能再次放飞.

过去的一年之间, 我的工作的氛围有了极大的变化. 从team role转到org role; 从带组员转到带TL; 从跟IC协作到跟EM协作. 在这个过程里面, 我发现自己难回到曾经那个up主的节奏里: 我的表达欲受到了一些冲击, 似乎因为看到了更多的人和事, 导致过往的’经验总结’显得过于肤浅, 无法入目. 基于这个认知, 我把小红书, YouTube, B站上面的视频全部下架了.

我姑且把这样的心理变化归类为个人成长, 但本质也是一种被打磨后的怯懦. 回想年少的自己, 未曾有顾及别人利益的情商, 看到不顺的事情还会写写文章; 而今, 每每有想法却无处表达, 瞻前顾后, 只能在网上给认同的观点加个赞.

2019年是我表达欲的巅峰, 那时候做了很多coding interview, 也做了很多人生低谷的自我检讨. 当时的我认为我是有信息差的. 而今, 我已经不具备明显的信息差, 尤其是跟硅谷大厂的同事们相比, 我能给到的信息, 远不及身边人.

这几年我都很喜欢听podcast. 从Mordern Wisdom听来的一个想法我非常赞同. 其实我并不需要是整个房间里面最聪明的那个人 - 做最愚蠢的那个人, 做提问的那个人, 没什么掉面子或者不好的. 这句话在我心里来回折腾了好几年. 现在的我认为, 我的能力从来不是有超宇常人的眼界, 但是我具备一定深度的同理心和好奇心. 这可能是一个新的方向.

2025年初的时候我在西雅图出差, 那时候已经有了重整podcast的想法. 当时我去跟课代表立正聊天, 受到了鼓励, 次日就录了编译日志的第一期: #1 课代表立正: 打开第四面墙, 走进课代表的世界. 就录视频而言, 我已经有了5年多的经验, 但查资料做采访, 那算是头一回.

在给播客取名字的时候, 我给它的定位, 是要找寻builders and thinkers. Builder字面意思, 就是那些创造者/构建者, 同时也包括了自我提高的人, 尤其是那些运动, 训练, 比赛的人. 其次, thinkers顾名思义, 就是乐于思考的人.

在过去的几个月, 我断断续续做了这些采访.

• 硅谷

  • #8 Heng: 在科技大厂从Staff Engineer转职Engineering Manager

• 美国

  • #2 Wilson: 接纳洛杉矶这座城市, 她也会接纳你

  • #3 GeekPlux: 打开美国的“战争迷雾”, AI时代的自我补全

  • #4 QIN: AI时代, 中式拼搏还是美式松弛?

• 跑步

  • #5 Wade: 越野入坑? 先把钱花了 | UTMB

  • #6 MuJing: 马拉松赛道上的人生刻度

• 人物

  • #1 课代表立正: 打开第四面墙, 走进课代表的世界

  • #7 Dr. Peter Jamieson: AI Dynamics, Empathy, Be Great Educators Through Games

做采访很有意思. 每个人, 都是他自己世界的main character. 哪怕有一些问题我是知道答案的, 但是他们每个人都有自己的故事和全新的见解. 同时, 我能够感知到每个人性格中独特的质地; 也许是特定沟通环境的协助, 几乎每一次, 我都有那么些个瞬间, 发现 ”原来你还有这样一面!” 或者 “原来我们的观点如此相同!”, 这一点让我非常惊讶和惊喜. 也许这是人与人, 面对面直接沟通的力量.

The Build Log, 我觉得编译日志是个好译名, 你怎么看?

② Vibe Coding | 人脑的认知负荷?

vibe coding 的中文叫啥来着? 氛围编程? 沉浸式编程? 怎么说都好, 大势所趋. 最早认真尝试, 应该是从课代表的superlinear.academy community里面开始的, 大约是2025年初. 中间断断续续的, 其实我上手非常的慢. 今年Q2的时候, 我的工作工作项目逐渐地跟internal tools, AI agent有了那么些关系, 我就不得不看了. vibe coding 已经席卷了科技公司的工作模式. 如果还没有拥抱vibe coding, 我觉的就有一种拿着石器时代的工具在工作的感觉, 什么事情都比别人慢好几倍.

#7 Dr. Peter Jamieson: AI Dynamics, Empathy, Be Great Educators Through Games

这这一期节目里面 (英文), 我跟Dr. Jamieson聊到一个观点, 为什么有时候年轻的同事, 反而比我们这些老员工更不愿意接受vibe coding? 照理说, 不应该反过来么? 难道是我们更加有紧迫感怕被替代? 我们得出的一个观点: 软件工程师的学习和训练过程, 不是教这个人’怎么写代码’, 而是教他该如何’思考/设计代码’. 写代码, 只是一个最终的结果, 而做系统, 架构设计, 才是一个工程师从菜鸡到senior的主要成长标志. 那么, vibe coding从0到1的效率那么高, 就会让一些年轻程序员担忧失去了学习的机会; 再或者, AI现在已经能取代的, 恰恰是入门级程序员的工作, 这样也会让他们有一定的反感.

我觉得这是个值得深思的问题. 在AI帮我们完成很多事情的时候, 它做到的到底是”1/ 重复性的工作”或者是”2/ 我原本就会放弃的思考”, 还是”3/ 我原本必须该有的思考”.

• #3是比较危险的: 它会导致我们思维的简化, 对AI的重度依赖, 对自己能力的质疑.

• #1, #2 会提高我们处理事情的效率和准确度, 甚至帮我们开阔一些原本会放弃的路.

有一个词叫做cognitive load, 就是我们人脑的认知负荷. 我们一定会有这样的感受, 如果学习的时候看了很多东西做了很多题, 人是会非常疲倦的; 工作时, 如果不断的开会, context swtiching, 一天下来, 也会感觉超负荷超级累.

认知负荷的理论, 有三个方面:

• 内在负荷: 学习材料本身固有的复杂性所带来的负荷。例如，一个复杂的问题本身就比一个简单问题产生更高的内在负荷。

• 外在负荷: 信息呈现方式不良或任务设计复杂所带来的不必要负荷。例如，不清晰的指令或不相关的信息会分散注意力，增加处理难度。

• 有益负荷: 与信息加工、知识构建和长期记忆的建立（形成图式）相关的认知努力。这种负荷是积极的，促进了真正的学习。

显然, 内在负荷是我们不太能改变的; 而外在负荷是我们可以控制的. 乐观地去向, 有AI帮助的时候, 就会直接改变我们cognitive load, 我希望他能够帮我减少外在负荷, 在维持我们所需要的有益负荷.

就比如说, 我们家的马桶按键坏了, 我需要找到更换它的教程然后自己动手学会如何更换:

• 内在负荷: 换零件本身的难度和它的基本原理

• 外在负荷: 零件叫什么名字, 英文怎么说, 在哪个地方可以买到, 是不是很贵, 是不是必须要专业人士来检修

过去, 我可能要在外在负荷上面寻找很久, Google搜索, YouTube去找相关的视频. 因为我没有办法把损坏的零件在网上直接找到, 同时因为我缺乏这方面的知识, 我的搜索是非常没有效率的. ChatGPT帮我瞬间解决了这些外在负荷, 并且负责地告诉我这是几块钱就能解决的小问题, 完全可以自己搞定. 这就是一个完美的高效帮助.

最终, 我仍然学会了该如何换零件(有益负荷), 但是外在负荷减少到几乎为零.

回到vibe coding, 我就在想, 有没有什么好的方式, 让我尽量减少外在负荷, 而维持有益负荷?

1/ 我觉得我们在开始写一段代码的时候, 应该自己去掌控的是对整个项目的设计, 安排. 在给coding tool下任务的时候, 还是把它当做一个intern来对待, 尽量在不废话的前提下, 把系统e2e要做的事情, 先自己想明白, 再写下来安排好.

2/ 当vibe coding报错的时候, 我们应该去积极的看报错分析, 理解报错的缘故, 做调整跟安排. 在这个时候, 做出积极的改变, 把这个错误记录下来, 写在coding agent的代码规则之中, 避免下次不犯错. 这一步就是有益负荷, 我们自己做出了努力去思考, 并且积极做出了选择, 而不是把选择交给AI.

关于AI对我们的影响, 你怎么看? 欢迎在任意地方留言!

小宇宙播客: Vol.20 我人生的第一场体育比赛 | 10K PB

去年 12 月，我突然想跑步，但35 岁的膝盖还行吗？ 于是我先在跑步机上试了试，感觉还行。但换到室外，发现硬地+坡度=灾难！小腿前侧疼得要命，姿势不对+肌肉不够力，跑起来像是在硬抗。💀

调整步伐后，问题没解决，反而膝盖更累……所以前期训练就是不停试错，努力找到不崩溃的跑法。

10K 训练：从“跑崩”到“稳住节奏”

1. 起跑太猛

第一次尝试 10K，前半程猛冲，后半程直接“走路大赛”，6:46 配速收场。

2. 跟别人跑容易乱节奏

和朋友一起跑，结果第 4 公里就炸了，自己的节奏才是王道！

3. 找到适合自己的配速

多练几次后，配速提升到 6:32，虽然中间还是掉速，但起码跑完不废。

比赛日：San Francisco 10K

早上 7 点到金门公园，结果下雨+刮风+没带雨衣，只好和大家一起瑟瑟发抖躲树下。（下次带塑料袋保暖, 开跑前丢掉！）

比赛氛围特别 chill，主持人开玩笑，音乐嗨翻，完全不像严肃竞技。起跑线前根本没人抢跑，大家就像菜市场排队一样慢悠悠地移动。

沿途观众太给力了！

• 有人举着“Power Up” 向日葵牌，大家都会去击掌🌻

• 桥底下有“应援团”在敲金属管助威🔥

• 终点家人朋友疯狂鼓掌，整个体验超温暖

冲线！

因为误解了路标，我一度以为自己的表有问题, 还剩很多路程。结果志愿者喊“快到了”才发现只剩 500 米，赶紧冲刺！最终 6:18 配速完赛，比训练快了一点！ 🎉

跑步的收获🏆

1. 比赛比训练更燃. 现场氛围和沿途观众的加油让你不得不撑下去

2. 自己的节奏最重要. 开跑太猛=后面炸裂，稳住配速才能保持输出。

3. 装备细节很关键. 雨天跑步要带个一次性雨衣！

4. 音乐很重要. 这次听了 big bang、汪峰、老王乐队.

下一步？半马！🏃‍♂️

目标是 挑战 21K，重点训练后半程耐力，争取 10K 进 60 分钟！💪

我原本对写new year resolution有所抵触, 因为从未完成过一年的计划; 花几个小时就为了当下感觉良好? 不太值当. 可是反观工作: 我最擅长的也是把饼转化成execution timeline + 收尾; 通常我喜欢把项目规划成超不超过12 ENG weeks的时间线, 哪怕18 ENG weeks 的项目在我这里都是过大的, 肯定要找更多人分割, 并排执行.

同样的思路, 亲测有效的执行方案, 我竟然从来没有给自己施行过. 因此, 我决定给自己的Q1 做个2025年度规划:

1/ 沟通成长

• 完成6次有准备的演讲或者视频, 不限工作/副业. Stretch: 12次.

• 发起24次新人coffee chat, 不限工作/副业, 但普通1:1之外的. Stretch: 48次

• 找到适合自己的Toast Master Club, 成为会员

2/ 健康&运动

• weekdaily avg burn 500 calories, stretch: 700 calories

• 挑战10k(2/2/2025), stretch: 挑战半马

• Snowboarding学会ride switch, 录一个ride switch video

3/ 学习

• LLM的自我修养: AI Builders课程; 总结至少一篇文章: LLM跟如何帮助我成长.

• 读4本non-fictional, non-bio的书 (因为我偏爱bio, 要去除一下). Stretch: 8本.

4/ 工作

• Q1‘ 2025的项目落地, 让团队延续2024的成长曲线

• 通过 12 - 18 months technical strategy

• 规划出自己的L7 path

这个规划我会在Q1结束的时候(03/31/2025)重新填充发布, 希望能hit stretch goals, 给自己一些收获.

• Pass: ✅

• Delay/Miss: ⚠️

• Fail: ❌

当时的契机是我们都听过的那种: 隔壁组的manager转走, 于是需要一个人来补. 不久后的将来, 我可能又要面对类似的选择: 我们自己的团队壮大许多, 所以在某一个时间节点, 我们会需要加一个manager.

我过去这两年一直在做Tech Lead, 我们原生的工程师团队成长到了14个人; 还有一些散装的合作的小团队. 我的角色一般是找找scope, 带带项目. 如果转职为管理, 对我来说, 是工作核心内容的彻底变更, 也相当于对这几年积累的机遇直接放手. 因此在这个选择上, 我找了一些前辈探讨, 今天的笔记就是讨论的一些话题点.

很多工程师默认的职业规划就是转管理. 曾几何时的我自己也有这样的想法. 举几个比较传统的思维:

1. 写代码是年轻人的活, 所以资历深更适合做管理, 总不能写一辈子代码?

2. 管理职位, 有个官职似乎更厉害, 眼界更开阔, 更有机会成长?

我对这两个假设都有一些不同的想法. 对传统观念的疑虑不是今天讨论的重点, 这里暂且不表; 我们主要讨论, 在去除这些传统观念之后, 客观地去考虑, 该如何选择呢?

首先, 我们来说说具体是什么时候有转职的机会:

工程师在升职到到了Staff或者Senior之后, 自然而然就有了这样的机遇. 我司职位到了level 5, 所谓的Senior Engineer, 就有资格转M; 同样级别对口的是M0. 职位到了level 6, 也就是Staff Engineer, 对口的就是M1. 近些年, M0已经很少见了, 大多数转管理的都是L6 > M1.

在传统的Manager职位之外, 还有一个TLM的职称, Tech Lead Manager. 他的职责兼顾Tech Lead, 要写代码管技术, 同时还要做Manager管组员的成长. 在兼顾的同时可能只带两三个人, 少一些人头; 他遇到的问题可能是要两者兼顾, 而哪一方面做的不好都会影响自己的评价.

在考虑做管理或者技术的时候, 有几个方面可以去参考:

1/ 长远看, 比如5年10年, 我们的长远目标是什么? 是要在people management的方面继续成长, 还是在technical leadership方面继续成长?

过去我的方向是要最终走到管理层. 当然这也不是我自己的想法, 而是来自父辈的建议.

2022年那时候, 我在公司目睹了我们的明星工程师是怎么工作的: 不但有话语权, 而且用经验和判断给大家解决的实质性的大问题, 最后我知道这个前辈自始至终都做IC, 有一段时间变成了Engineering Director. 他的成功给了我很多启发: 也许不转职管理, 同样还是有机会攀登职业的巅峰.

我的目标是在自己的领域有所作为, 但我并不觉得一定要做一辈子技术或者非要转换成管理. 那么这个问题就没有一个明确的答案, 我需要用第二个问题来帮我定位.

2/ 从个人影响最大化的角度看: 平时工作的时候在项目操盘我们成绩最多? 还是在帮助队友成长方面最有成就? 说白了, 做什么最拿手最开心最有回报?

我司最大的优点就是不会用职称限制人的作为: 有时候我顶着Tech Lead的帽子, 也常常做些帮人事牵线, 摆平沟通桥梁的事情, 于是久而久之有了一点people management的影子.

但我的工作中, 找scope, 带项目还是我发挥最得力的地方, 给团队带来最大的帮助也是这一方面. 有时候TL 和 Manager的工作内容会有一些重叠, 但我是大幅度偏向TL的老路子. People management应该只是顺带着做的一些小工作, 而不是我侧重努力的方向.

与此同时, 在application layer的很多项目的成功, 需要的是经验和对行业的判断, 而并不仅仅是纯拼代码. 我感觉这可能是我能够画饼和发挥的主要方向. 要长时间保持着敏感和判断, 我是不能够离开技术和第一线的. 从这个角度, 我的优势在单纯的管理岗位会很快消磨干净, 而我能够给团队带来的助力, 也将会消失.

总而言之, 从个人贡献的角度, 技术岗位是我的不二之选.

3/ 功利的考虑: 哪种职位在近期和长远是比较可持续成长的? 有没有行业的一些风向可以参考?

北美科技行业从2023年开始就进行过几轮大瘦身. 我倒不是想说管理岗位比技术岗位更容易被裁员, 而是说, 当整个行业更加提倡扁平化之后, 很多公司都不想有那么多金字塔式的人事结构, 那么管理岗位很可能会维持在‘一大片一线M1’的状态, 而manager的升职就更加困难.

由此而看, 维持在一个M1的状态可能是一个非常稳妥安全的选择. 反观做IC可能一直面对新的压力和挑战. 以上这些是行业内众所周知的现象 (至少是北美). 我个人感觉在几年之间, 都应该是这个节奏.

当下manager的状态和成长轨迹, 跟我的个人目标是相斥的, 那么我自然也会从管理岗位门前, 退后一步.

与人讨论时, 我专门请教了我过去的TL, 问他过去如何选择的. 他做过TLM, 转成Manager过, 最终也转回了IC继续做TL. 他给我的建议是, 看清自己是哪种情况:

• ”我敢于面对挑战, 可以变成一个称职的Manager“

• “我对培养团队人才有极大的热情, 而我会变成一个绝佳的Manager”

我百分之百属于前者, 仅仅是怀抱着一种 “你行我也行的原始冲动”, 因此我的转职时机并不成熟. 种种考虑之后, 我跟管理岗位擦肩而过.

如果你面临同样的选项, 你如何抉择?

Why bother writing about the recent past?

• Writing about the 45%–65% of my awake time is a meaningful practice for the year’s finale. Like many others, I dedicate a lot of effort to the yearly performance reviews for myself and others at work. However that only represents merely 40–60 hours per week (~35%–55% of the 112 hours of non-sleep active time). Ignoring the rest 45% — 65% seems silly.

• It’s worth noting down the list of pitfalls so my future self can deal with the stuff with lower learning curves. Each year’s resolution seems to repeat itself: stepping out of the comfort zone, more exercise, attempting some sort of second revenue stream, and then the big bucket of typical career growth items. It’s possible that the same set of struggles were listed 5 years ago and will repeat in another 5 years. Writing about them so my future self can laugh about life running in circles.

For the fun of it, I’m listing things out as if I’m writing the work performance review: What Went Well vs What Didn’t Went Well. They should consolidate a set of bullet points.

What Went Well

• I’m married. Yay!

• Leveled to Staff Engineer; +50% team growth at work.

• Traveled out of the States after 6 years.

• Adopted a Britsh Shorthair. Meow.

• Upgraded dark-themed man cave.

Once on a sunny Saturday morning, after the gym, my wife and I randomly put together some breakfast: yogurt, fruits, smoked salmon, and two coffees. We were either in the living room or sitting out in the backyard, I was in a great mood.

Suddenly I started imagining how things would be like in 40 years when we are in our 70’s.

Are we traveling all the time? Are we still working on side projects? Are we still able to challenge each other, are we in good physical strength and being active? Sometimes I had further thought about how it feels when one of us may have passed, which left me a flash of sentimental moments in my mind. Though she would argue that statistically speaking women live longer than men so it’s all good, nothing to worry about ;)

Coming back to reality, I realize these 2 minutes of daydreaming would just reflect the current state of my relationship, and it’s a pretty happy state.

Getting married was a major milestone for me. I had a cliché but catastrophic relationship before this. Any major relationship success afterward carries much more weight. I’m 2x more appreciative of what we achieved as a couple and understand what it means to be the right person for each other. In short, I think we have a good thing going.

On the work front, the promotion marks a stepping stone towards long-term career goals.

With a pretty solid foundation of personal life, I have been laser-focused at work and worry-free for 4+ years in this company. Don’t get me wrong — we have multiple anchors in work-life balance, which usually take place in the form of traveling or snowboarding. With that, I went all in at work.

Statistically, I actually have little to brag about. My wife has reached the same rank 3 years before me so the staff engineer title was nothing new in my household. Due to numerous excuses and career decisions, I was always catching up with my peers — as of the writing of this, I still am.

Nevertheless, this was still a moment to celebrate! We talked about when would be more comfortable with living costs in the Bay Area, different life choices with career progression, and our long-term goals together. Being able to hit a specific mid-point milestone (despite being late for 3 years) is a tiny sparkle of proof that things are heading in the right direction.

Oh yes, having two Bay Area bread owners in a household has its perks. Check the Man Cave section of this blog to understand more.

What Didn’t Went Well

• Observed a lawsuit and I was resourceless to help.

• The weight loss plan went south.

• The podcast didn’t pick up speed and the Youtube side hustle stopped.

The most critical lesson I learned: there are moments in life that will suck and out of my control, but I must let go of my ego and be able to accept shitty situations and move on; otherwise it’s just digging myself into a hole. Without getting into details, here is a TLDR: I was forced into positions where I was resourceless and could only observe a sinking situation at a lawsuit; I felt small, guilty, and depressed for not being able to help my family. As much as I wanted to grow and improve things in life, there were just imperfect situations and others’ decisions that I couldn’t alter. It’s a particularly sad experience because I had first-hand observation of how money and power (which I frankly lack both) can influence things in others’ favor. I had many moments of realization: what if I had already made hundreds of millions? Would that dissolve some of these situations where money could help?

These life situations will happen regardless of my will but maybe I can choose which way it sucks? Maybe I can counter this with happy memories despite being in a bad situation. Now almost a year later and it was all done, I had many rounds of after-thoughts beyond just the money factor. Sure accumulating more wealth will build a stronger backbone for the family, but that’s just one factor; there are things like health or family relationships that are also fragile. I lowered my expectations that life should continue to spit out bad moments; hopefully, I could navigate optimistic paths to counter them.

Man Cave

I had the mentality of not throwing things away, so getting my desk to a sustainable and optimized state was pretty challenging. It started a year ago:

• getting a dark desk

• painting the wall black

• getting a monitor stand + cable management boxes to hide things

Since then, I have made more changes this year:

• replaced the giant Intel iMac with the new Mac Mini. YO!

• found the perfect corner lights

• dark-themed keyboard + touchpad

• finally reduced my desk to 1 monitor only

Ultimately, he and I both find the man cave soothing; so I’m calling this project a success. He typically wants to participate in the late-night coding hours and provides emotional support (snoring). In return, we took care of his diet, poops, and jumping jacks.

This gentleman officially joined our household in September. I had never personally raised a pet but always wanted to so this was an interesting jump start. Getting to know the habits of another little being, attending to his needs, and being able to co-exist — these felt like the necessary human training that I always lacked.

Some of this stuff—the man cave setups, the quality of life items, a little cat, are all made possible with the both of us making progress towards our long-term goals in careers. Otherwise, I would not be mentally or financially flexible enough to do all on my own. To that, I’d love to note down some gratitudes.

Gratitudes

One special thing that my team does regularly and loudly is celebrating success and thanking each other for their extraordinary work, oftentimes about the extra little things we did that supported or accelerated each other’s progress. Imagine 20+ people writing down their special little thanks to a few individuals for last week’s highlights — this little team culture thing was magical.

Growing up in an Asian family, that’s a major culture miss and I still don’t express enough gratitude outside of work, so here are some makeups for that.

• I’m thankful for the life lessons I experienced that made me mentally tougher in dealing with bad situations. Knowing that life isn’t always sunshine and rainbows, I appreciate how much my parents have provided for this family.

• I appreciate the long-term goals finally coming together — having a family, a career, and a little being to take care of — a lot of which I own my wife pushing us or supporting me to do. Some call that persona a strong independent woman; I just know that it’s extremely rare to find someone smart, competitive, respectful, and sharing goals alike in life. Meanwhile, it’s also pretty unusual for someone to bear with your shortcomings and past failures, and still plant faith in you. This is something worth cultivating and protecting.

• I cherish the friendships I reclaimed this year. I reconnected with multiple school friends — some have long migrated to the next stage of life. They reminded me of the priceless memories we shared.

• I appreciate the good people I came across and a lot of these folks are from work. The challenges and big moments we experienced together allowed me to observe their sparkles: some were extremely good at articulating and navigating hard situations; some were super resilient in dealing with complex situations; some were just dead-fast efficient. These strong personal traits pulled me closer to what I want to achieve in personal growth.

With all that said, I’m looking forward to a badass 2025!

For a long time, I have been chasing after the prestigious title of senior engineer. I was mentally exhausted when I achieved it a few years back. Leading up to this latest title update, my anxieties piled up— what’s next? (vol.15 小宇宙FM)

Senior Engineer, 2022

In 2020, I flopped my interview for the senior engineer role at my dream company. Through a series of debates, I also gave up on the senior engineer role at Uber for which I aced the interview. I proved that I was worthy of a senior title, even just for a few hours at San Francisco Uber HQ. But on the flip side, I picked the lower rank in favor of my dream company.

Since then, it has been a long process of proving self-worth in the new company while balancing insecurity and impatience. I was not comfortable with a junior title so I accelerated where possible. It still took 1.5 years to change. Imagine many moments during COVID, I would question myself a bit — what if I went with Uber? The process of proving myself would be the same but I don’t have to spend extra energy justifying that I am so different from the rest of the junior cohort. It was no one to blame but that was a tedious process.

When I eventually achieved the senior engineer title in 2022, unexpectedly, a great sense of defeat and disappointment bubbled up my chest.

I should have been happy. Why did I feel such a great deal of disappointment?

Immediately I started judging: have I become the stereotyped personality that only knows about grinding but lost the sense of gratitude? Have I lost my way of chasing this prestigious senior title while not recognizing that these titles were just meaningless?

A few things have contributed to that moment of disappointment.

1. It was nothing to be proud of. My peers have achieved that title maybe 2–3 years ahead of me. I spent all this extra time to hit the senior title. Me getting this title 2–3 years late was nothing to brag about.

2. When would this chase ever end? After this small hill, all of a sudden my goal switched to the next mountain, a staff engineer title. I have exhausted so much for these past few halves. I had to start grinding right away again.

3. I was tired. Is the senior title the end of my marathon? The next title seemed so far from reach. Should I take this terminal level and chill?

I did not solve this mental burden for another year or so. But I also kept hitting the ‘next big project’ within my reach — work has been busy so I was soon distracted from my existential crisis.

Staff Engineer, 2024

Same chase but a different mental model. I no longer worry about proving myself but focus on landing the next big project; I no longer worry about not hitting the next level because I knew it was often opportunistic.

It’s still very exhausting after 2+ years of chase, but this time around, I felt pretty good about the Staff engineer title. Of course, I have nothing to complain about. I thanked my manager for the guidance, and my peers for the support, and shared to my family the good news.

Early in 2023, I established my position as a TL on this team. Even though I have been operating like that for a while, this official TL role solidified my mentality and made me realize that I had lined up with the best shot at my next goal. Nothing was disadvantaging for me. I just needed to jump over the hurdles to get the prize, which I had done consistently for 3 years.

This was a great career setup for me.

The largest mental shift was that the engineering ladder was not the only goal (Oh it was too devastating). Rather, I found an actual sense of achievement in bringing my group of people new opportunities. Of course, then they do have to deliver these identified opportunities. These were moments ‘Aha, my vision was right and you did a great job succeeding in that!’ I loved it.

With this mentality shift, strangely, odd-sized opportunities did show up one after another! I also had a strong team to chase these goals together. We delivered multiple long shots and even grew the engineering team further.

I became even more focused on impact rather than on the hard title goals. I was deep chasing after these big bets. I would be lying if I didn’t feel slightly defeated when my Jan 2024 rating didn’t push me over the Staff engineer bar. But the feeling was in and out of my mind because I had many more meaty projects to plan. I simply don’t have extra time to worry about when I will get my title.

The staff title came after 2+ years. It felt great this time.

What’s Next

The imposter syndrome kicked in a bit. Of course, I quickly acknowledged that even though my responsibility may have changed, I was no different than myself a month ago.

I have the same self-esteem and the same mix of introverted personalities. I don’t have any elevated ego and I’m not suddenly 20% more experienced. None of my co-workers will respect me more than what I deserve (from past collaborations). My company hides internal ranking information anyway. Unless my peers know my anonymous blog, nothing changes in my dynamics.

Naturally, I’ll go after the next title. If my senior experience is a trembling phase, then my staff experience should be a path aiming at a long-term trajectory.

No matter what type of dumpster fire stress comes up, hope that I can keep my cool and don’t have to take myself too seriously. If I can bring along a few folks to get what they want, that would be a dream.

那些不再用的代码, 通常被叫做 dead code.

每隔一段时间, 这些不用的代码会被手动清理掉. 不然, dead code会将系统变得臃肿, 难以维护, 有时候还会浪费一些计算资源.

比如, 有一些冗长的 if/else 曾几何时用来控制迭代版本的, 而多年后, 所有traffic都在最新的版本, 我们理应删掉不用的code path; 有一些 function 是当时防备一些edge case的, 而多年之后, 这些边角问题早就不存在, 我们没必要维护这些附加功能 … etc.

既然是没用的代码, 留你何用? 为什么不删除? 你怎么想?

• What Doesn’t Break, Don’t Fix It: 工作时, 大家一般不太想碰这些代码. 等出了问题, 报错了, 才会引起人的重视, 再删不迟

• Perceived Value: 再次遇见那一坨不用的代码, 我们很可能给出保守的判断: 这块代码, 未来可能还用, 是不是该留着?

• Identity and Self-Worth: 若是一串引以为傲的代码, 即便真的用不到了, 心理上肯定还有一点阻力: 是不是删掉了就意味着之前的功夫白费? 是不是就意味着之前的付出是无效的?

• Additional Efforts: 删除dead code也并不总是轻松: 我们还是要测试, 还是要验证’没用’的假设, 花好一番功夫. 在效率至上的工作环境里, 谁会无缘无故花几个小时给代码瘦身?

基于这些因素, dead code 很快就会积累起来, 让一个工程团队变得行动迟缓. 应对这个问题的方式, 当时还是从这个团队里面的人着手: 给清理工作带上光环, 让大家愿意做清理工作, 崇尚整齐有序的code base - 再一些公司里面, 这类工作可以被称作 Better Engineering, 或者概括为Best Practices.

每过一段时间, 工程师们会自发地组织起来, 清理dead code, 并且对此举引以为傲. 试想, 不久后的将来: AI对工程师的一大帮助, 可能是有序地建议dead code 清理, 并且做好测试, 让工程师更便捷地规整code base.

② Cutting Junks

近几年, 我有几次断舍离的机会.

Physical Junks

在西雅图, 我曾经有一个储藏间, 在里面存放着从2010 - 2020, 十年多的物件: 大学的铅笔笔记, 旧衣物, 旧家具, 主机箱, 损坏的电脑, 乐队杂物, 纪念品, EE硬件零碎, …etc.

这场清理会让人走一遍memory lane: 曾经的笔记, past relationship, 硬件零部件, 每个阶段认为”贵重”的东西.

最后我决定留下的只有小小的memory box, 里面的东西很基本上没有什么经济价值, 不过有一定的情绪价值

Digital Nomad - Minimum Household

数字游民的那两年, 每次离开一个地方 (湾区, 夏威夷, 阿拉斯加, 纽约, 西雅图), 我们也被迫做一次清理; 想带着的只有两三个行李箱, 一个吉他.

在买新东西时候, 都会考虑是不是真的需要, 能不能带走? 就算要买: 离开时候, 哪些家具可以卖掉? 哪些价格便宜可以捐掉?

绕了一大圈2022年回到湾区, 我的想法已经很不同. 打开2020离开时启用的仓库: 沙发, 桌子, 衣服 … 存了一年多的东西, 最后拿出来全部卖掉, 捐掉.

当时以为需要留的东西, 其实后来都不那么重要.

Digital Junks

Google跟很多大学有过协议, 我的大学也不例外, 用了Google Workspace (Gmail, Google Drive…etc). 虽然毕业很多年, 但学校的Google邮件都保留着, 我从没有想过要清理.

从2023年开始, 谷歌开始开始终止跟一些学校的协议; 7/1/2024, 谷歌正式跟我之前大学解约. 这意味着我需要把过去的资料备份转移.于是我又走了一遍memory lane: 当年的项目, 资料, 邮件, 全部复制一份到自己的Google 账号.

目前, 我的Google Plan扩展到10TB ($50 / month), 很自然地, 我又要开始一轮切割, 把这些不需要的文件删除掉, 解约储存资源.

为什么会积累废品?

对于那些不用的东西, 有可能带有情感依赖, 象征自我价值, 或者暗示未来需求. 我们有日渐扩大的生活空间, 或者网络储蓄空间, 给这些”废品”提供了积压的余地.

这些物品随着时间推移, 对于我们个人的独立存在讲变得越发不重要. 比如, 10年前你可能维护着二十几份精湛的课堂笔记; 那种做事的条理性会变成习惯, 但我们并不需要那些笔记本身, 更不需要完整4年的笔记来见证这段过往.

别人记住我们的, 和我们记住别人的, 都是仅仅是那些精彩的瞬间. 我们既然不活在过去, 那么抓住重点就足够了.

③ Mental Burden: Should I Be Responsible For All?

原生家庭

很多年, 在潜意识里, 家人的状态好像是我的责任. 反观我的童年, 这似乎是文化给小孩子的一个枷锁: “你的父母家人很辛苦, 所以你千万不要惹他们生气, 这样你们一家人才会好”.

看似一个合理的连带关系, 实则一种枷锁. 如果父母的幸福需要小孩子来维护, 那是不是颠倒了父母和孩子的身份? 如此一来, 小孩子反倒要照顾父母的喜怒哀乐, 而父母也失去了施加关爱的能力? 这种逆向的关系并不会因为孩子成年而解锁.

这个想法来自于一支podcast: Morden Wisdom (Chris Williamson); 同时他也是我想尝试podcast的灵感起源.

一个episode里, 嘉宾提到自己一直背负这样的心里压力: being responsible for others’ happiness. 而他人不幸福快乐的时候, 他也会有一定的负罪感. 反过来说, 也是一种自我价值的依赖: 当他们也需要我, 我才有在这个家庭合理存在的意义.

这种潜在的反向依赖, 在personal relationship和工作里面都会体现.

团队

工作了很多年以后, 我很清楚地感觉到一种’脱不开工作’的状态.

仿佛很多时候没你不行: 不管谁oncall你都要在线, 不管是什么报错, 你都需要心理有数; 一些同事能不能做出成绩升职加薪, 你都要有一定的担当. 这些可能是一个leader应该承担的, 但这也可能演化成一种无法scale的状态.

是不是说, 这种’负责任’的心理状态, 也是那个”自我存在意义”的衍生? 我们必须对他人提供更多的价值, 这样我的存在才更加合理?

但是反过来想: 如果所有的burden都由一个人来背, 队友是不是没了机会成长? 如果难题都等某一个人解决, 那是不是变成了团队的瓶颈? 如果每个人的成长都牵连到某一个TL的能力, 是否也意味着过大的风险.

Trusting others to do the right thing. 一段时间以后, 我开始努力把一些重要的位置空出来给别人: 一部分backend比较晦涩的难题, A来扛一扛; 一部分frontend的全新技术栈, B来主导一下设计. 就我目前观察, 这些承担更多责任的队友, 似乎比过去更主动积极.

建立独立的心理状态是挺独特的一种体验: 对同事, 我们共同承担着责任; 在特定的时候, 我需要把机会给别人准备好, 但是每个人是不是能够独立解决挑战, 独立成长, 有时候要取决于他们个人的天时地利.