@optional 议价和催收能力当然也是赚外快的一环。另外也不是说非得做和本职工作一样的活，不一定有那么大的压力。
对选择 996 的理性人来讲，说白了其实就是超出日常工作部分的本事不够，不如 996 中的违法黑工多出来的部分可行嘛。
不过 996 还是会影响不 996 的本职工作的成本问题。某些行业工贼抖 M 习惯了，普遍压缩行业的工作机会缩减选择余地，搞得找到不 996 的工作现在都变成一种本事了，这也是哄抬取得合法收入需要花费的成本。

工资？默认讨论时薪累积最大合法工作时间实际上本应该是常识。就是有人侥幸法不责众呢……
@Raymon111111 “短时间搞到大量的钱”是个真实需求，但是如果其实现不排除避免违法，那么门路实在多了去了。996 除了暂时不容易碰上刑法以外不配被特殊化。然而讨论这个需求应该对应的是“收入”而不是“工资”——没人阻止你非工作时间另外接私活或者兼职，非得 996 搞得没时间赚外快或者没能力接活，怪谁呢。

@myfei 那首先说明你输入效率太低。
输入不会成为瓶颈的情况下拿轮得到补全的 UI 反应？而且要是刚好 le 和 leader 之间还有其它变量名你不能马上回车怎么办？就算恰巧能回车，非连续输入的情况下不确信是不是马上能回车还得愣一下不需要时间？信不信你输入 le 去选词的时间都够我敲两个 leader 或者“领导者”了？
而更大的槽点是你没搞清主要问题在哪。正常输入代码实际上多花几倍时间输入 leader 或者领导者都不会成为瓶颈，因为这种低级操作很容易形成“肌肉记忆”，在瞬时是可并发的，原则上不需要阻碍思路。而停下来思考要不要回车甚至看 UI 反馈选字是复杂的分支操作，基本没法并发，明显更打断思路影响效率。
另外，真的不得不打断思路去对付一个比较长的名称的话，我倾向选择选中复制粘贴，因为可以减少让具体拼写（尤其是意义不明的前缀）过大脑污染 cache 的机会，避免之后稀里糊涂念歪变量名而被迫停下来修正这样再次增加打断思路的风险。

实际上一般人读研也好工作也好头几年都是混经验为主，因为没啥别的资源方便动用。
对经验值来讲，现在的行情还是小厂混经验<读研<大厂混经验。小厂的问题是你可能什么都得做但什么都做不精。大厂的好处是你可以有很大的纵深，但这得看脸，而且还有因为被迫当可替换螺丝钉工具人而降低实际竞争力的风险。
读研在经验值上是折衷的做法，运气好研究方向上可以加和大厂类似的 buff （但不要指望太多），不过也得看自己是不是能适应。文凭反而只是个小的 bonus，如果几年不积累经验只混文凭实际上还是吃亏的。学校不同现在也不会有特别大差距，因为批发行情供大于求，大厂 HR 各种名校都见得多了，技术对口拿 special offer 的基本也用不上。当然最后效果还得看脸——要是遇到个黑工头导师那未必比得上小厂混经验强，不能平衡好资源再毕不了业就更呵呵了。

@deadFish 怎么说呢……你的观点在统计意义上特别是现在这种供大于求的情况下是顶用的。
不过这主要是在 HR 招聘的角度上看。而我更在乎的更绝对意义上的能在之后工作中体现作用的水平。
说秒杀应届，也不是说随便秒杀任何一个应届生吧？合格的毕业生只要能保持应届生的平均水平，之后多出来的经验就理应顺秒之了，而且只要没有明显的天赋差距，时间差距越久越难被翻盘。所以只要能过面试，并不是非得显得“特别强”才能吃得开。
大厂批发的高学历研究方向和项目背景完全对口能发挥专长的并不多，所以高出来的学历实际有效的优势，主要也是比低学历者多出来的通用经验了。（混的另说。）

@yunshui 大部分情况下正常的程序从命令行就能看出是怎么启动的了。如果非要套娃几次让你看不出是哪个特异来源，那明确就是恶意程序，不放心就全系统排查杀到每个进程都认识吧。。

