Chuyện Nghề: Growth Pair Lead & iOS Lead, Loship — Lập trình là nghề nhiều áp lực, nhưng đừng vì khó khăn mà lỡ cơ hội

Chi tiết bài viết xem tại Blog Careerly!

Careerly ©: Lời đầu tiên, rất cảm ơn anh đã dành thời gian phỏng vấn cùng Careerly ngày hôm nay. Anh có thể giới thiệu qua về bản thân cho các độc giả của Careerly được biết không?

Trịnh Minh Quang (Q): Xin chào mọi người, anh là Trịnh Minh Quang. Hiện tại anh đang làm iOS Lead và Growth Pair Lead ở Loship. Anh có kinh nghiệm lập trình iOS 7 năm và đã gắn bó với Loship được 4 năm trong số đó.

C: Developer là một công việc khá đặc thù, anh nghĩ có một số kiểu tính cách nhất định nào sẽ phù hợp với công việc developer không?

Q: Thông thường cách giải quyết vấn đề sẽ quyết định xem ai đó có phải là người phù hợp với việc lập trình hay không. Nên anh nghĩ hai phẩm chất nên có ở một lập trình viên là tư duy logic và sự cởi mở để tiếp thu vấn đề.

Tư duy logic không chỉ giúp giải quyết các vấn đề về lập trình hiệu quả hơn, mà việc không để cảm xúc chi phối sẽ giúp họ đánh giá giải pháp của bản thân một cách khách quan, và sẵn sàng thừa nhận nếu có giải pháp khác tối ưu hơn.

Vì công nghệ thay đổi hằng ngày, phẩm chất này cũng sẽ giúp họ dễ đón nhận, tiếp thu kiến thức mới, một yếu tố ảnh hưởng trực tiếp tới tương lai và sự nghiệp của người lập trình viên.

C: Developer là một trong những nghề hot nhất hiện nay, thường xuyên được nhắc đến trên các mặt báo, trang mạng xã hội với mức lương đáng mơ ước. Trên thực tế, đằng sau vẻ ngoài hào nhoáng đó, developer có gặp nhiều khó khăn, thử thách trong công việc không? Cá nhân anh đã gặp những khó khăn gì? Làm thế nào để anh vượt qua những khó khăn đó?

Q: Anh không phủ nhận việc hiện nay developer là một trong những nghề hot với mức lương cao. Nhưng sau vẻ ngoài hào nhoáng đó thì developer cũng gặp những khó khăn riêng, tương tự những nghề khác. Đặc biệt là với mức lương càng cao thì thử thách và trách nhiệm càng lớn.

Nghề lập trình viên có một đặc điểm là “sóng sau xô sóng trước”. Thế hệ sau sẽ luôn giỏi hơn thế hệ trước, đặc biệt là khi mà các kênh thông tin các bạn trẻ có thể tận dụng để học hỏi kiến thức mới ngày càng nhiều. Có nhiều lần anh đã rất ấn tượng với những kiến thức mà thế hệ đi sau biết trong khi bằng tuổi họ thì anh không học nổi.

Đầu tiên thì điều này dẫn tới áp lực phải chạy đua để nâng cao kiến thức. Càng ngày kiến thức lập trình càng nhiều, cả chiều rộng lẫn chiều sâu. Khi ấy người lập trình viên phải đứng trước lựa chọn khi nào, cái nào cần mở rộng hoặc đào sâu. Do áp lực phải nắm bắt cái mới, dẫn đầu xu hướng về công nghệ, nên đôi khi người lập trình viên rơi vào trạng thái không biết mình có đang đi đúng hướng hay không.

Khó khăn về kiến thức chỉ là một phần thôi, thứ hai nữa là cách họ áp dụng kiến thức đó. Người lập trình viên đôi khi ở trong tình huống phải lựa chọn giữa việc viết những dòng code có thể không tối ưu nhất nhưng nó phù hợp với hoàn cảnh và tạo ra được giá trị nhanh nhất cho những người dùng ngoài kia sử dụng, và việc viết những dòng code chỉnh chu hơn, có thể dễ dàng đọc được và scale lên. Mỗi người một cách code, nếu biết được mình là kiểu nào thì có thể chọn ra môi trường phù hợp có thể gắn bó lâu dài để phát triển sâu hơn.

