7 sự thật mình bỏ lỡ khi còn là lập trình viên junior

Đã 10 năm kể từ khi mình chính thức trở thành 1 lập trình viên. Rất khó để nhớ về khoảng thời gian mà mình còn chưa biết HTML là gì. Đa số tụi nhỏ thường chọn múa ballet hay chơi loại nhạc cụ nào đó, riêng mình lại chọn đắm chìm trong những dòng code.

Nhớ lại lúc mình mới bắt đầu được nhận thù lao thường xuyên chỉ để gõ những ‘ký hiệu lạ lẫm’ vào Terminal, mình cũng muốn chia sẻ 1 chút về những thay đổi về cách suy nghĩ của bản thân trong nhiều năm qua với vai trò là 1 lập trình viên.

Với các bạn junior: Có thể bạn sẽ tìm thấy thứ gì đó để rút kinh nghiệm, cũng có thể tìm thấy cảm hứng để tiếp tục con đường developer. Hoặc có thể bạn sẽ thấy bài đăng này rất đáng khích lệ vì bạn đã vượt xa level của mình rồi.

Với các senior: Có thể bạn sẽ thấy điểm tương đồng, hay bắt gặp vài tình huống dở khóc dở cười mà chính bạn cũng từng gặp khi còn là junior.

Sau đây là 9 điều mình đúc kết được từ khi còn là junior.

Mình là 1 lập trình viên senior

Mình ứng tuyển cho công việc đầu tiên lúc mới 19 tuổi. Vị trí mình ứng tuyển là ‘Quản trị web sinh viên – Student Webmaster’. Vốn là 1 công việc khá xịn sò, bởi vì bạn sẽ vừa là sinh viên và còn là quản trị viên cùng 1 lúc. Giờ thì mọi người đều muốn được gọi là ‘kỹ sư’ vì nghe có vẻ hào nhoáng hơn, nhưng nếu bạn hỏi mình thì từ ‘quản trị viên’ sẽ chính xác hơn. Anyway, công việc của mình là viết PHP và MySQL, duy trì website Drupal cũng như dựng các bộ tool nội bộ.

Vì đã code tại nhà được vài năm, mình khá chắc khoảng thời gian đó cũng được xem như là ‘số năm kinh nghiệm’. Nên khi được hỏi về số năm kinh nghiệm về PHP, mình tự tin trả lời rằng: “3 – 4 năm!”

Mình cũng nghĩ là bản thân biết khá nhiều về SQL bởi vì mình có thể làm được outer joins. Và theo Google, 3-4 năm kinh nghiệm có nghĩa là mình nên đi kiếm tiền được rồi.

Nói qua về công việc hiện tại, mình được tuyển sau 5 năm học hỏi ở trường cũng như qua kinh nghiệm chuyên ngành (vốn mình từng nghĩ kinh nghiệm nào cũng giống nhau như cả thôi). Và ở thời điểm đó, mình cơ bản không bao giờ review code. Mình deploy ssh-ing vào 1 server và chạy ‘git pull’. Mình còn chưa phải open 1 Pull Request. Mình đã học được nhiều thứ tuyệt vời với 2 công việc đầu tiên, nhưng chưa bao giờ có cơ hội để làm cùng với các dev khác trong cùng 1 codebase. Tuy vậy, mình đã thử ứng tuyển cho vị trí ‘senior frontend engineer’, và đã được nhận việc.

Và thế là, mình đã trở thành 1 lập trình viên senior ở độ tuổi 24.

Rõ ràng là nhà tuyển dụng sẽ không để mình đảm nhiệm “chức danh” này nếu mình không thực sự là 1 senior. Và thế là mình trở thành lập trình viên trẻ tuổi nhất tại văn phòng làm việc.

Những điều mà mình đã học được

Không phải tất cả các kinh nghiệm đều giống như nhau. Kinh nghiệm coding từ nhỏ, làm việc thời sinh viên, làm về nghiên cứu CS, và làm việc tại 1 startup đang phát triển đều là những dạng kinh nghiệm đáng giá. Nhưng chúng không hề giống nhau. Giai đoạn đầu trong sự nghiệp, bạn có thể học được gấp 10 lần (ở 1 team hỗ trợ lẫn nhau trong 1 năm) hơn là chỉ viết code 1 mình (hay với feedback) trong 5 năm trời. Nếu code của bạn chưa từng được các lập trình viên khác review, thì bạn sẽ không học được nhanh hết sức có thể – đó là 1 yếu tố khá quan trọng.

