Bài viết được dịch từ Dev.to. Truy cập bài viết gốc: You don't need to know everything (but you should know something well)
Mới đi làm được cỡ một năm rưỡi nay, tuy chưa đủ thâm niên để gọi là người từng trải trên con đường công nghệ, kỹ thuật phần mềm, nhưng thật sự có những lúc mình cảm thấy đuối, mệt mỏi, bị "overwhelmed", và đôi khi muốn bỏ cuộc khi xung quanh có quá nhiều con người tài năng, thông minh mà mình thua kém, và còn quá nhiều kiến thức chưa biết hoặc không thể tiếp thu nổi trong lĩnh vực chuyên môn. Mình đã học hỏi kinh nghiệm của nhiều anh đi trước, đọc nhiều bài viết rất hay của nhiều người trong ngành, cả Việt lẫn Eng, để có nguồn động lực mà phấn đấu. Một trong số đó là bài chia sẻ dưới đây từ Dev.to, mình xin dịch lại để mọi người cùng đọc và chiêm nghiệm.
Photo by Lysander Yuen on Unsplash
Dan Abramov (kỹ sư tại Facebook, core member của ReactJS, đồng sáng lập Redux và Create React App) có đăng một số bài viết khiến tôi suy ngẫm rất nhiều. Có hai bài viết mà tôi xem là món quà quý giá, để tôi cho bạn biết tại sao.
Trong bài viết đầu tiên, Things I Don’t Know as of 2018 (Những thứ mà tôi chưa biết, tính đến 2018), Dan liệt kê ra một danh sách những công nghệ, kỹ thuật mà anh biết rất ít, hoặc thậm chí không biết gì. Tôi sẽ không liệt kê ra đây vì chúng ta không tập trung nói về chủ đề đó.
Nhiều developer phải vật lộn với ý nghĩ viễn vông là làm sao để trở thành một developer trên thông thiên văn, dưới tường địa lý, một người có thể am hiểu tường tận mọi công nghệ, kỹ thuật cool ngầu (từ quá khứ, hiện tại, đến tương lai). Ý nghĩ này có lẽ xuất phát từ sự kết hợp giữa các yếu tố: lòng tự tôn của bản thân, áp lực từ đồng nghiệp, đồng môn, những "siêu nhân" phần mềm, hay những kỳ vọng không tưởng, và những mô tả công việc tuyển dụng được phóng đại lên. Dẫn đến việc bạn dần bị kiệt quệ hoặc mất đi những kĩ năng xã hội cần thiết.
Do đó, để có cái nhìn thoáng hơn, tôi rất khuyên bạn nên đọc qua bài chia sẻ của Dan. Trích dẫn vài câu trong bài:
Chúng ta có thể thừa nhận những lỗ hổng kiến thức của mình, nhưng dù thế nào thì vẫn có những kiến thức chuyên môn cực kỳ giá trị mà ta đã phải trải qua nhiều năm làm việc mới có được.
Điều này nhắc tôi nhớ đến phong thái của một số thành viên khác trên Dev.to mà tôi đang theo dõi. Họ là những người biết rất sâu, rất giỏi chuyên môn trong một lĩnh vực nào đó nhưng không hề e ngại thừa nhận những điều họ chưa biết và muốn trao dồi không ngừng về lĩnh vực đó. Một phẩm chất nên có, không chỉ đối với việc làm lập trình.
Tôi biết mình còn thiếu sót nhiều kiến thức, nhưng tôi có thể bổ sung sau, lúc tôi tò mò hay cần dùng cho một dự án mới.
Điều này không làm đánh mất giá trị của tôi, về kiến thức hay kinh nghiệm. Bởi vẫn có nhiều thứ mà tôi có thể làm tốt, ví dụ như khả năng học nhanh công nghệ khi tôi cần tới.
Đây là điểm mấu chốt. Sự phát triển theo hướng tò mò (hoặc "sự phát triển khi cần thiết") là một trong những điểm chung có ở nhiều developer thành công. Học cách để học (learning how to learn) lại càng quan trọng hơn.
Trong bài viết thứ hai, The Elements of UI Engineering (Các yếu tố trong xây dựng UI), Dan nói về những cái mà anh biết sâu, cùng với một điều làm bài viết này trở nên quý giá.
Nếu trong bài viết đầu, anh liệt kê những công nghệ và kỹ thuật, thì ở bài viết này, a liệt kê những phương pháp, pattern, và những điều quan trọng cho việc phát triển UI. Dan nhấn mạnh một khía cạnh mà tại đây, chúng ta lại có một cái nhìn nữa:
Đột phá lớn nhất trong sự học của tôi không phải từ một công nghệ nhất định, mà là khi tôi phải vật lộn để giải quyết một vấn đề về UI, đây mới là lúc tôi học được nhiều nhất. Đôi khi, tôi tìm ra được một thư viện hay pattern có thể giúp giải quyết vấn đề, nhưng cũng có lúc, tôi phải tự tìm ra giải pháp cho riêng mình (tốt có, xấu có).
Hiểu được vấn đề, thử nghiệm nhiều giải pháp, và áp dụng các chiến lược khác nhau, chính sự kết hợp này mới đem lại cho tôi một trải nghiệm học bổ ích nhất trong cuộc đời của mình.
Trên dev.to, cũng có rất nhiều bài viết và thảo luận nói về việc: nắm chắc những nguyên tắc cơ bản và tư duy giải quyết vấn đề có giá trị hơn nhiều so với việc sử dụng công nghệ này, công nghệ kia.
Như tiêu đề: Không nhất thiết phải biết rộng, nhưng nên biết sâu.
