第477集：才四个月，我就已经讨厌我的工作，变得暴躁又迷糊

要成为一名优秀的工程师，光靠在自己的错位Slack消息下回复线程是远远不够的。这里是《软技能工程》第四百七十七期。我是主持人戴夫·史密斯。我是主持人贾米森·丹斯。《软技能工程》是一档每周建议播客，面向那些花费约一半时间寻找丢失的Slack消息，另一半时间等待生成式AI替他们写代码的软件开发者。

It takes more than replying thread to your own misplaced Slack messages to be a great engineer. This is Soft Skills Engineering episode four seventy seven. I'm your host, Dave Smith. I'm your host, Jamison Dance. Soft Skills Engineering is a weekly advice podcast for software developers who spend about half their time trying to find lost Slack messages and the other half of their time waiting for generative AI to write the

代码。这个开场让我很困惑。你回复线程是因为想以后能更容易找到它吗？

code for them. I'm befuddled by this intro. Are you replying thread because you want to be able to find it later?

我认为你回复线程是为了让它重新出现在同事的通知列表顶部。

I think you're replying thread to bump it back up on your coworker's notification list.

还是因为你试图羞辱别人，说'嘿，你们应该用线程回复这条消息'，但实际上这是你自己的消息？所以这像是一种被动攻击式的呼吁使用线程？是的。

Or is it because you are trying to shame people to say, hey, you should be threading this message, but actually it's your own message. So it's like a passive aggressive call to use threads? Yeah.

那应该是'线程感叹号'。

That would be thread exclamation mark.

我们的Slack里有个表情符号就是干这个的。

We have an emoji for that in our Slack.

是线程表情符号吗？

Is it is it the thread emoji?

不。是一个小小的袜子木偶小人。哦。它是由线做的吗？不是。

No. It's a little little sock puppet guy. Oh. And is he, like, made of thread? No.

它不是。我也不知道为什么。它上面写着'使用线程'的小提示，但我不明白为什么偏偏是这个角色。

He is not. I don't know why. He he says use threads in the little Oh. Oh. Sweet trouble above him, but I don't know why this particular character is the one.

我不知道。这不是重点。戴夫，我该感谢我们的赞助者吗？来吧。好的。

I don't know. That's not what this is about. Dave, should I thank our patrons? Let's do it. K.

感谢这些朋友将他们的Patreon名字改成了某些内容，可能让Patreon的工作人员相当困惑。是的。

Thank you to these folks who changed their Patreon name to something, probably pretty befuddling to the folks that work at Patreon. Yeah.

我很希望有一天能收到Patreon工作人员的邮件，他们会问，你都干了些什么？是的。每次我们给赞助人发邮件时，问候语里都会出现最奇怪的内容。

I would love to get an email from the Patreon people one day and be like, what have you done? Yeah. Every time we send an email to our patrons, it says, the weirdest things in the in the greeting.

是的，是的。我们怎么把这些分成名和姓呢？没错。看吧，让我们统一称花括号为卷曲括号吧，尽管它们其实挺卷曲而不是那么扭动。

Yeah. Yeah. How do we how do we tokenize these into first and last name? Exactly. Behold, let's normalize calling curly braces, squiggly braces, even though they're pretty curly and not so squiggly.

我是一个没有AI的永无止境的故事指针网站。今天早上醒来。给自己找了个嘎巴鬼。马蒂亚斯，我在LinkedIn上的真实名字是亚米，在黑暗中调试糖果，移动开发协调员。名字中的第一位，引号，或者一个等于一个删除表喵喵混粮。

I'm a never ending storypointer.com without AI. Woke up this morning. Got myself a Gabba ghoul. Matthias, my actual name on LinkedIn is Yami, debugging in the dark candy, the mobile development ordinator. First of his name, quote, or one equals one drop table Meow Mix.

雅各布·钱德林。比约恩，你的办公桌传来一股特别的味道。请创建一个尖峰来调查。一个缺失的分号。克里斯蒂，世界还好的程序员诺亚·拉巴特。

Jacob Chandling. Bjorn, there's a very particular smell coming from your desk. Please create a spike to investigate. A missing semicolon. Christy, the world's okay as programmer Noah Labhart.

怎么了，软煎锅国度？是你们的男孩J和D在这里分享一些超酷的智慧。超酷。丹尼尔·雷姆斯伯格。尼克·莫利纽。

What's up, soft skillet nation? It's your boys, J and D here to drop some dope wisdom. Dope. Daniel Remsberg. Nick Molyneux.

如果服务组织使用了一个控制次表层器官所必需的次表层器官，那就假装它不是。哈维尔·冈萨雷斯，切维，泰德·廷布雷尔，西蒙公主，糖果手杖，棒棒糖，鸡，咯咯，咯咯，砰，砰，还有狗，蓝莓派苹果酱蛇输入长度验证器一个单独的开括号。哦，我很感激这个。

If the service org uses a subsurface organ that controls at the subsurface organ necessary, pretend it's not. Javier Gonzales, Chewy, Ted Timbrell, Princess Simon, Candy Cane, Lollipop, Chicken, Bock, Bock, Pop, Pop, and Dog, Blueberry Pie Applesauce Snakes Input Length Validator A single open parenthesis. Oh, I appreciate that.

我认为那是事实

I think that's a fact

在过去。现在，现在这个，现在这个赞助人列表实际上是一个Lisp语言。来自DroneDeploy的丹。蔡斯·w·诺顿。Never不仅仅是火星上的一个陨石坑火烈鸟表情符号。

in the past. Now now this is a now this is this list of patrons is actually a lisp. Dan from DroneDeploy. Chase w Norton. Never is not just a crater on Mars flamingo emoji.

我喜欢鸡肉。我喜欢肝脏和Miamix miamix。请送达。垃圾熊猫瑞士Python峰会十月举行。你多久获取一次？

I like chicken. I like liver and Miamix miamix. Please deliver. Trash panda Swiss python summit in October. How often do you fetch?

这花了一段时间。Kyle Voss、Kent C. Dodds、那边那位、Jenny Kim、随机鹦鹉。Quentin，我们已经一个月没听到你的消息了。请尽快去人力资源部找Susan。

This took a while. Kyle Voss, Kent C. Dodds, that guy over there, Jenny Kim, the stochastic parrot. Quentin, we have not heard from you in a month. Please go see Susan in HR ASAP.

Jonathan Kings，近乎完美的功能性用户文档。你知道吗？我们现在有了AIONA，挺不错的。开发者不应该成为业务创造者吗？本集由HOR赞助，你的消息剩余部分被截断了。

Jonathan Kings, nigh beautiful functional user documentation. You know what? We got AIONA now like good one. Shouldn't developers become business creators? This episode is sponsored by HOR, and the rest of your message got cut off.

DroneDeploy的Dan。有人告诉Will Angel如何为www.vibechart.net设置HTTPS重定向。Ragnar、Braden Canes、John Grant、Brittany Ellich、Ben和Jill、卷心菜娃娃、温布尔登、网球比赛。谢谢。谢谢你，Juan。

Dan from DroneDeploy. Someone tell Will Angel how to get the HTTPS redirect working for www.vibechart.net. Ragnar, Braden Canes, John Grant, Brittany Ellich, Ben and Jill, Cabbage Patch, Wimbledon, Tennis Match. Thank you. Thank you, Juan.

感谢大家支持节目，并愿意公开——我本来想说羞辱自己，但我不认为这是羞辱。公开站出来作为，是的，在Patreon用户列表中拥有独特名字的人。

Thank you all for supporting the show and for being willing to publicly I was gonna say humiliate yourself, but I don't think this is humiliating. Publicly stand out as Yeah. Someone with a unique name, on the Patreon user list.

实际上很显著的是，几乎所有人，大约85%的这些人都真的改了他们的Patreon个人资料名称。是的。我不知道哪个更昂贵，就实际成本而言。是你每月支付的费用，还是通过将个人资料名称改成这个奇怪东西所带来的奇怪社交资本损失。