@yunshui 搞成服务了？ Process Explorer 或者 Process Hacker 之类的增强版任务管理器进程属性里找启动命令行，sc delete 一窝端了。

@cmdOptionKana 用拼音技术上就是 low：重码率高得发指，没事增加歧义，在绝大多数正常的中文用户眼里就是抽。
另外你得正视还有不少人拼音不如汉字水平的，以及拼音编码本身就有争议会引起文化冲突。

和业务文档能直接对应，需要应对的涉众能懂就没问题。
非得生造需求瞎翻译增加成本的乱棍打出去。

@deadFish 你这逻辑是不是反了。
同等职位筛简历过的一般不就是学历越差本事越不可说么。否则你还需要自愧不如个啥？
（另外，一些时候还是物以稀为贵，人也一样。）

@suriv520 我当年装 XP 反复蓝屏还被修电脑的抱怨系统太新不会用，，，
（后来证明是硬盘坏了。）

@aabbcc 依赖不透明的更残废饭桶模式？

@noobcoder1 Review 不清楚的后果自负。说好的不听还能干啥？打得过有主线 force push 权限有本地访问权限的配置管理员？不想自己维护的计算工作量的分支整个历史被编辑掉就老实听话，哪来那么多事儿。
你似乎没搞清楚，一般情况下，所有 remote 上所有（不是以团队成员命名的）公开的 feature branch 的工作是有需要就要准备移交的，从来就不可能完全是“自己的”分支，这样的分支上历史出偏差是要负责任的。而真正所谓“自己”的分支，要么是提前约好的专用分支，要么干脆是不 push 都随便的本地分支（当然，不算在工作量里），本来想怎么搞就怎么搞。
还有，你的“最新的代码合到自己分支上继续开发”“尽早解决冲突”的做法根本没法保证“冲突应该会很少”；即便冲突真的不多，历史也可能因为到处非 ff 的 merge 整个乱了。
原则：只要是往上 push 的东西，就应该清楚这些工作会影响到别人的 base。对应地，自己到底依赖的是什么 base 分支也必须清楚（这不只是管理的要求，不守规矩可能自己这边重现 bug 都可能呵呵），而且除非你自己保证负责 squash 掉，否则就不应该无脑尽早解决——要是你依赖的 base 更新了再回退，难道你这里还非得多 merge 几次才更好看？搞清楚你的历史 merge 后也会进被合的分支里。不要搞得 push 完到处意义不明的 merge，让别人看不下去再替你 rebase 浪费时间。

@vmebeh mpq 和下载后解压的更新包相比主要的差别是内容用私有格式加密和延迟解包。
如果每次加载时解包，可能影响加载体验，实现逻辑上也未必有更新时解包容易。
如果旧版本很多内容应该能被新版本覆盖掉，直接增量更新也会浪费空间。

根本上，下载压缩的更新包和小文件各种有优缺点。关键是看给谁省事。

对服务端来说，相对直接更新小文件，一整个更新包能提供以下优势：
1.节约更新服务器存储、带宽和请求压力。
一整个更新包压缩起来通常更小，文件数也显然更少。
2.提升更新服务器自身更新和同步时的可靠性。
减少收拾更新了一半出故障的烂摊子的成本。
3.实现简单，算法可按需灵活更换。
4.更新包作为事务边界，简单地保证客户端更新的完整性。
可整体加校验，比校验小文件方便得多。
5.更新包方便续传。
考虑更新可能覆盖文件，要保证准确覆盖对的状态不容易维护，可能还需要约定写入顺序。
不分块，下载一半掉线，默认已下载写入的部分可靠，不用重新请求已经下载的部分，接着往后下载就行。

直接下载文件相比先下载再解压更新的主要好处是可以并行下载和安装。不过，大部分不太大的更新上这个优势不明显。（又不是 Visual Studio ……）
其它的小的实现上的差别……除了可能省点时间（考虑压缩小文件传输可能更节约时间，实际不一定），基本上就是给客户端省了点电，但逻辑实现和服务端的开销还是没省。

