Advice to Aimless, Excited Programmers

I occasionally see messages like this from aimless, excited programmers:

Hey everyone! I just learned Erlang/Haskell/Python, and now I'm looking for a big project to write in it. If you've got ideas, let me know!

or

I love Linux and open source and want to contribute to the community by starting a project. What's an important program that only runs under Windows that you'd love to have a Linux version of?

The wrong-way-aroundness of these requests always puzzles me. The key criteria is a programing language or an operating system or a software license. There's nothing about solving a problem or overall usefulness or any relevant connection between the application and the interests of the original poster. Would you trust a music notation program developed by a non-musician? A Photoshop clone written by someone who has never used Photoshop professionally? But I don't want to dwell on the negative side of this.

Here's my advice to people who make these queries:

Stop and think about all of your personal interests and solve a simple problem related to one of them. For example, I practice guitar by playing along to a drum machine, but I wish I could have human elements added to drum loops, like auto-fills and occasional variations and so on. What would it take to do that? I could start by writing a simple drum sequencing program--one without a GUI--and see how it went. I also take a lot of photographs, and I could use a tagging scheme that isn't tied to a do-everything program like Adobe Lightroom. That's simple enough that I could create a minimal solution in an afternoon.

The two keys: (1) keep it simple, (2) make it something you'd actually use.

Once you've got something working, then build a series of improved versions. Don't create pressure by making a version suitable for public distribution, just take a long look at the existing application, and make it better. Can I build an HTML 5 front end to my photo tagger?

If you keep this up for a couple of iterations, then you'll wind up an expert. An expert in a small, tightly-defined, maybe only relevant to you problem domain, yes, but an expert nonetheless. There's a very interesting side effect to becoming an expert: you can start experimenting with improvements and features that would have previously looked daunting or impossible. And those are the kind of improvements and features that might all of a sudden make your program appealing to a larger audience.

程序员从初级到中级10个秘诀

Justin James曾发表过一篇博文《10 tips for advancing from a beginner to an intermediate developer》，为我们分享如何才能完成程序员从初级到中级的蜕变，现将中文译文转载于此，供大家借鉴。

在一封与TechRepublic会员交流的邮件当中，他提到了面向程序员的博客、文章及杂志分成两类：面向初学者类（“hello world”这种类型的教程）以及面向专家类（MSDN杂志）。这个观点很好，有关程序员如何从初级跃升到中级的信息极少。以下是为了实现这种转变需要你去做的10件事。

1.学习另一门语言

其实你学的是哪一门语言并没有关系，但是学习另一门语言（不管你已经了解多少种语言）将把你打造为更好的程序员。能学会一门与你日常使用的语言风格迥异的语言则更佳。打个比方，如果你是C#程序员，学习VB.NET或者Java对你的帮助就没有学习Ruby或者Groovy大。

我说“学另一门语言”的意思是要真正学会它。学习一门语言包括三个领域的知识：语法、内置操作符和库，以及“如何使用”。前面两个简单；我认为一名有经验的程序员，根据语言的不同，能在半小时到几小时内掌握足以维护代码的语法知识。操作符和库只不过是知识逐步积累的过程，你什么时候想清楚要了解什么了，再去查阅参考材料也不迟。只有第三项，“如何使用它”-要花上你几个月的时间去跟这门语言打交道，真正的奇迹就在此发生。我建议用这门语言的风格去做一个适合该语言的项目。

真正学会了另一门语言之后，我敢保证你的程序员水平一定会突飞猛进。

2.学习先进的搜索技术、手段和及策略

作为一名好的程序员，不仅仅是技能的问题了，而是你寻找信息的技巧，这个趋势越来越明显。对大部分人而言，仅仅输入“现代语言及开发框架”，这都是泛泛之谈，记不住多少的。因此，你完成工作的能力通常取决于你的检索能力。不幸的是，了解到如何找到准确而高质量的信息可不仅仅是跑到TechRepublic来找答案，或者在你选好的搜索引擎上敲几个字那么简单。

“技术（Techniques）”、“手段（tactics）”和“策略（strategies）”看起来是一回事，实际上并非如此。你需要学会的技术是掌握你喜爱的搜索引擎的高级搜索系统；你需要了解诸如布尔操作符，如何过滤结果（像“非”关键字，域限制等等），关键字的词序扮演什么角色，等等。一句话，RTFM（Read The Fucking Manual，读那些他妈的手册）吧。

