Tại sao các Senior Developer thường thất bại trong việc truyền đạt chuyên môn?

Bạn cảm thấy thế nào về câu nói này: "Các tác nhân AI là tương lai của phát triển phần mềm. Chúng ta sẽ không còn cần các lập trình viên để làm chậm tiến độ kinh doanh của doanh nghiệp nữa."

Nếu bạn là một Senior Developer và bạn nghĩ điều này là đúng, tôi hơi nghi ngờ về chuyên môn của bạn (tôi sẽ giải thích tại sao, tôi không cố tình gây hấn). Nhưng nếu bạn không phải là Senior Developer và bạn nghĩ điều này là đúng, tôi nghĩ bạn có lẽ đã đúng.

Hử? Điều gì đang xảy ra ở đây?

Viết quảng cáo, về bản chất, là việc khớp một thông điệp với đúng đối tượng. Vì vậy, đối với tôi, một người làm nghề copywriting, điều đang xảy ra ở đây là cùng một thông điệp lại mang hai ý nghĩa khác nhau cho hai đối tượng khác nhau.

Nếu bạn là một Senior Developer, nếu bạn đã từng thử nghiệm các tác nhân, kỹ năng và mô hình AI và tất cả những thứ khác đang làm mưa làm gió, và nếu trực giác của bạn vẫn mách bảo rằng có điều gì đó không ổn khi mọi người tuyên bố công việc của bạn lỗi thời, thì ở đây, trong bài viết này, tôi sẽ cố gắng diễn đạt trực giác đó thành lời (như một copywriter giỏi sẽ làm).

Nhưng khoan đã! Nhiều nhà phát triển dày dạn kinh nghiệm và nổi tiếng cũng đang tuyên bố về cái chết của lập trình viên.

Thế là sao? Trực giác của ai là đúng? Và điều gì đang gây ra sự chia rẽ này?

Khi gia nhập một đội nhóm, tôi thường gặp hai loại Senior Developer.

Loại đầu tiên thường nói những điều như: "Tôi tìm thấy công cụ mới này và nó khá ngầu..." "Công ty này làm việc theo cách này, nên..." "Đây, xem bài đăng trên HackerNews này nói rằng đây là phương pháp tốt nhất, chúng ta có lẽ nên..."

Tôi không thích loại Senior Developer này. Họ hơi tự bảo vệ mình, dành nhiều thời gian trong ngành, có lẽ là người biết đối nhân xử thế tốt. Nhưng không hợp tần số của tôi.

Sau đó còn có loại Senior Developer này: "Chúng ta có thực sự cần cái đó không?" "Điều gì sẽ xảy ra nếu chúng ta không làm điều này?" "Chúng ta có thể tạm dùng cái được không? Có lẽ sẽ quay lại sau khi nó trở nên quan trọng hơn?"

À, đây mới là Senior Developer kiểu tôi. Người né tránh, người giảm thiểu, người tái chế. Họ muốn tránh phát triển phần mềm càng nhiều càng tốt.

Tại sao ư? Bởi vì họ đang săn lùng một con quái vật duy nhất trong phát triển phần mềm chuyên nghiệp: độ phức tạp (complexity).

Các trường hợp đặc biệt, các câu lệnh if, các bảng cơ sở dữ liệu mới, các thành phần mới. Tất cả đều là những thứ "yuck". Senior Developer muốn càng ít những thứ này càng tốt, họ dành nhiều thời gian để đảm bảo rằng họ thực sự cần thêm mã.

Bởi vì thêm vào một hệ thống là đang mạo hiểm gia tăng độ phức tạp.

Vâng, vâng, tất nhiên điều này là đơn giản hóa. Có những Senior Developer xuất sắc trong việc giải quyết các vấn đề chưa được giải quyết và tìm ra các thiết kế sáng tạo mới. Nhưng cuối cùng, nếu bạn chịu trách nhiệm cho một hệ thống đang hoạt động, bạn sẽ sợ độ phức tạp.

Vậy tại sao lại như vậy? Điểm bất lợi của độ phức tạp là gì? Và tại sao không ai khác hiểu điều đó?