And it's actually remarkable how almost everyone, like, 85% of these people have literally changed their Patreon profile name. Yeah. I don't know what's more expensive, like, in terms of actual cost. The the fee you pay every month or the the weird social capital loss by changing your profile name to

这个奇怪的东西。我很想知道这些人是否也是其他事物的赞助人，以及那里发生了什么。

this weird thing. I would love to know if these people are patrons of other things as well and kinda what's going on there.

如果其他一些，比如，其他Patreon项目也这样做，那会很有趣，有时我们看到一些对我们来说没有意义的名字，你知道，因为，我不知道，它属于某个小众垂直领域。是的。也许这已经发生了，只是我们没有意识到。

It'd be funny if some other, like, some other Patreon thing does this, and sometimes we see names that don't make sense to us, you know, because it's like, I don't know, it's in some niche vertical. Yeah. Maybe that's already happened and we didn't realize.

我不会感到惊讶。我没有意识到很多事情。如果你想加入这个群体，可以去softskills.audio，点击“在Patreon上支持我们”，任何金额都可以让你获得我们Slack团队的邀请，并且，我想，用YouTube的术语来说，这让你成为软技能国度的一员。金额足够的话，我们还会每周特别鸣谢你，并致以我们永恒的感激。

I would not be surprised. I don't realize a lot of things. If you wanna join this group, you can go to softskills.audio, click support us on Patreon, where any amount will get you an invite to our Slack team and any, I guess it makes you a member of the soft skillet nation to use the YouTube verbiage. And enough, we'll get you a weekly shout out and our eternal gratitude.

我们实际上收到了一些听众相当严厉的——这里的“严厉”要打引号——指责，因为我们没有在上期节目中像我们承诺的那样称呼他们为软技能国度。

We actually got some, pretty harsh callouts, harsh in air quotes here, from, some listeners for not addressing them as soft skillet nation in our last episode, like

我们承诺过的。哦，是的。是超过一个人，还是同一个人多次提出？

we promised. Oh, yeah. Was it more than one person or was it the same person multiple times?

我不知道。

I don't know.

无论如何，有多条反馈意见亟待处理。民众呼吁被称为'软煎锅国度'。

Either way, there were multiple pieces of feedback clamoring to be addressed. The people cry out to be called soft skillet nation.

是的。

Yes.

我们是人民公仆。所以你要这么做吗？向软煎锅国度致敬。

We are men of the people. So so you're gonna do it? Shout out to soft skillet nation.

没错。不过这得作为结束语了，对吧？就像，这将成为收尾的口号。

Yep. That'll have to be the closing, though. Right? Like, that'll be the closing tagline.

好吧。好的，戴夫。你想读我们的第一个问题吗？

Alright. Okay, Dave. Do wanna read our first question?

我来读。这来自一位自称'右括号'的朋友，这很美妙因为我们之前有个'左括号'

I will. This comes from someone who calls themselves closed parenthesis, which is beautiful because we had an open parenthesis

是的。这样就完整了。

Yeah. It completes it.

在Patreon上。所以现在Lisp表达式已经闭合了。好的，这是来自括号先生或女士

In the Patreon. So now the lisp yes. The lisp s expression has been closed. Alright, so this is from Mr. Or Mrs.

的提问，说道：嘿伙计们，我工作四个月已经不喜欢这份工作了。这是我大学毕业后的第一份工作，在一家小型B2B SaaS公司担任C#后端工程师。我真的觉得这家公司没有前途。存在大量技术债务和反模式，而且我们完全没有自动化测试。大部分时间都花在手动调试上，但没人愿意重构。

Parenthesis, who says, hey, guys, I have been working for four months at my job, and I already don't like it. This is my first job out of college, and I work as a C sharp back end engineer for a small B2B SaaS company. I really think this company is a dead end. There is a lot of technical debt and anti patterns, and we have no automated testing whatsoever. Most of our time is spent manually debugging, but no one wants to refactor.

我已经在考虑换工作了。不过，我花了很长时间才找到这份工作，而且我觉得市场情况并没有好转。我正在纠结是该重新专注于投简历，还是应该做一些副业和开源项目来提升自己的竞争力。一方面，我可以自学新技术为下一份工作增加筹码；但另一方面，我觉得只要继续待在这家公司就是在浪费时间，因为从工作中根本学不到东西。反正我最终想转做Java分布式后端工程，只是不知道该如何着手。

I'm already thinking about working somewhere else. However, it took me a while to get this job and I don't think the market has gotten any better since. I'm trying to decide whether I should focus on applying to jobs again, or if I should work on a bunch of side projects and open source to stand out better. On the one hand, I can learn new technologies on my own to make me stand out for my next job, but on the other hand, I feel like as long as I stay at this company I am wasting time since I am not learning from my job. I want to switch to more distributed back end engineering in Java anyways, but I'm not sure how to go about it.

我想质疑你'在工作中学不到东西'这个前提。你正在大量学习如何进行手动调试——这很有价值。你正在学习如何在难以维护的代码库中工作。作为大学毕业后的第一份工作，你正在亲身体验技术债务和反模式。

I want to challenge the premise here that you're not learning anything at your job. You're learning a lot about how to do manual debugging. It's valuable. You're learning a lot about how to work in a code base that is difficult. And first job out of college, technical debt and anti patterns.

我也要质疑这个假设。你根本不知道普通商业代码库是什么样子——没有自动化测试。我的意思是...这听起来确实很糟糕。我还没在完全没有自动化测试的地方工作过。

I'm also going to challenge that assumption. You do not know what the average professional code base is like. No automated testing. I mean, that's yeah, that's that sounds rough. I don't know that I've worked somewhere with literally no automated testing.

但这可能就是中等水平的代码库。对吧？你觉得它很可怕，可能只是因为你还没在其他地方工作过。

But this might be the median code base. Right. And you think it's horrible because you haven't worked somewhere yet, I guess.

如果我告诉你所有代码库都很糟糕呢？

What if I told you that all code bases are horrible?

没错。每个能赚钱的代码库在某种程度上都是噩梦。是的。如果你觉得它不是噩梦，那它可能还没赚到多少钱。确实如此。

Yeah. Every code base that makes money is a nightmare in some way. Yeah. And if you don't think it's a nightmare, it probably hasn't made very much money yet. Yes.

或者也许你就是那个写代码的人。

Or maybe you're the one who wrote it.

我想可能已经很多年没说过那句关于烂代码的名言了，也许现在应该再说一次。你觉得时机合适吗，詹姆森？

I think it might have been enough years that I've haven't said this little quote about bad code that maybe I should bust it out again. You think the time is right, Jameson?

当然。虽然不知道具体是什么名言，但我支持你的所有想法。这简直是有史以来最棒的空白支票。没错。好的。

Yeah. I don't know what the quote is, but I approve of all your ideas. That's like the best blank check of all time. Yeah. Okay.

这句名言是这样的——或者说是代码名言，算是代码和名言的混合体。这是个代码名言，一句名言：世界上有两种公司，一种为自己的代码感到羞愧，另一种则走向失败。

So the quote goes like this or the quote, the quote, that was a mix of code and quote. It's a code quote, a quote. There's two kinds of companies, those that are embarrassed of their code and those that fail.

你是说那些花大量时间打磨代码库、追求完美代码的公司，很可能因为发布速度不够快而无法成功。是这个意思吗？这确实是其中一种可能导致失败的情况。

You're saying that the company that spends so much time on their code base that it's it's beautiful, it's probably not gonna make it because they haven't shipped quickly enough. Is that sort of it? That is for sure one avenue to

通往失败的一种途径，但成功也需要做出权衡和快速做出糟糕的决策。那些长期来看不利、但能让你生存下去的决策。

get to failure, but but also success demands trade offs and rapid bad decisions. Decisions that are bad in the long term that that make you survive.

是的，每个代码库在某种程度上都是路径依赖的。如果我按字面理解Close（假设这是第一个名字），嘿，Close，最近怎么样？也许这是个糟糕的代码库。

