Shopify如何打造高强度文化 | Farhan Thawar（副总裁兼工程负责人）

如果我在九到五这段时间里能多完成一些事，咱们花的时间一样，但我做的事更多。

If I can just get more done in the nine to five, we have both ex the time has elapsed the same for us, but I just got more done.

这样一来，我就能理直气壮地说：嘿，

And that allows me, of course, then to be like, hey.

我可以去接孩子踢足球，做别的事。

I'm gonna take my kid to soccer and do other stuff.

下班后咱们能做同样的事，但在上班时间，我只想尽量在有限的时间里把活干完，而不是把时间拉长。

Like, we can still do the same things out of work, but during work, I just wanna try to get as much done as possible during the time versus expanding the time.

我可以举个例子。

And I can give you an example.

对吧？

Right?

我以前在一家公司，每天干十二个小时，但白天老打桌球，还经常去喝咖啡。

I I used to work at a company where, you know, it was like, I worked twelve hours a day, but I was playing foosball in the middle of the day, and then we'd go for a coffee break.

这些事一做，时间自然就拖到了十二小时，而不是想办法把活压缩在八小时里完成。而结对编程就是个很好的例子，因为这活特别专注，两个人盯着一台电脑。

And, like, you kinda do these things, and, of course, the time expanded to twelve hours versus, you know, trying to compress into that eight hour day, and pair programming is a great example because it's such an intense activity, two people on one machine.

两个人一起合作，避开网络和那些干扰，专心解决手头的问题，真的能完成很多工作。

You can get so much done when two people are working together, being distracted by the Internet and distractions, and just focus on writing, like, the solution to the problem at hand.

而且这特别累人。刚开始尝试结对编程的那几个晚上，大家通常一睡就是十到十二个小时，因为强度太大了。

And it's so tiring that usually when people switch on to pair programming, they sleep, like, you know, ten, twelve hours a night, the first few nights, because it's so intense.

大家真的在拼命干活。

You're working so hard.

不过对我来说，这种高强度反而能带来特别出色的成果，哪怕你并没有多花时间。

But for me, that intensity actually leads to, like, extraordinary outcomes even if you don't have to put in more hours.

我觉得大部分人，你应该也经常听到这种说法，

Like, I think most people I you probably hear this all the time.

大家都会说，对，没错。

Everyone says, oh, yeah.

大家总说年轻就要努力工作，多熬点时长之类的。

Like, work hard and, like, do more hours when you're young, whatever.

但我会想，如果能把每分钟的效率都提上去，岂不是更好？

I'm like, what if you just did more per minute?

对吧？

Right?

就是能快速把事情搞定。

Like, quickly get through things.

还有一个不太容易想到的事实是，真正厉害的人其实能很快产出高质量的东西。

I think there's another unintuitive fact is that people who are really good can actually output high quality collateral quickly.

比如，把一个人水平不错和一个人特别厉害的做个对比。

So, like, take a person who is good and extremely good.

特别厉害的那个人能在很短的时间内产出大量成果，而水平不错的那个可能就得花更长时间。

The extremely good person can actually get a lot of output in a short amount of time, and the person who's good might take longer.

我觉得这里面有个时间上的差异，很多人根本没意识到。

Like, I think there's a there's a time variance there that people don't think about.

你可以在不怎么降低质量的前提下，把时间缩短两倍、三倍。

So you can kind of, like, not drop the quality too much, but get the time down by, like, two x, three x.

对吧？

Right?

这简直就是帕金森定律的放大版。

Like, Parkinson's law at scale.

比如说，我给你一小时做件事，真正厉害的人一小时就能交出高质量的成果。

Instead of, you know, if I give you an hour to do something, a good a really good person can get a high quality output in one hour.

我想聊聊怎么打造一个能这样运作的团队。

I wanna talk about how you create an org that operates this way.

你刚才提到了结对编程，我知道这是你特别推崇的一种方式。

But, specifically, you just mentioned pair programming, and I know that's one of your favorite, tools.

你为什么这么推荐它？它到底强在哪里？

Talk about why this is so powerful when you recommend it.

从外面看，就是两个工程师盯着同一段代码，感觉效率不是减半了吗？

I think as an outside observer, it's like two engineers on the same code.

那为什么还要这么做？

Why would why wouldn't we do things half as half as fast?

你能不能具体说说，为什么你这么看好结对编程？

Talk about just why you're a big fan of pair programming, specifically.

这是工程管理中被严重低估的工具，没有之一。

It is the most underutilized management tool in engineering, bar none.

它根本就没被充分利用，本来完全可以做得更多。

Like, it is just not used as much as it could be.

说到结对编程，可能有些人还不太了解，就是两个人共用一台电脑。

So pair programming, you know, for those who don't know, it's two people on one computer.

对吧？

Right?

两套键盘、两个鼠标、两个显示器，但只有一台电脑。

So two keyboards, two mice, two monitors, but one computer.

他们一起合作完成工作。

They work together.

如果是远程的话，可以用像Tupole这样的工具，我们就在用，能远程共用同一台电脑。

And if it's remote, they use a you can use a tool like Tupole, like, which we use, and you can just remotely be on one computer.

你说得完全对。

And you're totally right.

那个著名的推文是这么说的，关于结对编程，等等一下。

The the famous tweet about, pair programming is, wait a sec.

我们让两个工程师共用一台电脑。

We have two engineers on one computer.

那他们写的代码不会只有一半吗？

Won't they write half as much code?

答案是，不会的。

And the answer is, oh, no.

绝对不会。

No.

他们写的代码甚至比一半还少。

They write even less than that.

因为这根本不是看代码行数的事。

Because because it's not about lines of code.

对吧？

Right?

限制效率的不是谁在键盘上敲代码。

The throughput limiter is not hands on keyboard.

不是说我们俩坐那儿，限制因素就是谁把按键打到屏幕上。

It's not like we're both sitting there, and the limiter is, like, us trying to get through the key like, the keystrokes onto the screen.

真正的瓶颈在于：怎么找到一个好又优雅的解决方案？

The limiter is where is the good, elegant solution?

我们该怎么深入思考这个问题，然后做出真正合适的解决办法？

How do we think through the problem and build the right solution for the problem at hand?

你知道吗，Tobi 在 Shopify 时特别推崇结对编程，他和 CTO Cody 会定个闹钟，一起结对编程一小时。

You know, Tobi famously built a lot of Shopify pair programming, and what he would do is he would actually set a timer, and him and his the CTO, Cody, would pair program for one hour.

如果一小时内没搞定问题，他们就把代码全删了，只保留测试用例，然后重来。

And if they did not finish the problem in one hour, they would delete all the code, and they would keep the tests, and they would start over.

他们的想法是：如果一个功能在一小时内都说不清楚、写不出来，那肯定是设计方向错了。

And then the what their thinking was, if we were not able to articulate and write the code for this feature in one hour, we must be on the wrong design.

