如何向前辈请教问题?

写在前面

本文是对张鑫旭某篇文章的总结,原文链接,不建议点,后果自负

一.发邮件

联系方式的选择非常重要,邮件不快捷,但很可靠,推荐采用邮件方式,事出紧急可以邮件 + 短信 + 电话,当然,后两个只是为了告诉ta你发了邮件

即时通讯工具是最坏的选择,比如QQ、微信,因为效率低,一两行字能说清楚的事情,放聊天工具上30分钟就没了

二.斟酌邮件内容

1.不要以废话开头

比如:“在不在啊?xxx技术你熟不熟啊?”、“你好,我可以问你一个问题吗?”

前辈的时间很宝贵,没空看废话

2.注意语气、口吻

比如,xi大大体:

你好,xxx,我在网上看到了您写的xxx,有些地方不太明白。您能否能我解答一下 请您收到后请回复 谢谢! 本人xxx (我的QQ:******* 希望您加我为好友)

乍一看好像合情合理,好像多少还有点尊敬的意思,可是语气听起来确实不舒服,不是吗?

3.清晰描述内容

比如:

你好,打扰了。我最近做什么什么,然后发现xx问题,你知道是怎么回事吗?

大哥,我现在遇到一个非常棘手的问题:xx怎么才能x……

更常见的:

您好!我在 xxx 看到您做的这个工具。 我把它使用在xx上,无法使用。 请问咋回事呢? 谢谢! [rar附件]

这样短信式的描述放在邮件里很不合适,我们应该按照一定思路顺序描述问题,例如:

  1. 问题的环境和背景

    问题一般和环境有很大关系,必须说明环境背景

  2. 遇到的问题现象描述(截图)

    必须把问题是什么说清楚,最好给出截图,看一眼图可能瞬间就知道出什么问题了

  3. 自己对问题的思考过程与看法

    问问题当然不能无脑问,应该尊重前辈的时间,而且描述思考过程有助于更清晰地说明问题

  4. 必要的关键源代码

    程序员问问题必须的,但注意不宜过长,最好标注出关键部分,并添上注释,因为前辈也会“太长不看”

  5. 在线与预览的Demo

    最最高效的方式,如果能在线复现问题的话,前辈就可以直接面对问题,理想状况是丢过去个链接(问题),10分钟后前辈回复了一个链接(解决方案),甚至不需要任何废话

4.邮件附件

尽量不要添附件,因为要下载 -> 解压 -> 打开才能看到,尽量用邮件正文描述清楚,代码还可以添上高亮

用zip格式压缩文件,不要用rar,因为MAC不能直接打开rar

5.一次性把问题说清楚

邮件的优势就在于没有寒暄、没有家常、没有xx。。。力求简单明了地用一封邮件说清楚问题,以便对方全面了解并给出解决方案

如果你来我往地扯个没完,邮件联系的优势就全没了

三.其他注意事项

1.时间

对方忙不忙?在不在上班?星期一会不会很烦?星期五会不会没空?

对方心情好自然会认真回复,不是吗?

2.标题

邮件标题很重要,尽量表现更多的信息,这样不用点开邮件就能知道一些情况,能够提高你的邮件在对方邮件列表中的重要性,引起对方的注意

3.力求简洁

还是因为“太长不看”,收到一封1000字的叙事散文你看吗,我反正不看

邮件切忌废话连篇找不到重点,对方可能都不知道该怎么回复

后话

之所以有这篇文章,主要是因为原文废话太多,比起zxx废话连篇的鑫空间,我更喜欢sf的前端观察

如何向前辈请教问题?》上有2条评论

  1. 李富荣

    杰哥您好,我是西北大学的一名大三的学生,说起来和您同班呢。看了您的文章顿觉茅塞顿开,在此有几个问题想要找您请教,不知道你忙不忙?在不在上班?星期一会不会很烦?星期五会不会没空? 好了,问题是: 1,如何认识这些前辈? 2,PlaneBlock何时带我飞? 3,北京的地铁是不是真的很挤? 4,做交互设计的话,在编程有哪些要求?

    回复
    1. ayqy 文章作者

      谢谢捧场啊,上班是肯定的,不然活不下去。周一到周五其实过得很快,没空烦恼。好了,有空好好叙叙旧啊

      1. 认识前辈很容易,搜着搜着就认识了,只要是同行,而且肯专注一个方向下功夫,那么早晚会认识的,因为越往前走圈子就越小。

      2. PlanBlock可以自己完成了吧,不是学了安卓吗?其实可以分文件夹,加上版本号v1.0, v1.1…(或者干脆使用git控制版本)一步步增强功能,一直做下去肯定能做成一个了不起的应用

      3. 北京地铁还好,早点(6:30)出去晚点(8:00)回来,不是很挤

      4. 交互设计对编程没什么要求,对美术方面的比较高的要求,要求快速地做出页面设计草图,按钮怎么摆放才最好用,要不要分tab,界面怎么设计才最符合本期产品主题,颜色怎么搭配才看起来比较舒服。。。要既能让开发线各部门的人员乐于接受,同时又要保证用户满意

        交互设计叫UE(或者UX),企业开发流程是产品(提出需求)->UE(做出界面草图)->UI(做出设计稿psd)->前端/客户端/服务端(分头实现)->测试(找bug)->上线

      UE压力比较大,需求很容易想出一大堆,而UE必须在短时间内确定草图(大家等着呢,UE做不完就都没法干活儿),服务端接口是根据UE来定的,在哪里显示哪些内容,有没有必要显示,这些都会影响工作进度和工作量

      【评论排版有点扯,先忍忍吧,建议审查元素看,稍微好点】

      回复

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*

code