Phân level của Developer như thế nào?

Mở đầu

Nếu xem trên roadmap.sh, các bạn sẽ thấy tác giả không chia cụ thể: Junior, Mid Level hoặc Senior Developer thì phải học những gì, roadmap các vị trí FE, BE, Mobile, Devops… sẽ chỉ xoay quanh kiến ​​thức kỹ thuật. Tại sao vậy?

Bài viết này mình dịch và có chỉnh sửa quan điểm của tác giả sáng lập https://roadmap.sh, về việc phân loại kinh nghiệm của Developer, mời các bạn theo dõi ở phần dưới đây.

Thực trạng

Tôi đã thấy nhiều tổ chức quyết định level của các developer bằng cách coi trọng số năm kinh nghiệm hơn mức họ có thể làm được.

Tôi đã thấy các developer được gắn nhãn "Junior" làm công việc của "Senior Developer" và tôi đã thấy các "Lead" Developers thậm chí không đủ tiêu chuẩn để được gọi là "Senior".

Thâm niên của một developer (The seniority of a developer) không thể chỉ được quyết định bởi tuổi tác, số năm kinh nghiệm hoặc kiến ​​thức kỹ thuật mà họ có được. Có những yếu tố khác ảnh hưởng ở đây là:

• Nhận thức của họ về công việc
• Cách họ tương tác với đồng nghiệp
• Cách họ tiếp cận vấn đề

Chúng ta sẽ thảo luận chi tiết về ba yếu tố chính này đối với từng level của developer dưới đây.

Chức danh theo thâm niên

Các tổ chức khác nhau có thể có chức danh khác nhau nhưng chủ yếu thuộc ba loại:

• Junior Developer
• Mid Level Developer
• Senior Developer

Junior Developer

Các developer ở mức cơ bản, thường là những sinh viên mới tốt nghiệp và họ không có hoặc họ có ít kinh nghiệm trong ngành.

Họ không chỉ có kỹ năng code yếu mà còn có một vài đặc điểm nhận dạng khiến họ đích thực họ là Junior Developer:

Đặc điểm

