zoukankan      html  css  js  c++  java
  • 程序员生存定律【打造属于自己的稀缺性 】

      作为程序员,增值也好,改善表达力也好,最终都要在某种环境下达成一定的稀缺性,这样一个人才有价值。稀缺性同时受两个维度上的力量影响:一个是自身的努力;一个是大环境的变化以及对这种变化的适应。

     
      稀缺性可带给你什么
     
      既然稀缺性对个人有如此大的影响,那稀缺性到底可以带给一个人什么样的影响,我们来看一个简单的例子:
     
       在日本曾经有这样一个故事。一个人在某电信公司负责一个大型系统的维护,收入虽然不菲,但时间一长,这个人就对薪资发展不太满意,因此最终选择了离开。 结果他一离开,这大型系统立时跑的磕磕绊绊,无奈之下,这家电信公司只得以高职厚薪把这个人请了回来。可以想见为了达到这一目的,这家电信公司,无论在收 入还是职位上必然都开出了让这个人无法拒绝的条件。
     
      这是稀缺性起作用的一个典型例子。大型系统因为关联到庞大的用户群体而必须要用,同时这一系统的维护没有这个人又不行,这就使这个人的稀缺性变得非常突出。
     
       这事其实很有意思,因为在这里事实上是不好的软件成就了一个人的价值和稀缺性。这虽然不是很好,但其实这类情形并不罕见。从市场的角度来看,它并不关注 一个程序的内部逻辑是否清晰,是否有足够的注释,它只关注这东西能不能运作好。所以使用中的垃圾代码一样有巨大的价值,也就是说商业上的考量对稀缺性的影 响更大。
     
      为防止上述文字被曲解,这里补充一点说明。上述道路并非是一条非常值得模仿的道路。因为对上述那个人而言,事实上他的价值绑定于特定的一套系统,这会导致可流动性几乎没有,这就会限制住一个人的成就,并使未来存在很大风险。
     
      改善稀缺性的途径
     
       为了改善自己的稀缺性,通常需要同时做两个方面的工作:一是提升自己;一是顺应时势。提升自己可以让自己稀缺这点很好理解,但如果没有顺应时势相配合, 就很容易让这种稀缺性无法很好的实现。在 2013 年精通 DOS 编程的人无疑是稀缺的,可这不一定能产生价值。下面我们将从上述两个方面对稀缺性做一点说明。
     
      1、奔向程序世界里的价值高地
     
      投资大师巴菲特先生说过一句流传很广的话:有的企业有高耸的护城河,河里头还有凶猛的鳄鱼、海盗与鲨鱼守护着,这才是你应该投资的企业。这句话非常传神的描述了价值高地的外在形象。
     
      对于企业而言,护城河可以是很多东西:高难的技术(**飞机)、难以攻破的用户粘度(QQ)、独占的资源(中石油)、独特的企业文化(苹果)等等。
     
      护城河使企业拥有一种无可取代的价值,从供给上看这就是营造企业自身价值的稀缺性:缺了它不行,你又没有更多选择。这就是价值高地,当企业在这上面时,他相对安全。也正因此,大公司最终都会试图主导一种秩序与生态系统,只有如此大公司才能掌控稀缺性。
     
       这道理同样适用于个人。稀缺本身可以有很多来源,可以来源于时机,也可以来源于高度。来源于时机的稀缺性更像一种偶然,很容易被打破,往往并不具备长久 的价值,相对于人的一生而言,这并非是一种有力支撑。比如:Erlang 可能比较稀少,但单纯的语言壁垒并没有想的那么高,如果真的有巨大需求,这个世界上可以在一个月间多出几百万 Erlang 程序员。
     
      当一个人经营自己的稀缺性时,确实要找到一个有鳄鱼、海盗和鲨鱼守护的地方,这才是价值高地。当然鳄鱼之类很难是你放的,这与企业不同。在这点上管理方向上和技术方向上的程序员所面临的选择和所需要采取的措施不同。
     
      对于技术方向上的程序员而言,走向上述这类价值高地本身可以有两种方法:
     
       一是达到一定高度横向展开。比如:编程语言,(金融)业务逻辑,外语,网络知识等组合在一起就可以成为一个高地,这里面编程语言上一个人可能不如天才程 序员,业务逻辑上可能不如银行员工,外语可能不如专职翻译,但每多一重过滤,就会导致高地的海拔拔高一分,最终转换为稀缺性。
     
       一是彻底的专家型道路。有的岗位可能不需要把面扩的很宽,比如做 TTS,OCR 的算法,有些人甚至编程语言都可能不是了解的很熟,但确实可以是某一方面的专家。这同样是一种价值高地。在这个方向上,一旦真的达到一定高度,那就不是单 纯的累积数量可以超越的。比如:认为 100 个或多少个平庸的科学家等价于一个爱因斯坦无疑的是愚蠢的。
     
      不管是那种方向,最终都要达成这样一种效果:你可以完整的搞定一件很有商业价值的事情,而这件事情大多数人搞不定。比如说:
     
    • 我可以主导开发一款手机,因为我即懂软件又懂硬件,也还知道如果开发一款良好的产品。现在来看,如果真牛,可以去搞定锤子的问题。
    • 我可以把 OCR 的识别率提高1%。
    • 我可以主导架起百万级并发的网站
    • 我可以带领队伍搞定这个银行的整个系统。
    • ... ...
     
      这个时候最好不要用单纯的技术观点来衡量自己,比如我擅长 Java,我会用 PHP,我知道 TCP/IP 协议等等。不是说这没有价值,而是说这种视角有点低端。只有能完整搞定一件事情才会与商业利益直接挂钩,才可能有真正的稀缺性。
     
      对于管理方向上的程序员,走向上述这类价值高地似乎只有一种途径:
     
      要努力做出让人记得住的成绩,这个成绩可以是一个产品,也可以是某种业绩。今时今日,提到微信相信大家都会想到张小龙。这是因为微信本身在不到两年的时间里吸引了 2 亿用户,并且口碑很好,实在是个奇迹。
     
       关于价值高地,有一个典型的陷阱:不含复杂度的,特属于某个公司的经验,往往让人误以为是价值高地,但其实不是,因为只要环境相对的公开,这类东西往往 可以在短时间内被攻破。比如:一个公司可能定义了自己的流程,其中很多东西较为模糊,新人一做就处处碰壁。这很容易让然误解为掌握流程本身有较高的价值, 但其实这是由于流程不完善所造成的,是特定场景下的一种偶然。这确实导致稀缺性,但基本不具备可流动性,大多时候未必是好的选择。
     
      需求开发算价值高地么?
     
      在偏敏捷的组织里程序员往往离需求很近,但在比较传统的开发方法中,做需求的和程序员往往是有段距离的。做需求开发的可能不太会写程序,写程序的不太会写需求。
     
      那需求开发算价值高地么?
     
      很多纯粹的程序员可能觉得单纯的文档工作没什么技术含量,似乎谁都能写,因此可能认为这算不上什么价值高地。但从商业价值来看,当一个人摸透某个行业的业务(懂技术更好),那么这还真是价值高地。
     
      这可以来做个类比,**只做平台,各个**卖东西,那么**有价值么?当然有价值,** 11/11 的销售额 100 多亿比美国的黑色星期五还高,怎么可能没有价值。
     
      那为什么**有价值?因为终端客户的眼里是先有**,再有各个**,**垄断了入口,所以**更有价值。
     
      需求与开发的关系与此类似。当一个人做某个产品的需求时,在外人的眼里,这个人做的需求才表征着这个产品,透过产品才能看到程序员的贡献。外部人员思考的思路是先需求开发人员再程序员。
     
      其中比较极端的一种实践是需求开发人员主导整个项目,所有其他人员在需求开发人员的领导下工作。
     
      这个时候钻牛角尖是没意义的,比如:有的人可能认为没程序员那有产品,这就和争论没店家那来**一样,毫无意义。在现实中当然两者都有存在价值,这里讨论的只是说这是否算是一块价值高地。
     
      2、走在技术大潮的前面或里面
     
      IT 世界里,城头变幻大王旗来的特别的快,而每一次变幻时事实上都将导致某种技术的兴起或者某种技术的衰落。
     
       当年 WPS97 的开发时间非常长,对此百度百科上对此的描述是:Windows 有很多新东西,我们还没有熟悉过来,微软又升级了。很多技术资料,也很难找到。微软掌握着 Windows,而我们什么都要靠自己从头做起,这导致了 WPS97 难产。如果 WPS97 能在 1995 年推出,直接和 Word6.0 竞争,Word6.0 肯定没戏。
     
       这很生动的记述了一门新技术兴起时所造成的稀缺性,从侧面也可看出来,在 95 年的时候企业对高端 Windows 开发人员是何等的渴望。这种稀缺性是行业周期背后的技术更迭所造成的。而在今天,借助搜索引擎,初入行的程序员也可以解决大部分 Windows 编程的问题。
     
      面对这种技术潮流,比较合适的办法是基于现实勇敢拥抱新技术。
     
      基于现实是指考虑技能的可流动性,考虑实践和学习的 不可以分离特质,选择自己认为前景好的新技术,并投入时间。但这里面有个陷阱,一提到新技术很多人可能会联想到新编程语言,但编程语言太基础了,壁垒太 低,并不是一个足够大的考量区域。视角如果限在这个尺度上,看到的东西就会太多,而不容易聚焦,这时候需要把自己考量的单位适当放大一点,英文中常用 Tech Stack 这个词来描述这一组技术。
     
      比如说:LAMP (Linux+Apache +MySQL+Perl/PHP/Python)可以是一种考量单位,Windows 编程 +ASP.NET 也可以是一种考量单位,大数据处理相关种种也可以是一种考量单位。
     
       如果回望十年,我们就会发现,先有 PC 客户端程序的鼎盛,接下来是互联网的兴起,再接下来则是移动客户端的兴旺。以当下而论,无疑的移动客户端和互联网要比传统的 PC 客户端来的更有吸引力。而在云的时代里,壁垒比较分明的两套 Tech Stack 则是基于闭源的一系列技术(主要是由微软提供)和基于开源的一系列技术。在这里面如果那个 Tech Stack 的技术逐渐取得优势,那么无疑的在相应的 Tech Stack 中有积累的人会有比较好的稀缺性。
     
       虽然眼下看来,两者似乎没有明显差别,但在这点上,我个人认为未来开源 Tech Stack 会逐渐取得优势。在 Quora (quora.com)和 High Scalability (highscalability.com)上,我们可以查找到国外大部分新兴的、市值超过 10 亿美元 Web2.0 网站的技术架构,如:Flickr,Pinterest,Instagram 等。如果用心来读这些技术架构,就会发现他们一个根本的共同点:他们都是基于开源技术构建的。
     
      这种不约而同的选择背后有一定的必然性。当希望一定的定制性并且不愿意支付高额成本时开源 Tech Stack 几乎是一种唯一的选择,尤其是当开源的技术有越来越多成功实例的时候,这种优势就越来越明显。
     
      如果非要在客户端(iOS,Android,WinRT)和互联网中选择,我个人认为互联网比客户端更有优势。
     
      技术落潮所伴随的风险
     
      很 多人会讲微软在 2002 到 2012 这 10 年里几乎无所作为,也会谈论从股票上来看如果 10 年前买入的是微软股票那么现在只能赚 30~40%,而如果是买的苹果股票那就要赚 3 倍多。我个人偶尔思维发散,想到的却不只是这个,而是如果微软再失去 10 年,那挂掉的不只是微软,还有同微软绑在一起的各种公司和个人,包括很多资深的 Windows 程序员。
     
      在 PC 的世界里微软是无疑的霸主,但如果 PC 的时代过去了,那么这个霸主如果无法转型成功,那么无疑也要随之殉葬。而那个时候无数在微软平台上花了半生心血的人却还都在,他们又该何去何从?
     
      技术大潮的兴起会使潮头的很多人称为耀眼的明星,而某波潮水的退去,同样会带走与之相伴的一些人的光环。所不同的是前者轰轰烈烈,而后者寂寂无声。
     
      在这种情境下,还真就只能与时俱进。
     
      检查自己的稀缺性
     
       从社会需要的角度检查自己的稀缺性非常困难,因为相关的各种数据总是非常缺乏。但有个简单的方法可以很快的让一个人认清自己的稀缺性:假设一个毕业生很 努力的学,那么多久他可以取代你的工作?比如一个毕业生只要努力,那么可以在一两年取代你,而你的年纪已经接近 30 岁,那么稀缺性必然非常不好。
     
      而与这个相反,如果一个毕业生即使很努力,也要五年才有你的技术水平,同时如果没有特定的机缘,怎么也无法取代你,那么即使你已经 30 岁,你的稀缺性也会非常好。这里的机缘可以是指某些特别的实践机会。
     
      如果想比较系统的评估自己的稀缺性,那么需要依次考虑如下问题:
     
      自己所掌握的技术是即将过时的技术么?
     
      技术大潮总是会定时的淘汰各种技术,不同的时间点淘汰的对象也不太相同。有的虽然不是完全淘汰,但至少他们不再像当年那么辉煌了,如果以 2013 为界限而回看 10 年,那这样的技术有:Flash,MFC,Delphi 等。
     
      为保持对技术动向的敏感度,定期阅读别人的架构非常关键。
     
      当然可能过时的技术不单指通用的技术,还指老旧的可能会为新解决方案所替代的系统。比如说:曾经很多公司使用 Lotus Notes 来做知识管理的,但很少人使用这样的系统了。
    自己所掌握的技能究竟有多少人会?
     
      考 察这点时要像前文所描述的,更多的从公司的视角去考虑,而不是个人的视角。单纯的会使用某个语言或者框架这种程度,稀缺性一定没有。比如:单纯的会用 ASP.net 开发网页几乎没有较高的技术壁垒,但对数据库的设计有相当程度的掌握、能够较好的通过负载均衡、缓存等手段保证系统的性能就可以使自己的稀缺性上个台阶。(转载自:HTML5中国)
  • 相关阅读:
    朴素贝叶斯估计
    k临近法的实现:kd树
    感知机学习算法
    Logistic回归的牛顿法及DFP、BFGS拟牛顿法求解
    Logistic回归
    线性回归的梯度下降和正规方程组求解
    Redis学习笔记(8)-发布/订阅
    Redis学习笔记(7)-事务
    Redis学习笔记(6)-SortedSet
    Redis学习笔记(5)-Set
  • 原文地址:https://www.cnblogs.com/Alenliu/p/3892516.html
Copyright © 2011-2022 走看看