Chúng ta sẽ đơn giản hóa một doanh nghiệp bằng cách sử dụng hai vòng lặp.

Đây là vòng lặp đầu tiên; các nhà tiếp thị, nhân viên bán hàng, quản lý sản phẩm, CEO, tất cả họ sống ở đây:

Vòng lặp kinh doanh và sự không chắc chắn

Mục tiêu chính của vòng lặp này là cố gắng học hỏi. Doanh nghiệp muốn đưa sản phẩm ra thị trường và sau đó nhận được phản hồi xem họ có thứ gì giá trị hay không.

Con quái vật, đối với những người ở vòng lặp này, là sự không chắc chắn (uncertainty).

Và sự không chắc chắn là tàn nhẫn vì không có chiến lược nào được đảm bảo sẽ thành công. Khi kết hợp với thời gian (chi phí cho tiếp thị/bán hàng, hoặc lương cho các nhà sáng lập, hoặc dữ liệu cho quản lý sản phẩm), việc đưa sản phẩm ra thị trường càng nhanh càng tốt có thể cảm thấy như là cách duy nhất để giảm sự không chắc chắn trước một thời hạn. Bạn càng đưa ra thị trường nhiều, bạn càng nhận được nhiều phản hồi, và bạn càng có thể (tiềm năng) giảm bớt sự không chắc chắn.

Vòng lặp này, và tất cả các công ty đều bắt đầu với vòng lặp này, là về tốc độ thuần túy, thô sơ.

Nhưng điều gì sẽ xảy ra khi một doanh nghiệp có được khách hàng?

À, bây giờ, đây là vòng lặp thứ hai của chúng ta. Những người trả tiền cho dịch vụ.

Vòng lặp này là nơi nhiều Senior Developer tìm thấy mình. Mục tiêu chính ở vòng lặp này là sự duy trì và đảm bảo dịch vụ.

Giữ mọi thứ hoạt động, giữ mọi thứ có thể hiểu được, giữ mọi things có thể gỡ lỗi (debuggable), giữ mọi thứ có thể sửa chữa, giữ mọi thứ có thể dạy được, và giữ mọi thứ ổn định.

Senior Developer lo lắng về sự ổn định vì họ chịu trách nhiệm để doanh nghiệp tiếp tục phục vụ khách hàng.

Và điều gì gây rủi ro cho tất cả những điều đó?

Độ phức tạp.

Nó làm cho hệ thống ít dễ hiểu hơn, ít dễ gỡ lỗi hơn, ít dễ sửa chữa hơn, ít dễ dạy hơn, và cuối cùng, ít ổn định hơn.

Độ phức tạp tăng = sự ổn định giảm = Senior Developer thất bại trong trách nhiệm = xấu xí, thanh toán bị gián đoạn, mọi người buồn.

Vì vậy, nếu mục tiêu của vòng lặp đầu tiên là giảm sự không chắc chắn, thì mục tiêu của vòng lặp thứ hai là quản lý độ phức tạp.

Nhưng tại sao điều này lại dẫn đến thất bại trong giao tiếp?

Bởi vì một khi bạn có khách hàng, cả hai vòng lặp đều chạy đồng thời. Một doanh nghiệp cần cả việc khám phá các khả năng và phục vụ khách hàng cùng một lúc.

Được rồi, bây giờ bạn có thể nhận ra câu trả lời của tôi cho câu hỏi trong tiêu đề bài viết này.

Tùy thuộc vào việc bạn dành thời gian ở vòng lặp nào, vấn đề của bạn được định hướng khác nhau (đó là lý do tôi nghĩ các nhà phát triển bị chia rẽ trong quan điểm về AI; một số làm việc nhiều hơn ở một vòng lặp hơn vòng lặp kia).

Đây là câu chuyện của những người ở vòng lặp đầu tiên:

Nhưng đây là câu chuyện của Senior Developer ở vòng lặp thứ hai:

Các câu chuyện không khớp nhau.

Càng có nhiều yêu cầu xây dựng và thêm vào hệ thống, Senior Developer càng muốn phản hồi bằng "ừmmm, không, độ phức tạp... chi phí bảo trì... tính dễ hiểu... tốc độ phát triển liên tục... năng suất theo thời gian...".