Cuối cùng là niềm đam mê. Anh thì thấm nhất phần này. Sau 5 năm thì một người làm nghề code sẽ biết họ có yêu thích công việc này hay không. Thường thì sau 5 năm họ sẽ bắt đầu chán chường và có thể nghĩ đến việc chuyển sang hướng khác. Hoặc là công việc vẫn xoay quanh công nghệ, tuy nhiên là không còn nặng về viết code, mà chuyển sang làm manager chẳng hạn. Nó cũng không phải là việc gì xấu cả, chỉ là sau 5 năm, mọi người sẽ phải tìm cách giữ lửa đam mê với nghề lập trình của mình.

Lý do để sau 5 năm vẫn code nhiều như hiện tại là vì anh vẫn thích code. Ngoài ra thì anh cũng tìm kiếm nhiều thử thách mới cho mình để giữ đam mê với công việc, ví dụ như lên lead team, hoặc tìm hiểu những project, product ở ngoài. Việc trở thành lead team sẽ giúp anh có cái nhìn rõ ràng hơn về những khuyết điểm trên code của mình khi review code của các thành viên, từ đó giúp anh suy nghĩ cách tối ưu hoá trên chính sản phẩm mình viết ra.

Cách thứ hai là anh nhìn vào những bạn trẻ trong team của anh. Anh nhìn thấy họ giỏi và anh cũng phải cố gắng cập nhật theo để không bị tụt lùi. Nói tóm lại là anh giữ lửa đam mê bằng cách dựa vào sự vận động, thay đổi của những gì đang xảy ra xung quanh, những gì mà dòng code của mình đang tác động để từ đó mình cũng thay đổi theo. Suy cho cùng, nếu bản thân không thể tìm được giá trị từ những dòng code mình viết ra nữa, thì đam mê cũng chẳng thể tồn tại.

C: Tại sao anh lại chọn mốc thời gian là 5 năm để đánh giá đam mê của người lập trình viên? Và anh có tiêu chuẩn đánh giá nào về đặc điểm của một project hay product khác được gọi là hay ho?

Q: Về mốc 5 năm thì thường mất khoảng 3 năm đầu để mọi người đạt được middle level và tới năm thứ 4 là ở mức cận senior. Từ khi sang năm thứ 5, trong 2 năm mọi người làm senior thì mọi thứ trở nên dễ dàng dần, và khi ấy mọi người bắt đầu phải suy nghĩ xem ngoài tạo giá trị cho công ty từ những dòng code và làm xong task ra thì họ có thể tạo được giá trị gì khác hay không. Có thể bắt đầu từ việc giúp đỡ developer khác trong công ty mình chẳng hạn.

Tuy nhiên, việc viết code và việc dạy code sẽ hơi khác nhau. Mình viết code thì mình hiểu nhưng việc mình truyền đạt lại cho người khác hiểu những năm kinh nghiệm đó là một thử thách rất khác. Nếu không thể làm tốt ở vị trí lead dẫn dắt team mà vẫn tiếp tục code đơn thuần thì sau 5 năm, họ không thấy thử thách nào mới và muốn chuyển sang làm những việc khác hơn là viết code.

Về những điểm để một project được gọi là hay ho thì với anh là một điều gì đó anh chưa làm, chưa học hoặc để lại ấn tượng mạnh, nó có thể là cái gì đó rất là đơn giản như chuyển cảnh giữa hai màn hình hoặc là làm filter cho video. Những điểm này có thể không có giá trị áp dụng trong công việc của anh nhưng nó có thể giúp anh học được những công nghệ mới.

C: Anh có thể chia sẻ một chút về một dự án khiến anh “mất ăn mất ngủ” nhất không? Bài học hoặc giá trị anh đã nhận được sau dự án đó là gì?

