观点——职业与技术

0、起码学计算机，如果大一开始找找方向，大二开始定下来一直超那个方向努力，那么大四毕业时工作应该很好找的。

 

1、学而优则仕不对，仕是搞管理，是另一门学问，学而优你就继续学。

 

2、猎头的套路：跟你说工资多少多少，说的都是税前打包价。一般先说这个职位有多好多好，再谈你的缺点和要求，适当砍砍价，实在不行就搬出个“一般涨20〜30%，除非确实特别优秀可以涨50〜60%”——意思是你看你有什么资本能超出例外？至于你工作经历所体现的潜在价值、对客户长远发展的影响，即针对此岗位和客户实际情况，你的潜在价值到底值多大份量的市场行情溢价，是少有人愿意仔细考量的——毕竟备选简历那么多——或者考量了也不对你讲，而是对他的客户——招聘的一方讲。

 

3、工作头几年人家还看看你技术如何，越往后人家越看重你细分方向上的行业背景。不过不要十年都是给啥吃啥、从不思考的重复劳动，那叫条件反射不叫经验——我有30多年的走路经验，这算啥？

 

4、学计算机英语很重要，要听说读写都会。要尽量看原版书，因为外国人写技术书是生怕自己没讲清楚、生怕你不懂，所以讲得很细甚至有点啰嗦；中国人写书嘛，像教武术点到为止，成不成看你悟性和自己努力程度，师傅领进门，之后就不管了。

 

5、学外语跟学打球什么的一样，通过多练习把生疏的动作化成内在的、由潜意识控制的自发动作，往后再学新动作再扩展起来就容易得多了。

 

6、不管是在国内还是国外，你得有所建树，人家才认你。所谓生产力嘛，光空有想法是不行的，得落地。《Fluent Python》这本书里面提到一个人：The Zen of Python: import this的作者Tim Peters，江湖人称Timbot，an AI——这样的人到哪里不受欢迎？

 

7、关于代码风格。

　　字如其人，代码风格亦如此。

　　原则：如果是应用，跟你用的库保持一致——到什么山上唱什么歌；如果是库，作者就是你自己，那要好好把握一番了。

　　重要性一定要强调。《程序设计实践》开篇就强调的代码风格；大部分的开源软件代码，代码风格一致你看不出来是谁写的，但是工作中自己人写的往往都能根据代码风格推断出作者，这很不好。

　　Python强制基本代码风格，细节上也官方指导文档——好让大家有个讨论的共同基础，这很好。通过强制代码风格，让随便的人不能那么容易地随便起来，这很好很好。

　　

8、发现做嵌入式的个人甚至企业会自觉不自觉地轻视PC软件的开发：PC软件不是到处可以随便下载吗？有什么难的？看看这块板子稍微改吧改吧就能如何如何，如果需要配套PC软件的话那也只是个配套，核心还是在我这里……。原来PC/网络软件开发的鄙视链还藏着一大截。

 

9、远离社交平台，将注意力转向自身发展。虽然这有点有违人性，但至少目前的朋友圈卖的、晒的、转的、博眼球的大多质量不高、没多少思考与个人见解、没多少营养价值，太虚。

 

10、许多没有Python经验的人，会把Python看成跟Windows批处理或Linux Shell差不多的、不入流、不严肃的、很简化的、勉强称得上编程语言的语言。

 

11、有工作经验的人犯错误往往不是技术因素而是态度导致的，许多bug本不该发生的——如果写代码时能认真一些，考虑得长远一些。

 

12、写代码过于随便，网上复制点哪里需要贴哪里、胡乱堆砌，跟现实生活中随地大小便一个德性。

 

13、关于代码评审：

　　这工作得做，但不必像字面意思看起来那样地正式，有比没有差很多。

　　就像出门不能穿得太随便，写代码随便的人要是知道自己代码随时都有人看有人可能会提意见，他自然而然地就会仔细一些。

　　评审工作，还是CodeReview这个词好一些——评审太严肃了，得首先保证便利，要能随时随地地CodeReview——才会有自然而然地执行的意愿。

　　时效性的前提是便利性——要像GitHub那样打开浏览器马上就能看到谁改了哪些东西——不然像SVN客户端那样还得专门打开一个软件在各次提交之间摸黑找差异，麻烦，不能愉快地Code Review——要是路太长，想想都觉得累还怎么自发地往前走——要尊重人性。

 

14、把面向对象发挥到极致的是Java。

 

15、简单代替复杂是大势所趋：例如，试图用xml描述编程语言的SOAP WebService就被RESTful WebAPI取代；试图用二维结构描述多维世界的SQL，把问题表示搞得过于复杂化了，在复杂的现实和多变的需求面前显得越来越力不从心，是SQL自身的缺点造就了NoSQL的崛起。

 

16、许多企业对开源的态度：大路边上捡的、那个人故意丢了叫大家捡的、不捡白不捡，捡得理所当然、用得也理所当然，至于贡献？呵呵？没有法律效力的开放协议？呵呵。

 

