Câu chuyện về lạc quan, thì có lẽ nó bắt đầu từ một lần nói chuyện với đồng nghiệp của mình gần đây. Mình và colleague cùng discuss về một số chủ đề, công việc, sự nghiệp, ngành nghề, đủ thứ lung tung. Sau một hồi nghe mình thao thao bất tuyệt, thì tự nhiên bạn mình nói một câu làm mình cũng hơi khựng lại suy nghĩ một chút: “Tại sao anh nhìn mọi thứ nó lại lạc quan thế?”

Mình cũng tự ngẫm lại bản thân, và mình cũng thấy mình có cái nhìn khá lạc quan về cuộc sống hay công việc nói chung. Và mình cũng không ngạc nhiên nếu nhiều người có thể có cái nhìn bi quan về cuộc sống: Thế giới thì ngày càng có vẻ lộn xộn, kinh tế và xã hội có nhiều thứ thay đổi. Những người trong ngành của mình thì bắt đầu lo ngại về sự thoái trào của ngành Tech, về sự phát triển và thay thế bởi AI, rồi cũng gần với mình là lứa tuổi 35-40 mà nhiều người sợ bị xếp là “hết thời”, khó kiếm việc. Công việc thì đòi hỏi cao hơn, sức ép thì lớn.. Một tâm thế bi quan trong thời điểm này, có lẽ là điều dễ hiểu.

Thế thì lạc quan sẽ đến từ đâu? Bằng một cách nào đó, thì mình đã tự thuyết phục cho bản thân mình rằng lo lắng là một thứ vô ích. Khi một vấn đề làm bạn lo lắng thì sẽ luôn có hai trường hợp: (1) đó là vấn đề mà bạn không có khả năng can thiệp, như thế thì bạn có lo lắng hay không cũng vô ích (2) bạn có khả năng để can thiệp đến vấn đề đó, thế thì bạn nên dành thời gian để make it happen chứ ngồi lo lắng thì chỉ có tốn thời gian. Thế thì lo lắng để làm gì cơ chứ?? Và khi bạn không lo lắng nhiều thứ, thì tự nhiên nó cũng sẽ dễ suy nghĩ lạc quan hơn một chút.

Từ việc chỉnh lại góc nhìn của bản thân, thành những vấn đề có thể và nên giải quyết, mình tự xoay lại và thấy mình có một sự tự do nhất định, trong việc quyết định những thứ xảy ra với bản thân. Theo cách nói của các thought leaders thì đó là một concept như là High Agency (bạn có thể đọc thêm về nó ở đây). Nếu mình phải giải quyết một bài toán khó, thì mình sẽ đánh giá đó là một thử thách hay ho (“bài khó thì giải mới bõ chứ bài dễ thì giải làm gì”); nếu mình gặp những vấn đề khó khăn thì nó sẽ là những bài học cho các tình huống cho tương lai (no crying over spilt milk); còn nếu vấn đề đã xảy ra rồi thì cần làm gì để giải quyết được nó, chứ không phải tìm lý do để blame tội.

Cái chân cuối cùng của cái kiềng ba chân, chắc đó là một sự tự tin(hay là cố chấp), về khả năng thích nghi của mình. Mình tự tin với sự tò mò của mình, và với khả năng của bản thân, để có thể đối diện với khó khăn — không có gì là không học được, chỉ là mình chưa đủ cố gắng; nếu mình làm đúng và tự tin vào những gì mình làm, thì không có lý nào mình không làm người khác tin vào mình được (nhưng nếu người khác mà đúng, thì mình cũng sẽ học cách tin vào họ). Một sự tự tin vào bản thân, đến mức hơi cố chấp, đó là cách để mình có thể thích nghi vào bất cứ tình huống nào.

Thích nghi tốt nhưng không thích mà chỉ nghi

Sống một cách lạc quan, thích nghi tốt với mọi thứ — nghe thì có vẻ là tốt, nhưng đôi khi chưa chắc đã tốt. Mọi thứ đều có những mặt trái của nó, và thành thật với bản thân cũng là một cách để giữ lại những gì mình muốn.

Lạc quan, đôi khi cũng dẫn đến sự tự tin thái quá. Như việc mình hứa với bản thân về việc viết 100 bài blog trong năm ngoái (và chỉ hoàn thành được chưa đến một nửa), lao đi đăng ký Full Marathon và không hoàn thành nổi (haizz) hay là như việc xây dựng thói quen thể dục thể thao (vẫn có những vẫn hơi lười) — cũng có nhiều ví dụ về việc mình tự tin vào bản thân mà cũng không hoàn thành được mục tiêu. Biết được điểm yếu của bản thân, thì chỉ có cách là tìm cách hạn chế hoặc khắc phục nó. Đó là phải đi kèm với một chút khắt khe và kỷ luật — mình biết việc gì là không nên làm hỏng, việc gì là việc quan trọng, và nên cho nó lên hàng đầu. Và nếu nó đã là mục tiêu ưu tiên, thì phải làm bằng được chứ không có đầu hàng. Mình chỉ một chút kỷ luật trong người thôi, nên sẽ để dành cho những thứ cần thiết.

Còn thích nghi thì sao? Với mình, thích nghi tốt lại có thể là một con dao hai lưỡi. Như mọi người hay nói, bạn là kết hợp của 5 người gần bạn nhất — thích nghi là một cách dễ dàng để hoà nhập cũng như hoà tan vào môi trường xung quanh bạn. Đó là điều khác biệt khi mình nhảy vào những môi trường khác nhau, sau mỗi lần đó mình đều cảm nhận thấy là tư duy của bản thân có bị thay đổi theo những người làm việc gần gũi với mình. Có cả thứ tốt, có cả thứ xấu, và chỉ khi mình nhảy ra khỏi môi trường đó thì mình mới nhận ra được sự thay đổi của bản thân. Thế nên đó cũng là một thứ mình cũng cố gắng giữ cho bản thân mình, lựa chọn cho bản thân một môi trường thật tốt, và cũng sẽ cố gắng trở thành một sự ảnh hưởng tốt cho những người xung quanh. Thích nghi và hoà nhập nhưng không bừa bãi, và sống một cách thật tốt.

Chuyện của người lười viết

Đã được hơn hai tháng từ lần trước mình viết bài, phải nói là ăn tết cũng hơi kỹ. Mình vẫn mò lên Substack đọc lướt qua, nhưng cũng phải nói là hơi lười, nên đến hôm nay cũng cố gắng viết một chút.

Dù mình có lười đi thế nào đi nữa, thì mình cũng không muốn bỏ cái blog này. Đối với mình, nó cũng là khoảng lặng cần thiết, để có thể ngồi tĩnh tâm và viết ra những suy nghĩ của mình. Mặc dù 80% câu chữ của mình bây giờ thì là tâm sự với Claude, thì 20% còn lại sẽ để dành lại cho những thứ “người” hơn, đơn giản và thật thà, chứ không phải chạy theo productivity hay là cái gì khác.

Đó cũng là một cách để mình sống một cách lạc quan vui vẻ, và cũng là để chia sẻ thêm với mọi người xung quanh. Mình có hai người bạn, cũng là 2 substackers, hàng tuần vẫn chăm chỉ lên bài, viết lách và chia sẻ. Họ cũng là nguồn cảm hứng cho mình, và mình cũng muốn shout out cho họ, những con người luôn cố gắng và khiến mình rất hâm mộ. Đây phải chăng cũng là một môi trường mà mình nên cố gắng hoà nhập và thích nghi cùng?

Dù mình thích viết và cũng rất hâm mộ những người chịu khó viết và chăm chỉ, nhưng cũng không phải kiểu viết gì mình cũng thích. Với sự lạc quan và dở hơi của mình, mình thường sẽ không quá thích những câu chuyện nhìn đời hơi tiêu cực (như kiểu corporate toxic và bòn rút, phải sống ích kỷ tự bảo vệ mình) hay là các câu chuyện đe doạ (bạn không làm cái A cái B thì sẽ bị thụt lùi và bỏ lại phía sau blah blah). Mình luôn có cảm tình với các câu chuyện tự sự, nhẹ nhàng và mang một chút tích cực. Và đó là những thứ mà thế giới nên có nhiều hơn.

Có gì mọi người nếu có đọc được thì có thể qua ghé thăm a Hương (Code, Cook and Cash) tâm sự về cuộc đời, hoặc nghe Gia (Nitety-Nine Percent) chia sẻ về những thứ mới nhất về Data và AI nhé.

Cũng qua hơn 3 năm rồi mình mới quay lại với nhịp sống làm việc cùng công ty, quay lại với những tập tục lễ hội của giới corporate. Trong những dịp đầu năm này, (trừ khi bạn mới cãi nhau với sếp như thầy Amorim), thì có lẽ nhiều người cũng đang giống mình, lại trải qua quá trình làm performance review của năm cũ. Xem năm qua mình đã làm gì, mình có thay đổi thế nào, phát triển ra làm sao.

Có nhiều người thường không thích quá trình performance review này, coi nó như là một thứ thừa thãi. Họ nghĩ rằng đánh giá performance review là trách nhiệm của người quản lý: là người giao việc cũng như chỉ đạo, quản lý phải hiểu rõ về hiệu quả công việc cũng như giá trị đem lại từ phía nhân viên. Tại sao mình lại phải tự đánh giá bản thân mình — mình đánh giá bản thân mình tốt hay xấu thì đâu có ảnh hưởng đến lương thưởng hay là thăng chức hay gì đâu? Đánh giá về năng lực bản thân, phải chăng chỉ là thứ vô thưởng vô phạt?

Tuy nhiên với mình, việc mình tự đánh giá bản thân mình lại là thứ quan trọng nhất của những quá trình này. Việc tổng kết và tóm tắt lại những gì mình đã làm được cũng như học được trong thời gian vừa qua, cũng là một phần của việc cô đọng lại những kiến thức cũng như trải nghiệm của bạn, hiểu rõ hơn về những sự tiến bộ của bản thân trong thời gian vừa qua. Bạn phải cảm nhận được sự phát triển của bản thân, thì bạn mới biết cách để tiếp tục phát triển. Như một người nghệ sĩ đã được trau dồi qua nhiều năm nhận ra dàn nhạc đánh trật nhịp, một vận động viên đã trải qua hàng nghìn giờ luyện tập để có thể đưa ra pha dứt điểm chính xác: họ cảm nhận được thế nào là đúng, thế nào là sai, để có thể tiếp tục phát huy cái đúng và bớt đi cái sai. Cảm nhận sự phát triển của bản thân cũng vậy — bạn biết thế nào là đang phát triển, thì bạn sẽ có thể biết được mình có đi đúng hướng hay không.

Một quy trình performance review chuyên nghiệp, sẽ luôn bao gồm sự kết hợp từ feedback của đồng nghiệp, của quản lý trực tiếp — đó là những sự bổ trợ về góc nhìn, để bạn có thể tiếp cận sự phát triển của bạn theo các chiều khác nhau, những góc cạnh mà bạn chưa chú ý đến. Nếu họ cũng đánh giá bạn giống như những gì bạn nghĩ, đó sẽ là positive reinforcement, là bạn đang cảm nhận tốt về khả năng cũng như trình độ của bản thân. Tuy nhiên, nếu họ lại có góc nhìn khác hẳn với bạn, đó sẽ là một câu hỏi để bạn suy ngẫm: phải chăng là đánh giá của bạn chưa chuẩn xác, hoặc là bạn đang có những behavior gì mà lại khiến người khác đánh giá bạn theo một cách khác biệt? Suy ngẫm về câu hỏi này, cũng là một cách để bạn có thể phát triển và đi xa hơn.

Thế nên với mình, sự đánh giá bản thân này là một phần vô cùng quan trọng, mà mọi người không nên xem nhẹ.

Own your growth

Khi bạn làm ở những tập đoàn đủ lớn với hệ thống nhân sự phát triển, trong công ty sẽ luôn hình thành một framework cũng như guidance rất cụ thể, để có thể giúp mọi người mường tượng cũng như xây dựng khả năng đánh giá. Đâu là những Pillars của việc đánh giá, cách nấc thang của việc đánh giá trình độ và năng lực. Mình cũng cảm thấy may mắn với việc công ty mình cũng đầu tư khá chi tiết vào những items này, và xây dựng một quy trình đánh giá mặc dù có thể hơi dài dòng, nhưng đủ chi tiết và chặt chẽ.

Một thứ khá hay mà làm mình ấn tượng, đó là một mục riêng về “Own your growth”, một kiểu như tự nắm lấy sự tiến bộ của bạn. Đây là một thứ mình cũng từng ngẫm nghĩ, và cũng là một thứ mình cũng để ý và thường xuyên nhắc nhở cũng như nhắc đến với những người khác — một cụm từ ngắn gọn mà mình cũng cảm thấy khá đáng giá. Sự tiến bộ và phát triển của bản thân, nằm ở trong tay mình, và mình có quyền quyết định nó; không phải chờ một ai đi đến để có thể thúc ép mình lớn được.

Nếu bạn có đọc những bài khác mình từng viết (ví dụ như: Learning on the job, Giao việc cho sếp, Lời nhắn nhủ và cách học hành), bạn có thể thấy tư duy của mình thiên rất nhiều về việc chủ động, trong công việc cũng như học tập. Mình đánh giá rất cao sự chủ động trong tư duy, trong suy nghĩ, cũng như trong hành động. Kết hợp với một growth mindset luôn không ngừng tiến bộ, và đó sẽ trở thành sự chủ động cho việc phát triển bản thân.

Bạn cảm thấy bị chững lại trong khuôn khổ junior quá lâu, hãy theo dõi cách một senior mà bạn cảm thấy tâm phục khẩu phục và học hỏi cách người ta làm việc. Bạn cảm thấy bạn hay gặp trục trặc trong việc nói chuyện với các team business để hiểu nhu cầu của họ, vậy thì hãy luyện tập thêm khả năng giao tiếp và trình bày, để làm sao có thể trao đổi thông tin hiệu quả hơn. Bạn cảm thấy chưa được tiếp xúc hoặc làm việc với các công cụ AI, hãy tự đặt ra mục tiêu cho bản thân để có thể trải nghiệm cũng như học cách sử dụng hiệu quả. Chủ động nắm bắt điểm yếu của bản thân, chủ động tìm cách giải quyết nó, chủ động cho những mục tiêu phát triển của mình.

Học cách dũng cảm

Mặc dù mình nói đi nói lại về việc chủ động, nhưng mình đương nhiên cũng còn nhiều thiếu xót trong sự chủ động của bản thân mình. Vẫn còn những điểm yếu, vẫn còn những sự trì trệ, và cũng còn những bad habits của bản thân mà vẫn chưa bỏ được hẳn.

Nhận xét ra được những điểm yếu sẽ luôn là bước đi đầu tiên. Nhưng lại có một điều trớ trêu thay: với thế giới được kết nối rộng rãi, kiến thức được chia sẻ đầy rẫy qua các mạng xã hội, mọi người sẽ có khả năng nhận biết ra rất rất rất nhiều điểm thiếu xót về bản thân mình. Thời điểm mình mới đi làm, chắc mình chỉ tự biết và nhận ra vài thứ mình cần khắc phục (khờ khạo đôi khi cũng có cái tốt của nó) — nhưng các bạn trẻ bây giờ mới bắt đầu đi làm đã thấy thiếu đủ thứ: học khoá này, học kiến thức kia, công cụ này, đầu tư chỗ nọ… Nó là một cảm giác khá là ngộp, khi mình thấy bản thân chưa đâu vào đâu, mà đã có hàng trăm thứ cần phải “chữa”.

Mình nghĩ là, mọi người đều có ước muốn được chủ động, được nắm quyền điều hành trong cuộc sống của bản thân mình. Tuy nhiên, nếu bạn thấy có 100 thứ cần phải làm, lựa chọn chỉ 1 thứ để tập trung vào sẽ khiến bạn thấy sợ hãi — mình đang gạt 99 thứ qua một bên, liệu mình có đang chọn đúng thứ để sửa hay không??? Để bắt đầu chọn lựa, đi theo lựa chọn của mình, cần phải có một sự dũng cảm không hề nhỏ — đó là học lấy cách để chọn lựa bước đi của mình, và có dũng khí để chấp nhận lấy lựa chọn của mình.

Thế nên với mình, “owning your growth” không chỉ là một lời khuyên bâng quơ — đó là một kỹ năng mà bạn cần phải trau dồi, để biết cách grow, và nắm bắt lấy sự phát triển và tiến bộ của bản thân. Cho đến cuối cùng, người sếp quan trọng nhất của bạn, đó chính là bản thân bạn mà thôi.

Nếu có từ ngữ gì để mô tả về hành trình viết lách của mình trong năm vừa qua, thì chắc chắn nó không nằm trong 3 cái từ ở trên. Mở đầu năm mới với dự tính đơn giản, 100 bài viết một năm — nghe cũng không khó lắm nhỉ, chỉ cần là 2 bài một tuần là cũng đủ rồi. Kết cục của năm thì là ối dồi ôi, với chỉ có 43 bài, suýt được một nửa. Điều an ủi duy nhất, đó là mình cũng không hoàn thành các mục tiêu khác nữa, nên là đây cũng không có gì quá nghiêm trọng.

Tuy nhiên không phải vì thế mà không tổng kết lại cuối năm. Năm nào mục tiêu khó quá thì năm sau đặt mục tiêu dễ hơn là được.

Dùng hình thay chữ

Các nền tảng mạng xã hội đều có thông số cho các bạn creator, để có thể xem được tầm với của những nội dung đạt được đến mức nào. Tuy nhiên thì mình cũng không quá để ý các con số của Meta hay LinkedIn hay là gì, chủ yếu vì ở đó mình cũng chỉ share link lại về cái blog này mà thôi.

Mình cũng từng nghĩ, là mình sẽ happy với con số như thế nào, liệu đến được 1000 subs hay 100k views thì có bõ với công sức mình đã bỏ ra không. Nhưng đến lúc bắt tay vào viết, thì mình cũng chỉ đơn giản là viết những gì mình thích, và may mắn là có người thích đọc những gì mình viết. Mình lên mạng ngồi đọc lòi mắt ra mới tìm được 1 vài cái mình thấy hay ho ấn tượng, nên có từng này người theo dõi mình là mình cũng vui rồi.

Cũng có một cái mốc rõ rệt, khi mà mình viết ít đi hơn, và cái slope nó cũng thoải hơn so với trước. Đó là khi mình có thêm một mối quan tâm mới, và mình cũng rất vui vì đó là một công việc mình rất hứng thú, và có được một môi trường thú vị để tiếp tục phát triển bản thân hơn.

Cuối cùng, điều mà mình nhận lại là rất nhiều niềm vui. Thỉnh thoảng nhận được một sub mới. Gặp bạn bè thì cũng có một vài người đọc những gì mình viết. Thậm chí còn có đứa colleague đi ngang qua bảo là e cũng đọc mấy cái anh viết. Cũng hơi giật mình đó, nhưng mà cũng mang một chút tự hào đi kèm, là những thứ mình viết cũng mang lại giá trị cho người khác. Vẫn chưa quá tự tin, để có thể share ra hết những channel mình đang có (ví dụ như chắc là sẽ không bao giờ share lên fb cá nhân chẳng hạn) — nhưng mà vẫn là những bước tiến về phía trước, bước ra khỏi những vùng an toàn của bản thân.

Còn năm nay thì sao

Nói thật là mình chưa biết. Đời của dân code thì chỉ tính theo sprint thôi chứ làm sao mà tính xa quá được. Cũng như đầu năm 2025 thì mình cũng không thể mường tượng ra được bây giờ đầu năm 2026 mình đang làm cái gì, và năm nay cũng vậy thôi.

Bận rộn thì vẫn bận rộn, nên chắc mình cũng không thể viết nhiều được như năm ngoái. Hoặc nếu mọi người nhắn tin cho mình, đặt câu hỏi hay nội dung gì đó, để mình bớt ngại trong viết bắt đầu, thì mình có thể trả lời các câu hỏi hoặc bàn luận một số topics nhất định. Ai mà gặp mình ngoài đời thì chắc cũng biết tính mình, cái gì cũng sẵn sàng chia sẻ và bàn luận (và hài hơn ở trên mạng nhiều).

Và cuối cùng, cám ơn tất cả mọi người đã theo dõi và ủng hộ mình. Hy vọng những gì mình chia sẻ, sẽ mang lại những positive impact cho cuộc sống của mỗi người. <3

Một số ảnh khác

Facebook và activity nhìn rất quạnh hiu của mình

Rón rén thử share 1-2 bài trên Linkedin, cũng không quá tệ, nhưng mà vẫn shy shy shy.

Với một chút lăn lộn trong ngành công nghệ cũng được một thời gian, mình cũng tự cho bản thân là mình cũng có một chút hiểu biết về các công việc, các chức danh khác nhau ở trong ngành. Mình cũng có hứng thú chia sẻ và dạy đời nữa, nên cũng thường xuyên cũng để ý theo dõi các chia sẻ cũng như content trên mạng.

Có lẽ các bạn trẻ cũng đều có một chút hoang mang khi mới tham gia môi trường làm việc, thế nên mình có thể thấy một chủ đề vô cùng thu hút người theo dõi, đó là những chia sẻ về nghề nghiệp, về công việc, về kinh nghiệm của những người trong ngành đi trước (và đương nhiên, cũng có cả ngàn khoá học khác nhau được bán nữa). Các lời khuyên chắc cũng không có quá ý nghĩa đối với mình, nhưng mà mình thì thường để ý xem là những lời khuyên này được đưa ra có hợp lý hay không, phù hợp với ngữ cảnh như thế nào.

