Những điều không ai dạy bạn về ngành Phần mềm P2
Tại sao nên đọc bài này?
- Để bạn có một cái nhìn đa chiều hơn về ngành phần mềm, không phải hoàn toàn là việc nhẹ lương cao như thằng em sn 96…
- Một số sự thật khó tiêu hóa trong ngành phần mềm. Có khi nó giúp bạn nhận ra và unlock được một level mới
Nối tiếp phần 1 được rất nhiều người đón nhận, thì đây là phần 2222222 ✌️
Disclaim lại lần nữa: Đây là bản dịch từ bài gốc https://vadimkravcenko.com/shorts/things-they-didnt-teach-you/ dưới lời văn đã thay đổi nhiều cho phù hợp với cảm nhận của bản thân mình 😆. Khuyến khích mọi người đọc cả bài gốc lẫn bài của mình để có nhiều góc nhìn hơn.
Tác giả cũng ok với chuyện dịch lại, miễn là để lại link
Gét gô 💨
Bạn lúc nào cùng sống trong trạng thái mập mờ (Uncertain time)
Đối phó với con người đã khó, đối phó với trạng thái mập mờ còn khó hơn. Và đỉnh cao của khó khăn là đối phó với những con người mập mờ 
) Và đó đích thị là những gì bạn phải làm khi trở thành một software developer
Con người thì thường chả biết họ muốn gì, và đôi khi họ không nhận ra là thay đổi cái feature này một tí thôi là phải code ở dưới tới sấp mặt. - “Ê em đổi tích hợp thanh toán Momo thành Zalo giúp anh với, tích hợp ví thôi mà phải không? 😜”
Câu lừa vĩ đại nhất khi ở trường đại học dạy bạn là sẽ có một anh Prj Management đưa cho bạn một task chi tiết, cẩn thận, chỉn chu những gì cần làm, và việc của bạn chỉ là biết nó thành code thôi - một bản mô tả chi tiết công việc…mập rõ. Rồi cuối ngày bạn làm xong task được giao, đúng yêu cầu, đúng thời gian, vỗ vai nhẹ anh PM nói rằng “tối nay đi uống rượu không, em baoo. ez job, ez life”
Nhưng thực tế là PM sẽ luôn xuất hiện lúc bạn sml nhất và nói rằng “Chúng ta cần làm thứ gì đó để làm được A, tuy nhiên chưa có design, tụi 3rd party hay backend cũng chưa ready đâu, nhưng cứ thử làm trước đi”… Rồi sau đó sửa sml. Và nó đích thị là công việc thật sự mà một Software Engineer phải làm, đi gom lại hết requirement mọi nơi, rồi tìm xem là mình thật sự cần làm gì.
Okey thì chuyện đi gom góp requirement thì chả phải dễ dàng gì. Nó cũng không vui vẻ như việc viết code, vì rõ ràng mà, nói chuyện với máy tính thì vui vẻ hơn là nói chuyện với PM, với sếp, với client, với design hay là một ông backend nào đó. Nhưng nó lại là thứ tốn rất nhiều thời gian để hoàn thành công việc, vì nó phải làm việc với con người, không phải là máy móc. Bạn phải nói chuyện với bên 3rd party xem cái gì làm được cái gì không, hỏi designer xem làm kiểu này được không, và quan trong nhất là hỏi sếp/client xem người ta muốn cái feature đó trông như thế nào.
Để có thể yên vị code những dòng đầu tiên thì phải mất chắc cả tuần để làm những việc trên. Tìm hiểu requirement là gì, chỗ nào có thể hỏi được, rồi xem coi cái gì build được cái gì không, à còn cả phải tìm hiểu thêm chỗ nào có thể toang (vì thiếu data, vì design đẹp quá không code được,…) rồi mới có thể code được.
💡 Đoạn chữ in nghiêng sẽ là ý thêm của mình nha
Sau khi đọc comment của bài trước thì nhiều bạn/anh/chị nói lại tại mỗi trường nhỏ lẻ nó mới vậy, thử làm những công ty lớn như FPT, KMS,… đồ thì quy trình rất rõ ràng, PM viết task detail đầy đủ.
Thực tế là mình chưa từng được trải nghiệm môi trường như vậy nên mình cũng không rõ nó như thế nào. Mình đã từng làm ở một cty out-source dạng vừa, với hơn 20 prj lớn nhỏ, từ intern tới vị trí lead, đã từng làm ở công ty product với sản phẩm là top 1 market, từ vị trí bình thường tới senior. Và mình công nhận điều ở trên là đúng - ít nhất đối với mình. Sẽ luôn luôn có task mà mọi thứ chưa sẵn sàng, và mình phải tự đi mày mò xem cần những gì, và có thể làm gì. Mình cũng đã từng phải nhờ các bạn trong team làm điều tương tự.
Do đó, dưới góc nhìn của mình, chuyện này khá là đương nhiên và thậm chí mình còn thích điều đó. Bởi vì, nếu không tiếp xúc với nhiều bên thì làm sao mình biết thứ mình làm có đúng không, có value không. Và nó cũng giúp mình thấu hiểu được các bên khác quan tâm điều gì, kiểu như Backend thì quan tâm data input, scaling,… Design thì quan tâm usability, spacing,…
Và cảm ơn những khoảng khắc như vậy mà nó khiến cho mình phát triển trong sự nghiệp tốt hơn, vì nếu mình hình dung chỉ code y chang như những gì được mô tả, thì mãi mãi mình cũng chỉ như cái máy dịch - chuyển ngôn ngữ con người qua ngôn ngữ máy mà thôi. Cái đó hiện tại có khi còn làm không tốt hơn ChatGPT nữa rồi kìa 😛
Cho rằng mọi thứ đều có thể tồn tại bug 🐞
Một số quan niệm sai lầm mà rất nhiều các bạn dev gặp phải
- Bạn hiếm khi tin vào code trong prj của mình, bởi vì bạn cũng chỉ là con người thôi, và con người thì make mistake
- Thư viện, 3rd party cũng có thể có bug, nhưng có thể hiếm hơn vì chắc là tụi nó trình cao hơn mình
- Mấy thư viện của OS hay siêu nổi tiếng rồi thì chắc KHÔNG THỂ NÀO có bug đâu nhỉ? Mấy người viết code đó toàn siêu nhân.
- CPU/Hardware chắc không bao giờ toang đâu. Tụi nó tốn cả chục năm nghiên cứu ra mà, tiến trình 7nm đồ
Điện thì méo thể nào biến mất được(Okey cái này thì ở VN mà nói ra thì người ta nói thằng này bị điên))
Nhưng sự thật là - chúng ta - lập trình viên KHÔNG BAO GIỜ được chắc chắn là code của mình, library, hay thậm chí là phần cứng sẽ không bao giờ có bug. Ngay cả mấy người não to làm ra những thứ đó thì cũng là người mà thôi
Không tin hả, nhìn vào thử Github Issue mấy thư viện mà bạn sài đi, ngay cả repo của OS thì bạn sẽ thấy cả tỷ issue trong đó, và library càng nổi tiếng thì càng nhiều.
Bằng cách suy nghĩ là “cho rằng mọi thứ đều có thể tồn tại bug” thì sẽ giúp cho dev dễ dàng có cách phòng chống, hoặc là “sống chung với lũ” hơn. Và nó là một thứ cực kì cần thiết để build một hệ thống ổn định và đáng tin cậy.
À cách đối phó của mình với chuyện này cũng khá đơn giản. Mình hay thấy các bạn newbie khi code luôn có suy nghĩ là bug chỉ ở trong khoảng từ line 2 tới 4, và bạn dành cả ngày để thử sai, chỉ ở trong phạm vi code 2 tới 4 đó. Nhưng nếu suy nghĩ bug ở có thể ở khắp mọi nơi, thì mình sẽ luôn phải test xem bug có ở từ line 1-2 không, có thể từ line 4-100 không, hay nằm ẩn trong thư viện nào không. Dĩ nhiên, bạn phải có cách verify bug nằm ở đâu và không nằm ở đâu - Và mình tin đây là một kĩ năng CỰC KÌ quan trọng và cần thiết khi làm software
Đây méo phải là công việc mơ ước
Không quan tâm bao nhiêu video YouTube, Tiktok, bài viết, báo chí, thầy cô, bạn bè, voz, toingoicodedao tung hô về ngành lập trình. Nào là thằng em sinh năm 96, nào là nhân viên của Google, Facebook,… nào là lương lập trình viên tận trời xanh. Tất cả chỉ là bề nổi của tảng băng 🤷♂️
- Nó là một công việc cũng khá nặng nhọc đó. Bạn phải ngồi với máy tính cả ngày
Hiếm khi có work-life balance. Thử hỏi bug production lúc giữa trưa hay đêm khuya xem?Hiếm khi bạn build một thứ mà bạn thật sư thích nó. Bạn làm theo những gì client, PM yêu cầuCơ hội nghề nghiệp không tốt lắm. Ngay cả khi bạn là thằng perform tốt nhất.- Công việc stress vl. Deadline, bugs, QA, kì vọng từ khách hàng
- Làm việc remote thì cũng cool đó, nhưng sẽ tới lúc bạn bị tách rời khỏi thế giới. Vậy là kĩ năng tương tác với xã hội sẽ ngày càng mờ nhạt đi
- Không an toàn lắm. Công nghệ thì thay đổi xoành xoạch, lứa trẻ thì xuất hiện như quân Nguyên - vừa đông vừa hung hãn. Hôm nay còn được trọng vọng nhưng hôm sau bị layoff lúc nào không hay 🥲
Mấy cái gạch chữ thì mình thấy không đúng lắm. Work-life balance thì là do lựa chọn thôi, còn bản chất nghề nghiệp này không cho work-life balance thì mình thấy chưa đúng. Thích hay không thì còn tùy trình độ và cái tôi của bản thân nữa, nếu thứ bạn thích và nó có value thì nó ok, còn thứ bạn thích mà nó không có value thì nên làm một mình thôi. Cơ hội nghề nghiệp thì mình thấy tràn ngập, thực tế mình rất thích những người làm tech xong chuyển hướng, họ có suy nghĩ cực kì là logic. Còn lại hầu hết mình thấy mọi người khá yên phận khi làm dev, kiểu làm dev thì sau này làm dev vẫn ok á, không có kiểu tao lm z thôi, sau này tao làm nghề khác
Code đẹp đỉnh cao không thể dạy được
Okey, bạn có thể học code đẹp, đọc clean code, nhưng code dạng đẹp đỉnh cao thì không thể dạy ở trường học được.
Code đẹp đỉnh cao được định nghĩa là nhìn qua overall là có thể cảm nhận được là người viết ra code này đỉnh vkl. Nó sẽ kiểu dễ đọc, để hiểu, dễ sửa, nhìn chỉn chu ngay hàng thẳng lối lắm. Sẽ có những code mà bạn thấy đẹp nhưng sửa thì không dễ, và ngược lại,… nhưng code mà cover được hết những thứ đó thì người viết ra nó phải có kĩ năng thượng thừa lằm
Xui cái là, code được như vậy thì không thể học ở trường được. Nó là thành quả của rất nhiều, rất nhiều kinh nghiệm, rất nhiều trăn trở, rất nhiều lần đọc code thì mới có thể tu luyện được.
Kiểu gì cũng có người hỏi khi nào làm xong em? Làm bao lâu em? trong khi bạn cũng méo biết, hay méo muốn phải trả lời
Mấy sếp, thì thích số, thích estimates, và thích hỏi luôn khi nào thì em làm xong. Và thế giới thì vận hành như vậy đó - một cái biz luôn muốn đạt được điều gì đó, nhưng trước khi bắt đầu start, họ luôn muốn/phải biết cái giá phải trả là bao nhiêu. Và estimation là một đại lượng để biết cái giá đó là bao nhiêu
Okey, cái này thì chả thể nào dạy được ở trường đại học, và nó cũng là thứ mình thấy rất nhiều bạn bất ngờ khi đi làm bị hỏi estimation. Và các bạn phải rèn luyện nhiều thì mới trả lời được câu hỏi đó, phải biết năng lực bản thân mình, phải biết hệ thống đang chạy, phải biết code đang như nào, phải biết yêu cầu ra sao, thì mới có được câu trả lời. Và bạn càng đối mặt với nhiều vấn đề khác nhau thì kĩ năng này của bạn sẽ càng được cải thiện
Mình sẽ không thảo luận cách tốt nhất để estimates ở đây, bạn tự search Google hay hỏi chatGPT đi, nhiều lắm. Điều mà mình muốn nói ở đây là estimates là thứ duy nhất mà người làm biz hiểu và sử dụng được. Nếu bạn nói rằng “Chúng ta có một plan lâu dài cho cái này, nhưng tao cũng không biết khi nào hoàn thành nó”, thì thử hỏi, ông biz phải làm sao phải làm sao
Không phải tất cả cuộc họp đều tệ
Làm Dev mà hiếm khi được code, vậy thời gian đi đâu? Đi họp
Họp hành để đảm bảo mọi thứ mượt mà và đúng deadline. Nó giúp cho mọi người hướng tới cùng một mục tiêu. Team marketing biết rằng mấy ông dev đang làm gì đó, và họ thì chuẩn bị content, hình ảnh để lên bài khi release. PM thì muốn biết được dev đang làm gì, có đúng hướng không đặng biết đường còn chỉnh lại. Customer support thì đưa ra những feedback/bug mà khách hàng gặp phải,… vân vây mây mây
Mọi thứ, mọi thứ đều kết nối với nhau, và đi họp là cách để kết nối mấy thử đó. Với vai trò là một dev thì trách nhiệm của bạn cũng là một điểm để kết nối với team, công ty, khách hàng,… Bạn có thể không thích đi họp nhưng đó là trách nhiệm của bạn trở thành một mắt xích trong bộ máy công ty để nó vận hành trơn tru hơn.
Kết luận
Nếu bạn cân nhắc bắt đầu dấn thân vào con đường làm một Lập Trình Viên, thì hãy chuẩn bị để đối mặt với những vấn đề như trên, cố gắng, nắm bắt cơ hội và phát triển. Tới cuối thì có khi bạn cũng chẳng thể thay đổi thế giới gì đâu, nhưng tới cuối thì, nó cũng chỉ là công việc thôi mà, bạn không đóng góp cách này thì bằng cách khác, không thay đổi cả thế giới thì thay đổi… thằng đồng nghiệp cũng được.
Và điều quan trọng nhất, hãy tìm niềm vui trong đó.
Còn điều gì khiến bạn vỡ mộng khi mới bắt đầu đi làm, comment bên dưới nhé!
Những bài viết “lan quyên”
All rights reserved