你应该学会这些手段，诸如如何接近特定的搜索，以及了解自己实际上想查些什么。查错误很容易—只需查出错代码即可—但是许多搜索的关键字选择要困难得多。

至于策略，你需要学会的东西，包括像应该使用哪种搜索引擎（提示：普通的搜索引擎不一定就是最佳选择），使用普通搜索引擎前应该访问哪个网站，甚至是应该到哪个论坛去寻求帮助，等等。

3.帮助别人

教别人始终是学习一切东西的最好方法之一。相对而言，由于你在开发领域还是个新手，认为自己没什么可教给人家的，这可以理解。但这毫无意义。记住，你所学到的一切都是你从别人或别处学到的；因此请尝试一下，成为另外一个人要请教的“别人”。每天尽量花一点时间试着回答TechRepublic上的问题，其他网站的亦可。读读其他会员的回答，你也可以学到很多东西。

4.有耐心，常练习

研究表明，要成为一名“专家”，需要花费10年，或者10000到20000小时的刻意练习时间。真的很久。还有，成为专家不尽然就是执行10年同样的任务；通常这意味着要在特定领域内执行广泛的任务。需要花费大量的时间和精力才能成为“专家”；做几年程序员是不够的。想在30岁左右成为一名高级软件开发工程师？要么尽早接受教育/培训，要么你得愿意在闲暇时间进行大量的工作、阅读和练习。我从高中开始编程，还牺牲了许多休息时间去跟踪行业发展、学习新技能等等。结果，我获得中级和高级程序员的时间就比我的大部分同事都要早得多，随着时间的推移，这些就转化成为很多的金钱。

5.对教条拒之门外

是时候开诚布公了：也许初级程序员了解的东西还不足以说出做某件事情有一种最好的方式。尊重朋友或者权威的观点是好的，但直到你更有经验之前，不要把他们的观点说成是你自己的。很简单，如果你所了解的不足以让你独立地找出这些东西来，你又怎么会认为你知道哪一位“专家”是对的呢？话是难听了点，不过请相信我；由于受某些愚蠢建议的蛊惑，或者追随某些根本不知道自己在说些什么的所谓专家，白白把自己的职业生涯耽搁了几年，这样毛头小伙程序员，我见过多了。这一点有一个很好的例子，就是面向对象结构的滥用。比如说，许多初级者读了一些有关面向对象的信息后，突然间，他们那简单的应用程序的类图看起来就像埃菲尔铁塔一样了。

6.深入学习一点先进理念

成为一名中级程序员，很大一部分是要在代码里面体现出一些所擅长的概念。就我而言，是多线程/并行性，是正则表达式，以及如何对动态语言进行变化（后两个在我离Perl渐行渐远后开始退化）。这是如何发生的？多线程和并行处理是因为我读了相关文章，觉得它看起来很有趣，然后再自己把它弄清楚了；然后我就一直使用这些技术来写应用。我做过一件工作，是用Perl写的，里面运用了大量的正则表达式。我也用一个过程引擎模板和内置数据库系统写过我自己的电子商务引擎；那时我几乎花了2年时间在这上面。

找到真正令你着迷的东西。也许是图像处理，也许是数据库设计，等等。即便你是一个入门级的程序员，也要尝试一下成为某一自己所关注领域的专家。这会让你相当快速地进入到中级水平，一旦你到了那个水平，你的专家之路也走到一半了。

7.学习你的领域里面的基本理论

写出“Hello World”，跟理解那些字是如何显示到屏幕上的是两码事。通过学习支撑你所从事的工作的“基础/底层工作（groundwork）”，你会变得更加在行。为什么？因为你会理解事物为何会以这种方式运作，当东西坏了就能知道是哪里的问题，等等。通过掌握工作的底层机制，你变会得更出色。

如果你是Web程序员，读读HTTP RFC和HTML规范。如果你使用代码生成器，好好看看它生成的代码；如果你使用数据库工具，看看它生成的底层SQL语句，不一而足。

8.看看高级程序员的代码

在工作中看看高级程序员写的代码，然后问一问事情是如何以某种特别的方式完成的，为什么？可能的话看看开源的项目。甚至即使其他程序员没有最好的编程习惯，你也会学到许多编程经验。当然，要小心别学到坏习惯。我的意思是说不要生搬硬套人家的东西；你要能领会到哪些是能行的通的，哪些是有道理的，然后再模仿人家。

9.学习好的习惯

