Chào các bạn,

Tôi là Benoit - một kỹ sư phần mềm phần mềm với hơn 8 năm kinh nghiệm. Tôi làm việc tại công ty cũ (và công ty đầu tiên) của mình trong bảy năm rưỡi, sau đó tôi gia nhập công ty mới vào đầu năm 2022.

Bài viết này xuất phát từ sự tự suy ngẫm gần đây về những điều tôi ước mình đã bắt đầu làm sớm hơn trong sự nghiệp của mình và những điều tôi ước mình đã làm khác đi.

Những gì tôi đang chia sẻ ở đây có thể hữu ích cho bất kỳ lập trình viên mới bước chân vào nghề hoặc các bạn senior nào muốn cải thiện và thăng tiến sự nghiệp ở level cao hơn.

I. Những điều tôi ước mình đã bắt đầu làm sớm hơn

1. Viết nhật ký công việc

Nhật ký công việc là một tài liệu chứa danh sách các nhiệm vụ bạn đã hoàn thành. Mức độ chi tiết và loại nhiệm vụ không quan trọng, miễn là bạn theo dõi được những gì mình đã làm.

Bạn có thể ghi lại thông tin với tần suất bạn muốn. Tôi khuyên bạn nên làm điều đó hàng tuần. Các nhiệm vụ được thực hiện trong tuần vẫn còn mới, vì vậy bạn sẽ không gặp khó khăn khi viết chúng ra.

Tại sao chúng ta cần viết nhật ký công việc? Vì hai lý do sau:

• Để nhắc nhở bản thân về tất cả những việc bạn đã làm trong 6 đến 12 tháng qua. Điều này rất có giá trị trong quá trình đánh giá hiệu suất, vì vậy bạn có thể cho người quản lý của mình thấy những gì bạn đã đạt được và lý do tại sao bạn xứng đáng được tăng lương hoặc thăng chức.

• Để theo dõi các dự án, trách nhiệm đáng chú ý và các con số quan trọng (ví dụ: giảm độ trễ X% cho một dịch vụ quan trọng) mà bạn đã trải qua trong sự nghiệp của mình. Điều này rất tốt cho việc hoàn thiện portfolio của bạn bất cứ khi nào bạn muốn tìm kiếm cơ hội việc làm mới.

Khi phải viết portfolio để chuyển việc vào cuối năm 2021, tôi phải dựa vào trí nhớ của mình để nhớ lại những gì mình đã làm trong suốt 5 năm đầu lập nghiệp.  Thành thật mà nói, tôi phải mất một thời gian để nhớ lại những thứ có giá trị và tôi chắc chắn rằng mình đã quên khá nhiều điều quan trọng trong số đó.

Bạn có thể sử dụng mẫu nhật ký công việc nếu muốn (đây là một ví dụ). Cá nhân tôi thường sử dụng Microsoft Notes và Google Doc.

2. Rời khỏi vùng an toàn

Đây là cách tốt nhất để học hỏi và trở thành một lập trình viên giỏi hơn. Vùng an toàn là phạm vi, môi trường mà bạn cảm thấy thoải mái khi thực hiện công việc của mình. Đó là những người đồng đội mà bạn đã biết và làm việc cùng hàng ngày, những dự án bạn đã thực hiện trong nhiều năm, những trách nhiệm mà bạn đang gánh vác, v.v.

Nhưng tại sao lại có người khuyên bạn nên rời bỏ hoàn cảnh tuyệt vời này? Bởi vì môi trường này không thích hợp cho sự phát triển.

Chắc chắn, nếu bạn ở trong bong bóng này, bạn là người làm việc hiệu quả. Bạn đã biết nên nói chuyện với ai về một chủ đề cụ thể và tệp nào trong codebase phải được thay đổi. 

Lúc này, bạn nên tìm kiếm:

• Hướng dẫn đồng nghiệp/người mới để họ trở nên quen thuộc với công việc.

