chasing the shiny and new (追逐时髦的技术)

[原文地址](https://www.nemil.com/musings/shinyandnew.html)

湾区的[简评](https://wanqu.co/2015-09-28-chasing-the-shiny-and-new.html)也很有意思. 直接照搬过来:)

不要赶时髦。选择公司不应该光看那个公司用什么技术栈(php还是ruby还是nodejs、postgres还是mongodb),更重要的是看都有哪些有意思的技术问题要解决。

每天打开 Hacker News,肯定首页都有这种或那种新语言、新的编程框架。很多刚出校门的年轻的工程师们会有一种错觉,好像一定得用最新的技术才能改变世界一样。

Whatsapp 主要用80年代的语言 erlang、[Github用Ruby on Rails与C](https://wanqu.co/2015-08-28-scaling-on-ruby-with-a-nomadic-tech-team-s-c-a-l-e-medium.html)、[DuckDuckGo](https://wanqu.co/2014-09-23-google-duckduckgo.html)与Polyvore用 perl。语言、编程框架本身很重要,但更重要的是工程规范、思想、原则 – 关键还是看是什么人在用。你用了号称最先进、最新潮的语言,你也做不出一个 Whatsapp 啊 (不是指那个 app,而是指 Whatsapp 这个能赚钱、能被$190亿收购的公司)。

当 Paul Graham 被问到理想的编程语言时候,他说:"I mean, we have had startups writing their code in PHP – and that worries me a little bit. But not as much as other things worry me."


I worry that a small subset of programmers (and their employers) have this attitude, namely a consistent focus on transitioning stacks to the newest. They pick companies primarily based on the framework, aiming for the latest instead of the best tool for the job. They spend their time playing with new libraries and frameworks, instead of improving their core technical skills. Let's call them stack chasers - those pushing for new technologies (or their own favorite technologies) in a startup's stack, with limited advantages for key outputs (software capabilities that users value, development team productivity).

总是选择最新技术, 但是技术对关键输出(key outputs)却没有太多优势. 作者在脚注中给出了一个特例, 如果整个团队都对这个技术都有相同喜好.

If much of the team has the same favorite, it may be better to follow this – as teams do well with the tools they know intimately. Things get problematic where individual engineers each have their own favorite and advocate for changes primarily because it’s easier or more comfortable for them, rather than beneficial to the team.

There are several reasons this can be rational - the modern web engineer is often required be “current" to get a future job or contract; employers use a framework or language as a filter, rather than testing critical thinking and skills. Employers don't realize that strong developers can become experts in many languages or frameworks in weeks, often days, with the right support. Then in some frameworks/languages, the writing is on the wall: Swift is replacing Objective C, the world is moving to thinner, less monolithic backends and heavier, more responsive frontends. And often times, there are huge advantages to a switch: productivity goes up substantially or new user features are suddenly possible. And yet, many changes are not do or die for an early to mid stage company, and learning something for fun or a side project is a far cry from arguing that it's critical for production.

虽然选择最新技术看起来很有道理: 许多web工程师通常会被要求掌握最新技术来才能得到工作; 公司使用framework/language而不是critical thinking/skills来作为筛选条件. 但是他们没有注意到好的工程师可以在很快时间内掌握一门语言或框架; 转而使用最新技术可以让生产效率提高数倍并且一些user feature可以容易实现, 但是这些转变对于中小公司并不是do or die, 并且这些转变可以完全可以在side project中进行而不是立刻就一定要用在production上.

People may suggest that choosing a modern stack is a critical recruiting tool for great startup engineers. My own observation is that the greats look for other things. By far, the most important are interesting problems to work on - and interesting people to work with them on. Traction and a powerful mission are additional ways to attract great people (engineers or otherwise). 

For startups, PG [was asked in 2013 about ideal languages](http://castig.org/an-interview-with-paul-graham-hackers-painters-10-years-later/): "I mean, we have had startups writing their code in PHP – and that worries me a little bit. But not as much as other things worry me." Sam Lambert, Github’s Directory of Technology, in a [recent interview](https://medium.com/s-c-a-l-e/github-scaling-on-ruby-with-a-nomadic-tech-team-4db562b96dcd) speaks about his surprise at how much Github's stack is Rails, C, and Bash scripts when he initially interviewed with Github's CTO in 2013: "Then as the interview process went along, it was more revealed to me that this is actually a really pragmatic set of hackers that just hack on Ruby, hack on C and spend their time working on more interesting things using a more stable stack, rather than chasing after the latest and shiny tech." Github's approach strikes me as the right balance for many web and mobile engineers (startup and otherwise): explore tools widely, but then pragmatically choose the tools that solve the problems you face ([YAGNI](http://martinfowler.com/bliki/Yagni.html) applies in a lot more places than just user facing feature development). 

许多人会认为选择modern stack对于招聘到好的startup工程师是非常关键. 但是据我观察, 好的startup工程师更看重解决的是什么问题, 与哪些人一起工作.

What worries me is that certain developers, especially developers early in their career, may get the idea that a startup engineer is not a problem solver or computer scientist, but a glorified look up table - every few months their task is to memorize a new DSL, be it a language, framework, or library - in many cases to get limited benefits. This to me devalues who we are as early stage engineers - building things that people want, working on interesting technical problems, and shipping code rapidly. 

让我担心的是, 一些开发者尤其是职业生涯早期开发者, 会误认为startup工程师并不是problem solver或是计算机科学家, 而只是一个会炫耀发光的字典而没有太多实际用途. 这对于那些向我这样真正的初期创业工程师是一个侮辱.

By all means, experiment widely in your extra time and switch out languages/frameworks in production if the benefits are overwhelming, but think deeply about what the benefits are - and be critical of people who are cheerleaders for the new, without being thoughtful about the expected advantages for your team. To really embrace both your inner computer scientist and entrepreneur, spend your time learning concepts and solving interesting technical or user problems - rather than primarily spending your time moving from library to library, or forcing yourself to learn yet another framework or DSL without the potential to get substantial benefits in return. And if you have the right application boundaries and choose the framework you're productive in for now, you'll have some flexibility if your team is absolutely wrong about tech choice, but persistent enough to get to product market fit and beyond.

总之在使用新技术之前需要充分考虑, 这样是否真的可以带来实实在在的好处.

Open Hacker News on any given day, and there'll be a variety of posts beckoning you to learn, contribute, and build applications in a framework, language, library, or service of choice (including some companies like Mongo with serious cash, and therefore marketing budgets, behind their platforms). Some will have game changing capabilities, others a few critical differentiating features - but each will require time to become an expert. Some will loudly proclaim how they're the future, and look derisively at what you've learnt - but they'll need your skills and mindshare to truly compete with existing technologies. How will you choose?

HN上会有各种各样的帖子引诱你去关注和使用框架, 语言和库. 无论这些东西是有着game-changing的特性, 还是有某些细小特性, 都需要你花时间去学习. 某些人会宣传自己技术会成为未来, 并且略带嘲笑地看着你在所的事情. 然而, 他们却需要你的技术和想法来和现存技术竞争. 你会如何选择?

comments powered by Disqus