愚蠢的变量名，糟糕的缩进习惯以及其他一些凌乱的迹象就是一个没有经验的程序员的最好标记。一个程序员在学会如何编程时，却经常没有被传授到那些不那么有趣的细节，像代码格式编排。甚至尽管学习这些东西并不会令你的代码更好，也不会令你成为更好的程序员，它也会确保你不被同事视为入门级的程序员。甚至即使某人是高级程序员，如果他的变量是以他那97只猫的名字来命名，或者其函数叫做“doSomething（）”的，他们看起来也不像是知道自己在干什么的人。而且会令其代码在过程中更难以维护。

10.要玩的开心

想要痴迷于单调乏味的工作？痛恨工作吧。要想升级为中级程序员可不仅仅是为了拿到不断增长的工资不达目的誓不罢休，而是要真正享受工作。如果你不喜欢自己的工作，且还是初级程序员，你怎么会认为成为中级或高级程序员情况就会有所好转呢？换工作或改职业吧。反过来说，如果你喜爱所从事的工作，那就好！只要你坚持下去，我保证你能成为一名更好的程序员。（Justin James）

【人物小传】

Justin James

Justin James

Justin James就职于Levit & James, Inc，并在公司中承担着混合编程、网络管理员、系统管理员多项职务。自2005年就在TechRepublic开博，博客地址：http://blogs.techrepublic.com.com/10things/。

原文链接：http://blogs.techrepublic.com.com/10things/?p=732

译文链接：http://kb.cnblogs.com/page/71136/

十个糟糕的程序员的行为

原文：http://cocre.com/?p=1081

之前本站发表过《优秀程序员的十个习惯》以及《程序员需要具备的基本技能》，那是我们需要去学习和培养的。这里，我们主要讨论十个糟糕程序员的特征，主要是需要让我们去避免和小心的。

1) 情绪化的思维

如果你开始使用不同颜色的眼光来看待这个世界的话，那么你可能会成为一个很糟糕的程序员。情绪化的思维或态度很有可能会把自己变成一个怪物。相信你经常可以看到很多很糟糕的程序会使用下面的这些语句：

• 我的程序不可能有这种问题。
• Java就是shit。
• 我最恨的就是使用UML做设计。
• 需求怎么老在变，没办干了。
• 受不了这些人，他们到底懂不懂啊。
• …… ……

这些带着情绪化的思维和态度，不但可以让你成为一个很糟糕的程序员，甚至可以影响你的前途。因为，情绪化通常都是魔鬼，会让你做出错误的判断和决定，错误码率的判断和决定直接决定了你的人生。

2) 怀疑别人

糟糕的程序总是说：“我的代码一定是正确的，我怀疑编译器有问题”，“我这应该没有问题吧，STL库怎么这么难用啊”。我曾经见过有程序员这样使用 STL类：map，当他发现这样放入字符串后却取不出来，觉得那是STL库的BUG，然后自己写了一个map！我的天啊！

某些时候，过早的下结论是一个很不好的习惯，任何事情都有其原因，只有知道了原因，你才能知道是谁的问题。一般来说，总是自己出的问题。

3) 过多关注实现，陷入问题细节

有些时候，当我们面对一个问题或是一个需求的时候，糟糕的程序员总是会马上去找一个解决方案或是实现，这是一个很不好的习惯。设计模式告诉我们，“喜欢接口，而不是实现”就是告诉我们，认清问题的本质和特性要比如何实现更重要。

• 对于一个客户的问题来说，首先应该想到的是如何先让用户正常工作，如何恢复正在“流血”的系统，而不是把用户放在一边而去分析问题的原因和解决方案。
• 对于解决一个bug来说，重现bug，了解原来程序的意图是首先重要的事，而不是马上去修改代码，否则必然会引入更多的BUG。
• 对于一个需求来说，我们需要了解的需求后面的商业背景，use case和真实意图，而不是去讨论如何实现。只有了解了用户的真实意图，实际使用的方式和案例，你才能真正如果去做设计。

糟糕的程序总是容易陷入细节，争论于如何实现和实现难题，以及问题的根本原因，而忽略了比这些更重要的东西。只有看懂了整个地图，我们才知道要怎么去走。

4) 使用并不熟悉的代码

