"Tôi rất tò mò muốn biết một lập trình viên senior là như thế nào vì hiển nhiên chẳng có định nghĩa nào cho thuật ngữ này cả. Tôi đã tiến hành theo dõi các bạn trẻ độ tuổi từ 22-23 mà những người mà tự gọi mình là lập trình viên senior X hay lập trình viên senior Y. Với tôi một senior ít nhất phải có 10 năm kinh ngiệm trong lĩnh vực lập trình, đó là điều kiện cần để được coi là một senior. Và câu hỏi đặt ra ở đây là..."
Tôi nghĩ như vậy có sai không? và tại sao?
Trên đây là một câu hỏi rất thú vị của một bạn lập trình viên mà tôi vô tình đọc được trên stackoverflow. Đây cũng là thắc mắc không chỉ của riêng tôi mà còn của rất nhiều bạn lập trình viên ở VN và ở TG nói chung nữa.
Có một lập trình viên đã trả lời ngay sau đó.
Bạn có thể coi mình là một senior khi:
- Bạn có thể kiểm soát toàn bộ vòng đời của một sản phẩm, từ khi bắt đầu đến khi kết thúc hoạt động.
- Bạn có thể lãnh đạo người khác làm việc trong dự án, hoặc cung cấp hướng dẫn cho họ để họ có thể làm việc
- Bạn có thể tự quản lý các dự án
Đôi khi một sinh viên mới tốt nghiệp cũng có thể làm việc cùng với những kỹ sư có trên 20 năm kinh ngiệm cũng là điều bình thường. Lập trình là một thế giới kỳ lạ mà trong đó những dòng code chính là đế vương. Một số người thành công đạt được những điều trên chỉ trong 2 năm, thậm chí ít hơn, lại có những người hơn 10 năm mới đạt được.
Và đây là một câu trả lời khác
Khi tôi nghe đến thuật ngữ "Senior Developer" tôi nghĩ ngay đến những người có khả năng làm chủ trong lĩnh vực phần mềm. Tôi nghĩ đó là một người vừa có khả năng thiết kế, code, và kiểm thử hệ thống. Họ có thể thảo luận về kiến trúc hệ thống hoặc thiết kế thành phần của phần mềm. Họ hiểu về kiến trúc thiết kế và sử dụng các mấu có sẵn. Và những người này có khả năng phát hiện được vấn đề có khả năng phát sinh và biết làm sao để tối ứu trước khi nó xảy ra. Những người này sẽ cải thiện việc lập trình bất đồng bộ, hàng đợi, cache, ghi log, bảo mật và sự ổn định của phần mềm khi tích hợp hệ thống.
Khi được yêu cầu họ có thể cung cấp giải thích chi tiết về sự lựa chọn của họ bao gồm cả ưu, khuyết điểm của phương án đó. Và trong hầu hết trường hợp họ là chuyên gia về lập trình hướng đối tượng và thiết kế, và điều này cũng không phải tuyệt đối với các ngôn ngữ như js, C#, Scheme hay những ngôn ngữ không phải OOP nói chung.
Có thể xử lý những rủi ro và quan trọng nhất là họ có thể thông báo đến các bên liên quan kịp thời.
Vậy thế nào là chuyên gia phần mềm? Có rất nhiều câu trả lời đồng ý rằng, người mà có khả năng làm việc hoặc có kỹ năng xử lý một vấn đề nào đó suốt thời gian 10,000 giờ lặp đi lặp lại, và hiểu hoàn toàn vè nó thì đc coi là chuyên gia trong lĩnh vực đó.
Điều này cũng được viết trong cuốn sách của tác giả Malcolm GladWell, "Outliers". Tác giả cũng nói về làm sao để làm chủ một lĩnh vực, để đạt top trong một lĩnh vực thì tốn khoảng 100,000 giờ để làm việc với nó.
Một số ví dụ trong cuốn "Outliers" của Malcolm GladWell là:
Buổi concert đầu tiền của Mozart biểu diễn năm 21 tuổi. Có thể lúc này ông rất trẻ nhưng thực sự thì ông đã bắt đầu soạn nhạc từ năm 11 tuổi. Nhóm Beatles ban đầu cũng không được chú ý. Họ nói rằng cũng có lúc họ muốn chuyển sang một công việc khác. Họ dành 3 năm ở Đức chơi khoảng 1200 lần tại các địa điểm khác nhau, mỗi lần từ 5 đến 8 giờ. Họ xuất hiện trở lại như Beatles chúng ta biết và yêu ngày hôm nay. Và cuối cùng, Bill Gates bị thôi học ở tuổi 20 khỏi Havard và sáng lập Microsoft. Vài người nghĩ điều này thật ngu ngốc, nhưng ở tuổi 20 ông ấy đã dành gần như một nửa tuổi thanh xuân cho lập trình. Năm 1975, chỉ có khoảng 50 người trên thế giới có được kinh nghiệm như ông ấy. Và điều này giúp ông ấy có tầm nhìn chiến lược trong tương lai cho Microsoft. Peter Norvig cũng thảo luận về việc quy định 10,000 giờ trong bài luận “Teach Yourself Programming in Ten Years” (tạm dịch: Tự học lập trình trong 10 năm).
Trong cuốn sách Mastery (Làm chủ) của George Leonard cũng đưa ra chi tiết làm như nào để có thể làm chủ một kỹ năng. Nghĩa là bạn phải thực hành kỹ năng đó lặp đi lặp lại nhiều lần. Càng thực hành nhiều lần bạn càng phát hiện ra sự khác nhau của chúng. Và chỉ có cái nhìn sâu sắc và tinh tế này mới giúp bạn tiến bộ hơn.
Các danh của ngành lập trình (Junior, Mid-Level and Seniors) dễ gây hiểu lầm và hay bị thay đổi tùy thuộc từng tổ chức. Tôi đã làm việc ở nhiều công ty khác nhau, và thường họ định ra chức danh Senior Developer là người có hơn 5 năm kinh nghiệm. Và chẳng có đề cập nào đến giá trị để đánh giá số năm kinh nghiệm này, đơn giản chỉ cần chỉ ra rằng họ ngồi trước máy tính 5 năm + là đc. Khi làm việc với những người này, nhiều người trong số họ thậm chí còn chưa nắm bắt được quy trình OOP, nhưng họ vẫn được coi là 1 senior developer. Thật nực cười.
Chúng ta cần phải có một thước đo khách quan hơn, trung thực hơn để tính rank của một lập trình viên phần mềm. John Haugeland đã đưa một bài viết về ma trận để đánh giá kỹ năng của lập trình viên. Đó là một cách khách quan để đánh giá trình độ của một lập trình viên nếu không thì tất cả chỉ là cảm tính mà thôi.
Khi nhìn vào một kỹ sư phần mềm, tôi thấy 4 cấp độ kỹ năng: Luminary, Senior, Mid-Level and Junior:
Luminary ( 10+ năm kinh nghiệm) là người có khả năng làm chủ 1 kỹ năng nào đó và có khả năng nâng cao nhận thức cũng như kỷ luật làm việc của mình. Một vài vd như: Ted Neward, Uncle Bob Martin, Donald Knuth, Oren Eini, Peter Norvig, Linus Torvalds. Các Luminary thay đổi dựa trên kỹ năng cá nhân của bạn.
Senior (7 to 10+ years, Level 3) là người dành ít nhất 10,000 giờ làm việc trong một lĩnh vực cụ thể. Họ hiểu đc bản chất của các kiến trúc thiết kế phần mềm, có khả năng lập trình bất đồng bộ, hàng đợi, cache, log, bảo mật và ổn định hệ thống khi tích hợp.
Có thể một Senior sẽ không bao giờ đạt đến Luminary. Các Luminary thường được được người ta nhắc đến qua cá video, sách, học thuật... Họ đang cố gắng để duy trì kỷ luật của chính mình.
Mid-Level (4 to 6 years, Level 2) là người có thể hiểu công việc lập trình hàng ngày. Họ có thể làm việc độc lập và có các giải pháp mạnh mẽ. Tuy nhiên, họ vẫn chưa trải qua quá trình sáng tạo phần mềm hay bảo trì những hệ thống lớn và phức tạp. Các Middle có khả năng phát triển tầng module tốt.
Junior (1 to 3 years, Level 1) là những người hiểu được khái niệm cơ bản về lập trình. Họ có các chứng chỉ về khoa học máy tính, hoặc họ tự học. Code của họ cần được review. Và họ luôn cần được hướng dẫn những thuật toán hoặc công việc bảo trì và kiến trúc hệ thống.
Ngoài ra thì còn có thêm 1 rank nữa ở mức học việc, và được chia ra rất nhiều loại.
Internship / Entry là những bạn học sinh, sinh viên đang học lập trình để phân biệt các loại ngôn ngữ lập trình phù hợp với họ.
Tôi có thể nói tầng Entry tương đương với Junior. Họ chỉ vừa mới rời chân khỏi ghế nhà trường và có ít hơn 2 năm kinh nghiệm. Họ ít khi được giao những task khó và luôn cần được hướng dẫn cẩn thận. Nói chung họ chỉ nắm được khoảng 10% những gì mà họ nói là họ biết =)). Thường thì họ sẽ không nghĩ được tổng thể dự án, và thường xuyên đưa ra những câu hỏi ngây thơ, luôn mong chờ cơ hội để chọn lựa mà không tự tạo cơ hội. Đáng buồn thay, rất nhiều trong số họ không biết yêu cầu hoặc luật là gì, mà họ thích làm theo ý mình hơn. Và với họ kỹ năng debug là một cái gì đó xa vời, mông lung. It's truth!
Và mức trung bình (Middle) là chiếm đa số trong giới lập trình. Đa phần họ có nhiều hơn 2 và ít hơn 10 năm kinh nghiệm, và thậm chí ở mức này trong cả sự nghiệp của họ. Họ có thể code dưới sự giám sát ít hơn nếu được giao task thường xuyên. Họ thường không được giao những công việc đòi hỏi độ phức tạp cao hoặc đòi hỏi kiến trúc thiết kế với trình độ chuyên sâu. Họ có thể được giao task thiết kế một phần của ứng dụng mặc dù họ đang ở trong giai đoạn để phát triển thành một senior. Họ rất có thể làm task rất tốt, hoặc bảo trì nhưng chỉ tập trung một nhiệm vụ chứ không thường xuyên được giao task tổng thể, trừ khi họ đang làm việc với senior hoặc đang được đào tạo để trở thành senior. Họ chưa đủ kinh nghiệm để phân tích thiết kế mà họ chỉ sửa lỗi nếu nó xảy ra. Nhưng họ lại có kỹ năng làm việc và hiếm khi phải yêu cầu trợ giúp trong việc gỡ lỗi. Có lẽ họ đã trải qua toàn bộ chu trình phát triển ít nhất 1 lần và thấy được kết quả về phân tích các vấn đề thiết kế và đang học các để tránh trong tương lai. Thông thường, họ có khuynh hướng sửa được vấn đề nếu có nguyên nhân rõ ràng. Họ đã có đủ kiến thức để biết những gì mình chưa rõ và đang dần nâng cao khả năng đó.
@nguyenvietmanh