看你有多少队友，队友的平均&最低战斗力，以及项目打算维护多久决定了

我个人来说是极其讨厌

话说当年我校招面试的时候老板玩命提示我堆排，我就是想不起来还有堆排这么个算法，一直在扯快排……

实际项目，学力适应力和思维方式都比算法重要的多，也难培养的多，隔壁数据结构也比算法更实际。算法什么的作为调剂当脑筋急转弯随便啦


说穿了就是校招没法强行要求项目经验所以只能问问算法了这样……

重现了……嘛，自从换了chrome就再也没用过书签就是了

同事有辞了工作，自驾游了一年绕中国一圈，回来继续工作的

技术能力在那里，空个窗什么的不算啥问题

用::class语法不就完事儿了

就我周边的样本来说，没有15用户想要13的，一半以上13用户羡慕15的大屏幕

重的问题，可以配个电源在公司可以减轻不少重量，或者直接弄个锁，周末再带回家

测试和运维都是开发的重要(hao)搭(ji)档(you)，虽然前者一直在提bug，后者老不让你上生产，但最能帮开发分忧的也是他们，帮你减少线上bug少出生产事故的是他们，帮你提高系统鲁棒性稳定性，出事故时能有退路的也是他们，有这个心情和测试撕逼，不如约好一起去暴打产品狗（玩笑）

测试不了解需求，就推动他去了解需求。测试不了解系统，就介绍系统让他对总体结构有所认知。测试提建议型的ticket，就完善分级分类，优先级高的，blocking的解决，suggestion的improvement的可以即时做掉也可以延后。总之就是要协助测试让他能更顺畅地发挥他的作用，而不要“应付“他。

不如说无论是对测试还是运维还是产品还是设计，从协助对方的角度出发，一切好谈。毕竟团队里的每个成员的总体方向是一样的，你说呢？

黑的漂亮

优先学英文学到google stackoverflow 通常的技术文章等等无障碍的程度

然后不管学哪方面，都记得围绕自己的小项目，不要围绕读书或做题

然后第一个小项目差不多了以后，读《程序员修炼之道》，带着读后感和反思继续下一个小项目/迭代/重构

记得每年至少重读一遍《程序员修炼之道》。你碰到的大多数问题在里面都有解答/解决/回避方案。直到你发现周围所有的人有问题都找你解决，你每天的工作就是对着你的同事重复这本书里的观点/做法

每周帮小伙伴写周报的路过

我碰到过类似情况，感觉是虚拟机网卡桥接后干扰了dhcp

另外网上的删配置/增加位置/reset pram等等方法偶尔有效

为什么你没想到整理分享呢？ 别人发现这块东西有价值整理分享了就是办公室政治就是抢功劳？

合同没签，你当然有权要求提高offer

当然公司也有权因此拒掉你

想清楚这家公司拒掉你对你的损失有多大（或者说找到同等程度的offer有多难），想清楚这家公司的加薪渠道和频率（如果加薪渠道畅通，表现好很容易提高薪水，自然不那么需要这时候谈，反之则要谈到满意了）

推荐看看这篇文章

http://www.vikingcodeschool.com/posts/why-learning-to-code-is-so-damn-hard

Desert of Despair：能完成常见的需求，但发现自己水平根本不够，不知道该学什么

@lzsadam 友情提醒，linux运维和linux桌面没有任何关系，就好像学Javascript不用先掌握java一样

宇宙最好的语言表示，class interface和trait的花括号换行，控制结构if while switch for foreach的不换行～

@humiaozuzu tim yang那个群偏大厂架构，创业初期遇到的困难相对比较少

LZ建群的话拉上我，谢谢

生快🎂

被和隔壁家XX和你们班YY比还不够，成年了还找别人比么