Yeah, every codebase is path dependent in some way. If I take close at their word, that's the first name I assume. Close. Hey, Hey, what's up close? Maybe this is a bad codebase.

是的。而且人们不愿意重构。实际上，通常是不愿意掏钱的人不想重构。

Yeah. And people don't want to refactor. I mean, actually not wanting to refactor. It can be usually people that write the checks don't want to refactor.

是的。但是

Yeah. But

假设它确实很糟糕。当你在技术产物或技术实践较差的地方工作时，你能做些什么来学习和提升作为开发者的能力？我觉得你仍然可以做些事情来变得更好，这会给你带来经验，而答案并不总是跳槽到一个更好的代码库。或者，如果你需要一段时间才能跳槽，你仍然可以从工作中受益，不仅是因为能继续维持生计，还因为你能获得对未来有帮助的经验。

say it's actually bad. What can you do to learn and improve as a developer while you are working in somewhere with poor technical artifacts and or poor technical practices. I feel like there's still stuff you can do to get better and that will give you experience and the answer isn't just jump to a better code base all the time. Or, or if it takes you a while to jump ship, you can still benefit from having a job, not just because you get to keep paying for life, but because you you get to obtain experience that will help you in the future.

是的。至少，它能帮助你理解...不知道，也许我想说的词是校准。它会为你的校准数据集增加一个数据点，帮助你判断事物在某个地方是更好还是更差。

Yeah. At the very least, to help you understand where the where kind of the don't know, maybe the word I'm looking for is calibration. It'll give you one more data point on your calibration dataset, which will help you understand whether things are better or worse at a

未来的地方。我有个简单的建议。很好，但不一定容易做到。如果你负责会怎样？

future place. Here's an easy thing for me to suggest. Nice. Not easy to do, necessarily. What if you were in charge?

如果你是CTO或工程副总裁，或者是CEO的表亲，不管怎样，不管谁有技术决策的最终决定权。你对当前状态有自己的评估。你会怎么做？这可能是个有趣的思维实验。开发者们常常会说，我们需要停止所有开发来修复这个问题，因为它太乱了。

What if you were the CTO or VP of engineering or whatever the CEO's cousin, however, however they decide, whoever has the final say of technical decisions. You have your evaluation of the current state. What would you do about it? And this can be a fun thought experiment. Often developers will say like, well, we need to stop all development and fix this because it's such a mess.

我们需要投入资源解决根本的技术问题，然后才能重新为公司构建东西。

We're not going be able to we need to we need to invest so that we solve the underlying technical problems, then we will be able to go back to building stuff for the company.

而且

And

如果那是你的答案，那是个糟糕的答案。那不能是你的答案，因为那是不可能的。如果你负责公司，你有客户需求，你有营收目标要达成，公司必须生存下去。是的。而且我相信如果你说我们除了可能破坏它之外什么都不做。

if that's your answer, that's a bad answer. That cannot be your answer because that is that is impossible. If you are in charge of the company, you have customer demands, you have revenue targets to meet like the company has to stay alive. Yes. And I believe that if you say we just won't do anything except maybe break it.

对。最好的情况是客户在几个月内看不到任何额外的好处。对。最坏的情况可能是某些功能会停止工作。对。

Right. At the very the very best case is the customer will see no additional benefit for some period of months. Right. And the worst case is maybe stuff will stop working that. Right.

而且100%的非平凡重构都会涉及某种程度的破坏。

And that's 100% of reef of nontrivial refactors involve some kind of breakage.

是的。那不是个可行的解决方案。

Yeah. That's not a tenable solution.

特别是像这样没有任何自动化测试的重构。

Especially especially refactors that were like this one that don't have any automated testing whatsoever.

是的，我想说的是那不能是你的答案，但我觉得如果你退一步思考：如果我完全负责这个问题，我会学到宝贵的东西。我会怎么做？我如何以仍然为业务提供价值的方式改进情况，并正确平衡——说'正确'很难，因为我认为很难经验证明这就是正确答案。但我如何为业务和技术制定一个合理、可辩护的答案和计划来改善这种情况？是否存在某种权衡？

Yeah, I guess I'm saying that can't be your answer, but I think you will learn valuable things if you step back and say, what if I own this whole problem? What would I do about it? How would I improve things in a way that still provides some value to the business and correctly balances or correct is hard because I I think it's I think it's tough to empirically prove, like, this is the right answer. But how would I have a justifiable, reasonable answer and plan for for the business and the technology that that improves this situation? Is there some trade off?

关于这个话题还有另一个很好的思维练习：找出代码库中最繁琐、最糟糕、充满反模式的代码，然后假设性地思考完全重构它

There's another great thought exercise on this subject, which is take the most onerous, terrible, anti pattern filled code in your codebase, and then just walk yourself through the hypothetical of what it

会是什么感觉，把代码推回Git，部署到生产环境并让它正常工作。我得告诉你，感觉并不像你想象的那么好。根据我的经验，拥有干净重构代码的想法比实际拥有干净重构代码感觉好得多。

would feel like to completely refactor that, to push that code back up to Git, deploy it to production and have it work. I gotta tell you, it doesn't feel as great as you might think. What I have found is that the idea of having clean refactored code feels a lot better than actually having clean refactored code, in my experience.

对我来说，这完全取决于我因重构而获得多少赞扬和认可。如果这是每个人都讨厌的代码，然后我把它变成大家不那么讨厌的代码。

For me, it depends purely on how much praise and modulation I receive in response for refactoring it. If it's this code that everybody hates, and then I make it code everybody hates less.

比如，我们得感谢Jamieson带来了这个。

Like, we can thank Jamieson for this.

是啊。感谢你跋涉过火与焰，现在又以另一种方式让它变得令人困惑。是的。至少现在我对新的困惑类型感到惊讶了。没错。

Yeah. Thank you for trudging through fire and flame and making it confusing in a different way now. Yeah. Now I'm at least surprised by the new kinds of confusion. Yeah.

现在它很新颖。是的。我的意思是，这确实。我想根本点在于，我认为这是一个你可以从中学习的问题。代码很糟糕。

Now it's novel. Yeah. I mean, this is yeah. This I guess the underlying point is I think this is a problem you can learn from. Code is bad.

在这里工作很难。好吧，该怎么办？你如何交付东西并改进事物？从技术上讲，同时，这是每个级别工程师都需要的长青技能。

It's hard to work here. Okay, what do do about it? How do you ship stuff and improve things? Technically, at the same time, that's a that's an evergreen skill for every level of engineers.

绝对是。我看着这个问题，我想，好吧，这个人有他们讨厌的代码。好吧，我理解。但我实际上认为这里可能有一个更大的问题，那就是我认为这家公司本身就是一个死胡同。这真的会吸走你做任何其他事情可能带来的乐趣。

Totally is. I look at this question, and I think, okay, this person has code they hate. Okay, I get it. But I actually think there might be a bigger problem here, which is I think this company itself is a dead end. And that really sucks the joy out of anything else you could do.

即使你成功地重构了所有这些代码，让它变得美丽而奇妙，不再有反模式，并且你有一堆自动化测试，那么如果公司还是失败了呢？感觉并不好。所以这很难克服。

Even if you do successfully refactor all this code and make it all beautiful and wonderful, and no more anti patterns, and you have a bunch of automated testing, then what if the company fails anyway? Doesn't feel great. So that's hard to overcome.

说得好。我应该缓和一下我的建议，我的意思并不是说你就应该全身心投入，把生命奉献给这家公司。我想我有点假设你会继续前进。但就像你说的，现在市场很艰难。在你寻找其他事情做的时候，你该如何度过你的时间？

That's a good point. And I should temper my advice by saying, I don't think it means you should just go all in and dedicate your life to this company. I think I'm kind of just assuming that you'll move on. But like you said, the market is tough right now. How do you spend your time while you're looking for something else to do?

