《高效能程序员的修炼》一如何培养写作习惯

如何培养写作习惯

高效能程序员的修炼
我得忏悔一下:程序员同胞们,从某种程度上来说,我创办的Stack Overflow网站“耍”了大家。

在你找来棍棒准备揍我之前,请允许我先解释一下。

在过去的6年时间里,我越来越坚定地有了这样一个想法,那就是:成为一名杰出的程序员其实跟写代码没有太大的关系。做程序员确实需要一些技能,当然,还要有坚韧不拔的精神。但除此之外,更重要的还是要有良好的沟通技巧。

杰出的程序员跟勉强过得去的程序员之间的差别,不在于他们掌握了多少种编程语言,也不在于他们谁更擅长Python或Java。真正的关键是,他们能不能把他们的想法表达清楚。杰出的程序员通过说服别人来达成协作。通过清晰的注释和技术文档,他们让其他程序员能够读懂他们的代码,这也意味着其他程序员能够重用他们的代码,而不必重新去写。要不然,他们所写的代码的价值就大打折扣了。

以上是我的合伙人Joel Spolsky说过的一段话。我对他的这个观点非常赞赏!

程序员们可能会争辩道:与人沟通本来就不是我们的长项;我们并不是因为热爱跟别人聊天才做软件开发这一行的。然而,沟通从来就是个问题,书面沟通尤其困难。既然我们选择了这个行业,还是想想如何在这方面有所提高吧!我觉得写博客是个好方法:

人们需要花一生的时间去学习如何有效地写作。这事没有捷径。这东西你也买不来。你必须自己去提高。

这也正是那些担心自己写作不行的人应该开始写博客的原因。

这是一种锻炼。不管现在的你多么不靠谱,只要你每周练习几次,就一定会有所提高。博客不用太长,坚持每周写几个,你一定能越写越好。但如果你因为写作恐惧症而不这么做,那么,你很可能永远就这样了(别想成为杰出的程序员)!

大家都知道我抱有极大的善意,但只是单纯地对一个人说“你应该写博客”,他是不会理你的。对此我有切身体会。并不是所有的人都适合写博客。对于一个普通程序员来说,要他写一篇哪怕是很短的文章,都是一项不可能完成的任务,就像要他的命一样。那么,我该怎样让广大程序员自觉地写博客、培养起写作习惯呢?

连哄带骗呗,别无他法!

大家来看看我曾经收到过的这封信吧:

我不知道你有没有意识到Stack Overflow的边际效应,不过,这个网站确确实实教会了我很多有效写作的方法,比我从以前听过的任何课程、读过的任何书,或参加过的任何其他活动中学到的都要多。

我想不出还有什么其他工具,可以用来检测我写的东西,并且如此迅速地对它的质量给出反馈。当我在Stack Overflow上回答问题的时候,特别是做一些高质量的技术纠错时,我能看到其他人也在努力,所有的回复放在一起,差别自现。大家的投票是不会骗人的。他们给了我信心,让我确信将来我发给同事的电子邮件会在多大程度上被接受,也有助于我把商业企划做得更好。

在过去的5个月时间里,我可以察觉到自己写的回复在质量上的稳步提升。如果我的回复没被选为最佳答案,我会去看别人的回复,然后去研究原因。我会想:也许我写得太啰唆了?也许太简练了?也许我没有抓住问题的关键,或者没有一针见血?

我记得你曾经说过,这么多年来你一直在Coding Horror发表博文,这极大地提升了你的写作能力。我想告诉你,Stack Overflow对于我来说起到了相同的作用,因此我要由衷地感谢你。我决定效仿你,开设一个我自己的关于编程的博客。今天我刚刚完成了域名注册。我希望它能像Stack Overflow一样出色。没有哪个评论家会像程序员那样,对每个细节都刨根问底,拼命地想从你说的话中或者语法结构中找出纰漏。如果你写的东西能够被广大程序员接受,那么你将能经得起任何读者的考验。

