Cách xây dựng cơ sở kiến thức phát triển trước công việc tiếp theo của bạn

Chú ý: Đây không phải là quảng cáo cho Obsidian.

Quá trình làm quen với một công ty mới là công việc khó khăn. Việc giữ cho tất cả thông tin được sắp xếp là một luồng công việc riêng biệt đáng xem xét và chú ý. Vô số tên, khuôn mặt*, nhóm, sáng kiến và viết tắt xuất hiện trước buổi trưa. Tin tôi đi. Hiện tôi đang trong quá trình này. Tuần này, tôi đã tìm ra một hệ thống mà tôi cảm thấy khá hài lòng.

Bạn là một nhân viên tri thức. Hãy xây dựng một cơ sở kiến thức

Bạn cần một nơi để đặt tất cả thông tin bạn đang nhận được. Đây là một số nội dung tôi đang nói đến:

• Người
• Nhóm
• Kho lưu trữ
• Mối quan hệ giữa các nhóm, kho lưu trữ, người, v.v.
• Sáng kiến
• Sản phẩm công việc và nhiệm vụ của bạn
• “Playbooks” cho các nhiệm vụ phổ biến
• Lịch hàng ngày
• Ghi chú cuộc họp
• Ý tưởng
• Câu hỏi bạn cần hỏi ai đó

Tôi khuyến nghị sử dụng Obsidian. Nó về cơ bản là một trình soạn thảo markdown - nhưng nó là nhiều hơn thế. Nó là mã nguồn mở. Nó hoạt động dựa trên hệ thống tệp địa phương của bạn - không có vấn đề về quyền riêng tư dựa trên đám mây. Nó khuyến khích bạn tạo ra một mạng kiến thức dày đặc với nhiều liên kết và thẻ. Nó cũng có một bộ các plugin chính thức và plugin cộng đồng phong phú.

Gieo hạt giống

Bắt đầu từ một thư mục trống có thể làm cho bạn cảm thấy khá lo lắng. Nhưng bạn không cần phải xây dựng cơ sở kiến thức của mình bằng tay. Hãy thử gieo hạt từ các nguồn dữ liệu có sẵn.

Wiki kỹ thuật

Có một wiki kỹ thuật trên GitHub của tổ chức bạn không? Sao chép nó và đổ trực tiếp vào thư mục Obsidian của bạn. Bây giờ bạn có hàng nghìn trang thay vì một bảng trắng.

Bạn là chuyên gia hàng đầu của công ty về quá trình làm quen. Không ai khác nhớ được nó như thế nào khi làm quen, và đặc biệt là nếu họ làm quen cách đây lâu rồi, trải nghiệm có thể khác biệt rất nhiều bây giờ. Bạn có thể sử dụng quan điểm của mình để làm cho trải nghiệm làm quen của người thuê mới tốt hơn. Đóng góp vào wiki khi bạn đang làm quen. Làm cho nó ít rối bời hơn.

Tôi khuyến nghị kiểm tra một nhánh của repo để mọi thay đổi bạn thực hiện có thể được tạo thành PR. Một thay đổi rất dễ dàng mà thêm rất nhiều giá trị là thêm siêu liên kết. Thường có một trang mô tả điều gì đó mà không có bất kỳ liên kết nào đến nó. Siêu liên kết là một công cụ khám phá tốt hơn so với grep, vì vậy hãy thêm chúng.

Kho Github

Thêm một tệp markdown trong cơ sở kiến thức của bạn cho mỗi kho tại tổ chức của bạn. Nếu bạn sử dụng GitHub, hãy tải GitHub CLI. Từ đó, bạn có thể tạo ra một tệp JSON của 'n' kho hàng đầu tại tổ chức của bạn... nếu có thể, có lẽ chỉ cần tất cả chúng. Chúng được sắp xếp theo commit gần đây nhất.

