惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

D
DataBreaches.Net
量子位
博客园 - 三生石上(FineUI控件)
Hacker News - Newest:
Hacker News - Newest: "LLM"
月光博客
月光博客
博客园 - 叶小钗
爱范儿
爱范儿
S
SegmentFault 最新的问题
V2EX - 技术
V2EX - 技术
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Security Archives - TechRepublic
Security Archives - TechRepublic
小众软件
小众软件
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
S
Security @ Cisco Blogs
V
Visual Studio Blog
V
V2EX
Schneier on Security
Schneier on Security
Cloudbric
Cloudbric
有赞技术团队
有赞技术团队
C
Check Point Blog
T
Troy Hunt's Blog
Google DeepMind News
Google DeepMind News
Google DeepMind News
Google DeepMind News
TaoSecurity Blog
TaoSecurity Blog
Engineering at Meta
Engineering at Meta
Recent Commits to openclaw:main
Recent Commits to openclaw:main
S
Schneier on Security
N
Netflix TechBlog - Medium
Project Zero
Project Zero
Last Week in AI
Last Week in AI
N
News and Events Feed by Topic
Microsoft Azure Blog
Microsoft Azure Blog
NISL@THU
NISL@THU
T
The Exploit Database - CXSecurity.com
AWS News Blog
AWS News Blog
博客园 - 聂微东
S
Securelist
腾讯CDC
O
OpenAI News
H
Hackread – Cybersecurity News, Data Breaches, AI and More
A
About on SuperTechFans
Microsoft Security Blog
Microsoft Security Blog
B
Blog
博客园 - 【当耐特】
Y
Y Combinator Blog
N
News and Events Feed by Topic
Recorded Future
Recorded Future
Vercel News
Vercel News
PCI Perspectives
PCI Perspectives
Security Latest
Security Latest

Posts on WKLKEN THINKING

apisix 中的 lrucache apisix 中的服务发现机制 apisix 中的负载均衡 apisix etcd机制 聊聊框架 关于 k8s 的 zero downtime deployment 一些建议 apisix 遇到的一些问题 关于在除夕前一天换了一个洗衣机的故事 Django DRF 性能优化 DRF 的一些实践 Part1: Serializer DRF继承关系图 Better Code: 关于接口的灵活性 新的仓库: wklken/naming 缓存使用的一些经验 Better Code: 抽象: 可扩展性与可维护性的抉择 Better Code: 异常时, 该提示用户哪些信息? Better Code: 更好的异常日志打印 Go: some libs Go: go-redis/cache升级的坑 Go: logrus性能提升 Go: gin validation 远程办公的一点总结 Go: 开发过程中的一些bug 项目管理实践: 风险驱动开发 Go: 一种error wrap调用链处理方式 漫谈技术选型 Go: 基于 apitest 做handler层单元测试 Go: go-sql-driver interpolateparams参数优化 [分享]深度工作 你需要更多的思考时间 Django项目重构小结 工作七年小结: 学习,生活及其他 [分享]bash日常: bash-utils 极客时间推广海报 2017总结: 予时光以意义 k8s APIServer源码: api注册详细细节 k8s APIServer源码: api注册主体流程 k8s APIServer源码: 服务启动 k8s APIServer源码: go-restful框架 重构 - 读书笔记(Python示例) vim 杂谈 - 关于快速编辑 vim 杂谈 - 关于移动 读书笔记-重构: 章11 处理概括关系 读书笔记-重构: 章10 简化函数调用 读书笔记-重构: 章9 简化表达式 读书笔记-重构: 章8 重新组织数据 读书笔记-重构: 章7 在对象之间搬移特性 读书笔记-重构: 章6 重新组织函数 Python 代码规范小结 [分享]关于vim ElasticSearch集群部署文档 Logstash+ElasticSearch处理mysql慢查询日志 [分享]关于代码调试DE那些事 Logstash+ElasticSearch+Kibana- 实现相对通用的数据收集分析 ELK维护的一些点(二) [分享]Python源码剖析-数据结构 一些Centos Python生产环境的部署命令 摘录<<6个月学会任何一种外语>> ELK 维护的一些点 也许是一个新的开始 一些vim的个性化配置 读书笔记-调试九法 这段时间的一些想法 Python 源码阅读 - 垃圾回收机制 我为什么要写博客 APUE笔记-第一章 UNIX基础知识 Python源码阅读-闭包的实现 Python源码阅读-内存管理机制(二) Python源码阅读-内存管理机制(一) Python-基础-数据结构小结 '活动'设计的一些trick 一些简单的Python测试题 我的tmux配置及说明【k-tmux】 Review and Restart 工作四周年小结 vim插件: surround & repeat[成对符号编辑] vim插件: gundo[时光机] vim插件: expand-region[区域选中] vim插件: quickrun[快速执行] vim插件: trailing-whitespace[行尾空格处理] vim插件: closetag[成对标签补全] vim插件: ctrlp[文件搜索] vim插件: airline[状态栏增强] vim插件: theme[主题] vim插件: tagbar[大纲式导航] vim插件: nerdcommenter[快速注释] vim插件: rainbow_parentheses[括号高亮] vim插件: syntastic[语法检查] vim插件: delimitmate[符号自动补全] vim插件: matchit[成对标签跳转] vim插件: easy-align[快速对齐] vim插件: multiple-cursors[多光标操作] vim插件: vim-signature[快速标记跳转] vim插件: easymotion[快速跳转] vim插件: vundle[管理插件] Elasticsearch几个问题的解决 分享一份 Vim 简介PPT k-vim 更新9.0版本 关于知识管理工具的思考 Logstash+ElasticSearch+Kibana处理nginx访问日志
写给新人的沟通建议
2017-04-09 · via Posts on WKLKEN THINKING