Joel和我一直把Stack Overflow以及其他所有的Stack Exchange问答网站定位为轻量级的、专注的、不失趣味的写作型网站。

没错,凭良心说,我们是在“诱导”你成为一个更棒的写手。事实证明,这很奏效!Stack Overflow拥有很多非常明显的像游戏一样的元素,能为你的进步助力,也能使互联网变得更加美好。更重要的是,它使你变得更为出色!看着广大程序员跟他们的同伴们聚集在一起,在专设的专家问答社区里自然而然地提高了他们的书面沟通能力,我真是无比自豪!

还有其他的一些兄弟社区,它们同样对编程以外的写作推崇备至。在那里,你可以自由地锻炼你的文笔。我们也有这样的网站。

如果你是一名作家、编辑、评论员、博主、撰稿人,或者有志于任何方面写作的人,职业的或非职业的,都可以去看看writers.stackexchange.com。不管你是做什么的,有效写作都是推进你的职业生涯发展的一种基础性技能,必须加以重视!

再说一遍,你应该写作!我觉得Jon Skeet总结得非常好:

每个人都应该大量地写作,不管是撰写博客、写书、回复Stack Overflow上的问题、写电子邮件,还是写其他的什么东西。写下来,然后回过头去斟酌一下。依我的经验,这种书面沟通有助于理清我们的思路。当你要向其他人详细解释某样东西的时候,你会惊讶地发现你自己有多无知。于是,你不得不开始一个全新的探索过程。

写作的过程真的就是一次探索之旅,而且它会贯穿人的一生。至于你是在写一篇小说、写印刷评论、回复Stack Overflow上的问题、创作漫画故事、写博客、写一段注释、写技术白皮书、写旅游日志或者是写关于写作本身的文章,这些真的都无关紧要。动手吧,开始写起来!

时间: 2024-11-03 08:06:04

《高效能程序员的修炼》一如何培养写作习惯的相关文章

读书笔记--《高效能程序员的修炼》

        初次邂逅......        最近小编抽空看了一本书,书的名字叫做<高效能程序员的修炼>,从这本书的名字就能看出来,软件开发远不只是写代码那么简单,你要学会的是高效能的工作,这让小编想到了去年读过的一本书<高效能人士的七个习惯>,有兴趣的小伙伴可以看看哦,受益匪浅,<高效能程序员的修炼>这本书从人文角度而非技术角度去阐释了作为一个程序员,应该具备的基本素质,所以小编在看这本书的过程中,感到非常的有共鸣,通俗易懂,又很贴近小逼啊工作和生活中的实际,

《高效能程序员的修炼》一向橡皮鸭求助

向橡皮鸭求助 高效能程序员的修炼 在Stack Exchange上,我们坚持要求提出问题的人需要在自己的问题上多下些功夫,而且我们在这方面有些偏执.那就是说,当你开始要提问题的时候,你应该: 用足够多的细节来描述发生的状况,这样我们可以顺着你的描述继续研究下去.即使在你所在的特定领域里我们并不是专家,你也要向我们提供必要的背景情况,这样我们可以了解到底发生了什么事情. 告诉我们你为什么需要知道答案.你怎么会出现在这里?是闲来无事的好奇,还是在某个项目里遇到了障碍?我们不是要求你长篇大论地讲生活故

《高效能程序员的修炼》一大道至简

大道至简 高效能程序员的修炼 作者在Twitter上发的一条短讯: "你永远都有简化的空间." 11:29 AM – 2012-5-21 Rich Skrenta在"Code is our enemy"(代码是我们的敌人)一文中是这么说的: 代码不是什么好东西.代码会随着时间的推移慢慢腐烂.代码需要周期性的维护.代码里还藏有bug.新增功能意味着旧的代码需要被修改.你的代码越多,bug能藏身的地方就越多,迁出(checkout)或者编译的时间也就越长,新员工理解你的

