在我厂，如果代码格式化不标准，build 都没法 build。
我们写了一大堆 Code Rules 放在预编译阶段去检查代码规范。

提问真的需要技巧，这一点楼上已经说了很多了。

我想说的是一个新人刚进一家公司慢慢的成长节奏。
如果这家公司的代码库非常的庞大，让一个刚来的新人去闷头看代码显然是不现实的做法。
正确的节奏应该是分一些重要性不是很高的 issue 给他，让他去慢慢的 Debug。 （ PS.我一直觉得 Debug 是理解一个庞大代码库最有效的手段）
Debug 多了，对代码自然就了解多了。

回到楼主的疑惑，你的这个新师傅回答问题的方式不太好，即便是要你去看代码，也应该给一些方向，比如告诉你去哪个 solution，或者在哪个文件里打个断点，诸如此类。

所以楼主也别太困惑，说不定就是他懒，不知道怎么做一个好的 Mentor。

我厂不加班。

@followyourheart @songjiaxin2008 支持现学啊。

试试我厂，不算互联网，但是技术氛围还算浓厚。

@deepdark #17 招行 ETC 在哪里办理？
另外求教楼上各位，ETC 注销的时候麻烦不麻烦？

成本最低的创业就是找一份 955 的工作，用你的业余时间去尝试你的 idea。
因为工作时间之外的创业的试错成本是最低的。

@JerryCha 招啊，前段时间还有一个在上海的哥们直接面试悉尼的岗，然后去悉尼 Office 了呀。

@jsnjfz 是的是的，不过测试用机还是两台显示器。
@seki @exonuclease 哈哈哈，是你们的 Gold Partner, Azure Devops 我们暂时没没有用。
@EricLeo 啥公司呀？
@wu6694449 其实国外.NET 用得还挺多的。

我觉得当前帖子下，楼主说的这些都是楼主自己的主观感受，没有实际的案例。
楼主说 Leader 的方法烂，但是没有说出烂在哪里，如果能举出一个例子，也好让大家知道到底是谁的方法更优。而且很多时候方法的优劣，并不好通过一个人的单方面说辞去判断，要放在一个具体的产品的样本中去判断。

当一个产品足够大的时候，Leader 必然是对产品的了解比你更多的，他在做一个决定的时候，必然是从全局去考虑。

举个简单例子（只是例子），你深谙 SOLID 之道，在做一个简单的 issue fixing 的 work item 的时候，你觉得有几个文件的代码看着非常的繁冗，完全背离了 SOLID 原则，你想去做一下重构。 如果是我，我可能不会允许你在当前这个 work item 下去做这个事情，而会建议你新建一个 WI，专门去搞这个重构。
你可能不会同意，觉得是顺带手的事情，但是从大局来看，每一个 WI 拆分得越细，目标越单一，出错的概率就越小, Reviewer 审查代码的时候也越容易。
Fix Issue 就是 Fix Issue, 重构就是重构，New Feature 就是 New Feature.

综上来看，我无法判断你和你的 Leader 两个人的方法和观点谁对谁错，但是有一点他没有做好，就是他否决你的方案的时候，没有给你一个非常合理的解释，也没有照顾到你的情绪，所以才会让你觉得他的方法烂，和觉得他固执。

以上是我作为 Leader 的一些感觉和判断，不一定对，但是希望可以给楼主一个从另外一个角度去看待这个问题的可能性。

台式机，i9, 64g,3 显示器。

可以把房子租在 Mascot，离 CT 近一点，不过最近公寓断裂的消息也是够吓人的。

@kenanremix #2 一模一样的。

在我司，Senior Architect 和 CTO 都得写代码。

标题里出现类似“时代抛弃你，连声招呼都不会打” 这种夸装的煽动性的文字的，基本可以忽略了。

最好的读源代码的办法应该是 Debug 吧，而且我一直觉得 Debug 是每一个程序员最重要的能力之一。