糟糕的程序员最好的朋友是 Ctrl-C 和 Ctrl-V ，有些时候，他们并不知道代码的确切含义，就开始使用它，有证据表明，由拷贝粘贴引发的bug占了绝大多数。因为，代码总是只能在特定的环境下才能正常地 工作，如果代码的上下文改变了，很有可能使得代码产生很多你不知道的行为，当你连代码都控制不住了，你还能编出什么好的程序呢？

5) 拼命工作而不是聪明的工作

对于糟糕的程序员，我们总是能看到他们拼命地修正他们的bug，总是花非常多时间并重复地完成某一工作。而好的程序可能会花双倍的时间来准备一个有 效的开发环境，工具，以及在开发的时候花双倍甚至10倍的时间来避免一些错误。好的程序员总是会利用一切工具或手段来让自己的工作变得更有效率，总是为在 开发的时候尽可能得不出错。后期出错的成本将会是巨大的，而且那时改正错误的压力也是巨大的。所以，糟糕的程序通常会让自己进入一种恶性循环，他们看上去 总是疲惫的，总是很辛苦的，所以更没有时间来改善，越没有时间来改善，就有越多的问题。所以，拼命工作有些时候可能表明你不是一个好的程序员。

6) 总是在等待、找借口以及抱怨

当需求不明确的时候，当环境不是很满意的时候，他们总是在等待别人的改善。出现问题的时候，总是在找借口，或是抱怨这也不好，那也不好，所以自己当 然就没有做好。糟糕的程序员总是希望自己的所处的环境是最好的，有明确的需求，有非常不错的开发环境，有足够的时间，有不错的QA，还有很强的team leader，以及体贴自己的经理，有足够的培训，有良好的讨论，有别人强有力的支持……，这是一种“饭来张口，衣来伸手”的态度，这个世界本来就不完 美，一个团队需要所有人去奋斗，况且，如果什么都变得完美了，那么，你的价值何在吗？driving instead of waiting, leading instead of following.

7) 滋生办公室政治

有句话叫“丑女多作怪”，意思是说如果一个自己没有真实的能力的话，那么他一定会在其它方面作文章。糟糕的程序员也是这样，如果他们程序编不好的 话，比不过别人的话，他们通常会去靠指责别人，推脱责任，或是排挤有能力的人，等等不正常的手段来保全自己。所以，糟糕的程序通常伴随着办公室政治。

8 ) 说得多做得少

糟糕的程序员总是觉得自己什么都懂，他们并不会觉得自己的认识和知识都是有限的。这就是所谓的夸夸其谈，是的，什么都做不好的程序员能靠什么混日子呢？就是吹啊吹啊。

另一个表现方式是他们在评论起别人的程序或是设计，总是能挑出一堆毛病，但自己的程序写得也很烂。总是批评抱怨，而没有任何有建设性的意见，或是提出可行的解决方案。

这些糟糕的程序员，总是喜欢以批评别人的程序而达到显示自己的优秀。

9) 顽固

当你给出一打证据说明那里有一个更好的方案，那里有一个更好的方向的时候，他们总是会倔强的认为他们自己的做法才是最好的。一个我亲身经历的事例就 是，当我看到一个新来的程序员在解决一个问题的时候走到了错误的方向上时，我提醒他，你可能走错了，应该是另外那边，并且我证明了给他看还有一个更为简单 的方法，有。然而，这位程序员却告诉我，“那是我的方法，我一定要把之走下去，不然我会非常难受”，于是，在三天后的代码评审中，在经过顽固地解释以及一 片质疑声中，他不得不采用了我最先告诉他的那个方法。

这些程序员，从来不会去想，也不会去找人讨论还有没有更好的方法，而是坚持自己的想法，那怕是条死路都一往直前，不撞南墙永不回头。

10) 写“聪明”的代码

他们写出来的代码需要别的同事查看程序语言参考手册，或是其程序的逻辑或是风格看上去相当时髦，但却非常难读。代码本应该简洁和易读，而他们喜欢在代码中表现自己，并尝试另类的东西，以显示自己的才气。是的，只有能力有问题的程序员才需要借助这样的显示。

记得以前的一个经历，一位英语很不错的程序员加入公司，本来对我们这些英语二把刀来说，我们喜欢看到的是简单和易读的英文文档，然后，那位老兄为了 展示他的英语如何牛，使用了很多GRE中比较生僻的短语和词汇。让大家阅读得很艰苦。最有讽刺意味的是，有一位native的美国人后来在其邮件中询问他 某个单词的意思。呵呵。

你是一个糟糕的程序员吗？欢迎你分享你的经历