- Khi lặp đi lặp lại những tự động hóa nhỏ nhặt, đến một lúc nào đó ta sẽ chạm tới ngưỡng nhận thức nơi mọi công cụ và hệ thống đều trông như đối tượng cần phải sửa
- Càng tích lũy năng lực kỹ thuật, ta càng không chỉ nhận ra vấn đề mà còn mang theo sức nặng cảm xúc khiến nó giống như một trách nhiệm
- Ham muốn sửa chữa không chỉ vượt quá việc cải thiện năng suất đơn thuần mà đôi khi còn trở thành phương tiện điều tiết cảm xúc, và có lúc dẫn tới kết quả tự mắc kẹt trong chính hệ thống mình tạo ra
- Hệ thống theo thời gian chắc chắn sẽ hỏng, và ảo tưởng về một giải pháp hoàn hảo không hề tồn tại
- Cuối cùng, kỹ năng thực sự cần thiết không phải là khả năng sửa mọi thứ, mà là sự thư thả trong tâm trí để chịu đựng được mà không cần sửa một điều gì đó
Khởi đầu từ những tự động hóa nhỏ
- Bắt đầu từ những cải thiện năng suất nhỏ như script Python đổi tên file hay rút gọn lệnh
git - Sau khi tự tay sửa những bất tiện trong hệ thống, mọi thứ trên đời bắt đầu trông như đối tượng cần được cải thiện
- Từ một thời điểm nào đó, nó vượt khỏi “mình có thể làm” và chuyển thành cảm giác cưỡng bách đạo đức rằng “mình phải làm”
Sức nặng của năng lực kỹ thuật
- Trước khi biết lập trình, ta có thể bỏ qua phần mềm bất tiện, nhưng giờ đây các vấn đề hiện ra rõ mồn một
- Những đoạn code cẩu thả hay cấu hình hard-code do developer tạo ra gợi cảm giác như một lời buộc tội
- Một sự chuyển đổi nhận thức diễn ra khi mọi hệ thống và phần mềm đều hiện lên như danh sách TODO cần phải sửa
Cuộc đời refactor không hồi kết
- Hết lần này đến lần khác, suy nghĩ “cái này mình có thể làm tốt hơn” khiến ta sa vào việc tự phát triển công cụ của riêng mình
- Những thư mục code chưa được sắp xếp, vô số lần thử rồi bỏ cuộc, và việc tái thiết kế cấu trúc không có điểm dừng đôi khi trở thành một dạng lao động tự trói buộc
- Giống như ẩn dụ của Kafka về việc “xây lồng rồi chờ chim đến”, ta có thể bị cuốn vào việc làm công cụ không mục đích
Phần mềm sẽ mục ruỗng
- Ngay cả script từng có vẻ hoàn hảo rồi cũng sẽ trở nên vô dụng vì những thay đổi từ bên ngoài
- Như thay đổi bố cục website, thay đổi phiên bản package, lỗi dependency, v.v.
- Khi sự cố xảy ra, ta không chỉ thấy bất tiện mà còn cảm thấy tội lỗi
- Cuối cùng ta phải đối mặt với thực tế rằng cần có sự bảo trì liên tục
Ảo tưởng mang tên tự động hóa
- Ta thường ôm lấy hy vọng giả tạo rằng “chỉ cần setup một lần là sau đó không phải đụng tới nữa”
- Ta nghĩ lập trình là một chiến thắng trong giải quyết vấn đề, nhưng thực ra nó chỉ là một cuộc chiến không có hồi kết
- Không hề có khái niệm hoàn tất, mà chỉ là đào những chiến hào luôn bị ngập nước
Khi coding trở thành công cụ điều tiết cảm xúc
- Hành vi làm ra công cụ đôi khi là phản ứng tâm lý nhằm kiểm soát sự hỗn loạn của cuộc sống
- Hệ thống càng phức tạp thì nghịch lý thay, ta lại càng cảm thấy bản thân được sắp xếp ổn thỏa
- Để né tránh một cuộc sống rối ren, ta thử tạo app mới hoặc refactor, và nhờ đó tự xoa dịu bản thân
Burnout đến không báo trước
- Burnout không chỉ bắt nguồn từ làm việc quá sức mà còn từ cảm giác trách nhiệm quá mức
- Sự tự trách kiểu “mình sửa được mà, sao lại không sửa?” khiến căng thẳng càng chồng chất
- Cảm giác trách nhiệm kỹ thuật vô tận trở thành gánh nặng mang tính tự hủy hoại
Học kỹ năng buông xuống
- Không cần phải giải quyết mọi vấn đề
- Đôi khi, biết rằng có những thứ không cần sửa mới là một dạng kiểm soát lớn hơn
- Thừa nhận khiếm khuyết và cứ thế sử dụng cũng có thể là một lựa chọn có ý thức
Kỹ năng thật sự là sự minh định cảm xúc
- Quan trọng hơn kỹ năng sửa chữa là kỹ năng tinh thần để không phải sửa
- Khả năng phân biệt khi nào nên dừng lại, và dự án nào chỉ là để tự an ủi bản thân
- Cần thoát khỏi ám ảnh phải sửa mọi thứ, và nuôi dưỡng thái độ tìm thấy sự bình yên ngay trong sự không hoàn hảo
Cuối cùng, kỹ năng khó nhất trong lập trình là
"học cách cứ để thứ đang hỏng yên đó"
21 bình luận
Mọi thứ đều có mục đích. Nếu đã đạt được mục đích thì không cần tiếp tục sửa nữa. Nhưng nếu vẫn chưa đạt được mục đích thì phải sửa.
Có lẽ điểm khởi đầu là xác định rõ mục đích của dự án.
Cứ nghĩ rằng trên đời này có cả những công ty được định giá tới hàng nghìn tỷ won chỉ nhờ việc gom lại và sắp xếp đống API lộn xộn của các ngân hàng và bên thanh toán là sẽ thấy nhẹ lòng hơn thôi, haha
Ku x..
Nếu nhìn thấy một hệ thống được tạo bằng VB 6.0 và COM + OLE + ActiveX mà vẫn đang chạy ngon lành rồi hoảng hốt đến mức nảy sinh ham muốn viết lại nó, thì bạn là người sẽ phải chịu khổ.
Rốt cuộc, kỹ năng khó nhất trong lập trình là
học được cách "cứ để yên thứ đang hỏng"
Rất đồng cảm. Tôi là kiểu người hay bày thêm việc nên lúc nào cũng vất vả...
Một kiểu tự động hóa được một lập trình viên bình thường chắp vá lại thì đương nhiên sớm muộn cũng sẽ hỏng thôi.
Nội dung hay
Cháy sạch đến mức thành tro
: khi vất vả tự động hóa công việc xong thì người hưởng lợi lại là đồng nghiệp bên cạnh, còn bản thân thì bị điều sang tự động hóa những công việc khác;
Tôi là một trong những kẻ bị gọi là
ăn lươngvì đã mất 2 ngày để tự động hóa một việc vốn chỉ mất 15 phút.Tinh thần trách nhiệm quá mức gần như là bệnh nghề nghiệp của lập trình viên, nên phải giải quyết bằng hệ thống.
Đội Quality Assurance phải đảm nhiệm việc đó chứ.
QA có thể giúp kiềm chế cảm giác trách nhiệm quá mức của lập trình viên sao? Tôi vẫn chưa hiểu lắm.
Khi liên tục bị truy xét lỗi và nghe rằng “bạn code sai rồi”,
nhà phát triển sẽ bị đè nặng bởi cảm giác trách nhiệm nên ngại thử những điều mới
rồi cuối cùng chỉ viết những đoạn mã an toàn, không có tiến bộ.
Đó chính là ý nghĩa của việc QA phải đảm bảo.
Muốn lập trình theo hướng phát triển thì tất yếu phải chấp nhận một mức độ rủi ro nhất định,
và QA phải là bên kiểm chứng cũng như chịu trách nhiệm cho điều đó.
Có thể đọc bài này theo cách đó nữa sao? Nếu nhất định phải phân loại thì tôi lại nghĩ đây là một bài viết phê phán việc yak shaving.
Đúng như roxie đã nói, phần trao đổi về bài viết thực ra là nói về chuyện yak shaving,
nhưng khi đối chiếu với trải nghiệm cá nhân của tôi thì câu chuyện lại thành ra hơi khác với nội dung bài viết.
Có thể cũng giải thích bằng hiện tượng NIH (not invented here) phải không? Tôi nghĩ không nên quên rằng bảo trì đồng nghĩa với chi phí cố định, và trong chi phí đó cũng bao gồm cả công sức của con người.
Để làm việc này lâu dài, có lẽ cũng cần tập buông bớt gánh nặng của trách nhiệm và cảm xúc trước khi rơi vào cái vòng luẩn quẩn của tâm lý tự bù đắp do ý thức trách nhiệm quá mức.
Bản thân tôi cũng là kiểu không điều chỉnh tốt được chuyện này haha... nội dung hay đấy
Tôi nghĩ đây là một điểm rất hay. Vì trách nhiệm, đúng như nghĩa đen của nó, là cảm thấy mình có trách nhiệm, nên tự bản thân nó không đòi hỏi sự đền đáp. Nhưng theo thời gian, trong khi cơ thể và tinh thần dần kiệt sức thì cảm giác trách nhiệm lại không dễ biến mất, và để lấp đầy khoảng cách đó, có lẽ ta bắt đầu mong chờ sự đền đáp (dù thực ra không nên nối hai điều đó với nhau như vậy). Ngay cả khi bản thân cũng không nhận ra.
Ừ thì, có lẽ điểm thỏa hiệp còn đỡ hơn việc "cứ để thứ bị hỏng yên đó" là "đừng đụng vào cho tới khi nó hỏng" :)
Ý kiến trên Hacker News
Có một câu nói tôi học được khi làm sân khấu. Nó giải thích quá trình của nghệ thuật là biến điều khó thành thói quen, biến điều theo thói quen thành dễ dàng, và biến điều dễ dàng thành đẹp đẽ
Đưa ra ý kiến cá nhân về các vấn đề UI
Bày tỏ khó khăn với các dự án cá nhân
Bày tỏ sự tôn trọng đối với các kỹ sư phần mềm
Đưa ra phê bình về chủ nghĩa hoàn hảo
Chia sẻ những nhận thức cá nhân
Đề cập rằng gia đình và con cái giúp giải quyết chủ nghĩa hoàn hảo
Tự tay viết phần mềm thú vị hơn và mang lại những giải pháp đơn giản hơn
Lập luận rằng văn hóa ám ảnh với cái mới là gốc rễ của vấn đề
Các nhà tâm lý học phân loại con người thành những người tối đa hóa và những người tìm kiếm thứ đủ tốt
Câu "biết cách bỏ mặc những thứ bị hỏng" có lẽ không phù hợp bằng "biết cách buông bỏ những thứ không quan trọng"
Những gì nhất định phải sửa thì vẫn phải sửa thôi
Tôi đồng cảm. Tôi nghĩ cần tự biết rõ liệu mình đang làm cho khu vườn đẹp hơn, hay thực sự đang làm công việc quan trọng, rồi biết lúc nào nên buông xuống.