好奇求知 积极热忱 善用资源 勇于责任 团队协作 恪守承诺 开放大度 激励奋发
                
                想象:
我们将想象化为实际行动,为客户、大众和社区工作
                解决:我们协助解决一些世界上最棘手的问题
                营造:我们推崇企业文化,拓展市场、培养人才、为股东创造价值
                领先:我们唯才是用,以学习进取、兼容并蓄、求新求变的精神保持企业领先

                GE: Imagination at work

关于书写技术探讨性邮件的一点小小的建议

             关于书写技术探讨性邮件的一点小小的建议
                         周银辉

非常感谢DUDU为我们提供了一个这么好的平台,让我们能聚在一起如此广泛地交流,所以我也会收到许多朋友的技术探讨性邮件,当然大多仍以求助为主。收到此类邮件,我是很高兴的,这让我有更多的机会能与大家一起探讨技术难题。但,就此我想提一些不成熟的建议,若能为大家的交流提供一点参考价值,我将非常高兴。
值得声明的是:下面的文字所提到的一些小问题,仅仅是极少部分网友偶尔有所发生,但我仍然希望看到这些情况的尽可能的避免,所以写了下来。

1, 请提供一个小小的DEMO来说明问题,而不是贵公司的代码片段

这是一个让我很头疼的问题,不少朋友会在邮件中粘贴大片段的实际项目中的代码来呈现其所遇到的问题,然后问我应该怎么办。

我们知道,一个或多个大片段代码很可能很大程度上依赖于你的实际项目,而我是不具备这些上下文的,我为了搞清楚你所遇到的问题,而将这些代码从邮件中复制到一个临时的小项目中,显然,其会编译不过,那么我就不能重现其所遇到的问题,为此,我将花大量的时间来mock数据和上下文,而且我还不能保证这种mock的合理性,最后导致在我还没真正搞明白你所遇到的实际问题之前且被为你打造一个可以重现问题的DEMO而搞得头昏脑胀。

那么,如果你能花上5分钟,打造一个恰好能反映你的实际困难的小DEMO并放在邮件附件里面,我将不会迷失在混乱的代码片段中,并将节省下来的精力用于积极地为你出谋划策,你的邮件也能尽快地得到回复。

2, 大家都是兄弟,别太客气,但也请别太霸气

事实上,我有些犹豫是否将这一点写下来,因为这有可能是我这双鱼座的人平时太敏感而产生的错觉,但我始终认为“Hi,银辉,晚上好,我在开发中遇到这样一个问题XXX想请帮忙你看看”这样的语句会比“有一个问题XXX,请赐教”这中富有挑战性的语句更能让我愿意参与此次探讨。

3, 无论我是否给出了正确答案,我都想听听你的看法或更好的解决方案

我非常理解平时在项目中遇到难题时那种迫切地想得到完美解决方案的心情,但由于我的能力有限或者我不处于你的实际开发情景中而没能给你很好的解决方案或者是误解了你的实际问题,也请你不要生气,我很愿意听听你的看法或解决方案,这对我也很重要,而不是收到你“算了,我自己搞定了”或者“不过还是谢谢你”之类的回信。这可能会打击我回复你以后的邮件的积极性,当然你也可能从此不和我探讨问题了;但如此失败的探讨也会令我感到沮丧。

好了,这些文字虽然很不成熟,但仍算是有感而发吧,非常感谢大家长久以来的支持,祝大家周末愉快。

posted on 2008-07-11 21:55 周银辉 阅读(1182) 评论(17)  编辑 收藏 所属分类: Other

评论

#1楼  2008-07-11 21:59 Anders Liu      

深有同感……   回复  引用  查看    

#2楼  2008-07-11 22:10 杨义金      

让我想起很久以前一个老外的文章:Ask question the smart way.   回复  引用  查看    

#3楼  2008-07-11 22:14 TerryLee      

深有感触……

再补充一点,大家发邮件时尽可能详尽的描述一些错误,以及所使用的开发环境、版本等。有时候有些问题,我都看不明白是关于哪方面的问题,自然不可能去解答了,只好发邮件再问一遍,这样来来回回就浪费了不少的时间。   回复  引用  查看    

#4楼  2008-07-11 22:49 RubyPDF      