说明我们做的是错的东西，所以删掉代码，留下测试，再重新写一遍。

We must be building the wrong thing, And so they delete all the code, kept the tests, and then wrote it again.

有时候只超了一分钟，他还是把代码删了，重新来过。

And sometimes it'd be over by one minute, and he would still delete the code and start over.

因为他的想法是，真正优雅的解决方案，应该能在一小时内写出来。

Because his thinking was the right elegant solution should be able to be written in one hour.

所以结对编程，这算是一个极端的例子了。

And so pair programming, I mean, that's an extreme version of it.

但就连Pivotal Labs也是这样，如果你的搭档那天请假了，你自己写了好多代码，严格的做法是：搭档第二天来，把你写的全部删掉，然后你们再重新写一遍。

But even at, like, Pivotal Labs, if your pair was sick that day and you wrote a bunch of code, the strong version is, like, your pair would come in the next day, delete all the code that you wrote, and then you'd write it again the next day.

再说，还有什么时候比刚写完就重写更适合呢？

And, again, like, what better time to rewrite code than, like, right after you've written it?

因为你现在已经完全理解了问题，虽然听起来像是在浪费时间。

Because you now know the problem domain, and it's by the way, it sounds like a waste of time.

对吧？

Right?

听起来好像就是白删代码。

Like, it sounds like I'm just deleting code.

但原因在于，代码的生命期很长。

But the reason is is that code lives a long time.

代码是一种负担。

Code is a liability.

真正好的解决方案——通常行数更少、更优雅——往往是在你摸索了各种路径之后才浮现出来的。

And the, like, the right solution, the usually shorter lines, more elegant solution, tends to appear after you've done a bunch of pathfinding.

而要完成这种摸索，唯一的办法就是先写起来，然后删掉，再重来，接着发现：不对劲。

And the only way to do that pathfinding is kind of start and then delete and then start and be like, oh, no.

现在我明白了。

Now I know.

删掉。

Delete.

不过删代码其实特别难，毕竟我们是人，总会陷入沉没成本的陷阱。

And it's super hard to delete, by the way, because, you know, we're humans, and we have this sunk cost fallacy.

所以删代码真的很难。

So it's hard to delete.

但如果你能做到这一点，最终你会找到一个好得多的解决方案。

But if you can do that, you will actually land upon, like, a much, much better solution.

当然，结对编程的学习效果特别好，因为你一直跟别人坐在一起——不管是远程还是面对面，你都会学到对方的敲键方式，还有他们思考问题的思路。

And, of course, pair programming has high, high rates of learning because you're just, like, sitting beside like, you're not only, you know, whether it's tuple or remote, like, or directly, you'll you'll learn keystrokes, and you learn how somebody thinks about a problem.

你们会不断交流、互相讨论。

You go back and forth on the talking.

没错，你写的代码可能少一些，但你在为客户创造价值的路上会走得更快，比一个人单干强多了。

And, yes, you will write, like, probably less code, but you will move faster along the path of, like, delivering value for your customers than you would, if you did it on your own.

还有很多研究显示，结对编程能提升幸福感、促进知识共享、减少信息孤岛、增强专注度，而成本只比正常方式高出百分之二十左右。

And there's all these studies that show happiness is higher, knowledge transfer is higher, less silos, intensity is higher, all the things, and at a price of, like, you know, 20% or something of, like, what you would normally do.

我想到的一个类比是篮球里的下手罚球。

The analogy I have is the underhanded free throw in basketball.

对吧？

Right?

统计上证明它投进的概率更高，但看起来很别扭，所以没人这么干。

Statistically known to sink more baskets, but looks dumb and nobody does it.

说实话，我本来不是特别关注篮球，但读过关于沙奎尔·奥尼尔的事，他是名人堂球员。

Like, literally, Shaquille O'Neal I'm not that big a basketball fan, but I read this about Shaquille O'Neal who's a hall of famer.

他们问他：你为什么不试试下手投篮？

And, they said, why don't you throw underhand?

因为他罚球一直特别差。

Because, like, he was notoriously bad at free throws.

他说，那样子太难看了。

And he goes, it looks dumb.

就算他一年挣几百万美元，做这件事，还是觉得太难看了。

Even though he's paid millions of dollars a year to do this thing, it looks dumb.

他就是不愿意这么干。

Doesn't wanna do it.

我记得奥尼尔那会儿，他确实……

I remember those Shaquille O'Neil years when he was Yeah.

请了个专门的罚球教练，我记得他们聊过这事，他说：不行。

Hit a special free throw coach, and I remember them talking about this, and he's like, no.

我绝对不会这么做。

I'm never gonna do that.

我绝对不会做，因为看起来太傻了。

I'm never gonna do it because it looks dumb.

没错。

Yeah.

顺便说一句，回头看看采访的开头。

And by the way, go back to the beginning of the of the interview.

我不在乎看起来傻不傻。

I don't care what looks dumb or looking stupid.

我们就要这么做。

We're gonna do this.

事实上，我经营着世界上规模最大的结对编程团队。

And so, actually, I ran the biggest pair programming shop in the world.

说到这个，像Shopify这样的公司，有多少比例在这么做？

So on that note, so what percentage of shop like, Shopify do this?

你们平时就是这样工作的吗？

Is this how y'all operate?

是的。

Yeah.

我之前提到过，Shopify 刚起步的时候，Tobi 和 Cody 就是这么做的。

So Shopify I mentioned that Tobi and Cody did this at the beginning of Shopify.

关于结对编程，我以前在 Xtreme Labs 的经验是，我们很清楚该开发什么，因为我们做的移动应用几乎像是外包开发。

And the cool thing about, pair programming is and in my old world at Xtreme Labs is that we knew exactly what to build because we were building, like, mobile apps that were almost like contract manufacturing.

我们会有个 iOS 版本。

We're like, we have an iOS version.

那能不能再做个 Android 版？

Can we build an Android version?

所以我们很快就能定下需求文档。

So we kind of quickly were able to say, here's the spec.

赶紧动手做。

Go quick.

Shopify 完全是一家不一样的公司。

Shopify is such a different company.

对吧？

Right?

我们是一家探索路径的公司。

We are a pathfinding company.

我们正在寻找该构建什么正确的东西。

We are trying to find the right thing to build.

所以结对编程并不总是适用。

And so pair programming may or may not make sense all the time.

像 Pivotal 和 Xtreme 那时候，我们每周干四十个小时。

Like Pivotal and Xtreme, we were doing forty hours a week.

Shopify 的结对编程文化则更偏向每周四到八小时，大家聚在一起解决一个问题，说：嘿。

Shopify is much more of, like, a four to eight hour a week pair programming culture where you're gathering together on a problem and saying, hey.

咱们花半天一起结对吧，或者每周三固定结对。

Let's pair for half a day or let's pair every Wednesday.

我们用这个工具快速推进某个方向，但更多时候是在探索路径，琢磨该做什么，还得说服别人：嘿。

