Senior vs Junior Developer: không chỉ là chuyện kỹ thuật

Chào các bạn, tôi là Sơn, từ một thanh niên trẻ đam mê máy tính đến thành một "cụ" dev dày dạn kinh nghiệm cũng được 20 năm, tôi đã trải qua không ít thăng trầm trong thế giới lập trình.

Hôm nay, tôi muốn chia sẻ một góc nhìn về sự khác biệt giữa senior và junior developer trong cái ngành nghề đầy khổ cực của tôi, nhưng không phải từ góc độ kỹ thuật như nhiều người vẫn thường nghĩ.

Khi mới ra trường, tôi từng nghĩ rằng một senior developer là người biết hàng tá framework, thông thạo mọi design pattern, và có thể giải quyết bất kỳ bug nào chỉ trong vài phút. Nhưng sau gần hai thập kỷ làm việc, tôi nhận ra rằng kỹ thuật, dù quan trọng, chỉ là một phần của bức tranh lớn. Sự khác biệt thực sự giữa một senior và một junior không nằm ở việc bạn biết bao nhiêu dòng code, mà ở cách bạn tiếp cận công việc: sự cẩn thận, tỉ mỉ, và trách nhiệm.

Hãy để tôi kể bạn nghe một câu chuyện. Hồi mới vào nghề, tôi từng commit một đoạn code đơn giản để xử lý upload file lên server. Code của tôi chạy được, nhưng luôn bị "đập đi xây lại" trong các buổi review. Tôi đã từng thắc mắc: "Sao cứ phải tách cái method này ra làm hai? Sao phải đặt tên biến dài dòng vậy? Sao phải viết comment khi code đã rõ ràng rồi?"

Sếp lúc đó chỉ cười nhẹ, bảo: “Code chạy được không có nghĩa là code tốt. Code không phải để máy tính đọc, mà là để con người đọc.". Bài học đó theo tôi suốt sự nghiệp.

Tỉ mỉ là Chìa khóa

Sau gần 20 năm, giờ đây khi nhìn lại, tôi nhận ra rằng sự khác biệt lớn nhất giữa junior và senior developer không phải là: Số lượng ngôn ngữ lập trình biết, số framework thành thạo, tốc độ code nhanh hay chậm.

Sự tỉ mỉ của một senior developer không chỉ nằm ở việc viết code không bug. Nó nằm ở việc nghĩ đến trải nghiệm của người dùng, của đồng đội, và cả của chính mình khi phải quay lại debug code sau vài tháng. Một senior sẽ làm những việc rất đơn giản sau:

• Validate tham số đầu vào.
• Đặt tên biến, hàm rõ ràng để 6 tháng sau vẫn hiểu code mình viết.
• Đặt constant cho hầu hết các "string" được dùng đi dùng lại.
• Viết unit test không chỉ để “pass” mà để mô phỏng các lỗi thực tế.
• Logging để trace lỗi, kể cả khi ở trên Production.
• Document không chỉ cho sếp, mà cho cả đồng nghiệp mới vào team.

Giả sử khi tôi viết một middleware trong ASP.NET Core để xử lý authentication, tôi không chỉ đảm bảo nó hoạt động, mà còn thêm logging chi tiết, xử lý lỗi token hết hạn, và comment rõ ràng từng bước logic. Điều này giúp team QA dễ dàng kiểm tra, team bảo trì sau này không phải “đoán” code của tôi và ngay cả bản thân tôi sau 6 tháng đọc lại, sẽ không "oắt dờ heo".

Nhìn xa hơn cái nhìn trước mắt

Chúng ta thường giải quyết vấn đề trước mắt. Nhưng bạn có kinh nghiệm giải quyết vấn đề hiện tại nhưng luôn nghĩ đến tương lai.

Tôi từng chứng kiến một junior viết một hàm xử lý thanh toán. Khi được yêu cầu thêm phương thức thanh toán mới, cậu ấy copy-paste đoạn code cũ và sửa lại. Đến lần thứ 3, tôi đã phải ngồi xuống và nói: "Em có nghĩ là chúng ta sẽ còn thêm nhiều phương thức thanh toán nữa không? Nếu có, liệu cách làm này có bền vững?" Và chúng tôi đã lại đào lại training nhau SOLID, refactor code lại thành một strategy pattern đơn giản. Khi công ty thêm 2-3 phương thức thanh toán mới trong năm sau đó, chúng tôi chỉ cần viết thêm 3 class mới mà không phải sửa code cũ.