Q: Anh không biết là mọi người đã nghe về siêu thị LoX trên app Loship hay chưa. Đó là tính năng do pair của anh làm ra. Đây là một dự án khiến anh mất ăn mất ngủ, nhưng không phải mất ăn mất ngủ trong một thời gian dài, mà trong một khoảng thời gian rất ngắn, vì anh phải hoàn thành nó trong một tuần.

Anh định hình yêu cầu cho tính năng trong vòng 3 ngày và phát triển nó trong vòng một tuần. Khi ấy thời gian cũng không nhiều mà lực lượng lúc đó cũng không dày, bắt buộc anh phải lựa chọn những tính năng cần thiết nhất trong sản phẩm và chấp nhận lược bỏ các phần không quá quan trọng. Đây là một trong những dự án hiếm hoi anh phải học cách “buông bỏ”.

Điều thứ hai anh học được là về việc làm lead, anh phải biết cách cổ vũ tinh thần của mọi người. Dù lược bỏ cách mấy thì khoảng thời gian đó cũng rất stress không chỉ cho anh mà còn cho toàn bộ team. Nói một tuần nghe rất ngắn nhưng cũng đủ để có mỗi ngày một (vài) vấn đề. Anh cố gắng động viên anh em về giá trị vì nó là một trong những task mũi nhọn đối với sự phát triển của công ty này.

Nếu mà hỏi tại sao task mũi nhọn lại làm trong một tuần thì thật ra nó là kế hoạch trong tháng và cũng là tháng cuối năm, nếu mình làm lâu và sang tháng khác thì ảnh hưởng đến business chung của công ty. Anh động viên mọi người rằng Loship là một công ty công nghệ, trách nhiệm của team tech là sử dụng công nghệ để giải quyết vấn đề của công ty bao gồm cả vấn đề về mặt kinh doanh. Mình nhắc để mọi người thấy tự hào về giá trị mình làm ra.

Một bài học nữa là phải nắm bắt tình trạng của từng thành viên để giữ lửa cho anh em. Vấn đề không phải là thời gian ngắn hay thời gian dài, một tuần áp lực là đủ để làm xáo trộn rất nhiều mối quan hệ trong công việc, hoặc ngược lại mọi người có thể gắn kết hơn và tạo được nhiều giá trị cho công ty, điều này tùy thuộc vào người làm lead có đủ khéo léo hay không.

C: Anh có đề cập việc lược bỏ những tính năng không cần thiết để giữ lại những tính năng cần thiết nhất, khi đưa ra lựa chọn như vậy thì anh dựa vào những yếu tố gì?

Q: Anh dựa vào nhu cầu của người dùng. Nhu cầu người dùng thì cũng có nhu cầu cần (must-have) và nhu cầu đủ (nice-to-have), chẳng hạn như một số trải nghiệm thuận tay với người dùng. Tuy nhiên, chỉ nên giữ những nhu cầu cần, tập trung phát triển những tính năng giúp người dùng có thể hoàn thành thao tác mà họ muốn làm (ví dụ: mua hàng), và hoàn thành thao tác mà business muốn họ làm (ví dụ: thanh toán giao dịch). Còn những trải nghiệm cao cấp hơn thì có thể lược bỏ, chỉ nên giữ những tính năng đơn giản vừa đủ để trải nghiệm sản phẩm.

C: Tại sao từ khi mới bắt đầu tới tận bây giờ, anh lại lựa chọn gắn bó với lập trình cho iOS chứ không phải là Android?

Q: Hồi còn đi học thì anh học code cho Windows phone, nhưng khi ấy Windows phone chết dần thì anh phải lựa chọn iOS hoặc Android. Lúc ấy anh có đọc 1 bài trên The Verge phân tích là camera của dòng điện thoại Nokia Lumia có thể tùy chỉnh nhiều thông số, nhưng camera của iPhone thì gần như chỉ có 1 nút. Tức là họ sẽ không bắt người dùng phải tinh chỉnh, phải hiểu gì về camera mình đang dùng, chỉ cung cấp cho họ lựa chọn dễ nhất.