最近也碰上抄袭的号, 转了我几年前两个文章, 只改了标题, 然后删掉每篇文章中我个人的一两段吐槽, 然后发出来. 抄袭当原创, 然后在评论里以作者的角度回复别人, 看着有点恶心. 这种成本还是太低了, 举报两次, 知乎给删掉了, 但是对于我来说还是很不爽的, 举报的成本太高了, 来一篇举报一篇. 这个号下面的文章(入口), 目测都是直接用别人的文章改个标题了事.


很多年前写过一篇在自己博客里面, 后端不高兴——关于协作和沟通, 做后端的同学可以看看吐槽哈.

工作也好多年了, 前前后后跟不少新人合作过, 实际合作中不免各种问题, 都是从新人过来的, 所以打算写一些点, 算是一些感受吧

关于问题描述

好像之前有人也讲过.

不要发: hi, 在吗, 你可能会发现过了很久对方回复:, 然后你可能也没立即接下一句, 晚一会回复:xxxx问题, 然后对方又隔了很长一段时间才回….如此来来往往, 一次沟通跨度从一两个小时到好几天

一般新人会觉得心累, 有点玻璃心的会觉得委屈, 如果事情紧急, 光自己干着急了.

其实老鸟也很累, 一般事情比较多, 各种事情混在一起, 面对这种类型沟通, 无法获取足够多的信息, 自然无法快速解决. 其实心里也想事情快速处理掉.

这种有点类似打乒乓球的沟通方式是不对的. 每次没有提供足够的信息, 而又期待对方快速反馈, 然而每个人都有自己忙碌的事情, 势必导致这类沟通十分之低效.

正确的沟通方式应该是: 倾倒式的沟通.

hi xxxx:
我是xxxxx
目前遇到一个问题
现象
数据
结果

这个问题是xxxxxx?

而对方在看到你的消息后, 一次性就可以全面了解你的问题, 了然于胸, 很快就能解决问题.

而区别是: 一次传达的有效信息量.

如何问题

建议不管是新手还是老鸟, 都读一读 提问的智慧

实际上, 有些时候某些问题看起来十分的无奈

- 系统挂了       -- 一脸懵逼, 什么系统
- 接口返回错误   -- excuse me? 哪个接口? 给的参数是? 返回结果/状态码是?
- 页面有点问题   -- 哪个页面? 什么问题?