同感
另外不喜欢自己不思考直接索要答案的。   回复  引用  查看    

#5楼  2008-07-11 23:01 戏水      

小有感触……
有些朋友很少换位思考。我也反思自己是否也犯过同样的错误
感谢银辉写了这篇文。   回复  引用  查看    

#6楼  2008-07-11 23:11 560889223      

同感。   回复  引用  查看    

#7楼  2008-07-12 00:30 volnet(可以叫我大V)      

第一条非常赞同,经常问题并不总是出在那些给出的代码环节里,而是因为发问人自己的一厢情愿,还有甚至有的是环境问题造成的,跟代码都无关……,所以这个DEMO也很重要……
写一句不中听的话,网友们可能要骂我,连你发问都不愿意去写这样一个DEMO,难道我有义务去帮你做这些么?所以还是希望有这么一个DEMO,如果没有,我也得帮你做的。虽然大部分时间我都会帮着做,但并不总是能很顺利的做出来,关键是这本不是我该做的,所以建议那些发问的朋友都能够勤劳点。而且有时候问题本身就是因为你所处的环境太过复杂而你又没搞明白,那就做个DEMO,也许问题就凸现出来了。
周兄,关于第二点吧……,好像也没啥的,呵呵,平常心平常心~
关于第三点吧,有时候我其实都还没理解对方的意思,就会收到回复说是已经解决了,可能问题我正在解决,也许我有了初步的判断,但大家都是求知心切,还是烦请告诉我你的思路和方案,这样大家都能有所促进嘛,呵呵,希望各位发信的朋友都能够帮帮我。呵呵
第四点吧,就是跟数据库有关的尽量都要写个DEMO,呵呵,没数据要MOCK可累了……   回复  引用  查看    

#8楼  2008-07-12 03:40 枫子      

学习了。。。   回复  引用  查看    

#9楼  2008-07-12 07:45 阳春三月      

非常有同感!
还有的问题描述里错字连篇,同音的别字也不选一下。我觉得这虽是小事儿,但反映一个人做事是否有严谨认真的态度,一堆错字也显得对对方不尊重。你连选个字的时间都没有,那别人为什么要花额外的时间去帮你呢!   回复  引用  查看    

#10楼  2008-07-12 08:26 布尔      

不光向未成谋面的高手请教问题,日常工作生活中也应该首先将自己的问题描述清楚,养成好习惯是很难的的   回复  引用  查看    

#11楼  2008-07-12 09:04 金色海洋(jyk)      

我觉得吧要讨论的问题都放在博问里面是不是更好了。

大家都可以看到,可以学习到,也避免了同一个问题,不同的人重复提问的情况。

问题解决后,最后给出一个解决方案,大家共享呀。   回复  引用  查看    

#12楼  2008-07-12 10:49 深圳电信梅沙会 [未注册用户]

如何转换成UIntPtr呀。

  回复  引用    

#13楼  2008-07-12 11:50 Windie Chai(笑煞天)      

只能说,深有同感。   回复  引用  查看    

#14楼  2008-07-12 12:24 张荣华      

嗯 以后有问题 一定以这样的方式提交     回复  引用  查看    

#15楼  2008-07-12 12:29 Clingingboy      

思考后才会问.大家都不知道对方的性格.出于礼貌,所以会谨慎.当然如果早些知道对方的性格,讨论方式则会不同.以讨论的形式与对方交流,如果没有好的解决方案也没关系,并不代表这个问题无法解决就什么水平不好之类的. 互相交流哈:)   回复  引用  查看    

#16楼  2008-07-12 21:27 Tony Zhou      

"请赐教",然后过招,哈哈哈哈   回复  引用  查看    

#17楼  2008-07-12 23:31 Yes!加菲猫      

认同这三点,老实讲,自己平时问问题,也会犯文中的错误,后来被我的头训斥说,你怎么只会问,不会自己想办法。自从那次训斥后,自己倾向也开始独立思考起来   回复  引用  查看    

导航

公告

<2008年7月>
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

统计

搜索

 

常用链接

留言簿(79)

我参加的小组

我参与的团队

随笔分类(174)

随笔档案(165)

友情链接

积分与排名

最新随笔

阅读排行榜