And we use that tool in our arsenal to move quickly down a path, but a lot of other time is spent pathfinding and trying to figure out what to build and trying to convince people to like, hey.

我们要往这个方向走了。

We're gonna go down this path.

哦，现在我彻底明白了。

Oh, now I know exactly.

有时候，十八个月后，我们才把所有问题都想清楚了，这时候就该把一切推倒重来，而我们确实会这么做。

And sometimes, by the way, eighteen months later, we've now figured out all the things, and we should that's the time we should delete everything and start over, And that's something that we will do at that point.

所以你不可能连续十八个月都搞结对编程。

And so you don't wanna be pair programming for eighteen months.

你得先探索、找方向，等看清楚了，就说：明白了。

You wanna be, like, way finding and path finding and then go, I see the matrix.

干脆全删了，重新来过。

Let me just delete everything and now build it.

因为我们要的不是代码，是学习的过程。

Because the learning is what you're going for.

我们已经掌握了所有经验。

We have all the learning.

现在可以开始写代码了。

Now let's write the code.

明白了。

Got it.

当代码非常重要，而且你相当确定方向正确时，我们会进行结对编程。

So it's basically when the code is really you're pretty sure this is, correct, and it's really important, segments of the code base pair program.

是的。

Yeah.

另外，在出现故障或需要解决问题时，我们也会结对协作，一起找出解决办法。

And then also we do a lot of, pairing during, like, an incident or a way to, like, figure out together, work with somebody and say, hey.

我不太确定，不如我们开个会，一起看看问题出在哪里，共同分析一下。

I'm not really sure, and let's let's jump on a call together or jump on a tuple and, like, go down the path and say, let's figure out together what's going on.

我忍不住想问，AI 对这种工作方式有什么影响？

I can't help but ask, AI, how does that impact this way of working?

AI 真的特别有意思。

So AI is super interesting.

现在像 GitHub Copilot 这样的 AI 编程助手，其实就是你的搭档程序员。

What's happening right now with an AI Copilot, like GitHub Copilot, is it is your pair programmer.

你现在甚至能感觉到，即使没有真人，也像是在和别人一起写代码。

So you now can feel like you're pairing actually without another human.

你可以直接和 AI 搭档合作。

You can pair with the AI.

而且现在很多人还会用 Whisper 这类工具，对着 Cursor 说话，通过语音指令说：好吧。

And so what's happening too is that you're seeing people use, like like, Whisper, like they're talking to cursor, and they're talking through Whisper to say, okay.

我们来写一个新的 React 组件，实现这个功能，他们一边说，AI 就一边自动生成代码。

Let's build a new React component that does this, and they're talking, and then it's building us.

糟了。

Oh, no.

我不是这个意思。

That's not what I meant.

我是想这么做。

I meant doing this.

你甚至都不用打字，光靠说话就能搞定。

You can actually not even have to type just using voice.

跟你的编程搭档来回互动。

Go back and forth with your pair programmer.

我觉得这太棒了。

I would say that's amazing.

但我还是觉得，把这种体验跟两个真人结合起来更好。

I would still contend take that experience and add two humans together.

比如，一边是AI编程助手，一边是两个程序员——他们可以一起看代码，明白AI想表达什么，然后要么直接删掉，凭灵感自己重写，要么直接采纳建议，继续推进。

So you've got, like, an AI Copilot and humans because what's happening is generating code, the two humans can look and say, oh, I know what it's trying to do and either delete the code because you have inspiration and write it yourself or just take the suggestion and move it forward.

但我特别喜欢现在的AI编程助手，因为从此以后，你再也不用一个人写代码了。

But I love today's world of AI Copilots because you're now you never have to code alone on your own.

对吧？

Right?

你再也不用一个人写代码了。

You never have to code alone.

现在你可以尝试别的语言了，因为 API 和语法都更容易上手。

You can try a different language now because the API and the syntax is much easier to to pull forward.

这些方方面面都对工程团队有利，对所有想开发软件的人也是好事。

And so all of those things are are are, like, a win for for engineering and a win for everybody who wants to build any sort of software.

这很有道理。

That makes a lot of sense.

基本上，每个人都会成为结对程序员。

Basically, everyone's gonna be a pair programmer

没错。

Yes.

没错。

Exactly.

在未来。

In the future.

好的。

Okay.

我想再聊聊你在Shopify做的其他事情，是怎么营造出这种高效氛围的。

I wanna come back to what else you have done at Shopify to create intensity.

我觉得有必要强调一下，这种高效指的是如何在有限的时间里完成更多工作，然后准时下班。

And I think, again, it's important to highlight the intensity is meant to how do we get more done in the time we have and then go home?

不是那种。

Not Yeah.

整天连轴转，周末也不停的那种工作强度。

Just work all day, every day, weekends kind of intensity.

对。

Yeah.

所以我们有几个方面的做法挺管用的。

So we have a few things that we have going for us.

对吧？

Right?

首先，我们有个叫GST的工具，全称是‘Get Shit Done’，你可能听其他Java团队的人提起过，就是每周向全公司同步进展。

So one, have this tool called GST, which stands for get shit done, which you probably heard from maybe talking to other Java folk, which is this notion of, like, weekly updates to the whole company on what's happening.

这其实就是帕金森定律的规模化应用。

Again, Parkinson's law at scale.

如果你每周都问大家进展如何，每个人都会想方设法展示出自己的成果。

If you ask people every week, they wanna show progress every single week.

这是其中一种方式。

So that's one way.

我之前也提到过结对编程。

I talked about pair programming as well.

我们公司以前是半年一次节奏，

The other thing we do as a company is we used to have, like, twice a year was our cadence.

就像黑色星期五、网络星期一那样，或者夏天也会搞个大活动。

We like like a Black Friday, Cyber Monday, or, like, we had, like, an event in the summer.

现在我们改成每六周一次复盘了。

And now we do six week reviews.

所以团队每六周会聚在一起，梳理一下路线图、资源分配，以及他们正在做的工作，不仅要和直属领导对齐，还要和Tobi一起讨论。

So teams have this notion of, like, every six weeks actually coming together and walking through the road map, the resourcing, and what they're working on with their immediate leadership, but then also with Tobi.

这做法挺棒的，不过顺便说一句，这花的时间真不少。

And so what's cool about that and by the way, it's a huge time investment.

对吧？

Right?

大家都聚到一个房间里。

We all get into a room.

明天就要开始了。

It's happening tomorrow.

就是周二、周三、周四这几天。

So Tuesday, Wednesday, Thursday.

我们不少人会一起在办公室，把公司里所有项目挨个过一遍。

We're going, on you know, a bunch of us will be in the office together, and we're gonna go through every project in the company.

每个项目都会讨论：进展如何、资源够不够，然后当场做调整。

And we're gonna talk about the project, the resourcing, how it's going, and we're gonna make changes.

而且，这会带来一种紧迫感，因为你得展示出自己这段时间做了什么，从上一次复盘中学到了什么。

