序:
不应该局限于特定的技术,而是应该拥有足够广博的背景和经验基础,以让你能在特定的环境下选择好的解决方案。你的背景源自对计算机科学的基本原理的理解,而你的经验来自广泛的实际项目。理论和实践的结合使你强大起来。
一.定期为你的知识资产投资:
定期投资;多元化;管理奉贤;低买高卖;重新评估和平衡。
目标:
l 每年至少学习一种新的语言。不同语言以不同方式解决相同的问题。通过学习若干不同的方法,可以帮助你拓宽你的思维,并避免墨守成规。
l 每季度阅读一本技术书籍。一旦你养成习惯,就一个月读一本书。在你掌握了你在使用的技术之后,扩展范围,阅读一些与你的项目无关的书籍。
l 也要阅读非技术书籍。记住计算机是由人使用的,这十分重要,你在设法满足其需要的人。不要忘了等式中人这一边。
l 上课。在本地的学院或大学、或是将要来临的下一次会展上寻找有趣的课程。
l 参加本地用户组织,不要知识去听讲,要主动参与。与世隔绝对你的职业生涯来说可能是致命的;打听一下你们公司以外的人都在做什么。
l 试验不同的环境。如果你只在windows上工作,就试试Unix。如果你只用过makefile和编辑器,就试试IDE,反之亦然。
l 跟上潮流。订阅商务杂志和其他期刊。选择所函盖的技术与你当前的项目不同的刊物。
l 上网。想要了解某种新语言或其他技术的各种特性,要了解其他人的相关经验,了解他们使用的特定行话等等。
持续投入十分重要。一旦你熟悉了某种新语言或是新技术,继续前进。学习另一种。是否在某个项目中使用这些技术,或者是否把它们放入你的简历,这并不重要。学习的过程将扩展你的思维,使你向着新的可能性和新的做事方式拓展。思想的“异花授粉”(cross-pollination)十分重要;设法把你学到的东西应用到你当前的项目中。即使你的项目没有使用该技术,你或许也能借鉴一些想法。例如,熟悉了面向对象,你就会用不同的方式编写纯C程序。
二.交流:
作为开发者,我们必须在许多层面上进行交流。我们花许多小时在开会、倾听和交谈上。我们与最终用户一起工作,设法了解他们的需要。我们编写代码,与机器交流我们的意图;把我们的想法变成文档,留给以后的开发者。我们撰写提案和备忘录,用以申请资源并证明其正当性、报告我们的状态、以及提出各种新方法。我们每天在团队中工作,宣扬我们的主意、修正现有的做法、并提出新的做法。我们的时间有很大一部分都花在交流上,所以我们需要把它做好。
知道你想要说什么
在工作中使用的更为正式的交流中,最重要的部分也许是确切地弄清楚你想要说什么。规划你想要说的东西,写出大纲,然后问你自己:“这是否讲清了我要说的所有内容?”提炼它,直到确实如此为止。这个方法不只适用于撰写文档,当你面临重要会议、或是要与重要的客户通电话时,简略记下你想要交流的想法,并准备好几种把它们讲清楚的策略。
了解你的听众
只有当你是在传达消息时,你才是在交流。为此,你需要了解你的听众的需要、兴趣、能力。要在脑海里形成一幅明确的关于你的听众的画面。
l 你想让他们学到什么?
l 他们对你讲的什么感兴趣?
l 他们有多丰富的经验?
l 他们想要多少细节?
l 你想让谁拥有这些信息?
l 你如何促使他们听你说话?
选择时机
为了了解你的听众需要听到什么,你需要弄清楚他们的“轻重缓急”是什么。找到一个刚刚以为丢失源码而遭老板批评的经理,向他介绍你关于源码仓库的构想,你将会拥有一个更容易接纳的倾听者。要让你所说的适得其时,在内容上相关,有时候,只要简单地问一句“现在我们可以谈谈、、、吗?”就可以了。
选择风格
调整你的交流风格,让其适应你的听众。有人要的是正式的“事实”简报,有些人喜欢进入正题之前高谈阔论一番。如果是书面文档,则有人喜欢一大摞报告,而另一些人却喜欢简单的备忘录或电子邮件。如果有疑问,就询问对方。
但是要记住,你也是交流事务的一方。如果有人说,他们需要你用一段话进行描述,而你觉得不用若干页纸就无法做到,如实告诉他们。记住,这样的反馈也是交流的一种形式。
让文档美观
你的主意很重要。它们应该以美观的方式传递给你的听众。
让听众参与
如果可能,让你的读者参与文档的早期草稿的制作,获取他们的反馈,并汲取他们的智慧。你将建立良好的工作关系,并很可能在此过程中制作出更好的文档。
做倾听者
如果你想要大家听你说话,你必须使用一种方法:听他们说话。即使你掌握着全部信息,即使那是一个正式会议。
鼓励大家通过提问来交谈,或是让他们总结你告诉他们的东西。把会议变成对话,你将能更有效地阐明你的观点。
回复他人
当别人给你发送邮件或备忘录、请你提供信息或是采取某种行动时,你是否经常忘记回复?在匆忙的日常生活中,你很容易忘记事情。你应该总是对邮件做出回应,即使内容只是“我稍后回复你。”随时通知别人,会让他们更容易原谅你偶尔的疏忽,并让他们觉得你没有忘记他们。
三.其他
在所有的弱点中,最大的弱点就是害怕暴露弱点。
不要留着“破窗户”(低劣的设计、错误决策、或者是糟糕的代码)不修。发现一个就修一个。如果没有足够的时间进行适当的修理,就用木版把它钉起来。或许你可以把出问题的代码放入注释,或是显示“未实现”的消息,或是用虚设的数据(dummy data)加以代替。采取某中行动防止进一步的损坏,并说明情势处在你的控制之下。
如果自己找不到答案,就去找出能找到答案的人。不要把问题搁在那里。与其他人交谈可以帮助你建立人际网络,并且可能在这个过程中找到了其他不相关问题的解决方案。
批判地思考你读到的和听到的。
和别人交流真的很重要!!不要怕暴露自己的弱点而止步,要记住这是个进步的过程!!
发表于 @ 2005年10月19日 16:11:00 | 评论( loading... ) | 举报| 收藏