17、QQ的透明头像、M$ Office的VBA，苹果的中国帐户银行卡地址不能有英文字母，滴滴有钱烧10亿搞补帖大战却不肯花钱给已经上线的Windows Phone App加个支付链接……，等等，都是技术让步于商业的例子。 

 

18、LinkedIn被M$收购的第一个动作就是：默认全选、提示用词冗长模糊，诱导用户向通讯录中所有没开通领英帐户的人发邀请短信，典型的M$风格。

 

19、学习应当区分工具和非工具，工具性质的东西优先级高、要熟练掌握，必先利其器嘛！

 

20、对设计模式，正确的态度应该是：不必作为圣经，但是必须掌握；能力上的要求是：在具体场景上能够自由组合、区分用与不用这样用那样用的差别。

 

21、学校里的“电脑高手”——备胎大王，给N多女生修电脑却一个女朋友也谈不着。

　　通常没多高的修养，上不了华丽一些的台面，醉心于技术并希望以此来赢得荣誉和前程。

　　这种发展模式是有失偏颇的、是畸型的。衣着打扮、举止谈吐、气质气势、名声背景，等等等等，综合素质很重要。

 

22、Python Web开发的正确学习路线应该是：WSGI-->Werkzeug-->Flask-->Flask Extensions。而Django，应该在有Web基础的情况下再去看官方文档。

 

23、大公司喜欢考所谓“智力题”，但是有好多是用数学公式或《计算理论》中的方法就可解决的。所以，那不是考“智力”，更不是要为难人，而是测试用理论知识解决实际问题的能力。

 

24、为什么软件公司几乎见不到老人？程序员经验多了年龄大了怎么办？只能搞管理？为什么国外在这方面又很不一样？一是技术方面，没多少需求：我们只是用人家的语言和库来做应用，没人想做基础工作或者想做也凑不起来有足够水平的人；二是受传统思想的影响：尊老爱幼，老年人就不要做写代码这种体力活了；再说又如何管理呢？不好意思发号施令的。那么不远的未来怎么办？比如再过二三十年，现在的主力军80/90后到那时也五六十了，全去搞管理吗？也许到那时就自然而然地有写代码的老年人了？不会——如果还是简单地做应用，那么可以参考餐饮业：有老年服务员？

 

25、 简单的事情并意味着能做到、做好，比如每天记5个新单词，这个道理都懂，却没多少人有真实体会，因为就没怎么要求自己，这是对个人。对公司之类的组织，优点是任务布置下去了总要有个交代，缺点是个人惰性累加起来造成的影响。

 

26、不论先天条件如何，富二代、官二代、穷二代，都需要个人努力。盖兹他妈是IBM董事，如果当时他把DOS外包给某高校教授，然后游山玩水泡妞，而不是自己捋袖子干，会有今天的M$？再如有著名爷爷的那个大胖墩，背景了得，不还是对着媒体镜头挖鼻孔、连个话都讲不完整？穷二代条件差，努力了不一定得好，但是不努力只会更差。

 

27、一份代码，功能完成后稍作休息，然后自己回头试着以用户和第三方的角度冷静、仔细地看看，看看还有哪些文章可做。这样处理可尽早优化，尽量减少老是改来改去带来的工作量和不利影响。当然，这里的用户除了产品用户，还多的是指读你代码、用你代码的人。

 

28、国内情况，至少就汽车电子这块，嵌入式的坑，比上位机和互联网要深得多。一是嵌入式软件本身的复杂性；二是项目导向，忙于应付项目，难以维护稳定的核心代码；三是用人年轻化代码素养整体不高；四是管理上还很传统，流行技术工资一定要比管理低的传统观念，没有像互联网公司那样技术和管理两条线。

 

29、软件开发人员的收入天花板。不做管理，单纯搞技术，搞得再好，能有多少收入？除了996的互联网公司，在上海税前打包价是年薪30〜40万？再高能高到哪里去？绝大多数公司管理上还是很传统的，技术人员的存在无非就是满足公司日常开发需求而已，少了你一个再招一个，只要不是核心开发人员一下子都跑光了就行——有时出于内部斗争或自我保护的需要跑光了也无所谓——只要业务还在。所以不论你抱着多大热情、多高的期望进入软件行业，都不要被技术神话迷了眼。要意识到现实中天花板的存在，要思考如何突破。

 

30、外企的核心技术，也就是最好玩最有意思最有意义最有价值的那部分，哪怕从纯技术的角度你该掌握的，也是不会让你玩的。你要等着人家封装好了，封装成砖头，你搬来好砌个漂亮的产品去卖。所以核心的技术，还是得自己开发自己掌握。可是内企，又有哪几家是实打实地人性化地搞些基础性的东西？

 

31、领导的艺术：即使没吃过猪肉，甚至猪跑都没见过，也能对着一盆猪肉夸夸其谈。这也是个本事。

 

32、管理人员的技术水平要求：层级越靠近一线开发人，技术要求就越高。

 

33、软件领域的许多方法论前提是开发人员都是熟手、水平都差不多。但是实际情况往往不是这样。所以水平参差不齐的的团队还是老老实实干活为妙。