Từ đó anh bị ấn tượng bởi tư tưởng làm sản phẩm chuẩn chỉnh của Apple, bởi sự chu toàn, tinh gọn của họ trên iPhone, trên hệ điều hành của họ. Dù hồi đó anh nhớ là học code iOS khó hơn Android, anh lại có nền để code Android hơn, nhưng bản thân lại bị thuyết phục bởi cách làm sản phẩm của Apple nên anh đã quyết tâm theo iOS.

C:Anh có thể chia sẻ một ngày làm việc điển hình của anh thường diễn ra như thế nào không?

Q: Trước khi bắt đầu làm việc thì anh sẽ lập kế hoạch/thời gian biểu cho ngày. Nhưng khác với hồi anh chỉ làm developer anh có thể lập kế hoạch kín cả ngày, giờ anh sẽ phải lập các đầu việc thưa hơn vì làm lead anh phải giao tiếp với nhiều bên hơn nên thời gian cần linh hoạt. Ngoài ra anh cũng phải kiểm soát tiến độ ở trong 2 team anh quản lý xem các task có đang đi đúng hướng hay không và hỗ trợ nếu thành viên team có vấn đề gì.

Đến buổi chiều thì anh có thể dẫn các bạn trong team hoặc người team khác đi ăn để bonding. Đến tối thì anh mới code được. Vì hiện anh lead 2 team thì công việc lead cũng chiếm hết ngày rồi, cộng thêm thời gian giao tiếp với các stakeholders. Do đó tầm 5 rưỡi — 6h tới tối khuya thì anh mới như một người lập trình viên, ngồi code một mình mà không bị ai làm phiền.

C: Cùng một lúc phải lead hai mảng là lập trình cho iOS và Growth, anh có gặp khó khăn gì không? Anh đã vượt qua những khó khăn ấy như thế nào? Trong hai mảng này, cá nhân anh thích mảng nào hơn? Tại sao?

Q: Khó khăn đầu tiên là anh phải dẫn dắt các bạn. Thực ra lúc đầu thì anh chưa giỏi lãnh đạo, nhưng cũng may là các bạn hồi đó cũng chịu đi theo anh lâu dài. Sau thì anh biết cách để dẫn dắt team hơn, còn về phần chuyên môn vì anh đã có base là một lập trình viên iOS rồi nên cũng dễ dàng.

Sau khi làm leader một thời gian, CTO bên mình lập ra hệ thống mới là cấu trúc Pair bên cạnh cấu trúc theo stack. Nhìn chung Pair là một team tech nhỏ gồm đủ các thành viên từ các stack khác nhau với mục tiêu tạo ra các tính năng cho sản phẩm, chứ không phải chỉ tập trung vào kỹ thuật (Careerly: để hiểu chi tiết về mô hình này, độc giả có thể xem lại bài phỏng vấn với anh Nguyễn Ngọc Thịnh — CTO Loship). Cấu trúc này giúp cho team có thể đi nhanh và xa hơn, giúp team tập trung vào sản phẩm hơn kỹ thuật.

Khi mới lead Pair Growth thì anh cũng gặp nhiều khó khăn trong việc định hướng các bạn theo mục tiêu của product, của business. Thông thường trong 1 stack kĩ thuật, các thành viên sẽ hiểu rõ kĩ thuật mà các bạn đang làm là gì, và điều đó sẽ giúp các bạn dễ giao tiếp hơn. Trái lại, ở trong 1 pair thì người lead phải tìm cách gắn kết các bạn bằng các giá trị đi cùng với sản phẩm hơn là chỉ kĩ thuật. Pair Growth là một mảng rất quan trọng của công ty nên Pair Growth gặp khá nhiều áp lực.

Theo anh (dù hơi cực đoan 1 chút), nếu công ty mà không tăng trưởng được, thì dù trị giá ngàn tỷ cũng không có ý nghĩa gì. Do vậy, với anh thì các bạn làm việc trong Pair Growth có thể tự hào vì giá trị team đang tạo ra cho công ty. Anh cũng dùng sự tự hào đó để giúp cho các bạn đoàn kết lại và làm việc chung với anh hiệu quả hơn. Đặc biệt là với Pair Growth thì các bạn phải vừa đi nhanh vừa hiểu hệ thống ở mức sâu nhất có thể để có thể tìm ra giải pháp nhanh cho công ty.