• Tìm điều gì đó mới để làm ngoài vùng an toàn của bạn.

Mentor là một trong những trách nhiệm được mong đợi từ một vị trí cấp cao. Đó là một cách tuyệt vời để giúp đồng nghiệp của chúng ta làm việc hiệu quả hơn một cách nhanh chóng. 

Đối với những tác vụ hằng ngày, IT nên làm gì để tránh rơi vào tình trạng chán nản? Dưới đây là danh sách công việc mà bạn có thể tham khảo để gia tăng nguồn cảm hứng:

• Viết tài liệu về một chủ đề mà bạn cảm thấy thoải mái. Mục tiêu là chia sẻ kiến ​​thức của bạn và gián tiếp hướng dẫn mọi người để họ có thể tiếp thu kiến ​​thức này nhanh hơn bạn. Ngoài ra, viết là một kỹ năng tuyệt vời để học hỏi và cải thiện, có thể là tài liệu, email, tin nhắn tức thời, RFC (Request for Comments - Yêu cầu nhận xét), bài đăng trên blog, v.v.

• Tình nguyện tham gia vào các dự án liên nhóm. Bạn thậm chí có thể đảm nhận vị trí leader trong các dự án này để nâng cao kinh nghiệm cho bản thân.

• Quan tâm hơn đến việc cải tiến các quy trình về công cụ, giám sát hoặc nhóm/tổ chức.

• Ghi danh vào các cộng đồng/hội nhóm tại công ty để làm việc trong các dự án cấp tổ chức, liên nhóm.

•  Tham gia quy trình tuyển dụng: dành thời gian thực hiện các cuộc phỏng vấn kỹ thuật trong team.

3. Tò mò về các nhóm và dự án khác

Trong một thời gian dài, tôi không quan tâm đến các nhóm và dự án nằm ngoài phạm vi nhóm của tôi. Sản phẩm của chúng tôi có một số phụ thuộc vào các dịch vụ do các nhóm khác sở hữu, nhưng miễn là giao diện API giữa họ và chúng tôi được xác định rõ ràng, chúng tôi không cần phải biết gì về các dịch vụ của họ.

Thời điểm duy nhất mà chúng tôi phải tìm hiểu và xem cách thức hoạt động là khi chúng tôi phải đóng góp vào các dự án nọ. Vì chúng tôi được tổ chức thành các nhóm tính năng, nếu chúng tôi cần thay đổi một số điều trong một số những dự án khác của công ty, chúng tôi phải tự thực hiện những thay đổi đó. Mỗi nhóm tính năng có một kế hoạch làm việc riêng, vì vậy chúng tôi không thể yêu cầu một nhóm khác làm công việc đó cho chúng tôi. Mặc dù ban đầu chúng tôi chậm chạp, nhưng với sự giúp đỡ của nhóm khác, chúng tôi dần trở nên hiệu quả hơn khi đóng góp vào các dự án của họ.

Nhưng, đối với các dịch vụ khác mà chúng tôi không tương tác trực tiếp, tôi không biết chúng hoạt động như thế nào và vai trò cụ thể của chúng trong hệ thống là gì. Chỉ khi tôi gia nhập nhóm on-call, nhiều năm sau đó, tôi mới thực sự bắt đầu nhìn vào tất cả các dịch vụ của công ty. Khi cuối cùng tôi hiểu được toàn bộ bức tranh toàn cảnh, cảm giác thật tuyệt vời.

• Tôi hiểu rõ hơn nguyên nhân khi có sự cố xảy ra.

• Tôi biết tại sao chúng ta cần dịch vụ cụ thể đó hoặc tại sao chúng ta đã chọn lựa cơ sở dữ liệu đó.

• Cuối cùng, ghép tất cả mọi thứ lại với nhau, sau nhiều năm đóng góp giá trị cho công ty, mang lại cho tôi một cảm giác rất tuyệt vời kiểu "Ôi, bây giờ tôi hiểu rồi."