$ gh repo list [tên tổ chức của bạn] --limit 1000 --json name,description,createdAt,updatedAt`) > kho-repos-của-bạn.json

Tôi đã viết một đoạn mã node nhỏ để tạo các tệp markdown.

const { writeFileSync } = require('fs');
const repos = require('./kho-repos-của-bạn.json');

const đường dẫn đến Obsidian = '...';

function renderMarkdown(repo) {
	return `# [${repo.name}](https://github.com/tên-tổ-chức-của-bạn/${repo.name})
	
  >> bất cứ điều gì bạn muốn ở đây, mô tả là tốt...<<`;
}

for (const repo of repos) {
	writeFileSync(
	  `${đường dẫn đến Obsidian}/repos/${repo.name}.md`, 
	  renderMarkdown(repo)
  );
}

Người và đội ngũ

Việc làm cho cái này trở nên chung chung hơn khó hơn. Tại công việc mới, tôi tìm thấy một danh sách khá tốt của tổ chức kỹ thuật trong Google Groups, sao chép bảng html từ trình duyệt vào Google Sheets, sau đó xuất thành CSV. Nguồn thông tin chính của bạn có thể là Slack, GitHub Teams hoặc một cái gì đó hoàn toàn khác. Bạn cũng có thể thêm người bằng cách thủ công.

Theo dõi phiên bản

Sử dụng git. Git init trong thư mục Obsidian của bạn. Chúng ta sử dụng git cho mọi thứ khác, tại sao không sử dụng cho cơ sở kiến thức của chúng ta? Commit vào cuối mỗi ngày và nhìn vào sự khác biệt. Viết một thông điệp commit thực sự. Đừng lo lắng về độ dài. Với tôi, nó chứa một tóm tắt tốt hơn về ngày của tôi so với bất kỳ nơi nào khác.
$ git log giờ đây là một cách khá tốt để xem bạn đã làm gì trong một tuần.

Chỉ cần đảm bảo bạn có một tệp .gitignore. Trong trường hợp của tôi, tôi bỏ qua thư mục eng-wiki của mình để tôi không phải làm việc với git submodules.

Sơ đồ

Một bức tranh có giá trị 1000 từ. Đây là cách tôi vẽ tranh.

Excalidraw

Có một plugin Excalidraw cho Obsidian (cảm ơn @zsviczian!). Tôi đã viết về tôi thích Excalidraw đến mức nào. Việc Obsidian có thể tích hợp một cách tinh tế với Excalidraw là tuyệt vời. Khi tôi nói về tinh tế, tôi có nghĩa là nó. Bạn có thể liên kết từ bên trong sơ đồ đến các trang trong cơ sở kiến thức của bạn. Bạn có thể nhúng. Nó tuyệt vời.

Mermaid

Excalidraw là một công cụ vẽ sơ đồ đa năng tuyệt vời. Nhưng, đối với các sơ đồ có cấu trúc cao, Mermaid đôi khi tốt hơn. Obsidian có hỗ trợ tự nhiên cho các sơ đồ Mermaid. Chỉ cần tạo một khối mã được chú thích là 'mermaid'.

Dưới đây là một ví dụ từ tài liệu của họ.

flowchart TD
  A[Bắt đầu] --> B{Đúng không?};
  B -- Có --> C[OK];
  C --> D[Nghĩ lại];
  D --> B;
  B -- Không ----> E[Kết thúc];

Câu hỏi

Mỗi ngày sẽ xuất hiện 1,000,000 câu hỏi. Đôi khi bạn sẽ không có thời gian để hỏi chúng. Một số câu hỏi bạn có thể tra cứu. Tôi khuyên tạo một hệ thống cho chúng. Tôi đã tạo một trang câu hỏi trung tâm. Khi có vấn đề xuất hiện trên các trang khác, tôi liên kết đến trang câu hỏi của mình. Như vậy, khi tôi muốn xem lại các câu hỏi chưa giải đáp, tôi có thể xem tất cả các liên kết ngược. Nhãn cũng có hiệu quả.

Mỗi ngày xem xét các câu hỏi chưa giải đáp. Lục qua wiki công ty hoặc các nguồn thông tin khác. Nếu bạn tìm thấy câu trả lời, cập nhật liên kết từ [[question]] thành [[answered-question]] và bao gồm câu trả lời với bất kỳ siêu liên kết nào đến nội dung hiện tại trong cơ sở kiến thức. Ví dụ: [[answered-question]] giao thức mở PR vào kho chứa của các nhóm khác? Trả lời: [[eng-wiki/code-review-process]] đề cập đến điều này.

Đối với những câu hỏi bạn không thể trả lời được, lọc chúng chỉ là những câu hỏi quan trọng và đội của bạn có thể trả lời được, và gửi chúng trên Slack hàng loạt, mỗi ngày. Hãy đảm bảo rằng các câu trả lời trở lại cơ sở kiến thức của bạn.

Ghi chú hàng ngày

Obsidian có một tiện ích ghi chú hàng ngày rất hữu ích. Đầu tiên vào buổi sáng, tôi tạo một ghi chú hàng ngày, nhập lịch trình của mình từ Google Calendar (liên kết đến tất cả mọi người tôi sẽ gặp). Tôi luôn bao gồm một phần 'meta' để quan sát về cách hệ thống phục vụ cho tôi. Tôi cũng khuyến nghị tạo liên kết đến ngày kế tiếp và ngày trước đó.

Tôi thấy rằng ghi chú hàng ngày thường tích luỹ rất nhiều nội dung ngẫu nhiên xuất hiện trong ngày. Dành một chút thời gian để tự hỏi liệu nội dung trên trang ghi chú hàng ngày có nên được chuyển đến vị trí khác không.

Tickets

Ít nhất là ở giai đoạn đầu, mọi công việc bạn được giao trong quản lý sản phẩm của bạn cũng có thể được theo dõi trong hệ thống ghi chú cá nhân của bạn. Điều này cho phép bạn liên kết đến tài liệu liên quan, ghi chú, viết bản cập nhật trạng thái, đặt câu hỏi, vẽ sơ đồ, v.v.

Thư mục tickets của tôi không phẳng. Của tôi trông như thế này:

tickets
├── closed
│   ├── POP-696.md
│   └── POP-698.md
└── open
    └── POP-700.md

Sự phân biệt giữa việc mở và đóng cửa sổ giúp tại buổi họp nhóm khi bạn muốn nói cho đội của bạn biết nhiệm vụ đang diễn ra như thế nào.

Nhiều công việc bạn hoàn thành khi bạn mới vào công việc có phần làm theo quy trình. Bạn không phải làm lại trang chủ trong tuần đầu tiên. Đối với những công việc lặp lại này, liệu có tài liệu hướng dẫn tốt về cách thực hiện không? Có lẽ không. Hãy tạo một cuốn sách hướng dẫn. Nó sẽ làm cho việc thực hiện lần sau dễ dàng hơn. Nếu cuốn sách hướng dẫn của bạn mô tả điều gì đó ngoài bạn và nhóm của bạn, hãy thêm vào wiki toàn bộ eng.

Retros, viết tự do và tổng hợp

Nếu nhóm của bạn thực hiện retros, tôi khuyên bạn nên lên lịch một thời gian trước để viết tự do. Ngay cả khi nhóm của bạn không có truyền thống retros, lên lịch một thời gian để tự do phản ánh là một ý tưởng tuyệt vời - nó khuyến khích tổng hợp, kết nối và hiểu biết.

Hãy xem đó là một phần của mô tả công việc của bạn để giảm thiểu cảm nhận của môi trường. Sau khi bạn hiểu rõ quy luật phức tạp của tổ chức bạn, bạn có thể giải mã nó, hoặc ít nhất giảm tốc độ làm mớ của nó. Bạn có thể nghĩ ra các ví dụ, sơ đồ, kết nối - bất cứ điều gì làm cho hệ thống phù hợp vào đầu óc tốt hơn - bạn sẽ thêm giá trị to lớn. Đây là một bài viết tuyệt vời về ý tưởng chung này khi áp dụng cho người nghiên cứu. Họ gọi nó là nợ nghiên cứu. Tôi nghĩ về nó như là nợ ngữ nghĩa hoặc nợ nhận thức. Viết phản ánh là một cách tốt để chuẩn bị tâm trạng của bạn cho sự tổng hợp.

Khi bạn viết theo cách phản ánh. Đừng lo lắng về định dạng và liên kết trong khi bạn viết tự do, nó có thể làm cản trở sự luồng. Sau khi bạn hoàn thành, xem xét xem có liên kết để thêm vào hoặc định dạng để áp dụng không.

*Không giúp được gì cả khi tôi bị mù mặt!

Bài viết này từ Off-by-one là một dòng suy nghĩ về máy tính. Tác giả, Zeke Nierenberg, viết về lập trình, giáo dục, công cụ tư duy kỹ thuật, và phát triển sản phẩm. Tìm bài viết gốc tại đây.