Đó là lý do các cố vấn viên – mentor rất là quan trọng, và có 1 team làm việc cùng cũng đáng giá hơn nhiều so với việc kiếm được vài đồng trong ví. Đừng chấp nhận vị trí junior ở nơi mà bạn sẽ phải làm việc 1 mình! Và đừng chấp nhận vai trò đầu tiên của bạn (hay thực sự mà nói là cho bất cứ vai trò nào) chỉ dựa vào tiền nong. Làm việc cùng team mới chính là nơi có giá trị thực sự.

Mình cũng học được rằng chức danh nghề nghiệp cũng không chứng tỏ được gì cả. Giống như việc là CTO của 1 team 5 người sẽ khác biệt với 1 team có 50 người hay 1 team có 500 người. Công việc và kỹ năng yêu cầu cũng hoàn toàn khác biệt, dù tước danh thì giống hệt nhau. Cho nên dù mình có 1 công việc với chức danh ‘senior’ thực sự không làm mình hoàn toàn trở thành 1 kỹ sư senior. Hơn thế nữa, các chức danh phân cấp cũng thường dễ bị thiếu sót, và khó để so sánh giữa các công ty. Mình học được điều quan trọng là đừng nên quá quan trọng các chức danh, mà chỉ nên dùng chúng như 1 dạng công nhận bên ngoài xã hội. 

Việc làm junior IT lương cao trên TopDev

Mọi người đều tự test

Trong nửa đầu sự nghiệp, mình làm về nghiên cứu. Nói rõ hơn là mình làm ở 1 dự án gây quỹ cộng đồng trong khoảng 3 năm rưỡi, và sau đó là tại 1 trường đại học ở NLP được 1 năm rưỡi. Phải nói rằng việc lập trình cho nghiên cứu khác hoàn toàn với việc lập trình trong ngành công nghiệp (thương mại).

Phần lớn công việc mình sẽ không phải phát triển ứng dụng, mà sẽ làm việc với các thuật toán hay phân tích bộ dữ liệu. Còn nếu đang dựng ứng dụng thì khả năng cao là được gây quỹ từ cộng đồng – đồng nghĩa với việc app hoàn toàn free và dự án là open-source. Và khi 1 thứ gì đó miễn phí, có nghĩa rằng bạn không phải chịu trách nhiệm để làm cho chúng hoàn hảo nhất.

Vì nó miễn phí mà. Bạn cũng không chịu trách nhiệm kiếm tiền từ app đó hay tạo ra sản phẩm, nhưng đó là 1 câu chuyện hoàn toàn khác khi làm lập trình viên trong học viện.

Sau đó mình rời khỏi học viện với khá nhiều kỳ vọng.

Kỳ vọng về công việc sẽ được triển khai như thế nào. Sẽ có automation, Pull request và code review .Nghe rất gì và này nọ. Ngoài ra còn là những dòng code đỉnh nhất, thêm nữa mình còn tin rằng mọi người trong ngành công nghiệp lập trình đều phải test.

Trái với mong đợi, ngày đầu tiên đi làm của mình ở 1 startup và không hề có test tiếc gì. Chẳng có test cho frontend và cũng không có test cho backend. 

Nada. Zip. Null. Undefined. NaN test.

Không những không có test, mà dường như không ai có vấn đề gì với việc thiếu vị trí tester! Với 1 chút ngây thơ, mình cho rằng lý do không test vì mọi người không biết viết test cho AngularJS. Nếu mình dạy cho họ cách làm, mọi thứ sẽ ổn và chúng ta sẽ bắt đầu có test. Sai lầm! Nhiều năm sau đó, công ty mình thậm chí cân nhắc việc thêm test tự động vào code, và nó cũng không đơn giản như mình nghĩ.

Nhưng không phải là vì mọi người không biết cách viết test. Họ cũng hầu như không bao giờ cảm nhận được nỗi khó chịu khi thiếu bước test ấy.

Những gì cuối cùng mình học được

