Tôi có một lời thú tội. Tôi đã copy và paste trong suốt sự nghiệp lập trình của mình. Thật lòng mà nói, đó là cách tôi tồn tại qua nhiều năm làm việc với tư cách là một developer.

Ở mỗi team tôi từng tham gia, tôi luôn quan sát và học hỏi từ những lập trình viên giỏi hơn. Có người đã khởi nghiệp thành công và xây dựng doanh nghiệp trị giá hàng triệu đô. Có người đã viết một thư viện unit test phổ biến mà có thể bạn đã từng nghe qua. Trong đó, có cả người đã thẳng thắn chỉ ra những sai lầm của tôi. Tôi đã "lấy cắp" một chút từ mỗi người trong số họ để thúc đẩy sự nghiệp của chính mình. Tôi muốn chia sẻ những bài học mà tôi học được từ những người đó, những người đã cứu tôi khỏi sự tầm thường và có thể sẽ giúp ích cho bạn.

Bạn sẽ không nhận ra điều gì là tệ cho đến khi bạn trải nghiệm được những thứ  tốt hơn. Trước khi gặp những lập trình viên xuất sắc này, tôi đã đặt mục tiêu quá thấp trong sự nghiệp của mình. Sau khi học lập trình ở tuổi 30, tôi chỉ cảm thấy vui mừng khi có ai đó chịu tuyển dụng mình. Mục tiêu chính của tôi lúc đó chỉ là không bị sa thải. Tôi đã chọn trở thành người “bình thường” và tôi thậm chí còn không đạt được điều đó.

Đây là những câu nói bạn thường nghe từ những lập trình viên ở mức trung bình:

  • "Nó chạy được trên máy tôi là được rồi."

  • "Tôi không biết sao nó hoạt động, nhưng cứ để vậy đi, đừng động vào."

  • "Tôi chỉ viết code, tôi không biết gì về việc kinh doanh."

  • "Nhìn ổn mà!"

Bất ngờ chưa: tôi đã từng nói tất cả những câu này, và câu cuối cùng suýt chút nữa khiến tôi mất việc, nhưng tôi sẽ nói thêm về chuyện đó sau.

Dưới đây là 3 bài học mà tôi học được từ những người thông minh nhất mà tôi từng gặp.

1. Người ăn salad

Gọi anh ấy là Don nhé. Trước hết, anh chàng này là một thiên tài. Tôi biết điều đó vì ngay ngày đầu đi ăn cùng CEO và CTO, anh ấy đã dùng tay để ăn salad. Sau đó, anh ấy hỏi liệu có thể về sớm vì cảm thấy mệt. Anh ấy ngủ trên ghế sofa trong văn phòng vào giữa trưa. Chỉ có thiên tài mới có thể làm mấy chuyện như thế mà không bị sa thải ngay lập tức.

Don chuyển nghề từ y khoa sang phần mềm khi anh ấy đã 40 tuổi và lúc tôi gặp thì anh ấy đã ngoài 50. Tôi lúc đó đang bước sang năm thứ 3 làm lập trình viên và tự xem mình đã ở tầm mid-level và điều ấy là sai hoàn toàn.

Don đã pair-programming với tôi trong 2 tuần đầu tiên đi làm, và tôi nhanh chóng nhận ra mình vẫn còn rất "non". Don đã viết các bài test cho những tính năng mà chúng tôi phát triển, sử dụng chính thư viện mà anh ấy tạo ra cho framework chúng tôi đang dùng. Tôi thì chưa bao giờ viết bài test nào trong đời.

Don thông thạo các phím tắt để lướt qua lại như bay trên terminal và code editor. Còn tôi thì "không có thời gian" cho mấy chuyện đó. Tôi chỉ muốn mọi thứ “chạy được.” Don không chấp nhận kiểu làm việc “miễn sao chạy được” của tôi. Anh ấy từ chối làm việc cùng tôi cho đến khi tôi học cách sử dụng phím tắt trong VS Code để làm cho việc pair-programming trở nên dễ dàng hơn.