Vì vậy nếu có thể, hãy nhìn vào các dự án và nhóm khác trong công ty của bạn. Đọc các trang wiki nội bộ, tham dự các buổi demo và đọc tài liệu công khai của họ. Đây là điều bạn có thể làm thường xuyên, không cần phải bỏ ra quá nhiều nổ lực. Thêm vào đó, nếu bạn có thể vẽ biểu đồ và viết một số tài liệu tham khảo về "toàn bộ dịch vụ trong công ty", hãy làm điều đó. Có khả năng rất nhiều người trong tổ chức sẽ cảm ơn bạn vì điều đó!

Lưu ý rằng bạn không cần phải tạo ra bất cứ sản phẩm hay tài liệu nào ở đây. Tất cả những gì bạn cần là sự tò mò, đọc tài liệu từ các nhóm khác và đặt câu hỏi. Trong quá trình đó, bạn có thể gặp gỡ những người từ các nhóm khác, và bạn có thể khám phá những dự án mà bạn thực sự muốn làm việc.

4. Tham gia on-call team

Điều này có thể gây tranh cãi và có thể một số công ty sẽ không có đội ngũ này. Tất nhiên, bạn nên xem xét lời khuyên này nếu công ty của bạn có môi trường làm việc lành mạnh.

On-call team được tạo thành từ những người sẵn lòng can thiệp nếu có vấn đề xảy ra trong và ngoài giờ làm việc, tức là vào ban đêm, cuối tuần và các ngày lễ. Công ty của bạn có thể có một đội SRE (Site Reliability Engineers - Kỹ sư quản lý độ tin cậy) chuyên trách và/hoặc nhóm của bạn có thể không phải làm việc DevOps.

Nhưng, nếu bạn có cơ hội tham gia vào đội ngũ này, dù đó là cho sản phẩm bạn đang làm việc, hoặc cho cả công ty (phụ thuộc vào quy mô), tôi khuyên bạn nên thử.

Dưới đây là một số lợi ích của việc tham gia nhóm này:

• Bạn học được nhiều về "góc khuất phía sau hậu trường" của các sản phẩm và dịch vụ giúp công ty phát triển mạnh mẽ.

• Bạn cảm thấy có sự đồng cảm hơn với đồng nghiệp của bạn, khi bạn trải nghiệm trách nhiệm nặng nề mỗi khi có điều xấu xảy ra, đặc biệt là vào ban đêm.

• Bạn cảm thấy có động lực hơn với công ty, khi bạn đầu tư thêm thời gian của mình để đảm bảo rằng các sản phẩm và dịch vụ hoạt động như mong đợi cho khách hàng.

Một lần nữa, cần phải có một môi trường trực lành mạnh trước khi đảm nhận những trách nhiệm này.

Ở công ty đầu tiên, tôi tham gia vào on-call team (đảm nhiệm tất cả các dịch vụ) khoảng hai tháng trước khi ra đi. Tôi ước rằng mình đã tham gia sớm hơn, vì tôi học được rất nhiều trong những tháng cuối cùng này, và trách nhiệm bổ sung này đã được đền đáp xứng đáng.

5. Luân chuyển nhóm làm việc

Nếu bạn từng rơi vào một trong những trường hợp sau đây:

• Quá thoải mái với vị trí hiện tại và muốn bước ra khỏi vùng an toàn của mình.

• Không thực sự thích các dự án/phạm vi của nhóm và bạn muốn làm việc trên những dự án mà bạn yêu thích hơn.

• Mối quan hệ với đồng nghiệp và/hoặc người quản lý của bạn đã xấu đi và bạn muốn có một chút không khí mới mẻ trong khi vẫn là một phần của công ty.

Thì tôi khuyến khích bạn nên cân nhắc tìm một đội mới thay vì từ chức và tìm kiếm một công ty mới.

Thay đổi sang một công ty mới rất mệt mỏi và bạn có thể mất đi những thứ mà bạn thực sự đánh giá cao, chẳng hạn như đồng nghiệp, văn hóa làm việc hoặc phúc lợi của nhân viên.

