Làm công việc lập trình thêm vui từ việc thay đổi cách tiếp cận

1. Sử dụng keywords trong giao tiếp

Sau nhiều năm làm việc trong ngành này, tôi nhận ra rằng khâu làm việc cần thiết nhưng lại kém hiệu quả nhất chính là giao tiếp.
Nó tốn rất nhiều thời gian và công sức để giải thích một vấn đề, đặc biệt là khi có nhiều level, nhiều người không cùng chuyên môn tham gia vào cuộc trò chuyện.
Và lúc này, keywords, những từ khóa chuyên ngành dễ dàng tìm được thông qua AI, đã giúp cho cuộc trò chuyện trở nên “hanh thông” rất nhiều.
Tôi có thể giới thiệu keywords, mọi người sẽ mất thời gian cho việc hiểu keywords lần đầu tiên, nhưng sau đó nó sẽ giúp vấn đề được hiểu nhanh hơn rất nhiều, nhất là trong lần giao tiếp tiếp theo.

2. Design pattern

Sáng tạo, hmmm, mĩ miều đấy, nhưng có thực sự phải sáng tạo lại mọi thứ không?

Có nhất thiết phải tập trung tìm tòi sáng tạo lại bánh xe trong quá trình xây dựng 1 chiếc xe đạp không?

Cụ thể hoá bài toán, tìm ra design pattern phù hợp, đánh giá tính phù hợp và phạm vi, cuối cùng là áp dụng nó là các bước mà tôi thường làm khi giải quyết một vấn đề nào đó.
Với tôi, áp dụng design pattern là cách để giải quyết vấn đề một cách hiệu quả, nhanh chóng và đặc biệt nhất là giúp việc bảo trì, mở rộng sau này trở nên dễ dàng hơn. Nó phù hợp với việc sử dụng keywords trong giao tiếp mà tôi đã đề cập ở trên.

3. Tập trung vào business logic hơn là kỹ thuật vĩ mô

Tìm tòi và áp dụng công nghệ mới trong lập trình luôn là điều hứng thú với tôi cho đến tận bây giờ.
Tuy nhiên, sau nhiều năm đi làm, tôi nhận ra rằng việc “sa đà” quá nhiều vào công nghệ mới có thể làm mất đi sự tập trung vào business logic. Nó dẫn đến, đôi khi tôi bị mắc phải sai lầm mang tên “dùng dao mổ trâu giết gà”.
Việc tập trung vào business logic và tìm công nghệ phù hợp là thiết thực hơn. Vì dù sao đi nữa, đích đến cuối cùng của lập trình là giải quyết vấn đề kinh doanh một cách hiệu quả, chứ không phải là việc khoe mẽ công nghệ mới nhất.

4. Là một code reviewer “dễ tính nhưng nghiêm khắc”

Với tinh thần mỗi dòng code đều có lý do tồn tại, tôi không đặt câu hỏi tại sao nó lại được viết như vậy, mà tôi sẽ đặt câu hỏi “nếu tôi là người viết code này, tôi sẽ viết nó như thế nào?”.

Tôi thích các cách mà member giải thích cho nhau nghe về code của nhau theo với những cách tiếp cận khác nhau.
Việc cho nhau cơ hội giải thích, tôi nhận lại được nhiều hơn mình nghĩ. Những domain knowledge, keywords về technique, design pattern, hay thậm chí là những cách tiếp cận khác nhau để giải quyết một vấn đề nào đó.

Tuy nhiên, để mọi thứ không đi quá xa, tôi luôn có những pipeline steps cần được tuân thủ. Những convention, lint rules, hay những quy tắc về code structure, code style, v.v… sẽ được thống nhất bởi mọi người ngay từ đầu và áp dụng một cách nghiêm khắc.

5. Tư duy phản biện

Trong suốt quá trình làm việc, tôi luôn được làm việc với những con người rất tử tế. Họ có năng lực thực sự vì thế mà họ thực sự lắng nghe và tôn trọng ý kiến của người khác, kể cả khi họ không đồng ý với nó.
Chính trong những môi trường làm việc này, tư duy phản biện của tôi cũng được cải thiện rất nhiều. Tôi học được cách lắng nghe, phân tích và đánh giá các ý kiến khác nhau một cách khách quan, thay vì chỉ dựa trên cảm xúc hay quan điểm cá nhân.
Và thay vì chấp nhận mọi thứ một cách mù quáng, tôi đã học được cách đặt câu hỏi, tìm hiểu sâu hơn và có những quyết định đúng đắn hơn trong công việc.
Tuy nhiên, đôi khi, chính cái tư duy phản biện này đã làm “phiền” những người xung quanh tôi vì chưa chọn đúng thời điểm phù hợp. Nhưng biết sao đây, tôi vẫn đang “học” và “vui” với nó.

6. Ưu tiên code chạy hơn là code đẹp

Tôi sẽ bắt đầu bằng câu nói của Reid Hoffman

If you are not embarrassed by the first version of your product, you’ve launched too late
— Reid Hoffman, người sáng lập LinkedIn —

Và kết thúc section này với một triết lý của Mark Zuckerberg

Done is better than perfect
—Mark Zuckerberg, Meta —

Phần kết

Còn 1 cách tiếp cận công việc của tôi gần đây nữa, đó là AI. Hiệu quả của việc sử dụng AI là điều không thể phủ nhận, nó giúp tôi tiết kiệm rất nhiều thời gian trong giao tiếp khi những “keywords” được tìm và hiểu nhanh chóng giữa mọi người, những bản demo theo design pattern được viết ra nhanh hơn và pre-check rules trước để quá trình review code ít “focus point” hơn.

Hiện tại, tôi xem AI như công cụ thực thi hơn là công cụ tư duy tự chủ, nhưng không biết được tương lai sẽ ra sao khi mà AI ngày càng thông minh hơn.

Công nghệ sẽ luôn thay đổi nhưng giá trị cốt lõi của lập trình vẫn ở đó, hy vọng rằng “những góc nhìn mới về cách tiếp cận” sẽ giúp ích bạn trong hành trình tìm hiểu và phát triển trong lĩnh vực lập trình.

Tác giả: anh Châu Đức Tài – member dự án Easier tại TechX Vietnam