And, again, that creates intensity because you wanna show what has been done, what have you learned since the last week's review.

我们发现六周是一个很合适的节奏，短到你还能记得清楚背景，又不至于太短。

And we find six weeks is a very good cadence because it's short enough that you can remember the context, and it's long enough.

六周已经足够长了，尤其是如果一个团队有十几名工程师，完全可以做出不少成果。

Six weeks is long enough, especially if you have you know, let's say a team has a dozen engineers, you can do a lot.

不仅如此，一天之内也能有实质进展，这就像一个定期的检查点。

And not only that, you can do a lot in a day, this is, like, kind of, like, a check-in point.

我还注意到，一旦在复盘中收到反馈，我们不会等到下一个六周再行动。

And what I've noticed too with intensity is, let's say we get a review and there's some feedback we get in that review.

我们不会等到下一个六周复盘才处理。

We don't wait till the next six week review.

对吧？

Right?

第二天，我们就开始动手改了。

Like, the next day, we are building things.

我们正在不断迭代。

We are iterating.

我们正在标记相关人员。

We are tagging people.

到了下一周，我们就清楚看到进展方向了。

And then by the next week's week, we're like, here's here's the trajectory.

对吧？

Right?

我真的想做个那种埃隆的T恤。

Like, I actually I wanna get that, Elon shirt made.

这周你具体做了些什么？

Like, what have you done this week?

是的。

Mhmm.

因为帕金森定律确实存在。

Because Parkinson's law is real.

听起来有点奇怪，但我老是提这个。

It sounds funny, but, like, we I, know, I keep bringing this up.

你给一件事分配多少时间，它就会花掉多少时间。

But whatever time you allot to something will be the time it takes.

对吧？

Right?

所以如果你在做一件大事，比如组织调整之类的，你当然可以慢慢来。

So if you're doing something monumental, like, I don't know, you're doing, like, a reorg or something, right, you can do it the slow way.

坐下来好好规划，一点一点推进，大多数公司可能得花六个月。

Let's, like, sit down and plan and roll it out over and it's probably, like, six months in most companies.

但在Shopify，一两周就搞定了。

Shopify, this is, a week or two.

你坐下来。

You sit down.

然后说，嘿。

You're like, hey.

这基本上就是它的核心框架了。

This is kind of the bones of it.

咱们多叫些人来一起想想。

Let's bring some more people and think.

等它开始有点松动了，我们就直接上线了。

Then you know it's gonna start, like, leaking, so we just, like, launch it.

对吧？

Right?

Shopify 里很多事我们都是这么做的。

And we do the same thing with lots of, things at Shopify.

我们就是想快点行动，跳出那些繁琐流程。

We just try to move more quickly and get out of the chain.

我们从不搞什么变革管理。

We don't do change management.

我们直接落地，然后跟大家说：嘿。

We kinda just, like, land it and then go, hey, everyone.

这就像一家充满变数的公司。

It's kind of like a volatile company.

事情就是这样发生的，但我们靠这种方式快速推进，然后继续过自己的日子。

This is what's happening, but this is how we get things done quickly and then move on with our lives.

真厉害。

Wow.

这里面内容太多了。

There's so much there.

我经历过那些长达六个月的组织调整，现在我试着从你刚才说的视角来看——我们是一家充满变数的公司。

I have been through through those six month reorgs, and I'm trying to like, think that context you just shared of we're at a volatile company.

我们不断调整，过程不会平稳，但我们相信这么做才是最好的。

We're changing things, it's not going to be smooth, but here's we think this is for the best.

这就是Shopify的文化。

It's just the culture of Shopify.

听起来我们就是要保持快速前进。

Sounds like we want to keep moving fast.

我们知道这不会太顺利，但现在改总比拖着好。

We know this isn't going to be the smoothest thing, but we just know this better to make the change at this point versus wait.

这正是Tobi提升公司韧性的方法。

It's how Tobi increased the resiliency in the company.

以前我们还有数据中心的时候，他经常到处走，直接拔掉机器的电源。

He would walk around in the old days when we had a data center and just unplug machines.

对吧？

Right?

就是那个所谓的混沌猴。

The, you know, chaos monkey.

是的。

Yeah.

混沌猴。

Chaos monkey.

没错。

Right.

但其实这样是管用的，因为它就是提醒你：嘿。

And then but but that but that actually works because it just says, hey.

顺便说一句，系统肯定会出问题，所以我们得能扛得住。

By the way, shit's gonna break, and so let's be resilient to that.

这儿也是同样的道理。

And so same thing here.

嘿。

Hey.

顺便说一句，有人会动你的奶酪。

By the way, someone's gonna move your cheese.

没关系。

It's fine.

我们的目标是培养更多创业者。

We are here to create more entrepreneurs in the world.

我们不是来搞六个月的变革管理计划的，那只会拖慢我们为商家创造价值的速度。

We are not here to have a six month change management road map, and that would just actually hurt the speed at which we can deliver value to merchants.

关于你刚才说的那些事情，我想聊聊。

So kind of on those on the all the things you shared.

我们每周会有一次更新。

So there's weekly updates.

每个人都会分享自己这周在做什么。

So the weekly updates are each person shares what they're working on for the week.

是这样吗？

Is that

对，就是这个意思。

the idea?

项目。

Project.

每个项目都可以有自己的更新内容。

So each project can get like, it has an update.

有时候还会附上一段视频，展示实际的使用体验。

It can it might have a video of a of here's the experience.

它会包含大量内容，明显会写清楚自上次以来有哪些变化。

It it'll have a bunch of, obviously, a bunch of writing on, like, what's changed since last time.

我们有个流程叫 OK1 和 OK2，OK1 通常是总监级别的人来确认：好吧，

We have a process called okay one and okay two, which is like okay one is typically at the director level where they're like, okay.

我认同这个方向，或者我不认同，他们可以提出调整。

This is like I'm aligned with the direction that this is going at, or I'm not aligned, and they can make changes.

等到 OK2，就是该领域的副总裁来审核，他们会说：好吧，

Then when it goes to okay too, it's typically the VP level of the area who's now looking to say, okay.

你正在做的工作是否真的符合整体架构？

What you're working on actually aligns with the overall architecture.

顺便问一下，你有没有看过这个背景资料？

But by the way, have you looked at at this context?

可能你还没看到这部分内容。

Maybe you haven't seen this.

行业里现在正在发生这些事，所以你要在这个层面上对齐。

This is happening or in the industry, So you're trying to align at that level.

然后，就像我之前说的，每六周我们都会和托比一起过一遍，他这个人本身就很较真。

And then, again, like I mentioned, every six weeks we go through with Tobi, and, like, he's an intense guy himself.

所以很多时候他都会问：

And so a lot of it is like, hey.

这事儿怎么拖了这么久？

Why is this taking so long?

我们是不是想得太复杂了？

Are we overthinking it?

是不是因为卡在什么地方，才迟迟推进不了？

