在 CTO 眼里，什么样的程序员是更值得信赖的？

平衡个人成长和公司效率

我的个人经验来看，互联网公司分为两种：一种是独角兽公司，另一种是创业公司。当你在创业公司的时候，公司给你的 title 可能不是太得到市场的认可，这就要求你和公司一起成长，当公司成为这一行业里面的独角兽的时候，你也同时会得到市场的认可。公司的发展和工程师的个人成长的成长是相辅相成的。

从程序员的角度来想，个人考虑的大多数是如何涨工资，如何提高个人技能，或者获得一些资格认证，然后来证明自己的获得成长，一步步走向成功。

在公司层面来看，一是希望每个小伙伴都能成长地更快，这样做事的人感觉到成就感，人才自然而然就留下来。二是做事的效率和结果。一般公司也会经常组织进行技术分享会、内部交流探讨会，鼓励大家申请技术专利等，或者给予一些参加技术大会的门票福利，如 QCon、ArchSummit 等大会。这样小伙伴得到成长，提高效率把公司业务发展得更好。达到一个平衡，也是双方的共识。

90 后程序员

其实最开始创业的时候，内心觉得 80 后会比 90 后更能拼，二次元沟通困难。轻松筹开始从校招之后，我们发现很多 90 后小伙伴挺能拼的，经常加班到很晚。做事情也很积极主动。

如果你是一个新手程序员或者是刚刚进入互联网行业不久的 90 后程序员，其实你不必担心，你只需要一步一步稳扎稳打地做。当你找不到方向的时候，你可以从网上找到权威的网站 InfoQ 或者是技术大会，你只需了解一些关键词，看看他们的方向，然后做深入研究。最重要的是花大量的时间在这上面，并且持续投入。最近有个很流行“一万个小时”的理论。就是你在这个很专业的领域持续投入一万个小时，刻意练习后你就能达到一个很成熟的程度，大约就是三年的时间你就可以成长起来。

当然 80 后做事稳重、更加成熟、经验丰富。他们会帮助这些 90 后小伙伴更快的成长起来，90 后小伙伴也渴求得到指点。有的 90 后小伙伴也慢慢逐渐有了独立完成任务的能力，成为了团队的中坚力量。

技术选型

轻松筹前端框架有基于 Vue、React、还有自己研发的一套已经开源的框架 H5UI.IO，后端框架使用的开发语言是 Golang，我们是在 15 年下半年使用 Golang，之前使用的是 PHP，2016 年经历过一次高峰期，我们切换到能够扛高并发的 Golang。PHP 是 CPU 消耗型，所以当时用 PHP 成本非常高，还有语言的特性本身有一些局限，比如说要写一个连接池或者守护进程都很麻烦。

当时考虑 Go 语言的语言特性自身就支持协程，支持高并发，I/O 消耗型，所以当时决定选型用 Golang 的时候，在比较大的并发和流量的页面，比如众筹的一个详情页面，然后发现用 GoLang5 台机器干了 PHP 用几十台机器干的活，机器还没有压力，所以试验了一段时间，发现 Go 语言比较好，当时我们用 1.5 就开始做了 (这里指 Go 语言的版本号)，现在 Go 语言都到 1.9，已经比较成熟，很多创业公司从一开始创业就直接选择 Golang。

我觉得产品初期或者创业公司初期，技术负责人选择自己最熟悉的语言是最好的语言，用 PHP 做东西快就用 PHP，用 Golang 快就用 Golang，因为项目初期可能更多要求的是这个赶快上线，每种编程语言都是需要你投入时间去深耕的，或多或少都会踩各种各样的坑，所以在技术选型上用哪一个语言，就是在你适合的时候选择合适的语言。

关于系统重构，如果你是一个负责任的人，你可以把旧的东西推倒重做，不建议为老代码填坑。如果想做好这个事情。初期可以先在一些边缘业务尝试，不用提前和产品、运营沟通新型技术，他们可能会觉得会影响到进度或者不稳定因素来阻止你。最好是等上线一段时间后，再开始跟非技术人员讲，或许他们并关心技术如何实现，只要结果好就行。关键是要保证好项目进度。做好备用方案，如果新架构执行失败，那就加班在原有的基础上完成新的任务。

个人转型

我觉得大龄程序员还接着干，是因为喜欢写程序这个事情。如果你现在不是因为喜欢代码而是在养老，那么可能就会逐渐失去竞争力。

不要因为最近哪个技术火就盲目选择，到底做设计、前端、后端、人工智能或者大数据，这都取决于你的个人因素。如果你是一个喜欢做一些看起来很酷的事情，那么做前端比较好，如果你是一个逻辑思维比较清楚而且有点内向，那么你适合做后端。这都完全取决于你个人。

对于不在互联网行业的同学，比如有数学或者统计学方面的功底，可以尝试转型做互联网大数据，对黑客方面有所研究的，可以转型做互联网安全方面。如果你有这样的机会，初期不要要求太高薪水，要耐得住寂寞，三年时间你就可以在这个行业站稳脚跟。

公司方面

程序员最熟悉的 996，可能在大多数互联网公司已经司空见惯，当然也有很多弹性工作时间，周末不加班的公司，公司从实际的角度来讲是以结果来衡量程序员的，所以不必追问中间过程环节，但是一些特殊项目或者重要时间节骨眼，公司也可能会要求 996。目的是为了把公司的运转效率提高。

程序员和架构师在创业公司没有分的那么清楚和严格，都得写代码，因为创业公司人比较少，有可能是看上你可以一个人顶 10 个人用，所以还得看创业公司为什么邀请你，看重你哪方便的个人能力。

优秀程序员身上重要的特质

