技术写手的工作任何一个人都可以做。这份工作并不需要任何真正的技巧，因为它仅仅是写文本。更何况，通常情况下技术写手往往不能牢固掌握他们正在记录着的技术。
他们只是问一些，什么样的功能是应该做的，然后他们把开发的话写下来，也许增加一个章节和一些修饰的文字。
有没有想过这样一个问题？
事实上，人们有时候也会用这种思维，类比测试人员。
任何人都可以做测试。做测试只是需要有一个人站在产品面前，点击一下鼠标，或者给出一些测试案例而已。任何一个人都可以做到的。
为什么人们习惯在别人的工作上出现这种狭隘的思想呢？除了摇滚明星“The Developer”（注：People love to say that a rock star can do the work of 10 regular engineers.）以外，还有很多其他软件行业的角色面临着同样类似的偏见。
例如，配置管理工程师（或实施工程师）。
任何一个人都可以做到这一点。到头来，那仅仅是一个人肉文件处理器？
我们存在这些偏见的原因,是由于缺乏洞察别人的工作，和用什么标准来区分：一个好的测试人员/好的配置管理工程师/和一个平庸的,甚至是糟糕的技术写手。
也或许我们缺乏与真正优秀的人接触,而仅仅接触一些糟糕的人罢了。
例如我有幸与有可能成为最优秀的瑞典配置管理工程师(看您怎么定义)合作,在Softhouse的Christian Pendleton (@chop_se)
与他近距离合作，给了我一些感受就是如何做“优秀的配置管理工程师”,看他作为一个配置管理人员对哪些方面感兴趣,以及他是如何保持对最新的技能的把握。
到目前为止，我还没有与技术写手近距离合作,所以我在努力理解用什么标准去区分一个好的和一个平庸的技术写手。
但是错误在于，我的工作结束了,相反,我从来没有做任何技术方面的写作,除了情不得已要为我自己的代码编写。
“这些角色已经存在了很长时间”,可能是至今的最好的一个理由。
虽然我相信有经验的老读者能够指出软件行业的某些角色已经存在过几十年的，但此后消失或过时了,比如：相当于Copy boys 和Elevator operators的岗位。
在上一年，Scrum和Agile正一直在处于上升期，而且构建跨职能团队的误解已经更多的在行业中传播开来。
现在别误会我,其实我喜爱跨职能团队的理念和这个理念所表达出的东西,这些年来我都大力倡导它。
但是跨职能团队背后的最初想法是：你可以提高你的团队成员的综合能力水平，从而成为专家团队,这样他们可以独自完成一些较简单跨职能的任务。
但我遇到太多的管理者太计较,他们认为跨职能意味着每个人都应该能够做所有的事。
我有见过一些组织,“去掉头衔/职位”，如开发人员,测试人员等,并用一些含有“designer”的标题进行替换,并期望一个designer应该能够做测试,配置管理,技术支持等。当然，最重要的是编码,因为这是关系到推动更多的迭代版本产出的关键。
这既是悲剧又是错误,因为它剥夺了不同岗位的技能特质，而且还传送出一个“任何人都可以做你的工作”的信号。你再也不用指望在某个职业领域能够做得更好了。
这些公司要么外包一些可以所有事情都能做,但结果表现都很一般的super-generalists,要么通过某些渠道发现一些凡是所能做，且都做得很好的super-generalists(super-heroes)。这意味着,如果他们真的能找的这样的super-heroes话，也不得不通过猎头去雇佣这样的人。多数情况下，人们都会选择第一种情况，结果当然是不言而喻的。
我们需要意识到，长久以来已经存在的角色可能就是它得以存在的一个很好的理由。
还需记得,他们也可以随时间而变化。
例如Elisabeth Hendrickson(@testobsessed)最近在她的CAST2012主题演讲中给出了一个美好的引述:
"Testing is only dead if you're trying to find something that looked like testing in 1998"
“在当下，如果你仍旧尝试按照1998年的测试套路来做测试，那测试岗位是时候dead了”
最后，所有这一切都归结到这一点。我们对别人的工作了解得越少,我们就越倾向于认为，他的工作是简单的和可替换的。
所以当下次你在享受着咖啡和你的技术写手，或配置管理、或测试工程师，在一起聊天的时候,不妨对他们的工作提起兴趣,并试图找出区分优秀和平庸的标准。还有了解他们是如何在他们的职业上与时俱进。
因为老实说，比起仅仅了解自己的技能，我们为何要吝惜，通过了解更多岗位的技能而从中受益呢？
