Bài viết được sự cho phép của tác giả Thanh Lê
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 dung của bài viết này sẽ được dịch từ bài gốc ở trên, dĩ nhiên là dưới góc nhìn của mình, có thêm bớt khá nhiều. Tác giả cũng disclaim là đây cũng chỉ là góc nhìn chủ quan của tác giả. Tuy nhiên mình thấy đây là bài viết cực kì hay về ngành mà mình đang làm.
Bác nào giỏi tiếng anh thì nên đọc bài gốc và skip qua bài của mình cũng được nhé. Đọc xong back lại đây comment cũng được .
Gét gô!
Bạn hiếm khi được code thứ gì đó từ đầu
Khác với trường học, nơi mà mọi bài tập của bạn đều chỉ có đề bài mà một màn hình trắng xóa, bạn fill code vào, chạy thử, fix bug, nộp bài. Dù đó có là học giải thuật hay là học một số môn lập trình thực tiễn hơn, hầu hết đều như vậy. Mục đích là thể hiện trình độ cá nhân của bạn.
Nhưng thực tế thì sao? *éo . Dù bạn mới ra trường, đi thực tập, đã đi làm được đôi ba năm hay thậm chí cả chục năm. Thứ ném vào mặt bạn là một project với vài ngàn dòng code (hoặc vài triệu) với vô vàn dấu chân của những dev trước để lại, có những người là thực tập, những người là junior, những người là senior… và bạn. Hiếm khi bạn được start một thứ gì đó từ zero.
Bạn coi tới coi lui đống code, check qua từng file, check lại document. Và bạn tốn cả 1 tuần để hiểu xem mấy ông dev trước làm gì (tất nhiên là vừa làm vừa chửi ) để rồi thêm 10 lines code vào để fix một bug bé tí nào đó.
Đó làm coder là vậy đó, hầu hết thời gian của bạn sẽ là sửa những gì đang chạy, thêm feature vào dựa trên một cục code base có sẵn.
Kiến thức “ngành” (Domain knowledge) quan trọng hơn kĩ năng múa code
Mình thấy rất bất ngờ nếu mình hiều về một thứ gì đó thì việc coding của mình trở nên rất đơn giản. Mọi thứ chạy như thế nào, và tại sao nó lại cần chạy như vậy.
Ví dụ khi code app ngân hàng/fintech thì bạn tốt nhất nên hiểu transaction chạy như thế nào, sổ cái hoạt động ra sao
Khi build một hệ thống PoS (Poin of sale – mấy phần mềm để tính tiền, gọi món ở quán Trà sữa, nhà háng á) thì bạn nên tìm hiểu xem tụi nhà hàng nó hoạt động thế nào, chia ca, tồn kho, rồi còn các bước để quẹt thẻ,…
Và nó đúng với hầu hết các ngành khác như Y tế, Logistic, Xây dựng,..
Nếu mà không có mớ kiến thức ngành đó, bạn sẽ rất dễ bị lạc. Kiểu như bạn sẽ bị struggle vì mình chỉ code theo task thôi mà không hiểu ý nghĩa công việc của mình ở đâu á, chả biết mình code có đúng không, chả biết nó chạy ở đâu, chả biết nó đóng góp gì cho biz đang chạy ngoài kia, và bạn sẽ chả biết… thứ bạn làm có value ở đâu cả.
Mình đã nhận ra điều này là thực sự quan trọng đối với mình trên con đường làm phần mềm, nó khiến mình buồn khi user dùng app mà bug, nó khiến mình vui khi có ai đó dùng phần mềm mình làm và khiến cuộc sống của họ dễ dàng hơn, nó khiến mình tự hào khi có ai đó nhắc tới phần mềm mà mình đã làm. Việc vui buồn đó, phần nào, khiến cho mình kết nối với những dòng code và công việc nhiều hơn!
Ngoài ra kiến thức ngành cũng là một vũ khí cực kì tốt giúp bạn dễ dàng sống sót hơn ở ngành phần mềm. Kiểu như nếu bạn đã biết kiến thức ngành về banking thì rất dễ cho bạn kiếm một công việc khác tương tự và dĩ nhiên, có lương cao hơn.
Tham khảo việc làm Software Developer hấp dẫn trên TopDev!
Viết document không được đề cao lắm
Okey, back lại trường đại học thì họ nhấn mạnh vào việc coding, giải thuật nhiều hơn là việc viết ra những dòng code, bạn và đồng nghiệp đều hiểu, và viết cả document cho nó.
- Như đầu bài đã chia sẻ, bạn hiếm khi được code một thứ mới, do đó nếu bạn viết clean code hay có một document ngon lành sẽ giúp ích cho bạn, và những người sau bạn tiếp tục với cục code base hiện tại.
- Đi làm là làm việc theo nhóm, và bạn sẽ không được làm solo nữa. Nên bạn phải từ bỏ suy nghĩ tất cả đều đã được lưu lại trong đầu mình, mà phải share chung cho cả team.
Code là thứ Hai, kiếm được tiền mới là Chủ Nhật
Sẽ méo có ai tới và vỗ vào vai bạn nói rằng “VKL, làm được được việc đó trong 1 dòng code hả” (okey, thực ra ngoài đời thì vẫn có thôi, chỉ là mấy ông làm chung ngành nâng bi nhau ), mà thay vào đó họ sẽ nói kiểu “Hey ku, user thích cái feature may mới làm lắm” hay tệ hơn là “Thằng , m deploy cái gì mà sập cả website kìa”
Đôi khi nó nghe khá là WTF, nhưng
Công việc chính của Software Developer không phải là viết code mà là tạo ra value thông qua qua software, thứ mà họ đã viết
Code chỉ là công cụ để bạn tạo được value. Code → Software → Value
Thứ bạn viết ra, phải phục vụ một mục đích nào đó cho thế giới – một công cụ gì đó, hay là một đoạn automation giúp giảm chi phí, bất cứ thứ gì, mà có người chịu trả tiền cho nó (có thể bằng thời gian, tiền bạc hay sự chú ý).
Nếu bạn build ra một thứ gì đó với đống công nghệ như nhưng mang lại value cho users – bạn phục vụ một nhu cầu tất yếu của một software engineer. Nếu bạn build ra một thứ gì đó với mớ công nghệ cool ngầu nhưng éo ai thấy nó có value – xin lỗi tôi và bạn không cùng ngành.
Code clean, follow best practice, design pattern – mớ đó để giúp cho cuộc sống của những ông dev sau bạn đỡ vất vả hơn chứ mục đích tối thượng của nó không phải là tạo ra value. À dì nhiễn cũng giúp cho cuộc sống của bạn sau này dễ thở hơn, và cũng không phải bị những người sau vừa fix bug mà vừa đọc thầm tên bạn và … chửi.
Xem thêm Làm thế nào tôi trở thành một Software Developer tại Twitter?
Bạn sẽ phải làm việc với những thứ/người gà vkl
Trong môi trường làm việc, bạn sẽ phải làm chung với những người mà theo bạn nghĩ là “gà vkl”, nào thì code toàn bug, nào thì API không lúc chạy được lúc không, nào là design mỗi chỗ một màu khác nhau, hay lâu lâu con bé QA dở người,… Có khi đó là output của một người cùng công ty, có khi nó là ouput của khách hàng – một bên thuê bạn.
Nói chung thì bạn sẽ thấy khó chịu vkl thì phải đối mặt với những tình huống như vậy. Nó tạo ra một môi trường toxic, unproductive, poor decisions.
Tao (tác giả gốc, không phải mình) đã dành rất nhiều thời gian để tìm cách đổi phó với những loại người như vậy mà không phải trở thành một thằng , đáng ra trường đại học phải dạy cho mình mấy cái này chứ nhỉ?!
À có một cách tao (tác giả) ngộ ra là hãy tự tập trung vào công việc của bản thân và kệ người khác đi. Tìm một giải pháp thay thế nào đó hợp lý hơn và đừng có dây vào những người kém productive. Viết document thì cũng khá hữu ích, nó có thể trở thành “Bằng chứng thép” để cáo với sếp về mấy người unproductive đó .
Cuối cùng, cách tốt nhất để “đối phó” với mấy người đó là
- Tìm một giải pháp hay người nào đó có thể giúp mình
- Nhờ vả những người chuyên môn cao hơn làm task đó hộ mình
- Implement một số giải pháp kiểu code của tụi nó có hư thì bên mình cũng không bung bét ra (failsafe, fallback)
- 1-1 meeting với người đó và nói với họ là họ làm chậm process ntn
- Okey, không cần phải trở thành một thằng để chiến tranh với họ
Phần này mình dịch hoàn toàn như bên bài viết gốc. Còn đối với mình, thực tế mình đã từng rất nhiều rơi vào tình cảnh như vậy. Phần dưới là input thêm từ mình
Có lúc mình làm với Backend code api lúc up lúc down, mình khó chịu mình chửi thầm, có lúc mình làm với Design mà lệch alignment, mình khinh thường mình chửi họ, rồi cũng có lúc mình làm việc với QA và PM và mình code bug, họ là chê output của mình. Ồ mình nhận ra nếu bạn trong team nào thì bạn sẽ luôn luôn chê input của mình, và bị chê bởi output của mình.
PM → BE → FE → QA → PM
Và mình nhận ra mình khó chịu vì nó tổn hại tới cái tôi của mình. Nếu mà BE làm trễ deadline và mình sẽ cũng bị trễ theo, và mình đổ lỗi cho BE, để nuôi dưỡng cái tôi, để feel good vì do mày nên tao không làm được, chứ tao tốt đẹp vl . Đó đã có lúc mình suy nghĩ như vậy, nhưng được làm việc với nhiều team hơn, thử thực sự làm BE hay làm QA mình nhận ra một điều:
Mọi thứ luôn luôn broken ở software.
Mình không rành ngành khác như thế nào, nhưng đối với software, nó là soft, nên nó có thể tháo rất nhanh phần hư ra, hoặc fix phần hư rất nhanh. Nên ngành này vận hành theo cơ chế là ship một thứ gì đó chạy được cơ bản rất nhanh, rồi vừa chạy vừa fix. Do đó, sẽ luôn luôn có thứ broken. Và việc của mình không phải là đổ lỗi cho BE, Design hay PM làm broken, mà là khiến mọi thứ tiến về phía trước. Mình đồng ý với việc sẽ có lỗi từ BE, sẽ có lỗi từ Design, và cũng đồng ý với việc mình sẽ code bug, đôi khi sẽ bị QA dí như vì mình cũng tệ vậy. Và mình hướng tới việc làm sao để mọi người trong team phối hợp tốt hơn, và nếu là một lỗi sảy ra, thay vì đi tìm người gây ra cái bug đó, thì mình tìm cách để nó không xuất hiện lần thứ 2 hay thứ 3 như vậy nữa.
Mục tiêu chính của mình là deliver cái software đó, không phải là nuôi dưỡng cái tôi “thanh cao” của bản thân tôi thì tốt đẹp còn những người xung quanh thì tệ vkl.
Vậy đó, software luôn luôn broken, mà broken thì mới có việc để làm chứ không thì AI code hết mọe rồi.
À một point thứ 2 là đôi khi do một người trong team broken, hay thậm chí là khách hàng broken thì mình nghĩ là đơn giản thôi: CẮT. Nếu trong team thấy một người như vậy thì mình sẽ nói với họ và để họ thử và nếu họ không survive được thì chắc là “chúng ta không thuộc về nhau”. Ngay cả khách hàng cũng vậy, mình đã từng stoploss với 2-3 client vì làm việc không chuyện nghiệp
Wait, lỡ mình không có power cao bằng người ta nên mình không “chia tay” người ta được thì sao? Thì mình tự nói với bản thân rằng, thôi nếu vậy hạn chế chơi với ông này, đợi khi nào power mình cao hơn rồi tính vậy. Dù gì thì phải có lý do gì đó mà khiến ông đó có power cao hơn mình chứ, lỡ ông đó giỏi tiếng anh hơn mình thì sao, lỡ ông đó kì này có chuyện buồn gì sao,… chả ai muốn mình là broken person trong team cả, hẳn họ có một nỗi niễm gì đó,… Hoặc họ gà thật :)))
Thôi thì không thể thay đổi được thế giới, thử thay đổi bản thân vậy
Kết
Đầu năm nói những thứ phũ phàng khi đi làm chắc không đúng vibe lắm, nhưng dù muốn dù không thì bạn cũng sẽ phải đối mặt với nó, nếu bạn đi làm phần mềm. Thường bạn sẽ nghe tới ngành IT là lương chăm triệu, tháng làm 2-3 jobs, gái theo xếp hàng,… nhưng hiếm ai nói cho bạn những phần bên dưới của tảng băng – những sự thật khi đi làm.
Nghề gì cũng vậy, phải khó khăn thì mới có việc để làm, phải có khó khăn thì bản thân mới thể hiện được giá trị của mình chứ hả?
Còn tiếp…
>>> Xem thêm: Things they didn’t teach you about Software Engineering
Bài viết gốc được đăng tải tại thanhle.blog
Có thể bạn quan tâm:
- Những điều không ai dạy bạn về ngành Phần mềm (Phần 2)
- Cách viết CV dành cho Software Developer
- Một số lầm tưởng về big data của software engineer
Tìm việc làm IT mọi cấp độ tại TopDev
