Con đường trở thành một Senior developer đích thực

Sau những năm tháng làm việc từ một fresher dev đã đưa tôi trở thành cổ đông của một công ty phần mềm, tôi đang làm việc và dẫn dắt rất nhiều kĩ sư trẻ tuổiCâu hỏi tôi nhận được rất nhiều đó là làm sao để trở thành senior developer?

Câu hỏi này không đơn giản, mỗi nơi có một định nghĩa về senior khác nhau. Tuy nhiên từ kinh nghiệm cá nhân làm việc tại nhiều công ty, tôi phát hiện ra rằng việc trở thành senior dev không chỉ ngừng ở việc thành thạo các tool nhất định. Thật ra, bạn phải có khả năng đưa ra quyết định, đưa ra những ước tính chính xác, và nhiều thứ khác nữa. Dưới đây là những điều mà các dev trẻ tuổi cần để phát triển sự nghiệp của mình, có thể các dev đã từng trải sẽ thấy nó quá bình thường, list này sẽ tóm tắt những gì tôi tìm và nghe được.

Project

1) Biết đâu là ưu tiên và theo nó đến cùng:

Đơn giản hơn là: Tưởng tượng bạn đang xây một căn nhà, theo to-do list thì bạn cần phải lắp toilet và sơn khung cửa sổ. Dĩ nhiên, mọi thứ trong list này đều cần được hoàn thành. Nhưng một căn nhà có thể ở được thì không thể thiếu toilet được, còn khung cửa sổ thì có thể không. Đây có thể là một ví dụ nhảm nhí và tranh cãi rằng đã sẵn có project plan và budget rõ ràng, nhưng trên thực tế plan có thể thay đổi và budget có thể bị cắt giảm. Ý tưởng ở đây là phải biết rõ cái gì quan trọng nhất vào thời gian nhất định và đảm bảo phải hoàn thành nó.

2) Tránh giả định và đặt các câu hỏi hợp lý:

Giả định là nguồn gốc của nhiều vấn đề và cái đáng ghét nhất đó là nó hoàn toàn có thể tránh được. Bạn cần phải tìm hiểu kĩ những thứ mình không biết và hỏi rõ ràng để tránh mơ màng. Ví dụ, tưởng tưởng ai đó hẹn gặp bạn tại Starbucks lúc 8 giờ, thì bạn phải hỏi những câu hỏi rõ ràng như chi nhánh Starbucks nào và hẹn lúc 8 giờ sáng hay 8 giờ tối. Tóm lại, bạn sẽ không rơi vào tình huống tự khiển trách bản thân đã không hỏi rõ.

3) Phân tích trước khi code:

Khi còn trẻ, chúng ta thường muốn thể hiện và viết code nhanh nhất có thể. Tuy nhiên, thật ra nghĩ kĩ trước khi build cái gì đó sẽ nhanh hơn, kể cả khi phải vẽ một vài biểu đồ ra trước, nhưng chúng đều giúp chúng ta có cái nhìn rõ hơn về nó và trả lời các câu hỏi cần thiết. Từ đó bạn có thể viết code an toàn hơn.

4) Đưa ra những quyết định đúng đắn:

Ý tôi nói đến trong những tình huống làm việc chuyên nghiệp. Đầu tiên, liệt kê hết các yếu tố ảnh hưởng đến quyết định của bạn, ví dụ như: implementation như thế nào, trải nghiệm với technology, performance, cost, etc. Một khi đã liệt kê hết các yếu tố, hãy làm tương tự với các option khác. Bây giờ bạn cần phải phân tích các option ra, có thể dùng các technique đơn giản như Pugh Matrix để so sánh giữa các option và support các quyết định bạn đã chọn.

5) Hiểu khách hàng:

Tôi quen nhiều người làm việc với codebase mà không có cả kiến thức lẫn quan tâm đến vấn đề cần giải quyết. Theo tôi, chúng ta gọi đó là những code monkeys và trong tương lai không xa sẽ bị thay thế bởi robot. Khi bạn quan tâm, và mọi người lắng nghe bạn, và hỏi ý kiến từ bạn và trân trọng nó. Và từ đó dần dà, trách nhiệm tăng, và kể cả các cơ hội và giá trị của bạn, và đương nhiên cả ví cũng dày lên.