《高效能程序员的修炼》一一路向前冲

一路向前冲 高效能程序员的修炼就运营Stack Overflow这个公司而言,我采用的商业策略全来自一个人,而且只有这一个人:Curtis Armstrong. 更准确地说,是Curtis Armstrong在1985年的经典荒诞青春喜剧<再见人生>(<Better Off Dead>)中所扮演的Charles De Mar.当他被问到如何从一个特别险峻的高山上滑雪下去的时候,他回答道: 沿着那条路下去,一定要快.如果有什么东西挡住了你的去路--绕开它! 在我们宣布Stack Ov

《高效能程序员的修炼》一磨刀不误砍柴工

磨刀不误砍柴工 高效能程序员的修炼作为一名软件开发人员,你该如何磨快你的锯子? "磨锯子"实际上是一个代名词,泛指一切编程以外的活动(不必编写代码),而这些活动(从理论上来说)能使你成为一名更出色的程序员.这个词源自于Covey的一本书:<高效能人士的7个习惯>(<The 7 Habits of Highly Effective People>).1 有个人在山间漫步,偶遇一位伐木工.他便停下来观察这位伐木工,看他热火朝天地锯一棵很大的树.他发现这位伐木工干得大

《高效能程序员的修炼》一性能致胜

性能致胜 高效能程序员的修炼在Stack Overflow和Stack Exchange上,我们总是非常强调性能.不仅仅因为我们是性能的发烧友(我很内疚),也因为我们认为速度是一个竞争优势.已经有大量的实验数据表明,网站载入和显示的速度越慢,使用它的人就会越少. Google发现,显示10个结果的网页需要0.4秒来生成,显示30个结果的网页需要0.9秒来生成.半秒钟的延迟会造成20%的流量下降.半秒钟的延迟就扼杀了用户的满意度. 在A/B1测试中,亚马逊试着以100毫秒为单位逐步增加页面的延迟,

《高效能程序员的修炼》一学会读源代码

学会读源代码 高效能程序员的修炼在"沟通"这个复杂的领域里,写出能让人类领会并理解的连贯段落比敲出几行不至于让解释器或编译器"呕吐"的软件代码要难得多. 这就是为什么--就软件开发而言--所有的文档大概都是很差劲的.而且,由于为人写作比为机器写作要困难得多,恐怕在可预见的将来,文档还会继续差劲下去.对此,你基本上是无能为力的. 除了做一件事-- "卢克1,学着去读源代码." JavaScript"始终带有源代码"是一股革命性的

《高效能程序员的修炼》一导读

译者序 高效能程序员的修炼出版社的冀康一开始来找我谈翻译这本书的时候,我的第一反应是:这兄弟真是不知道我现在有多忙!我每天要处理200多封邮件:在资源有限的情况下经常要同时带6-7个项目,而且每个项目的交付计划都很紧,压力很大:每天起码工作12个小时,有时候还要熬夜跟美国同事开会:周六基本上也是工作状态--我哪里还有空来翻译书?! 后来,当我了解到这本书的作者是Stack Overflow网站的创始人Jeff Atwood,还有书的内容实际上就是从作者的博客网站Coding Horror精选而来

《高效能程序员的修炼》一关于多任务的神话

关于多任务的神话 高效能程序员的修炼在<质量·软件·管理:系统思维(第1卷)>一书中,Gerald Weinberg1提出了一个经验法则,用以计算由于切换项目而引起的浪费. 根据Weinberg的计算,哪怕在你的工作负荷中只是增加一个项目,也会严重地影响你的效率.你会损失20%的时间.当你增加第三个项目的时候,你会有将近一半的时间浪费在任务切换上面. 即便你同一时间只做一个项目,这种问题也可能会发生.轻易被电子邮件.电话以及即时消息打断你正在进行的工作,其影响可能是深远的,就像BBC2的这个研