Một thứ hay ho mà mình có thể để ý, đó là cùng một chức danh, cùng một nghề nghiệp, nhưng mà có một số title thì sẽ có những trải nghiệm vô cùng khác biệt. Hai thứ mà mình hay để ý nhất, đó là về Data, cũng như là Products — nghe như câu chuyện của mọi người, mỗi người đều có những trải nghiệm và cuộc sống khác biệt. Đem so sánh với Backend Engineer, khi tất cả mọi người đều trải nghiệm gần với việc viết code cho server-side, thiết lập API; hay là Frontend Engineer khi mọi người làm việc đều thiên hướng rõ ràng về việc xây dựng giao diện — khi bạn nói về Data và Products, trải nghiệm của mọi người sẽ không được thống nhất. Data thì có thể làm từ xây dựng hệ thống dữ liệu đến viết script vẽ charts làm BI; products thì từ việc quản lý sprints đến viết PRD, đến cả đi nói chuyện với stakeholders hàng ngày, mỗi công ty lại có một hình dạng, một job scope khác nhau.

Đây không phải là một kết luận, là công việc A sẽ đơn điệu và dễ đoán hơn công việc B. Nó như một cảm nhận của bản thân mình, về sự khác biệt về chia sẻ cho từng công việc nhất định.

Làm Data là sao?

Cảm nhận chung của mình về Data, đó là công việc của bạn sẽ đi theo ngành nghề, theo business domain của công ty đang theo đuổi, và nó sẽ set the tone cho những công việc bạn phải làm.

Điều mà mọi công ty đều (bảo rằng họ đang) theo đuổi, đó là data-driven. Thế nhưng data-driven có những mặt khác nhau của nó, đó là sử dụng dữ liệu vào mục đích gì. Một cách hiểu nôm na, doanh nghiệp sẽ dùng dữ liệu cho hai hướng: tối ưu (optimize) những quy trình, những nghiệp vụ họ đang có; hoặc là phát triển thêm những nghiệp vụ mới, sản phẩm mới (r&d) để họ có thể mở rộng kinh doanh. Hai chiều hướng khác nhau, nhưng đều mang trên mình ý nghĩa của data-driven decision.

Một góc cạnh khác để xem xét về cách sử dụng dữ liệu, đó là analysis (backward-looking) và predictive (forward-looking). Nghiệp vụ dữ liệu khi bạn làm nhiều về mặt báo cáo, reporting, đánh giá lại những gì đã xảy ra trong quá khứ, đòi hỏi sự chính xác cao độ. Còn khi bạn muốn dự đoán được tương lai, thì sẽ có nhiều chiều hướng để tối ưu: bạn có thể ưu tiên về độ chính xác, mức độ rủi ro, hoặc là cân bằng hiệu quả và ngân sách để vạch ra kế hoạch trước mắt.

Nhưng, thứ quan trọng nhất sẽ quyết định bạn làm gì trong công việc hàng ngày, thì đó lại là doanh nghiệp của bạn thuộc về chuyên ngành gì, và họ có những bài toán nào. Nếu bạn làm trong ngân hàng hoặc tài chính, bạn sẽ phải làm nhiều về báo cáo để phục vụ compliance, cũng như bài toán tối quan trọng sẽ thuộc về credit scoring model. Nhưng nếu bạn làm trong ecommerce hay adtech, thì lại có rất nhiều bài toán về realtime recommendation/ad-serving, xử lý tối ưu hoá thời gian thực. Một doanh nghiệp sản xuất và kinh doanh FMCG, bài toán sẽ nằm rất nhiều về Demand Forecast and Planning, vì tối ưu chuỗi cung ứng sẽ quyết định cho độ hiệu quả của doanh nghiệp. Rồi những bài toán IoT, hoặc Customer Segmentation, tối ưu logistics, vân vân và mây mây. Sự khác biệt về bài toán của doanh nghiệp, cũng sẽ là gốc rễ để vẽ ra các mảnh đời khác nhau cho “dân Data”. Bạn có thể phải xử lý hàng tỷ record mỗi lần, nhưng cũng có thể là chỉ cần vẽ charts và send reports hàng ngày, mọi thứ đều có thể xảy ra cho cuộc đời Data.

Còn Products thì sao?

Một điều mình nhận thấy về mặt Data, đó là nếu bạn hiểu về những thứ công ty đang làm, thì bạn có thể hơi mường tượng về cuộc sống Data ở đó một chút. Nhưng điều đó thì lại không áp dụng được với Products, vì Products thì nó lại không phụ thuộc theo ngành.

Products, về bản chất, là một role thường được tính là “glue work”, là mảnh ghép để kết nối được các bộ phận khác nhau hoạt động một cách trơn tru. Điều tạo nên sự khác biệt cho công việc của Products, thực ra về sự khác nhau cũng như tương tác giữa các mảnh ghép đó. Thế nên, công việc Products nó sẽ thể hiện ra dynamics của các team trong cùng 1 doanh nghiệp, và nó sẽ rất khác biệt, mỗi nơi một khác.

Nếu công ty của bạn hoạt động theo kiểu chỉ đạo từ trên xuống dưới, đôi khi Products sẽ phải làm những việc như là biến lời nói của CEO thành thời gian, hành động và timeline; nhưng nếu Product có ownership thì họ có thể là người đưa ra những quy chuẩn để CEO tham gia vào việc đánh giá. Nếu Engineering team của bạn có product sense tốt, họ có thể hình thành 70-80% giải pháp, và Product Manager sẽ không cần viết PRD sát sao đến từng centimet — tuy nhiên nếu team Engineering chỉ là những người nhận requirement và làm, thì PM sẽ cần vẽ từng diagram, chú thích từng dòng trong design doc để đảm bảo là các yêu cầu được liệt kê đầy đủ. Nếu UI/UX design hiểu được sự khó khăn của Engineering cũng như thiết kế chuẩn mực, PM có thể được quản trị theo những simplified metrics, chứ không phải đi check và align từng pixel một trong Figma.

Điều này cũng rất khác biệt cho những công ty có Product orgs phát triển mạnh mẽ và chuyên nghiệp, so với những công ty mới còn đang chập chững để theo đuổi tư duy Products. Bạn có thể nghe những chia sẻ hào nhoáng từ các PM các công ty top trên thế giới như Google, Meta — nhưng mà những thứ các PM được làm ở những công ty đó sẽ hoàn toàn khác biệt với trải nghiệm thực tế của bạn. Khi bạn là keo dán, phải dán ở đúng chỗ, ở những nơi cần được kết nối và giải quyết, chứ không thể cứng nhắc và tư duy về công việc như một thứ cố định được.

Lắng nghe với ngữ cảnh

Để quay lại câu chuyện ban đầu, đó là về việc lắng nghe và học theo những lời chỉ dẫn trên mạng xã hội. Cùng một title, nhưng nội dung và trách nhiệm của công việc có thể có sự khác biệt rất xa xôi. Lắng nghe, nhưng cũng stay critical, để bản thân có một cái nhìn khách quan hơn, và không chỉ đi theo các lời khuyên bảo một cách mù mờ :).

Không hiểu là vì lý do tuổi già hay là gì, nhưng mình thường có thói quen đưa ra những lời khuyên (không cần thiết) cho những người xung quanh, đặc biệt là mấy cái đứa juniors ngồi gần mình trên văn phòng. Thỉnh thoảng không có việc gì thì phải mở miệng hỏi han xem các bạn có gặp vướng mắc trở ngại gì không để còn (được) khuyên bảo cho nó sướng.

Một thứ mình không phải chỉ nghe được một lần, thì là về vấn đề họp hành. Có nhiều người thì thấy là họp hành nhiều quá thì phải context switching liên tục, cảm thấy năng suất công việc giảm xuống. Có người thì thấy là đi họp thì thấy là mệt, muốn được ngồi cắm mặt vào màn hình ngồi code cho nó vui.

Nhìn lại cái GCal của mình thì đúng là dành cả thanh xuân để đi họp thật. Trong 3-4 tuần gần đây thì tuần nào mình cũng phải bỏ hơn 20h hàng tuần ngồi trong meeting (chỉ trừ tuần đi công tác). Tuần làm việc 40 tiếng thì đã hơn 1 nửa đang ngồi họp rùi. Cũng một phần vì cả team mình làm việc cùng cũng như các stakeholders của mình đều không ngồi cùng office, thế rồi lúc nào cần gặp cũng phải mời nhau lên Zoom tâm sự. Số phận mà, biết phải làm sao.

Họp gì mà lắm thế

Thực ra hồi còn thiếu kinh nghiệm hơn, thì mình cũng chả phải là con người thích họp hành gì nhiều. Ngồi tâm sự với màn hình IDE vui hơn nhiều, vừa đeo tai nghe vừa ngồi gõ lạch cạch xem code chạy trên màn hình chả sướng hơn? Mỗi lần phải nhảy vào meeting thì nó là một cảm xúc rất là trì trệ. Tự nhiên lại bị lôi khỏi guồng làm việc, lại phải đi vừa lắng nghe, đôi khi còn phải tranh luận để đạt được mục đích — toàn những thứ không phù hợp với người lầm lì khó ở ít nói như mình.

Nhưng, sau mấy năm đi làm, thì mình dần dần lại có một nhận thức khác về việc đi meeting. Đôi khi có những thứ mà nếu không họp thì không thể nào hoàn thành được, có những cái thứ mà cần phải có đủ người ngồi nghe, đủ thứ được mang ra trình bày và tranh luận, thì mới có thể đạt được sự thống nhất, và mới có thể có gỡ được khúc mắc, mới đi vào được tiến độ. Tự nhiên, mình mới có thể nhận ra được là meeting thực ra là một công cụ vô cùng có ích, để đẩy cao hiệu quả của công việc.

Để nắm được điều này, chúng ta chắc phải hiểu được về bản chất và tác dụng của meeting. Một trong những thứ quan trọng nhất để công việc ở trong corporate có thể vận hành một cách suôn sẻ, đó là alignment — đó là khi mọi người có đạt được một sự đồng lòng đồng thuận về một vấn đề gì đó. Không có một con số nào đo lường cụ thể mức độ alignment, nhưng hãy tưởng tượng như mọi người đều là những mũi tên, những vector đang kéo project đi về các hướng khác nhau. Nếu mọi người đều muốn kéo theo những hướng khác nhau, thậm chí là đối nghịch, thì mọi thứ sẽ dường như khó thể nào mà di chuyển được; tuy nhiên, khi mọi mũi tên đều cùng kéo về 1 hướng, đương nhiên là mọi thứ sẽ trở nên suôn sẻ hơn rất nhiều.

Meeting là một công cụ hữu hiệu, để kéo các mũi tên đó lại, cùng hướng với nhau hơn (aligned). Nếu bạn đã tham gia vào một meeting hiệu quả, bạn sẽ thấy sự đồng lòng được tăng lên khi so sánh giữa trước và sau cuộc họp. Còn những cuộc họp thiếu hiệu quả, thì bạn chỉ thấy là sự rối tung rối mù, nó vẫn như y xì như cũ (đôi khi còn tệ hơn). Và khi bạn ngồi trong một meeting hiệu quả, đôi khi bạn còn cảm thấy productive hơn là ngồi mấy tiếng làm việc, khi tự nhiên mọi việc trở nên thông suốt và trôi chảy hơn.

Để họp không còn hành

Khi hiểu được nguyên lý của những cuộc họp, cũng như thế nào là cuộc họp hiệu quả, đó là bước đầu của việc biến cuộc họp từ một thứ phiền hà thành một công cụ hữu dụng.

Khi bạn biết key của một cuộc họp là alignment, mọi các thứ kinh nghiệm mà mọi người hay truyền đạt về kỹ năng đi họp, tự nhiên nó lại make sense hơn trước rất là nhiều: cuộc họp luôn phải có agenda rõ ràng, có người chỉ định để take meeting minute, và sau cuộc họp thì phải có action items, cũng như follow-up sau đó. Agenda là những thứ mà cần được aligned; meeting minutes để đảm bảo là những vấn đề được nêu ra được tổng kết cụ thể cũng như có bước giải quyết; Action items và follow-ups là những bước tiếp theo cần có thêm alignments.

Hiểu được mục đích của cuộc họp là để mang đến sự đoàn kết, thì việc của bạn, một meeting-goer, đó chính là chuẩn bị trước khi tham gia nó: nếu bạn cần xuất hiện trong một meeting, bạn phải biết bạn cần làm gì, và muốn đạt được điều gì trong thời gian ngắn ngủi đó. Đặt ra mục đích cho bản thân — bạn có thể cần được nghe vướng mắc của người khác, hoặc là bạn muốn giải pháp từ phía bạn được sự đồng ý để triển khai — đi họp với clear intention, đó là cách tốt nhất để bạn có một cuộc họp hiệu quả và productive. Ngoài ra, thực ra còn có một cách hay ho hơn, để bạn có thể meeting một cách hiệu quả — đó là không cần phải có meeting. Để giảm thiểu số lượng meeting, cách tốt nhất đó là giữ cho sự alignment trong team, trong các dự án của bạn luôn đạt ở mức cao — khi mọi người đều biết rõ mục đích của mình là cần làm gì và làm thế nào, ai làm cái gì, tiến độ của dự án đang ở đâu, số lượng meeting cần thiết sẽ giảm hẳn đi. Điều này sẽ có thể đạt được bằng việc xây dựng các rituals trong công việc để giảm thiểu việc cần phải có disruptive communications, hệ thống documentation rõ ràng, workflows mượt mà không vướng bận nhau, team cùng work trong một high-trust environment, cũng như quy trình reports trôi chảy mượt mà.

Đương nhiên, đây luôn là ước mơ của mọi người, cuộc đời không bao giờ suôn sẻ đến vậy. Để alignment làm mục tiêu, bạn sẽ hiểu thêm về cách vận hành của các công ty. Đây cũng là một điều mình có nói với một số người xung quanh mình: hãy trở thành một người mà mọi người muốn bạn hiện diện ở trong cuộc họp, vì sự hiện diện của bạn sẽ làm một meeting trở nên suôn sẻ hơn. Đây có thể sẽ là một topic khác nữa, mà một ngày nào đó mình sẽ viết thêm.

Nếu bạn thấy bài viết trên cũng hay ho, có thể đọc thêm một số bài mình cũng viết về việc đi làm :)

Theo dòng sự kiện

Tầm 4-5 năm trở lại gần đây, nếu mà bạn làm trong ngành Data, dù là Analyst, Engineer hay là Scientist, thì chắc chắn đều có nghe qua về dbt. Gần như là một tool gắn liền với phong trào Analytics Engineering, kết hợp giữa Analytics với những best practices của Engineering, như là version control, D.R.Y các thứ các thứ.

Data luôn là một ngành gắn với rất nhiều tools, nhiều tech stack, nhiều standards, nhiều SaaS được ra lò liên tục, và đặc biệt trong khoảng 10 năm gần đây. Không phải sản phẩm nào cũng được đón nhận mạnh mẽ, gây được tiếng vang, và có tầm ảnh hưởng như dbt. Cũng có nhiều ý tưởng xây dựng theo cùng hướng như dbt, trong đó có SQLMesh cũng là một cái tên khá là nổi bật.

Từ đầu năm đến giờ, nhiều động thái xảy ra trong cái domain này. Đầu tiên, với sự ra lò của dbt Fusion, viết lại cái khung của dbt (vốn được viết bằng Python và chuyển qua Rust), kèm theo những phát triển về hướng language server: những đoạn code SQL bây giờ không chỉ là templated queries, mà có thể còn được hiểu cả ngữ nghĩa, để tích hợp vào môi trường IDE một cách hoàn chỉnh hơn. Mặc dù tính năng cũng như performance tăng lên rất nhiều, dbt Fusion lại chỉ được đi kèm với bản trả phí, như một động thái hạn chế bớt sức mạnh của bản free và để có thể monetize tốt hơn.

Chỉ vài tháng sau đó, TobikoData, công ty đứng đằng sau SQLMesh, bất ngờ thông báo được mua lại bởi Fivetran, một ông lớn về data integration/data movement, chuyên về xây dựng các connector và mang dữ liệu qua lại các hệ thống thông tin. Và trong tháng 10 này, Fivetran và dbt Labs đã thông báo sát nhập, và thế là 2 đối thủ lâu năm như SQLMesh và dbt lại quy chung về một mối.

Thời gian từ lúc sát nhập vẫn còn rất ngắn và vẫn chưa thấy các bước đi tiếp theo, tuy nhiên, cũng dẫn đến nhiều người lo ngại về tương lai của dbt, liệu nó có còn tiếp tục được giữ là một sản phẩm open source hay không, hay là các công ty sẽ đẩy mạnh hơn về mặt monetization, và đầu tư nhiều hơn cho các sản phẩm enterprise.

Là một sản phẩm có tầm ảnh hưởng, và cũng là cần câu cơm cho rất nhiều người trong ngành Data. Ai mới tiếp cận với data trong thời gian gần đây, chắc đều phải hiểu qua dbt nó hoạt động thế nào, cũng như áp dụng trong công việc hàng ngày. Về phương diện kinh tế, chưa biết quá trình tiếp theo sẽ thế nào, nhưng chắc chúng ta cũng chỉ có thể ngồi chờ xem chuyện gì sẽ xảy ra trong những tháng tới.

dbt, thích và không thích

Để nói về bản thân mình, mình đã có trải qua kinh nghiệm làm việc từ trước thời của dbt. Từ lúc dbt và analytics engineering nổi lên, mình cũng khá hứng thú với những sự phát triển của sản phẩm này, và cũng có theo dõi sát sao với nó trong những năm gần đây. Với gốc gác là Engineering của mình, đương nhiên sẽ rất hứng thú với những gì dbt mang lại, vì nó kết hợp giữa Analytics và Engineering, và nếu mọi người có trải qua giai đoạn trước đó, thì chắc có thể sẽ hiểu sự lộn xộn trong quá trình Data Transformation, khi mà không có một quy chuẩn làm việc nghiêm ngặt nào. Các đoạn code lộn xộn không đầu đũa, các transformation logic mỗi nơi 1 kiểu, không có sự kết nối giữa các datasets. Nên đương nhiên, mình rất thích những gì mà dbt mang lại.

Ở một chiều hướng khác, khi sử dụng dbt đủ lâu, thì mình cũng sẽ thấy có những điểm làm mình không thích ở dbt. Cùng với Analytics Engineering, đó là một tư duy khác về quản lý và xây dựng hệ thống dữ liệu; tuy nhiên, cái framework này lại chưa đủ chặt chẽ, chưa đủ bao quát, nên sẽ có những điểm hạn chế nhất định. Cảm nhận của mình và dbt, đó là một sản phẩm chưa đủ: nó làm rất tốt việc của nó, nhưng không bao giờ bao quát hết được hoàn toàn.

Note: mình viết đoạn này thì sẽ assume là mọi người đã có kiến thức sơ bộ về cách thức vận hành của dbt và các thứ ETL căn bản.

Transformation Logic

Một điểm dbt làm rất tốt, đó là vẽ ra được sự liên kết giữa các data model, làm sao để xây dựng được cái bước transformation để xây dựng model đích này từ các models trước. Transformation logic được codified, để dễ quản lý, cũng như làm một ngôn ngữ chung để tất cả mọi người đều có thể hiểu được. Nó cũng giúp vẽ ra một bức tranh tổng thể về data và column lineage, giúp việc quản lý data platform trở nên dễ dàng hơn.

Tuy nhiên, khi cái transformation logic nó vượt qua khả năng diễn tả của SQL, thì mọi thứ trở nên rắc rối hơn, đặc biệt khi bạn phải làm nhiều hơn thiên về lĩnh vực của Data Science, như là model training hoặc là feature engineering. Khi transformation của bạn là một thuật toán, hoặc là qua nhiều bước probabilistic transformation, thì khó có thể “diễn giải” nó bằng cái ngôn ngữ của dbt.

Khi hệ thống của bạn bắt đầu tiếp cận các transformation phức tạp, dbt sẽ là không đủ.

Nghịch lý từ Macros

Một trong những thứ hay ho nhất, mà những người có gốc từ Engineering nghe thấy sẽ rất hứng thú, đó là dbt Macros. Ai chả muốn làm D.R.Y., viết code dùng đi dùng lại nhiều lần. Thay vì phải viết code đó nhiều lần, bạn có thể thay thế bằng 1 đoạn macro, và bạn có thể tái sử dụng lại logic trong code của bạn.

Tuy nhiên, một trong những điểm mạnh nhất của SQL, đó là transformation logic của bạn được hoàn toàn thể hiện một cách declarative, để bạn có thể nắm bắt logic từ đầu đến cuối chỉ tại một nơi. Nhưng, để tiết kiệm thời gian và công sức với macros, bạn lại tìm cách tái sử dụng một đoạn code, và sau đó phần declarative logic của bạn sẽ bị phân tán giữa SQL code và Macro code của bạn — giả dụ như bạn viết một đoạn logic rẽ nhánh ở trong code macros của bạn, nó có thể dẫn đến việc làm code của bạn nó không còn mang tính declarative nữa, và rất khó debug. Mặc dù bạn tiết kiệm được chút code, nhưng mà logic của bạn sẽ dễ bị convoluted hơn. Đây là một điểm vừa mạnh cũng như vừa dễ có thể trở thành footgun trong một dbt stack, dễ giúp mình bắn vào chân nếu không cẩn thận.