Ngoài ra thì việc trở thành lead của 2 team cũng gặp nhiều khó khăn khi mà anh phải làm cả công việc lập trình. Như anh nói ở trên, thời gian làm việc 8 tiếng bình thường của anh chỉ dành để lead 2 team và giao tiếp với các team khác, và anh chỉ có thể code từ lúc 6 giờ tối đến 9 giờ tối. Khác với một developer thông thường, đơn vị ngày của anh chỉ bao gồm 3 tiếng ít ỏi để thực hiện đúng công việc lập trình.

Thông thường có 2 lựa chọn: ngưng việc lead, quay trở về với việc code thuần tuý hoặc xin thêm thời gian về đơn vị giờ (làm theo số giờ, không tính theo ngày, ví dụ 8 tiếng là 2 ngày rưỡi). Tuy nhiên anh đã chọn cách thứ ba, đó là thay đổi cách code, cả về kỹ năng lẫn mindset, để có thể tăng tốc độ code, tận dụng thời gian và làm việc năng suất hơn.

Ví dụ: Anh có 5 phút để nhìn thấy cái sai trong code của mình, không tự ái, anh có 10 phút để tìm phương án đúng, và anh có 30 giây để chuẩn bị tinh thần đập bỏ những sai sót trong code dù tốn công. Và khi đã quyết định làm rồi, thì không được phép có suy nghĩ sợ mệt và nặng, điều này chỉ làm đánh mất cơ hội phát triển bản thân thôi. Và như vậy, tốc độ lập trình của anh vẫn đảm bảo được lợi ích của người dùng và công ty.

C: Anh có thể chia sẻ thêm về quy trình phát triển sản phẩm, công nghệ tại Loship hay không? Một điểm về quy trình này mà anh thấy hay?

Q: Một điểm về quy trình phát triển sản phẩm ở Loship đó là thời gian phát triển tính năng rất nhanh. Về quy trình thì bên mình sắp xếp vào các sprint. Và điều đặc biệt là sprint ở Loship chỉ kéo dài 1 tuần, trái với các công ty khác sẽ kéo dài 2 tuần, vì Loship coi tốc độ là một giá trị cốt lõi của công ty.

Sprint 1 tuần cho phép chúng ta thay đổi, ứng biến nhanh với tính năng trong khi sprint 2 tuần sẽ hạn chế business can thiệp vào giữa sprint đó. Sau 1 tuần, nếu bên business muốn thêm bớt can thiệp gì vào thì team mình rất thoải mái theo. Loship thường report và họp theo tuần, sau mỗi lần như thế thì có thể phát sinh thêm những nhu cầu mới. Sprint 1 tuần sẽ cho phép team thay đổi để đáp ứng nhu cầu đó. Là một công ty công nghệ thì team tech phải bám sát business.

Đương nhiên với những tính năng lớn, yêu cầu 3 tuần, thì bên anh sẽ chia task ra 3 tuần. Nhưng với mỗi tính năng team đều sẽ đặt câu hỏi liệu làm trong 1 tuần có khả thi không, và cố gắng đạt mục tiêu hoàn thành trong 1 tuần nếu có thể. Trong trường hợp không khả thi thì cũng cần đẩy tốc độ của nó lên nhanh nhất có thể.

C: Hiện tại, ngoài công việc tại Loship thì anh có hay cập nhật thêm kiến thức hoặc tin tức để bổ trợ cho công việc hay không? Anh có thể đề xuất một số nguồn anh cảm thấy tâm đắc được không?

Q: Chuyên về kỹ thuật thì anh thường lên đọc bài trên Medium, xem video demo trên Youtube. Còn về văn hóa công ty hay trải nghiệm công việc thì anh hay đọc blog công ty, và anh có đọc Careerly. Anh hay đọc về Product Management trên Careerly vì nó phù hợp với định hướng của anh và nội dung cũng khá ổn. Về Growth thì anh cũng có follow vài người để đọc, cập nhật và hiểu thêm về mảng này.

