Những sự thật không ai dạy bạn về Ngành Phần mềm (Phần 2)

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.

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

Tham khảo thêm các vị trí tuyển dụng Software Engineer tại Topdev

Cho rằng mọi thứ đều có thể tồn tại bug

1. 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

2. 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

3. 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.

4. 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 đồ

5. Đ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.

Đây méo phải là công việc mơ ước

• 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ầu

• Cơ 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

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.

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…

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é!

Bài viết gốc được đăng tải tại thanhle.blog

Có thể bạn quan tâm:

• Liệu Software Engineer có phải là nghề dễ ăn?
• Software engineer phát triển bản thân như thế nào?
• Biến Git và GitHub trở thành công cụ đắc lực cho Software Engineer