Có khá nhiều công ty và startup có rất ít hoặc không hề có test. Khi chật vật để tìm thị trường sản phẩm phù hợp, hay chiến đấu để tồn tại, rất nhiều công ty bỏ qua việc test sớm. Ngay cả các công ty nhìn rất hào nhoáng, tài trợ cho các hội nghị hay code open-source – nên thành ra là nhiều nơi vẫn còn lượng Monolith lớn.

Thật sự không có công ty nào có tech setup hoàn hảo. Mỗi công ty đều có nhiều vấn đề riêng, mỗi công ty đều có technical debt của họ. Câu hỏi là họ đang làm gì với nó. Chúng ta không nên ảo tưởng khi ứng tuyển rằng luôn có việc gì đó cần phải hoàn thành – nếu không họ sẽ không thuê mình.

Quá ngoan cố về các chủ đề mà bạn thiếu kinh nghiệm ngoài đời thực là khá kiêu ngạo. Mình tình cờ trở thành 1 người ‘biết tuốt’, khăng khăng phải có test nhưng hầu như không có bất kỳ kinh nghiệm nào về những gì có quy mô thực sự giống như vậy. Đừng như mình. Dù có nguyên tắc là tốt , nhưng bạn cũng phải cởi mở tiếp thu những kinh nghiệm và quan điểm của người khác.

Chúng ta đã bị bỏ lại khá xa so với những người khác (aka tech fomo)

Đây khá liên quan tới chủ đề về unit testing. Trong khi công ty mình không có nhiều unit test, mình chắc là tất cả các công ty khác thì có. 

Tuyển dụng junior IT TPHCM mới nhất

Những điều cuối cùng mình học được

Nhiều cuộc hội thảo thường bao gồm bằng chứng của các khái niệm hơn là kịch bản ngoài đời thực. Chỉ bởi vì bạn thấy 1 cuộc hội thảo nói về 1 công nghệ đặc thù, không có nghĩa rằng công ty đó đang sử cụng công nghệ như vậy trong công việc hàng ngày của họ, hay là tất cả code của họ đều hoàn hảo. Những người tham dự hội thảo thường là để giới thiệu các ứng dụng đồ chơi hơn là các trường hợp nghiên cứu thực tế, khá quan trọng để phân biệt 2 loại này.

Đối mặt với legacy code (code không có test) là hoàn toàn bình thường. Nhưng sau khi dành nhiều thời gian cho các cuộc hội thảo và nói chuyện với những người làm việc ở những công ty công nghệ hàng đầu, mình cảm thấy nó trở nên rõ ràng hơn là chúng ta đều ở trên cùng 1 con thuyền. Công ty nào mà KHÔNG CÓ lượng monolith PHP hay Ruby khổng lồ mà họ đang cố thuần hóa chứ ? (hay buộc phải thuần hóa ở 1 vài thời điểm). Legacy code là chuyện bình thường, và học cách để đối phó với nó thường sẽ dạy cho bạn nhiều thứ hơn là chỉ dựng các ứng dụng từ scratch, vì bạn sẽ được tiếp xúc với các khái niệm mà bạn chưa hiểu. 

Chất lượng code là điều quan trọng nhất.

Từng có ngày, nhận 1 review code từ mình có thể là việc khá tàn nhẫn.

Mình khá kỹ tính trong việc code. Cách mình code khá tương đồng với style guide Airbnb JavaScript. Những thứ như indentation (thụt đầu dòng), format (định dạng), đặt tên, … Nếu ai đó “vượt qua” review code mà không nhận ít nhất 1 comment từ mình thì đó thật sự là “tâm linh tương thông” giao thoa với việc ‘trúng xổ số“, thật sự.

Thử tưởng tượng việc có hơn 50 comment trong PR của bạn với biết bao dấu ‘;’ bị thiếu sót… mình khá tinh mắt nên là mình muốn có những dấu ‘;’ chất lượng đó.

(May thay, mình đã không còn tinh mắt nữa sau khi nhìn chằm chằm vào máy vi tính từ năm này sang năm khác, nên là tha cho các bạn đấy! – Đùa tí thôi.)

Điều cuối cùng mình học được