Ngoài ra, cũng có nhiều người dùng macros như là một cách để simplify một số tác vụ, ví dụ như là viết ETL log sau mỗi transformation steps, hoặc là update các thông tin metadata. Đây thực ra lại là một possible dark pattern của system design: Khi bạn chạy SQL code, đó là bạn thực hiện thay đổi ở Data layer; tuy nhiên, việc viết transformation log hoặc là update metadata lại là một việc của Management/Coordination Layer. Nếu mà bạn có một tầng coordination layer ở phía ngoài, ví dụ như Airflow DAGs hay gì đó, thì đang có một sự giẫm chân nhau của hai system.

Với mình, macros mặc dù là một thứ rất mạnh, nhưng mà rất dễ dẫn đến dùng sai.

Data Pipelines

Một điểm quan trọng khi nói đến dbt, đó là vấn đề xây dựng data pipelines. Thực ra, để nói đến xây dựng data pipelines, thì mình luôn tính nó là 2 steps tách biệt. Đầu tiên, bạn phải xây dựng transformation logic, ở đây chính là dbt SQL của bạn. Sau đó, phần thứ 2 sẽ là xây dựng data pipelines: lập lịch, thiết lập dependencies, các cấu trúc về retries, SLAs, vân vân và mây mây.

Các mechanism này, nó lại chỉ được xử lý 1 phần bởi dbt; thế nên, dbt lúc nào cũng phải được đi kèm và kết nối cùng với một hệ thống khác để thiết kế pipelines: dbt Cloud có sẵn việc lập lịch, còn nếu không thì sẽ phải tích hợp với Airflow hay gì đó. Và khi đó, bạn sẽ phải bị giằng xé giữa những khái niệm của các hệ thống khác nhau.

Một ví dụ đơn giản, Airflow có thể thiết kế 1 backfill run cho 1 daily DAG, bằng việc chạy lại tất cả các run của DAG đó trong khoảng thời gian cần backfill. Tuy nhiên, nếu việc xây dựng dbt model của bạn lại bằng việc lấy incremental data cho mỗi lần chạy, thì backfill lại chỉ là chạy lại dbt job đó bằng đúng khoảng thời gian cần backfill, và nó sẽ không tích hợp một cách gọn gàng với Airflow job. Còn nếu muốn tích hợp cùng với cấu trúc của Airflow DAG, thì dbt model của bạn lại phải nhận thêm biến là processing time từ phía bên ngoài, và như thế lại có thể giẫm chân lên cấu trúc của một incremental materialization.

Thế nên, dbt vẫn sẽ gây cho bạn một cảm giác thiếu thiếu, khi bạn vẫn phải xây dựng dựa vào cấu trúc của orchestration layer/data pipelines phía bên ngoài, và sẽ có dẫn đến những design conflicts.

Nắm giữ data

Để quay lại câu chuyện M&A đã viết ở đầu. Mình nghĩ một điểm yếu từ dbt, đó là nó không thể là một sản phẩm đầy đủ — lúc nào sản phẩm cũng sẽ phải đi kèm với 1-2 thứ khác, để làm nốt phần việc của nó, trong việc xây dựng một hệ thống data transformation hoàn chỉnh. Và data transformation, sẽ không bao giờ có thể có một quy chuẩn hoàn chỉnh cho nó cả, vì đơn giản việc sử dụng data nó muôn màu muôn vẻ — không có một cấu trúc nào có thể mô tả và giới hạn hết cách con người muốn sử dụng dữ liệu.

Những ông lớn mạnh nhất về data, Databricks, Snowflake, họ đều mở rộng về cách lưu trữ và xử lý data: nó phải đi càng gần với code hơn, để con người có thể viết Python, thêm library, chạy notebook vân vân và mây mây. Và khi bạn đã onboard vào trong Unity Catalog hoặc là data của bạn đã được load vào Snowflake, mọi thứ trở nên dễ dàng hơn rất nhiều: bạn có thể dùng scheduler của bạn, dùng dbt hay là tự viết sql, miễn là data catalog của bạn nằm ở trong đó. Và khi catalog của bạn nằm với họ, thì sẽ rất khó để bạn có thể thoát ra trở lại hệ thống riêng của mình; bởi vì nó quá là tiện lợi.

Vậy nên với mình, dbt/fivetran sẽ rất khó cạnh tranh với các ông lớn. Bởi vì, thứ mà để giữ chân mọi người lâu nhất, đó là Data và Data Catalog. Còn data transformation, it will come and go.

Chưa biết tương lai thì câu chuyện sẽ đi tiếp thế nào, nhưng hôm nay thì mình biết được đến đó.

Ngày thứ 3 kể từ hôm bắt đầu đi làm, tôi vác một đống sách từ nhà lên office. Nghe thì oách thôi, nhưng mà sách thì nặng mà, tôi chỉ vác được khoảng hơn 10 quyển lên. Xếp được 2 chồng ở trên bàn làm việc, tôi mở Confluence ra và làm một page cá nhân “The Friendly Neighbourhood Library”.

Ý tưởng thì cũng đơn giản, mình muốn làm một góc nhỏ như một cái library ở trên văn phòng. Mọi người có thể tạt qua, nhìn thấy một quyển sách nào hay ho thì có thể tạt vào ngắm nghía, và mượn về đọc. Nhưng đương nhiên, một cây thì làm chẳng nên non, và 10 quyển sách thì không thể xây thành một cái thư viện. Thay vì loay hoay một mình, thì mình nghĩ về hướng crowdsourcing: mọi người có thể mang những quyển sách từ nhà lên, cùng đóng góp vào quỹ sách chung — thay vì chỉ có một cái thư viện mà bạn có thể mượn, bạn cũng có thể đóng góp những quyển sách hay ho mà bạn có, và chia sẻ những thứ hay ho mà bạn được đọc.

May mắn thay, là mình cũng được sự ủng hộ nhiệt tình từ anh site leader và một số đồng nghiệp, giờ thì đống sách cũng đã lên được hơn 50 quyển, và cũng có cả vài chục người đi qua mượn sách và đọc sách. Con số vẫn còn nhỏ, nhưng mà phải có một sự bắt đầu từ đâu đó phải không?

Write once, read many

Nếu ai mà có học hay đọc qua về các loại Analytical System, hoặc là về storage các kiểu, có thể đã từng nghe cái term là “write once, read many”. Đó là khi hệ thống được tối ưu chỉ để viết một lần rồi được đọc nhiều nhiều lần. Ví dụ như các bảng trong Data Warehouse, hay là một file dữ liệu Columnar storage, viết ra thì tốn kém nhưng lúc đọc nhiều thì lại rất là tối ưu.

Nghĩ một chút, thì chẳng phải điều này cũng áp dụng được với sách cũ hay sao? Một quyển sách mà bạn mua về, mua thì một lần thôi nhưng mà bạn lại có thể đọc nó nhiều lần. Và nếu bạn có một quyển sách mà bạn có thể chia sẻ với những người khác, đọc nhiều lần hơn, thì như thế mới là tối ưu được công dụng của quyển sách hết mức có thể. Mình cũng có đam mê với vấn đề tối ưu hoá, phải chăng vì thế này mà mình lại thích chủ đề sách cũ và chia sẻ?

Từ ngày xưa, từ trước khi mình về Việt Nam, thì mình đã nghĩ ra mấy cái idea làm quán sách cũ. Mình thì đã nghĩ ra cả tên shop rồi chứ — hàng sách nó phải tên là Cuốn, vừa là cuốn sách mà vừa là đọc sách thấy cuốn =). Đương nhiên là chỉ nghĩ thôi, nhưng mà rồi lười và ngại thì cũng chưa làm đến. Tuy nhiên, mình vẫn thích việc mang sách đến chia sẻ.

Đây cũng không phải là lần đầu tiên mình mang sách đến văn phòng. Tuy nhiên những lần trước, mình chỉ mang của chính mình lên thôi (và cũng ít người hưởng ứng nhiệt tình). Lần này, mình mới quyết tâm hơn, để nó thành crowdsourcing, và hy vọng có nhiều người hứng thú hơn. Mình nghĩ đơn giản thôi, những cái gì tử tế và tốt đẹp, nếu mà làm được thì cứ cố gắng làm.

Đọc là thế, còn viết thì sao?

Ngoài tư cách là một người đọc, thì mình còn hoạt động dưới tư cách một người viết (và đây, tôi đang trau chuốt từng từ để viết cái bài blog này đây).

Ở trong cái thời đại đa nền tảng, đa phương tiện này, một trong những điều những dân content hay kháo nhau, đó là phải viết nhiều lần, nhiều kiểu, và post lên tất cả các channel khác nhau. Phải post nhiều share nhiều thì mới có nhiều view, mới có hy vọng thuật toán nó sẽ distribute nội dung của mình đi. Thay vì “write once, read many”, thì hình như nó lại là “write many, hope to be seen once”.

Kể ra những thứ mình viết thì không hề dài, nếu muốn, thì mình cũng có thể chỉnh lại định dạng, chỉnh lại wording, để có thể làm những bài viết post lên mạng xã hội. Nếu bạn để ý, những bài post trên mạng xã hội điều được xây dựng theo format: bằng một câu hỏi, hoặc một statement đầu tiên để thu hút người đọc (clickbait), rồi sau đó mới đi vào nội dung chính. Vì cách mọi người sử dụng mạng xã hội để đọc, đó là tua một cách vô thức, và chỉ khi nhìn thấy một dòng hook nào làm mình chú ý thì mới dừng lại để đọc kỹ hơn. Thế nên nếu bạn để ý sẽ có thể thấy các tiểu thuyết mạng của Nhật Hàn Trung với những cái tên cực kỳ dài dòng mà phải đi thẳng vào nội dung (you know, kiểu That Time I Got Reincarnated as a Slime , hay là một đống truyện khác mà tạm thời chưa nghĩ ra tên).

Vì một cách nào đó, mình muốn những thứ mình viết ra, nó có thể được đọc một cách trọn vẹn hơn, chăm chú hơn — chứ không phải là một đoạn văn dài trên mạng xã hội để mọi người lướt qua, phải cạnh tranh lấy từng mắt xem bằng những dòng giật tít. Như một cuốn sách vậy, viết một lần, và hy vọng nó đủ hấp dẫn để người đọc có thể chia sẻ nó thêm cho nhiều người khác. Write once, read many.

Quay lại với guồng làm việc, thì tự nhiên thấy thời gian để viết lách của mình nó trôi đi đâu hết. Mình tự ngưỡng mộ mình của mấy tháng trước, ngồi xuống trước máy tính 1 tiếng là viết được cả nghìn từ. Chả hiểu chữ ở đâu ra mà văn chương lênh láng như thế.

Nói đi thì cũng có nói lại, mình hay ngẫm một chủ đề nào đó, ngẫm được 1 vài hôm, rồi khi nghĩ cho thông và đặt ra được những ý chính, thì lúc đó ngồi viết nó rất là nhanh. Kể cả khi làm việc cũng vậy, khi phải viết một cái gì đó dài dài thì mình cũng viết hết gạch đầu dòng ra, ngồi ngẫm về nó một vài hôm, sau đó dành được khoảng 1 buổi là viết được xong hết. Tiếc rằng những thứ gần đây mình dành suy nghĩ nhiều thì toàn là các bài toán nội bộ, và đến khi về nhà là não hết pin để suy nghĩ thêm về những thứ khác. Có được cuối tuần mở được máy cá nhân ra thì viết được vài dòng rồi lại thôi :)

Một phần rất lớn cảm hứng về viết lách của mình đến từ những cái gì mình đọc. Trong thời gian rảnh rỗi, mình có nhiều thời gian đi lượn Threads, đọc Hackernews và Reddit; mình sẽ thấy một topic nào đó khiến mình suy nghĩ và muốn suy nghĩ sâu hơn về nó một chút. Khi không có sức ép về thời gian hoặc deadline, cũng như những chủ đề rộng mở hơn, cách tiếp cận vấn đề của mình sẽ trừu tượng hơn, thiên hơn về khái niệm hoặc hướng đi. Khi không có một vấn đề nhức nhối cụ thể, cách nhìn của bản thân mình tự nhiên nhẹ nhàng hơn, suy ngẫm hơn.

Vèo một phát và mình trở lại với cuộc sống corporate, có vấn đề cụ thể, có sức ép của deadline và milestones. Những thứ mình nghiên cứu và cần giải quyết nó trở nên cụ thể và rõ ràng hơn rất nhiều. Các bài toán thì đều có success criteria, các cuộc bàn luận thì phải dẫn đến actionable items, vân vân và mây mây. Như một bước ngoặt 180 độ, mình nhảy ngay vào cái sự hối hả, bận rộn này, và cũng hàng ngày vắt óc lên để nghĩ hướng giải quyết các vấn đề được đặt ra.

Nhưng, có một điều quan trọng nhất, đó là mình cảm thấy thoải mái, và mình hoà nhập nhanh hơn tưởng tượng của chính bản thân mình. Mặc dù là bận rộn hơn, cường độ thì cao hơn; nhưng mình cảm thấy được sự kết nối của bản thân với những bài toán rất thú vị, những thử thách rất hay ho. Té ra, não của mình vẫn còn chưa nghỉ hưu được.

Tham lam là một sự cần thiết

Nói về ngữ cảnh, khi các hệ thống xung quanh bạn đều ở một scale nhất định, với hàng trăm tỷ records là chuyện thường ngày ở huyện. Tự nhiên, mọi bài toán xung quanh bạn đều trở thành bài toán triệu đô. Tương xứng với giá trị, đó cũng đều là những bài toán, những vấn đề không hề đơn giản.

Sống một cuộc sống an phận, bạn có thể được cấp trên giao cho 1 trong những vấn đề đó. Tuy nhiên, nếu bạn là một con người có niềm đam mê problem solving, thì thật sự là khó có thể an phận — vấn đề nào cũng khiến bạn thấy thú vị, vấn đề nào cũng có thể làm bạn trăn trở suy nghĩ. Bản thân mình, mình tự thấy lòng tham trong bản thân nổi lên — nhiều thứ mình muốn được nhảy vào ngẫm nghĩ, nhiều thứ mình cảm thấy muốn bàn luận, phải mở ngay máy ra viết nháp vài dòng SQL hoặc là vẽ vài trang excalidraw.

Tham lam đương nhiên là cũng có cái hại của nó. Có mấy hôm ngồi trong meeting bàn luận sôi nổi quá đến khô cả cổ, về nhà muốn hướng nội đến hết tuần. Có hôm viết cái doc dài ngoằng về mỏi nhừ hết cả vai. Và hại nhất là về nhà hết muốn mở máy cá nhân lên viết blog tiếp :)) Nhưng cái cảm giác đụng vào một vấn đề khó khăn, làm rõ được nó ra, rồi propose và implement hướng giải quyết, nó thực sự là rewarding. Và mỗi tuần về nhà, mình vui vẻ nghỉ ngơi, vì cảm thấy đã học thêm nhiều thứ mới và giải quyết thêm được những vấn đề mới.

Phải có một chút tham lam vào người, thì mới có động lực để phát triển.

Tham lam và tham vọng

Nghe thì đều là tham, nhưng nếu để ý một cách sâu xa thì hai điều này lại vừa khác biệt lại vừa có liên quan đến nhau.

Tham vọng mang ý chỉ về tầm nhìn xa hơn của bạn, là cái mà bạn mong muốn đạt được. Tham lam không đúng cách, chính là một hướng đi nguy hiểm để bạn không thể nào đạt được tham vọng của mình. Đó là khi bạn chọn cách ôm đồm, nhưng lại thiếu tính chiến thuật trong đó.

Ví dụ đi, bạn có một tham vọng để được promote trong kỳ review sắp tới. Bạn chọn làm 3 features cùng một lúc, vì nghĩ là ôm đồm làm nhiều features sẽ mang lại cho bạn sự ghi nhận từ cấp trên, và sẽ thành những gạch đầu dòng đẹp cho hồ sơ của bạn. Tuy nhiên, sự thật là công việc quá sức của bạn, bạn chỉ làm được 1 feature, còn lại 2 thứ dở dang; hệ thống thì vì có quá nhiều thay đổi dẫn đến mất ổn định, làm bạn tốn thêm nhiều công sức vào debug và maintenance. Kết cục là bạn lại bị burn out, thêm việc vào đầu mà lại không được promote — lose-lose-lose situation. Tương tự như thế, đó là một công ty đầu tư dàn trải quá nhiều hạng mục: cái gì cũng muốn làm, để rồi làm gì cũng không tốt và cuối cùng là thụt lùi.

Một trong những điều quan trọng nhất, khi bạn làm việc ở cường độ cao, đó là khả năng prioritization: bạn phải có một hệ thống thật là ổn định trong đầu, một mental model vững chãi xây dựng trên nền tảng kiến thức cơ bản, một khả năng bóc tách vấn đề và nhận diện mấu chốt trong một vấn đề lớn. Để đạt được tham vọng, hãy học cách đánh giá và ưu tiên làm những điều quan trọng nhất.

Thế nhưng, tham vọng mà đi kèm với tham lam là sao? Cũng là ví dụ như trên với 3 features, bạn đánh giá bản thân sẽ có thể làm được 1 feature quan trọng nhất, một cách chắc chắn và ổn định. Tham lam ở đây, đó là bạn vẫn nghĩ feature 2 và 3 có giá trị về sau, và bạn vẫn muốn có thể tiếp tục xây dựng nó nếu được. Vậy thì, bạn sẽ phải vừa tập trung giải quyết feature 1, nhưng trong lúc planning và execution vẫn phải có thêm chút cố gắng để chuẩn bị sẵn sàng cho việc bổ sung các feature 2 và 3 sau này nếu có thể. Push limit của bản thân thêm 1 xíu, push tư duy của mình sâu hơn 1 tị, và giải quyết vấn đề trước mắt với một tầm nhìn xa hơn — sự tham lam của bản thân sẽ tự nhiên trở thành một mấu chốt để đẩy bạn đi xa hơn 1 tí.

Mình cũng hay nói với mấy bạn juniors, nếu bạn là học sinh cấp 1, giải đi giải lại các bài toán cấp 1, bạn sẽ mãi chỉ là một học sinh cấp 1 xuất sắc — bạn sẽ không thể tự nhiên trở thành học sinh cấp 2 được. Nếu bạn là một junior, và tiếp tục chỉ xoay quanh làm những công việc của 1 junior, bạn sẽ không thể expect ngồi đủ năm đủ tháng và bạn sẽ trở thành senior được. Phải bước ra khỏi comfort zone một chút xíu, phải tham lam một chút xíu, làm những việc khó hơn khả năng của mình một chút để nâng cấp bản thân. Ở những công ty với hệ thống đánh giá năng lực chuyên nghiệp, khi bạn là một junior nhưng đã thể hiện khả năng làm việc của senior, đó mới là lúc cơ hội thăng tiến của bạn tìm đến.

Hãy học cách tham lam, một cách khéo léo.

45 ngày nghỉ viết tưởng là nhiều mà thực ra mình cảm thấy trôi vèo qua. Đó là một chuyến du lịch vui vẻ để chấm dứt một quãng nghỉ dài, và cũng là một tháng mình mới bắt đầu ở công việc mới. Mình cũng có chút tự nhủ với bản thân, là hãy dành cho bản thân 1 tháng với công việc mới, để đưa mọi thứ vào guồng ổn định, và sau đó mình có thể tiếp tục duy trì với những thứ chia sẻ mình còn đang dang dở.

Đương nhiên, không phải là trong thời gian đó thì mình cũng không viết lách gì… chỉ là thay việc viết những chia sẻ lung tung trên mạng cho thế giới xem, thì mình chuyển qua đọc documentation do đồng nghiệp viết, và viết internal documentation trên Confluence cho đồng nghiệp đọc.

1 phút cho quảng cáo. Những thứ mình đọc được và viết được đều rất hay ho và thú vị, xây dựng những hệ thống xử lý đến hàng Petabytes mỗi ngày, và giải quyết những vấn đề cho hàng trăm triệu consumers trên nhiều nước trên thế giới. Nếu điều này khơi dậy sự tò mò trong bạn, team của mình, Data Engineering Platform, đang tuyển nhiều vị trí tại Việt Nam, cả HCM và HN nhé:

• Senior Software Engineer, Stream Processing - Apply

• Lead Data Engineer, Computation Engine Infrastructure - Apply

Nếu bạn đọc có biết và quen ai interested về hệ thống dữ liệu thực sự lớn, có thể apply thẳng qua Link hoặc connect và nói chuyện với mình qua LinkedIn để hỏi thăm thêm!

Đương nhiên, sau 45 ngày thì đầu mình đã không còn chữ nữa. Bài này coi như mở bài lại, để quay lại vào guồng viết bài chăm chỉ như xưa!

Trừ khi bạn là chủ doanh nghiệp (và nếu thế thì bạn bỏ qua cái này cũng được), thì bạn chắc chắn sẽ có một người manager ở cấp trên, quản lý và điều hành các hoạt động của bạn. Với nhiều người, người sếp thường có một hào quang đáng sợ, vì họ là người giao việc cho bạn, kiểm tra chất lượng công việc của bạn, và cũng là người đánh giá cho sự phát triển và thăng tiến của bạn.

