Thế nào là 1 engineer giỏi

Đây là cái sẽ không có 1 câu trả lời chuẩn mực hoàn toàn mà sẽ là góc nhìn từ mỗi người. Đối với mình, 1 engineer giỏi khi có những tố chất sau

Trong suy nghĩ

1. Luôn muốn đơn giản hóa vấn đề

Làm sao để giải quyết vấn đề bằng phương pháp đơn giản và dễ hiểu nhất. Làm sao giúp user dễ sử dụng nhất. Làm sao giúp việc bảo hành sau này ít tốn công sức nhất.

2. Luôn muốn giải quyết vấn đề bằng phương pháp phù hợp nhất

Có cái sense về việc khi nào nên dùng giải pháp nào

• khi nào cần tối ưu cái có sẵn
• khi nào chỉ cần workaround
• khi nào thì bắt buộc đào sâu fix root-cause ngay
• khi nào cần ... đập đi viết lại

và có khả năng giải thích lí do cho những người liên quan

3. Không ngại khó

Dám giải quyết vấn đề có vẻ lằng nhằng (ví dụ fix bug khó hoặc những vấn đề logic phức tạp). Đây là cái sẽ không giúp có instant gratification (tạm dịch: sướng ngay) như khi làm tính năng. Làm tính năng sẽ nhanh thấy kết quả, nhanh thấy 1 màn hình mới có thể tương tác còn bug khó thì sẽ cần thời gian mày mò. Tuy nhiên, fix bug khó thể hiện tư duy logic và ... "level" của mình, là cái đáng thử.

Điều này cũng cần sự hỗ trợ của các bạn manager, dành thời gian cho team quay lại các bug khó cần xử lí triệt để.

4. Giữ được sự tò mò

Đây là yếu tố rất quan trọng, nó giúp mình có đam mê thắc mắc, từ đó tìm hiểu sâu hơn về nghề. "Giữ được" là vì đây là cái dễ có khi còn là junior, nhưng sẽ khó giữ về sau này.

Khi mày mò thử nghiệm nên cần kết hợp với "lấy, đọc và dùng data"

5. Tương tác

Động viên, chia sẻ kiến thức với người khác, đồng thời open-mind đón nhận idea mới (có thể khác mình) và feedback (có thể là chê) của người khác

6. Ownership

Hơi khó dịch, đại khái là trách nhiệm cao với công việc, coi vấn đề/project là của mình (thì mình sẽ sung mà tìm tòi tu sửa cho nó ngon, đặc biệt nếu bug khó) thay vì đó chỉ coi đó là vấn đề của cty, của KH, của team khác

Các kĩ năng

1. Giải thích vấn đề technical rõ ràng và phù hợp với đối tượng tiếp nhận

• Đối với người nắm rõ nội dung như mình: trao đổi trong ticket hay khi trao đổi làm việc với team
• Đối với người chưa nắm rõ nội dung như mình: khi chia sẻ chung (blog, talk v.v...) hoặc coaching cho các bạn khác

Giải thích vấn đề rõ ràng cũng thể hiện là mình đã hiểu rất rõ về vấn đề đó

2. Mở rộng và đào sâu ở những phần mình làm

• Tìm hiểu về performance (đo cái hiện tại, tối ưu)
• Viết test (đây là 1 trong những cái nói lí thuyết thì dễ nhất nhưng làm thật và làm tới nơi tới chốn tương đối chưa nhiều. Vì những phần khác như fix bug, tối ưu performance không làm là sẽ thấy ảnh hưởng đến hệ thống hay trải nghiệm người dùng ngay, còn không viết test thì cái giá khó nhận thấy hơn mặc dù có thể lâu dài cũng nghiêm trọng không kém). Có cái sense chỗ nào cần viết loại test nào và chỗ nào (có thể) chưa cần viết test
• Có kiến thức về Devops (CI/CD), Linux v.v...
• Có sense về UI/UX. Không cần nhất thiết phải biết thiết kế, đó là việc của designer nhưng nên có sense để nhận xét thế nào là đẹp, dễ xài thế nào là chưa
• Tham gia tuyển dụng, học cách đánh giá ứng viên
• Rèn luyện khả năng estimate thời gian hoàn thành tính năng. Đây là điều khó, đa phần các dự án đều ... estimate sai. Expectation không phải là estimate đúng 100% mà là estimate gần đúng và có dựa trên dữ liệu - ví dụ chia nhỏ vấn đề ra để estimate

Nếu bạn thấy hình bóng mình đâu đó trên đây, Tiki chào đón bạn :)