是啊。副业项目和开源，那没问题。但我认为你不太可能仅仅在业余时间做出一个足够出色的副业项目来直接帮你找到工作。我觉得我看到的大多数副业项目都比较浅薄，而且我认为一个糟糕的副业项目可能更糟，因为它破坏了神秘感。是的。

Yeah. Side projects and open source, that's fine. I think it's probably unlikely you'll make a side project that's just awesome enough in your free time to just get you a job. I feel like most side projects I see are pretty shallow, and I think a bad side project can be worse because it destroys the mystery. Yeah.

如果没有，如果什么都没有，我还可以抱有这种想法：也许他们有很好的品味，能做出优秀的东西，只是还没时间。而当我看到它时，我想，不，不。

Where if there's no, if there's nothing, I can entertain this idea that, maybe they have great taste and could build excellent stuff, and they just haven't had time. And when I see it, I think, no, no.

这就像那句名言，宁愿闭嘴让人以为你是傻瓜，也不要开口让人消除所有疑虑。是的。我能不能说，我其实对这个故事很有共鸣，因为我大学毕业后的第一份工作也是一家死胡同公司？我花了一点时间才感觉到，或者说意识到这一点，可能比这个人时间还长，因为我在那里待了大约十八个月。但我记得当时在做这个。

That's like that's like that famous quote, it's better to keep your mouth shut and be thought an idiot than to open your mouth and remove all doubt. Yeah. Can I just say that I I actually resonate a lot with this story because my first job out of college was also a dead end company? And it took me a little while to feel it, or to realize it maybe even longer than this person because I stayed there for about eighteen months. But I remember working on this.

那真是个非常奇怪的软件项目。不知道我之前在节目里有没有提过。当时我们在用Java开发一个叫移动代理的概念。我说移动的时候，你可能会想，对，就像智能手机那种移动，但不对，不是今天大家熟知的移动应用。而是指能够把自己打包起来，迁移到另一台电脑上运行一段时间，然后再打包迁移到另一台电脑继续运行的移动代理。

It was a really weird software project. I don't know if I've ever mentioned this on the show before. We were working in Java on this concept called mobile agents. And when I say mobile, you might be thinking, yeah, like smartphone mobile, like no, not mobile apps that you know them today. Mobile agents that are able to package themselves up and move to another computer and then run on that computer for a while, and then package themselves up and move to another computer and run on that computer.

这就像是个很有趣的学术概念，但完全没有实际价值或应用场景。

This is a like really fun academic idea that has no real world value or application.

是啊，听起来像是某个系主任写了一堆相关论文的东西。

Yeah, this sounds like somebody's a chair of a department somewhere that has written a bunch of papers about it.

百分之百就是这样。这概念源自学术界，然后这家公司不知怎么搞到了一笔政府资助来研究这个，想要做出某种奇怪的、勉强可行的产品卖给政府。真是太糟糕了，完全是在浪费生命，愚蠢至极。

It is 100% what this was. It came out of academia, and this company somehow procured a bunch of government funding to work on this and make some kind of weird viable semi viable product that the government would then buy from us. And it was terrible. It was a huge waste of time. It was so dumb.

说实话，对我来说再没有什么比这更让人泄气的了。

And there is honestly to me nothing more demoralizing.

什么结局？抱歉，我刚刚走神在想移动代理的事。这到底是要解决什么问题？

What an end? Sorry. I'm just distracted by thinking about the mobile agents thing. Like, what what is the problem that solves?

问得好。它解决的问题是：我银行账户里钱不够，而政府正好有补助金可以打进我的账户。我相信这就是移动代理的主要应用场景。也许就像是...

Yes. The problem that solves is my bank account didn't have enough money in it, and the government had grants available that would put money in my bank account. I believe that was the main application for mobile agents. Maybe it's like

某种持久化执行类型？我也不懂。我还是闭嘴保持神秘感，假装自己很聪明吧。

a durable execution type of I don't know. I'm gonna stop. I will I will shut my mouth and preserve mystery that I'm smart.

我花了一年时间苦苦思索，一直相信公司高层知道自己在做什么，做出了明智选择。最后我跑去网上论坛问：这玩意儿到底有什么用？结果遇到了一些最初构思这个想法并实现初步方案的人——顺便说下，这是IBM开源的项目叫Aglet（a-g-l-e-t），IBM Aglet。你现在去谷歌应该还能查到。

I spent a year wondering, like, just trusting that the people above me in this company knew what they were doing and had chosen wisely. And finally, I went and found like some online group and I'm like, what is the point of this? And it was some of the people who had originally, like, conceived of this idea and built the initial implementation, which by the by the way, was an open source project out of IBM called the Aglet project, a g l e t, IBM Aglet. I wonder if that you could probably Google that and see.

我现在就要去查这个，不听你说了。

That's what I'm gonna do now instead of listening to you.

总之，论坛上有个人说，我问过，为什么除了我在做的这个奇怪项目外，其他地方都见不到移动代理？那家伙的回答是，我们还没找到移动代理的杀手级应用。结果二十二年过去了，我们依然没找到。所以这很让人沮丧。而且我得告诉你，我在那家公司做什么都不重要，因为我知道那是一条死路。

Anyway, so one of the people on forum was like, I said, how come I don't see mobile agents anywhere except this weird project I'm working on? And this guy's response was, we just haven't yet found the killer app for mobile agents. Well, it's twenty two years later and we still haven't found it. So it was demoralizing. And I gotta tell you, it didn't matter, like nothing I did mattered at that company because I knew that it was a dead end.

我也明白，我的意思是，我职业生涯的前六个月热情满满地投入这项工作。我们还去了联邦政府的一个客户站点，向他们展示了这些东西。他们的反应就是，好吧，挺酷的。然后就没下文了。

And I also knew that, I mean, I worked on this enthusiastically for the first six months of my profession. And we went and took it to a customer site in the federal government. And we presented these things to them. And they were like, okay, cool. And that was that.

就像完全没有应用场景，完全被搁置了。这对我打击很大，因为我意识到自己投入了那么多心血去写代码、完成所有这些我觉得很酷的事情，结果却完全没用。所以我辞掉了那份工作。我先找到了新工作，然后才辞职的。

There's like no application, it was completely shelved. And that was devastating to me, because I realized that I had put all this love and care into writing the code and accomplishing all this cool stuff, or that I thought was cool. And it was just totally useless. So I quit that job. I first found a new job, then I quit it.

我就是受不了。而且说实话，我当时反应太慢太笨了，至少又做了一个项目，可能两个，结果都一样。第一个是移动代理，第二个是某种没人会用的愚蠢生物识别技术，就是把第三方供应商的东西拼凑起来，还有其他一些东西。最后我就想，我到底在干什么？

I just could not handle it. And actually, was so slow and dumb at the time that it took me at least one more project, maybe two more projects with the same outcome. The first one was mobile agents. The second one was some dumb biometric thing that no one was ever gonna use, where we just cobbled together third party vendors, and then some other thing. And finally, I'm like, what am I doing?

就像，这简直是在浪费我的时间。于是我去找了一家新公司，在那里我的工作真的被人们实际使用，用来完成非常酷的事情。这让我有成就感一百倍，动力也强多了，我简直爱死它了。

Like, this is such a waste of my time. And I went and found a company to work for where my work was actually getting productively used by people to accomplish really cool things. And it was 100 times more gratifying. And I was so much more motivated. And I just absolutely loved it.

所以我觉得，没有比待在一家你觉得是死路的公司更糟的事了。我建议你尽快离开。副业嘛，随便搞搞。你可以同时做清单上的所有事：开始面试、做副业、干什么都行，但我建议还是离开。

So think there's nothing worse than being part of a company that you think is a dead end. And I would say get out as soon as you can. Side projects, fine, whatever. Like you can do everything on this list. You can start interviewing, you can do side projects, you can do whatever, all these things at the same time, but I would recommend getting out.

人生苦短，不该把时间花在对世界毫无意义的事情上。

