Chào anh Steve, người anh Tech Lead hãy giới thiệu đôi chút về bản thân hoặc sở thích đến bạn đọc nhé.
Chào mọi người, anh là Steve, anh từng là một RoR engineer, và hiện tại đang nắm vai trò Tech Lead của Money Forward Vietnam.
Sở thích của anh thì cũng như bao người, nhưng du lịch và chụp hình là hai điều đầu tiên anh luôn nhắc đến. Hai sở thích này bổ trợ cho nhau trên mỗi chặng đường anh đi, hy vọng mùa dịch này mau hạ nhiệt sớm.
Với cũng như các anh dev khác, anh cũng có những sở thích liên quan đến lĩnh vực của mình. Anh hay dạo quanh các video review đồ công nghệ, bên cạnh đó cũng ghé các trang nguồn như medium, quora, reddit, dev.to nữa, tại đó kiến thức khá đa dạng và thú vị, có thể học hỏi nhiều lắm.
Được biết trước khi vô MFV, anh Steve từng có kinh nghiệm làm việc ở công ty outsource. Vậy có gì khác biệt giữa công ty outsource và công ty product?
Khác chứ, nhất là ở sự góp sức của mình. Ở công ty outsource, hầu hết các dev sẽ tham gia vào quá trình phát triển sản phẩm, hay có thể nói là thuần viết code.
Nhưng ở công ty product, phạm vi công việc của mình sẽ rộng và nhiều hơn, sẽ phải có mặt từ khâu lên kế hoạch phát triển, hoặc được tham gia xây dựng thiết kế Ux và được trải nghiệm cả quá trình vận hành project nữa. Cảm giác như mình đang tận tay nhào nặn ra sản phẩm của mình vậy.
Điều thú vị nhất khi làm engineer ở MFV Tại Money Forward nói chung hoặc Money Forward nói riêng, theo anh là gì?
Như anh đã đề cập, vì là công ty product nên mình học hỏi được nhiều mảng hơn. Nhưng, còn có một điều “hay ho" hơn là một vài Ruby committer (người tham gia phát triển ngôn ngữ Ruby on Rails) cũng đang hoạt động tại Money Forward. Tuy ở hai đầu cầu Nhật Bản và Việt Nam nhưng vẫn chung một tổ chức nên vẫn có thể tìm tòi nhiều thứ và nếu có thắc mắc mình vẫn dễ dàng trao đổi về tech đấy.
Điều gì khiến anh trở thành một Tech Lead?
Một hôm nọ, bác Matt (CTO của MFV) đã gửi đến anh một lời đề nghị, trở thành Tech Lead. Anh cũng không còn rõ cảm xúc của mình khi ấy vì trước đó anh không nghĩ đến Tech Lead nhưng cũng không nghĩ sẽ chỉ làm mỗi engineer.
Với anh đây là vị trí giúp anh mở rộng tầm mắt và tư duy hơn.
Vai trò của Tech Lead có làm anh rời xa với việc coding không Steve nhỉ?
Dĩ nhiên vẫn phải code như một engineer nhé. Nhưng mà tỉ lệ phần trăm code trong công việc sẽ khác, 30% effort anh dành cho CTO office và 70% cho Project ấy. Thường ngày anh sẽ đến công ty, mở Calendar lên để nắm được công việc, họp hành trong ngày. Buổi sáng họp team project đang làm và review code của team. Thỉnh thoảng tham gia vào việc tuyển dụng, review CV nữa.
Tech Lead ở MFV là Cross department (liên phòng ban), bao trùm toàn bộ các ban khác trong công ty. Không phải là bao trùm việc phát triển sản phẩm, mà là làm sao để cải thiện chất lượng code của toàn công ty, triển khai phù hợp từng team.
Ví dụ anh sẽ hỗ trợ những team đang cần một số góp ý về mặt công nghệ hoặc tham vấn, vì Tech Lead của MFV là cross-department development nên có thể tham gia vô nhiều dự án. Cái khác nhất của Tech Lead so với vị trí khác chắc là trách nhiệm đưa ra quyết định. Tham gia hỗ trợ vào một số quy trình của team thì sẽ không tránh khỏi việc bị ngộp trước tình hình team đó. Nhưng có một điều may mắn tới giờ là anh có cơ hội tiếp xúc, lắng nghe chia sẻ của các leader, và các bác Nhật cũng chia sẻ mỗi khi 1on1 nên anh có được cái nhìn bao quát về tình hình team đó.
Anh cũng sẽ hỗ trợ các bạn fresher hoặc intern. Ví dụ đối với fresher học những ngôn ngữ mới ở công ty, thì mình xác định một tháng đầu sẽ training về mặt ngôn ngữ là chính, tư vấn những thứ có thể bổ trợ, và phải cố gắng truyền đạt điểm mạnh của ngôn ngữ như khả năng viết code dễ, cộng đồng lớn và có hỗ trợ lâu dài để các bạn thích ngôn ngữ, theo ngôn ngữ đó lâu dài. Nhưng quan trọng là làm sao để truyền đạt cho người mới họ hiểu.
Ngoài ra sẽ có Corp dev training soft skill. Còn training cho flow cụ thể thì sẽ tuỳ thuộc team bạn được phân vào.
Những khó khăn của một Tech Lead và hướng giải quyết?
Hiện tại anh có hỗ trợ những bạn fresher và intern. Với số lượng một vài bạn thì cái này không có áp lực gì lớn cả, nhưng nếu với số lượng đông hơn thì sẽ cần dành khá nhiều thời gian cho việc review code, giao tiếp và hỗ trợ các bạn. Nhưng anh không một mình, có cả các team leader đồng hành với các bạn ấy.
Thường thì người dọn bug là người trong team, không phải Tech Lead, nhưng nếu có một dự án anh tham gia với tư cách hỗ trợ từ đầu ấy, thì anh vẫn có thể “quét bug” với team đó. Khách hàng có vấn đề khi sử dụng sản phẩm của mình, đó là có bug rồi, dù là bug lớn hay nhỏ cũng phải mò ra con bug đó ngay để sửa kịp thời rồi release lại. Nhưng chưa xong, team vẫn phải họp tiếp để đề ra kế hoạch hành động không để sự cố xảy ra nữa. Có thể dùng đến các công cụ kiểm tra coding convention để chặn các lỗi tương tự, hoặc dựng nên một checklist “bí kíp" code hoặc là self-test sau khi code.
Có điều trớ trêu rằng, khi xảy ra lỗi chúng ta có thể nhìn hiện tượng và nhìn log là biết ngay lỗi ở đâu và fix thế nào, nhưng vấn đề là không ai nghĩ tới viễn cảnh của cái lỗi kỹ thuật ấy.
Trong tương lai anh còn dự định gì để phát triển bản thân hơn?
Hồi đó anh học Ruby vì thấy nó đơn giản, dễ hiểu, viết code rất gọn và nghe nói tốc độ phát triển sản phẩm bằng Ruby on Rails rất nhanh nữa, nhưng có đôi khi hiệu suất của Ruby không tốt lắm. Hiện tại ngoài Golang thì anh cũng tìm hiểu thêm về Crystal, một ngôn ngữ khá giống với Ruby nhưng hiệu suất thì hơn rất nhiều. Tuy giờ học để biết thôi, nhưng biết đâu sẽ có ngày dùng được Crystal trong các dự án ở Money Forward Vietnam.
Tất nhiên ngôn ngữ lập trình cũng quan trọng nhưng chưa phải là tất cả, còn rất nhiều thứ khác phải học nữa. Anh có mong muốn đi theo hướng DevOps nên hiện tại cũng đang tìm hiểu sâu hơn về infrastructure và CI/CD.
Theo anh Steve, cần những gì để trở thành một Tech Lead
Theo anh, người đó nên sở hữu 3 "Có" sau:
1. Có hiểu biết về nhiều công nghệ khác nhau để có thể phân tích và lựa chọn công nghệ phù hợp với từng dự án.
Thường thì công nghệ cho từng dự án sẽ được xác định dựa trên yêu cầu về nghiệp vụ và khả năng của các thành viên trong team. Nếu mình có hiểu biết về nhiều công nghệ khác nhau thì sẽ dễ dàng hơn để so sánh, phân tích và đưa ra gợi ý phù hợp nhất. Các yếu tố cần phải để ý là điểm mạnh, điểm yếu của từng công nghệ, độ phổ biến, khả năng duy trì sản phẩm bằng công nghệ đó, tình hình tuyển dụng của công ty… Việc sử dụng một công nghệ quá cũ hoặc quá khác biệt cũng nên tránh vì nó tiềm ẩn nguy cơ nếu thành viên chịu trách nhiệm chính cho phần đó mà “đứt gánh” thì dự án khó mà tiếp tục được.
2. Có kỹ năng thiết kế, quản lý code hiệu quả, dễ đọc, dễ duy trì, đặc biệt là khi team có nhiều người, nhiều cấp độ.
Trước hết anh nghĩ điều quan trọng nhất đối với một sản phẩm là nó phải chạy được và đáp ứng được đúng yêu cầu về nghiệp vụ. Kế tiếp là code quality, nó sẽ ảnh hưởng tới trải nghiệm của người dùng, chi phí vận hành, khả năng bảo trì và mở rộng sản phẩm. Có khá là nhiều best practice, design pattern về cách tổ chức code, thiết kế database, thiết kế API… để mình có thể cải thiện code quality. Cái chính là mình phải có khả năng và chủ động tự học, tự tìm hiểu, cũng đừng quên chia sẻ kiến thức với những người có cùng sự quan tâm để mọi người cùng nhau phát triển bản thân.
3. Có khả năng thích ứng với sự thay đổi
Công nghệ luôn phát triển từng ngày và các tính năng của sản phẩm cũng không phải là cố định. Sẽ có những lúc code hiện tại không thể đáp ứng tốt được nữa và cần có sự thay đổi. Trong những trường hợp như vậy, bên cạnh việc phải nhanh chóng nắm bắt được công nghệ mới thì còn phải đánh giá được sự thay đổi đó ảnh hưởng gì tới code hiện tại và làm thế nào để thay đổi với chi phí có thể chấp nhận được.
Author: Jim
Interviewee: Steve
