Trong lĩnh vực phát triển phần mềm đang thay đổi nhanh chóng, không tiến bộ đồng nghĩa với việc tụt lại phía sau. Công nghệ đang phát triển với tốc độ chóng mặt – những ai theo kịp sẽ được hưởng nhiều lợi ích, còn những ai không theo kịp sẽ nhanh chóng trở nên lỗi thời. Trong bài viết này, mình sẽ trình bày những cách phổ biến nhất khiến lập trình viên bị tụt hậu và cách để tránh điều đó.
Họ không tiếp nhận (hoặc không thực sự tiếp nhận) phản hồi
Không nghi ngờ gì nữa, phản hồi mang tính xây dựng chính là chất xúc tác quan trọng nhất giúp lập trình viên phát triển sự nghiệp và nâng cao kỹ năng. Dù là phản hồi từ Pull Request, từ quản lý, hay từ đồng đội, nó có thể tạo nên sự khác biệt giữa một lập trình viên giỏi và một lập trình viên xuất sắc. Nếu một lập trình viên không thể tiếp nhận phản hồi một cách hiệu quả, họ đang tự đặt giới hạn cho năng lực và tiềm năng của chính mình.
Bạn có thể đang nghĩ: “Tôi tiếp nhận phản hồi rất tốt mà, tôi không bao giờ để bụng và luôn cư xử tử tế với người góp ý.” Điều đó thật tuyệt, nhưng đó chưa phải là cách tiếp nhận phản hồi đúng nghĩa. Phản hồi nên khiến bạn thay đổi cách viết mã, cách suy nghĩ khi thiết kế giải pháp – dù chỉ một chút. Nó không phải thứ bạn áp dụng qua loa trong một vài Pull Request chỉ để làm hài lòng người góp ý.
Đây là cách bạn nên tiếp nhận phản hồi:
Trước hết, nếu bạn có thắc mắc về phản hồi, hãy hỏi. Nếu bạn không đồng ý hoặc không hiểu phản hồi đó, hãy mạnh dạn đặt câu hỏi. Bạn sẽ không thể ghi nhớ hay áp dụng phản hồi một cách hiệu quả nếu bạn không thực sự hiểu – hoặc tệ hơn là bạn chẳng tin vào nó. Đừng dễ dãi với mã của mình chỉ để làm hài lòng người khác.
Ghi chú lại. Hãy viết ra những gì bạn học được, duy trì một nhật ký kỹ thuật hoặc ghi chú cá nhân về các bài học. Việc này giúp bạn có thể xem lại khi cần và đưa ra các quyết định kỹ thuật chính xác hơn trong tương lai.
Áp dụng lại phản hồi vào mã cũ. Nếu phản hồi bạn nhận được thực sự có ý nghĩa với bạn, hãy quay lại và chỉnh sửa cả những đoạn mã cũ. Nếu bạn nhận phản hồi ở một phần mã cụ thể, hãy áp dụng nó rộng hơn ở những phần khác nữa. Càng thực hành, bạn sẽ càng thành thạo và giúp cho codebase ngày càng chất lượng hơn.
Chia sẻ lại với người khác. Nghe có vẻ đơn giản, nhưng đây là điều cực kỳ hiệu quả – dạy lại là cách học tốt nhất. Khi bạn chia sẻ điều mình học được với người khác, bạn sẽ hiểu sâu hơn và thậm chí có thể học thêm nhiều điều mới từ chính cuộc trao đổi đó.
Họ không đặt câu hỏi
Lập trình là một lĩnh vực kỳ lạ. Rất nhiều kiến thức hữu ích nhất không nằm trong các bài giảng đại học, sách vở hay các khóa học lập trình. Kiến thức thực sự lại nằm trong đầu của những lập trình viên tài năng và giàu kinh nghiệm – những người thường không bao giờ viết sách, và phần lớn trong số họ chỉ viết tài liệu kỹ thuật ở mức tối thiểu.
Vì vậy, lập trình viên quá nhút nhát hoặc quá tự cao để nhờ người khác và đặt câu hỏi sẽ luôn tụt lại phía sau so với lập trình viên tò mò – người luôn có một kho vô tận những câu hỏi.
Người này sẽ học các tiêu chuẩn của ngành ngay khi chúng được xây dựng trong khi người kia có thể mất nhiều năm để học chúng.
Nói tóm lại là: nếu bạn không biết, hãy hỏi. Đừng lo lắng về những điều như “nếu mình làm phiền lập trình viên này thì sao?” hoặc “mình sẽ trông ngốc nếu hỏi câu này chăng?”, vì bạn sẽ trông ngốc hơn nhiều khi đến lúc cần thông tin đó mà lại không có.
Họ Tránh Né Những Vấn Đề Khó
Rất dễ để rơi vào lối mòn khi làm phần mềm. Bạn có thể cứ tiếp tục làm những việc quen thuộc mà mình cảm thấy thoải mái và không bao giờ thử thách bản thân để giải quyết một vấn đề thực sự phức tạp. Tôi đã từng thấy nhiều lập trình viên luôn chọn những nhiệm vụ dễ và không bao giờ dám đụng đến những việc khó khăn. Nhưng chính những vấn đề khó mới là nơi bạn học được nhiều nhất – bạn buộc phải suy nghĩ theo cách khác, phải khám phá những công nghệ mới để giải quyết chúng. Nếu bạn cứ mãi giải quyết những vấn đề dễ dàng lặp đi lặp lại, thì tôi đảm bảo bạn sẽ tụt lại phía sau với tư cách là một lập trình viên.
Nếu bạn là một lập trình viên full stack nhưng lúc nào cũng chỉ chọn các nhiệm vụ frontend, thì bạn biết không? Vài năm nữa bạn sẽ chỉ còn là một lập trình viên frontend mà thôi. Nếu bạn là một lập trình viên backend nhưng chỉ làm các công việc nhỏ, đơn giản, thì chẳng mấy chốc bạn sẽ quên cách tích hợp hệ thống hoặc triển khai các tính năng phức tạp. Những gì bạn không sử dụng sẽ dần biến mất.
Họ Không Bao Giờ Làm Dự Án Riêng
Tôi hoàn toàn không có ý nói rằng lập trình viên phải dành toàn bộ thời gian ngoài giờ làm việc để cắm đầu vào dự án cá nhân, nhưng mỗi lập trình viên nên cố gắng tạo ra một vài dự án riêng cho mình. Lý do chính là không có cách nào tốt hơn để phát triển một cái nhìn tổng thể và sâu sắc về hệ thống. Trong hầu hết các công việc lập trình, một lập trình viên thường chỉ chuyên sâu vào một hoặc hai lĩnh vực, điều này giới hạn cơ hội phát triển. Làm một dự án từ đầu sẽ giúp bạn lấp đầy những lỗ hổng kiến thức và học được nhiều điều như thiết kế hệ thống, quản lý sản phẩm, tích hợp hệ thống, xác thực, devops, v.v.
Một lý do tuyệt vời khác để làm dự án cá nhân là để áp dụng kiến thức vào thực tế. Việc học qua các tutorial hay từ giảng viên là một chuyện, nhưng việc tự mình triển khai những gì đã học vào một dự án thực tế lại là một câu chuyện hoàn toàn khác. Khi học qua tutorial, lúc nào cũng có câu trả lời “đúng” và có người hướng dẫn bạn từng bước. Nhưng khi làm dự án riêng, bạn phải tự mình nghiên cứu và suy nghĩ để tìm ra giải pháp tốt nhất cho trường hợp của mình – và chính điều đó giúp bạn hiểu sâu sắc và ghi nhớ lâu hơn rất nhiều.
Họ Không Bao Giờ Thay Đổi Vai Trò Hoặc Công Ty
Khi bạn thay đổi vai trò hoặc chuyển sang một công ty mới, sẽ có một vài điều xảy ra:
- Bạn được tiếp xúc với những đồng đội mới – những người có thể dạy bạn nhiều điều mới mẻ
- Bạn làm những công việc khác, buộc bạn phải suy nghĩ theo cách khác
- Bạn được làm việc với các công nghệ khác nhau, giúp mở rộng kỹ năng và làm đẹp hồ sơ cho các cơ hội trong tương lai
Tôi xem những sự thay đổi này như là động lực mạnh mẽ để học hỏi và phát triển – chúng đóng vai trò như một “cú hích” giúp bạn nâng cao khả năng lập trình. Tôi tin rằng việc nhanh chóng học một tech stack mới trong quá trình onboard, cùng với những thử thách hoàn toàn mới, sẽ thúc đẩy não bộ bạn hoạt động và giúp nâng cấp kỹ năng lập trình của bạn lên một tầm cao mới.
Họ Không Bao Giờ Chuyển Sang Ngôn Ngữ Lập Trình Khác
Điều này có thể khiến nhiều lập trình viên cảm thấy không thoải mái, đặc biệt là những người luôn khăng khăng cho rằng ngôn ngữ lập trình của mình là tốt nhất. Nhưng sự thật là, việc học và thực hành nhiều ngôn ngữ khác nhau mang lại rất nhiều giá trị. Cuối cùng thì, một ngôn ngữ lập trình chỉ là công cụ – bạn nên chọn công cụ phù hợp nhất với công việc, không tồn tại cái gọi là “công cụ tốt nhất” cho mọi tình huống. Lập trình viên sở hữu càng nhiều công cụ thì càng linh hoạt và thích nghi tốt hơn.
Bạn có thể yêu thích C++ và ghét Javascript, nhưng sự thật là Javascript phù hợp với phát triển giao diện người dùng hơn rất nhiều. Cố gắng viết mã frontend bằng C++ chẳng khác gì cố gắng gõ bàn phím bằng cờ lê – nó đơn giản là không phù hợp, mặc dù C++ rất hữu ích trong các ngữ cảnh khác. Tương tự, nếu bạn cần viết một ứng dụng có hiệu suất tối ưu và cao, thì nhìn chung nên tránh dùng Python. Dù Python không phải là một ngôn ngữ tệ, nhưng nó đơn giản là không phù hợp cho nhu cầu đó.
Các tiêu chuẩn và yêu cầu trong ngành công nghệ thay đổi liên tục. Phía dưới là biểu đồ so sánh mức độ phổ biến của các ngôn ngữ lập trình theo thời gian. Việc học nhiều ngôn ngữ lập trình khác nhau sẽ giúp bạn dễ dàng thích nghi với sự thay đổi của ngành và luôn được săn đón trên thị trường.
Mình hy vọng những chia sẻ trên đây sẽ giúp ích được bạn. Cảm ơn các bạn đã đọc hết bài viết của mình.