It's just life's too short to work on things that don't make any difference in the world.

谢谢你的好建议。

Thank you for giving good advice.

现在去谷歌搜索IBM Aglets吧。

And now to Google IBM Aglets.

不用了，太迟了。我已经搜了。正在看移动代理的页面呢。不错。总之，这太棒了。

No, too late. Already did. I'm on the mobile agents page right now. Nice. Anyways, this is great.

有一些鼓舞人心的名言，尤其是安迪·赫兹菲尔德的，我认为他在苹果时代是个大人物。Telescript的美妙之处在于，现在我们不再只是拥有一台可编程的设备，而是拥有了整个云端，一个程序可以前往许多不同的信息源，创建一种虚拟服务。然后下一句是：然而，这家公司并不成功。

There's some inspiring quotes, especially by Andy Hertzfeld, who I think was a big deal in Apple days. It's this the beauty of Telescript is that now instead of having just a device to program, we now have the entire cloud out there where a single program can go and travel to many different sources of information and create a sort of virtual service. And then the next sentence is, the company was unsuccessful, however.

因为事实证明，你不需要让代码去数据所在的地方。你可以直接通过网络请求数据。

Because it turns out you don't need the code to go to the place where the data is. You can just ask for the data over the network.

事实证明，这样简单多了。

That's a lot easier, it turns out.

你能想象一个运行时环境，用于处理所有的信任问题吗？有所有这些证书之类的东西，代码必须经过签名才能传输，证明它来自可信的商店。我的意思是，这基本上就像是在说，我要创建一个运行时环境，让地球上的任何病毒都可以来我的电脑上运行。是啊，是啊，不行。

Can you imagine like a runtime environment for all your I mean, trust issues, there was all these certificate things that you like, the code had to be signed before it could be shipped over and you show that it was from a trusted store. I mean, it's basically like saying, I'm gonna create a runtime environment where any virus on earth can come and run on my computer. Yeah. Yeah, no.

好吧，我被说服了。不要研究移动代理。我相信这就是问题的答案。

Well, I'm convinced. Don't work on mobile agents. I believe that was the question.

是的，我想这就是我们来这里要回答的问题。不行。

Yeah, I think that's what we came here to answer. No.

我……我要再尝试一次为我最初的建议辩护，我假设你会在那里困上一段时间。我的建议是，趁你还能的时候，充分利用它。即使是一条死胡同，你仍然可以学到有价值的东西。在某种程度上，这让你可以更自由地进行一些实验。你能做什么呢？

I'm I'm gonna make one more attempt to justify my original advice, which is I'm assuming you're kinda stuck there for a while. And I guess my advice is, like, make the most of it while you can. You can still learn valuable stuff even if it's a dead end. In some ways, it frees you to experiment a little bit more. What are you going to do?

让公司不成功？

Make the company not successful?

好消息是，无论你认为那家公司有多死胡同，它都不可能像我第一年的公司那样是个巨大的死胡同。所以我说，很可能……

Good news. No matter how much of a dead end you think that company is, there's no way it was as big of a dead end as my company in my first year. So I'd say there's probably a good chance

你可以在这里学到很多东西，并做一些很酷的事情。你比戴夫强多了。是的，完全正确。完全正确。这就是总结。

you can learn a lot here and do some cool stuff. You're better off than Dave. Yeah, totally. Totally. That's the summary.

好的。我们回答完这个问题了吗？

Alright. Have we answered the question?

我觉得是的。祝你好运。

I think so. Good luck.

祝你好运。戴夫，你想读我们的下一个问题吗？

Good luck. Dave, do you want to read our next question?

我可以读，但我觉得我会

I could, but I feel like I would

剥夺你的机会。哦，等等。你说得对。这是我。我来读吧。

be taking the opportunity away from you. Oh, wait. You're right. This is me. I will do it.

好的。这是一位名叫加尼的听众提出的问题，他问：我是一名中级软件工程师，当任务、故事或项目的信息不明确或缺失时，我很难与我的工程经理和产品经理沟通。他们回答时带有敌意或轻蔑的语气，或者给出非答案。例如，说信息在Jira卡片或Epic上等等。然后当他们后来获得信息时再进行修正。

Okay. This is from a listener named Ghani, who asks, I'm a mid level software engineer who has trouble communicating with my engineering manager and product manager when there's unclear or missing information about an assignment or story or project. They answer with hostile or dismissive tones or a non answer. For example, it's on the Jira card or the Epic, etc. Then they course correct when they have the information later.

而且态度很严厉。我的印象是他们当时并没有这些信息。他们期望工程师做出决定。他们期望工程师知道一些他们不知道的事情。例如，架构、基础设施、过去的决策、计划等等。

Harshly. My impressions were they don't have the information at the time. They expect engineers to make a decision. They expect engineers to know something they don't. For example, architecture, infrastructure, past decisions, plans, etcetera.

我真的很想找到一个能够安全交流信息的地方。我该怎么做？

I really want to look for where we can have a safe exchange of information. How can I do this?

哦，非常有趣。天啊，我很想听听产品经理那边的说法。

Oh, very interesting. Boy, I would love to hear the other side of this story from the product manager.

哦，天啊。我觉得我经常这样做。可能没有那么敌意，但我很容易自以为知道这里的背景。而且我肯定已经把所有的信息都写在这个工单里了。然后我看看工单，上面写着：做会议中提到的事情。

Oh, man. I I think I do this all the time. Maybe not as hostile, but it's so easy for me to think I know the context here. And surely I've written it all down in this ticket. And then I look at the ticket and it's like, do the thing from the meeting.

我就是。

I'm Exactly.

所有内容就这些了，这就是你写的全部。

All of the That's everything you wrote.

这是工单里唯一的文本。

It's the only text in the ticket.

你是在说你自己是个糟糕的产品经理吗，贾米森？

Are you are you saying you're a terrible product manager, Jamieson?

有可能。有时候我确实挺糟糕的。

I can be. I can be a pretty bad one at times.

你有这个能力？

You're capable of it?

是的。我能堕落到相当低的程度。

Yep. I can stoop to some low depths.

这个故事，让我深有共鸣。就像，这就是工程师的困境。经常被给予你觉得根本不足以实际构建东西的需求或规格说明。

This story, it resonates with me on a deep level. Like, this is the plight of the engineer. Being given requirements or a specification that is that you feel is just insufficient to actually build the thing happens all the time.

我觉得‘不足’可能有几种情况。一种情况是，某人或某个群体知道，信息是存在的。只是没有正确、有效地沟通，或者没有集中在一个地方。也许，也许确实有一份详细完整的规格说明，但你必须自己去找，或者去和某人沟通，而信息只在他们脑子里等等。这是一种情况。

I feel like there's a couple ways it could be insufficient. One of the ways is someone someone knows or some group of people, the information is out there. It's just not communicated correctly or effectively or in a single place. Maybe, maybe there is a spec and the spec is detailed and complete and you have to go find it or, or go talk to somebody about it and it's in their head or whatever. That's one case.

信息是存在的，只是没有为你集中呈现在工单里。另一种情况我认为更可怕，那就是信息 literally 不存在，当你问‘如果这个失败了会怎样’时，这是负责思考这个问题的人第一次想到，哦，这个可能会失败。是的。哦，糟了。

The information is there. It's not there for you in the ticket together. The other case is I think scarier, which is it's literally not there where you ask questions about what happens when this fails, and it's the first time the person responsible for thinking about this has ever thought, oh, this can fail. Yeah. Oh, shoot.

确实如此。

Exactly.

比如说，如果你在这里想要用大写字母显示用户的名字，但我们40%的用户在这个字段里根本没有填写名字，或者其他类似的情况。这时候我们该怎么办？我把这些问题称为边缘情况，或者我觉得产品经理会认为很多这类问题都是边缘情况，但工程师很难区分哪些是我可以自行决定的边缘情况，哪些是实际上如此核心以至于需要设计到产品中的情况。我发现这是一个棘手的平衡点——产品经理希望尽可能少处理这类问题，而工程师却只关注这些。你也不会希望产品经理处理每一个可能的边缘情况，因为首先，他们通常并不知道所有可能的情况。

