One helpful tip per day:)
(The English version follows)
技术公司和传统公司很不一样的一点就是内部的开放程度。Gergely Orosz 介绍了 Uber 在内部如何公开技术文档：
需要更棒的简历，不妨试试我们的 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:
If you find today's sharing helpful, why not share it with your friends?
Need a superb CV, please try our CV Consultation
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.