Are we not trying to move forward, on this thing because we're blocked on something?

是不是基础设施那边出了问题？

Is there some piece of infra?

我给你举个具体的例子吧。

Actually, I'll give you a good example.

上次评审时，我们遇到一个挺有意思的AI问题，是用大语言模型解决的，需要特别大的输出上下文窗口。

In one of the reviews from last time, there was an interesting AI problem we were trying to solve with LLMs that required us to have a very large output context window.

现在大多数大语言模型的输出上下文窗口都很小。

And most of the LLMs today have a very small output context window.

不过在复盘的时候，我想起我们跟所有搞大模型的人有一个共享的 Slack 频道。

But in the review, right, I actually met we have shared Slack channel with all the LLM folks.

对吧？

Right?

我就在 OpenAI 的频道里发了消息。

I messaged in the OpenAI channel.

我在 Gemini 频道里发了消息，随便怎么说的。

I messaged in the Gemini channel, whatever.

结果不到一个小时，我们就把好几个主要模型的输出上下文长度给调大了，就因为我提了一嘴，这事儿就能接着往下推了。

And within an hour, I had I had we had increased the output context on, like, a a bunch of major models, and we were able to kind of move forward through the thing just because, like, I asked.

所以这就是个例子，这事儿没等到下一个六周复盘，但确实让团队紧张起来了，因为他们之前觉得被卡住了，以为必须得把数据切碎处理，还得搞什么缓存，就是因为输出上下文不够大，虽然输入上下文够大，但还得做缓存。

And so that's an exam like, it didn't it didn't take another six week review, but it increased the intensity because the team was like, oh, we were blocked because we thought we had to now chunk up this data and do this thing because we had smaller output context, and we thought we could do a big input context, but, like, we'd have to do this caching.

我当时就想，咱们直接问他们能不能给大点不就行了？

And it was like this whole thing, and I'm like, well, did we just ask them if get bigger?

然后他们说，哦，这个功能我们没开放。

And then they were like, oh, we don't have this.

这功能没写在文档里，不过我们这就给 Shopify 开通了。

This undocumented, but, like, we'll just enable it right now for Shopify.

这下团队一下子意识到，原来我们能这么快解除限制。

And so that kind of created the intensity of the team to be like, oh, we can now quickly get unblocked.

这就是一个典型的例子，说明只要快速行动，大胆提个看似傻气的问题。

So that's a kind of example of just, like, moving quick and trying to, like, just ask a again, ask a dumb question.

我当时想，这恐怕行不通。

I'm like, this is probably not possible.

但他们回来告诉我，哦，可以的。

But and then they came back and said, oh, yeah.

这个功能我们能做。

We can do that.

这真是个很好的例子。

That's a great example.

你描述 Shopify 如何营造紧迫感和效率时，挺有意思的是，你列出的其实是一堆会议和同步检查——对大多数人来说，这反而会觉得：怎么这么多会？不是应该尽量少开会吗？

And as you're describing the ways that you create intensity and velocity within Shopify, It's interesting that what like, what you're listing is a bunch of, like, meetings and check ins, which to most people would feel like, why do we need so many there's all this, like, less meetings.

我知道你们 famously 取消了所有会议，那又是另一个话题了，咱们以后再聊。

And I know you guys famously canceled all your meetings, and, that's a whole thing we can talk about.

对。

Yeah.

但有趣的是，更多的定期同步反而让你们走得更快。

But it's interesting that more check ins and regular check ins allow you to move faster.

这在一定程度上是因为，它能确保你们不会浪费时间在那些没必要、没用的事情上，不断聚焦和优化。

Imagine it's partly because it just makes sure you're not working on things that are unnecessary and dumb and not gonna be used, and it's just continue to refine.

真正重要的，其实是这些事。

These are actually the most important.

这其实是信任加验证的结合。

I mean, it's combination of, like, trust but verify.

对吧？

Right?

别忘了，定期沟通的目的不是为了抓你没干活。

Because don't forget, the goal of the check-in is not for you to be like, I caught you not doing your work.

不是那种《呆伯特》里的老板样儿。

Like, that it's not like the Dilbert boss.

喂，

Like, hey.

你那事儿干完了吗？

Did you do your thing?

对吧？

Right?

你看马斯克发消息也是这样，说：

It is like, even when I look at the Elon text, which is like, hey.

这周你完成了什么？

What did you get done this week?

他不是想抓帕拉格偷懒，或者干了一堆没用的事。

It wasn't to try to catch Parag in a you didn't do anything or you did a bunch of useless stuff.

目的是希望能一起解决这个问题。

It was hopefully to pair on the problem.

对吧？

Right?

也就是说，当我问别人，嘿，

Meaning, like, when I ask somebody, hey.

我们这个大语言模型项目有没有进展？毕竟现在上下文窗口变大了，

Like, did you you know, did we move forward on this LLM project because we now have this larger context window?

然后对方回来说，这是我们学到的东西，

And then they came back and said, oh, here's what we learned.

我就能看看他们的回复，接着说，那你们有没有考虑过这个办法？

And so then I can then look at the answer and say, oh, so now are we gonna try like, have you thought of this?

这是一种共同解决问题的方式。

Have you tried it's a way to pair on the problem.

所以这并不是那种——大家总说‘微观管理’这个词，但其实我们不觉得这是个贬义词，对吧？

So it's it's not like, you know, we we talk we we have this word, like, everybody talks about micromanagement as a word, and, like, we don't actually think it's a dirty word Shopify.

但我们不觉得这是个贬义词，因为这不只是吉尔伯特·博斯在问：‘你那件事办得怎么样了？’

But the reason we don't think it's a dirty word is because it's not just, again, Gilbert Boss saying, where did you do the thing?

而是说：嘿，

It's like, hey.

我能跟你一起解决这个问题吗？

Can I work on this problem with you?

如果我要跟你一起做这事，我就得经常了解你的进展，给你一些建议，或者你得跟我分享一些背景信息——毕竟我不是每天都在现场，等我回来的时候，才能根据我们双方掌握的情况，一起想想能不能往这个方向推进。

And if I work on this problem with you, I kinda gotta see where you are pretty often and then give you advice, or you're gonna share context with me, because I don't I'm not in the work every day, to then come back and say, oh, based on what I know and what you know, can we move this in this direction?

也许这样对商家更有帮助。

Maybe that's better for merchants.

我不太想把‘结对’这个词用得太泛，但说白了，其实就是：我能跟你结对做这事吗？

It's like it's really like I don't wanna overuse the pairing paradigm, but it is really much like, can I pair with you?

我刚加入Shopify不久就明白了这一点，因为Tobi每次跟我一对一开会，我都会说：Tobi，你没必要浪费时间。

And I learned this actually very early in my Shopify tenure because Tobi would have these one on ones with me, and I'd like, Tobi, you don't have to waste your time, man.

你雇我，就是相信我能干好。

Like, you hired me.

我明白了。

I got this.

我当时想，他是不是误会了我来这儿的目的。