Nếu tôi viết tính năng mà không có kiểm thử, anh ấy sẽ từ chối. Khi tôi nhờ anh ấy giúp đỡ, Don không bao giờ đưa ra câu trả lời trực tiếp mà chỉ bảo tôi nên tìm nguyên nhân ở đâu.

Chúng tôi chỉ làm việc cùng nhau 9 tháng nhưng đó là khoảng thời gian tác động mạnh nhất trong sự nghiệp của tôi. Tôi đã học được nghệ thuật kiểm thử, tầm quan trọng của việc thành thạo công cụ của mình, và cách cân bằng giữa việc hoàn thành công việc và làm cho đúng cách.

Lần cuối tôi nghe về anh ấy, Don đã đồng sáng lập một công ty phần mềm trị giá hàng triệu đô. Tôi cá là anh ấy vẫn đang ăn salad bằng tay.

2. Reviewer từ địa ngục… hay có lẽ là từ thiên đường

Tôi từng rất lo lắng mỗi khi anh chàng này (tên là Parker) review code của tôi, lúc nào cũng có cả tá comment trở lên. Đôi khi anh ấy sẽ đề xuất một cách tiếp cận hoàn toàn khác và lần nào cũng thông minh hơn.

Lúc ấy tôi suy nghĩ: "Sao mình không nghĩ ra nhỉ?"

Tôi nhận ra rằng anh ấy rất kỹ lưỡng với code của tất cả mọi người. Tôi cảm thấy tự hào khi chỉ nhận được vài góp ý nhỏ trong một lần review. Còn tôi thì sao? Tôi làm review code kiểu "đóng dấu" như nhân viên ở bưu điện.

Nhóm này toàn senior level developers nên tôi tin tưởng rằng họ đã tự kiểm tra code của mình. Việc review chỉ là hình thức, đúng không?

Một buổi chiều, tôi nhận được một tin nhắn Slack khó hiểu từ "Parker."

"Này bạn — cậu có rảnh chút không?"

Tim tôi bắt đầu đập nhanh hơn.

Anh ấy gọi video và hỏi tại sao tôi lại chấp nhận review code gần đây từ một trong những người senior trong nhóm. Anh ấy bắt đầu chỉ ra từng lỗi rõ ràng.

"Sao cậu lại không phát hiện ra điều này?"

Đó là một cuộc trò chuyện khó khăn và tôi cảm thấy xấu hổ.

Anh ấy nói đúng. Tôi đã không làm được tối thiểu cần thiết và chúng tôi suýt chút nữa release code có thể gây crash app và làm khách hàng bực mình. Tôi đã xin lỗi và tự hứa sẽ trở thành reviewer giỏi thứ hai trong nhóm.

Tôi hỏi anh ấy: "Parker, cậu review code như thế nào vậy?"

Anh ấy chỉ cho tôi quy trình của mình:

  • Chạy code trên máy local và kiểm tra xem chức năng có hoạt động không, trước khi bắt đầu xem code. Nếu nó không chạy đúng, thì việc xem code cũng không có ích gì.

  • Xem qua code mới từng dòng một để hiểu rõ những thay đổi hoặc tính năng mới được thêm vào.

  • Đặt câu hỏi nếu có phần nào không rõ ràng để đảm bảo bạn hiểu đúng ý tưởng của code.

  • Với những phần review lớn, hãy gặp mặt trực tiếp với developer để họ giải thích về code.

  • Nên thực hiện việc review vào buổi sáng trước khi bắt đầu công việc của mình để tránh phải chuyển đổi giữa các nhiệm vụ, giúp tập trung tốt hơn.

Điều đó thực sự chi tiết hơn rất nhiều so với những gì tôi đang làm. Tôi quyết định sẽ bám theo quy trình này và tránh một cuộc "đấu khẩu" khác.

Trong buổi đánh giá cuối năm, nhiều đồng đội đã khen ngợi tôi về các bài review code và quản lý của tôi cảm ơn vì tôi đã làm việc rất cẩn thận. 

3. Người chuyên dùng thuật ngữ như ăn salad

