我要是公司领导，我只想把 LZ 拖出去打屁屁

这个和 review 的工具也有关系。

比如你用原装的 github 来 code review，方法二会非常的令人费解。
如果你用 Gerrit，phabricator 这样的工具，方法二也是可以拆的比较清楚的。

@sjmcefc2 账单太贵，其实有时候也是一个好事，是一个量变到质变的一个指标。

上 snowflake 后，其实让数据查询和运算变得特别的“亲民”，因为 snowflake 处理掉了大量的底层的运算和存储。之前这些数据都是公司内部工程师和数据科学家才懂得如何获取和处理（需要获取大量权限，确保查询要经过优化），现在变成业务人员、分析师，大家经过一定的学习之后都会自己处理一些简单的需求。

一些 BI 软件，链接 snowflake 这样的云上数仓之后，也变得特别的易用，谁都可以整两个漂亮的 dashboard 支持一下自己组的业务需求。一些数据管道需求，配合 dbt 这类的工具，我见过很多偏业务的分析师都能写出相当可用的管道代码。所以每个业务组都会开始做自己的数据产品，来支持自己的业务运营。

所以，公司内部其实对数据的依赖和使用率更高了，激发了大家创造力，副作用是会造成账单比你之前估计的要高很多。
但怎么平衡这个成本和收益，也是仁者见仁智者见智。我个人觉得公司变得更加“数据驱动”是很好的，多付的这点计算费用还是划得来的，公司的运营效率，方向感更强了，带来的好处远胜于这些成本。

可以，简单易用，账单感人。

@ishowman 公司在加州不一定注册在加州，很多公司都注册在 delaware 州。
https://icis.corp.delaware.gov/ecorp/entitysearch/NameSearch.aspx

> 一个 RPC 请求回来的数据是啥得分析半年
这个应该不是 c++的问题，服务提供方得提供接口说明（例如 protobuf 文件）

> 改一行代码编译要几分钟，一大堆依赖
你可能需要 TDD，用测试搞定一些局部功能先

> GDB 还没空学怎么用
这个应该先学一下，否则真是两眼一抹黑，靠 print debug 太痛苦

@typetraits 所以大家需要的是虚拟机服务（可能带 GPU ）多一点，不需要 sagemaker 这种全流程管理服务？

> 公司用的是自有集群

自有集群一般是什么样的呢？

新一点的项目建议直接搞容器把

感觉最重要的能力和代码其实关键都不大，比较泛泛，放之四海皆准

1. 学习的能力
2. 分析问题和解决问题的能力
3. 沟通和与人协作的能力

1G 的文档大概 8 千万个中文字，7G 的文档大约有 5 亿 6 千万字。LZ 的这个文档大概水平相当于《永乐大典》。。一部宏伟的码农巨著。。

建议走 tsv + 份文件 + 压缩的路线吧。
excel 虽然很牛。。但也不是万能的。

codespace 很方便，代码如果全部托管在 github 上面的话没有比这个更方便的开发模式。github 内部的工程团队开发环境也已经迁移到 codespace 上了。
https://github.blog/2021-08-11-githubs-engineering-team-moved-codespaces/

什么是专门给开发者使用的搜索引擎？

google site:stackoverflow.com ?

人工智能在专业领域落地，难的不是人工智能，难的是专业领域。

感觉 linux 娱乐还是差一些。但是干活是真的迅猛，基本不会碰到搞不定什么工具和软件的时候。
如果单纯想要干活，强烈推荐各种平铺窗口管理器，这个是把这个优点放大到极致的工具。

这不是孵化器的原型么，参考 plug and play 的发家史

1. 口音基本不重要
2. 尽量用简单的表达。沟通复杂的内容，尽量拆解成几个点逐步沟通。
3. 语速可以适当放慢一些
4. 别人说完之后可以简单复述一遍，确认没听错
5. 自己讲完了之后，留一些空白给比人提问题或者复述一遍

面试讲究的沟通而不是英语。英语只要有个大学四级水平基本就可以做没问题的沟通了。

为啥需要框架？ grpc + k8s 就可以起飞了。需要 tracing 熔断 metrics 这类就上个 istio 或者 linkerd 。业务和运维的代码高度解耦化，写起来很清楚的。

建议先对代码 review，分支合并先有一套规范再说。直接往 master 上面推代码怎么看都不是个好事儿