I'm like, where he goes, oh, you misunderstand why you're here.

我们来这儿是为了一起解决问题。

I'm we're here to work on problems together.

我那时候觉得，他雇我是为了让我把问题都扛下来。

And I was like, oh, like, I didn't even think I didn't I thought he hired me to take problems away.

他雇我，是想和我一起解决问题。

He hired me to work on problems with me.

这跟我原先想的完全不一样。

Like, that's completely different than what I thought.

我很喜欢这一点。

I love that.

明白了。

Okay.

你提到过一个关于会议的事情。

One thing you mentioned is meeting thing.

对于还不了解你们是怎么处理会议的人，我觉得有必要简单说一下，因为你们的做法真的很棒，很多公司都能从中学习。

For peep people that don't know what you all did with meetings, I think it might be worth just sharing that very briefly because it's awesome and something a lot of companies can learn from.

是的。

Yeah.

当然。

Sure.

其实关于‘会议末日’这个事，有个挺有意思的故事：在我刚加入Shopify之前，我就跟Tobi聊过‘会议末日’的事。

Actually, the funny story about the Meeting Armageddon is that, I was messaging Tobi prior to me starting at Shopify about Meeting Armageddon.

所以我其实觉得，我在加入Shopify之前，就已经悄悄影响了他，让他开始这么做，当时我就说：

And so I actually think I had a little hand in him, like, doing this before I got to Shopify because I like, hey.

你有没有注意到Dropbox的做法？

Have you seen I think it was Dropbox.

你有没有看到Dropbox是怎么搞‘会议末日’的？

Have you seen what Dropbox is doing and Meeting Armageddon?

所以他当时说，这太有意思了。

And, and so he was like, this is super interesting.

这可是我加入公司好几年前的事了。

This is years before I started.

所以我觉得挺搞笑的，结果真就这么推行开了。

So I think it's funny that it ended up being a real thing.

但让我跟你们说说我们是怎么做的。

But here's what we do.

每年我们会随机选一个时间，把所有参与人数超过两人的定期会议全部删掉，一对一的会议不算，只删内部会议，不包括面试或外部合作伙伴的会议。

Once a year at a random time, we will delete all recurring meetings that have more than two people, so not one on ones, and are internal people only, so not interviews or external partner meetings.

然后我们会进入两周的冻结期，期间禁止创建任何新的定期会议。

And then we have a two week moratorium where you are not allowed to add a reoccurring meeting.

你可以安排一次性会议，但不能设定期重复的会议。

You can add a regular meeting, but not a reoccurring meeting.

这么做的目的是，定期会议很容易形成惯性，很难取消。

And the idea is that there's a lot of, inertia behind a recurring meeting.

它总是存在，你都知道接下来要开什么会。

It just always is there, and you know what's coming up.

想删掉还挺难的，因为你一想，哦，对啊。

And, like, it's hard to delete because you're like, oh, yeah.

我们每周都聊这个事。

We talk about this thing every week.

所以我们干脆来个会议重置，我觉得这招挺管用的。

And so what we do is we kinda just do a meeting reset, and I think yeah.

这招叫‘混沌猴子’，管理员进去一删，全都没了。

It's just called Chaos Monkey, and some you know, the admins go in and just delete everything.

有意思的是，它逼着你重新思考：

Now what's cool about it is it forces you to rethink.

我们到底需要定期开会，还是开一次就够了，或者换个频率？

Do we need a recurring meeting, or do we just need one meeting, or do we need a different cadence?

这是其中一点。

That's one thing.

另一点是，它节省了大量工程师的时间。

The other thing is it frees up so much crafter time.

对吧？

Right?

我一直在跟踪工程团队的一个数据：每个个体贡献者每周参加多少小时的会议。

Like, one of the stats I track across engineering is how many hours are individual contributors in meetings per week.

我们发现，在做了两件事之后——顺便说一句，第二件事我有个更劲爆的——

And we noticed that after we did we did two things, by way, and this is I have a spicy second one for this.

第一件事是删掉了一些会议，第二件事是把很多 Slack 对话迁移到了 Facebook Workplace，这个我待会儿细说。

But the first one was we deleted meetings, and the second thing we did was we moved a lot of our Slack into Workplace, Facebook Workplace, which I'll talk about.

我们只做了这两件事，就明显减少了工程师参加会议的时间。

Those are the only two things we did, and we saw a huge decrease in the amount of time crafters were in meetings.

之后，我们还看到了各种其他生产力的提升，因为他们有了更多连续的工作时间，可以专心做事。

And then we saw all kinds of other productivity enhancements because they were able to have that flow time and work on things.

现在，Shopify 的个体贡献者每周开会时间大概只有三个小时，这简直太棒了。

So we're at something like three hours of meetings per week for an individual contributor at Shopify, which is phenomenal.

每周只开三小时会，简直太棒了。

Three hours a week is amazing.

我觉得管理者的情况也没那么糟。

I think managers is not that bad.

我觉得我之前发过推文提到过这个。

I think it's I think I tweeted this.

我觉得大概是每周六到七个小时。

I think it's six or seven hours per week.

为了保持同步，这个时长完全没问题，剩下的时间都可以专心工作。

Like, that's not bad at all in order to get aligned, and then all the rest of the time is work time.

那在调整之前，大家每周要开多少小时会呢？

And how how many hours was it before a meeting get in and and work

我得承认，确实如此。

I have to yeah.

你问得我一时答不上来，得去查一下数据，但总之减少了大概五到六成。

You're asking me not a good I have to go look and see, but it it it came down by something like 50 or 60%.

当时普通员工每周开会大概五到六个小时，后来降到了三个小时。

Like, it was, like, something like five or six hours for individual contributors and came down to three.

至于经理们，我记得原来是十个小时左右，现在降到了六个，差不多是这样。

And then the managers, I think it was, like, ten and came down to six, something like that.

但这个降幅真的很大。

Like but it was a huge difference.

当时只有两个主要变化，我提过一个，是减少会议，另一个我也能说说。

And the only two things were, like, I mentioned were, like, one was the meeting get in, the other one was, like, this and I can talk about this.

这个是，

This is, a

对。

Yes.

我们来聊聊这个。

Let's talk about this.

好的。

Yeah.

我是真的很喜欢Slack。

So, I mean, I love Slack.

它是我最常用的工具。

It's, the I'm tool.

人人都在用，但确实容易让人分心。

Everybody uses it, but it can, for sure, cause distraction.

所以我们把所有公告信息都迁走了。

And so what we did was we moved all announcement information.

比如任何状态更新或者发给大群的通知，我们都移到了Meta Workplace——也就是企业版的Facebook，虽然现在这个平台要停用了，我们得另想办法。

So, like, anytime you're sending a status update or large group announcement, we moved all of that to, like, face Meta Workplace, like Facebook for Work, basically, which is now being deprecated, so we'll have to figure that out.

