Nghề lập trình viên, nhìn kỹ từ bên trong một văn phòng phần mềm

Phan Anh Tú · làm phần mềm hơn mười năm

Chín giờ kém năm, tầng bốn của một tòa nhà văn phòng ở quận Tân Bình còn thưa người. Cậu kỹ sư ngồi gần cửa sổ đã mở laptop, hai màn hình phụ sáng lên, một bên là Slack đỏ chấm thông báo, một bên là bảng Jira với cột “In Progress” dài hơn cột “Done”. Cậu chưa gõ dòng code nào. Việc đầu tiên trong ngày của cậu là đọc lại ba bình luận review mà đồng nghiệp ở Đà Nẵng để lại lúc mười một giờ đêm qua.

Tôi đã ngồi ở những chỗ như thế hơn mười năm, từ lúc còn viết PHP cho một trang bán điện thoại đến khi dẫn một nhóm tám người làm hệ thống thanh toán. Người ngoài hay hình dung nghề lập trình viên là cảnh gõ phím liên tục trên nền đen chữ xanh. Thực tế thì gõ phím chiếm ít thời gian hơn họ nghĩ nhiều.

Phần lớn thời gian là đọc, không phải viết

Một lập trình viên (software developer) mới vào nghề thường bất ngờ vì mình phải đọc code của người khác nhiều đến vậy. Một sản phẩm đã chạy vài năm có thể có hàng trăm nghìn dòng mã, viết bởi những người đã nghỉ việc từ lâu. Muốn thêm một nút “Xuất hóa đơn” nhỏ, cậu kỹ sư kia phải lần theo luồng dữ liệu qua bốn năm tệp, hiểu tại sao có một hàm tên calcTotal2 nằm cạnh calcTotal, và đoán xem sửa hàm nào thì không làm hỏng màn hình báo cáo của phòng kế toán.

Rồi đến họp. Buổi họp đứng mười lăm phút lúc chín rưỡi, mỗi người nói hôm qua làm gì, hôm nay làm gì, đang kẹt chỗ nào. Có hôm buổi họp đó kéo thành bốn mươi phút vì hai người tranh luận nên lưu ngày giờ theo múi giờ nào. Nghe thì vụn vặt, nhưng chính những chuyện như thế làm hệ thống sập vào lúc ba giờ sáng nếu không ai chịu cãi cho ra lẽ.

Phần viết code thật sự thường dồn vào buổi chiều, khi văn phòng yên hơn. Tôi biết nhiều người đeo tai nghe chống ồn suốt ba bốn tiếng, ai gọi cũng chỉ giơ tay ra hiệu đợi. Sau đó là viết test, đẩy code lên GitHub hoặc GitLab, mở pull request, chờ người khác review. Bị yêu cầu sửa lại hai ba lần là chuyện thường, không ai coi đó là bị chê.

“Code chạy được mới là nửa việc. Nửa còn lại là để người sau đọc mà không chửi mình.”

Câu trên tôi nghe từ một anh trưởng nhóm cũ, và mãi về sau mới hiểu hết. Code chạy được là điều kiện tối thiểu. Thứ phân biệt người làm lâu với người mới là code của họ dễ sửa, dễ đọc, có tên biến tử tế và có ghi chú ở những chỗ đáng ghi.

Nghề này có nhiều ngã rẽ hơn người ta tưởng

Khi ai đó nói “tôi làm IT”, câu đó gần như không nói lên điều gì. Trong cùng một công ty phần mềm, người ngồi bàn bên trái có thể cả ngày căn chỉnh khoảng cách giữa hai cái nút trên giao diện, còn người bên phải lại chỉ nhìn log máy chủ và biểu đồ CPU. Họ đều được gọi là lập trình viên, nhưng công việc hằng ngày khác nhau như thợ sơn với thợ điện trong cùng một công trình.

Tôi gom lại vài nhánh hay gặp trong các văn phòng phần mềm ở Việt Nam theo những gì mình đã chứng kiến, kèm thứ mà người làm nhánh đó dùng nhiều nhất:

Bảng này đơn giản hóa khá nhiều. Ở công ty nhỏ, một người có thể ôm cả frontend lẫn backend, người ta gọi là fullstack. Ở công ty lớn thì ngược lại, có người chỉ chuyên tối ưu tốc độ tải trang hoặc chỉ lo phần đăng nhập. Tester và BA thì không phải lúc nào cũng viết code, nhưng họ ngồi cùng phòng, dự cùng cuộc họp và chịu chung áp lực khi sản phẩm sắp ra mắt.