Tuy nhiên, theo góc nhìn của mình, thì người sếp, đôi khi lại là một nguồn tài nguyên vô cùng phong phú để bạn có thể làm tốt công việc và phát triển bản thân. Nếu bạn chỉ sợ sệt, nghe lời sếp một cách răm rắp, thì bạn đã bỏ quên một nguồn tài nguyên vô cùng giá trị. Biết cách “khai thác” mối quan hệ công việc với sếp, và biến manager của bạn thành một support system của mình, sẽ giúp mọi thứ trở nên trôi chảy hơn rất nhiều.

Để dạo đầu cho nội dung này, thì mình cũng phải giải thích trước về một số viewpoints mà mình đã có từng nói qua (qua một số bài viết cũ hơn của mình):

• Manager cũng là người thôi, họ cũng muốn làm tốt công việc của họ, và việc bạn làm tốt công việc của mình cũng là đóng góp rất lớn cho sự yên ổn của họ - Đọc vị Manager trong 10 phút.

• Những trách nhiệm đi cùng với công việc của một manager, họ sẽ phải quản lý và lãnh đạo về mặt technical, về project management cũng như people management - Trách nhiệm của manager.

• Là một phần trong những ý mình viết trong bài Learning on the job - bạn phải tự chủ về việc học tập để phát triển bản thân, chứ đừng chờ người khác đến dạy mình.

Bạn nên tự chủ cho việc học hỏi và phát triển của mình, và manager muốn bạn làm tốt công việc của bạn để họ có thể được thoải mái, họ cũng có trách nhiệm quản lý sắp xếp cũng như dẫn dắt bạn và team. Nếu ghép những mảnh ghép đó lại, thì manager không phải là một kẻ thù luôn mong muốn trù dập bạn — thực ra họ lại là những đồng minh, là một support system vô cùng mạnh mẽ nếu bạn biết sử dụng.

Và để sử dụng được nguồn tài nguyên đó, bạn phải biết cách để giao việc cho sếp của bạn.

(Note: nếu bạn là manager mà đang đọc những dòng này, good luck)

Cẩm nang sử dụng bảo bối

Đương nhiên, nói về “giao việc” thì nó là một cách nói vui vẻ hơn thôi, nhưng mà có một điều chắc chắn là manager của bạn có khả năng và có thể làm được nhiều thứ hơn bạn, thậm chí là rất nhiều. Việc đó phụ thuộc vào khả năng của họ, về hiểu biết của họ, cũng như vị thế của họ, vốn rất khác bạn.

Về khả năng và hiểu biết, manager có thể đã trải qua nhiều năm trong nghề hơn so với bạn, đã có nhiều kinh nghiệm và hiểu biết, không những là những know-how, mà còn là những gotcha, những do-and-don't, được tích luỹ qua nhiều năm làm nghề. Họ có mối quan hệ rộng rãi hơn trong môi trường làm việc, vì công việc của họ yêu cầu phải làm việc với nhiều phòng ban hơn. Họ cũng có những vị thế khác biệt, như khả năng khơi mào và dẫn dắt những cuộc discussion khó khăn, hay là có thể escalate vấn đề lên những con người đủ thẩm quyền để giải quyết vấn đề.

Biết được điều này, bạn có thể nhận được rất nhiều sự trợ giúp. Đó là về mặt cải thiện kỹ năng của bản thân và nâng tầm nghiệp vụ của bản thân; đó là về mặt giải quyết các khúc mắc và hoàn thành công việc đúng thời hạn, đúng chỉ tiêu. Và quan trọng hơn, họ sẽ là đầu mối giúp đỡ cho sự phát triển của sự nghiệp của bạn.

Sếp của bạn, với nhiều năm làm nghề, sẽ là một kho tàng kiến thức và tư duy quý giá. Họ cũng đã trải qua những thời gian như bạn hiện nay, và bây giờ họ có trách nhiệm quản trị về mặt chất lượng sản phẩm - họ cũng sẽ là người đánh giá xem những gì bạn đã làm ra có đạt chất lượng hay không, có tránh được những sai lầm mà kinh nghiệm của họ đã cho họ thấy hay không. Làm việc với sếp hiệu quả, đó là học cách communicate clearly để hiểu được hướng đi đúng: tìm xem cách giải của bạn sai ở chỗ nào, những tiêu chí nào mà sản phẩm của bạn làm tốt hoặc chưa tốt, nếu họ cũng làm thì họ có hướng cải tiến hoặc hướng nào khác biệt không?

Trao đổi với người đi trước và hiểu cách họ tư duy, học tập từ họ để bạn cải thiện khả năng nghiệp vụ của bản thân. Nếu bạn cũng đã và đang phạm những sai lầm giống họ ngày trước, họ cũng có thể là người chỉ được ra cho bạn cách họ đã vượt qua điều đó như thế nào. Thư viện kiến thức ở ngay đó, chỉ là bạn có chịu khó nghiên cứu và học hỏi hay không. Nhưng còn xa hơn nữa, là bạn có một expert ngay bên cạnh để có thể bàn luận về các chủ đề technical hơn. Ví dụ, bạn đọc về một hệ thống tương tự với những gì công ty bạn đang làm, bạn có thể chia sẻ với manager và xem những đánh giá của họ: cái này có gì hay, có gì tốt, có gì chưa kỹ, có áp dụng được vào bài toán của doanh nghiệp mình hay không. Từ đó, bạn có thể tự định hình được suy nghĩ cũng như là khả năng đánh giá của bản thân, và phát triển tư duy kỹ thuật của mình. (Đây cũng là một thứ mình rất thích, cả về hướng là report cũng như là manager, đó là chia sẻ về công nghệ với team và cùng bàn luận.)

Một phần nữa mà sếp của bạn phải quản lý, đó chính là quản lý về tiêu chí và tiến độ của dự án của team. Đương nhiên, điều căn bản để làm việc hiệu quả với manager, đó là chia sẻ về tiến độ, về tiêu chí cũng như các khúc mắc bạn gặp phải - họ cần nắm được điều đó để có thể quản trị rủi ro cho dự án. Một cách đơn giản mà mọi người thường thấy, đó là manager khi biết rõ được các rủi ro của dự án có thể tiến hành điều chỉnh: bổ sung thêm người hỗ trợ, giảm bớt nguồn lực cho các vấn đề phát sinh khác, thay đổi cũng như quản lý về deadline hay scope.

Tuy nhiên, nếu bạn biết cách làm việc hiệu quả cùng với sếp, thực ra vẫn còn rất nhiều sức mạnh mà bạn còn có thể sử dụng. Bạn có thể nhận thấy có những vấn đề trong project requirements còn chưa hợp lý và có cách giải quyết hiệu quả hơn → bạn có thể trao đổi với sếp, tìm hiểu lý do và động cơ cho nhu cầu này; nếu được sự đồng thuận của sếp bạn có thể thay đổi cách giải quyết và kết hợp với sếp để negotiate cho những thay đổi này. Nếu bạn cần hỗ trợ từ các team khác, bạn có thể nhờ manager làm người kết nối hoặc giới thiệu, cũng như chia sẻ ngữ cảnh để bạn có thể giao tiếp dễ dàng hơn với team khác. Họ đã làm việc ở cấp cao hơn và làm việc với nhiều team hơn rồi, và nhiều công việc của bạn có thể sẽ thuận lợi hơn nhiều nếu có tiếng nói của họ.

Đương nhiên, điều tiên quyết để làm được những điều trên, đó là bạn phải làm tốt phần việc của bản thân mình — nếu manager tin tưởng khả năng của bạn và cũng được thuyết phục với giải pháp bạn đề ra, họ mới sẵn lòng hỗ trợ những yêu cầu mà có vẻ hơi “quá phận”. Những sức mạnh này chỉ được dành cho những người xứng đáng.

1-on-1 và la bàn định hướng

Tương ứng với gạch đầu dòng cuối cùng trong những trách nhiệm của một manager, đó là về people management, đó là giúp bạn phát triển bản thân của bạn.

Mình thấy ở nhiều công ty hoặc tập đoàn, thường có yêu cầu với manager đó là setup ra những buổi trò chuyện 1:1 với các reports của mình. Đó là thời gian để các reports có thể trao đổi với các manager về những tâm tư và nguyện vọng của mình. Tuy nhiên đối với nhiều người, thì những thời gian này thường không được tôn trọng lắm. Họ ngại không muốn bàn luận, hoặc là không biết cách nào để bàn luận với manager. Điều này thường dẫn đến (1) buổi này chỉ được dùng để bàn bạc về công việc (làm thế này đúng không, làm thế này có kịp không) — tương tự như những cái mình có nói ở trên hoặc (2) “em không có gì để bàn bạc cả” và xin kiếu.

Với mình, thì thời gian 1:1 này chính là thời gian tốt nhất để bạn có thể phát triển bản thân, vì đây là thời gian mà bạn có thể nói chuyện với một người đi trước, một người muốn bạn phát triển hơn, và để hiểu biết hơn về bản thân của mình. Những bàn bạc về chất lượng hay tiến độ công việc — nó nên là một phần của những work discussion hàng ngày; thời gian 1:1 này, nên là thời gian để bạn nói chuyện về bạn, về sự phát triển của bạn, về định hướng của bạn.

Nói chuyện về những chủ đề này không dễ, nếu bạn không có định hướng quá rõ ràng về bản thân. Tuy nhiên, phải bắt đầu làm việc này, thì bạn mới có thể đặt được ra những thứ mà bạn mong muốn, những thứ mà bạn muốn đạt được, cùng với lời khuyên từ một người có kinh nghiệm hơn. Manager của bạn, cũng đã trải qua những thời gian junior như bạn trước kia, và cũng có thể hiểu được một phần về những trải nghiệm của bạn. Họ cũng nắm về những thứ bạn đang làm, có ngữ cảnh về trình độ cũng như khả năng của bạn; họ cũng nắm được một phần những khó khăn mà bạn đang gặp trong công việc. Vậy nên, đây là một thời gian vô cùng tốt để bàn luận về bản thân, với một người biết và đánh giá về công việc của bạn, mà không cần tốn nhiều lời để giải thích.

Bàn bạc với manager, bạn có thể biết được mình đang ở đâu, tự đánh giá và định vị bản thân về khả năng, trình độ cũng như sự phù hợp với công việc. Bạn cũng có thể dò tìm các phương hướng cho bản thân - mình nên phát triển thêm kỹ năng gì, nếu mình muốn vươn lên các chức vụ cao hơn thì sao, mình nên phát triển bản thân về career nào… Với kinh nghiệm của người đi trước, các manager có thể chỉ ra cho bạn là bạn đang ở đâu, và nếu bạn đi về hướng này thì bạn cần chuẩn bị những gì, có điều gì phải để ý - họ có thể là những la bàn tin cậy để bạn tiếp tục phát triển bản thân. Họ có kinh nghiệm của bản thân, có thâm niên trong nghề, thậm chí có nhiều mối quan hệ để hiểu rõ hơn được những đường hướng của những người đã đi trước.

Mình dùng từ “la bàn” ở đây, cũng còn một hàm ý khác: manager có thể chỉ ra cho bạn hướng nào là hướng nào; tuy nhiên họ không thể đẩy bạn đi được, mà bạn phải là người tự bước đi. Đừng yêu cầu họ làm Google Maps - “làm ơn cho mình lộ trình đi từ A đến B”. Lộ trình là từ bạn mà ra, bạn vẫn phải đi và vượt qua những chông gai bằng đôi chân thực lực của mình.

Và hy vọng một ngày nào đó, bạn cũng sẽ trở thành la bàn của những người khác.

Nếu bạn thích bài viết này có thể đọc thêm những bài mà mình có link ở trên

Dạo gần đây, trên mạng có nổi lên cái discussion về việc “Làm sao để người giỏi dạy mình”. Nhiều ý kiến đi qua đi lại, và mọi người đều đề cao việc là muốn để người khác dạy cho mình, thì mình phải bắt đầu từ một tinh thần học hỏi. Hãy làm một người ham học hỏi, cầu tiến, và biết cách tiếp thu, đó là lời khuyên chung từ những người đi trước - là cách để người giỏi muốn dạy bạn.

Sau nhiều năm đi làm, thì mình nghĩ những ý kiến đó là chính xác, nhưng chỉ là còn chưa đủ. Để người giỏi dạy mình thì đương nhiên là điều tốt rồi, nhưng chưa phải là tất cả. Điều tối quan trọng, đó là một khả năng của bản thân, để bạn có thể chủ động trong việc học tập.

Phải nói về người giỏi đi, nó cũng là một khái niệm không được định nghĩa rõ ràng. Sau nhiều năm giao tiếp với xã hội, bạn sẽ thấy xung quanh bạn có rất nhiều người giỏi, chỉ là đơn giản họ giỏi những mảng rất là khác nhau, vì họ đã dành rất nhiều thời gian và công sức trau dồi bản thân. Có người rất tài năng với những ý tưởng sáng tạo, có những người cực kỳ chặt chẽ với tư duy lập luận, có những người kể chuyện nghe như rót mật vào tai. Nếu bạn tham vọng và cầu tiến, bạn sẽ không muốn chỉ được một người giỏi dạy bạn, mà bạn sẽ mong muốn học hỏi từ tất cả những sự giỏi giang của những người xung quanh. Bạn không thể có 100 mentors, nhưng bạn có thể học hỏi từ 100 người khác nhau.

Một ý khác của nó, đó chỉ đơn giản là về sự hiệu quả trong sử dụng thời gian. Giả sử đi, bạn có một người sếp vô cùng tài năng và tận tình chỉ bảo. Mỗi tuần làm việc của bạn và của họ đều có 40-45 giờ làm việc. Sếp của bạn phải dành 50-60% thời gian cho công việc của bản thân, và ngoài ra có 4-5 bạn reports cần phải hướng dẫn. Chia một cách đơn giản, sếp của bạn, dù có tận tình và tử tế đến đâu, cũng chỉ có thể dành cho bạn ~4 tiếng mỗi tuần. Với 40 tiếng đi làm của bạn, chỉ cần bạn có khả năng chủ động học tập, thì chỉ với tốc độ bằng 10%, đã tương ứng với sếp bạn bỏ hết công sức để dạy bạn rồi. Thế nên, sử dụng 40 tiếng đó một cách thật sự ý nghĩa, sẽ giúp bạn trau dồi bản thân một cách vô cùng hiệu quả.

Cuối cùng, khi bạn biết cách chủ động học, bạn sẽ không chỉ dừng việc học tập của bạn ở trong thời gian của công việc. Bạn có thể học hỏi thêm từ những thứ xung quanh, từ những báo chí bạn đọc được, từ những câu chuyện bạn nghe được thoáng qua. Quan sát cách vận hành của xã hội, mà bạn cũng có thể nghiệm ra được nhiều điều. Những doanh nhân, những người trí thức thành đạt hay có các hội chơi tán gẫu với nhau, vì cùng một nội dung nói chuyện mà họ có thể nghe một hiểu mười, đúc kết ra được nhiều thứ và liên tục học hỏi điều mới. Mọi người không hề có ý định dạy nhau, nhưng việc giao tiếp, trao đổi với nhau giúp họ liên tục không ngừng phát triển.

Thế nên, thay vì tìm người giỏi để dạy mình, hãy bắt đầu bằng việc học một cách chủ động.

Vừa làm vừa học

Cùng ngẫm nghĩ lại quá trình đi học 12+4 năm của bạn đi (mình assume là nếu bạn có đọc bài của mình thì cũng đã đi làm và qua giai đoạn đại học). Bạn bắt đầu từ học đếm ngón tay, rồi sau đó đến phép cộng, chuyển qua phép nhân, vèo 1 cái là đến giải phương trình bậc hai, rồi chẳng hiểu từ đâu lên đến giải tích đạo hàm. Các kiến thức ở cấp độ cao hơn, nó được xây dựng dựa trên các kiến thức căn bản ở tầng thấp hơn. Bạn không bao giờ thắc mắc phép nhân, phép cộng, vì đó là những kiến thức vô cùng cơ bản mà nó là gốc rễ để xây đắp toàn bộ hệ thống kiến thức của bạn.

Đi cùng với kiến thức cơ bản đó là khả năng áp dụng. Bạn Lan đi xe đạp với vận tốc 200km/h thì sẽ mất bao nhiêu phút để đi từ Hà Nội đến London - đó là bài toán cụ thể, và bạn áp dụng sự hiểu biết của bạn để làm ngay một phép chia. Ví dụ đơn giản là thế, nhưng bạn càng học cao lên thì bài toán của bạn sẽ phức tạp hơn, như kiểu giải hệ phương trình khi học Lý học Hoá vậy. Trường học cũng sẽ chỉ dẫn cho các bạn cách định hình bài toán và đưa về một dạng căn bản nào đó để bạn có thể giải được. Một từ cũng hay được dùng trong công nghệ, đó là giải thuật - phương pháp để giải một bài toán từ những dữ kiện cho sẵn.

Quay lại với chủ đề của việc vừa học vừa làm đi. Nhìn lại về việc đi làm, bạn sẽ được giao cho những công việc, những task để làm. Đó là bài toán cụ thể mà bạn được giao để hoàn thành, và để bắt đầu giải được những bài toán được giao, bạn phải có được hệ thống kiến thức và cách thức giải bài toán mà bạn đang có trong tay.

Về kiến thức, bạn sẽ phải hiểu được các định nghĩa, các khái niệm, các hành động và mục đích bạn chuẩn bị làm. Nghiên cứu về định nghĩa, và nếu định nghĩa này dẫn đến những định nghĩa khác mà bạn chưa hiểu, hãy tiếp tục đi sâu thêm đến khi bạn nắm bắt được những thứ mà đang được nhắc đến. Bạn không thể chỉ dừng lại ở phép nhân khi không biết được phép nhân dựa trên phép cộng, vì như thế là bạn đang học vẹt phần kiến thức ở trên ngọn, mà không biết được cái gốc nó là ở đâu.

Phần thứ hai đó là cách làm, là giải thuật cho bài toán của bạn. Khi bạn hiểu được nội dung của đề bài, thì cách làm sẽ đến từ đâu? Đó chính là những ví dụ thực tiễn, mà bạn có học tập theo. Đó có thể là một bản template báo cáo mà bạn có thể làm theo. Đó có thể là một cái case study chuẩn chỉnh nào đó về các bước tiến trình mà bạn có thể cóp nhặt và học hỏi.

Điểm đặc biệt của hai thứ thông tin ở trên là gì? Đó là thông tin mà bạn có thể lấy được trong thời gian của bạn. Các kiến thức căn bản, các terminology chuyên ngành, các khái niệm cơ bản, bởi vì nó là hệ thống kiến thức căn bản, nên bạn có thể tự học và tìm hiểu. Các report mẫu, các ví dụ về bài làm, các case study đáng học tập, đó là những thứ bạn có thể tìm trong tài liệu có sẵn của công ty, hỏi thăm từ các đồng nghiệp cùng team, hỏi thăm bạn bè trong ngành (nếu có). Đặc biệt, nếu nói về algorithm, chắc các bạn trong ngành tech càng có thể mường tượng dễ dàng hơn, đó là kiểu tìm một ví dụ về cách implementation của một thuật toán, và ứng dụng vào trong task hiện giờ mình đang phải làm. Đó là gốc rễ của sự mày mò, để tự đi đào sâu vào vấn đề, hiểu được những khái niệm mình đang sử dụng, bài toán và giải thuật mình đang dùng.

Những sự mày mò này, là gốc rễ của việc tự học. Bạn biết cách mày mò, biết cách tự tiếp thu kiến thức, thì đó là cách để tận dụng thời gian làm việc hàng ngày của bạn để xây dựng cho bạn một nền tảng cực kỳ vững chắc. Và sau khi biết tự học và ngẫm nghĩ, đó sẽ là bước đệm, để bạn có thể học từ người khác.

Đánh giá và nhận định

Khi bạn học đến các cấp bậc cao hơn, bạn sẽ dần phải đối diện với các câu hỏi mở rộng hơn, những khái niệm hoặc là những vấn đề có nhiều cách phân tích, nhiều hướng tư duy và nhiều luồng ý kiến trái chiều. Để đi sâu vào nghiên cứu, bạn sẽ phải đào sâu tìm tòi nghiên cứu, phân tích và đánh giá, để tự đưa ra đáp án của chính mình.

Tương tự như vậy với việc đi làm, bạn sẽ gặp các vấn đề, các câu hỏi mở hơn, và bạn phải mở rộng suy nghĩ và đánh giá, và lựa chọn phương án phù hợp nhất để bạn đi tiếp. Để tiếp tục phát triển, khả năng đánh giá và nhận định chính là một trong những khả năng quan trọng nhất mà bạn cần phải phát triển. Bạn có thể được giao cho trọng trách planning cho cả một event, hoặc là được thiết kế cả một hệ thống lớn - có rất rất nhiều thứ cách thức, giải pháp khác nhau mà bạn có thể sử dụng. Làm sao để bạn có thể đưa ra lựa chọn phù hợp nhất?

Đó là những thứ đầu tiên mà bạn nên học từ những người cấp cao hơn, những người giao việc cho bạn, đó là tư duy của họ về việc nhận định một vấn đề, đánh giá một giải pháp. Đôi khi, những điều đó với họ rất là hiển nhiên, nhưng nó lại không hiển nhiên với những người xung quanh; vì vậy, bạn phải chủ động trong việc tìm hiểu và học tập từ những điều này.