Like, what happens if you said here you wanna display the user's first name with an uppercase letter, but 40% of our users don't have first names in the field, you know, whatever, something like that. It's like, now what do we do? And I call these things edge cases, or I think product managers would consider a lot of these things edge cases, but engineers have a really hard time distinguishing between what's an edge case that I can decide on, and what's a case that's actually so core that it really needs to be designed into the product. And that is a tricky balance I found where product managers want to do as little of that as possible, and engineers only think about that. And you wouldn't want your product manager to do like every possible edge case because A, they just don't know what they all are usually.

其次，那纯粹是浪费他们的时间。他们还有很多更高价值的事情要做。所以我不知道该怎么定位这个问题，但我确实曾经是那个工程师，总是问：'嘿，这个情况怎么办？'

And B, that would just be a waste of their time. They've got a lot of other things to do that's higher value. So I don't know. I don't know where to put this one, but I've definitely been that engineer who's like, hey. What about this?

'你怎么没考虑到这个？'然后产品经理就会显得很沮丧，你知道吗？有时候我觉得那种沮丧是针对我的。是的。

How come you haven't thought about this? And the product manager's like, like, frustrated, you know, and I sometimes perceive that that frustration is pointed at me. Yeah.

你就不能想办法让它正常工作吗？

Can't you just can't you just make it work?

是啊，没错。而我们工程师就喜欢琢磨这些。我们特别喜欢深入细节，比如：'哦，这个边缘情况怎么办？那个边缘情况呢？'

Yeah. Exactly. And we engineers, we love this stuff. Like, we love getting into the little details in the weeds about, oh, what about this edge case? Oh, what about that edge case?

'哦，我可以写个单子来解决这个边缘情况'，诸如此类的事情。而产品经理通常不太喜欢这样。

Oh, I could write a monad to resolve this edge case, you know, it's things like that. And and product managers usually don't don't love it.

是的，部分原因可能是当边缘情况导致系统崩溃时，我们会被叫起来处理。这里面有些责任归属——如果某个用户确实没有名字，然后代码崩溃了，我就会被呼叫。我认为，部分吸引人们从事软件工程的原因是对确定性事物的渴望，或者对'正确'（大写C的正确）的追求。想要构建正确的系统，处理现实世界中的所有情况，而现实世界是非常混乱的。

Yeah, part of it is we're probably going to get woken up when the edge case breaks the system. There's some ownership there of of it's kind of on my head if someone turns out to not have a first name and then yeah, the code crashes and then I get paged. Some of it is, I think, part of what attracts people to software engineering is this desire for deterministic things or things that are correct with a capital C. Want to build systems that are correct. They handle all the cases in the real world, and the real world is very messy.

它会不断抛出你未曾想到的边缘情况。是的。但能够感觉自己构建了如此健壮的东西，它不仅能够工作，而且不可能不工作，这种成就感是很令人满足的。是的，确实如此。

It will continue to throw more edge cases at you that you have not thought of. Yeah. But it can be gratifying to feel like I have built something so robust that not only does it work, it cannot not work. Yeah. Exactly.

确实如此。而且我已经严格证明了它。是的，看看我的类型系统。看看那依赖类型的斜塔之类的。

Exactly. And I've proven it rigorously. Yeah, behold my type system. Behold the the leaning tower of, of dependent types or whatever.

我认为关于如何推进这件事，有一系列的选择。这些选择从简单到不可能都有。其中一个几乎不可能的选择——抱歉，是近乎不可能——就是试图说服产品经理，他们需要扩大产品中需要明确关注的范围，比如预先考虑到工程师可能会反馈的情况。这需要时间和培训。坦率地说，很多产品经理对此并不那么感兴趣，也不愿意深入。

I think there are a range, there's a range of options for how to proceed with this. And some of these options are gonna be, they're gonna range from easy to impossible. And one of the impossible options is maybe, sorry, bordering on impossible, is trying to convince a product manager that they need to widen the scope of concerns that they need to specify in the product, such as what happens if when an engineer comes back with that, like pre anticipate that stuff. And that's something that just takes time and training. And frankly, not a lot of product managers are all that interested and willing to go into it.

但作为工程师，你可以对产品经理施加一点专业压力，比如说：'很抱歉，在我看来这个功能定义不足，因为有以下六个问题。现在，你是希望我来明确这些并实现它们，还是你想亲自参与？'

But as an engineer, you can apply a little bit of professional pressure to your product managers by saying things like, I'm sorry, it feels to me like this feature is under specified because of the following six things. Now, you like me to specify these and implement them? Or would you like to have a hand in it?

这取决于你的产品思维有多好，可能是一种威胁，也可能是一种帮助的提议。

Depending on how good of a product mind you have, that could be a threat or an offer to help. Do

你想

you want to

看看我对良好错误处理的想法是什么吗？

see what I what my idea of good error handling is?

哦，我记得我有一个长期的朋友兼同事，他会半开玩笑地威胁产品经理来构建那样的东西。他的威胁是：'听着，如果你让我设计这个UI，我就会像命令行参数一样从左到右排列小部件，一个接一个。当碰到屏幕右边缘时，我就换到下一行。所以别把这个交给我。'

Oh, I remember I have a I have a longtime friend and coworker who would kind of jokingly threaten product managers to build things like that. And his threat was, look, if you let me design this UI, I'm just gonna lay out the widgets like command line arguments, just left to right, one after the other. And when I hit the right edge of the screen, I'm gonna wrap them to the next line. So don't leave this to me.

他可能不知道，在CSS技术中实现这一点我们花了很长时间。他当时说的其实是网页设计师梦寐以求的功能。

Little did he know that technology was beyond us in CSS for quite a while. He was cutting that would have been that was the dream of web designers for You

你能做到那样？

can do that?

按行排列东西。哦，天哪。我多么希望能做到啊。

To lay stuff out in rows. Oh, my goodness. What I wouldn't give.

而且还能自动换行？

And it word wraps?

哦。要包装？要滚动？你能滚动吗？

Oh. To wrap? To scroll? You can scroll?

什么？这家伙说他不是前端开发，但哇哦。

What? This guy says he's not a front end developer, but wow.

从这段关于架构、基础设施、过往决策、计划等内容来看，让我觉得无论是工程经理还是产品经理，他们脑子里都有一堆知识没有清晰传达出来，而且他们和我们一样，都很难准确判断听众已经知道什么、不知道什么。这是一项很难的技能。

I think from this architecture, infrastructure, past decisions, plans, etc, piece makes me think that either the engineering manager or product manager, they have a bunch of knowledge floating around in their head that isn't clearly communicated, and they have a hard time, like we all do, I guess, understanding what the audience already knows and what they don't. This is a hard skill.

哪部分算是难技能，James？

Which part is the hard skill, James?

难技能在于——我觉得这里涉及很多难点。其中之一就是足够了解你的受众，写出包含他们不知道的内容，同时省略他们已经知道的内容。

The hard skill is, I guess there's lots of hard skills in here. One of the hard skills is knowing your audience well enough to write things that include the stuff they don't know and don't include the stuff they already do know.

是的，这样就不会给假设或错误叙事留下填补的空间。

Yeah, it doesn't leave room for assumptions or false narratives being filled in.

没错，我觉得另一个难点是告诉你的工程经理：嘿，你需要多沟通，并促使他们改变，增加沟通。而你说的“难”，是指这属于

Yeah, and I guess the other hard skill is telling your engineering manager, Hey, you need to communicate more, and making them change so that they communicate more. And by hard, you mean this is

一项难的软技能，对吧？

a hard, soft skill. Right?

是的。一项困难的技能。完全符合这个节目和我们的专业领域，所以我才对该怎么办有如此精彩的答案。