我们把这些东西都放到了一个信息流里，你可以用跟Slack完全不同的方式来浏览，因为Slack本质上是个即时通讯工具。

But it just moved all this stuff to, like, a ML feed that you can kind of consume differently than you would Slack because Slack is, like, a messaging unit.

你在Slack上看到提醒，一堆消息扑面而来；而在Workplace上，是你主动想去看看公司动态、获取更新、分享信息。

You see an alert and all this stuff versus, Workplace is like, oh, I wanna go and consume content from the company and get updates and share updates.

这样一来，分心的情况也少了很多。

And so that reduced a lot of distraction as well.

所以我特别想弄清楚，接下来我们该用什么工具，最好是那种信息像河流一样缓缓流过，我可以随时瞥一眼，而不是随时随地陷在聊天里。

And so I'd love to, you know, figure out what the next tool for us is, but it is it's probably something more like like a river of information that I can dip my toe into versus, like, I'm in chat everywhere.

这真的很有意思。

That is super interesting.

所以你们是想把那些不需要讨论的更新信息单独分出来。

So it's specifically things that are just updates where you don't need a discussion.

甚至都不希望有人在下面评论。

You almost wanna discourage discussion.

是的。

Yeah.

它其实也能评论，但跟聊天工具完全不是一回事。

I mean, it has the commenting, but it's not the same as, like, you know, it's not it's not the same tool.

顺便说一句，Slack 真的很棒。

Like, Slack by the way, Slack is amazing.

我们一直在用。

We use it.

只是这件事对我们来说不太管用，所以我们想把它移到别的地方去。

It's just that for this thing, it wasn't working for us, and so we wanted to move that somewhere else.

我越深入了解Shopify的工作方式，就越发现一些意想不到的有趣东西。

I feel like the more I dig into the Shopify way of working, the more fun stuff I never expected emerges.

我很想知道接下来还会冒出什么新花样。

I'm curious what else is gonna emerge.

我们一直在聊，你们——特别是工程团队——是怎么营造出那种高强度氛围的。

So we've been talking about ways that y'all and you specifically have created intensity, especially in the engineering org.

你们也提到过Shopify整体的情况。

And then you've also shared just broadly Shopify.

还有哪些方法在你们的清单上？

What else is on that list?

还有哪些做法能让你每小时产出更多能量？

What else have you found helps create more kilojoules per hour?

对。

Yeah.

我觉得再说一遍，真要说最有效的，那就是结对编程了，因为你坐在电脑前，根本没别的事可做。

So I think, again, I think there's nothing I would say, again, start from the beginning, there's nothing more than pair programming because, literally, you can't do anything else but be on your computer.

所以结对编程绝对是第一位的。

So, like, pair programming is the number one.

每周的节奏也特别有帮助，你提到过，这其实是GST的一部分，就是同步进展，还有六周一次的复盘。

I will say the weekly cadence helps a lot, right, which you mentioned, which, again, which is part of GST, which is sharing the updates, and then the six week reviews.

这个真的特别管用。

That that does a lot.

另一方面，我们还有很多指标和告警系统，能帮我们及时发现系统里可能出问题的苗头。

On the other side, we also have a lot of metrics and alerts that help us see when potentially things might be happening in the in the system that can allow us to be like, hey.

等等，有点不对劲。

Wait a sec.

这种类型的事情一下子太多了。

There's too many things going on of this type.

这时候我们就得停下来，重新调整，搞清楚到底出了什么问题。

We probably have to sit back and reset and figure out what's going on.

比如，我们发现 Shopify 的工程师在开发后台时，速度变得特别慢。

So one thing that happened, for example, was we we started seeing that it was taking a lot of time to develop in our admin, like engineers at Shopify developing in the admin.

于是我们就把这情况称为‘代码黄灯’，就是在‘代码红灯’之前的一个预警。

So we called that, like, what's called, like, code yellow, which is before code red.

‘代码黄灯’的意思是，嘿，得注意了。

The code yellow is this idea of, hey.

我们要给后台系统拉一个‘代码黄灯’警报。

We're gonna call a code yellow on the admin.

我们希望 Shopify 内部的开发体验一定要好。

We wanna make sure that the developer experience inside Shopify is really good.

启动项目应该很简单，

It should, you know, it should be easy to create to start up the repo.

改代码也应该很顺畅，

It should be easy to make changes.

看到改动的效果也得一目了然。

It should be easy to see the changes.

所以这类事情，我们可以通过这种代码黄牌制造紧迫感——让负责人随时拍一下任何人肩膀，说：别干别的了，来帮一把，这事儿属于基础设施层面的。

So those are the kinds of things that, again, we can create intensity because this code yellow allows the champion to tap anyone on the shoulder and say, stop what you're doing and come help this thing, which is an infrastructure layer thing.

通过搭建这套基础设施，你们就能跑得更快。

And by building out this infrastructure, it allows you to go fast.

前期搭基础设施确实花时间，但之后就永远能快起来了。

It takes longer to build the infrastructure, but it makes you go fast forever afterwards.

对吧？

Right?

我来举个具体的例子。

Actually, I'll give I'll give an example of one of these.

2020到2021年，疫情最严重的时候，加密市场又迎来了一波高潮，行情特别疯。

So we in 2020, 2021, the heyday of, like, pandemic, obviously, there was a crypto summer again, and crypto was going nuts.

我们当时就在那儿感叹，天啊。

And we were sitting back and saying, wow.

很多我们的商家都在问，能不能做NFT门禁。

A lot of our merchants are now asking for NFT gating.

还记得NFT门禁吗？

Remember NFT gating?

就是说，只要你拥有那个代币，就能进入店铺查看我的产品、价格，还能下单，但前提是得有这个代币。

Which is like, if you have the token, you can now go into the storefront and see my products, you can see my prices, and you can check out, but only if you have the token.

当时很多商家都在说，我们也想做这个。

And we were getting a lot of demand from merchants to be like, we want to do this.

他们想卖NFT，还希望买家必须持有NFT才能享受这种专属体验。

We wanna sell an NFT, and we want our our buyers to have to have the NFT to have this great experience.

我们觉得这想法不错。

And we're like, we agree.

你当然应该能做任何你想做的事，所以我们也要帮你实现这个功能。

You wanna be able to do we want you to be able do whatever you want, and, so we wanna build this for you too.

Tobi也说，你这么想就搞反了。

And same with Tobi, he's like, you are thinking about it wrong.

他问，开发NFT门禁功能要花多长时间？

Because he goes, how long would it take to build NFT gating?

我说，我不确定。

I'm like, don't know.

两三个星期吧？

Two, three weeks?

他说，那如果要搭建一个平台层，开放API，让任何人能在一小时内实现NFT门禁，你觉得要多久？

He goes, now how long would it take to build, like, a a platform layer which exposes APIs so anyone could build NFT gating in one hour?

我说，我也不知道，大概两三个月吧。

I'm like, I don't know, like, two, three months.

他说，那就去做。

He goes, do that.