Tôi nghĩ việc nhảy nhóm là điều tuyệt vời vì:

• Cách tổ chức của nhóm mới có thể khác nhau (cách làm việc cùng nhau), do đó bạn sẽ có thêm kinh nghiệm trong lĩnh vực này.

• Bạn có thể mang lại những thay đổi tích cực mà bạn đã học được từ nhóm trước (cải thiện quy trình review code, công cụ, thư viện và phương pháp làm việc)

• Bạn có thể giúp đỡ các đồng đội mới của mình khi họ phải làm việc trong các dự án thuộc sở hữu của nhóm trước đó của bạn (tức là chia sẻ kiến ​​thức một cách hiệu quả từ nhóm này sang nhóm khác).

• Bạn có thể học các công cụ, ngôn ngữ, thư viện, kiến ​​trúc mới và cách giải quyết vấn đề. Nói cách khác, trở thành một lập trình viên giỏi hơn.

Một năm trước khi rời công ty đầu tiên, tôi quyết định chuyển sang một nhóm khác. Một số đội đã đề nghị tôi tham gia cùng họ và nếu tôi có thể phân thân, tôi sẽ vui lòng tham gia tất cả.

Khi gia nhập đội ngũ mới, tôi cảm thấy vị trí trưởng nhóm của mình không còn phù hợp nữa. Tôi phải học các cơ sở mã, công cụ và phương pháp thực hành mới. Chắc chắn, tôi vẫn giữ được các kỹ năng mềm và kiến ​​thức về doanh nghiệp/sản phẩm, nhưng kỹ năng kỹ thuật của tôi đã bị giảm đi. Tất nhiên, học được điều gì đó mới là điều tuyệt vời, nhưng tôi không còn là người cố vấn kỹ thuật của nhóm nữa. Tuy nhiên, mỗi khi nhóm phải đóng góp vào các dự án của nhóm trước đó của tôi, tôi có thể giúp họ một cách hiệu quả hơn. Theo thời gian, cảm giác “không xứng đáng với danh hiệu của mình” mờ dần và tôi thậm chí còn trở nên giỏi hơn khi tích lũy được nhiều kỹ năng.

Nói như vậy, nhưng tôi nghĩ việc thay đổi nhóm không nên diễn ra quá thường xuyên. Nếu bạn cảm thấy hoàn cảnh của mình phù hợp với một trong ba lý do đã kể trên, tôi khuyên bạn nên cân nhắc thay đổi, nhưng chỉ khi bạn làm việc ở nhóm hiện tại của mình ít nhất một năm. Tôi nghĩ một năm là khoảng thời gian hợp lý để cảm nhận xem bạn có thuộc về đội ngũ hiện tại của mình hay không. Nếu bạn không thể đợi cả năm, điều đó có nghĩa là tình hình khá nghiêm trọng và tôi khuyên bạn liên hệ người quản lý của bạn và/hoặc cấp trên hơn để giải quyết vấn đề.

6. Viết blog

Viết là một trong những kỹ năng quan trọng nhất mà một lập trình viên nên có. Rất nhiều công việc hàng ngày của chúng ta liên quan đến việc viết: code, tin nhắn, email, tài liệu, RFC, ghi chú cuộc họp, . . .

Viết là một trong những cách giao tiếp gián tiếp tốt nhất với mọi người. Họ có thể đọc tin nhắn của bạn bất cứ khi nào họ thấy phù hợp và không bị gián đoạn giữa nhiệm vụ và có thể tập trung vào đó. Tất nhiên, trong một số trường hợp, giao tiếp trực tiếp là cách giao tiếp tốt hơn, tức là gọi điện video, gặp mặt trực tiếp, v.v., để giải quyết một số trường hợp khẩn cấp hoặc loại bỏ sự mơ hồ và hiểu sai. Nhưng theo kinh nghiệm của tôi, các lập trình viên tiếp xúc với việc viết nhiều hơn là nói chuyện hàng ngày.