Yes. A difficult skill. Squarely in the vein of the show and our expertise, which is why I have such a great answer for what to do.

是什么？哦，不。我……我看向那边了。

Which is? Oh, no. I I look over there.

一个干扰。看啊。一个干扰。

A distraction. Look. A distraction.

看啊。哇。你见过这么让人分心的东西吗？太让人分心了。

Look. Wow. Have you ever seen such a distraction? It's so distracting.

让我想想。我在思考人们是如何帮助我意识到自己表达不清的。我觉得他们就是直接说出来。他们会说，嘿，如果一开始就知道所有这些信息，会很有帮助，能节省我们的时间。

Let's see. I'm trying to think of how people have helped me recognize when I'm being unclear in this way. I think they've just said it. They've just said, Hey, it would have helped. It would have saved us time if we knew all this stuff up front.

这一点让我非常在意，因为我非常敏感——我指的是对帮助团队提速很敏感。当我无意中拖慢了团队进度时，我会感到非常难受。这有时甚至克服了我对开会的反感，或者对重复陈述事情的抵触。因为，这能帮助项目更快推进。如果他们不了解这些前提假设，就会走错路，反而花费更长时间。

That one got my attention a lot because I'm very sensitive. I like to think of sensitive to trying to help the team go faster and areas where I've inadvertently slowed them down feel just painful to me. This has overcome my distaste for meetings at times or, or kind of restating things or whatever. It's just, this will help it go faster. It'll take longer because they'll go down wrong paths if they don't have these assumptions.

所以，我觉得你可以这样去沟通。如果你拿到这些任务单，并且觉得背后有某种整体计划或架构，你可能想问你的工程经理：嘿，你能给我们讲讲整个计划吗？我们不会一次性实现所有内容，但这能帮助我理解如何处理这些具体任务，让我有一个挂靠这些信息的背景框架。

So, I think you could pitch it that way. If you're getting these tickets and you think there's some underlying plan or architecture, you might want to ask your engineering manager, Hey, can you just go over the whole plan with us? We're not going to implement it all at once, but it'll help me know what to do about these specific tickets. It'll help me have some context to hang this information off of.

还有一件事我喜欢做，也喜欢看到团队成员这样做，就是当产品经理带来一个需求说明不足的产品时——顺便说一句，这种情况100%会发生。因为一个完全明确的产品规格其实就等同于代码已经写完摆在那里了。你知道，代码本身就是最完整的产品规格说明。

There is something else that I like to do that I like to see team members do when product managers come with an under specified product, which, by the way, is a 100% of the time. Because a fully specified product would actually be all the code is written and here it is. You know, that the code is the the complete product spec.

就像一堆堆的文档手册。是的，我觉得你可能并不希望在一个所有东西都被完全明确规定好的环境中工作，因为有时候能灵活完成任务是件好事。

It's like binders and binders of documentation. Yeah, I think you probably don't want to work in a world where everything is fully specified because it's nice to be able to get stuff done sometimes.

没错。当我在一家科技巨头公司工作时，其中一个最受重视、最重要且会获得财务奖励的核心工程素质，就是处理模糊性的能力。在晋升标准中，它是排名第一的能力：作为一名工程师，你能处理多大程度的模糊性。你能处理的模糊性越多，我们付你的薪水就越高。所以，这里有一件事你可以做，来展现强大的主人翁意识、应用出色的专业精神，并且我认为能以最少的延迟推动项目前进。

That's right. And when I worked at a mega tech co, one of the core, like the most sought after and important engineering attributes that was rewarded financially was the ability to deal with ambiguity. It was a number one competency on the promotion chart was how much ambiguity are you able to deal with as an engineer. And the more ambiguity you can deal with, the more we're gonna pay you. And so here's one thing you can do to demonstrate strong ownership, apply really good professionalism, and I think move projects forward with the least amount of delays.

那就是当你收到一个需求说明不足的产品时，不要回去找产品经理说：看看你这些没做好的地方，我们现在来谈谈这个。相反，你应该带着你自己关于这些东西应该如何运行的提案回去，并附上理解它们所需的背景信息。举个例子，回到那个例子，比如：嘿，你这里说想显示用户的首字母大写的名字，但我们40%的数据库记录没有名字。

And that is when you receive an underspecified product. Instead of coming back to the product manager and saying, here's all the places where you have failed to do your job. Let's talk about that now. Instead, you come back with your own proposals for how you think these things should behave along with the context necessary to understand them. So for example, like, let's go back to that example, like, hey, you've said here you wanna display the user's first name with capital first letter, but 40% of our database records don't have a first name.

我提议我们显示一个通用问候语来代替。比如，不说“Hello, D”（代表Dave），我就只说“Hello!”，就这样。然后就把这个作为一个具体的解决方案提出来，告诉他们如何处理这种情况。然后把你列表上最重要的事项一个一个这样处理，并带给产品经理。这会产生两个非常积极的效果。

I propose we show a generic greeting instead. Like instead of saying hello comma space capital D for Dave, I would just say, hello exclamation mark, and that's it. And then just put that out there as a concrete proposal for how to deal with the situation. And they go one by one through the most important things on your list, and bring those to the product manager. And this will have two very positive effects.

第一，这能让产品经理简洁地表示同意（如果他们喜欢），或者选择讨论。第二，我发现当你提出具体方案时，能促使更优质的讨论以达成解决方案。而如果你只是提出问题，团队就容易陷入原地打转——‘这里有个想法’‘那里有个想法’。但提出具体答案，比如一个稻草人方案，确实有助于推动问题得出结论。

Number one, it will allow the product manager the brevity to just say yes, if they like it, or the option to discuss. And number two, what I have found is that when you show up with a concrete proposal, it prompts much better discussion to get to a solution. Whereas if you just show up with a proposal, or sorry, not a proposal, if you show up just with a problem, then the group will just kinda go around in circles. Well, here's an idea and here's an idea. But there's something about bringing a concrete answer, like a straw man that helps a question get to conclusion.

这样做不仅能大幅缩短时间，还能避免产品经理可能产生的误解，认为你在指责他们工作不力。

And so if you do that, I think you can you can really shortcut a lot of this time, and you can also sidestep the potential perception from this product manager that you are accusing them of being bad at their job.

没错。这会把抱怨转变为团队共同面对的问题——就像大家围成一圈看着它问：我们该怎么解决？

Yeah. It moves it from a complaint to a a a problem that you're all kinda standing around a circle looking at. Like, what do we do about this?

正是。而且圆圈中央的不只是产品经理一个人。

Exactly. And that thing in the middle of the circle is not just the product manager.

对。这不是在说‘嘿，你搞砸了，你没给我足够信息’，对吧。

Yeah. It's not it's not, hey. You you you messed up. You did not tell me enough. Right.

我很喜欢这个思路。但技术问题可能更难实施，因为存在更多‘未知的未知’——可能有个巨大的抽象层必须使用，或者光看规格说明无法意识到缺失的技术细节。

Hey, you. I love that idea. It feels like it might be a little bit harder for the technical things because I feel like those might be a bit more unknown unknowns where maybe there's some giant abstraction over here that you're supposed to use or or you can't look at the spec and know the pieces of the technical stuff you're missing.

确实如此。但有些讨论根本不需要展开，只需告知：‘需要说明的是，基于当前产品设计，实现所需工作量是...’ 这其实是工程师与产品经理互动中最重要的一环——沟通产品设计选择带来的工作量。我听过太多次产品经理说：‘早知道这个功能要开发这么久，我根本不会提这个需求’。

Yeah. That that's totally true. But and some of those discussions you don't even need to have other than to say, hey, just so you know, the way this product is designed, the effort levels are going and this this is, by the way, this is one of the most important things engineers can do when interacting with product managers is communicate effort levels that come with product design choices. Like I can't tell you how many times I've heard a product manager say, if I had known this feature was gonna take this long to build, I would not have asked for this feature.

是的。现实中很少遇到那种独裁者说‘要么按我的愿景做，要么就毁掉公司，宁可让公司倒闭也不愿把下拉菜单左移一像素’。

