Nói 'viết code chưa bao giờ là việc khó' là một sự xúc phạm đối với lập trình viên

Nghề phát triển phần mềm đang ở giữa một cuộc biến động lớn. Không ai biết cuộc cách mạng AI cuối cùng sẽ đi đến đâu, nhưng rõ ràng nhiều khía cạnh trong công việc và cuộc sống sẽ bị thay đổi—bao gồm cả lập trình.

Một trong những bình luận tôi thường nghe gần đây có thể tóm gọn lại là: “LLMs có thể giỏi viết code, nhưng phần mềm chưa bao giờ là phần khó” và “viết code thì dễ, tìm ra cái gì để viết mới là khó”.

Tôi tin rằng đó là một sự xúc phạm nặng nề đối với tất cả các lập trình viên trên toàn thế giới.

Nếu viết code là dễ...

Nếu viết code là dễ, tại sao các lập trình viên lại được săn đón và đòi hỏi mức lương cao trong nhiều năm (ngay cả trước thời kỳ ZIRP)? Tại sao lại có quá nhiều căng thẳng, làm việc quá sức và kiệt sức ngay cả trước khi AI bắt đầu tạo ra hàng loạt PR dài 5000 dòng? Tại sao các công ty lại tìm kiếm những "ninja rockstar" 10x và bắt họ trải qua các cuộc phỏng vấn leetcode—chẳng phải một nhân viên mới tốt nghiệp đại học có thể làm được nếu nó dễ dàng đến thế sao?

Nếu viết code là dễ, tại sao chúng ta lại có những cuốn sách dày cộp như *Clean Code* và *The Pragmatic Programmer*? Liệu *The Art of Computer Programming* có phải là một cuốn sách đọc giải trí nhẹ nhàng mùa hè? Liệu *SICP* có phải là một cuốn sách để trưng bày trên bàn cà phê? Tại sao chúng ta lại có các khóa bootcamp hay thậm chí là cả bằng đại học dành riêng cho nó?

Nếu viết code là dễ, liệu Carmack chỉ là người gặp thời đúng lúc? Tại sao chúng ta lại coi Fabrice Bellard là một thiên tài?

Nếu viết code là dễ, tại sao mọi người lại tức giận khi AI (hoặc bất kỳ ai khác) sao chép code của họ? Tại sao họ lại hành động như thể họ đã đổ mồ hôi, tâm huyết và vô số thời gian vào một thứ gì đó tầm thường như vậy?

Nếu viết code là dễ, tại sao nhiều người hiện nay cảm thấy bản sắc và mục đích nghề nghiệp của họ đang bị tước đoạt?

Nếu viết code là dễ, tại sao phần mềm lại đầy lỗi đến thế?

Nếu tìm ra cái gì để xây dựng mới là phần khó...

Nếu quyết định xây dựng cái gì mới là phần khó, tại sao nhiều quản lý sản phẩm (product manager) lại có vẻ mù mờ? Tại sao không có các cuộc phỏng vấn khắt khe 10 bước dành cho họ? Tại sao họ không được trả lương cao hơn các lập trình viên?

Nếu quyết định xây dựng cái gì mới là phần khó, tại sao các nhà nghiên cứu thị trường, chuyên gia trải nghiệm người dùng và—chết tiệt, cả bộ phận chăm sóc khách hàng—lại không được coi là những ngôi sao trong một công ty phần mềm? Nếu “thấu hiểu khách hàng” là khó hơn, tại sao các nhà phân tích kinh doanh lại bị coi thường như những kẻ chỉ biết làm công việc giấy tờ?

Nếu việc triển khai là dễ và tìm kiếm nhu cầu là khó hơn, tại sao các lập trình viên lại khó chịu khi nhân viên kinh doanh hứa hẹn một tính năng mới với khách hàng để chốt đơn? Họ đã tìm ra một nhu cầu thực sự, thứ mà mọi người sẵn sàng chi tiền!

Nếu viết code là dễ, tại sao không phải ai cũng xây dựng mười biến thể của một thứ và xem cái nào thành công?

Một bình luận sáo rỗng khác là “phần lớn công việc trong phát triển phần mềm là nói chuyện với các bên liên quan, thấu hiểu nhu cầu của khách hàng và làm rõ các ưu tiên”.

Tôi đã gặp nhiều lập trình viên trong suốt sự nghiệp của mình, và rất ít người trong số họ muốn nói chuyện với các bên liên quan, chứ đừng nói đến khách hàng (ngoại trừ những người làm freelancer và các nhà sáng lập, đặc biệt là các cửa hàng phát triển phần mềm). Và, “làm rõ các ưu tiên” thực chất chỉ tóm gọn lại là “cứ bảo tôi phải làm gì và đừng thay đổi nó mỗi hai ngày”.

Một số nhà phát triển phần mềm nói rằng “Tôi không viết code, tôi giải quyết vấn đề của khách hàng”. Nhưng sau đó họ quay lại và bắt đầu bàn luận về monad, an toàn bộ nhớ và các nguyên tắc DRY, trong khi sự hiểu biết của họ về khách hàng chỉ là một “user persona” giả tạo, và họ nghĩ “affordance” là số tiền mà cha mẹ từng cho bạn vào cuối tuần để bạn có thể đi chơi và vui vẻ.

Những người khác lại nói “Phát triển phần mềm là xây dựng lý thuyết”. Các chương trình thực chất là các chứng minh (như trong chứng minh toán học). Mỗi commit nên kể một câu chuyện. Và việc giải quyết vấn đề của khách hàng bằng cách FTP một file PHP là một tội lỗi tày đình.