Teamwork

6) Đừng ngại hỏi:

Tôi hiểu rằng bạn sẽ không muốn trở thành một người vô tâm trong mặt bạn bè hoặc tech lead, nhưng có một sự thật là một team tốt rất cần phần mềm được hoàn thiện đúng dead, và ghét tất cả những trì hoãn và nguyên nhân của nó. Vì thế họ có thể còn thất vọng về bạn hơn nhiều nếu bạn không chịu hỏi, và project sẽ bị trì hoãn, hơn là hỏi cái gì đó kì quặc nhưng hiểu chuyện và học được bài học.

7) Đừng ngại nộp task:

Giao nộp task có thể như một trải nghiệm kinh hoàng nếu bạn là người học việc, nhưng hãy nhớ rằng, chúng ta được trả lương để hoàn thiện product, đơn giản và nhanh chóng. Vì thế, thay vì cố kiếm cớ trì hoãn task: nộp, thương lượng về hậu quả, học từ thất bại và thành công, cải thiện và lặp lại đến khi bạn không còn sợ nữa.

8) Tôn trọng những đồng đội nhiều kinh nghiệm hơn mình:

Đôi khi bạn sẽ bất đồng với những quyết định của tech lead đưa ra, điều đó không sao cả, nhưng trước khi bạn nổi đóa lên tại sao người đó lại sai, tôi đề xuất một cách giải quyết khác: Hỏi xem tại sao họ lại quyết định như vậy, xem và hiểu được bức tranh toàn cảnh, có lẽ có những khuất mắt mà bạn chưa biết. Nói chung việc bạn hiểu cả quá trình ra quyết định của họ vẫn là tốt hơn.

9) Cân bằng giữa việc tuân lệnh và bất tuân:

Để làm rõ tôi sẽ kể một câu chuyện nhỏ. Tôi đang làm một project với tư cách Business Analyst và một trong những nhiệm vụ của tôi là viết một số quy trình lưu trữ. Acceptance test của khách hàng được thực hiện tại Trung Quốc và tech lead của chúng tôi phải đến đó để thực hiện bài test. Khoảng một tuần trước khi ra mắt thị trường của test user, tech lead bảo tôi business rule đã sai và cách fix nó. Cái anh ấy nói khiến tôi thấy không hợp lí và tôi đã đã phản hồi anh ấy một cách đầy tôn trọng, và anh ấy vẫn nhấn mạnh rằng tôi nên thay đổi quy trình thì tôi nói anh ấy muốn điều gì thì hãy email. Tất nhiên tôi buộc phải làm theo nhưng không quên tạo backup cho code cũ để có thể lấy ngay khi cần. Một tuần sau, khi test tại Trung Quốc thì nó không pass được bài test và tôi nhận được cuộc gọi từ team lead hỏi tại sao nó lại như vậy và ai phụ trách. Tôi đã rất lịch sự rep lại rằng là anh ấy và forward lại mail cho anh ấy. Khoảng 30 giây sau anh ấy hỏi tôi xem thay đổi nó có tốn nhiều thời gian không. Và ngay lúc đó tôi lấy bản backup ra. Mục đích của câu chuyện đó là đôi khi boss của bạn có thể sai, và trong những tình huống như vậy bạn nên hỏi xác nhận qua email hoặc bất kì phương tiên theo dõi được và có thể suggest luôn giải pháp. Vì thế, trong trường hợp có vấn đề phát sinh bạn sẽ an toàn. Bạn có thể nghĩ nó không cần thiết nhưng đôi khi các sếp có thể nổi đóa lên, nên tôi đề nghị nên suy nghĩ cẩn thận về nó.

10) Trả lời email:

Làm ơn nhớ việc này, đôi khi không nhất thiết phải trang trọng nghiêm túc mà chỉ cần Thank you! hoặc xác nhận bạn đã nhận mail là đủ, và nó sẽ khác xa rất xa so với việc không rep mail.

Hellolaptrinh tổng hợp