Bạn nộp một bản báo cáo và nhận được feedback là không được, làm lại. Việc đầu tiên của bạn không phải là mở ngay cái báo cáo đó ra sửa, mà là bạn phải hỏi xin ngay ý kiến, xin feedback: vì sao lại phải làm lại, có phần nào ổn phần nào chưa ổn, nếu mình sửa theo hướng này có okay không? Ngược lại, bạn nộp bài và sếp ok ngay, bạn cũng phải tò mò và suy nghĩ tại sao nó lại được chấp nhận, mình cảm thấy mình làm tốt phần nào và không tốt phần nào, hoặc là mình đạt được tiêu chí gì khiến sếp lại đồng ý. Bạn cũng có thể chia sẻ và hỏi xem các đánh giá của đồng nghiệp, hoặc của người quen trong ngành, xem là cách bạn làm có đúng chuẩn hay không, hay còn gì mà bạn chưa giải quyết được.

Việc liên tục đánh giá, cũng như tìm hiểu nhận định của người khác về sản phẩm của bản thân, sẽ giúp bạn định hình một khả năng tư duy, về cách những người khác nhau có thể cùng đánh giá một vấn đề. Những sản phẩm của bạn được làm ra, bạn không chỉ làm ra nó để “xong việc”, mà nó là đánh dấu các mốc bản thân qua thời gian, về sự phát triển trong tư duy của bạn. Bạn nhìn lại sản phẩm bạn đã làm qua ở công ty trước hoặc là vài năm về trước, bạn cũng sẽ “à, nếu là bây giờ thì mình sẽ không làm thế này nữa, vì…” Khi bạn đặt tâm trí vào công việc, và quan tâm vào việc mình làm việc lần sau sẽ tốt hơn lần trước, đó là bạn đã phát triển thêm bản thân qua các lần đánh giá và nhận định của mình.

Mở rộng ra, bạn có thể bắt đầu nhận định và đánh giá thế giới bên ngoài. Bạn có thể xem một cái campaign marketing của một công ty khác đang chạy trên đường và nghĩ xem họ đang muốn làm gì và có thành công hay không. Bạn đọc một bài technical blog của một công ty khác và hiểu xem bài toán họ đang giải là gì và nếu là bạn thì bạn có làm gì khác không. Rồi mọi trải nghiệm cuộc sống của bạn, khi bạn biết cách nhận định và đánh giá, nó sẽ đắp thêm vào tích luỹ kinh nghiệm cho sự phát triển của bản thân.

Và đó, bạn đã trở thành một học sinh của tất cả mọi người.

Một số bài khác mình cũng viết về learning mindset, nếu bạn hứng thú với bài trên thì có thể đọc thử nhé!

Note: mình xin thế mà cuối cùng nó cũng không chịu.

Soliloqui đã đạt được 500 subscribers ạ. Rất cảm ơn cả nhà đã ủng hộ mình trong thời gian qua.

Có thể là thời gian tới mình cũng sẽ bận rộn hơn một chút và không viết được nhiều thế này nữa. Mình vẫn rất happy với những thứ viết lách linh tinh thế này, nên là mình vẫn sẽ muốn duy trì nó lâu lâu nữa.

❤️❤️❤️

Iceberg v3, đưa Lakehouse về cùng một mối

Viết về mấy thứ Technical của Data Engineering, thì mình cũng thấy có được một chút đón nhận. Nếu vậy thì mình cũng tranh thủ xin phép chia sẻ thêm một chút về những thứ mới có.

Trong tuần này, Databricks đã ra thông báo về phiên bản Iceberg v31. Với nhiều cải thiện về tính năng và chức năng, phiên bản mới này của Iceberg là một bước tiến mới của Databricks, và có vẻ hướng mà họ đang nhắm đến đó là dọn dẹp lại cái big data ecosystem mà họ đang quản lý. Đó là những bước tiến về cải thiện hỗ trợ các tính năng của SQL cũng như tệp dữ liêu. Đó là việc kết hợp những tính năng tốt đẹp của Delta và Iceberg để xây dựng ra tiêu chuẩn chung. Và những bước tiến tiếp theo để củng cố vững chắc hệ sinh thái mà họ đã và đang xây dựng.

Để kể một chút về lịch sử, thì gốc gác của những người sáng lập Databricks, đó là những người đã viết lên Apache Spark. Spark được ra đời làm thay đổi cả hệ thống xử lý big data, và với việc là những con người đóng góp chính vào việc phát triển các tính năng của Spark, team Databricks luôn luôn đóng vai trò là những người tiên phong trong xử lý Big Data.

Không chỉ muốn dừng lại là những người cầm trịch của Spark, họ còn có tham vọng nắm giữ cả hệ sinh thái Big Data, bằng việc phát triển thêm các tính năng về tầng Data Layer, về cách thức dữ liệu được lưu trữ, để thay đổi những gì đã được thiết lập ra từ hệ sinh thái của Hive/MapReduce. Delta Table format, đi cùng với khái niệm Lakehouse, được phát triển từ team Databricks, như một bước tiến mới về cách dữ liệu được lưu trữ và xử lý, với tham vọng đạt được những tính năng của Data Warehouse ở trong hệ thống Big Data, đó là ACID-compliant.

Cùng với thời đó, Iceberg cũng được sáng tạo ra, từ các Engineer từ Netflix; Iceberg nhanh chóng được donate cho Apache Software Foundation và từ đó được phát triển và sử dụng rộng rãi bởi các công ty với dữ liệu rất rất lớn, như Apple, Netflix, LinkedIn. Các nhà sáng lập Iceberg lập ra một công ty về quản lý dữ liệu, tên là Tabular.

Giữa sự cạnh tranh của Databricks Delta và Apache Iceberg, đã có hẳn hai nhánh về phát triển môi trường Lakehouse. Mặc dù ý tưởng về Table Format với Manifest files đều tương tự nhau, nhưng mà dần dần có sự khác biệt về mặt phát triển giữa hai phía. Databricks và platform của họ vẫn tiếp tục hỗ trợ Iceberg vì Iceberg rất được ủng hộ, nhưng về mặt quản trị thì tích hợp thì họ gần như phải làm việc gấp nhiều lần. Để rồi, đến năm 2024, thì Databricks đã mua lại cả công ty Tabular2, với lời hứa sẽ tiếp tục phát triển hệ thống Open Source, cũng như xây dựng một hệ thống lưu trữ dữ liệu mà có thể kết hợp được các tiêu chuẩn khác biệt với nhau (interoperability).

Và với Iceberg v3, đây có vẻ là bước tiến rõ ràng đầu tiên để Databricks đi theo hướng đi này, và để họ có khả năng là công ty đi đầu và dẫn dắt các quy chuẩn về Big Data.

Iceberg v3 có gì mới?

Trong thông cáo báo chí của Databricks, thì họ có liệt kê ra 4 điểm chính:

• Deletion Vectors

• Row Lineage

• Semi-Structured Data and Geospatial Types

• Interoperability across Delta Lake, Apache Parquet, and Apache Spark

Mình có thể đi qua nhanh về những thay đổi này.

Deletion Vectors, có thể hiểu là một cách sử dụng manifest file một cách thông minh để tăng hiệu năng xử lý. Ví dụ bạn có 1M records, nhưng mà bạn muốn xoá đi chỉ 10 records trong đó trong một lần thêm dữ liệu.

• Thời đầu tiên, một file mới với (1M-10) records sẽ được viết và thay thế cho file cũ.

• Deletion files: thay vì viết lại toàn bộ các records, một file mới sẽ được viết lên, lưu lại thông tin là 10 records này đã được soft-deleted và sẽ ko được compute engine xử lý.

• Deletion Vectors: khi bạn có nhiều bước thêm sửa xoá, số lượng delete files sẽ ngày càng tăng lên, và compute engine sẽ phải đọc rất nhiều file manifest. Deletion vectors được lưu lại với định dạng mới chỉ bao gồm 1 file, và sẽ lưu toàn bộ thông tin về các records đã được soft-delete → tối ưu về việc xử lý metadata lên nhiều lần.

Row Lineage, là một feature đã có từ trước cùng với Delta, và bây giờ được kết hợp với Iceberg. Mục đích của nó là cho mỗi một row trong record một cái identifier, để biết được là row này đã được xuất hiện từ version nào, snapshot nào, và được thay đổi từ lúc nào. Việc lưu giữ các thông tin về version history của Row giúp cho hệ thống compute engine có thể thông minh hơn trong việc xử lý dữ liệu. Ví dụ cho các cách xây materialization mà đi theo hướng incremental, engine có thể thông minh và chỉ lựa chọn các record mới được thay đổi để xử lý thêm, và không cần động vào các record cũ.

Thêm semi-structured Data (VARIANT) là một hướng đi cũng tương tự với thông báo trước đó về Spark 4.0.0, để mở rộng việc lưu trữ và xử lý dữ liệu semi-structured. Cùng với định dạng Geospatial, điều này cũng đồng nghĩa với việc Engine sắp tới có thể sẽ bổ sung thêm các tính năng về Geospatial Computation/Query. Đây đi cùng với hướng đi của Databricks, đó là mở rộng sự tương thích với ANSI SQL, và đầu tư hơn cho các tính năng SQL-based.

Và đương nhiên, việc Interoperability với Delta/Parquet mình cũng có nhắc đến ở trên, đi cùng với các update về Spark 4.0.0 kỳ trước, đây có vẻ là bước tiến tiếp theo của Databricks, để đẩy mạnh sự phát triển trong hệ sinh thái Spark.

Hướng đi nào cho tương lai

Về mặt lưu trữ dữ liệu, mình nghĩ đó là một sự chấp nhận của Databricks, đó là Delta sẽ không thể phát triển được như Iceberg. Mặc dù họ cũng nắm giữ Delta khá lâu, nhưng động thái của thế giới Big Data gần đây luôn ủng hộ sự phát triển của Iceberg. Từ việc AWS mở rộng việc tạo S3 Data bucket lưu trữ thẳng dưới dạng Iceberg, cho đến việc mua lại Tabular và đẩy mạnh sự tương thích của hệ sinh thái Big Data và Iceberg; mình nhận định là Iceberg sẽ là chủ lực của hệ sinh thái Lakehouse và sẽ có thêm nhiều tính năng được bổ sung thêm cho Iceberg trong thời gian mới.

Về Iceberg (và cả Spark nữa), mình thấy có một sự đẩy mạnh cho các tính năng cần thiết của Data Warehouse. Không chỉ là ACID-compliant nữa, mà các tiến bộ mới cũng khá đều đi theo các xu hướng tiếp theo mà các team Big Data đang đẩy mạnh: (1) tương thích với các tính năng của ANSI SQL → SQL sẽ là ngôn ngữ chung của data, và mọi người thay vì phải lựa chọn các phương thức xử lý khác nhau, thì sẽ quay lại về 1 nguồn là SQL, (2) các row-level functions.

Các row-level function, đặc biệt là các ảnh hưởng dẫn đến thay đổi 1-2 records, vốn luôn là trở ngại và là sự phân tách giữa hệ thống OLAP và OLTP. Việc support các tính năng để cải thiện xử lý cho các write nhỏ như thế này, đó sẽ là xu hướng/ước mơ tiếp theo của các anh em xử lý dữ liệu: Unify Batch/Streaming Interface: Batch để xử lý nhiều dữ liệu, và Stream xử lý Event-based và near realtime.

Nói chung, có nhiều thứ khá exciting đang diễn ra trong môi trường Big Data. Một năm mới nhiều thứ để hóng!

Dạo gần đây mình cũng rảnh rỗi hơn, cũng có thêm một chút thời gian cho bản thân. Nhờ đó mà mình cũng quay lại, nói chuyện và connect lại với các bạn các anh em đồng nghiệp cũ; lâu chưa nói chuyện nhưng mọi người cũng vẫn rất quý mến nhau. Âu cũng là may mắn của bản thân mình, xây dựng được những tình đồng nghiệp rất tốt và đáng quý.

Hôm nọ mình có nhờ anh đồng nghiệp cũ một việc nho nhỏ và có nói chuyện lại với anh sau mấy năm. Anh cũng kể là anh vẫn âm thầm theo dõi mấy cái blog xàm xí của mình, và thỉnh thoảng vẫn check lại mấy cái tài liệu mà mình viết ngày xưa trong Confluent của công ty. Đơn giản vậy thôi, nhưng mình cũng cảm thấy khá là xúc động; những thứ mình cố gắng làm ra ngày xưa, đến bây giờ vẫn còn có giá trị, vẫn còn có tác dụng giúp đỡ cho những người đến sau.