Nhưng điều đó không giải quyết được nhu cầu giảm sự không chắc chắn của phần còn lại của doanh nghiệp.

Chẩn đoán của copywriter: Bạn không thể giải thích vấn đề của người khác bằng chính vấn đề của bạn.

Và đơn thuốc của copywriter: Bạn cần mô tả giải pháp của mình như một giải pháp cho vấn đề của họ.

Senior Developer thất bại trong giao tiếp vì họ diễn đạt vấn đề của mình theo hướng quản lý độ phức tạp trong khi họ nên diễn đạt giải pháp của mình theo hướng giảm sự không chắc chắn.

Bằng cách thừa nhận rằng những gì phần còn lại của công ty đang tìm kiếm là giảm sự không chắc chắn, Senior Developer có thể sử dụng chuyên môn của mình để giúp đỡ.

Và kỹ năng hữu ích nhất của một Senior Developer là gì? Sự miễn cưỡng xây dựng những thứ không cần thiết; khả năng phát hiện cơ hội để tái sử dụng thứ gì đó đã được xây dựng.

Cần thu thập dữ liệu khảo sát? Google Forms, baby.

Cần xây dựng một tính năng hoàn toàn mới để kiểm tra nó? Bạn đã thử đặt một nút bấm trong giao diện người dùng (UI) hiện có chưa và xem liệu người có nhấn vào nó không?

Cần dịch vụ phân tích mới? Quyết định quan trọng nhất mà chúng ta cần phân tích là gì? Chúng ta có thể bắt đầu với một quyết định, một biểu đồ, một chỉ số không?

Bạn muốn nướng cho tôi cả một chiếc bánh sinh nhật? Chỉ cần đặt một cây nến lên bánh mì kẹp của tôi.

Đây là điều Senior Developer học được: họ học cách đưa cho người khác những gì họ muốn bằng cách khéo léo sử dụng phần mềm hiện có.

Nhưng làm thế nào để bạn truyền đạt điều này mà không gửi cho họ những bài luận dài dòng?

Copywriter thích chắt lọc nhiều tín hiệu thành các cụm từ đơn lẻ. Và vì vậy, đây là cụm từ ma thuật mà mọi Senior Developer phải học: "Liệu chúng ta có thể thử cách nào nhanh hơn không?"

Việc sử dụng từ "nhanh hơn" thừa nhận những gì họ thực sự tìm kiếm; "cách nào" ngụ ý một cách khác để đạt được nó; "thử" ngụ ý sự không hoàn hảo, nhưng cũng là khả năng nó đủ tốt.

Nó cắt giảm chính xác yêu cầu của phần còn lại của công ty, tốc độ để giảm sự không chắc chắn, đồng thời cho phép Senior Developer thể hiện chuyên môn của họ: giảm thiểu, tái sử dụng, và nếu cuộc đời thực sự ban phước, thì né tránh.

Đó là nó. Đó là câu trả lời của tôi cho tiêu đề bài viết: Senior Developer nói về độ phức tạp khi mọi người khác lo lắng về sự không chắc chắn.

Nhưng! Nhưng lớn!

AI dường như làm cho tất cả những điều này trở nên vô nghĩa, phải không? Tại sao phải giảm thiểu? Tại sao phải tái sử dụng? Tại sao phải né tránh? AI có thể xây dựng rất nhiều thứ trong rất ít thời gian.

À, vâng, nó vẫn chưa thể làm một điều mà Senior Developer vẫn làm.

Chịu trách nhiệm.

Senior Developer rất quan tâm đến việc hiểu hệ thống vì sự hiểu biết cho phép sửa chữa nó khi có sự cố. Nó cho phép mở rộng nó một cách thông minh khi hệ thống cần phát triển. Nó cho phép, hơn bất cứ điều gì, việc phục vụ khách hàng trả tiền một cách liên tục, đáng tin cậy.

AI đe dọa tính dễ hiểu này. Nó đáng kinh ngạc trong việc cải thiện tốc độ đưa sản phẩm ra thị trường, nhưng nó cũng ảnh hưởng đến vòng lặp kia, vòng lặp mà Senior Developer chịu trách nhiệm.

