我为什么要当一个程序员?

当我把标题的内容复制到百度搜索，敲下回车键之前，我忐忑不安的先预估一下搜索结果，这么冷门的话题，应该不会太多吧？
结果………

百度为您找到相关结果约5,040,000个

随便点开几个链接，浏览了一下里面的内容，一颗悬着的小心脏放了下来，我今天要谈的内容，估计不会与他人重复的太多。引用第一条搜索结果，转载一下来自知乎的答案。

程序员，是个技术活，也是一个吃青春饭的活，经常加班、高强度工作、新技术学习需求，转眼已经青春不再，有一大批人因为各种原因十年如一日的敲着代码，有的人早早就转行了，在经济迅速发展的今天，不由会使程序员有压力，什么行业的工作都压力，选择做程序员，只有一个原因就是你喜欢这个行业，喜欢这样的工作，不然，干嘛做程序员呢
作者：李晨
链接：https://www.zhihu.com/question/19783862/answer/34824102
来源：知乎

很明显，这是一个工作，这是一份职业，一种谋生的手段。什么？我为什么要当程序员，这么白痴的问题，当然是因为互联网时代的大势所趋了，赚钱多，工作好找，说白了就是想混的好一点，就这么简单。没错，没错就是这样简单与现实， 为了生活，为了赚钱

为什么要当老师，为什么要当医生，为什么要考公务员，为什么要读大学…………靠，这还用问么，为了有个好的将来，为了赚钱啊，老大。

不过这显然不是我要给出的答案，要优雅的解决这个问题，我们首先要知道，什么是程序员。

那么，啥是程序员呢？

大体上英文解释分为三个单词，coder，programmer，developer，贴到百度翻译里给出的解释分别是，编码器，程序设计者，开发者。显然程序设计者更靠谱，程序员就是会编程，会设计程序的人。他要掌握至少一种编程语言，并且会应用，会设计。

所以说这个概念很宽，所谓青春饭，加班，高强度工作，只不过是一个互联网程序员的一个子类，而程序员能解决的问题不仅仅是web开发，移动开发，人工智能等现在很火的问题，事实上它很广泛，只要你通过设计程序来解决问题，你就可以被称之为程序员。

搞机械，数控车床要编程设计吧，算程序员吧。搞工程的，cad用吧，lisp要编程吧，算程序员吧。往大了说，程序员更不应该只限于计算机程序员，生活中也有编程，就说买个菜吧，要不要确定一下目标，规划一下路线，挑菜要不要方法，砍价要不要技术，一套流程下来有没有固定的经验和套路，能不能优化，能不能创新。这套流程记下来，是不是程序？那买菜的大妈算不算程序员？

所以说重要的是思想，是内核，而不是现实的实现与方法。

先说说我怎么走上编程的道路吧：

我第一次接触程序，第一门程序语言很有趣，叫做GVBASIC的BASIC语言，依托于当年很火的文曲星。90后的回忆，尤其男同胞们应该还记得背着老师，用文曲星、电子词典，打游戏，看小说的年代吧。对了，就是游戏，依托于强大的GVBASIC解释器，大量的RPG应运而生，更有意思的是，不仅仅是解释器，文曲星还提供了编辑器。所有的RPG游戏都可以用编辑器编辑。而我学习编程的目的很明确，就是要改我的HP,MP，改装备改武器。

不过摆在我面前有个很现实的问题，你不能指望一个初中小屁孩能看得懂代码。巧的是，同寝室的哥们有一个职业高中计算机专业的，他们的课程中就有一门QBASIC编程语言基础，虽然不大一样，但都是BASIC，语法也大体差不多，靠着啃这本书，我打开了编程这扇通往新世界的大门，当然，顺便也在游戏中爽了一把。

对当时的我来说，RPG游戏就是虚拟的世界，RPG中的角色就是我在游戏中的化身，而掌握的编程技术，我就成了游戏中的上帝，要什么有什么，一句话，感觉爽歪歪！

更重要的是，我从那时理解了一个重要的思想，通过顺序，选择，循环的构筑，可以达成我想要做的任何事情。即便在以后的经历中接触了面向对象的思想，程序设计的本质依然逃不过这三点。扯淡一点讲，我的人生，我的世界线也是一样，充满了选择和重复，这样我也可以用程序的思想来设计我的人生。

罗嗦了半天，该给出一个答案了：

我为啥要当一个程序员呢？

我要成为一个程序员，不是码农，不是coder编码器，而是一个利用编程思想，编程工具去解决问题的programmer。而编程的思想是什么呢？简洁，高效，最优化的解决问题，拒绝重复，拒绝混乱。

我要成为一个程序员，把编程的思想带入工作与生活中，优化工作，优化生活。永远追求更高效，更简洁，更优雅的解决办法。程序员不是我的职业，不是我的谋生手段，而是我的生活态度。

以上就是对我要成为程序员的解释。最后让我们截取一首诗来收尾，虽然它来自Python，但确是所有的programmmer都遵循的信条：

The Zen of Python, by Tim Peters 《Python 的禅》 by 提姆·彼特

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.

Special cases aren‘t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
…………