1. Câu thần chú chính của họ là "making it work" (làm cho nó hoạt động) mà không chú ý nhiều đến cách đạt được kết quả của giải pháp. Đối với họ, một phần mềm hoạt động được và một phần mềm tốt là tương đương nhau.
2. Họ thường yêu cầu hướng dẫn rất cụ thể và có cấu trúc trước khi bắt tay vào code.
3. Họ bị hạn chế về tầm nhìn (tunnel vision - tầm nhìn đường hầm), không nhìn được bài toán tổng quan, cần được giám sát và hướng dẫn liên tục để trở thành một member hiệu quả trong team.
4. Hầu hết các Junior Developer chỉ cố gắng hoàn thành vai trò, nhiệm vụ của mình, và khi gặp khó khăn, họ có thể nghỉ việc thay vì cố gắng thử sức giải quyết các vấn đề.
5. Họ không biết về công việc kinh doanh của công ty, không nhận ra hoặc không quan tâm đến cách quản lý, bán hàng, tiếp thị/v.v. và họ không nhận ra sự lãng phí công sức vào việc re-work, fix bug và sự phiền phức mà người dùng cuối gặp phải trong lĩnh vực kinh doanh của họ.
6. Over-engineering (Phức tạp quá mức cần thiết) là một vấn đề lớn, thường dẫn đến sự rối rắm không cần thiết và gây lỗi. Lỗi này thường do Junior Developer code để thể hiện trình độ.
7. Khi gặp sự cố, họ thường cố gắng chỉ khắc phục sự cố hiện tại hay còn gọi là khắc phục các triệu chứng thay vì khắc phục nguyên nhân gốc rễ.
8. Bạn có thể nhận thấy "Vấn đề của người khác"  (Somebody else's problem) hành vi từ họ.
9. Họ không biết họ thiếu kiến thức, kỹ năng gì? họ cũng không biết họ đang thiếu bao nhiêu. Xem thêm Hiệu ứng Dunning-Kruger.
10. Họ không chủ động và có thể ngại làm việc trên một codebase không quen thuộc.
11. Họ không tham gia thảo luận nhóm.

Trở thành Junior Developer trong team không hẳn là một điều xấu, vì bạn chỉ mới bắt đầu, bạn không được kỳ vọng là một người biết tuốt. Tuy nhiên, bạn có trách nhiệm học hỏi, tích lũy kinh nghiệm, để không bị mắc kẹt với danh hiệu "Junior" và cải thiện bản thân. Dưới đây là một số tips dành cho các Junior Developer để giúp thăng tiến nhanh hơn:

Để thăng tiến nhanh hơn

1. Tất cả các loại vấn đề có thể được giải quyết nếu bạn làm việc với chúng đủ lâu. Đừng bỏ cuộc nếu Stack Overflow hoặc GitHub Issue không có câu trả lời. Nói với đồng nghiệp rằng "Tôi đang gặp khó khăn, nhưng tôi đã thử X, Y và Z. Bạn có gợi ý nào không?" sẽ tốt hơn nhiều so với việc nói "Điều này nằm ngoài khả năng của tôi."
2. Đọc nhiều code: không chỉ code trong các dự án mà bạn đang thực hiện, mà cả mã nguồn các libs, framework, opensource. Hãy hỏi các đồng nghiệp của bạn, có lẽ trên Reddit nữa, về các ví dụ code tốt, code đẹp cho ngôn ngữ/công cụ bạn chọn.
3. Thực hiện các dự án cá nhân, chia sẻ chúng với mọi người, đóng góp cho cộng đồng mã nguồn mở. Tiếp cận với mọi người để được giúp đỡ. Bạn sẽ ngạc nhiên về mức độ hỗ trợ mà bạn có thể nhận được từ cộng đồng.
4. Tránh hành vi, cách cư xử "Đây là vấn đề của người khác"
5. Khi đưa ra một vấn đề cần giải quyết, hãy cố gắng xác định nguyên nhân gốc rễ và khắc phục thay vì khắc phục các triệu chứng. Và hãy nhớ rằng, bug không thể tái hiện có nghĩa là không bug được giải quyết. Nó được giải quyết khi bạn hiểu tại sao nó xảy ra và tại sao nó không còn xảy ra nữa.
6. Hãy tôn trọng mã đã được viết trước bạn. Hãy hào phóng khi đưa ra đánh giá về kiến ​​trúc hoặc các quyết định thiết kế được đưa ra trong codebase. Hiểu rằng code thường xấu và kỳ lạ vì một lý do khác chứ không phải do kém năng lực. Học cách chung sống và phát triển với mã kế thừa là một kỹ năng tuyệt vời. Đừng bao giờ cho rằng ai đó ngu ngốc. Thay vào đó, hãy tìm hiểu làm thế nào mà những người thông minh, có thiện chí và giàu kinh nghiệm này lại đi đến một quyết định ngu ngốc như hiện nay. Tiếp cận kế thừa code của người khác với "tư duy cơ hội" thay vì phàn nàn.
7. Không biết nhiều cũng không sao. Bạn không cần phải xấu hổ vì chưa biết mọi thứ. Không có câu hỏi nào là ngu ngốc, hỏi nhiều câu hỏi sẽ cho phép bạn làm việc hiệu quả.
8. Đừng để bản thân bị giới hạn bởi chức danh công việc mà bạn có. Tiếp tục làm việc để cải thiện bản thân của bạn.
9. Làm bài tập về nhà -> gặp khó khăn hoặc bạn đã làm sai gì đó -> tham gia vào các cuộc thảo luận nhóm: Ngay cả khi bạn sai, bạn sẽ học được điều gì đó.
10. Tìm hiểu về lĩnh vực, sản phẩm mà bạn đang làm việc. Hiểu sản phẩm từ đầu đến cuối với tư cách là người dùng cuối. Đừng giả định mọi thứ, hãy đặt câu hỏi và làm sáng tỏ mọi thứ khi nghi ngờ.
11. Học cách giao tiếp hiệu quả - kỹ năng mềm quan trọng. Tìm hiểu cách viết email hay, cách trình bày công việc của bạn, cách diễn đạt câu hỏi của bạn một cách chu đáo.
12. Ngồi với các Senior developer, xem họ làm việc, tìm một người cố vấn. Không ai thích một người biết tất cả. Hãy kiềm chế cái tôi của mình và đủ khiêm tốn để tiếp thu những bài học từ những người có kinh nghiệm.
13. Đừng mù quáng làm theo lời khuyên của các "Chuyên gia", hãy xem nó là một trong các lựa chọn của bạn.
14. Nếu bạn được yêu cầu cung cấp ước tính cho một số công việc, đừng đưa ra câu trả lời trừ khi bạn có tất cả các chi tiết để đưa ra ước tính hợp lý. Nếu bạn buộc phải làm điều đó, hãy tăng gấp đôi hoặc nhiều hơn tùy thuộc vào mức độ bạn không biết về những gì cần phải hoàn thành để nhiệm vụ được đánh dấu là 'hoàn thành'.
15. Hãy dành thời gian để tìm hiểu cách sử dụng các Debug tools. Debug tools khá hữu ích khi bạn làm việc trên codebase mới, không có hoặc ít tài liệu hoặc gặp các “bug lạ”.
16. Tránh nói "nó hoạt động trên máy của tôi" - vâng, tôi đã nghe điều đó rất nhiều.
17. Cố gắng biến các cảm giác kém cỏi hoặc “hội chứng kẻ mạo danh” thành năng lượng để thúc đẩy bản thân tiến lên và nâng cao kỹ năng cũng như kiến ​​thức của bạn.

Mid Level Developer

Cấp độ tiếp theo sau Junior Developer là Mid Level Developer. Họ mạnh hơn về mặt kỹ thuật so với các Junior developer và có thể làm việc với sự giám sát tối thiểu. Họ vẫn còn một số vấn đề cần giải quyết để nhảy lên cấp Cao cấp.

Mid Level Developer có năng lực hơn Junior Developer. Họ bắt đầu nhìn thấy những sai sót trong codebase cũ của họ.

Họ có được kiến ​​thức nhưng họ bị mắc kẹt trong khi vận dụng các kiến thức đó, tức là làm mọi thứ rối tung lên trong khi cố gắng thực hiện chúng "đúng cách".

Mid Level traps

Ví dụ:

• Sử dụng quá mức hoặc sử dụng Design Pattern không cần thiết, họ có thể cung cấp giải pháp nhanh hơn các Junior Developer nhưng giải pháp đó có thể đưa bạn vào một lỗ hổng khác về lâu dài.
• Nếu không có sự giám sát, họ có thể trì hoãn việc thực hiện trong khi cố gắng "làm mọi việc đúng cách".
• Họ không biết khi nào nên đánh đổi (trade offs) và họ vẫn không biết khi nào nên quyết đoán (dogmatic) và khi nào nên thực dụng (pragmatic).
• Họ có thể dễ dàng trở nên gắn chặt với giải pháp của mình (fixed mindset - bảo thủ), trở nên thiển cận và không thể tiếp nhận phản hồi.

Mid Level Developer là khá phổ biến. Hầu hết các tổ chức đều gọi nhầm họ là "Senior Developer". Tuy nhiên, họ cần được cố vấn thêm để trở thành Senior Developer. Phần tiếp theo mô tả trách nhiệm của một Senior Developer và cách bạn có thể trở thành một người như vậy.

Senior Developer

Senior developer là cấp độ tiếp theo sau Mid-level Developer. Họ là những người có thể tự mình hoàn thành công việc mà không cần bất kỳ sự giám sát nào và không tạo ra bất kỳ vấn đề nào trong quá trình thực hiện. Họ trưởng thành hơn, đã tích lũy kinh nghiệm bằng cách cung cấp cả phần mềm tốt và xấu trong quá khứ và đã học được từ nó - họ biết cách thực dụng. Dưới đây là danh sách những điều thường được mong đợi ở một Senior Developer:

Đặc điểm

• Với kinh nghiệm trong quá khứ, những sai lầm đã mắc phải, các vấn đề mà phần mềm được thiết kế quá mức hoặc được thiết kế kém gặp phải, họ có thể thấy trước các vấn đề và thuyết phục hướng đi của codebase hoặc kiến ​​trúc.
• Họ thực dụng trong việc thực hiện. Họ có thể đánh đổi khi được yêu cầu và họ biết tại sao. Họ biết đâu là nguyên tắc, đâu là thực dụng (pragmatic).
• Họ có một bức tranh toàn cảnh về lĩnh vực này, biết đâu là công cụ tốt nhất cho công việc trong hầu hết các trường hợp (ngay cả khi họ không biết công cụ đó). Họ có khả năng bẩm sinh trong việc chọn một công cụ/ngôn ngữ/mô hình/vv mới để giải quyết vấn đề cần đến nó.
• Họ biết họ đang ở trong một đội. Họ coi đó là một phần trách nhiệm của họ trong việc cố vấn cho người khác. Điều này có thể bao gồm từ pair-programing với các Junior Developer đến thực hiện các nhiệm vụ không mấy vinh quang như viết document, test hoặc bất kỳ việc gì khác cần phải làm.
• Họ có hiểu biết sâu sắc về lĩnh vực này - họ biết về khía cạnh kinh doanh của công ty và nhận ra cách quản lý/bán hàng/tiếp thị/v.v. suy nghĩ và hưởng lợi từ kiến ​​thức của họ về lĩnh vực kinh doanh trong quá trình phát triển.
• Họ không đưa ra những lời phàn nàn sáo rỗng, họ đưa ra những đánh giá dựa trên bằng chứng thực nghiệm và họ đưa ra những gợi ý về giải pháp.
• Họ nghĩ nhiều hơn là chỉ code - họ biết rằng công việc của họ là cung cấp giải pháp cho các vấn đề chứ không chỉ viết code.
• Họ có khả năng giải quyết các vấn đề lớn không rõ ràng, xác định chúng, chia nhỏ chúng và thực hiện các phần. Một Senior Developer có thể lấy một cái gì đó lớn và trừu tượng và chạy với nó. Họ sẽ đưa ra một vài phương án, thảo luận với nhóm và thực hiện chúng.
• Họ tôn trọng code đã được viết trước đó. Họ rất hào phóng khi đưa ra đánh giá về kiến ​​trúc hoặc các quyết định thiết kế được đưa ra trong codebase. Họ tiếp cận việc kế thừa mã kế thừa với một "tư duy cơ hội" hơn là một tư duy phàn nàn.
• Họ biết cách đưa ra phản hồi mà không làm tổn thương bất cứ ai.

Kết luận

Các Team dev được tạo thành từ sự kết hợp của tất cả các vai trò này. Hài lòng với vai trò của mình là một điều tồi tệ và bạn nên luôn cố gắng cải thiện bản thân cho level tiếp theo.

Rất nhiều công ty quan tâm nhiều hơn đến số năm kinh nghiệm để quyết định level của nhân viên, đây là một thước đo không sát với thực tế  - bạn không thể có được kinh nghiệm chỉ bằng cách dành nhiều năm làm việc.

Bạn đạt được nó bằng cách liên tục giải quyết các loại vấn đề khác nhau, bất kể số năm bạn làm việc trong ngành. Tôi đã thấy những sinh viên mới tốt nghiệp không có kinh nghiệm trong ngành nhanh chóng bắt kịp và tạo ra kết quả như một Kỹ sư cấp cao và tôi đã thấy những developer Cấp cao được gắn mác "Cao cấp" chỉ vì tuổi tác và "Số năm kinh nghiệm" của họ.

Những đặc điểm quan trọng nhất mà bạn cần có để thăng tiến trong sự nghiệp là:

• Không hài lòng với sự tầm thường
• Có tư duy cởi mở, khiêm tốn, học hỏi từ những sai lầm của mình
• Giải quyết các vấn đề thách thức
• Có tư duy cơ hội hơn là phàn nàn về các vấn đề.

Bạn nghĩ gì về level hiện tại của chính mình? Suỵt, Không cần phải nói với ai cả, hãy đọc lại những tips được đề cập ở trên và bắt tay vào cải thiện để tự level up bản thân mình nhé.

Link tham khảo: https://roadmap.sh/guides/levels-of-seniority