@zushi000 我说的是考虑项目管理的涉众为主的一个侧面角度，你说的是垂直领域的另一个侧面的一些角度。评价这些成功并不矛盾。我也基本上同意你说的对待产品的态度的问题。不过这里我更在意的是微信有这个底气的更根本原因。
微信为什么用户多？
我想，很大程度是赶上了移动互联网的车，而提供了大量之前对 IM 功能不敏感的非核心用户。
也正是如此，多数用户理解的“成功”恐怕比你我说得简单得多：到处都在用且有很多人用。
具体来讲，很多中老年人根本不用电脑（也不用手机 QQ ），这些基本就没什么产品预期的用户自然容易被先入为主地洗脑。至少相对短信这样的形式，微信确实提供了更多实惠的功能，所以他们眼里这就算是个成功的产品了。然后，这些人虽然个体表达能力不强，但凭借数量和家庭和社会地位的绝对优势集体垄断了用户之中的话语权，加上各种垂直领域的新功能的实用化（特别是金融和生活服务相关的），相对更理性了解微信 IM 功能缺陷的用户的声音被淹没了。这样，凭借话语权垄断，微信歪曲了它作为产品“成功”的内涵。
我算不上微信的核心用户，因为很早就被各种莫名其妙的设计恶心到了而避免主动使用（基本就是只有应付长辈的时候用；其它情形下 IM 功能最不济也有 QQ 顶着），也因此我并没怎么接触张小龙团队，不清楚应付产品反馈上的态度露骨程度。考虑到微信的功能不少有其它选项而不至于像用户话语权一般垄断，我也没热心去怼（而只是乐意落井下石）。但是，不了解同类产品而盲目支持微信的用户群体和基数还是摆在那里。只要有这个前提在，根本上很难保证没有一个被骂成狗的张小龙第二。那么剩下的一个问题，如果不幸再有类似的情况，作为少数群体的用户该如何应对？（七大姑八大嫂要加微信还不能不给面子就够烦的了……）

@zushi000 成功有很多不同的角度。
项目方和投资人这样的核心涉众自己是怎么想的？满足了多少既定目标？外人大概只能靠猜了，实在有很多变数。虽然就他们的立场上整体上算成功看上去没问题，但至少成功的程度也不是一概而论的。考虑项目本身，像用户数和变现的能力算是项目自身的商业成功，但现在这样的用户体验混乱的问题真的就是计算之内的吗？还是把原来的目标妥协打折的结果？再考虑项目外的影响：这个市场格局是项目方预料好的吗？特别地，虽然鹅厂有内讧不奇怪，但是好歹资方最终利益应该是一致的。在已经有 QQ 的情况下出来一个微信和 QQ 竞争这个风险是不是值？在微信立项的当时这就不是显然的。现在两边问题都不很大，这个意义也是能叫成功；要是大水冲了龙王庙，那即便微信能达到现在的影响，也不会被当作现在这样成功。
对用户来说，他们享受到本来就应该容易得到的更好的服务、更有效地满足需求了吗？这个就不是那么难想了。对瞎下载东西把机器弄卡的问题，用户很多也是很有意见的。然而，作为主力的中老年人表达不满意的平均能力较弱，这些用户的不满被严重低估了。算上这些因素，还算很成功吗？
而就整个 IM 发展的历史来讲，通过跟现在的类似产品对比就能发现微信在很多地方开了倒○车，就更难以称得上有多成功了。

@vmebeh 下载完再解包很正常，否则出现几 w 小文件下载 99%失败这类情况就呵呵了（不管是扔掉进度全部重下还是头铁同步状态都容易被用户打）。不过正常更完就该把包删掉。

@zppass 不巧，因为恰巧有个 QQ，比竞品差的一些地方就露马脚了。
光是这些部分就明显就不是“差不多”。
@zushi000 有个问题，什么算成功？
要是背靠腾讯是主要原因，QQ 算不算更成功？
如果要拿用户基数来衡量成功，大概“天时地利人和”——数量最多的这届用户恰好比较白目——才是“成功”更重要的原因。
另一个问题，微信这个项目的具体目标，外人都没法明确，如何能否定？
看来这里很多人自始至终都没理解，名义上吐槽产品问题，其实真正是给谁看的呢。

@cmdOptionKana 这玩意儿被怼显然不只是因为作为工具的问题。
至少正常来说，你不去用的工具不应该会上门来烦你，然而借助社交网络传播的瘟疫就是另一回事了。