......

很是无奈, 很多问题看起来言简意赅, 但是蛋疼的也是这个, 缺乏信息量, 缺乏对问题的准确描述, 往往站在信息接收人的角度是: 一脸懵逼. 然后, 就开始来来往往的沟通

所以: 如何准确描述问题, 算是提问的基本要求了

基础问题不要问

基础问题, 例如某些库的方法/参数, http状态码, 某个异常堆栈信息.

很多时候, 拿这类问题去问别人, 是十分低效且有害的!

因为: 这个时代, 搜索引擎这么强大, 技术资料如此丰富, 各类社区如此多前人踩坑, 团队的wiki如此完善, 你还拿一个如此基础的问题去问别人, 似乎说不过去吧.

只要是搜索引擎能回答的就别问别人……

也不是说不能问, 但是前提是, 自己搜索无果, 无法解决的情况下.(google, 且会基本搜索技巧)

这类问题, 看起来很简单是吧, 对其他人也许也就一句话的事情, 但是, 这样造成不好的结果是, 对方被你打断了! 无论多短暂, 都是打断, 断点-思考-回答-回到断点.

因为回答你一个本可以自己解决的问题, 而手头正在做的事情被打断.

而这个, 对效率影响是非常大的.

所以, 忠告: 不要把同事当做搜索引擎, 尊重对方.

遇到问题, 先从自己查起

很多人遇到问题后, 第一意识是, 我的代码是ok的, 你的接口有问题.

然后, 直接抛给对方(对方大写懵逼)

而此时, 对方心里肯定第一意识也是: 我的代码是ok的, 一定不是我的问题. 此时心态上会有些变化, 然后去确认接口是不是有问题, 如果有问题也就罢了, 没问题会反向再反馈回来, 自己排查.

而很多时候, 要么没看文档, 没配host, 配错host, 环境不对, 没有遵循协议, 参数传错等等一系列自己代码的低级错误导致的.

也许这都是小事, 但当次数多了, 而大多数问题不是对方问题时, 你的信誉点已经降到了最低, 你的任何问题反馈, 无形中会被降级.

想象一下, 有人说你接口有问题, 然后你确认服务没问题(几分钟), 找对方要参数数据复现没问题(十几分钟), 然后到对方电脑查问题(几分钟), 一折腾半个多小时没了. 最后发现是一个低级问题(例如没配host), 你心里…..

所以, 先确认错误, 排查下是否是自己的问题

不要胡乱猜测, 拿数据说话

接上个问题, 当你认为别人系统有问题时, 请拿数据说话. 当别人认为你系统有问题的时候, 请对方提供数据.

发现自己在跟人沟通时, 问的最多的问题是: 把调用的接口/参数/返回值/状态码/日志等等, 发给我, 谢谢.

发现有问题, 不要猜, 代码是确定的, 查就是了.

当看到报错, 从上往下查, 一层层向下跟踪, 确认输入/输出/异常/状态码等. 学会追踪调用是必备技能.

有足够的数据才能断定是哪的问题

如果是自己的问题, 修正.

如果是别人的问题, 拿着数据, 也方便别人定位问题.

特别忌讳的是: 没有数据的情况下, 猜测, 然后把问题抛出去了, 会造成组织效率低下, 可能你一个小小猜测, 花费别人很多时间. 每个人的时间都需要尊重.

该问就问, 不要害怕打断

基于上面的几点, 假设问题自己没法解决, 需要求助, 那就求助吧.

不要害怕打扰别人, 一般程序员都很nice, 有问题, 把问题准备好, 精确描述, 自己的尝试, 目前遇到的点等等, 将信息汇聚, 一次性问, 然后直接去问.

紧急请当面, 次紧急用电话, 不大紧急, 可以用IM 工具, 对方实在忙, 可以先约个时间.

小结

学会基本的沟通技巧, 善用之, 同时, 尊重他人的时间, 他人也会尊重你的时间.