Nếu đang phân vân nên nhìn thị trường tuyển dụng thế nào, tôi thường bảo người mới cứ mở các tin đăng thật ra đọc, xem nhà tuyển dụng đang cần ngôn ngữ nào, yêu cầu mấy năm kinh nghiệm, ở thành phố nào.

Một chỗ tôi hay gửi cho mấy bạn sinh viên năm cuối là trang tổng hợp việc làm CNTT – phần mềm, đọc chừng hai chục tin là thấy rõ công ty đang thiếu người ở mảng nào.

Người giỏi nghề không nhất thiết là người gõ nhanh

Có một cô kỹ sư backend tôi từng làm cùng, gõ phím chậm đến mức đồng nghiệp hay trêu. Nhưng mỗi khi hệ thống trục trặc, cả nhóm đều quay sang hỏi cô. Cô có thói quen đọc log từ đầu đến cuối thay vì đoán, và ghi lại mọi giả thuyết vào một tệp văn bản trước khi thử sửa. Kiểu người như vậy hiếm, và các trưởng nhóm thường nhớ rất lâu.

Về chuyên môn, người làm nghề nào cũng cần một nền tảng chung. Đó là hiểu cấu trúc dữ liệu và giải thuật ở mức đủ dùng, biết Git để làm việc nhóm, biết đọc tài liệu tiếng Anh, và biết viết câu lệnh SQL cơ bản. Tôi chưa gặp lập trình viên nào làm lâu năm mà không phải đọc tài liệu tiếng Anh hằng ngày, từ trang hướng dẫn của thư viện đến các luồng thảo luận trên Stack Overflow hay GitHub Issues.

Phần ít được nói đến hơn là kỹ năng diễn đạt. Một ticket mô tả lỗi rõ ràng, có các bước tái hiện, có ảnh chụp màn hình, tiết kiệm cho cả nhóm cả buổi sáng. Một tin nhắn “cái này lỗi rồi anh ơi” thì ngược lại. Tôi từng thấy người viết code rất ổn nhưng lên cấp chậm chỉ vì không ai hiểu họ đang làm gì.

Từ bàn làm việc: mấy năm gần đây hầu như ai cũng dùng trợ lý AI như GitHub Copilot hay các công cụ chat để viết nháp code. Nó nhanh thật, nhưng tôi thấy người mới hay chép nguyên khối mà không hiểu, đến lúc lỗi thì không biết bắt đầu sửa từ đâu. Người dùng nó khéo là người đọc lại từng dòng như đang review code của đồng nghiệp.

Còn chuyện tiếng Anh, không cần nói trôi chảy mới đi làm được. Nhưng nếu muốn làm cho khách hàng nước ngoài, tham gia họp với đội ở Nhật hay Úc, thì kỹ năng nghe nói sẽ quyết định khá nhiều việc bạn được giao phần nào của dự án.

Đường lên cấp thường không thẳng

Ở hầu hết công ty, nấc thang trông khá giống nhau trên giấy. Thực tập sinh, rồi fresher, junior, middle, senior. Sau senior thì đường bắt đầu tách làm hai.

Một hướng là đi sâu vào kỹ thuật, thành tech lead rồi kiến trúc sư phần mềm (software architect). Người theo hướng này vẫn viết code, nhưng phần lớn thời gian dành cho việc quyết định hệ thống nên chia thế nào, chọn công nghệ gì, chỗ nào có thể chịu lỗi và chỗ nào thì không. Hướng kia là quản lý con người, thành trưởng nhóm, engineering manager, rồi có thể lên cao hơn. Người theo hướng này viết code ít dần, có tuần không mở trình soạn thảo lần nào.

Tôi đã chứng kiến không ít người chọn sai rồi quay lại. Một anh bạn lên làm quản lý được hai năm thì xin trở về làm kỹ sư chính, vì anh nhớ cảm giác giải được một bài toán khó hơn là ngồi sắp lịch họp. Công ty đó cũng đồng ý, và tôi nghĩ đó là một công ty biết giữ người.

Thời gian để đi từ junior lên senior thì không có con số cố định. Có người mất ba năm, có người bảy năm vẫn loay hoay. Thứ đẩy nhanh nhất mà tôi thấy là được ném vào một dự án thật, có người dùng thật, có lỗi thật vào giữa đêm. Làm hai năm ở một chỗ toàn sửa giao diện cũ thì kinh nghiệm cũng chỉ là một năm lặp lại hai lần.

Có tuần tôi chỉ sửa được đúng một lỗi. Nhưng đó là cái lỗi làm hai nghìn đơn hàng bị trừ tiền hai lần.