Nếu bạn có một loạt các tác nhân AI, lập trình viên junior, người không phải lập trình viên, và các nhà đầu tư cùng mẹ của họ thêm mã vào hệ thống, bạn sẽ nhận được một hệ thống bù đắp quá mức cho tốc độ bằng cách đánh đổi sự ổn định.

Đây là doanh nghiệp trong hai vòng lặp:

Và đây là cách AI ảnh hưởng đến hai vòng lặp:

Tác động của AI lên sự ổn định

Quên việc duy trì sự ổn định, AI là một tác nhân gây mất ổn định trực diện. Nó làm giảm tính dễ hiểu, khả năng sửa chữa, khả năng gỡ lỗi, khả năng dạy, khả năng đảm bảo, tất cả những thứ "bility" tạp nhạp.

AI làm điều này và không chịu trách nhiệm.

Không hay chút nào. Đây là mối lo ngại chính của Senior Developer đang bị gạt sang một bên.

May mắn thay, Senior Developer có vài thủ thuật trong tay áo.

Cụ thể là: giải耦 (decoupling).

Trong một thời gian dài, chỉ có các nhà phát triển phần mềm mới có thể xây dựng phần mềm. Họ chịu trách nhiệm cho cả hai vòng lặp.

Đó là một hệ thống hỗ trợ hai mục tiêu.

Nh如果我们 có hai hệ thống, một cho mỗi mục tiêu thì sao?

Một ví dụ: một nhà văn hư cấu vội vàng hoàn thành bản nháp đầu tiên (thường được gọi là bản nháp "nôn mửa") và sau đó trích xuất những gì hoạt động và loại bỏ những gì không. Có một quy trình biên tập sau khi viết nhanh ban đầu. Công việc của biên tập viên là lấy những phần hoạt động tốt và định hình tất cả thành một thể thống nhất.

Nếu chúng ta có một hệ thống chỉ dành cho tốc độ thì sao? Mọi người tập trung vào đưa mọi thứ đến đời có thể làm việc ở đây. Các tác nhân AI, mã do chính chúng ta tạo ra và chưa được xem xét, junior dev, tiếp thị, v.v.

Chúng ta có thể gọi đây là phiên bản "Tốc độ" (Speed) của hệ thống. Nó không có nghĩa là dễ hiểu, mục tiêu là đưa mọi thứ đủ tốt để đưa ra thị trường để nhận phản hồi.

Và sau đó nếu chúng ta có một hệ thống thứ hai tập trung vào sự ổn định thì sao?

Chúng ta có thể gọi đây là phiên bản "Mở rộng" (Scale) của hệ thống. Nó được thiết kế bởi các Senior Developer để ổn định, dễ hiểu và có thể mở rộng.

Phiên bản "Tốc độ" cho phép phần còn lại của doanh nghiệp tiếp tục học hỏi từ thị trường, trong khi các Senior Developer xây dựng một phiên bản theo sau của hệ thống được xem xét kỹ lưỡng và dễ hiểu.

Hơn nữa, thiết kế của phiên bản 'Mở rộng' chịu ảnh hưởng bởi những gì hoạt động và những gì không hoạt động trong phiên bản 'Tốc độ' của hệ thống.

Các tính năng được xây dựng trên 'Tốc độ' nhưng sau đó được ổn định trên 'Mở rộng'.

Trong thực tế, điều này trông như thế nào có thể chưa rõ ràng, nhưng ý tưởng là có một sự giải耦 được truyền đạt tốt giải thích rằng có sự khác biệt giữa việc hướng tới tốc độ và hướng tới sự ổn định.

Hãy tưởng tượng bạn được yêu cầu xây dựng điều gì đó tham vọng, và bạn nói:

"Chắc chắn, tôi sẽ có phiên bản Tốc độ sẵn sàng trong 3 ngày. Sau đó phiên bản Mở rộng trong khoảng 6 tuần."

Họ nhận được những gì họ muốn, tốc độ và đà phát triển. Bạn nhận được những gì bạn muốn, quan sát và thiết kế.

Có lẽ không?

Ý kiến của bạn, Senior Software Developer?

Hay tôi nên gọi là, Senior Software Editor?