Đây là bài mình dịch lại 100% từ bài gốc của tác giả trên Medium vì nó thật sự rất hay và sát thực tế, nên mình xin phép giữ nguyên ngôi xưng của tác giả, link bài gốc mình sẽ để ở cuối bài để các bạn tiện tham khảo nha.

1. Cuộc họp System Design Review

Tuần trước, trong một buổi họp design review, tôi đã chứng kiến một điều khiến tôi phải suy nghĩ lại toàn bộ về ý nghĩa thực sự của chữ “senior” trong vai trò kỹ sư.

Jake, lead architect của đội, trình bày một thiết kế kiến trúc microservices khá phức tạp, đầy những sơ đồ rối rắm và thuật ngữ kỹ thuật cao cấp. Ai cũng chăm chú lắng nghe và gật đầu, dường như đồng thuận với hướng đi mà Jake đưa ra.

Bất ngờ, Sarah — một principal engineer lên tiếng “Em cảm ơn anh đã trình bày rất rõ ràng,” “nhưng em đang băn khoăn về cơ sở dữ liệu cho service mới này. Liệu chúng ta có thực sự cần một instance riêng không? Service người dùng hiện tại vốn đã xử lý dữ liệu tương tự rồi. Liệu mình có thể tận dụng và mở rộng nó để đáp ứng những tính năng mới này không?”

Jake hơi ngạc nhiên, lập tức giải thích về lý do tại sao một database riêng sẽ tốt hơn khi hệ thống cần mở rộng sau này.

Sarah vẫn kiên nhẫn lắng nghe. Khi Jake trình bày xong, cô tiếp lời, “Em hiểu vấn đề về khả năng mở rộng, nhưng việc tạo thêm một database mới sẽ khiến chi phí vận hành, bảo trì và độ phức tạp của hạ tầng tăng lên đáng kể. Trong khi đó, service hiện tại của mình đã rất ổn định và được kiểm chứng qua thực tế. Nếu tận dụng nó, chúng ta vừa có thể triển khai nhanh hơn, vừa giảm được nhiều rủi ro.”

Cuộc tranh luận trở nên sôi nổi, và tôi nhận ra rằng Sarah không chỉ đặt câu hỏi về giải pháp kỹ thuật, mà cô ấy còn liên tục kết nối chúng với các yếu tố tổng thể:

• Chi phí: Một database mới đồng nghĩa với các khoản phí bổ sung cho license, server, vận hành.

• Tốc độ: Tận dụng nền tảng hiện có giúp đưa sản phẩm ra thị trường nhanh chóng.

• Rủi ro: Chọn một giải pháp đã được kiểm chứng giúp giảm thiểu những rủi ro không đáng có.

• Tác động sản phẩm: Các đề xuất kỹ thuật luôn gắn liền với mục tiêu kinh doanh chung.

Sau cùng, cả nhóm đã quyết định xem xét nghiêm túc đề xuất của Sarah bằng một thử nghiệm benchmark nhỏ, và kết quả cho thấy database hiện tại hoàn toàn đáp ứng được các yêu cầu mới. Quyết định này đã giúp công ty tiết kiệm hàng ngàn đô la cùng nhiều tuần phát triển.

2. Sự khác biệt từ câu hỏi "Tại sao?"

Các junior và mid-level engineer thường tập trung vào việc “làm thế nào”. Làm thế nào để chúng ta xây dựng feature này? Làm thế nào để chúng ta sửa bug này?

Các senior engineer thì ngược lại, họ bắt đầu với câu hỏi “tại sao”.

• Tại sao chúng ta lại xây dựng feature này?

• Nó giải quyết vấn đề gì cho người dùng?

• Nó phù hợp như thế nào với các mục tiêu chiến lược của công ty?

Việc đặt ra những câu hỏi này giúp các senior engineer không chỉ đảm bảo làm đúng kỹ thuật, mà quan trọng hơn, còn chắc chắn rằng đội ngũ đang xây dựng đúng thứ doanh nghiệp/tổ chức thực sự cần.

3. Cách áp dụng tư duy này

• Nắm rõ bức tranh toàn cảnh: Trước mỗi buổi họp, bạn hãy dành thời gian tìm hiểu kỹ về mục tiêu của dự án. Chủ động trao đổi với product manager và đọc các tài liệu liên quan đến yêu cầu sản phẩm để hiểu sâu hơn.

• Suy nghĩ vượt ra ngoài phạm vi code: Khi đưa ra quyết định kỹ thuật, hãy cân nhắc đến những tác động của chúng đối với việc triển khai, giám sát hệ thống, khả năng mở rộng cũng như trải nghiệm của người dùng cuối.

• Ước lượng sự đánh đổi: Khi đề xuất một giải pháp, hãy chuẩn bị lý giải rõ ràng về các lợi ích và chi phí. Thay vì chỉ nhận định “giải pháp A tốt hơn”, hãy cụ thể như: “giải pháp A giúp chúng ta ra mắt sản phẩm sớm hơn hai tuần, nhưng sẽ làm tăng chi phí hạ tầng khoảng 10%”.

• Sẵn sàng đặt câu hỏi: Hãy mạnh dạn trao đổi, thảo luận, kể cả khi các quyết định đó đến từ lead architect, với thái độ tôn trọng. Mục tiêu cuối cùng là tìm ra giải pháp tối ưu nhất cho công ty, chứ không phải chỉ đơn giản là đồng ý với mọi lựa chọn.

4. Kết luận

Việc trở thành một senior engineer thực sự không chỉ nằm ở chức danh bạn được giao, mà là kết quả của tư duy, cách tiếp cận công việc mà bạn rèn luyện mỗi ngày. Khi bạn chủ động đặt ra câu hỏi “tại sao” và luôn ý thức về những ảnh hưởng mà các quyết định kỹ thuật mang lại cho hoạt động kinh doanh của công ty, bạn không chỉ nâng cao chuyên môn của bản thân mà còn đóng vai trò quan trọng, góp phần tạo ra giá trị lớn cho tổ chức.

Reference: Medium