Communicate! — Giao tiếp cũng quan trọng như code (Pragmatic Programmer #7)

Mở đầu

Mấy bạn ơi, mình lại lên đây tiếp nè! Hồi trước mình có nói là đang đọc cuốn "The Pragmatic Programmer" bản kỷ niệm 20 năm, và thấy nó hay quá trời nên muốn ghi lại cảm nhận từng topic một. Hôm nay tới topic số 7 rồi—cũng là bài cuối cùng của Chapter 1: A Pragmatic Philosophy. Chủ đề là Communicate! — giao tiếp đó mấy bạn.

Mà đừng nghĩ giao tiếp chỉ dành cho mấy tay sales hay manager nha. Lập trình viên tụi mình cũng gặp chuyện này mỗi ngày đó.

Ảnh: Lukas Blazek — Pexels

Topic 7. Communicate!

Nghe cái tựa là biết nói về gì rồi. Nhưng mình thích cách tác giả tiếp cận vấn đề—không dạy đao to búa lớn, mà đưa ra mấy nguyên tắc rất thực tế.

Tác giả mở đầu bằng câu: "Nếu bạn viết được code mã nguồn, viết document cũng không khó đâu." Nghe quen không mấy bạn—cái tâm lý "code là chính, giao tiếp là phụ" đó. Nhưng sự thật là dự án nào cũng cần teamwork, cần giải thích ý tưởng, cần thuyết phục người khác. Một ông lập trình viên giỏi mà không biết truyền đạt ý tưởng thì cũng như một nhạc sĩ tài ba nhưng không ai nghe nhạc ổng vậy.

Các nguyên tắc chính trong topic này:

1️⃣ Biết đối tượng của mình. Bạn đang nói chuyện với ai? Sếp? Đồng nghiệp? Khách hàng? Mỗi người cần một cách tiếp cận khác nhau. Sếp muốn biết timeline, khách hàng muốn biết giá trị, đồng nghiệp muốn biết technical details. Đừng trộn mấy cái đó với nhau.

2️⃣ Chọn thời điểm thích hợp. "A man is known by his questions rather than by his answers" — câu này hay quá trời. Biết khi nào nên nói, khi nào nên im lặng, khi nào nên đặt câu hỏi. Có cái gì đó muốn hỏi thì hỏi sớm, chứ đừng đợi tới cuối rồi mới hỏi.

3️⃣ Biết mình muốn nói gì. Trước khi gõ email hay ngồi vào họp, hãy phác qua outline trong đầu. Cái "tôi cần A để làm B vì lý do C" — kiểu vậy. Ngắn gọn, súc tích.

4️⃣ Làm đẹp. Một email có tiêu đề rõ ràng, một trang wiki có format đẹp, một slide trình bày gọn gàng—tất cả đều thể hiện sự chuyên nghiệp. Dân kỹ thuật tụi mình hay coi nhẹ chuyện hình thức, nhưng thực tế thì hình thức ảnh hưởng tới cách người ta cảm nhận nội dung đó.

5️⃣ Lắng nghe. Đây là cái quan trọng nhất nhưng cũng khó nhất. "Nếu bạn nói, bạn chỉ lặp lại những gì bạn biết. Nếu bạn lắng nghe, bạn học được điều mới." Nghe để hiểu người khác, không phải nghe để chuẩn bị phản bác.

Ảnh: Christina Morillo — Pexels

Cảm nhận của mình

Có một câu trong topic này mà mình nhớ hoài: "Invest in your communication skills—they're as important as your programming skills." Hồi mới đi làm, mình thấy cái này không đúng lắm. Lập trình viên thì cứ code thôi, ai cần giao tiếp gì ghê. Nhưng càng làm lâu, mình càng thấy tác giả nói đúng.

Những lúc khó khăn nhất của mình trong công việc—không phải lúc debug mấy cái bug khó nhằn, mà là lúc không hiểu ý nhau với đồng nghiệp, hoặc giải thích hoài mà sếp không hiểu tại sao task A mất nhiều thời gian hơn task B. Giao tiếp kém tạo ra nhiều vấn đề hơn là code dở đó mấy bạn.

Có lần mình nhận task fix bug gấp, xong xuôi rồi nhưng không nói với ai. Hai ngày sau team lead hỏi "sao cái bug đó chưa xử lý?"—toang! Mất công giải thích, mất lòng tin, mà lỗi tại mình không nói. Từ đó mình rút kinh nghiệm: không chỉ làm xong, mà còn phải báo xong.

Cũng nhờ cái topic này mà mình thay đổi cách viết email, cách đặt câu hỏi trong meeting. Đơn giản như có một template cho mỗi câu hỏi: "Mình muốn biết X, vì mình đang làm Y, và mình cần quyết định Z." Câu hỏi nào cũng theo format đó—ai nghe cũng hiểu, trả lời cũng nhanh.

Giờ thì mình thấy giao tiếp là một phần của nghề nghiệp rồi. Không thể tách rời được. Một developer giỏi giao tiếp còn giá trị hơn một developer siêu code nhưng không biết nói.

Ảnh: Kira auf der Heide — Pexels

Kết

Topic 7 khép lại Chapter 1 với một bài học rất nhân văn: code hay đến mấy cũng vô ích nếu bạn không thể giao tiếp với người khác. Làm việc nhóm là chuyện cả đời, và giao tiếp là kỹ năng sinh tồn.

Tới đây là hết Chapter 1 rồi nha mấy bạn. Chapter 2 sẽ bắt đầu với chủ đề mới — mình hóng quá chừng! Hẹn gặp lại mấy bạn ở bài sau nhe. 👋