Trong cuộc đời đi làm của mình, mình cũng để lại khá nhiều “tác phẩm” phía sau lưng. Cũng có một vài lần, mình cũng nghe đứa junior mình quen, vào công ty cũ của mình rồi bảo “ơ em vẫn thấy mấy cái tài liệu trong công ty có tên anh này”, hoặc là “em có đọc cái anh viết hồi trước, cũng hay ho phết” (còn tệ hơn nữa thì “ya, I saw your name in all the git blame.."). Một phần thì mình cũng khá hoang mang vì mình cũng chả nhớ thằng Hiếu của 5-6 năm trước đã viết lung tung cái gì, nhưng một phần mình cũng rất là vui vẻ, như là là mình vẫn còn lại dấu tích và được nhớ đến ở những nơi mình từng đặt chân qua.

Và nếu ai có từng đọc qua những gì mình viết, mà có thêm câu hỏi hay cảm nghĩ gì, thì nhớ để lại cho mình một comment hoặc một câu hỏi gì đó, mình sẽ rất vui được nghe nó.

Khi nói về khái niệm, mục đích cũng như tác dụng của viết lách, bạn có thể thấy có khá là nhiều hướng suy nghĩ khác nhau. Đôi khi bạn sẽ thấy những lời khuyên, đó là bạn phải nắm bắt độc giả của mình để lựa lời mà viết. Ngược lại, nhiều khi lại có lời khuyên là bạn nên viết lại những ngẫm nghĩ của chính mình, để tự do phóng tác, và để thể hiện bản thân. Những lời khuyên đó, thực ra đều không sai; bởi vì nó là hai mặt của việc sáng tạo: bạn viết cho bản thân mình, và bạn viết cho độc giả của bạn.

Có hai góc nhìn khác nhau, mà nội dung và cách viết lách của bạn sẽ đi theo những hướng tư duy khác hẳn.

Viết để nhớ và viết để quên

Khi để viết cho chính bản thân mình, thì mình hay quy về hai mục đích rất là đơn giản: đó là viết để nhớ và viết để quên. Tuy nhiên, việc viết để nhớ và viết để quên có thể sẽ hơi khác với những gì mọi người có thể nghĩ đến.

Viết để nhớ, nghe thì có thể tưởng là việc viết lại các thông tin, để bạn có thể tra cứu lại lúc cần thiết. Tuy nhiên ý mình thì lại không phải như vậy; ở đây viết để nhớ, là dùng hành động viết lại, để xây dựng cơ sở tư duy và kiến thức cho bản thân. Một phần vô cùng quan trọng để hình thành sự hiểu biết và nắm bắt nội dung phức tạp, vì nó như là một bài tập cho bộ não vậy.

Bạn muốn hiểu hơn, nhớ kỹ hơn về một nội dung hay kiến thức nào đó, hay ngẫm nghĩ và viết lại nó. Khi bạn cố gắng hiểu rõ một vấn đề, và tìm cách trình bày lại nó theo những lời lẽ của bản thân mình, đó là khi bạn rèn luyện cho bản thân kỹ năng tư duy, phân tích và tổng hợp; đúc kết từ câu chữ của người khác thành kiến thức của bản thân mình. Quá trình viết lại như là những nét khắc vào bộ nhớ của bạn, làm bạn thấm hơn, và hiểu hơn về những thứ bạn đã được đọc.

Ứng dụng của việc viết để nhớ luôn đi theo suốt cuộc đời của bạn. Ngồi học trong lecture và cố gắng note lại những gì bạn được nghe giảng, sẽ giúp bạn hiểu nội dung được truyền tải hơn. Bạn viết study note để ôn thi, và việc viết lại những kiến thức đã đi qua sẽ là một cách hiệu quả để bạn rà soát lại kiến thức, củng cố lại hiểu biết trước khi đi thi. Bạn đi làm và cố gắng viết lại meeting note, bạn dần hiểu ra những nội dung được trao đổi trong buổi họp và nắm rõ được mục tiêu cũng như ý chính của các buổi bàn luận. Bạn ngồi viết lại documentation cho hệ thống bạn xây dựng nên, đó cũng là cách bạn review lại những gì bạn đã làm qua, ngẫm nghĩ thêm và hiểu về điểm yếu điểm mạnh, và cách phát triển nó theo các bước tiếp.

Viết để nhớ ở đây, là để cho bạn nhớ nó, chứ không phải giúp cho người khác nhớ đến nó. Tương tự như vậy, viết để quên, là cho bạn khả năng có thể quên được việc đó đi.

Khi nào bạn có thể quên đi được một thông tin, mà bạn nghĩ là quan trọng? Đó là khi bạn đã backup dữ liệu sang bộ nhớ phụ, và nó sẽ ở một chỗ mà bạn có thể dễ dàng truy cập lại. Khái niệm về viết để quên cũng tương tự như vậy; bạn viết lại thông tin, để bạn có thể tạm thời không cần phải nhớ đến nó nữa, dọn lại bộ nhớ của bạn để bạn có thể lưu trữ thêm các thông tin khác. Như là bạn giải phóng một phần bộ RAM của bạn và lưu sang ổ cứng, có thể truy cập nó lại sau.

Một ví dụ đơn giản và dễ hiểu, đó là khi bạn viết comment cho những dòng code của bạn, giải thích về ngữ cảnh của business logic. Thông tin này là quan trọng và cần thiết, tuy nhiên bạn chỉ cần đụng đến thông tin này khi nào có người hỏi, hoặc là đụng đến function bạn đã từng viết. Thay vì lưu giữ thông tin này trong đầu, bạn bổ sung dữ kiện này vào comment của đoạn code, đính kèm link đến JIRA ticket mà dẫn đến ngữ cảnh của logic. Khi đó, bạn không cần phải nhớ lại từng dòng nội dung mà bạn đã viết ra, nhưng mà bạn có thể dễ dàng dò lại dấu vết và hiểu được chuyện gì đã từng xảy ra. Bạn bỏ thông tin ra khỏi đầu, nhưng bạn luôn để lại dấu vết để có thể tìm lại được nó.

Tương tự như thế cùng với những thứ nhanh chóng trải qua trong đầu của bạn. Bạn có một ý tưởng hay nhưng đang bận rộn chưa có thời gian nghiên cứu thêm, thì viết nó vào sổ tay để có thời gian sẽ nghiền ngẫm thêm. Một bài báo hay nhưng mà dài nhưng bạn chưa có thời gian để ngẫm nghĩ, thì bạn ghi tạm đường link vào trong Notion và đến hôm nào bạn nhớ lại thì có thể tìm đọc. Chưa chắc bạn đã đọc nó, nhưng mà bạn có một sự yên tâm cho bản thân, là khi cần bạn có thể tìm lại được nó để xem ngay.

Viết cho người khác

Mình không thể bình luận được quá nhiều về việc viết cho người khác, bởi vì nó quá là đa dạng. Bạn có thể là một tác giả muốn nhiều người đọc tác phẩm của mình; là một marketer đang xây dựng một câu chuyện về branding; hoặc đơn giản chỉ là lên giải toả năng lượng bằng viết hò hét cho mạng xã hội xem. Một ma trận của mục đích, tệp khách hàng hay cũng như cách thực hiện; mình không thể bảo là mình hiểu hết mọi người muốn làm gì và thể hiện sự thấu hiểu với cuộc đời.

Mình chỉ có thể comment về cách suy nghĩ của mình khi làm việc mà thôi. Ở trong những công ty lớn, những môi trường làm việc chuyên nghiệp và thay đổi nhanh chóng, một điều mà ai cũng phải nhận thấy là sẽ có sự thay đổi liên tục giữa nhu cầu công việc hay dự án, cũng như đội ngũ nhân sự. Những thứ bạn viết ra ngày hôm nay, hoàn toàn có thể sẽ được đọc bởi những người ở team khác, dự án khác, công việc khác, khi bạn đã không còn ở đó nữa. Thế nên, để xây dựng được một tài liệu mà có giá trị sử dụng lâu, bạn sẽ phải học cách viết cho những người lạ mà bạn hoàn toàn chưa bao giờ được gặp mặt.

Để viết cho một người bạn không biết là ai, thực ra lại là một kỹ năng không hề đơn giản. Nhiều khi, bạn sẽ dễ đi vào thói quen viết tài liệu chỉ cho đồng đội của mình đọc, những người đó có kiến thức cũng như context từ trước, và điều đó khiến bạn lược bỏ rất nhiều chi tiết, và cuối cùng khi tài liệu đó được đọc bởi một người khác, thì nó lại không có giá trị sử dụng mấy.

Bạn trình bày nội dung, cho một bạn junior mới vào dự án để có thể nắm bắt được chi tiết. Hoặc là bạn giải thích cho một người ở đội khác, khi họ tò mò về những gì bạn đang làm. Hay là bạn đi phỏng vấn sang một công ty khác, bạn cũng có khả năng diễn giải lại về những thành tựu mà bạn đã làm được. Kỹ năng trình bày bản thân sẽ giúp bạn đi được xa, cũng như đạt được sự công nhận của mọi người.

Nó có thể bắt đầu bằng việc xây dựng các đầu mục/chỉ mục dễ dàng để người xem tiện theo dõi cấu trúc của văn bản; trình bày những ngữ cảnh trước khi đi vào giải pháp; hoặc là xây dựng quá trình lập luận tư duy để đi đến kết luận. Bổ sung thêm visualization để hỗ trợ cho quá trình theo dõi, thêm những đường dẫn bên ngoài để cho những người tò mò có thể đi sâu hơn và nghiên cứu thêm.

Việc trình bày cho người khác dễ hiểu, lại là một phần bổ trợ không thể thiếu cho việc bạn viết cho chính mình. Tiêu biểu của những wisom này là câu quote nổi tiếng từ Einstein, “If you can't explain it to a six year old, you don't understand it yourself.” Giảng cho một đứa nhỏ 6 tuổi thì có thể không hề đơn giản, nên có thể mình không nghe theo câu này một cách mù quáng. Nhưng mà, hãy thử cách để giải thích cho một bạn mới join team, một bạn sinh viên mới ra trường, hoặc là một bạn sinh viên mới bắt đầu vào ngành. Một cách để nâng cấp tư duy của bạn, xây cho mình một vốn kiến thức vững vàng, cũng như mang lại giá trị lâu dài cho cả bản thân lẫn những người xung quanh.

Thường thì mình viết nhiều mấy cái trải nghiệm lung tung hơn, nhưng mà dạo này cũng đọc lại nhiều thứ về Big Data. Đợt này một số bên mà mình theo dõi thì đều có thêm những tính năng mới được ra lò, và cũng mang lại nhiều thứ khác biệt mới. Cũng là cơ duyên thôi, nhưng cũng là một cơ hội để mình đọc qua lại những kiến thức mà mình cũng có bỏ ngang qua trong một thời gian.

Mình cũng bắt đầu với Big Data qua Spark, thử nghiệm và chạy project dbt đúng cùng thời dbt bùng nổ và trở thành thứ không thể thiếu trong môi trường data trong doanh nghiệp, và DuckDB cũng có những design philosophy khá là thú vị mà làm mình cũng khá hóng và theo dõi xem họ đang làm gì, bước đi tiếp thế nào. Cùng trong 1 tuần, mà có 3 cái announcement lớn:

• Bắt đầu là dbt và Ducklake, một Table Format mới, với những hứa hẹn là bài giải cho những vấn đề còn tồn đọng với Iceberg. (https://duckdb.org/2025/05/27/ducklake.html)

• Spark ra bản 4.0.0 release. Đã có bản preview một thời gian rồi, nhưng hôm nay là chính thức ra bản chính (https://spark.apache.org/releases/spark-release-4-0-0.html)

• dbt announce về dbt-fusion, gần như là bản mới của dbt. Thay cho core cũ chạy trên Python, và đổi thành rust, tuy nhiên mới chỉ có tích hợp của Snowflake mà chưa ra đầy đủ. (https://docs.getdbt.com/blog/dbt-fusion-engine)

Đây có lẽ là 3 trong những sản phẩm có ảnh hướng nhất đến xu hướng của Data Engineering cũng như Big Data hiện giờ; vừa là về độ phổ biến cũng như độ ảnh hưởng. Tự nhiên làm mình cũng muốn đọc qua và bàn luận về nó một xíu

Thay đổi mà không thay đổi

Đầu tiên phải nói về Ducklake. Khi tầm 2021, khái niệm Lakehouse bắt đầu được ra đời và đẩy mạnh bởi sức mạnh từ Databricks. Cùng với Hudi sẵn có từ Uber (với câu chuyện Unified Batch and Streaming computation), thì hai sản phẩm nổi trội cho nhu cầu của Lakehouse được ra đời và cạnh tranh với nhau, Delta Lake và Iceberg.

Là một bước tiến từ Hive Metastore, khi thông tin của một Dataset (hoặc là Table) bị chia làm hai phần: một là các file dữ liệu, và phần còn lại là các thông tin Metadata được lưu trong Metastore DB. Các table này có một vấn đề là nó không portable: bạn có thể copy hết các file dữ liệu, nhưng mà không có thông tin ở trong Metadata DB thì bạn sẽ không ghép nó lại thành một bộ dữ liệu hoàn chỉnh được. Delta và Iceberg được tạo ra là các format mới, với việc sử dụng các file log để lưu lại các bước biến chuyển của tệp dữ liệu, lưu lại dưới định dạng file (AVRO hoặc Parquet). Định dạng này có một điểm tối ưu đó là bạn có thể copy cả dataset đi cùng với nhau, và khi vẫn có đầy đủ thông tin transaction logs từ metadata files, thì mang đi đâu bạn cũng vẫn dùng nó được (portability).

Ducklake thì vừa là một lùi vừa là một bước tiến. Các dữ liệu metadata để support cho nhu cầu của Lakehouse, bây giờ lại được ghi lại vào database. Metadata layer bây giờ không còn đi cùng với dataset nữa mà nằm cùng với Metadata DB của DuckDB, và nó lại quay lại hơi tương tự như cách thiết kế của một Database(hoặc Data Warehouse truyền thống): như information_schema của mysql, hoặc Hive metastore. Nó giải được vấn đề của Lakehouse table format, đó là có quá nhiều file nhỏ được lưu rải rác để xây lại transaction history, bằng cách là sử dụng một thiết kế hơi cũ hơn.

Mình chưa comment gì về vấn đề này, vì mình thấy cách thiết kế của DuckLake và của Iceberg đều có những điểm hay ho khác nhau. Có lẽ cần thêm sử dụng thực tế để hiểu hơn về nó.

dbt fusion, thì có lẽ là release đơn giản và dễ hiểu hơn. Giữ nguyên cái logic và workflow của dbt cũ, tuy nhiên cái engine đằng sau được viết lại bằng Rust. Nhìn một cách đơn giản, nó là một cái “rewrite it in Rust” meme. Tuy nhiên, bổ sung thêm vào tốc độ xử lý nhanh hơn nhiều lần của Rust (so với Python), thì lần viết lại này đã xây dựng một hệ thống dbt với độ chuẩn mực và extensible hơn, với built in compiler, để hiểu semantic của các đoạn SQL, xây như một cái language server để kết hợp với IDE. Mình nghĩ đây là một bước chuẩn bị của dbt, để có thể mở rộng tính năng của họ từ phía trong nhiều hơn. Đương nhiên, chỉ cần chạy dbt run mà nhanh hơn được mấy giây là vui lắm rồi; nhưng chắc là cũng cần một thời gian kha khá để các integration/adapter được update dần.

Spark 4.0.0, thì mình thấy là một bước đẩy mạnh cho Spark Connect. Có vẻ là nhiều thứ được tách biệt trong Spark Core, để mở đường cho Spark Connect phát triển hơn, tách biệt giữa server và client của Spark ra làm 2 phần. Điều này sẽ giúp các bên có thể phát triển thêm được các lightweight client để làm việc cùng Spark, mà không cần nguyên cả Spark library để nó có thể chạy nữa. Ngoài ra, rất nhiều tính năng để tăng performance đã được bổ sung, cũng như thêm nhiều tích hợp cho các SQL syntax, cũng như data collation. Một bước đẩy mạnh, cũng như là chính thức dồn công sức vào SQL interface. Thay cho những Interface ngày xưa như Dataframe/Dataset, bây giờ việc mở rộng SQL Interface có vẻ đang là một thứ khá được chú trọng. Ngoài ra, cũng có thêm khá nhiều improvement về mặt Stream Processing cũng được bổ sung. Mình không dám comment quá nhiều về vấn đề này, do chưa đủ hiểu kỹ càng… chắc để bao giờ luyện công thêm một chút thì mình sẽ comment thêm.

Một số nhận định

Một hướng chung mình có thể nhận thấy, đó là mọi người đều có hướng đến là dùng SQL là ngôn ngữ của Data, là giao diện mà nhiều bên cần phải đầu tư. Khác với thời đại tầm 2020 khi mỗi bên đều đầu tư vào cách lưu trữ dữ liệu, partition, index khác nhau, cùng với những query pattern đa dạng; bây giờ có vẻ xu thế đó là giải quyết vấn đề hiệu quả bằng những thứ truyền thống chất lượng, đó là interact với dữ liệu bằng SQL vẫn là chuẩn nhất. SQL là thứ đi xuyên suốt cả hành trình data, và kỹ năng SQL có thể đi qua các hệ thống từ DB, Cloud Data Warehouse hay là các Data Processing Engine thì cái nào cũng chạy được. Data Engineering, cuối cùng quay lại về gốc là phải giỏi SQL.

Thin client của Spark sẽ là một bước tiến khá là thú vị, đặc biệt là nếu thin client làm việc với dbt (như SQL) hoặc là các notebook hiện tại. Giảm khá nhiều độ phức tạp trong việc thiết lập hệ thống, vì có sự tách biệt giữa bên cần viết logic (client) và bên xử lý. Mình nghĩ đây có thể sẽ giúp cho hệ thống ETL trở nên gọn ghẽ hơn nhiều; ví dụ như airflow worker của bạn không cần Spark mà chỉ cần có spark-client để nối vào hệ thống data processing, thế sẽ giảm nhẹ đi nhiều về phần maintenance.

Ngoài ra, có vẻ Rust đang được trở nên yêu thích hơn với anh em làm Data. Hiệu năng thì cao, và cũng chặt chẽ trong việc code so với Python. Các dự án như Arrow cũng khá thú vị, và cũng sẽ tăng cường và đẩy mạnh tầm ảnh hưởng của Rust lên Big Data Ecosystem.

Chắc sắp tới mình cũng sẽ phải đụng đến Big Data nhiều hơn. Những thay đổi này làm mình cũng thấy khá là hứng thú rùi đó.

Khi để nói đến một công việc nào đó, cách để mọi người mô tả thường sẽ được gói gọn trong cụm từ “role and responsibilities”, dịch nôm na ra là vai trò và trách nhiệm. Trách nhiệm thì như là những gạch đầu dòng về công việc, những thứ mà bạn sẽ phải đảm nhận; còn vai trò, thì là thường sẽ là chức danh, title của bạn ở trong tổ chức - bạn sẽ được phân cho một vai trò trong sơ đồ hoạt động của một bộ máy lớn.

Vì là chức danh trong doanh nghiệp nên là role sẽ có rất nhiều biến thể khác nhau giữa các công ty với nhau. Kết hợp với sơ đồ phòng ban loằng ngoằng của công ty lớn, hoặc là sự mập mờ thiếu rạch ròi ở công ty nhỏ hơn, nên một thứ tưởng chừng đơn giản mà có thể phức tạp không ngờ.

Role thì đặt gần với tên công việc, và có một số role thì khá là rõ ràng. Ví dụ như Software Engineer hay Data Analyst, bạn có thể từ role mà suy ra được một phần trách nhiệm và những thứ bạn cần phải làm trong công việc. Ở các big corp, có thể sẽ có những role nghe mù mờ hơn, như là Executive, Analyst hay Associate, nhưng mà nó sẽ đi chặt theo phòng ban, hoặc là nghiệp vụ của công ty, nên phải đi kèm với bộ phận làm việc nó mới rõ ràng hơn.

Ngoài ra, có những chức danh lại mù mờ hơn nhiều, tiêu biểu là danh xưng Manager. Manager, nhiều người nghĩ là trưởng bộ phận, trưởng phòng ban; tuy nhiên với thời đại mới mình có thấy nhiều chức danh nghe là manager mà không phải manager. Ví dụ như Account Manager quản lý tệp khách hàng, Territory Manager thì là quản lý khu vực, mà Product Manager thì cũng là quản lý sản phẩm - những chức danh là manager nhưng lại không có bổn phận của một nhà quản lý, một manager.

Sự định hình của các Manager, sẽ nằm ở responsibilities của họ, là những trách nhiệm mà họ phải quản lý. Đọc trong các JD tìm người, có thể thấy trong phần trách nhiệm của những role này sẽ là quản lý team, quản lý dự án, có khi là quản lý tiến độ mà cũng có khi là người dẫn đầu về kỹ thuật. Thường các bạn mới bắt đầu làm manager có thể trải qua nhiều lúng túng, vì không biết nên bắt đầu từ đâu, mình phải làm cái gì.

Ba trách nhiệm

Manager, đặc biệt là các bạn middle manager (không phải executive level) thì luôn là người bị ép từ mọi phía. Sức ép về chỉ tiêu từ trên xuống, sức ép quản trị của đội ngũ phía dưới, từ các phòng ban xung quanh về chất lượng, về yêu cầu công việc. Nó là một mớ bòng bong, mà nếu bạn không có hướng thu xếp ổn thoả thì khả năng cao là sẽ trải qua một chút ngợp.

Với mình, mình nhìn về trách nhiệm của manager sẽ có thể chia thành 3 phần chính, cũng tương ứng với 3 phần mà manager nào cũng sẽ phải làm và quan tâm. Một là technical management, quản trị về sản phẩm của đội nhóm, về chất lượng của những sản phẩm của team với những stakeholder bên ngoài. Hai là project managment, đó là quản trị về thời gian và vận hành, làm sao để sắp xếp công việc và thời gian để đạt được yêu cầu đúng thời hạn. Và cuối cùng, đó là people management, quản trị con người, xây dựng đội hình của team, để team phát triển vững mạnh và hoạt động hiệu quả.

• Technical management: Cái này có lẽ sẽ thân thuộc hơn với các bạn làm trong những ngành mà yêu cầu nhiều về kỹ năng. Nhiều bạn trong ngành này, vì có kỹ năng tốt và hoàn thành được nhiệm vụ, nên được promote lên thành manager. Quản lý technical thì hơi khác với việc làm việc technical: thay vì bạn hoàn thành đúng nhiệm vụ được giao, thì bạn phải làm người lãnh đạo thế nào mà có thể giúp cho team của bạn hoàn thành được nhiệm vụ được giao. Đó có thể là coaching, hướng dẫn các bạn junior hơn hoàn thành được nhiệm vụ của mình. Khó hơn thì có thể là xây quy trình và mang mọi người đi theo quy trình, để đạt được chất lượng đầu ra tốt hơn. Nâng tầm “technical” của team, sẽ khác với nâng tầm technical của bản thân - bạn muốn xây dựng một tập thể vững mạnh và deliver được những sản phẩm chất lượng, vì đó mới là cách để bạn có thể đi được đường dài.

• Project Management: Đây là nơi mà khả năng thiết lập kế hoạch, cũng như khả năng đối nội đối ngoại sẽ lên ngôi. Không có cái gì to tát mà có thể được xây dựng trong vòng 1 ngày cả, bạn sẽ phải quản lý những dự án trải dài vài tháng đến cả năm. Bạn phải biết cách thiết lập kế hoạch dựa theo các nhu cầu, cùng với cột mốc(milestones), cũng như quy trình để đảm bảo tiến độ và de-risk(giảm thiểu rủi ro) cho các dự án. Về mặt đối ngoại, bạn sẽ làm việc với các stakeholders để nắm được nhu cầu, cũng như negotiate các đề mục, các chỉ tiêu, ngân sách, để bạn có thể hoàn thành được dự án. Đối nội, bạn phải là người dẫn dắt đồng đội, phân chia công việc cũng như tháo gỡ vướng mắc, để team có thể cùng nhau hoàn thành mọi vấn đề đúng theo chỉ tiêu. Đảm bảo về việc vân hành dự án một cách trơn tru, cũng như giao tiếp giữa các bên diễn ra một cách mượt mà

• Cuối cùng, people management: đây là bài toán về quản trị con người. Với từng cá nhân trong team của bạn, bạn là người có nhiệm vụ để họ có thể tiếp tục phát triển, để họ có thể nâng lên tầm cao mới. Có nhiều người dùng từ là “set up for success”, gần như là xây dựng lộ trình cho một người có thể tiếp tục phát triển bản thân và có thể thành công. Một phần là lắng nghe những chia sẻ, cũng như góp ý để họ có thể cải thiện công việc hiện tại. Một phần khác, đó là quản trị về sức mạnh của team, làm sao để khi hai người góp sức vào thì có thể đạt được hiệu quả nhiều hơn khi họ làm việc 1 cách riêng lẻ (nếu đọc mấy cái bài viết văn hoa thì là 1+1 >2 đó). Đó còn là việc khen ngợi cũng như thưởng cho mọi người khi hoàn thành xuất sắc nhiệm vụ, và đó cũng là quản lý những người không hoàn thành. Vì đây là vấn đề giữa người và người, đây cũng sẽ là phần oái oăm và khó khăn nhất đôi với nhiều người quản lý.

Tuy ba mà một

Ba nhiệm vụ này, tuy nghe thì riêng rẽ, nhưng lại khó có thể tách rời. Một phần nào đó, bạn khó có thể làm cái này mà không ảnh hưởng đến phần kia. Nó xen kẽ với nhau, và góp phần xây thành một bài toán chung cho người lãnh đạo.

Ví dụ, bạn muốn giao cho một junior trong team để làm một cái task hơi khó một chút. Về phần technical, bạn muốn đảm bảo là chất lượng sản phẩm đầu ra đạt chuẩn, nên có thể bạn sẽ phải chuẩn bị sẵn một template để junior có thể làm theo, hoặc bạn có thể xây quy trình review với team để sản phẩm bạn nhận được là đạt chất lượng cần thiết. Về phần project, bạn cũng phải đảm bảo là việc giao task cho junior này là hợp lý, ví dụ như là không làm ảnh hưởng đến tiến độ dự án, hoặc là giúp một bạn senior hơn rảnh tay để có thể giải quyết một task khó hơn. Kết hợp với people management, đây có thể là một thử thách bạn muốn giao cho bạn junior trẻ, để bạn đó có thể học thêm một kỹ năng mới, và lần sau bạn có thể làm lại và tiếp tục phát huy.

Khi nhìn vào công việc của một manager, nhìn vào các khía cạnh khác nhau của các responsibility, bạn có thể thấy như là một người, nhưng đang cân bằng 3 bài toán một lúc. Đương nhiên, ai cũng sẽ có ước mơ, một ngày mình có thể đi theo lộ trình và sẽ đi lên làm một quản lý. Tuỳ theo lộ trình phát triển của bạn, bạn cũng có thể nhìn vào những đầu mục này để bạn có thể tiếp tục phát triển bản thân.

Nhiều bạn phát triển lên từ những ngành technical, khi các bạn phát triển khả năng technical của mình tốt rồi và được promote lên các chức vụ quản lý. Vì bạn có khả năng nên có thể khả năng technical management của bạn cũng tốt, và vì bạn hiểu rõ domain nên bạn cũng có thể nắm được một phần của việc project management. Có thể bạn sẽ phải chỉnh lại bản thân một chút và cải thiện thêm khả năng people management của mình hơn. Cũng có những bạn, đã làm việc với nhiều team hoặc là chỉ dẫn rất nhiều người trong khả năng của mình, và đã rất khéo léo với khả năng quản trị con người - bạn có thể tập trung phát triển kỹ năng technical hoặc khả năng quản lý dự án, những thứ có thể giúp bạn lên đến tầm cao hơn.

Đương nhiên, mỗi ngành mỗi nghề cũng sẽ một khác. Thậm chí hiện nay, ở các công ty lớn trên thế giới còn mở ra một ngạch khác để các bạn IC (individual contributor) có thể đi xa hơn, như là Principal/Staff level. Những người này sẽ cần rất vững về mặt technical management, nhưng có thể sẽ không cần làm nhiều nhiệm vụ về people management.

Mình vẫn luôn vô cùng hứng thú với các lĩnh vực về quản lý, quản trị. Viết lại những thứ này, hy vọng có một bạn nào đó đang muốn vươn lên các vị trí cấp cao hơn, có thể hiểu ra thêm được chút gì đó.

Nếu bạn thích bài viết này, có thể đọc thêm:

Nếu mọi người hay đọc những gì mình biết thì cũng có nghe mình nhắc đến là mình có 1 cái Threads. Mình vẫn dùng Threads như kiểu Twitter thời những năm 2010, thời mà nó là một cái chỗ để chia sẻ lung tung cũng như là một cái micro-blog cho những gì mình trải qua hàng ngày. Có thể là một bài viết hay ho nào đó mình mới đọc được, hoặc là một cái xàm gì đó mình mới vừa nghĩ ra, và quan trọng nữa là chia sẻ những cái gì mình viết ở trên substack.

Đương nhiên với sự tréo ngoe của cuộc đời, cái gì nghiêm túc đầy kiến thức mình muốn chia sẻ thì không có mấy người quan tâm; còn mấy cái thứ xàm xí mình viết lung tung thì lại đôi khi được ủng hộ một cách kỳ lạ. Thôi thì chịu vậy, mình happy nếu những gì mình viết có người đọc, thế là được rồi.

Nhưng dù thế nào đi chăng nữa, thì mình cũng không thể viết lách một cách vô tư như 10-15 năm về trước. Hò hét comment từng bàn thắng khi xem đá bóng, từng tình huống căng thẳng khi xem Dota, hoặc là comment theo những cái liveshow mà mình đang xem. Thêm cùng sự xuất hiện của algorithmic feed, các nội dung sẽ được recommend mà không đi theo thứ tự thời gian, mà sẽ đưa đến những thứ mà hệ thống cảm thấy là “phù hợp” nhất với mình. Khi những thứ mình viết ra cũng đi vào cùng một dòng chảy đó, tự nhiên bạn sẽ không muốn những gì mình viết trở nên lạc lõng. Một cách tự nhiên, từ sự thay đổi trong cách tiêu thụ nội dung, dẫn đến một sự thay đổi trong cách viết, cách truyền tải. Tự dưng, những lời bạn chia sẻ đều mang một cảm giác nó đang muốn nhắn gửi đến một ai đó, có một mục đích nhất định đằng sau.

Đi ngược lại dòng chảy của xã hội khó hơn mình tưởng. Và từ lúc nào đó, cách chia sẻ của mình cũng không còn được vô tư nữa.

Độc giả tôi biết và độc giả tôi không biết

Mình dùng từ độc giả vì đây là một bài viết, nhưng mà nếu trong đúng các từ mà nghe nó business-y hơn thì chắc là audience. Đó là những người đọc bài viết của bạn, những người xem photos hoặc videos của bạn, hoặc là nghe bạn hót trên podcast.

Thế giới của những năm trước được định hình bởi những nội dung được gửi đến những người nhất định. Khi bạn viết một cái bức thư, một cái email, bạn chỉ có một người gửi rõ ràng ở trong đầu, và nội dung hoàn toàn chỉ dành cho chính người đó. Đó là những độc giả, những người xem mà bạn biết; và có sự kết nối với họ ở một tầng nhất định. Có những context khác giữa bạn và người xem, và nó sẽ khiến tương tác của họ với nội dung của bạn theo những hướng rất riêng của họ mà bạn cũng có thể mường tượng được phần nào.

Với sự phát triển của algorithmic feed, bạn sẽ thêm một tệp audience mà bạn không ngờ tới, content của bạn được họ nhìn thấy và để ý đến hoàn toàn là dựa vào sức mạnh của thuật toán. Điều khác biệt của những độc giả này, đó là họ chưa bao giờ xây dựng context về bạn: họ không biết bạn là ai, họ không biết bạn có niềm đam mê và sở thích gì, và gần như không biết được personal views của bạn về các chủ đề văn hoá hay xã hội hay là gì. Thậm chí bạn có thể đang kể một inside joke mà cần phải biết trước khá nhiều thứ mới hiểu được.

Những cuộc chạm trán này, hầu hết thì harmless, hoặc là chỉ có một chút hiểu nhầm đơn giản. Đó là 90%, nhưng chỉ cần 10% còn lại là đã đủ bùng thành cuộc cháy to: nhiều khi chỉ là tranh cãi, nhưng rồi có thể dẫn đến name-calling, rồi đến vơ đũa cả nắm chửi xéo lên đến một cộng đồng nào đó(“à mày là XXX nên YYY là đúng rồi”). Thêm dầu vào lửa, những người xung quanh cũng bất bình và cũng phải nhảy vào tranh cãi, không ai nghe ai. Cãi nhau trên mạng thì thường làm gì có người thắng, chỉ có 3 bên cùng thua: bên chửi, bên cãi và bên người qua đường.

Viết cái gì nói cái gì?

Ở cái thời đại mà những gì bạn nói đều có khả năng được nhìn thấy bởi bất kỳ một người nào trên mạng, số lượng độc giả mà bạn không ngờ tới, trở nên nhiều hơn rất nhiều so với những độc giả mà bạn biết. Dù có hay dù không, bạn cũng sẽ bị ảnh hưởng bởi những người theo dõi bạn. Một mặt, bạn có thể không tự do với câu từ của mình được như trước; mặt khác, bạn có khả năng lan rộng và chạm đến không chỉ 100 mà có thể đến hàng trăm nghìn người khác. Nó như một tấm vé số diệu kỳ mà mạng xã hội mang lại cho bạn.

Mình biết có nhiều bạn trẻ cũng hay nói rằng: “đây là chỗ riêng của tôi, đây là tường nhà tôi, tôi muốn gì thì viết, tôi viết cho tôi đọc chứ không phải để phục vụ cho người khác”. Mặc dù đó là một ý tưởng nghe chừng đơn giản và hợp lý, nhưng mà mình lại nghĩ nó là một điều không thể, cũng như không nên. Tự do ngôn luận không đi kèm với việc bạn được bác bỏ trách nhiệm với những gì mình nói, nên khi những lời nói của bạn có ảnh hưởng, bạn không thể chỉ bảo vệ những gì mình viết vì “mình thích thế”.

Mình nghĩ những lời nói đều có sức mạnh và tầm ảnh hưởng của nó. Words are weapons, you can’t just wield it however you want. Nếu những câu chuyện gần nhà thì việc người nổi tiếng lợi dụng sức ảnh hưởng của mình để quảng cáo sai sự thật và đã bị kết tội lừa đảo. Xa hơn nữa là những câu chuyện lịch sử hoặc hiện đại về propaganda, về bưng bít thông tin, về chiến tranh truyền thông; còn về dân sự thì là lan truyền của fake news hoặc là những làn sóng tranh chấp bạo động xảy ra trên khắp nơi trên thế giới. Đương nhiên đó là những ví dụ vĩ mô, nhưng mà những thứ to lớn đều được bắt đầu từ những làn sóng nhỏ cộng dồn lại.

Chịu trách nhiệm với những gì mình viết ra, cũng đồng nghĩa với việc bớt đi sự vô tư trong chia sẻ. Một phần nào đó, nó mang lại một sự vô hồn trên mạng xã hội: một là các brand đang hô hào quảng bá sản phẩm của họ; hai là những người đang tự xây dựng thương hiệu cá nhân, lặp đi lặp lại những nội dung sáo rỗng viết theo format như rải tờ rơi “theo dõi mình đi”. Những người hài hước thú vị nhất, bây giờ chỉ còn tồn tại trong các group chat nhỏ, hoặc bạn chỉ có thể gặp được ngoài đời.

Mình thì vẫn viết, vẫn có đam mê chia sẻ. Muốn giữ được sự vô tư, nhưng vẫn mong được sự lan toả. Muốn mang được bản sắc cá nhân, nhưng cũng muốn được đa số đón nhận. Có lẽ đây là một sự tham lam, nhưng không thể vì thấy khó mà không làm. Hơi đi ngược dòng của xã hội một chút, nhưng có lẽ thế lại vui hơn.

Nếu bạn thích bài viết này, bạn có thể đọc thêm:

Một chủ đề lớn trong thời gian gần đây mà được nhiều người bàn tán, đó là về sự khó khăn trong thị trường lao động. Việc thì khan hiếm, người thì lại nhiều, mà yêu cầu lại càng tăng cao lên; câu chuyện có thể được kể từ nhiều hướng nhiều nguồn, nhưng mà đều có một cảm nhận chung, đó là một giai đoạn khá là ảm đạm trong thị trường lao động.

Nếu bạn cũng là một người cũng bị ảnh hưởng trong giai đoạn này, thì trước hết mình cũng muốn chúc mọi người may mắn, và cũng hy vọng mọi thứ sẽ nhanh trôi qua để chúng ta có thể quay lại với một thời kỳ tươi sáng hơn!

Với hơn chục năm đi làm rồi, mình cũng trải qua những thời gian đi tìm việc, cũng như có đóng vai làm nhà tuyển dụng nhiều lần. Lướt qua mạng xã hội, mình có thể cảm thấy sự đồng cảm với những post đầy hoang mang của những bạn đang trong độ tuổi đi làm. Lúc nào cũng thắc mắc là mình đã có đủ kỹ năng, kiến thức hay là bằng cấp chưa; làm thế nào để thể hiện bản thân thật tốt và được nhà tuyển dụng chú ý. Rồi đến khi đi làm (hoặc nhận được lời mời đi làm) thì lại thắc mắc là công ty này là red flag hay greed flag, mọi thứ xảy ra này là có đúng hay là không. Từ phía doanh nghiệp cũng thế, các discussion này thì không phổ biến rộng rãi, nhưng luôn có thắc mắc, đắn đo là làm sao để tìm được đúng người, tìm được người phù hợp giữa muôn vàn ứng viên.

Từ kinh nghiệm của mình, tuỳ vào hoàn cảnh của mỗi người thì chi tiết cụ thể sẽ có sự khác biệt, chứ thực ra trong vấn đề việc tìm người người tìm việc này, chỉ có một câu hỏi quan trọng nhất mà cả hai bên cùng nên phải đặt ra và tìm cách để trả lời: “Mình có muốn làm việc cùng người này hay không?”. Khi có nhiều ứng viên, người mạnh về technical, người lại rất tốt về mindset, người thì có kinh nghiệm từ trước; những gạch đầu dòng này rất là khó so sánh với nhau theo điểm cộng điểm trừ. Chính vì vậy, câu hỏi về việc ai là người mà bạn muốn làm việc cùng nhất sẽ là điều vô cùng quan trọng.

Về phía người tìm việc, thì câu này cũng có thể đi theo nhiều hướng khác nhau. Khi bạn còn đang là một junior chưa có nhiều thứ trong tay, thì câu hỏi của bạn sẽ là “làm sao để trở thành một người mà người khác muốn làm việc cùng?”. Đối với những bạn đã senior hơn, biết thiên hướng cũng như mong muốn của bản thân, đó là cách để bạn lựa chọn "đây có phải là người sếp/người đồng nghiệp mà mình mong muốn không?”.

Chỉ là một câu hỏi dẫn đường đơn giản, nhưng nó cũng sẽ là mấu chốt cho cả sự nghiệp của bạn.

Cọc đi tìm trâu

Để tiếp cận vấn đề này, mình sẽ đi trước từ hướng của một doanh nghiệp, của một hiring manager. Khi bạn muốn xây dựng một quá trình tuyển dụng, bạn muốn tìm cho bản thân được những đối tượng phù hợp, mà bạn sẵn sàng làm việc cùng. Với câu hỏi “bạn có muốn làm việc cùng người này không?”, hãy tìm cách để ứng dụng nó vào trong cả hiring process, từ việc viết JD (job description) và chọn lọc, cho đến phỏng vấn và onboarding.

Việc đầu tiên mà một hiring manager nên làm, theo mình là đầu tư công sức vào việc viết JD. Suy nghĩ và xây dựng JD của bạn không nên chỉ đơn thuần dừng ở việc là tìm người biết cái X, cái Y, mà nó sẽ đi cùng với cả môi trường làm việc bạn đang làm nữa. Môi trường làm việc của bạn, cũng như những dự án sắp tới đang chờ đón, sẽ ảnh hưởng nhiều đến nguồn nhân lực mà bạn cần có, cũng như cách để bạn có thể mang thêm một người mới vào team.

Ví dụ (ví dụ của mình có thể sẽ hơi Tech một chút), công ty bạn đang cần tuyển thêm nhân lực backend, và dự án là Ecommerce viết bằng Golang. Đương nhiên nếu ứng viên có biết Golang từ trước thì chắc chắn là một thế mạnh, nhưng nếu bạn muốn mở rộng candidate pool, bạn có thể xem xét các ngôn ngữ có nhiều tương đồng (ví dụ như C# hay Java), thì sẽ là +0.5 điểm thay vì là +1 điểm chẳng hạn. Nếu ứng viên đã có kinh nghiệm về Ecommerce, thì đương nhiên cũng là một điểm cộng về business understanding; tuy nhiên bạn cũng có thể xem xét những phần nhỏ hơn trong ecomm, ví dụ như Cart/Order/Checkout/Payment flow, hoặc là SKU/Inventory Management, hoặc là kinh nghiệm về Logistics/Delivery; tuỳ nhu cầu của dự án mà bạn có thể đi sâu hoặc mở rộng nhu cầu. Dự án sắp tới của bạn là một project hoàn toàn mới, hay là bạn phải mở rộng và scale up hệ thống đã có sẵn - đó là điều cần quan tâm về kiến thức kỹ thuật cũng như kiến thức domain. Bạn có thời gian để train các ứng viên của mình lên hay không, hoặc là quy trình hoạt động của team dev sẵn có đã đủ tốt chưa để một bạn mới vào có thể thích ứng trong 1-2 tháng làm onboard? Rất nhiều câu hỏi nên được đặt ra, từ trước cả khi quá trình tuyển dụng bắt đầu, và bạn càng có các câu hỏi cụ thể hơn, thì bạn sẽ càng rõ ràng về con người mà mình muốn tìm kiếm.

Việc chuẩn bị JD một cách kỹ càng sẽ giúp cho bạn rất nhiều trong quá trình lọc CV và lựa chọn phỏng vấn. Những gach đầu dòng cụ thể sẽ giúp bạn hiểu rõ hơn quá trình sàng lọc của bản thân, và sẽ giúp bạn đánh giá và shortlist các ứng viên một cách hiệu quả. Về mặt kỹ thuật, sẽ có những chỉ tiêu mà bạn nhân thấy là ứng viên đạt, không đạt, hoặc là chưa rõ ràng. Khi đó, vòng phỏng vấn trực tiếp sẽ là nơi mà bạn tìm hiểu về ứng viên, khẳng định những thứ họ đạt, và làm rõ thêm những đầu mục mà bạn cảm thấy chưa rõ ràng.

Với mình, vòng phỏng vấn trực tiếp sẽ là câu trả lời rõ ràng nhất cho việc “mình có muốn làm việc cùng với người này hay không”. Làm việc cùng, không chỉ nằm ở giải quyết bài toán kỹ thuật, mà còn ở việc giao tiếp trong công việc, trao đổi kiến thức, cũng như không khí làm việc hoà thuận đồng lòng. Đó có thể là sự chỉn chu trong chuẩn bị, hoặc là sự rõ ràng rành mạch trong trình bày vấn đề. Cũng có thể đó là khả năng xử lý những bài toán vượt khả năng, tinh thần học hỏi và cầu tiến. Cũng có thể đó là sự sâu sắc trong tư duy, biết cách đặt vấn đề và đặt câu hỏi.

Từ phương diện cá nhân, có một câu hỏi phỏng vấn mà mình khá là thích áp dụng. Mình hay nhìn vào hồ sơ của ứng viên, khi mà họ thường đã trải qua một vài project khác nhau, có thể là trong công việc trước, dự án cá nhân, hoặc là trong quá trình học tập. Câu hỏi của mình sẽ dựa trên đó: “Theo bạn, trong những dự án bạn đã trải qua, thì dự án nào bạn thấy thú vị/khó khăn/mở mang nhất?”. Tại sao phải là “nhất”, vì với mình nó là một câu hỏi về khả năng đánh giá: phải có sự suy nghĩ và so sánh giữa những thứ mình đã từng làm và ngẫm nghĩ về nó, thì mới có sự chênh lệch hơn kém. Khi một dự án là “nhất” so với một dự án khác, thì nó cũng sẽ để lại ấn tượng sâu đậm hơn với ứng viên nên ứng viên cũng sẽ nhớ về nó một cách rõ ràng hơn. Đó là tiền đề cho các câu hỏi nối tiếp, mà tuỳ vào cách trả lời mà mình sẽ sử dụng để đi tiếp. “Tại sao dự án này lại để lại ấn tượng như thế?” - để ứng viên giải thích về điểm mạnh điểm yếu của bản thân. “Nếu traffic của hệ thống tăng lên gấp 100 lần thì bạn có cách giải quyết thế nào” - để ứng viên xử lý cùng một bài toán nhưng với đề bài được nâng độ khó. “Nếu bây giờ được làm lại thì bạn sẽ làm gì khác trước” - cách đối diện với lỗi sai và phát triển lên thêm từ đó. Từ một câu hỏi đơn giản, mà tuỳ cơ ứng biến, sẽ dẫn đến rất nhiều thứ để cho ứng viên có khả năng bộc lộ.

Người đồng nghiệp đáng mong chờ

Nếu như ở trên thì mình nói về cách mà người tuyển dụng có thể tìm được cho bản thân một ứng viên thật tốt, thì đương nhiên sẽ phải kể lại câu chuyện theo hướng ngược lại. Người nào đi tìm việc, thì cũng mong muốn tìm được cho mình một cơ hội thật tốt cho bản thân.

Với tính xấu của bản thân là suốt ngày khuyên bạn bè bỏ việc (như kiểu cộng đồng mạng chỉ vote chia tay), thì câu cửa miệng của mình trong lúc chém gió là: “Tuần nào cũng phải đi làm 40+ tiếng, trong gần 40 năm cuộc đời, thời gian đó là quá dài để bị vướng trong một công việc mà mình không thích”. Môi trường làm việc của bạn, đồng nghiệp, sếp, lãnh đạo sẽ là những người trải qua 40 tiếng hàng tuần với bạn, và khi bạn đi tìm việc, câu hỏi của bạn cũng sẽ là đi tìm những con người mà bạn muốn dành thời gian 40 tiếng mỗi tuần cùng với họ. Nói đơn giản, nhưng đây lại là một câu hỏi vô cùng quan trọng trong lúc tìm và làm việc.

Bạn đang còn trẻ và ấp ủ nhiều ước mơ, thì bạn muốn tìm được môi trường nhiều thử thách và năng động, sếp có khả năng lãnh đạo và chỉ dẫn, nhiều cơ hội cho bạn học hỏi và phát triển. Nếu bạn đã có kinh nghiệm hơn, thì thay vì muốn được cầm tay chỉ việc thì bạn muốn có một nơi để bạn có khả năng phát triển tự do để tìm thấy điểm mạnh của bản thân; một nơi mà lãnh đạo tôn trọng ý kiến và khả năng của bạn. Còn khi bạn ổn định hơn, thì có thể là một nơi mà bạn có thể được tôn trọng với cuộc sống cá nhân của mình, phát huy khả năng và kinh nghiệm của bản thân trong yên bình. Biết mình muốn gì, và tìm cho bản thân một môi trường phù hợp, nó cũng là câu chuyện cho cả quãng đời đi làm.

Có đi thì cũng có lại, bạn muốn tìm cho mình những người đồng nghiệp tốt, thì những người đồng nghiệp đó cũng muốn tìm cho họ những người tương tự như vậy. Muốn được tuyển dụng, thì bạn nên biến bản thân thành một người đồng nghiệp mà người khác muốn làm việc cùng.

Bạn có từng nghe về lời khuyên là khi bạn viết CV ứng tuyển cho mỗi công ty thì bạn nên viết một bản CV phù hợp với từng vị trí mà bạn apply? Ý tưởng ở đây cũng tương tự, đó là thể hiện sự phù hợp của bản thân cho những môi trường mà bạn đang ứng tuyển. Cùng là một con người thôi, nhưng nếu bạn tìm hiểu về những nơi bạn đang mong muốn đến, thì họ sẽ có những tiêu chuẩn cũng như một số thứ nhất định mà họ tìm kiếm; và nếu bạn biết đúng cách để thể hiện bản thân thì bạn sẽ có thể đạt được cơ hội.

Tuy nhiên, không phải là bạn có thể tự vẽ ra một hình tượng của bản thân để bạn có thể ứng tuyển; bạn còn cần tiếp tục bổ sung và cải tiến bản thân mình, thành một đồng nghiệp trong mơ. Bạn muốn có một người sếp hướng dẫn chỉ bảo, thì bạn phải có khả năng của một học trò biết cách tiếp thu và phát triển. Bạn muốn được đưa vào các dự án đầy thử thách, thì bạn cũng phải thể hiện khả năng của bản thân khi được đối diện với những vấn đề khó khăn (mà có thể bạn chưa được học mà sẽ phải tìm tòi thêm nhiều). Bạn muốn xây dựng một mối quan hệ tốt với đồng nghiệp, thì bạn cũng phải trau dồi khả năng giao tiếp cũng như ứng xử của bản thân.

Còn để nói về lâu về dài hơn, khi bạn là một người đồng nghiệp mà được người khác yêu quý, nó cũng sẽ là tiền đề để bạn nhận lại được nhiều cơ hội hơn. Có thể 5-10 năm về sau, khi bạn cần loay hoay tìm việc; những người đồng nghiệp ngày xưa của bạn sẽ là những người sẵn sàng mang lại những cơ hội referral cho bạn, chỉ vì đơn giản vì “tôi muốn làm việc cùng với bạn”. Một tiêu chí đơn giản thôi, nhưng mà sẽ là hành trang đi cùng với bạn suốt cuộc đời.

Vậy nên, hãy luôn cố gắng, để trờ thành một người đồng nghiệp mà ai cũng muốn có.

Nếu bạn thích bài viết này, bạn có thể đọc thêm:

Vâng, tiếp tục là mình với câu chuyện podcast. Tập 2 của podcast cũng đã ra lò từ đầu tháng, và đến hôm nay mình mới có thời gian để viết một bài đi kèm với nó.

Các bạn có thể theo dõi tập mới nhất ở đây nhé.

Podcast của chúng mình sẽ có tên là Engineer Talks - Câu chuyện của kỹ sư, đàm đạo linh tinh về các chủ đề mà các bạn kỹ sư có thể quan tâm. Các tập sẽ được phát sóng vào ngày 1 và 15 hàng tháng!

Các kênh để bạn có thể theo dõi:

• Đương nhiên là mình sẽ update trên blog này rồi.

• Trang web chính của bọn mình: podcastcuakysu.com

• Youtube playlist với các tập mới nhất

• Podcast chính chạy trên Spotify

• Ngoài ra mình cũng sẽ update trên Thread nên có gì cứ follow mình

Cám ơn sự ủng hộ của mọi người!

35 - mốc khó khăn

Với chủ đề của tập podcast nhắc đến các khó khăn mà các bạn kỹ sư gặp vào độ tuổi 35, thì bài viết này cũng sẽ chia sẻ thêm về mốc thời gian khó khăn này. Mỗi lứa tuổi, mỗi ngành nghề đều có những sự khó khăn khác nhau, điều này thì là chắc chắn. Tuy nhiên, điều mình muốn nhắc đến ở đây là sự khó khăn lại mang một chút đặc thù, một chút của ngành nghề, và một chút là của thời đại.

35 tuổi, thường là tương ứng với khoảng 10 năm tham gia vào thị trường lao động. Với cuộc sống văn phòng ngồi cả chục tiếng một ngày, các thói quen ăn ngủ cày cuốc kéo dài từ thời học sinh sinh viên cho đến những năm đầu tiên của đi làm, các sức ép của công việc và cuộc sống; thì có thể hiểu được khi đến năm 35 tuổi này thì các bạn bắt đầu cảm thấy sự giảm sút của sức khoẻ. Chợt một ngày, tự nhiên bạn nhận thấy cơ thể của bạn không còn là cơ thể của những năm thanh niên nữa, một chút cổ vai gáy ở đây, một chút dạ dày ở kia, mỗi lần thiếu ngủ là cả một ngày lờ đờ. Tự dưng cảm thấy bản thân lại có chút mong manh yếu đuối nào đó.

Ngược lại với sức khoẻ đi xuống, lại là trách nhiệm của bản thân lại tăng lên. Đây là thời điểm mà nhiều người bắt đầu đi vào giai đoạn xây dựng gia đình của bản thân. Bạn có sức ép về tài chính, để nuôi nấng gia đình nhỏ của bạn; chi phí còn tăng cao hơn nhiều nữa nếu bạn đang chăm những thiên thần nhỏ của mình. Bạn muốn có một mái ấm cho chính mình, có chiếc xe để đưa đón người thân khỏi nắng mưa - đó có thể là khi bạn làm việc với ngân hàng để kiếm nguồn vốn cho những big purchases của bản thân, tương ứng với việc bạn thêm một gánh nặng tài chính trả nợ. Một sự hoang mang của lứa tuổi, khi tứ phương là sức ép. Đôi khi, bạn có sự chuẩn bị đầy đủ hơn, hoặc được sự hậu thuẫn tốt hơn các support system của mình, đó là một sự may mắn không hề nhỏ.

Về riêng ngành kỹ sư công nghệ, thì mình nghĩ giai đoạn 10 năm kinh nghiệm cũng là một cột mốc thay đổi. Bạn đã trải qua giai đoạn “thợ code”, làm việc theo task, được giao gì làm nấy rồi. Tuỳ theo thiên hướng của bản thân, thì khi đã qua 10 năm làm việc thì bạn sẽ thường phải phát triển được một chút thiên hướng leadership/management của bản thân: hoặc là technical leadership hoặc là project and/or people management. Nếu là technical leadership, bạn phải có sự am hiểu về hệ thống, về công nghệ, để có thể vạch ra kế hoạch hoặc thiết kế chỉn chu cho những hệ thống phức tạp. Project management sẽ là các khả năng quản lý dự án, nói chuyện và làm việc với stakeholders, bóc tách dự án thành các đầu mục nhỏ để hoàn thành cũng như kiểm soát rủi ro cho dự án. People management thì có thể đi với việc đào tạo, hướng dẫn và định hướng cho các bạn trẻ hơn, để các bạn có thể phát triển hơn. Đó là những thứ mà bạn nên có sau hơn 10 năm kinh nghiệm, và đó sẽ là những kỹ năng khả năng sẽ đem lại khác biệt giữa bạn và các bạn lớp trẻ. Khi các bạn trẻ có sức khoẻ và sự bền bỉ cho việc cày cuốc, thì yêu cầu cho một bạn 10 năm kinh nghiệm sẽ không còn là một thợ code nữa, mà phải đem lại những giá trị cao hơn cho doanh nghiệp. Các bạn trẻ theo ngành kỹ sư công nghệ, nếu nghĩ là mình chỉ cần làm việc với máy tính, không cần phải giao tiếp với người khác, không cần biết gì khác ngoài code, đó sẽ là những thứ khiến bạn dễ bị tụt lại hơn - và khoảng tuổi 35 này sẽ là khi sự tụt hậu đó trở thành vấn đề nghiêm trọng.

Một vấn đề khác của ngành công nghệ, nhưng lại thuộc về yếu tố thời thế, đặc biệt là trong những năm gần đây. Trong 10-15 năm gần đây, thì thực sự là ngành công nghệ trên thế giới có sự phát biển vượt bậc, với tiềm năng vượt trội - là điểm đến của các công việc sang xịn mịn với lương cao bổng hậu. Nếu bạn ở trong thị trường lao động trong những năm đó, thì bạn có thể cảm thấy một cuộc sống màu hồng, với các công việc thú vị, thu nhập hấp dẫn cũng như được sự quan tâm và chú ý của mọi người. Tuy nhiên, 2-3 năm gần lại đây thì cuộc sống màu hồng đó không còn được như trước nữa, khi các sức ép về thu hẹp tuyển dụng, nỗi lo sợ về AI, cũng như nguồn cung kỹ sư tăng vọt (do quá nhiều người nhảy vào ngành trong những năm gần đây). Khi bạn đã trải qua một giai đoạn màu hồng 10+ năm, thì bạn sẽ thấy những năm nay thực sự khó khăn - khi bạn bắt đầu sự nghiệp trong những năm tốt đẹp, thì sức ép từ cơn khủng hoảng sẽ có thể hơi shocking. Đó là yếu tố về mặt thị trường bên ngoài, mà bạn hoàn toàn không có khả năng kiểm soát, và chỉ khiến bạn thêm hoang mang.

Sống để hy vọng

Đó, nếu kể ra khó khăn của lứa tuổi, thì nghe như trời sắp sụp, thế giới sắp ngừng quay. Tuy nhiên, bạn cũng có thể có nhiều người trải qua lứa tuổi 35 này một cách yên ổn và bình an, thậm chí còn rất vui vẻ hạnh phúc. Nếu tính ra thì mình mới trải qua đi làm có hơn 10 năm thôi mà, ngày xưa bố mẹ chúng ta còn đi làm 40 năm trời mới nghỉ hưu, mà vẫn ổn đó.

Mình không có ý dismiss sự khó khăn của thế hệ mới, vì mình thấy là thế hệ mới có những vấn đề khó khăn hơn thật. Nhưng mà đó chỉ là một niềm cảm hứng, là đâu sẽ có đó, khó sẽ có đường ra, và có những sự kiên trì rồi sẽ được đền đáp.

Một thứ khó có thể bỏ qua được, thì đó là vấn đề là sức khoẻ. Như câu quote tiếng Anh: “A healthy man wants a thousand things, a sick man only wants one.” Bảo vệ sức khoẻ của bản thân, có thể là physical health hay là mental health, có lẽ vẫn nên là điều quan trọng nhất. Phải khoẻ mạnh tỉnh táo, thì mới có sức để vượt qua khó khăn. Mà cũng phải khoẻ mạnh tỉnh táo, thì bạn mới có thể enjoy được những vẻ đẹp của cuộc sống. (Nghe thì hơi giáo điều, kiểu gặp người ốm thì bảo là “khoẻ lên”, gặp người hay lo nghĩ thì “đừng lo nghĩ nữa” - mình thì chỉ có ý tốt thôi, nhưng làm thế nào thì đương nhiên mình không thể dễ dàng cho lời khuyên được).

Một thứ khác, để giúp bạn có thể bạn có thể bảo vệ bản thân, đó là xây dựng cho bản thân một hệ thống support system vững mạnh. Support system, đó là những cột trụ có thể hỗ trợ cho bạn, và nó có thể đến từ rất nhiều nguồn, và cũng phụ thuộc rất nhiều vào hoàn cảnh của bạn. Đó có thể là gia đình, bố mẹ anh chị em của bạn; cũng có thể là người thương hoặc gia đình nhỏ của bạn như vợ chồng con cái. Có thể là những người bạn thân luôn sát cánh bên bạn từ thời đi học, có thể là những đồng nghiệp thân thuộc, người sếp cũ mà bạn làm việc cùng rất hợp, thậm chí là hội đá bóng cùng khu chung cư… Sự trợ giúp đến từ nhiều nguồn, và cũng có thể đến dưới nhiều dạng: có thể là sự hỗ trợ về tài chính, sự giải phóng về thời gian, cơ hội về việc làm thăng tiến, hoặc có thể đơn giản là sự giải toả về tinh thần. Con người sinh hoạt không thể thiếu cộng đồng, và những giao tiếp xã hội luôn có thể mang lại tính win-win, khi mình sẵn sàng hỗ trợ và giúp đỡ người khác, người khác cũng sẽ vui vẻ hỗ trợ và chia sẻ với mình. Support system, nó là minh chứng của việc bạn không cô đơn, và bạn luôn có những người đứng bên cạnh mình.

Mình viết cái blog này, cũng mang tính chia sẻ với mọi người xung quanh. Mình luôn hy vọng những câu chữ của mình có thể tiếp thêm một chút sức mạnh cho mọi người, đi qua thêm một chút khó khăn mỗi ngày. Thế nên, hãy lạc quan và luôn sống có hy vọng nhé!

Tự nhiên dạo này thấy bản thân viết hơi nhiều về các thứ AI quá. Cũng một phần vì các thông tin mới nhất hay ho về ngành công nghệ dạo này bị chiếm hết bởi các thứ liên quan đến AI và LLMs, mình thấy nhiều dẫn đến đọc nhiều, đọc nhiều thì nghĩ nhiều rồi lại viết nhiều. Đấy, như các bạn marketer hay bảo, every impression counts…

Là một bước tiến khá quan trọng trong ngành công nghệ, tuy nhiên, điều mà khiến mấy tools AI chiếm đóng thế giới, vì nó đã đánh vào câu hỏi quan trọng nhất của thế giới tư bản này: Cái này hay quá, làm thế nào để mình kiếm tiền được với nó? Thô mà thật, nhưng mà vì câu hỏi này nên mới có nhiều sự quan tâm với công nghệ này đến thế.

Có những người bạn của mình cũng discuss với mình những chủ đề tương tự, những người mà đầu óc business-minded hơn là technical. Khi bạn nhìn nhận nó từ hướng technical, có thể bạn sẽ tỉ mỉ và khắt khe hơn: giả dụ như bạn có thể sẽ hiểu ML model luôn có thiên hướng là non-deterministic, nên sẽ luôn có những vấn đề lặt vặt, có những khe hở trong bài toán mà nó sẽ có thể không giải quyết tốt được. 1 dòng code nhỏ, nhưng nó là một phần của hệ thống logic mà có thể một ngày sẽ được chạy 1 triệu lần 1 ngày; nếu bạn là một coder chặt chẽ thì có thể bạn sẽ khó có thể happy với việc đoạn code của bạn chỉ có 90-95% chính xác.

Thế nhưng, từ phía business thì mọi người nhìn AI và LLMs lạc quan hơn rất nhiều. Ồ, cái này nó đã capable thế này rồi, nó có thể giải quyết được vấn đề ABCXYZ; mà nếu như thế thì rõ ràng là có khả năng kiếm được tiền từ nó. Giải quyết vấn đề mà, add value mà, thì sẽ phải có người sẵn sàng trả tiền cho nó chứ.

Từ những cái gì mình hiểu, mình sẽ cố giải thích góc nhìn của mình, về việc kiếm sống với cái bộ tool mới này.

Công ty TNHH một mình tao

Đầu tiên thì mình phải nhận là mình không hiểu quá rõ về các ngành khác, nên là mình sẽ không thể comment về các công ty thuộc các ngành đặc thù và sử dụng AI trong workflow của họ, để tăng cường hiệu quả và tính năng của nghiệp vụ. Cái này thì mình nghĩ là cần một người chuyên sâu hơn, có domain knowledge thì mới nói được sâu xa. Mình chỉ có thể comment về các sản phẩm tech-based, vì nó mới gần với những gì mình biết hơn.

Nhóm người đầu tiên cần nhắc đến, thì chắc là xu thế mới nhất hiện nay: đó là các solopreneur, là những business mà chỉ gồm có một người. Xuất phát từ xu hướng của vài năm trước là các indie devs và SaaS, khi chỉ cần 1 người dành thời gian và tự xây sản phẩm; mấy năm gần đây thì đã có nhiều người nhảy thêm vào mảng này, với sức mạnh của các AI coding tools. Có thể chia tạm ra thành hai nhóm nhỏ hơn:

• AI-enabled SaaS: vẫn là các bạn indie devs xây dựng SaaS, họ vẫn tiếp tục xây sản phẩm của bản thân, nhưng với sự hỗ trợ của các AI tools nên họ có thể tăng tốc hơn trong việc phát triển sản phẩm. Gốc rễ của sản phẩm có thể không cần phải liên quan đến AI, nhưng mà với sự đóng góp của AI mà họ có thể tiếp tục bổ sung thêm tính năng, mở rộng phát triển những mảng khác như marketing, sales. Ngoài ra, cũng có các bạn vốn chưa có technical background, nhưng mà với sự xuất hiện của các công nghệ hỗ trợ, cũng có thể tự xây dựng thành thành phẩm (vibe code their way to new product).

  • Các sản phẩm này luôn có chỗ đứng của nó, và mô hình SaaS rất thu hút với mọi người như là một dòng income stable → mọi người đều muốn một phần của miếng bánh này, như là tạo ra một nguồn thu nhập thụ động vững bền → sự cạnh tranh trong mảng này sẽ tăng lên rất nhiều.

  • Tuy nhiên, sự xuất hiện của AI khiến cho việc “bắt chước” một sản phẩm trở nên nhanh hơn rất là nhiều. Nếu sản phẩm của bạn chưa đủ phức tạp, thì bạn sẽ khó có thể bảo vệ sản phẩm của bạn khỏi cạnh tranh (defensibility). Không chỉ từ các đối thủ cạnh tranh, mà nếu bạn lấn quá nhiều vào tầm ngắm của một số công ty tech lớn hơn, họ có nhiều khả năng sẽ chọn cách copy bạn với lực lượng engineer hùng hậu thay vì mua lại bạn.

  • Điều quan trọng cho các business này, lại không còn là tech nữa, mà là vào khả năng distribute của họ (distribution network, có thể là marketing materials, industry contacts hoặc direct sales). Việc đầu tư vào distribution network trở nên quan trọng hơn nhiều.

  • Technical capability sẽ trở thành điểm mạnh ở giai đoạn scale-up: nếu bạn có đủ users, đủ volume, thì khi đó hiểu biết về tech để scale hệ thống/maintain được development capacity như là thêm feature mới, optimize code.. sẽ trở thành vô cùng quan trọng.

• New AI-use cases startups: Những ý tưởng mới xuất hiện nhờ có sự xuất hiện của AI, như là các tác vụ xử lý dữ liệu phức tạp (chuyển định dạng, thu thập tổng hợp và tóm tắt thông tin) hoặc interactive workflows (chatbot cho tư vấn, learning, customer service). Đây là những ý tưởng được nảy ra dựa trên sự xuất hiện của AI, chứ không phải là những thứ có sẵn.

  • Nếu những tác vụ này chỉ là một lớp wrapper nhỏ ngay trên LLMs, thì có nguy cơ là sẽ bị tích hợp thành một phần trong những tính năng mới của các LLM chatbots (ví dụ như khả năng phân tích bị chiếm bởi các tính năng research, hoặc là đọc văn bản/ảnh..)

  • Theo thiển ý của mình thì những tính năng này sẽ có người sử dụng nhưng mà sẽ khó mà trụ được lâu, trừ khi nó được tăng cường và bổ trợ bằng các tính năng khác, và lúc đó nó sẽ phát triển tương tự như các SaaS ở trên.

Một hướng về tools nữa mà mọi người cũng hướng đến nghiên cứu, đó là các workflow/automation tools như n8n, make.

• Một điểm đặc biệt của các workflow tool này đó là nó sẽ có sự thu hút với B2C users, những khách hàng cá nhân. Các workflow tool thường mang tính cá nhân cao và khó có thể xây dựng trong môi trường doanh nghiệp (ví dụ như bộ Tools của Atlassian gần như là ai cũng dùng nhưng mình chưa thấy có công ty nào thiết kế giống nhau). Để đạt được các tiêu chí bán cho corporate thì các tools này sẽ thiếu nhiều các tiêu chí như testing (làm sao mà có thể xây UAT với SIT cho các tools này), các corporate governance/compliance requirements như bảo toàn dữ liệu…

• Các tools này sẽ có chỗ đứng của nó, nhưng nó cũng sẽ tiếp cận được một tệp user nhất định. Nếu nó tiếp cận được nhiều người hơn, cũng sẽ cần hướng về phướng SaaS, hoặc nếu không sẽ bị một bên nào khác hơi technical hơn bắt chước theo ngay.

Với ý kiến của mình, các business nhỏ (hoặc rất nhỏ) như thế này thì sẽ cần cạnh tranh nhau nhiều hơn về distribution network của sản phẩm. Nhiều người nhảy hơn vào miếng bánh, nhưng sẽ khó nhằn hơn hoặc là sẽ có rất nhiều người được những miếng rất nhỏ.

Các công ty lớn

Để nói về các ông lớn trong ngành công nghệ, thì có thể bảo đảm luôn là tất cả đều đã có những động thái nhảy vào miếng bánh AI, nên có thể coi tất cả đều là AI-enabled business, không chừa một ai cả. Cái này thì gần như là chắc chắn luôn.

Hầu hết các công ty đi theo mô hình SaaS thì đều sẽ mang đến các tính năng AI vào sản phẩm chính của mình, và làm sao để các tính năng đó được tích hợp một cách hiệu quả vào sản phẩm đã có. Đó là ví dụ như các tool như Slack, Notion, Figma… và một tỷ các thứ khác, đều đã có những phần hỗ trợ bằng AI, tương ứng với các chức năng vốn có của hệ thống. Tuy nhiên, nếu để nói về việc “kiếm tiền”, thì thực ra cách họ kiếm tiền vẫn như thế, chứ không thay đổi bản chất về thứ mà họ bán cho người dùng. Vẫn là mô hình SaaS như cũ, với một chút AI magic đi kèm.

Để thực sự nói về cuộc chiến kiếm tiền từ AI, thì nên cần nhắc đến những công ty gần đây mới được phát triển nhờ phong trào này. Đó là OpenAI, là Anthropic, Perplexity, những công ty phát triển Foundational model, và là nguồn gốc LLMs để các hệ thống khác, các tool khác cắm vào và sử dụng. Business model của họ, đó là release ra những model mới mẻ xịn xò nhất, và sau đó charge các người dùng của họ theo sử dụng(subscription-based và per-usage billing).

Có 2 vấn đề với những business này:

• Việc cạnh tranh về Foundational model là không có hồi kết. Khi Meta đã quyết định open-source Llama và có quá nhiều big tech cùng nhảy vào cuộc đua về benchmark, thì cạnh tranh trong việc tạo ra Foundational model là quá lớn. Khi đạt đến gần giới hạn, đẩy sự chính xác của model lên 1 chút lại tốn kém hơn rất rất nhiều, mà sự chênh lệch giữa của model chuẩn xác 90% và 91% sẽ không giúp bạn vượt bậc hẳn, để có thể chiếm được hoàn toàn thị phần và trở thành monopoly.

• Kiếm tiền bằng subscription gần như là tiền lẻ (mặc dù nhiều tiền lẻ như thế thì mình cũng thích). Trích dẫn một bài báo gần đây1 , OpenAI có 2 triệu người dùng trả phí, tính thoải mái là 200$/người/năm, thì tổng doanh thu 1 năm của OpenAI chỉ bằng Revenue của các Big Tech kiếm được trong 1 tuần, đó là còn chưa kể là Operation margin của họ chưa chắc đã có lời.

Đương nhiên, áp lực về lâu về dài của các business đã được thổi lên một cách quá mức này, đó là phải tìm ra được một con đường về revenue mới. Gần đây thì có hai tít báo khá là thú vị: một là về Perplexity2 và sản phẩm mới, Browser Comet, muốn track từng đường đi nước bước của bạn; hai là OpenAI bổ sung thêm tính năng về Shopping3.

Từ đó, bạn lại quay lại và nhìn lại 2 tech behemoth lớn nhất và cách họ kiếm tiền, đó là Meta và Google và bán quảng cáo. Ước mơ và tương lai của việc kiếm tiền cho các big AI players, có vẻ đó chính là đi theo con đường của các ông lớn đã đi trước, đó là nhảy vào con đường Internet Advertisement, một miếng ngon béo bở với lợi nhuận ổn định và vẫn luôn luôn còn đang phát triển. Nghe có thể hơi buồn, nhưng có vẻ tương lai của big AI vẫn là đi bán quảng cáo.

Ngoài ra, thì các bạn cũng có thể nhận thấy có những players khác như Cursor, Lovable hay là các Productivity tools trong thời đại AI. Bây giờ vẫn còn quá sớm để nói gì, vì ngoài các công ty bán quảng cáo ra thì còn một Big Tech khác nữa, trùm cuối của productivity tool và là backbone cho hầu hết các business đang chạy hiện giờ, đó là Microsoft. Mình có thể tiếp tục quan tâm theo dõi, xem đó có phải là hướng mà họ sẽ đi theo hay không; họ có thể sẽ tham vọng tiếp tục phát triển, hay là sẽ bị nuốt trọn bởi các big tech khác.

Mình cũng chỉ ngồi dự đoán thôi, và cũng khá hóng xem tương lai sẽ ra sao.