Câu trên là lời một cậu kỹ sư trẻ kể trong buổi tổng kết dự án mà tôi dự. Cậu nói với giọng hơi ngại, như sợ bị cho là làm ít. Thật ra cả phòng đều biết tuần đó cậu làm việc nặng nhất.

Về thu nhập, tôi không đưa con số vì nó chênh lệch rất mạnh. Người làm cho công ty gia công phần mềm, công ty sản phẩm trong nước và công ty nước ngoài có mặt bằng khác nhau. Ngôn ngữ, mảng nghiệp vụ, thành phố và khả năng ngoại ngữ cũng kéo con số lên xuống. Cách hợp lý là xem tin tuyển dụng có ghi khoảng lương ở đúng vị trí, đúng số năm kinh nghiệm của mình, rồi hỏi thẳng người đang làm.

Những thứ ít ai kể trước khi bạn vào nghề

Có những đêm điện thoại rung lúc hai giờ sáng vì máy chủ báo lỗi. Nhiều công ty có lịch trực (on-call) xoay vòng, tuần đó ai trực thì ngủ cũng phải để điện thoại cạnh gối.

Rồi chuyện học liên tục. Framework bạn học năm ba đại học có thể đã lỗi thời khi bạn đi làm được ba năm. Tôi không nói là phải chạy theo mọi thứ mới, vì phần lớn trào lưu sẽ qua đi. Nhưng cứ vài năm, người làm nghề phải tự hỏi mình còn đang dùng công cụ mà thị trường cần hay không.

Một điều nữa là ngồi nhiều. Lưng, cổ tay, mắt. Mấy anh chị làm hơn chục năm mà tôi quen ai cũng có một bệnh nghề nghiệp nhỏ, người thì đau vai gáy, người phải đeo nẹp cổ tay. Một cái ghế tử tế và thói quen đứng dậy mỗi giờ nghe có vẻ không liên quan đến nghề, nhưng nó ảnh hưởng đến việc bạn còn làm được bao lâu.

Cuối cùng là cảm giác mình không đủ giỏi, thứ mà dân trong nghề hay gọi đùa là “hội chứng kẻ mạo danh”. Tôi gặp nó ở cả người mới lẫn người đã làm mười năm. Ngồi cạnh một đồng nghiệp giải bài toán trong mười phút trong khi mình mất cả ngày, ai cũng từng chạnh lòng. Thứ giúp tôi vượt qua là nhìn lại code mình viết một năm trước. Nếu thấy nó tệ, nghĩa là mình đã khá hơn.

Ai hợp với nghề này

Tôi không tin có một kiểu tính cách “sinh ra để làm lập trình”. Tôi đã làm cùng người hướng nội ít nói lẫn người nói cả buổi không dứt, người học Toán chuyên lẫn người học xong cử nhân Ngữ văn rồi mới chuyển ngành. Điểm chung của những người trụ được lâu là họ chịu được cảm giác bế tắc. Có những lỗi phải mất hai ngày mới tìm ra nguyên nhân, và nguyên nhân hóa ra chỉ là một dấu phẩy.

Người trái ngành vào nghề ngày nay không hiếm. Có người học qua các khóa ngắn hạn, có người tự học qua tài liệu miễn phí rồi làm vài dự án nhỏ đưa lên GitHub. Con đường này khó hơn và hồ sơ thường bị lọc kỹ hơn ở vòng đầu, nhưng tôi biết vài người đi được. Họ đều có sản phẩm cụ thể để cho nhà tuyển dụng xem, chứ không chỉ có chứng chỉ.

Nếu bạn đang ở ngưỡng cửa, cách thử rẻ nhất là tự làm một thứ nhỏ cho chính mình. Một trang web ghi chi tiêu, một bot nhắc lịch uống thuốc cho bố mẹ, một công cụ đổi tên hàng loạt tệp ảnh. Làm xong mà thấy vui, và lúc kẹt vẫn muốn ngồi gỡ tiếp thay vì bỏ đi, thì có lẽ nghề này hợp với bạn. Còn nếu chỉ vì nghe nói ngành này dễ kiếm việc, tôi khuyên nên dành vài tháng thử trước khi bỏ tiền vào một khóa học dài.

Sáu giờ chiều, cậu kỹ sư gần cửa sổ đóng laptop. Pull request của cậu đã được duyệt, ba bình luận hôm qua đã sửa xong. Ngày mai lại có ticket mới trên Jira. Nghề này là vậy, ít khoảnh khắc lớn, nhiều ngày nhỏ cộng lại.