Đủ tốt là đủ rồi. Khi quá chăm chút cho việc code cần “tốt” như thế nào sẽ gây ra việc suy giảm hiệu suất. Không cần phải sạch hoàn hảo để có thể hoàn thành công việc và cũng không hẳn là 1 thảm họa để duy trì. Đôi khi, code 1 cách lặp đi lặp lại nhiều hơn 1 chút hay dài dòng hơn 1 chút sẽ làm người khác dễ hiểu hơn. Và khái niệm ‘code tốt’ cũng không giống như ‘code nhìn giống như mình viết’.

Kiến trúc code quan trọng hơn sự chi li. Đoạn code có thể từ từ cải thiện, nhưng các vấn đề lớn thường xuất hiện về phần cấu trúc. Đáng lẽ mình nên tập trung nhiều hơn về cấu trúc của ứng dụng hơn là chăm chút từng li từng tí khi mới bắt tay vào code.

Chất lượng code khá quan trọng, và mình không nói ngoa đâu. Nhưng thực sự là chất lượng code không giống như những gì mình từng nghĩ, vốn mĩnh cho là những thứ như linting hay formatting hay bất cứ style gì được quảng bá trên các bài viết trên blog gần đây mà mình đã đọc. 

Mọi thứ phải được tư liệu hóa – document.

Ở công ty đầu tiên, cũng là lần đầu tiên mình làm việc với nhiều code của người khác viết như vậy. Trước đó mình chưa từng phải tiếp nhận 1 codebase có sẵn và hình dung xem cái khỉ gì đang diễn ra như vậy. Có lần mình đã viết lại tất cả code thay vì cố gắng tìm ra cách hoạt động của nó.

Dù sao thì, nó cũng không giúp được gì vì đó là code AngularJS được viết bởi lập trình viên Ruby, hay vì mình chỉ là 1 lập trình viên junior vốn không biết mình là 1 junior.

Vậy cách mình lo liệu sự thật rằng 300 line code lạ lẫm làm cho mình như bị ngập ngụa trong nó?

JSDOC. Ở KHẮP MỌI NƠI.

Mình bắt đầu bình luận mọi thứ để làm mọi thứ hợp lý hơn.
Chú thích cho mỗi function mà mình có thể nắm được.

Mình đã học được tất cả các syntax JSDoc hào nhoáng của Angular đó. Code của mình lúc nào cũng dài gấp đôi bởi vì có khá nhiều document và comment.

Điều mình cuối cùng học được

Document cũng nhiều khi là xạo thôi. Khá dễ dàng để nghĩ rằng document là 1 giải pháp giải quyết tất cả. ‘Chúng tôi cần doc!’ Trong khi mình chưa đưa ra kết luận rằng chỉ vì doc là công việc khó nhằn, không có nghĩa là nó không đáng để làm 1 chút nào, mình học được rằng bạn phải “doc” lại đúng thứ theo đúng cách. Quá nhiều doc cho những thứ không cần thiết thường dẫn tới sự cứng nhắc, vốn có thể gây nhầm lẫn tới người đang cố fix 1 vấn đề nào đó.

Ưu tiên automation hơn “doc” nếu được. Các test hay automation thường đi chung với nhau. Cho nên thay vào đó, mình cố tập trung về việc viết test, để các lập trình viên làm việc với code của mình có thể nhìn được các function của project với code đang hoạt động.

Technical debt khá là tệ

Có khoảng thời gian, mình nghĩ rằng bất cứ code ‘lộn xộn’ đều là technical debt. Technical debt là 1 cụm từ khá hài hước bởi vì nếu bạn hỏi mọi người để cho bạn 1 thí dụ để chỉ ra nó là cái gì, thì sẽ có rất nhiều câu trả lời khác nhau.

Cho nên với tư cách là 1 người đã xem bất kỳ code ‘không đúng trật tự’ nào là technical debt, mình ngay lập tức cố để loại bỏ nó với cái rùng mình cùng cực.

Từng có 1 lần, mình thực sự dành nguyên cuối tuần để fix thủ công tận 800 linting error.

Mình biết mình đã quá rảnh rang (Dĩ nhiên đó là khi auto-fixing được ra đời)

Điều mình cuối cùng học được