Yeah. Yeah. I think it it is pretty rare that there are just these monomaniacal dictators saying, like, my vision or or nothing. I will I would rather kill this company than move this dropdown one pixel to the left.

一像素都不行。

Not one pixel further.

对。我喜欢这种协作方式，提出稻草人方案（也可能是好方案），关键是要先有方案。关于信息缺失的问题——我在想，他们可能期望工程师掌握某些未知知识，比如不了解构建所需的抽象层，或者不知道某些技术方案的存在。

Yeah. I like the idea of being collaborative about it, bringing straw man ideas, or they could be good ideas too, but just having an idea is is the first part of it. Unclear missing information. I'm just trying to think about they expect engineers to know something they don't. Maybe maybe that means the engineer doesn't know the abstractions required to build a thing or doesn't know that that thing exists.

我不知道。

I don't know.

这是有可能发生的。

It can happen.

是的。我的意思是，熟悉代码库的过程就是这样。如果问题频繁出现，你可以把答案写下来。我觉得这是个好做法。让它变得比你接手时更好。

Yeah. I mean, that's part of coming up to speed on a codebase. If they're frequent questions, you can write the answers down. I think that's a good thing to do. Make it leave it leave it better than you found it.

如果你向经理提问却得到不友善的回应，那感觉确实很糟。完全同意。严厉、粗鲁的态度。这绝对不是我想工作的环境。

It does feel bad if you ask your manager a question and they respond unkindly. Totally. Harshly. Rudely. That is not an environment I would love to work in.

也许你选择不多，只能在这里工作。但我认为，与不理解他人知识边界的人共事，和与对提问不友善的人共事是有区别的。因为你不可能刚加入公司就完全掌握代码库，不向更懂的人请教。那样成本太高了。我讨厌那种压力：我不知道需要了解什么才能完成工作，但如果我问这个人，他们会生气冲我吼叫，或在Slack上发个皱眉表情之类的。

Maybe you don't have a lot of choice, and this is just where you have to work. But I think there's a difference between working with people that don't understand what other people know and don't know, and working with people that are unkind to questions. Because you can't you can't just join a company and learn a code base and not ask people that know more than you about it. Like that's, it feels so expensive. And I would, I would hate that pressure of, I don't know what I need to know to build this, but if I ask this person, they're going to get mad at me and yell at me or type a frowny face in Slack or whatever.

嗯。

Mhmm.

我们上周也讨论过这个问题，关于如何与初级开发者共事，你提到了批量提问。或许有些方法可以更轻松地收集信息，但核心在于对方必须愿意分享。也许他们不耐烦是因为觉得你掌握得不够快？也许还有其他原因。也许他们对你的技术能力感到失望之类的。

We we talked about this last week too, about how do you work with juniors, and you mentioned batching up the questions. Maybe there's some stuff around there about how do you how do you gather the information in maybe an easier way, but at the core of it, they have to be willing to share it with you. Maybe they're impatient because they feel like you haven't picked it up fast enough? Maybe there's something else going on there. Maybe they're frustrated with your technical expertise or something like that.

是的，有可能。而且你知道，确实存在这种现象：工程师刚接触代码库的新领域时，并不清楚自己不知道什么，结果花了大量时间走错路，这些时间本应用来快速上手。然后你回来说还没完成，他们却说：拜托工程师，这是你的本职工作，你就这一个任务。

Yeah, it could be. And, you know, there is certainly this phenomenon where engineers don't know what they don't know when they jump into a new area of a code base, and they end up taking time that is really just ramp up time by going down the wrong paths. And then you come back and you're like, I'm still not done. And they're like, oh, come on, engineer, you're supposed to be this is supposed to be your job. You had one job.

把产品做出来。

Build the product.

是的。但有时候这就是学习的代价。确实如此。你必须付出代价来建立对程序运作方式的理解，直到能够...

Yeah. But that's also just the cost of learning stuff sometimes. It is. You have to pay the price of developing your theory of how the program works enough to be able

要修改它，否则你根本无法实现。任何有超过五分钟经验的产品经理都已经经历过这种情况数百次了，工程师们会说：哦，我们原以为这个简单可行，但结果发现这里有个我们没意识到的依赖项。现在我们必须更新服务器上的Java版本，因为需要这样做才能实现那个功能，而这将额外花费一个冲刺周期或类似的时间。你知道，这种情况随时都在发生。所以显然，作为工程师我们不应该这样做。我们不想这样。

to modify it, or you just won't be able to. Any software product manager who's been around for more than five minutes has already experienced this, like, hundreds of times where the engineers are like, oh, we thought this was doable and easy, but it turns out there's a dependency here we didn't realize. And now we have to update the version of Java on this server because we had to do this to get that whatever thing, and that's gonna take an extra sprint or whatever, know, this happens all the time. So obviously, don't try to do that as engineers. We don't want to do that.

但有经验的产品经理应该理解这一点。是的。不过他们不是来这里回应这个的。哦，他们来了。我把他们

But product managers who have been around, they should understand that. Yeah. Not that they're here to respond to that. Oh, they're here. I've got them

就关在我的衣柜里。一群产品经理。他们现在非常生气。他们感到很不舒服，既因为被塞在衣柜里的方式，也因为我们给出的所有关于他们的糟糕建议。

right here in my closet. A of product managers. They're so mad right now. They're quite uncomfortable, both because of the way they're crammed in the closet and all the horrible bad advice we've given about them.

他们好像在说：我不知道哪个更难受，是我的身体疼痛还是对你们建议的心理挫折？两者都很糟糕。

They're like, I don't know where what's more uncomfortable, My physical pain or my psychological frustration with your advice? They're both really bad.

听起来我的工作完成了。Dave，我们回答完这个问题了吗？

Sounds like my work here is done. Dave, have we have we answered this question?

我想是的。祝你好运。告诉我们进展如何。

I think so. Good luck. Let us know how it goes.

是的。祝你好运。如果人们想得到自己问题的解答，该怎么做？

Yeah. Good luck. What can people do if they want their own questions answered?

访问softskills.audio，或者填写我们的表格。感谢所有认真填写表格的人。超过40%的人填写了名字，这很棒。我们也喜欢那些编造的名字。虽然我们提供了匿名选项，但说实话，我宁愿你们用假名而不是完全匿名提交。

Go over to softskills.audio, or you can fill out our form. And, thank you to everyone who fills out that form so dutifully. More than 40% of you put in your first name, which is great. And we love the made up names too. So it's almost like we give you an option to say you're anonymous, but quite frankly, I'd much rather you be a fake name than an anonymous submission.

所以感谢大家所做的一切。我们真的很喜欢。我们喜欢阅读你们的问题，这让我们感觉就像在你们糟糕的工作岗位上与你们同在，与你们一起受苦，而没有其他地方我更愿意待了。

So thank you for all that. Really love it. We love reading your questions, and it just makes us feel like we're right there with you at your terrible job, suffering aside you, and it's there's nowhere else I'd rather be.

并在你糟糕的工作中受苦。

And suffering at your terrible job.

是的。

Yes.

没错。我也不想待在别处，只想陪戴夫干他那糟糕的工作。

Yeah. I too would not like to be anywhere else than beside Dave at his terrible job.

好了，詹姆森。你要给我们签字确认吗？

Alright, Jameson. You gonna give us our our sign off here?

哦，好的。我是不是该说我知道他们怎么开场？

Oh, yeah. Do I just say I know how they do the intro.

嗯，我不知道。

Yeah. I don't know.

我不知道。这是...这是你的哥们儿，J和D，软技能国度，到此结束。

I don't know. It's it's it's your boys, J and D, Soft Skill Nation signing off.

好吧。还有一点点改进空间，但我们会做到的。

Alright. Little little room for improvement, but we'll get there.

下次我会做得更好。我保证。好了。谢谢大家。再见。

I will do better next time. I promise. Alright. Thanks. See y'all.