Tôi có một lời thú nhận.

Tôi đã copy-paste 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 sống sót qua nhiều năm làm lập trình viên.

Trong mọi nhóm mà tôi từng tham gia, tôi luôn ghi chú lại những gì các lập trình viên giỏi hơn đang làm.

Tôi học hỏi từ những người giỏi ở một số công ty đáng kinh ngạc và làm việc với những lập trình viên mà tôi thực sự nghĩ rằng họ là thiên tài.

Một người đã sáng lập một doanh nghiệp triệu đô.
Một người khác đã viết một thư viện phổ biến để kiểm thử mà có lẽ bạn đã nghe qua.
Người cuối cùng gọi thẳng ra những sai lầm của tôi.

Tôi đã "mượn" một chút từ mỗi người này để thúc đẩy sự nghiệp của mình.

Tôi thực sự rất may mắn.

Tôi sống ngay giữa trung tâm của thế giới công nghệ, tại khu vực Vịnh San Francisco. Mọi lập trình viên đầy nhiệt huyết và mơ ước đều tìm đến đây.

Nhưng bạn không cần phải dựa vào may mắn đâu.

Tôi muốn chia sẻ những bài học tôi học được từ mỗi người trong số họ, những người đã cứu tôi khỏi sự tầm thường và có thể 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 điều gì đó thật sự tốt đẹp

Trước khi gặp những lập trình viên siêu sao 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ỉ biết ơn vì ai đó đã thuê mình. Mục tiêu chính của tôi lúc đó là không bị đuổi việc.

Tôi chỉ muốn mình ở mức trung bình.

Và tôi còn không đạt nổi điều đó.

Dưới đây là một số câu nói mà bạn sẽ thường nghe từ các lập trình viên kém cỏi.

“Nó chạy trên máy của tôi”
“Tôi không biết nó hoạt động như thế nào, chỉ là nó hoạt động thôi. Đừng đụng vào nó.”
“Tôi chỉ viết code, tôi không biết gì về cách doanh nghiệp hoạt động”
“Có vẻ ổn với tôi!”

Plot twist: tôi đã từng nói tất cả những câu này.

Câu cuối cùng suýt nữa đã khiến tôi bị sa thải, nhưng chúng ta sẽ nói về chuyện đó sau.

Bạn không cần phải nhảy việc 6 lần trong 10 năm như tôi mới trở thành một lập trình viên trên mức trung bình một chút.

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

1. Người ăn salad bằng tay

Chúng ta hãy gọi anh ấy là Don.

Trước hết, người này là một thiên tài.

Tôi biết điều đó vì khi chúng tôi đi ăn vào ngày đầu tiên làm việc cùng CEO và CTO — anh ấy dùng tay để ăn salad.

Sau đó, anh ấy hỏi liệu anh 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 dám làm như vậy mà không bị sa thải ngay lập tức.

Anh ấy chuyển nghề từ y học sang lập trình ở tuổi 40 và khi tôi gặp anh ấy, anh đã ngoài 50.

Tôi mới vào nghề được 3 năm và tự coi mình là lập trình viên ở mức trung cấp.

Nhưng tôi đã nhầm.

Don lập trình cùng tôi trong hai tuần đầu làm việc và tôi nhanh chóng nhận ra mình còn quá non nớt.

Don viết các bài kiểm thử cho những tính năng chúng tôi tạo ra bằng thư viện mà anh ấy tự viết cho framework mà chúng tôi đang sử dụng.

Tôi chưa bao giờ viết một bài kiểm thử nào trong đời.

Don có các phím tắt để bay quanh terminal và trình soạn thảo code.

Tôi thì “không có thời gian” để học những thứ đó.

Tôi chỉ muốn mọi thứ “hoạt động”.

Don không chấp nhận cách làm việc kiểu “làm cho nó hoạt động bằng mọi giá” của tôi. Anh ấy từ chối làm việc với tôi cho đến khi tôi học các phím tắt trên VS Code để việc lập trình đôi trở nên thú vị hơn.

Nếu tôi viết một tính năng mà không có bài kiểm thử, anh sẽ từ chối nó.

Khi tôi nhờ giúp đỡ, anh ấy sẽ không cho tôi đáp án mà chỉ cho tôi nơi có thể tìm ra vấn đề cơ bản.

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 mẽ 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 nắm vững 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 nó đúng đắn.

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

2. Người kiểm tra mã khó tính... hay có lẽ là thiên thần

Tôi từng rất lo lắng mỗi khi người này kiểm tra mã của mình.

Lúc nào cũng có hàng tá nhận xét.

Đôi khi anh ấy đề xuất một cách tiếp cận hoàn toàn khác. Và nó luôn thông minh.

“Tại sao mình không nghĩ ra điều đó?”

Tôi nhận ra anh ấy luôn tỉ mỉ với mã của mọi người.

Tôi cảm thấy tự hào khi chỉ nhận được vài lời chỉnh sửa nhỏ trong một lần kiểm tra mã.

Còn tôi thì sao — tôi thường chấp nhận mã của mọi người một cách qua loa.

“Có vẻ ổn với tôi!”

Có. Vẻ. Ổn. Với. Tôi.

Đội ngũ này đầy rẫy các lập trình viên cấp cao. Tôi tin rằng họ đã tự kiểm tra công việc của mình. Kiểm tra mã chỉ là một hình thức đúng không?

Đúng không?

Một buổi chiều, tôi nhận được tin nhắn bí ẩn từ "Parker."

“Này, cậu có chút thời gian không?”

Nhịp tim của tôi tăng lên.