C: Anh cảm thấy công việc developer (lập trình) đã đem lại giá trị gì cho mình?

Với công việc developer, những giá trị anh tạo ra có thể nhìn thấy được rất rõ ràng. Ở Loship, anh có thể code ra thứ gì đó giúp ích cho những người ngoài kia. Mỗi ngày, anh biết được có ai đó đang sử dụng sản phẩm mình làm ra, họ sử dụng như thế nào, họ còn gặp vấn đề nào. Điều quan trọng hơn việc biết vấn đề của người dùng đó là việc anh có thể tự mình giải quyết những vấn đề đó cho họ. Nhìn chung công việc developer đã cho anh cảm thấy những dòng code của anh có thể mang lại ý nghĩa, tạo ra giá trị cho xã hội.

C: Lời cuối cùng anh muốn nhắn nhủ đến độc giả của Careerly, những bạn trẻ đầy nhiệt huyết đang muốn dấn thân vào nghề Developer?

Q: Đầu tiên thì các bạn cần thích code trước, đừng chỉ nghĩ mình thích chơi game thì sẽ code giỏi.

Thứ hai là hãy khoan nghĩ đến chuyện tiền bạc, mà hãy nghĩ dòng code của mình có thể mang lại giá trị gì cho xã hội, thì đồng tiền sẽ đi theo thôi.

Thứ ba là đừng sợ sai, đừng sợ chuyện code sai. Cho đến hiện tại thì anh đã code rất nhanh và chỉn chu, nhưng đâu đó thì 90% những dòng code anh viết ra đều học từ bug, từ những cái sai của anh. Điều quan trọng không phải là bạn sai hay đúng, mà quan trọng là thái độ của bạn với lỗi sai của mình, có sai thì phải tìm hiểu tại sao mình sai để nhớ lỗi sai, học cách sửa và không lặp lại lỗi sai của mình.

Hãy sửa lỗi sai của mình nhanh nhất có thể, đừng tốn thời gian đổ lỗi cho người dạy hay stackoverflow. Hãy nhớ rằng, dù ai hay ngôi trường nào dạy bạn bất cứ dòng code nào, thì cũng chính bạn đã đọc, chọn, và gõ ra nó. Hãy học cách chịu trách nhiệm, và đối mặt trực tiếp với vấn đề, đó là cách giúp bạn trưởng thành tốt nhất.

Thứ tư, là đừng nhìn khó khăn như một thước đo để chạy trốn cơ hội đang có, rời bỏ môi trường nào đó vì khó khăn. Hãy dũng cảm đối mặt với những khó khăn, xem nó như một cơ hội để phát triển bản thân, trưởng thành trong môi trường đó. Những thành công mà bạn thường thấy từ những người thầy, những người giỏi, anh nghĩ đa phần là họ chịu chấp nhận những cơ hội lẫn khó khăn họ đang có, can đảm đón nhận cả hai và tin rằng bản thân có thể phát triển được.

Điều cuối cùng anh thấm được từ một người thầy hồi đại học của anh đó là phải đọc sách nhiều lên. Anh không chỉ nói về sách code không đâu. Nếu stress thì các bạn có thể đọc 1 cuốn nào đó để giải stress, hoặc đang thiếu kiến thức thì bạn có thể đọc thêm về các lĩnh vực khác để bổ sung kiến thức. Nó cũng có thể là tài liệu trên mạng, đọc sách điện tử cũng được, blog cũng được, Medium hay Careerly cũng được. Nhưng hãy đọc nhiều lên, vì đọc sách là một cách để mình mở rộng tầm nhìn, nhận thức được những gì mình đang biết vẫn còn hạn chế và tiếp tục học hỏi.

💥Theo dõi Loship để cập nhật thông tin mới nhất:

• Fanpage: fb.com/lozi.team
• Linkedin: linkedin.com/lozi
• Twitter: twitter.com/LoshipVN
• Instagram: instagram.com/loshipvn/
• Spotify: open.spotfify.com/lifeatloship