他说，因为你根本没法预知别人会在这个平台上做出什么来。

He goes, because you don't know what they're going to build on top of the platform.

NFT门禁只是其中一种用途。

NFT gating is one thing, one use case.

但如果你花时间把底层基础设施搭好，他管这叫给油箱加满油。

But if you spend the time to build out the infrastructure layer, he calls it putting gas in the tank.

如果你把油加满了，以后人们就能靠着这股劲儿长时间往前跑。

If you put the gas in the tank, people could drive on that gas for a long time going forward.

所以他总说，我希望你一直想清楚，关键在于，你能做出什么东西，让别人一小时就能搭出来？

And so he goes, I always want you to think about and yet the key part was, what can you build so anyone could build this in one hour?

对吧？

Right?

他老对我们这么干，一开口就说‘这事儿应该很简单’，结果大家都理解错了。

So, like, he does this thing to us all the time where he goes, oh, this should only be he'll say it, and people get the wrong thing.

他会说，这东西一天就能写完。

He'll say, oh, you could write this in a day.

但他真正的意思是，得有什么前提条件，才能让你一天内写完？

And what he means is, what has to be true so that you could write this in a day?

你需要什么样的基础设施？

What infrastructure do you need?

他确实是这么做事的。

And he actually develops this way.

他总是会先写代码，调用一个根本还不存在的API。

He will always, like he will write code against an API that doesn't exist.

因为他会想，这里明明应该有个这样的东西才对。

Because he's like, you know what should exist here?

这个API就该存在。

This API.

他先把代码写出来。

He'll write the code.

然后来回调整客户端和服务器端，最后说：对，这才是正确的客户端代码。

He'll go back and forth and refine the client and the server, and then he'll go, this is correct, the correct client code.

现在，我来实现服务器端。

Now let me go implement the server code.

这种做法听起来好像更慢，因为要花两三个月，而不是两三个星期。

And, like, this is notion of, like, building things as infrastructure that sounds slower today because it's gonna take it's two, three months instead of two, three weeks.

但之后，别人基于这个基础开发的东西，反而变得特别简单。

But after that, the things that people built on top, right, were so easy to build.

出现了更多我们之前没想到的情况。

There were so many more scenarios that were emerged.

这是一种完全不同的软件思维模式，它以另一种方式释放了这种专注力。

It's just a different way of thinking about software, and, it really, again, allows it's intensity in a different way.

这种专注体现在搭建基础设施上，虽然我们想快点完成，但这次花了两三个月，之后却能让所有人更快地基于我们的平台开发。

It's intensity around building this infrastructure layer, which we wanna build quickly, but takes two or three months in this case, but then can get everyone building on top of our infra in a much, much quicker way.

当然，谁知道接下来会冒出什么精彩的东西呢？

And, of course, you know, who knows what can flourish from there?

这挺有意思的，也说得通，你们的思维方式更多是打造最好的平台，而不是只为某个人做最直接的解决方案。

It's interesting, and it makes sense that so much of the way you all think is about building the best possible platform versus the necessarily best possible, like, point solution for someone.

这也解释了为什么你们花这么多时间打磨代码、结对编程——因为你们是在为别人搭建一个开发平台。

And it also explains why you spend so much time in crafting really great code and pair programming because, again, it's a platform for other people to build stuff on.

所以我觉得，这套思路对平台型公司特别有参考价值。

So I think it'll a lot of this is very useful, especially for platform businesses.

不对。

No.

没错。

Exactly.

实际上，你这么一说，我想起一个数据。

And, actually, you're making me think of a of a of a stat.

去年我发过一条推文，虽然有点跑题，但我说过，GitHub Copilot 为 Shopify 写了超过一百万行代码。

So last year, I tweeted out, you know, maybe a tangent, but I tweeted out that GitHub Copilot has written over 1,000,000 lines of code for Shopify.

人们都说：天哪。

And people are like, oh my god.

这条推文被广泛转发，大家都在讨论。

And it got, like, picked up, and everyone's talking about it.

但我真不明白大家为什么这么激动，我更想看到的是 GitHub Copilot 删除一百万行代码。

And I go, I don't know why everybody's getting so crazy because what I wanna see is GitHub Copilot deleting 1,000,000 lines of code.

那才是真的说明它已经接近一个工程师的水平了。

Like, that's when you know we're actually at this point where this is close to an engineer.

对吧？

Right?

今年我们大规模删掉了数百万行代码，因为我们想专注于避免沉没成本，重新打造更优雅的系统，有些东西根本没必要保留了。

And so we famously have, deleted millions of lines of code this year because we're trying to focus on the, again, the sunk cost and, like, rebuilding things elegantly or you don't need this anymore in rebuilding.

我之前还发过一条推文，有人提到Shopify是全球前十大的Ruby代码库之一。

And I even tweeted out, I think, someone said, oh, Shopify, is in the top 10 Ruby code bases in the world.

我说，我真不希望再看到Shopify出现在这种榜单上。

And I said, I never wanna see on this on this list again.

我们不该追求排第一，而应该争取连前十都进不了。

Like, it's not it's not like we shouldn't be gunning for number one, and we should be gunning for number 100.

对吧？

Right?

我们希望的是根本不在这种榜单上。

Like, we wanna be not on this list.

对吧？

Right?

让别人去拿这个头衔吧。

Someone else can take the crown.

本期节目由Vanta赞助播出。

This episode is brought to you by Vanta.

要确保公司拥有顶尖的安全实践，事情很快就会变得复杂。

When it comes to ensuring your company has top notch security practices, things get complicated fast.

现在，通过Vanta这一平台，你可以评估风险、赢得客户信任，并自动化完成SOC 2、ISO 27001、HIPAA等合规要求。

Now you can assess risk, secure the trust of your customers, and automate compliance for SOC two, ISO 27,001, HIPAA, and more with a single platform, Vanta.

Vanta作为行业领先的信任管理平台，能持续监控合规状态，同时追踪风险并生成报告。

Vanta's market leading trust management platform helps you continuously monitor compliance alongside reporting and tracking risk.

此外，使用Vanta填写安全问卷还能帮你节省大量时间。

Plus, you can save hours by completing security questionnaires with vanta.ai.

成千上万的全球企业都在使用Vanta，自动化收集证据、统一管理风险、简化安全审查流程。

Join thousands of global companies that use Vanta to automate evidence collection, unify risk management, and streamline security reviews.

访问vantacom/lenny，即可享受1000美元优惠。

Get $1,000 off Vanta when you go to vantacom/lenny.

网址是vanta.com/lenny。

That's vanta.com/lenny.

等一下。

Wait.

再详细说说这个。

Talk about more about this.

现在有一种趋势，就是要删代码、做简化。

So there's been a drive to delete code and simplify.

那背后的原因是什么？

What's kind of that what's what's behind that?

这到底是怎么回事？

What's going on there?

是的。

Yeah.

有好几个原因。

So there's a few things.

对吧？

Right?