Biết khi nào KHÔNG viết code

Đây có lẽ là điều khác biệt lớn nhất. Các bạn thường muốn code mọi thứ từ đầu. Senior biết khi nào nên dùng thư viện có sẵn, khi nào nên "không làm gì cả", và đặc biệt là khi nào nên xóa code.

Hay thậm chí, fix một bug chỉ bằng cái lưỡi dẻo để trao đổi chiêu thức với tester, thêm một dòng ở Document Guide, mọi chuyện đã được giải quyết.

Cực kỳ kiên nhẫn với "technical debt"

Junior thường muốn refactor mọi thứ ngay lập tức khi thấy code xấu. Người kinh nghiệm biết cân nhắc giữa "technical debt" và giá trị kinh doanh.

Tôi từng làm việc với một hệ thống legacy 17 năm tuổi, với code base khủng khiếp - ý là lởm khủng khiếp đến mức chúng tôi gọi đùa là "dự án sinh viên". Một junior trong team đề xuất viết lại toàn bộ. Nhưng tôi đã phải giải thích không dưới 5 lần rằng:

• Hệ thống đang phục vụ người dùng
• Viết lại sẽ mất ít nhất 2 tháng
• Rủi ro bug mới rất cao

Thay vào đó, chúng tôi áp dụng "boy scout rule": Mỗi khi chạm vào một phần code, hãy làm nó tốt hơn một chút. Sau 2 năm, 70% code base đã được cải thiện mà không làm gián đoạn dịch vụ.

Hành trình từ Junior đến Senior: hãy kiên nhẫn

Nếu bạn đang đọc bài viết này và đang ở giai đoạn đầu sự nghiệp, đừng nản lòng. Mọi senior đều từng là junior, và những khác biệt tôi nêu trên đều có thể học được qua thời gian và kinh nghiệm. Các bạn mới ra trường, có lẽ các bạn đang cảm thấy áp lực: phải học .NET Core, Entity Framework, Azure, Docker, và hàng tá công nghệ mới. Nhưng tôi muốn nhắn nhủ rằng: Kỹ thuật có thể học, nhưng tư duy cẩn thận cần thời gian rèn luyện.

Hãy bắt đầu từ những điều nhỏ nhất, đây là một vài lời khuyên để rút ngắn quá trình:

• Hãy cẩn thận hơn với từng dòng code bạn viết. Hãy luôn tự hỏi: "Nếu 6 tháng sau quay lại, mình có hiểu code này không?". Kiểm tra lại code trước khi commit. Một lỗi nhỏ như quên null check có thể gây ra hàng giờ debug.
• Đọc code của người khác nhiều hơn. Đặc biệt là code của các anh đã làm trước đó, hiểu và hỏi tại sao họ viết như vậy.
• Học cách lắng nghe. Feedback từ senior, từ tester, từ QA, hay thậm chí từ khách hàng là cơ hội để bạn trưởng thành.
• Đừng ngại sai. Tôi đã từng commit code làm crash cả hệ thống, nhưng chính những sai lầm đó dạy tôi cách làm đúng.
• Đừng sợ hỏi "tại sao". Nhưng trước khi hỏi, hãy tự tìm hiểu trước thì câu hỏi của bạn sẽ chắc chắn hơn, và câu trả lời sẽ được tiếp thu tốt hơn.

Và điều tuyệt vời nhất? Bạn không cần đợi 10 năm để có tư duy của một senior. Bạn có thể bắt đầu ngay từ hôm nay, với sự cẩn thận và tỉ mỉ trong từng dòng code.

/Son Do - I share real-world lessons, team building & developer growth.

#DevMindset #DeveloperGrowth #TeamBuilding #DevLife #CodeWithCare #Mentorship #DotNet #CSharp #wecommit100xshare #1percentbetter