Tôi gặp James gần đây, tại công ty trước của tôi, và chúng tôi cùng là quản lý một nhóm nhỏ các developer.

Với vai trò Engineering Manager, tôi chịu trách nhiệm xây dựng roadmap kỹ thuật cho từng quý. Tôi chưa bao giờ có quyền hạn lớn như vậy trước đây. Cuối cùng thì, tôi cũng có thể sử dụng các công nghệ mà tôi luôn muốn thử, như NextJS và TypeScript. Chúng tôi có thể chỉnh sửa lại thư viện mà tôi đã viết từ vài năm trước. Thậm chí, tôi còn nghĩ đến việc tích hợp cả Kubernetes.

Nghe có vẻ thật tuyệt. Tôi trình bày kế hoạch đó cho James.

“Làm tất cả những điều này để làm gì?” anh ấy hỏi.

Tôi bắt đầu xổ ra hàng loạt thuật ngữ công nghệ (đang rất nhập vai người quản lý mới):

“À, ờ, static site generation sẽ giúp giảm thời gian tải trang, tăng giá trị SEO, và http client của chúng ta đang dùng phiên bản NodeJS cũ, nên có thể dùng công cụ CLI để cải thiện DX.”

James nghe xong mà muốn "xỉu ngang".

“Thành thật mà nói, tôi chẳng hiểu cậu đang nói gì cả. Những thứ này có giúp gì cho mục tiêu kinh doanh của quý không?”

…

Thật sự, tôi chưa nghĩ tới điều đó.

“Brian,” anh ấy nói, “Chúng ta làm việc để tạo ra doanh thu cho công ty. Nếu những thứ này cần thiết hoặc hỗ trợ mục tiêu kinh doanh thì tốt. Còn không thì chỉ là màu mè thôi.”

Tôi quay lại xem xét lại kế hoạch và trao đổi với team sản phẩm để hiểu rõ nhu cầu của doanh nghiệp cho quý tới. Hóa ra, chẳng ai quan tâm đến việc giảm thời gian tải trang thêm 200 mili giây. Nhưng lại có vài thách thức rất thú vị mà tôi rất sẵn lòng giải quyết.

Tôi nhận ra mình có ý định tốt, chỉ là đi sai hướng thôi.

4. Bạn sẽ là ai?

Mọi câu chuyện hay đều cần có một nhân vật chính.

Ba người này chính là những “người hùng” mà tôi cần vào các thời điểm khác nhau trong sự nghiệp. Tôi đã học theo rất nhiều thói quen của họ, áp dụng cách làm việc và lối tư duy của họ vào công việc hàng ngày của mình. Nhìn chung thì cách đó đã hiệu quả với tôi.

Dù vậy, tôi vẫn dùng nĩa để ăn salad.

Bạn biết điều gì nữa mà mọi câu chuyện hay đều cần không?

Một nhân vật phản diện. Đáng tiếc là có lẽ trong mắt một vài developer, tôi đã từng là nhân vật phản diện đó. Tôi đã gây khó dễ cho họ. Tôi tạo ra những đoạn code cẩu thả. Tôi mất quá nhiều thời gian để hoàn thành một tính năng.

Nếu có một điều mà tôi rút ra được từ những người đồng nghiệp này, bên cạnh việc bạn nên viết test, quan tâm đến ngữ cảnh kinh doanh và đánh giá code cẩn thận — thì đó là: Hãy theo đuổi sự không thoải mái.

Làm việc cùng những người giỏi hơn mình và học hỏi từ họ là con đường hiệu quả nhất để trở nên nhỉnh hơn mức trung bình trong bất kỳ lĩnh vực nào.

Hy vọng điều này sẽ hữu ích với bạn.

Nguồn: Brian Jenney

VietnamWorks inTECH

TẠO TÀI KHOẢN MỚI: XEM FULL “1 TÁCH CODEFEE” - NHẬN SLOT TƯ VẤN CV TỪ CHUYÊN GIA - CƠ HỘI RINH VỀ VOUCHER 200K