Code không theo trật tự hay lộn xộn và technical debt hoàn toàn khác nhau. Chỉ bởi vì 1 thứ gì đó không ‘đẹp đẽ’ cho lắm không có nghĩa nó là technical debt. Technical debt thực sự sẽ làm bạn chậm lại theo nhiều cách, hay làm 1 số dạng thay đổi phức tạp hoặc dễ bị error. Nếu code chỉ hơi lộn xộn 1 chút, thì đơn giản là nó hơi thiếu trật tự chút thôi, và làm gọn nó có thể hơi tốn thời gian chút.

Có vài technical debt là chuyện bình thường. Đôi khi chúng ta đi đường tắt bởi vì chúng ta cần chút thời gian, và vì vậy chúng ta từ bỏ ‘tốc độ’ của mình trong tương lai. Có nhiều phần code thực sự dính ‘technical debt’ cũng ổn thôi, miễn là bạn nhận ra được bạn sẽ phải cần để trả phần nợ đó lại sau. Nếu bạn nghĩ codebase của mình không có technical debt nào, có nhiều cơ hội là bạn đang đánh bóng quá mức thay vì tự nhìn nhận lại. Và mình cũng từng bị như thế rồi!

Có thâm niên = giỏi lập trình

Vì đã bắt đầu code từ khi còn nhỏ, mình  khá thành thạo trong việc thực hiện các vòng lặp (hơn 15 năm kinh nghiệm). Đối với mình lập trình cũng gần như việc mình thở vậy. Khi 1 giải pháp đã rõ ràng, mình có thể chỉ cần gõ theo và code sẽ đi theo sau. Cũng giống như viết bài blog hay email. Mình có thể code ra giải pháp nhanh hơn bất kỳ ai, và thường đảm nhận các dự án phức tạp hơn cho bản thân.

Trong 1 thời gian dài, mình nghĩ rằng đó là ý nghĩa của việc trở thành 1 lập trình viên senior.

Sao lại không chứ? Chức danh công việc của mình là ‘lập trình viên senior’,  chứ không phải ‘người giao tiếp senior’ hay ‘quản lý dự án senior’. Nên mình nghĩ là mình không cần phải thêm nhiều kỹ năng khác cho việc lập trình để thành 1 lập trình viên senior thực sự.

Điều mình cuối cùng học được

Kỹ sư senior phải phát triển nhiều kỹ năng bên cạnh việc lập trình. Số lượng kỹ năng mà mình phải phát triển trong thời gian đó là vô số kể, so với những gì mình thực sự nắm được. Trải dài từ giao tiếp và quản lý phụ thuộc tới chia sẻ bối cảnh, quản lý dự án, ước tính và công tác thành công với các đồng nghiệp không phải là lập trình viên. Những kỹ năng này ít có thể xác định số lượng hơn và cần nhiều thử nghiệm và sai sót để hoàn thiện.

Không phải ai cũng trở thành ‘senior’ trong sự nghiệp của họ. Thâm niên trong nghề là kết quả của nhiều năm tích lũy kinh nghiệm. Và chưa hết, nhiều năm kinh nghiệm là chuyện cần thiết, nhưng chưa đủ điều kiện cho việc có thâm niên. Nó cũng phải là dạng kinh nghiệm phù hợp nơi bạn tiếp thu được những bài học phù hợp và áp dụng thành công những bài học đó trong tương lai. Đôi khi những bài học lớn hơn có thể mất cả năm hay nhiều hơn để tiếp nhận đầy đủ – đó là lý do tại sao nhiều năm kinh nghiệm vẫn khá quan trọng, ngay cả khi bạn là đã là 1 coder giỏi.

Chúng ta vẫn còn là 1 junior trong vài lĩnh vực khác. Không quan trọng là bạn có bao nhiêu năm kinh nghiệm, vẫn có nhiều lĩnh vực khác mà bạn không biết nhiều về nó.
Thừa nhận những gì bạn không biết là bước đầu tiên để lấp những khoảng trống đó và nhận sự giúp đỡ từ những người có nhiều kinh nghiệm.

Lời kết

Bài học số 1 mà bạn đã học được khi trở thành 1 lập trình viên junior là gì? Hay bài học hàng đầu mà bạn đang phải đối mặt, hãy chia sẻ nó với mình nữa nhé!

Topdev via Freecodecamp

Tìm việc IT lương cao, đãi ngộ tốt trên TopDev ngay!