一、聪明，大部分人都喜欢和更聪明的人一起工作，聪明人理解事情的程度、做事的方向、察言观色等方面都出色。

二、积极主动，不管是个人的生活态度还是工作态度，都是充满阳光的，甚至能给别人带来正能量的人。

三、责任感，如果公司网站出故障，不管是不是自己平时负责的，都能主动尝试先去解决问题。

四、完美主义，代码结构非常清晰，一旦决定做一个事情，会自始至终把这件事做到极致。当写完代码会再次 review，而且会从别人角度来审视代码，自测也是一个非常重要的环节，完美主义者 bug 是很少的，在别人心中是一位“老司机”，对自己也要求非常严格。

程序员也需要高情商

情商高低标志一个人对别人关心的程度。讲述三个方面的情况：

1、沟通协作做一个互联网产品，需要很多角色的齐力协作。现在已经不是一个能单打独斗的时代，对整个团队来说，你的口碑更好，别人也会更愿意和你合作。别人觉得你更靠谱，后面有合作也会主动来找你。就是俗称的“人缘好”。

如果遇到队友代码很烂，当着别人的面羞辱一番，可能一时痛快，后面可能所有队友也会对你有所距离和谨慎。好的方式是你可以一个产品升级的时候提出重构项目，之后对这个项目有了主动权，选择一些更优秀的人和一起协作。

2、做事方式一些程序员不爱讲话，在自己的舒适区域埋头苦干，做一个事情也很少讲出来，是很吃亏的。既然已经辛辛苦苦把一个事情做了，至少总结或者记录下来，拿出点实际的结果数据或者事实，这样你在团队合作的结束后会给人留下很深的印象。

3、技术管理成为一个好的技术管理者，特别是遇到一个问题，会去分析问题原因，找谁来解决问题，最后有人总结出问题的本质，避免再次发生。管理团队需要因人而异，找到一个合适的人来做这件事非常关键，如何引导和激励团队成员，需要具备良好的沟通能力，从别出拿过来的需求是否也理解透彻，不要把团队成员带到一个错误方向。

另外程序员可以参加一些 meetup，可以给自己找到一个更宽广的社交范围。这样生活更加与众不同。

与产品经理共同打造一款成功的产品

互联网公司主要考虑的第一个因素是用户，不管你做什么，互联网最关注的是你的用户，你的用户需要什么，你就去做什么，而不是说我们想一个东西，让用户来适应我们，而是我们去了解用户真实的需求，去帮助他们解决一个问题。

第二个因素就是你的团队，互联网最重要的就做事的人，大家齐心协力去做一个事情，不管是产品、市场还是技术，大家都是出于一个目的，就是为了把这个产品做出来，用户给你好口碑，大家做这个事情很有成就感，同时自己得到了一个成长。

在整个过程中，逻辑是技术服务于产品，产品服务于用。但在这个环节，或多或少和产品有一些摩擦，但是我个人更看好的是和产品有更好的沟通，当我做技术编程角色的时候，更多的是和产品一起去探讨，初期讨论产品需求的时候，一起加入产品一起去探讨，怎么做更好，逻辑该怎么写，怎么更符合用户体验好一些。程序员天生逻辑性思维比较强的，而且比较保守。这样产品和技术刚柔结合起来，对最终产品的打磨更少出错。

理解产品需求

程序员需要了解产品需求的本质，一种是最小化可行性产品的需求，最开始只是做一个实验性的东西，然后一个逐步迭代的过程，需要不断地去尝试，去迭代，去引导用户。然后找到用户真正的刚需，验证这个需求是不是一个自己“意淫”或者“伪造”出来的东西。这种情况下我建议技术一定要和产品多沟通，最开始你参与进来和产品探讨，成为这个产品成员的一份子，后期这个方向不对或者甚至砍掉不做了，程序员也能明白其中的原因，同时乐在其中，最后大家一起其乐融融往同一个方向走。

另一种产品需求是逻辑关系复杂和严谨的，已经给你考虑到会出现 N 多种情况，各种错误提示及文案都一一俱全，这样程序员看到找不出有什么逻辑漏洞，只好照办。技术最终实现了产品，如果最终的实际效果不好，这时候技术就会觉得不爽，会觉得自己身上一点问题也没有，其实技术在这样的情况下也是有责任的，技术要勇于说“不”，可以说好的产品大道至简，举一些实际成功案例来引导“产品”。

我觉得第一种模式是最好的(看美国大片，首先一般会遇到一个难题，然后找到自己的 team，中间出现一些小分叉，然后克服困难、同心协力，最后暴击大 boss，取得成功)，大家共同参与进来，一起去探讨，然后一起共同去做，如果出了问题也有自己一部分的责任，往任何一个方向改变，也是大家共同的意见。后期出现什么问题都好沟通，这样其实产品和技术更和谐，形成一个精英团队，程序员和产品需要一起去打磨和成长，大家形成一个利益共同体，一起畅想未来，一起提出问题一起解决。

产品和技术“撕逼”那些事

产品和技术争辩一个事情怎么去实现的情况，时常都会发生，或多或少都有争锋相对的意思，其实主要看是在什么场合争吵，不要在公司办公区大庭广众之下或者有上级领导在场的地方，那样会造成同事或者领导对你的印象不好，或许也会认为你们不适合在一起做事。关起门来争吵是比较好的，这个事情不管最后谁说服谁，最后这个疑问有了一个结论并达成一个共识，对最后产品形态来说是一件好事。或许两个人关系变得更近了。

记住只有在乎这个事情的人或者想和你说真话的人才会和你去争论，如果压根不在乎，他就会随便应付草草了事。