『1024』这个程序员节，聊聊程序员的自我进阶
今年的1024是程序员节，程序员是个怎样的个体如何定义，程序员们每天都在做什么，作为一个职业程序员该有怎样的认知，如何进阶成更好的程序员，小编整理了InfoQ过往文章，送给每天都在跟需求和代码战斗的猿伙伴们。ps：今天过节不加班，看完文章去狂欢～
按照Wikipedia的定义，程序员又称为计算机程序员（Computer Programmer）、开发者（Developer）、编码者（Coder）或计算机工程师（Computer Engineer），和网络上广泛流传的码农或程序猿同义。下面代码出自一位程序员之手——“程序员”的代码显示，姑且算作节日一乐。
再说程序员的定义。程序员是彻头彻尾的脑力工作者(Mind Worker)，怠于思考者绝对不能成为好的程序员。有鉴于此，类Programmer天生的就应该是Thinker的子类。就程序员所使用的思考技巧而言，Thinker的具体内涵包括逻辑(Logic)和数学（Mathematics）。作为程序员，不一定非要达到逻辑或数学领域的专业水准，而是必须具有逻辑和数学的基本素养。逻辑用来推理，数学用来培养逻辑。另外，数学还有助于程序员训练另外两项必不可少的思考的技能，分析和抽象。下文还要展开讨论。程序员的工具是编程语言，日常活动和主要工作包括设计（design）、建模（model）、编码（code）、调试（debug）、重构（refactor）、沟通（communicate）、学习（learn）和思考（think）。
有关程序员有一个流传甚广的误解，认为做程序员门槛低，没什么技术含量。即使没有学过计算机的课程如离散数学、数据结构、算法等，也可以写程序。写几行程序当然算不得什么，但要修炼成有一定思想境界的一流程序员，却殊非易事。这就如同会做饭的人很多，但真正的烹饪大师却并不常见。所谓码农者，乃是程序员的自我吐槽，岂足深信耶？所以，作为程序员要有持续进阶的强烈的进取心，断不可妄自菲薄，自怨自艾。
程序猿与产品汪的恩怨能写出一部书剑恩仇录，同意的程序员请默默点赞。程序员每天的工作都在处理需求编写代码中度过，程序员需要依据需求实现让公司让客户满意的东西，需要直接对结果负责，当结果与预期出现偏差，不论需求是否恰当且合理，程序员都不得不重新加班熬夜再虐一轮。
因而，对于程序员来说，准确理解预判需求，和写得一手好代码，是同等重要的。那到底怎样的需求才是合理的需求，有资深开发者这样描述一个恰当的需求的制作过程：
需要业务人员与程序员共同讨论，并且经过双方充分的沟通
需要不断拆解、拆解、再拆解
不断打磨，经得起推敲
也许有的程序员认为制定需求与自己无关，其实不然。在大型组织中可能会有专门的业务分析师，他们的主要工作就是在将详细的需求规范传递给实现团队之前对其进行不断的完善。在理想情况下，这么做是完美无缺的，程序员只需坐在那儿编写代码就行，不过实际情况却并非如此。
组织的规模越小，程序员需要处理的事情就越多。对于勤恳钻研的程序员来说可能阅读AngularJS 2.0的升级路径要比与客户讨论领域问题和需求更有趣。但现实是，你的技术、对框架或算法的理解只是你每天工作的一部分。因为对于所有开发工作来说，基础是“恰当的需求”。唯有参与其中，才能更有效地提升工作效率。
某新创公司CEO针对技术人员招聘困难的问题，总结了多条阻碍程序员职业生涯发展的行为，具体如下：
1. 直到特性“完成”的时候才会提交。（但永远都不会完成！）
有些程序员没有足够的信心来承受团队中其他成员的批评和审查，因此会把自己的工作藏起来，直到“完成”状态才提交。这种开发者会损害团队中其他人员的生产力，因为团队看不到他每天的成果，而且他也不会在正常开发的过程中寻求帮助，这样就会造成很多“最后一分钟”的缺陷，从而让交付延迟。这时候程序员需要做的事，要清楚地知道，代码并不是他们自己，因此会把代码经常自信地呈现在其他团队成员的眼前，获得批评和建议。
2. 分析瘫痪（Analysis paralysis）
分析瘫痪是指在程序开发初期进行系统分析，常因为太过执着于控制所有可能的变化和意外，而造成大量时间的浪费，裹足不前。这是一种很经典的问题，会影响很多一般的程序员。它通常是由过度分析造成的，不敢做出坏的决定。一般的程序员会担心犯错，只想一次成功。一个敢于拥抱机遇与挑战的程序员不会害怕，他们会编写很烂的代码，对其进行单元测试，如果认为无法达到目的，就会在45分钟之内把它抛弃。强大的程序员会积极地限制用来研究的时间，因为他们知道那是个陷阱——看起来是有效的，但经常都无效。
3. 不知道如何让其他程序员更容易使用你的代码
在所有技术团队中，工作很重要的一部分就是人员的并行（human parallelism），也就是多个人能够同时对同一代码库工作的能力。但是对于团队来说，能够异步工作也很重要，当你不在的时候我可以修改你的代码，反之亦然。然而一般开发者对一项任务编写代码，认为他们会永远拥有这段代码。有经验的资深开发者会知道技术债务的说法，会试图通过设计代码来对其限制，让它尽可能可维护和自解释。编写可读的代码需要程序员改变他们的看法——你的代码要比你在组织中存在的时间长。
4. 不知道如何阅读其他人的代码
当一位一般程序员看到用他所不熟悉的语言或框架编写的代码库时，就想立刻重写，而不考虑业务价值或者推向市场的时间。而强大的程序员会接受这样的观点，重写所导致的业务成本通常是不可接受的，所以应该避免这种行为。他们会试图坐在计算机前，理解、学习然后修改现有的代码。阅读代码要比编写代码还难，但是强大的程序员会投入时间来学习如何超越。
5. 不能从最终用户的角度编码（你考虑的范围太狭窄）
作为程序员，你的工作不是解决技术问题，你之所以解决技术问题，是为了解决业务问题。一般的程序员会陷在技术问题之中，而不知道最初是为什么要解决这个问题。无法从头开始创建出具有业务价值的东西。当被要求基于简单的用户设计新特性的时候，死板地、照着字面对故事或者说明书做出解释，这样交付的产品用户根本无法使用。不考虑相关的用例；不考虑最终用户的体验；在做面向用户的内容时，设计会很笨重。这导致无法编写业务应用，只能做产品。有经验的程序员会从最终用户的角度来看他们的代码。我怎样才能让它更轻松地解决用户的问题呢？故事的文字内容之外有哪些方面会让这个特性给用户带来更多收益呢？
6. 无法判断任何编程任务的业务价值
对选择如何投入时间做出很好的业务决定，应该问这样的问题：这是我现在应该做的最有价值的事情吗？我应该为之投入多少时间？离交付日期有两个星期，我现在能做什么，从而更容易满足那个日期呢？而反之拿着说明书，盲目地实现，直到结束，不关心他们的工作和公司的业务目标有什么关系，以及对其他团队和业务组会产生什么样的影响。这样做会在业务价值很低的技术任务上浪费大量开发时间。
想让自己的职业生涯更上一层楼，必然需要通过打造自己的个人品牌来积极地对其进行梳理。打造你自己的个人品牌要做的4件事：
信息——品牌代表什么？
视觉效果——品牌的视觉表现是怎样的？
一致性——品牌所传递的信息是不是一样的，我能否信赖？
重复曝光——品牌是否经常出现，我能够认出来？
缺乏这4个方面的品牌注定要失败。一个品牌必须要有一个清晰一致的信息、从视觉上能够被人所识别，这样才能达到效果。
信息的打造
品牌的一个主要构成就是信息了，信息是品牌所要表达的东西。没有信息的品牌什么也不是，因为它无法沟通。信息应该传达出品牌的内涵以及品牌所要表达的期望与承诺。如果实在想不出个人品牌的信息是什么，那么可以先看看你会提供什么价值。作为一名软件开发者或是软件开发公司，你会提供什么价值。为什么会有人雇佣你呢？信息背后就是你所提供的价值。你是金钱能够买到的最棒的前端开发者么？你学习新技术的速度比其他人快么？你能提供哪些独特的价值使得雇主会雇佣你而不是其他人？
视觉效果
虽然说Logo并不是构成品牌的唯一元素，不过显然它是大多数品牌的一个重要组成部分。一个好的品牌都有很好的视觉效果，你也不例外。显然，首先你应该创建自己的Logo。既可以使用公司名，也可以使用自己的名字。这两种方式都很有效。比如说，我使用Simple Programmer作为自己的品牌，同时也为这个品牌创建了一个Logo。
没必要花很多钱来设计Logo，可以在Fiverr网站上花5美元就能搞定一个，效果还非常不错。还可以在oDesk上找人帮你做一个，都非常便宜。你的品牌还应该有一个一直使用的不错的颜色主题，我建议在你的在线资料与博客上都使用相同的颜色主题。
保持一致性
信息与Logo的事情搞定后，你需要坚持不断地使用他们从而打造真正的品牌。一致性是构建个人品牌的一个非常重要的组成部分。想想那些你熟知的个人品牌，这些品牌会成天变化么？在访问喜欢的技术站点时，你是不是知道要看什么以及何时会看到新的内容呢？
曝光
如果缺乏频繁的曝光，那么你就无法树立品牌。如果你只看到或听到一两次某个品牌，那么它是不会在你的脑海中留下印记的，也不会有任何效果。为了树立自己的品牌，你需要频繁地向同样的人曝光你的信息与视觉效果。有很多方式可以曝光你的品牌，比如：
创建并维护一个活跃的博客
为杂志撰写文章或是在其他博客上发表文章
在用户组与会议上发表演讲
在播客或其他媒介上出现
写书，自己写或是按照传统的出版流程来
为开源做贡献
创建YouTube视频或教程