Việc viết blog mang lại cho bạn rất nhiều lợi ích và trải nghiệm thú vị:

• Nếu bạn chưa có kinh nào trong việc viết lách thì đừng sợ, cách duy nhất để cải thiện một kỹ năng là thực hành. Nếu bạn không chắc chắn mình đang làm đúng, bạn có thể nhờ sự giúp đỡ từ một người làm tốt việc đó theo quan điểm của bạn, để họ có thể tư vấn cho bạn về chủ đề này. Bạn cũng có thể đọc tài liệu và bài đăng trên blog về nó. Như đã nói, điều quan trọng nhất là hãy bắt đầu luyện tập, ngay cả khi những bài viết đầu tiên của bạn có một số sai sót.

• Buộc bạn phải biết chủ đề bạn đang nói đến. Đây là một cách tuyệt vời để thực sự học hỏi mọi thứ - bằng cách đào sâu hơn bình thường vào một chủ đề cụ thể.

• Phát triển thương hiệu cá nhân của bạn. Càng nhiều người quan tâm đến bài đăng trên blog của bạn, bạn càng có nhiều người theo dõi và bạn càng trở nên có ảnh hưởng hơn.

Bạn có thể viết bài trên blog cá nhân của mình và/hoặc trên blog của công ty bạn (nếu có). Bắt đầu bằng việc viết bài cho công ty của bạn là điều tuyệt vời vì nó đã có sẵn một lượng độc giả và người theo dõi. Tuy nhiên, bạn có ít quyền tự do hơn về chủ đề bạn muốn nói vì đó là lựa chọn của công ty.

Đừng mong đợi trở nên nổi tiếng sau bài đăng đầu tiên. Phải mất một thời gian dài để trở nên có ảnh hưởng. Bạn thậm chí có thể không bao giờ đạt được sự nổi tiếng như bạn mong đợi, và điều đó không sao cả. Bạn nên viết cho BẠN, để cải thiện kỹ năng viết của mình và chia sẻ những khám phá của bạn với cộng đồng. Bạn không nên quan tâm đến việc bạn nhận được bao nhiêu lượt thích hoặc theo dõi. Đúng, việc được công nhận như vậy là một động lực lớn về mặt tinh thần, nhưng mục tiêu của bạn không phải là tăng những con số này. Mục tiêu của bạn phải luôn là cải thiện khả năng viết và chia sẻ kiến ​​​​thức.

Tôi bắt đầu hành trình này bằng cách đăng tải bài viết đầu tiên của mình trên blog của công ty đầu tiên của mình. Bài viết thậm chí còn được đề cập trong bản tin JavaScript Weekly (một newsletter khá phổ biến, nơi chia sẻ các tin tức mới nhất, các bài viết, các công cụ và tài nguyên liên quan đến JavaScript.) và điều đó khiến tôi cảm thấy vô cùng tuyệt vời và tự hào.

Sau đó, vào tháng 3 năm 2021, tôi bắt đầu viết và đăng bài trên Dev.to và thỉnh thoảng tôi vẫn hay làm công việc này.

Lời kết

Như vậy, đó là những lời khuyên mà tôi ước mình biết từ khi bắt đầu hành trình của mình trong lĩnh vực Công nghệ Thông tin. Đôi khi, những điều nhỏ nhặt có thể làm nên sự khác biệt lớn lao trong sự nghiệp của chúng ta. Nhưng cuộc hành trình của mỗi người không chỉ dừng lại ở đó. Hãy cùng chờ đợi phần 2 của bài viết, khi tôi sẽ chia sẻ với bạn những kinh nghiệm thú vị và những quyết định mà tôi ước mình đã thực hiện khác đi.

>> Xem thêm: 9 lời khuyên đắt giá mà lập trình viên nên biết nếu muốn nhanh thăng tiến trong sự nghiệp (Phần 2)

VietnamWorks inTECH