Tôi là Phạm Huy Hoàng, một developer.
Thuở còn là sinh viên, tôi từng có những thắc mắc, trăn trở về technical, về con đường nghề nghiệp, nhưng không có ai giải đáp. Blog này là nơi tôi chia sẻ những kiến thức, kinh nghiệm mà mình đạt được trong quá trình làm việc và trải nghiệm. Mong rằng nó sẽ giải đáp phần nào những khúc mắc, trăn trở cho những bạn sinh viên như tôi ngày xưa. Cảm ơn bạn đã bỏ thời gian đọc những dòng tôi chia sẻ.
Mấy năm gần đây, ngành IT luôn được “gắn mắc” là một ngành hot, việc nhẹ lương cao, nhu cầu tuyển dụng nhiều vô số. Do vậy, có rất nhiều bạn được truyền cảm hứng, đam mê trở thành lập trình viên, “cắm đầu” vào học ngành này!
Tuy nhiên, không phải ai cũng phù hợp theo ngành này. Làm developer có rất nhiều cái sướng, nhưng đi kèm với nó là nhiều trả giá/đánh đổi mà không nhiều người biết.
Vì vậy, trong bài này, mình sẽ chia sẻ thêm về những đánh đổi, trả giá mà bạn phải chấp nhận nên muốn theo ngành này. Nếu đọc xong mà thấy “sợ” quá thì bạn nên chọn ngành khác phù hợp hơn nhe.
Truyện kể rằng, thuở xưa có người tên Tôn Tử, người Lạc An nước Tề. Vì nội chiến nên phải dời tới kinh đô của nước Ngô, ẩn cư rồi chuyên tâm nghiên cứu binh pháp.
Sau nhiều năm ẩn cư, quan sát thế sự và kinh nghiệm tác chiến của các bậc tiền nhân, ông đã viết ra cuốn: "Binh Pháp Tôn Tử" đồng thời xuất sơn phò tá vua Ngô.
Kể từ đó nước Ngô bách chiến bách thắng, uy chấn thiên hạ.
Binh pháp Tôn Tử tuy viết rất nhiều về kinh nghiệm chiến tranh, cách chiến thắng mọi trận chiến. Thế nhưng, Tôn Tử lại cho rằng cảnh giới cao nhất chính là … không chiến mà vẫn thắng.
Đọc đi đọc lại một hồi, mình ngẫm thấy điều này cũng khá đúng với ngành lập trình. Do vậy, mình chia sẻ trong bài này để anh em cùng nghiền ngẫm nhé!
Câu chuyện bắt đầu với một cậu Junior ở công ty phần mềm Ép Dê Dê (hoặc cty F cho gọn) – là tui
Thuở đó, Code Dạo chỉ là một thanh niên lông bông vừa ra trường, biết dăm ba cái C# MVC mà đã tưởng mình gì cũng giỏi. Nhận bằng tốt nghiệp, vừa mở sẵn cái CV trên VietnamWorks rồi nằm đung đưa đợi ở nhà nhà thì đã có công ty nọ gọi đi phỏng vấn.
Chả nhớ chém gió kiểu gì mà phỏng vấn hôm trước hôm sau đã gọi offer, mình nhận luôn.
Trái với giang hồ đồn đại, công việc của mình hồi đó khá nhẹ nhàng, không bị OT bao giờ. Sáng 9h vào làm, đọc voz và web trẻ thơ đến 11h, code nửa tiếng rồi đi ăn. Ăn xong về ngủ, 2h dậy đọc voz tới 3h, sau đó code tới 4h30, điền timesheet rồi chen chân lên xe buýt về nhà nghỉ ngơi.
Mấy tháng đầu đi làm, mình chỉ được làm những công việc “ruồi bu” như fix bug, sửa text, sửa layout, đọc document, họp hành báo cáo. Phỏng vấn về Web MVC và vào chỉ làm WPF.
Mình đã tự trấn an: “Chỉ cần skills vững là được, ở đâu không quan trọng, hữu xạ tự nhiên hương!” Nhưng thực tế đã cho mình một cú vã sấp mặt, mình quen dần với cuộc sống làng nhàng, sáng lên xe bus tối về nhà, cái “hữu xạ” của mình không còn đủ sức “tự nhiên hương” trong một môi trường như vậy nữa.
1 dev buồn chán không thể trở thành 1 dev hào nhoáng
Lúc đó mình mới bàng hoàng nhận ra rằng chính mình phải tự bắt lấy những cơ hội khác tốt hơn. Và kết quả các bạn thấy đó, có một Code Dạo thường xuyên chém gió cùng anh em như hiện giờ.
Cụ thể, mình đã làm điều đó như thế nào?
Xin lưu ý, phần này không phải để review hay bóc phốt công ty, cũng không phải để quảng cáo.
Trải qua 5-6 năm trong cuộc đời code dạo. Mình rút ra một phương châm hành nghề cơ bản rằng: Cơ hội không bao giờ thiếu, chỉ cần bạn biết tìm chúng ở đúng chỗ, và đúng cách. Một vài tips cơ bản dành cho các bạn:
Chủ động ngắm – bắn công việc mà bạn muốn
Ngành IT trước giờ vẫn hot, tại sao vẫn phải chủ động? Nếu có ai thắc mắc điều này thì mình xin giải đáp: đơn giản là thế chủ động luôn mang lại lợi ích lớn cho bạn.
Ví dụ bạn nghe đồn về môi trường công ty A rất tốt và phúc lợi siêu xịn đã lâu nhưng chưa có cơ hội gia nhập, thì điều bạn cần làm là ghim ngay website việc làm lên bookmark bar, mỗi ngày refresh 1 lần xem có job nào của công ty đó mở chưa.
Nhiêu đó chưa đủ, follow luôn facebook, đặt See First, có bạn bè nào đang làm ở đó thì nhắn nhỏ 1 câu: Ê khi nào có job hú tau liền nhé!
Việc chủ động ngắm – bắn này giúp bạn tự chủ, tự tin và tự chịu trách nhiệm với lựa chọn của mình (đương nhiên). Bản thân mình cũng đã trải qua dăm ba lần chóng đến rồi cũng chóng đi nên mình hiểu, chỗ ngồi code thì muôn hình vạn trạng, chịu khó bỏ thời gian tìm hiểu kĩ một tí, chứ để ngồi vào rồi mới thấy không vừa, rút ra không có dễ đâu à!
Buồn của dev
Rõ ràng mục tiêu và lộ trình sự nghiệp của mình
Cái này tưởng đơn giản nhưng thật ra không hề. Bạn cần biết rõ mình muốn gì để xác định “chỗ ngồi code” hiện tại có phù hợp với bạn không. Nhưng cuộc sống luôn có ups and downs, VD bạn muốn up skills thật nhanh thì nên tìm kiếm cơ hội được tham gia vào các big projects và đồng thời chịu thức đêm debug trong khi bạn bè với công việc tàn tàn đã yên giấc nồng.
Người ta hay nói Dev chọn việc chỉ cần lương cao là được, nhưng kinh nghiệm cá nhân mình thấy rõ là những yếu tố môi trường khác cũng ảnh hưởng không nhỏ tới “chỉ số hạnh phục” của tụi mình. Quay lại câu chuyện phía trên của mình, nếu mình vẫn yên vị với job Junior việc nhẹ lương cao đó, hẳn đã không có Code Dạo đang chia sẻ về việc chọn “chỗ ngồi code” với các bạn rồi.
Đã có cách, thế còn chỗ thì sao?
Demo luôn cho các bạn một chỗ mà mình đã tự trải nghiệm và QA/QC chất lượng: VietnamWorks InTECH (tiền thân là topITworks).
Nói sơ một tí, đây là brand tuyển dụng dành riêng cho nhóm ngành IT của VietnamWorks, với “tuổi đời” lâu năm trên thị trường việc làm trực tuyến, trên site luôn có tầm 900 – hơn 1000 jobs uy tín.
Ngoài ra InTECH đã và đang tổ chức rất nhiều hoạt động thú vị và bổ ích để anh em trong ngành giao lưu và kết nối.
Giao lưu kết hợp từ online tới offline luôn đó
Tạm kết
À cuối cùng, bài viết này đã có quảng cáo, không có tiền thì ngồi code làm sao!
Nhưng yên tâm đi, tui tin các bạn sẽ tìm được một “chỗ ngồi code” xịn hơn với sự trợ giúp của VietnamWorks InTECH. Thử ngay nhé!
Ở 2 phần trước, mình đã chia sẻ về những việc cần làm khi hệ thống sập bất ngờ, nên viết post motern như thế nào để tránh gặp phải những sai lầm tương tự.
Tuy vậy, như các cụ đã nói “phòng bệnh hơn chữa bệnh”, phòng chống hệ thống sập thì tốt hơn là chờ hệ thống tèo rồi mới sửa chứ nhỉ. Do vậy, ở kì này, mình sẽ chia sẻ những kinh nghiệm phòng chống nhé.
Ở kì trước, chúng ta đã cùng bạn Hùng xấu số tìm ra lỗi, khôi phục hệ thống chạy lại như thường. Ở kì này, chúng ta sẽ cùng tìm hiểu về những điều chúng ta nên làm, cách viết post-moterm sau khi sự cố xảy ra nha.
Những điều này tuy nhỏ nhưng vô cùng quan trọng, vì nó giúp chúng ta tránh được những sai lầm tương tự trong tương lại đấy.
Một chiều thứ 6 đẹp trời nọ, Hùng đang thư thả về nhà, dắt gấu đi chơi cuối tuần, đi ăn khuya. Ăn uống no say, Hùng dắt gấu vào nhà nghỉ (tất nhiên là chỉ để nghỉ thui nha, blog này cho cả các bạn chưa đủ 18 tuổi).
Vào đến nhà nghỉ, Hùng vừa mới tuột quần, chuẩn bị … chạy thẳng vào toilet (chắc do nồi lẩu vừa ăn không sạch lắm). Bỗng dưng, di động reo, anh Sơn team leader trên công ty réo: Hùng ơi, hệ thống sập con bà nó rồi, khách hàng không vào được trang chủ, em lên công ty phụ anh và anh Kha kiểm tra với.
Vội vàng chưa kịp mặc quần, bỏ gấu nằm bơ vơ trong khách sạn, Hùng bắt vội chiếc Grab chạy thẳng lên công ty để tìm lỗi… Còn tiếp!
Hôm trước, mình có làm livestream nhẹ về kinh nghiệm làm việc tại công ty startup/product, kinh nghiệm làm blockchain với anh Trần Hoàng Giang – Giảm độc sản phẩm của AkaChain.
Do clip hơi dài nên mình tóm tắt lại 1 vài cái hay ho mà 2 anh em chém gió cho các bạn nhen:
Có phải làm outsourcing/IT services chỉ là gia công “đưa gì code nấy”, như “thợ hồ công nghệ”? Tuỳ dự án, ở tầm IT Services thì chúng ta sẽ lo toàn bộ từ architecture design, UI/UX Design, vận hành hệ thống, tư vấn cho khách hàng, chứ không chỉ là đi kiếm requirement rồi làm việc.
Nên làm outsourcing/IT services hay làm product/sản phẩm? Mỗi thứ đều có cái hay riêng. Làm IT services sẽ học được về qui trình, document, domain của khách hàng nhưng hơi gò bó. Làm product thì vui hơn, được quyết định nhiều thứ hơn, nhưng cũng khó khăn và phải mò mẫm nhiều hơn.
Làm product/startup có gì vui? Làm ra sản phẩm thật, có user dùng chứ không chỉ là code rồi bàn giao. Dev ở product/startup có tiếng nói hơn, được tham gia quyết định hướng đi của sản phẩm.
Muốn làm product/startup thì cần những tố chất gì? Phải biết ôm đồm nhiều thứ như full stack, đôi khi nhảy cóc từ front-end, back-end tới DevOps. Phải có cái nhìn sản phẩm, code 1 chức năng cũng biết suy nghĩ cho người dùng chứ không chỉ thuần là code
Về AkaChain (akachain.io): AkaChain là 1 hệ thống định danh điện tử, dựa trên công nghệ blockchain, hỗ trợ các doanh nghiệp thiết lập hệ thống điểm thưởng, chăm sóc khách hàng mà vẫn đảm bảo tính privacy.
Kinh nghiệm tự tìm hiểu blockchain: Đừng cố gắng build một 1 blockchain ngay từ đầu, mà hãy thử build ứng dụng dựa trên cái có sẵn, vừa làm vừa tìm hiểu dần dần.
Một số kĩ năng cần có để làm về blockchain: Lập trình back-end (Golang, Rust hoặc NodeJS), hiểu biết về Server/DevOps, cách triển khai các hệ thống phân tán
(30s quảng cáo) Tại akaChain nói riêng, cũng như FPT Software nói chung, có khá nhiều dự án làm product hay ho, các bạn mới ra trường hoặc thích làm product có thể tìm hiểu nhé.
Các bạn quan tâm có thể xem clip full 60 phút không che tại đây nha:
Chuyện kể rằng, vào thời thế chiến thứ 2, binh lính Mĩ lần đầu tiên tiếp xúc với các thổ dân ở nhiều quần đảo thuộc vùng Melanesia.
Vì nhu cầu chiến tranh, quân Mỹ/Nhật chở hàng loạt tàu hàng, cho máy bay thả hàng tiếp tế (thức ăn, lương thực, vũ khí) xuống, làm đời sống nhân dân trên đảo được cải thiện.
Khi chiến tranh kết thúc, hàng hoá cũng hết theo. Cư dân trên đảo bắt đầu bắt chước hành động của binh lính Mĩ. Họ cũng dựng chòi canh, khắc gỗ làm radar headphone, quơ quào trên đường băng như binh lính liên lạc.
Cư dân trên đảo làm giả máy bay, headphone, đài phát sóng; với hi vọng máy bay thật sẽ quay lại
Dân chúng bắt đầu làm theo những nghi lễ này, với hi vọng máy bay sẽ quay lại, mang theo những thùng hàng tiếp tế. Tất nhiên là, dù họ có quơ quào cả năm trời, cũng chẳng có chiếc máy bay nào quay lại cả.
Dần đà, những thứ này trở thành nghi lễ, được thờ cúng. Những tôn giáo, nghi lễ dạng này được gọi là cargo cult (cargo là hàng hoá được chuyên trở trên tàu).
Ơ, chuyện nghe thú vị đấy, nhưng mà nó có liên quan gì đến lập trình đâu?? Ấy vậy mà có đấy!
Từ coder đến developer - Tôi đi code dạo 