Anh ấy gọi video và hỏi tại sao tôi lại chấp nhận một mã mới từ một trong các lập trình viên cao cấp của đội. Anh ấy đưa ra từng lỗi rõ ràng mà tôi đã không bắt được.

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

Đó là một cuộc trò chuyện đau đớn và tôi xấu hổ.

Anh ấy đã đúng.

Tôi đã không làm tròn trách nhiệm cơ bản và suýt nữa chúng tôi đã phát hành mã có thể làm ứng dụng gặp sự cố và khiến khách hàng tức giận.

Tôi xin lỗi và thề sẽ trở thành người kiểm tra mã giỏi thứ hai trong nhóm.

“Parker, anh làm thế nào để kiểm tra mã?”

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

Chạy mã trên máy cục bộ và kiểm tra chức năng trước khi xem mã. Nếu nó không hoạt động thì không có lý do gì để xem xét.
Xem qua mã mới từng dòng để hiểu nó đang thêm gì.
Đặt câu hỏi để chắc chắn rằng bạn hiểu những gì không rõ ràng.
Gặp mặt để xem lại các lần kiểm tra lớn và để lập trình viên giải thích mã.
Luôn kiểm tra mã vào buổi sáng trước khi bắt đầu công việc của riêng mình để tránh phải chuyển đổi ngữ cảnh.

Wow.

Đó là một quy trình phức tạp hơn rất nhiều so với những gì tôi đã làm.

Tôi quyết định sẽ kiên trì thực hiện nó để tránh những rắc rối trong tương lai.

Trong buổi đánh giá cuối năm, một số đồng nghiệp đã khen ngợi khả năng kiểm tra mã của tôi và quản lý cảm ơn tôi vì đã làm việc một cách tỉ mỉ.

Tôi cảm thấy mình đã làm tốt.

3. Người ăn salad từ các từ khóa công nghệ

Tôi gặp “James” gần đây, ở công ty cuối cùng tôi làm và chúng tôi cùng nhau quản lý một đội ngũ nhỏ các lập trình viên.

Là quản lý kỹ thuật, tôi phụ trách lập kế hoạch kỹ thuật cho quý.

Lần đầu tiên, tôi có quyền quyết định mọi thứ.

Cuối cùng, chúng tôi có thể sử dụng tất cả công nghệ mà tôi muốn như NextJS và TypeScript. Chúng tôi có thể làm lại thư viện mà tôi đã viết nhiều năm trước. Tôi nghĩ chúng tôi thậm chí có thể tìm cách sử dụng Kubernetes.

Nó sẽ rất tuyệt.

Tôi trình bày cho James.

“Mục đích của việc làm tất cả những thứ này là gì?” anh ấy hỏi.

Tôi bắt đầu diễn giải một cách hào hứng các từ khóa công nghệ:

“Ờ thì, uhh, trang web tĩnh có thể giảm thời gian tải, tăng giá trị SEO và client HTTP của chúng ta đang dùng phiên bản NodeJS lỗi thời và có thể dùng công cụ CLI để cải thiện DX.”

James chỉ biết thở dài.

“Thật lòng mà nói, tôi không hiểu cậu đang nói gì cả. Làm thế nào điều này sẽ giúp chúng ta đạt được các mục tiêu kinh doanh trong quý?”

…

Thật lòng mà nói, tôi chưa nghĩ đến chuyện đó.

“Brian,” anh ấy nói, “chúng ta đang kinh doanh để kiếm tiền cho tổ chức. Nếu những điều này cần thiết hoặc hỗ trợ cho một mục tiêu kinh doanh nào đó thì nên làm. Nếu không thì chỉ là những thứ hào nhoáng không cần thiết.”

Tôi quay lại bảng vẽ và nói chuyện với đội ngũ sản phẩm để tìm hiểu nhu cầu thực sự của doanh nghiệp cho quý tới.

Điều đó không bao gồm việc giảm thời gian tải trang xuống 200 mili-giây.

Nó bao gồm một số thách thức rất thú vị mà tôi vui lòng tiếp nhận.

Ý định của tôi là tốt, chỉ là đi sai hướng.

Bạn sẽ trở thành ai?

Mỗi câu chuyện hay đều cần một người hùng.

Ba người này là những người hùng tôi cần ở những thời điểm khác nhau trong sự nghiệp của mình. Tôi đã áp dụng nhiều thói quen, quy trình và mô hình tư duy của họ vào thói quen của mình. Điều đó đã giúp tôi rất nhiều.

Nhưng 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 cần chứ?

Một kẻ phản diện.

Không may, tôi có lẽ đã là kẻ phản diện trong suy nghĩ của một số lập trình viên khác.

Tôi từng là một gánh nặng. Tôi từng viết mã cẩu thả. Tôi từng mất quá nhiều thời gian để hoàn thành tính năng.

Nhưng điều đó cũng ổn, tôi nghĩ vậy.

Người ta nói rằng nếu bạn là người thông minh nhất trong phòng, thì bạn đang ở nhầm phòng.

Nói thì dễ, làm mới khó.

Nếu có một điều rút ra từ những người mà tôi đã gặp, ngoài việc bạn nên viết kiểm thử, quan tâm đến bối cảnh kinh doanh và kiểm tra mã một cách nghiêm túc, thì điều đó là:

Hãy đuổi theo sự không thoải mái.

Ở bên những người biết nhiều hơn bạn và học hỏi từ họ là con đường hiệu quả nhất để trở nên giỏi hơn một chút trong bất kỳ lĩnh vực nào.

Hy vọng điều đó có ích.

nguồn: Brian Jenney

#ChunhThanhDe #ChungNguyenThanh #NguyenThanhChung #ChungBlog #3lesson

3 Lessons from the Smartest Developers I’ve Worked With

Table of contents