Tôi không có ý nói rằng không có những nhà phát triển vừa quan tâm sâu sắc đến kỹ nghệ phát triển phần mềm vừa thực sự đồng cảm với khách hàng. Tuy nhiên, tôi tin rằng họ có thể nên đi khám bác sĩ tâm lý vì chứng rối loạn đa nhân cách.

Điều gì là quan trọng?

Tôi tin rằng việc nói chuyện với người dùng, thấu hiểu trải nghiệm của họ, đồng cảm với họ, giải quyết vấn đề của khách hàng và đảm bảo tất cả các bên liên quan đều có cùng quan điểm là yếu tố then chốt cho sự thành công của một dự án phần mềm.

Tôi cũng tin rằng tạo ra code tốt là một kỹ nghệ đòi hỏi kỹ năng, sự kiên nhẫn, chú ý đến chi tiết, kinh nghiệm và trí tuệ, và nó sẽ tiếp tục phù hợp trong thời gian tới.

¿Por qué no los dos? (Tại sao không phải là cả hai?)

Trong phạm vi chúng ta có thể làm được, tôi nghĩ chúng ta nên hướng tới cả hai. Một sự hiểu biết sâu sắc về hệ thống mà chúng ta đang xây dựng, cùng với sự hiểu biết sâu sắc về lý do tại sao chúng ta xây dựng nó.

Việc lớn tiếng tuyên bố rằng “code là dễ” hoặc ở thái cực ngược lại, “code là nghệ thuật, là sự thể hiện sáng tạo của con người không thể bị tự động hóa”, chỉ là hành động tự lừa dối bản thân.

Đó là cơ chế đối phó. Và bạn không muốn chỉ đối phó, bạn muốn phát triển.

Ý tôi ở đây không phải là “hùa theo trào lưu LLM”. Tôi không có ý nói “hãy trở thành người quản lý các đội ngũ AI agent”. Tôi cũng không có ý nói “code do AI tạo ra là rác rưởi bị đánh cắp, hãy chiến đấu với nó đến cùng, dù sao thì bong bóng cũng sẽ sớm vỡ thôi”.

Nhưng hãy nhận thức rằng chúng ta đang ở giữa một sự thay đổi mang tính kiến tạo trên toàn ngành. Chúng ta cần tìm cách thích nghi. Chúng ta cần hiểu điều gì có khả năng thay đổi và điều gì không bao giờ thay đổi.

Điều gì không thay đổi?

Phần mềm sẽ ngày càng phức tạp hơn. Phần mềm sẽ luôn cần bảo trì: bit-rot là một thực tế của cuộc sống. Entropy cũng vậy. Công nghệ (phần cứng và phần mềm) sẽ tiến về phía trước, dù tốt hay xấu. Tòa tháp (hay tòa nhà chọc trời?) của các lớp trừu tượng ngày càng cao hơn.

Người dùng sẽ luôn muốn nhiều hơn và sẵn sàng chi ít hơn. Họ vẫn sẽ không biết cách truyền đạt nhu cầu và mong muốn của mình. Tệ hơn nữa, họ vẫn sẽ không biết chính xác mình muốn gì. Sự ngắt kết nối giữa khách hàng (những người thực sự trả tiền cho phần mềm) và người dùng (những người sử dụng nó) vẫn sẽ tồn tại, cũng như sự căng thẳng giữa nhu cầu của doanh nghiệp và nhu cầu của khách hàng.

Ngoài ra: sẽ không bao giờ thiếu những kẻ bán thuốc dạo. Công nghệ thời thượng đến rồi đi (tôi vẫn đang chờ đợi sự phục hưng mới của VR!).

Điều gì thay đổi?

Các lập trình viên đã tham gia vào việc phá vỡ ngành công nghiệp của chính mình ngay từ đầu. Không ai còn sử dụng thẻ đục lỗ nữa. Rất ít người cần viết code bằng assembly hoặc COBOL. Những thập kỷ dành để chiến đấu với các lỗi bộ nhớ trong C hoặc C++, với những vết sẹo để chứng minh điều đó, trở nên vô giá trị trong thời đại của Rust, Go, Python và JavaScript.

Tôi đủ già để trân trọng valgrind hoặc nhớ mysql_real_escape_string từ thời PHP4—những thứ mà tôi sẽ không bao giờ cần đến nữa trong đời. Và điều đó thậm chí chưa lâu lắm! Tôi suýt bỏ lỡ kỷ nguyên dBase, Clipper, HyperCard và Access, những công nghệ mà tôi vẫn có thể thấy đang hoạt động trong các cửa hàng, quán cà phê, hoặc trong một chiếc máy tính midi-tower đầy bụi bặm, từng có màu be nay đã chuyển sang màu nâu vàng, vẫn đang vui vẻ chạy một giải pháp kinh doanh tùy chỉnh nào đó (sao lưu ư? sao lưu là gì?)

Làm thế nào để chúng ta phát triển?

Hãy chấp nhận rằng sự thay đổi là điều tất yếu. Hãy vừa tò mò vừa có tư duy phản biện về những thứ mới.

Hãy hiểu rằng có rất nhiều sự thổi phồng và cố gắng phân biệt giữa những lời quảng cáo sáo rỗng với những gì thực sự hiệu quả (và ở mức độ nào). Ngoài ra, hãy nhận thức về những mục tiêu luôn thay đổi: hãy lùi lại và nhìn vào năm vừa qua, hoặc năm năm qua, và đánh giá tốc độ thay đổi (về kỹ thuật, kinh tế, xã hội).