Hãy nhớ lại khi bạn bắt đầu công việc viết code của mình, như thế nào nhỉ?
Chắc chắn là: số lượng những điều mới mẻ cần phải học thật sự choáng ngợp, bạn cảm thấy đuối, lịch của bạn hoàn toàn mở và trống trải sau tuần đầu tiên làm việc. Nhưng phần tuyệt vời nhất khi bắt đầu một công việc mới vẫn là khi bạn thực sự bắt tay vào làm việc.
Cuộc sống thật tuyệt, khi bạn là người mới
Hãy tưởng tượng một ngày làm việc điển hình của một thành viên mới trong nhóm:
10:00 - họp
10:15 - xử lý ticket
11:00 - trò chuyện nhanh để đặt câu hỏi
11:15 - xử lý ticket
12:00 - ăn trưa
12:30 - xử lý ticket
15:00 - đánh giá các PR (pull request)
15:30 - giải lao
16:00 - xử lý ticket
18:00 - xong việc
Với 8 tiếng làm việc, 30 phút họp, 30 phút PR, hàng đống code.
Một người quản lý giỏi sẽ đưa bạn vào một dự án dài. Đó là cách tốt nhất để học.
Khi nhận một dự án lớn và thực hiện nó, bạn sẽ có cơ hội khám phá hệ thống, tìm hiểu cách các phần hoạt động cùng nhau, và sẽ có một chuỗi chung để hướng dẫn bạn.
Các junior engineer mới sẽ bắt đầu làm việc trên các phần của cùng một dự án lớn trong nhiều tuần và nhiều tháng, còn các senior software engineer mới làm toàn bộ.
Cả hai đều có vai trò riêng của mình.
Khi bạn đã cứng cáp
Bây giờ, hãy tưởng tượng một ngày điển hình đối với một engineer dày dạn kinh nghiệm
10:00 - họp
10:15 - bỏ chặn giúp đồng nghiệp
10:30 - gặp Product Manager (PM)
11:00 - trò chuyện nhanh để trả lời câu hỏi của đồng nghiệp
11:15 - trả lời câu hỏi về tiến độ của PM
11:30 - review code
12:00 - ăn trưa
12:30 - chào mừng thành viên mới vào nhóm (1-1)
13:00 - đọc 5 chủ đề Slack
13:30 - giải quyết lỗi trên production
13:45 - bỏ chặn giúp đồng nghiệp
14:00 - gặp Head Of Engineering
14:30 - viết thông số kỹ thuật cho dự án tháng tới
15:00 - trò chuyện nhanh với PM để làm rõ vài việc
15:15 - tiếp tục viết thông số kỹ thuật
15:45 - bỏ chặn giúp đồng nghiệp
16:00 - xử lý ticket
16:15 - thông báo trong kênh #bugs
16:20 - xử lý ticket
17:50 - bắt kịp các chủ đề Slack
18:15 - xong việc
Với 8 tiếng làm việc, 2 giờ 45 phút họp, 45 phút viết lên đặc tả kỹ thuật và một giờ viết code. Không bao giờ có quá 30 phút thời gian tập trung “làm cho xong” cái gì đó.
Đấy, và đó là lý do tại sao các senior software engineer chẳng làm được gì. Họ có quá nhiều kinh nghiệm và biết quá nhiều (quyền lực/khả năng càng lớn, trách nhiệm càng cao). Hay nói cách khác, ngoài chăm chăm vào phần việc của riêng mình, họ còn phải “chịu trách nhiệm” cho phần việc của các kỹ sư phần mềm (đặc biệt là các bạn junior) trong nhóm.
Mọi thứ sẽ diễn ra với bạn như thế nào
Bạn bắt đầu với việc viết code và mang đến kết quả tuyệt vời, bạn thực sự là một “tay chơi” và mọi người đều yêu quý bạn!
Nhưng sau đó, mọi code của bạn đều xuất hiện lỗi ở trên production.
Code nào cũng có bug thôi, thực sự đấy, hãy bình tĩnh và tiếp tục.
Làm chủ sở hữu thì tốn thời gian đấy
Là một kỹ sư phần mềm chuyên nghiệp, bạn duy trì code này, bạn là chủ sở hữu (owner) của nó.
Khi một lỗi xảy ra trên production, bạn sẽ xem xét nó. Bạn tìm ra ai tốt nhất có thể giải quyết nó. Có thể là bạn, có thể là hệ thống thượng nguồn hoặc hạ nguồn, và bạn phải đảm bảo rằng lỗi sẽ được sửa.
Điều đó có nghĩa là bạn chịu trách nhiệm giao tiếp với bất kỳ ai đã gây ra lỗi. Cho họ biết bạn đã thấy lỗi, sẽ thông báo họ khi lỗi được sửa, và đưa ra giải pháp thay thế ngay bây giờ.
Tăng cường thúc đẩy thì tốn thời gian đấy
Khi kiến thức của bạn về hệ thống ngày càng tăng, công việc của bạn sẽ chuyển từ công việc viết code sang việc tăng cường thúc đẩy các thành viên khác. Nói cách khác, bạn có thể giúp người khác giải quyết công việc nhanh hơn.
Ví dụ, khi Trang gặp vấn đề, hoặc là cô ấy sẽ dành 03 giờ trên Google để tìm giải pháp hoặc chỉ 05 phút để hỏi bạn. Khi Nghĩa không thể hiểu một mô-đun, hoặc là anh ấy sẽ dành cả một ngày để tìm hiểu code hoặc chỉ cần 05 phút để hỏi bạn.
20 phút của bạn sẽ tiết kiệm 7 tiếng đồng hồ cho nhóm.
Công ty của bạn sẽ đánh đổi điều đó mỗi ngày, bằng cách nhờ vào 40 đô la thời gian đắt đỏ của bạn để cứu lấy 420 đô la thời gian của mọi người.
Hãy chắc chắn rằng sếp của bạn hiểu và coi trọng công việc tăng cường thúc đẩy của bạn!
Rất nhiều senior software engineer đã dành nhiều tâm huyết cho vấn đề này, nhưng tiếc thay chỉ có việc viết code là được trân trọng (Và điều đó chẳng công bằng tí nào!).
Vậy, bạn có thể làm gì để bảo vệ thời gian viết code của mình
Đừng trở thành kẻ không bao giờ trả lời câu hỏi hay giúp đỡ nhóm của mình! Nhưng để bảo vệ thời gian viết code của cá nhân, bạn có thể sử dụng hai chiến lược được áp dụng rộng rãi sau:
- Lên khung thời gian (timeboxing)
- Tối ưu hóa
Lên khung thời gian
Lên khung thời gian là chiến lược tự đặt lịch cho các loại nhiệm vụ cụ thể (block hẳn trên lịch của hệ thống).
Ví dụ, bạn có một cuộc họp với chính bản thân vào mỗi buổi chiều. 3 giờ chiều đến 6 giờ chiều là thời gian viết code. Lịch của bạn trên hệ thống sẽ hiển thị “busy” và mọi người sẽ không lên lịch cuộc họp nào với bạn khi thấy vậy. Khi bạn thực sự có các cuộc họp, hãy lên lịch tất cả chúng vào cùng một thời điểm trong mọi ngày. Khoảng thời gian 15 phút giữa 2 cuộc họp quả thật rất… khó sử dụng. Quá dài để lãng phí và quá ngắn để làm bất cứ điều gì.
Tương tự với Slack và email. Hãy dành một khoảng thời gian nhất định trong ngày để kiểm tra và trả lời mọi thứ trong 15 phút. Dù điều này có vẻ khó làm nhưng nó thực sự hữu ích. Cài đặt thông báo của các ứng dụng trò chuyện nhóm chỉ báo khi bạn được đề cập hoặc nhắn trực tiếp. Đó là cách bạn giữ bình tĩnh. Xóa tất cả các thông báo khác. Giữ máy tính của bạn ở chế độ "DoNotDisturb".
Bạn càng nhận được ít thông báo, bạn càng dễ dàng bỏ qua mọi thứ cho đến lúc dành riêng cho việc trả lời các câu hỏi.
Đừng mong đợi những câu trả lời ngay lập tức, không trả lời ngay lập tức. Cứ để các thắc mắc dồn lại nếu có thể.
Tối ưu hóa
Làm thế nào bạn có thể trả lời nhiều câu hỏi nhanh hơn?
Đó là dựa vào tài liệu.
Không ai đọc tài liệu phải không? Lỗi thời, khó tìm, không thể hiểu nếu không có ngữ cảnh. Tốt hơn hết là hỏi.
Đây là những gì bạn sẽ làm:
1. Ai đó đặt câu hỏi
2. Trả lời
3. Dành 5 phút để viết ra câu trả lời của bạn
4. Chia sẻ công khai
Lần tới khi bạn nhận được câu hỏi tương tự, hãy làm như sau:
1. Tìm câu trả lời của bạn
2. Dành 30 giây để xác thực nó đúng
3. Gửi liên kết
Theo thời gian, mọi người sẽ học cách kiểm tra tài liệu trước. Nếu không, bạn đang tiết kiệm thời gian bằng cách chia sẻ các câu trả lời đã được đóng gói sẵn.
Việc lưu câu trả lời cho câu hỏi của bạn cũng thực sự có ích. 6 tháng kể từ bây giờ, bạn sẽ không nhớ tại sao hoặc làm thế nào mà bạn đã làm điều gì đó. Vậy nên hãy tra cứu nó trong ghi chú của bạn, làm cho các ghi chú dễ tìm kiếm và chia sẻ được.
Đặt câu hỏi hay và giúp người khác đặt câu hỏi hay
Một cách tối ưu hóa khác là đặt những câu hỏi hay.
+ Gặp vấn đề với một thư viện hoặc framework? Tra google.
+ Gặp vấn đề với code của nhóm bạn? Hỏi.
+ Bạn có vấn đề với cách mà nhóm đang sử dụng một thư viện hoặc framework? Hỏi.
Đây là lý do tại sao bạn nên tránh phát minh ra mọi thứ ngay từ đầu và sử dụng các thư viện mã nguồn mở. Nhóm của bạn càng có thể học hỏi nhiều từ các nguồn công khai, thì các kỹ sư dày dạn kinh nghiệm của bạn càng ít bị làm phiền.
Đây là những câu hỏi mẫu mang tính suy nghiệm mà bạn nên biết:
Bạn có thể giúp tôi với vấn đề này? Ai là người tốt nhất để hỏi? Đây là những gì sẽ xảy ra và đây là những gì tôi mong đợi sẽ xảy ra. Tôi đã thử X, Y và Z để giải quyết vấn đề. Tôi sẽ bị chặn (blocked) khi làm vậy trong N phút.
Hỏi trước khi bạn bị chặn, hỏi công khai, trình bày những gì bạn đã thử, giải thích những gì sẽ xảy ra và những gì bạn mong đợi sẽ xảy ra.
Hy vọng các mẹo bên trên có thể giúp senior software engineer làm việc năng suất hơn, và junior engineer tiến nhanh hơn đến nấc thang "senior". Bởi như chúng ta biết, kỹ năng viết code hay fix bug chỉ quyết định một phần thành công của kỹ sư phần mềm, nhớ nhé!
