Daily Productive Sharing 238 - Why Does Writing Matters in Work?
One helpful tip per day:)
(The English version follows)
技术公司和传统公司很不一样的一点就是内部的开放程度。Gergely Orosz 介绍了 Uber 在内部如何公开技术文档：
- 在开发前做规划；
- 把这个规划写成一个文档；
- 在开始工作之前，让别人批准这个规划；
- 将这份计划文件发给公司的所有工程师；
- 让每个人都遵循上述步骤，除非是非常小的项目；
这样做的好处之一就是所有人都有机会了解这些项目，如果有建议或者意见也可以提出，降低了项目间可能的冲突，也降低了重复造轮子的可能性。
我们陆续介绍了写工作文档的必要性，可以参考之前的分享：
Daily Productive Sharing 138 - 20210224
Daily Productive Sharing 114 - 20210121
如果你觉得今天分享有帮助，不妨把它分享给你的朋友
原链
Scaling Engineering Teams via RFCs: Writing Things Down
需要更棒的简历，不妨试试我们的 CV Consultation
如果你也想成为更高效的人，欢迎加入我们的 TG group
One of the things that technology companies differentiate from traditional companies is the internal openness, and Gergely Orosz describes how Uber makes technical documentation internally available:
- Do planning before building something new.
- Capture this plan in a short, written document.
- Have a few, select people approve this plan before starting work.
- Send this planning document out to all engineers in the company.
- Have everyone follow the above steps for every project that is beyond some super trivial complexity and iterate on a lightweight
One of the benefits of this is that everyone in the company has the opportunity to learn about these projects and to make suggestions or comments if they have any, reducing possible conflicts between projects and the possibility of duplication of building.
We have introduced the need to write working documents, and you can refer to the previous sharing:
Daily Productive Sharing 138 - 20210224
Daily Productive Sharing 114 - 20210121
If you find today's sharing helpful, why not share it with your friends?
Link
Scaling Engineering Teams via RFCs: Writing Things Down
Need a superb CV, please try our CV Consultation
Excerpt
It addresses not only issues on visibility or reducing tech/architecture debt, but also spreading knowledge and having engineers be more engaged day to day.
Writing and sharing that writing with others creates accountability.
Documentation is often seen as one of these time wasters, mostly because it is boring to do.
Once the plan is written-up, the surest way to make sure the people actually read the doc is to require them confirming just this - in writing, via e.g. a comment.
At the same time, there are a lot less project plans being sent out, even with an engineering size in the hundreds or thousands, than people typically expect.
Finally, allowing anyone and everyone to chime in is a key part of keeping a consistent engineering bar across the organization.
What started out as an email to every engineer changed into mailing lists per domain (backend, mobile, web) and templates built by engineers to help convey information in a more consistent matter.
People who review many engineering proposals often had the same type of questions. Questions like "What is the motivation to do this work?" or "How will this be tested?"_or "Will any archtiecture changes be made here?"_ were very common questions.
one of the things that will help engineering scale greatly is having a type of RFC process in place early on.