Vậy là hai sprint đã trôi qua kể từ khi mình được tham gia vào dự án đặc biệt nhất của công ty. Đây thực sự là một sprint khó khăn đồng thời cũng là một sprint thú vị khi phần công việc của mình tương đối phức tạp so với trình độ hiện tại của mình. Thế nhưng may mắn là mình đã vượt qua tương đối ổn. Sau sprint này, bài học mà mình rút ra được có thể gói gọn trọng một câu: Hãy hoài nghi và hãy hỏi đúng lúc.
Hãy luôn ý thức về năng lực của bản thân mình để biết mình đang ở đâu, nên làm gì và có thể làm được những gì. Đó là điều đầu tiên mình phải học được trong sprint này. Sau tuần đầu tiên, mình đã có được một chương trình tương đối hoàn thiện và cảm thấy mọi thứ kết thúc khá nhanh. Tuy nhiên hóa ra không phải như vậy. Mình vẫn chưa đào sâu vào hơn vào cách vận hành của hệ thống mà vẫn chỉ nhìn trên bề mặt.
Có thể giải thích vấn đề như thế này. Khi bạn có một danh sách các sự kiện bạn cần làm trong tuần hiển thị ra màn hình. Trông thì có vẻ đẹp đấy! Thế nhưng nếu như một sự kiện trong số đó thay đổi thì liệu trang danh sách sẽ load lại toàn bộ danh sách hay chỉ load lại chỉ sự kiện cần cập nhật thôi? Câu trả lời hiển nhiên là chỉ sự kiện đã được cập nhật thôi! Đó là một điều đơn giản nhưng mình mất nửa sprint chỉ để hiểu ra và những 2 ngày để cải tiến chương trình! Đó là một pha hú vía. May thay mình đã được tỉnh ngộ ra sớm :v Để rồi sau khi cải thiện chương trình, mình cảm thấy tự bản thân đã học được nhiều hơn và sâu hơn. Đấy! Đôi khi ta cần một lời nhắc nhở hơi gay gắt và đầy thách thức để đẩy bản thân xa hơn giới hạn hiện tại
Và bài học thứ hai, cũng đầy sự thú vị, đó là Hãy hỏi đúng lúc! Như thế nào là đúng lúc? Đơn giản là khi bạn đã hiểu rõ vấn đề đó hết mức có thể! Trong ngành của mình có một cụm từ là debug chỉ việc chúng ta điều tra xem tại sao chương trình không hoạt động đúng ý. Thông thường ta sẽ bắt đầu với một vấn đề mơ hồ. Sau đó bằng cách nghiên cứu cách chương trình hoạt động, ta sẽ thu hẹp lại phạm vi của vấn đề và rồi biết được cốt lõi của nó là gì hoặc chia nhỏ vấn đề thành từng bước để giải quyết. Câu chuyện ở đây là ta nên tự mình đào sâu vấn đề đến mức nào là đủ để hỏi. Bởi đôi khi hỏi sớm quá hay trễ quá cũng đều mất thời gian. Khi bạn chưa đào sâu đủ để hiểu vấn đề nhưng bạn đã hỏi thì chính người được hỏi cũng phải tốn công debug. Nhưng khi bạn cứ đăm đăm giải quyết một mình thì có thể bạn đang lãng phí thời gian khi mà biết đâu đồng đội đã gặp và giải quyết một câu chuyện tương tự. Vậy thì, khi nào thì ta nên đào sâu vấn đề và khi nào thì nên mở miệng ra hỏi? Mình có một số bí quyết như sau:
1. Với quyền hạn của mình, bạn còn có thể debug tiếp được hay không? Nếu có, hãy tiếp tục đào sâu. Nếu không, hãy hỏi.
2. Bạn đã tìm ra vấn đề, bạn có thể tự đưa ra hướng giải quyết thỏa đáng hay không? Nếu có, hãy thử làm và nhờ review. Nếu không, hãy hỏi.
Trong trường hợp của mình, mình đã có thể gom lại một vấn đề mơ hồ thành một câu hỏi duy nhất: Làm sao để gọi một danh sách các API giống nhau chỉ trong một hook? Và anh senior sau khi nghe câu hỏi đã trả lời rất nhanh: À! Em research key word “for await” trong source code nhé. Và thế là câu chuyện được giải quyết! Một sự giao tiếp gọn gàng mà hiệu quả.
Vẫn còn nhiều vấn đề trong cách mình tiếp cận và làm việc với dự án này. Nhưng cho đến hiện tại, mình thấy trình độ và thái độ của bản thân được nâng cao lên rất nhiều qua từng sprint. Đây là một dự án đòi hỏi nhiều về kỹ năng tự lập lẫn làm việc nhóm hiệu quả. Sẽ còn nhiều bài học cần phải thuộc lòng và còn nhiều thử thách cần vượt qua. Nhưng mình nghĩ mình sẽ vẫn giữ vững tinh thần bởi vì như một anh đã nói với mình: Có việc khó mới cần tới ta! Đừng than vãn mà hãy tận hưởng.
Tâm sự Kỹ năng nghề nghiệp Kỹ năng mềm