Tôi có một vài trải nghiệm với “mã tệ”. Nhiều khi tôi làm việc một mình, nhưng cũng có lúc trong nhóm tôi viết những đoạn mã tuy chạy được nhưng không tối ưu. Khi cố refactor mã cũ cùng với công việc mới, tôi thường bị từ chối; những phần refactor hoặc sửa chữa cần thiết dù được tạo ticket thì thường cũng bị đẩy lùi ưu tiên hoặc bị bỏ qua.
Nếu làm một mình, bạn có thể đưa việc cần làm vào danh sách ưu tiên, nhưng trong nhóm, những quyết định hạng hai có thể tồn tại mãi mãi hoặc bị bỏ mặc cho đến khoảnh khắc “hệ thống sập”. Sau đó, trong phần phân tích hậu sự cố, khi chỉ vào ticket đã yêu cầu sửa quả bom đó từ vài tháng trước, việc này lại bị xem là “đổ lỗi” hoặc “công kích”; rốt cuộc giải pháp dường như trở thành không bao giờ viết mã hạng hai, khiến việc lập trình càng thêm bực bội và lo âu.
Năm 2017, tôi thậm chí còn được liên hệ để sửa đoạn mã viết từ năm 2003/2004, và đoạn mã đó vẫn đang chạy trong production. Nhìn lại những đoạn mã hỏng và những chỗ từng thỏa hiệp, rồi nhận ra người chịu trách nhiệm chính là mình, là một trải nghiệm khá khiến người ta khiêm tốn; sau đó quan điểm của tôi về mã có thể bảo trì và tài liệu hóa đã thay đổi rất nhiều.
Còn tùy vào nhóm và công ty. Tôi đã trải qua nhiều nhóm nơi developer được khuyến khích dành thời gian bảo trì mã và refactor, đôi khi còn bị bắt chỉ làm việc đó; công việc thiên về kỹ thuật được ưu tiên hơn các yêu cầu sản phẩm ngẫu hứng, và lịch trình cũng được điều chỉnh để làm cho xong tử tế.
Từ các tập đoàn lớn thuộc S&P 500, công ty quy mô 100 triệu đến 1 tỷ USD, cho tới startup, những trải nghiệm như vậy với tôi là khá bình thường. Trong các trường hợp này, có những kỹ sư phần mềm và quản lý dày dạn biết đưa ra thỏa hiệp hợp lý và vẫn chăm lo nhu cầu kinh doanh; kỹ sư cũng thường xuyên tương tác trực tiếp với khách hàng.
Điều cốt lõi là sự cân bằng, và sự cân bằng đó thường được tạo ra bởi những người có khả năng phán đoán cân bằng. Nếu chỉ theo đuổi “hoàn hảo”, bạn sẽ rơi vào refactor bất tận và không bao giờ ra mắt; còn nếu phớt lờ nợ kỹ thuật hoặc chất lượng rác, theo thời gian doanh nghiệp có thể sụp đổ. Nên đứng ở đâu còn tùy vào sản phẩm, ngành, khách hàng và mô hình kinh doanh.
Hoặc là chết như một anh hùng, hoặc là sống đủ lâu để nhìn thấy tên mình trong git blame của đoạn mã 10 năm tuổi.
“Chạy được nhưng không tối ưu” thường là một thỏa hiệp chấp nhận được khi thiếu thời gian và có quá nhiều việc phải làm. Những khẩu hiệu kiểu MBA như “hoàn hảo là kẻ thù của cái tốt” cũng là câu có thể đem ra dùng khi còn thiếu thứ gì đó.
Việc năm 2017 bạn được gọi đi sửa mã viết từ năm 2003/2004 cũng có nghĩa là tất cả chúng ta đều là người du hành thời gian. Ta rộng lượng với bản thân trong quá khứ và hơi bất lịch sự với bản thân trong tương lai.
Tôi của quá khứ trẻ và ngây thơ, nhưng năng suất, và đã vượt qua rất nhiều ngọn núi. Mất hai ngày để hiểu lại mã, nhưng cuối cùng nó khá thông minh; có khi việc tôi của hiện tại quên sạch chỉ là do trí nhớ kém.
Tôi của tương lai sẽ sửa mọi sai lầm. Tôi tin rằng người đó già hơn, khôn ngoan hơn, có vô hạn thời gian để biến XXX và TBD thành mã thông minh, triển khai những ý tưởng hay và triển khai lại những ý tưởng chỉ tàm tạm. Nếu có comment tốt hơn, có lẽ cả ba phiên bản tôi sẽ trở thành một.
Tôi cho rằng thái độ kiểu “một người chính nghĩa đó” là có hại. Việc một developer senior có thể nói về những sai lầm mình đã mắc và những việc mình làm hỏng là điều rất giải phóng và lành mạnh.
Nó không chỉ là cơ hội học hỏi đơn thuần, mà còn thể hiện văn hóa cởi mở và có tác dụng chống lại hội chứng kẻ mạo danh. Thái độ cầu toàn thì ngược lại, chỉ là “hãy cố hơn để đừng mắc lỗi”, không có gì để học mà chỉ đòi hỏi thêm nỗ lực cá nhân.
Ít nhất hai lần, tôi đoán rằng “người đó” đã không thừa nhận sai lầm lớn, né tránh dù phải mất khách hàng tốt, và có lẽ còn nói xấu sau lưng.
Một lần, tôi nhận thay một lỗi nhỏ của một junior khi họ đưa sai phiên bản phần mềm vào báo cáo; lẽ ra chỉ cần nói với khách hàng rằng “đã có lỗi và đây là báo cáo đã sửa”, nhưng sếp tôi chỉ nghĩ “liệu có thể giấu chuyện này và giữ thể diện rằng chúng ta hoàn hảo không?”. Cũng chính người đó lại dùng sai lầm của người khác như cơ hội để đòi giảm giá, bồi thường hoặc cung cấp miễn phí.
Tôi nghĩ phần lớn mọi người đang làm việc của mình và dần tốt hơn. Trong phần quản lý cấu hình của chúng tôi có khá nhiều thứ do tôi viết, về mặt chức năng thì chạy ổn, nhưng sau khi dùng công cụ đó 1–2 năm, tôi bắt đầu gọi chất lượng của chúng là khá tệ vì nhiều lý do.
Nhưng như vậy vẫn ổn. Khi có lý do để thay đổi thì ta dọn dẹp; cho đến lúc đó, chúng vẫn là ví dụ cho thấy thực hành xấu và cách tiếp cận tốt hơn.
Nếu bạn không tìm thấy điều gì để phê bình ở chính mình, nghĩa là bạn không tiến bộ. Khi chia sẻ kiểu tự phê bình đó, người khác cũng học được từ sai lầm của bạn và biết rằng học từ sai lầm của chính họ là điều bình thường.
Trong code review, tôi thường nghe những câu như “sao cứ không mắc lỗi đó là được mà?” hoặc “sao không cứ làm thế này?”.
Dạo này tôi đáp: “Chắc là vì IQ của bạn cao hơn tôi. Tôi IQ thấp nên phải làm những việc ngu hơn và đơn giản hơn.” Khi đó đôi khi đối phương đỏ mặt vì nhận ra mình vừa cư xử như một gã lập dị nhỏ nhen, hạ thấp người khác mà không hề tự xét lại.
Tôi hơi dị ứng với các câu hỏi bắt đầu bằng “sao không cứ …?”. Chỉ nghe ba từ đó là tôi thường đoán được đề xuất phía sau; không phải vì nó cực kỳ phức tạp, mà vì đó thường là cách hiển nhiên đầu tiên hiện ra trong đầu, và đã được cân nhắc kỹ hoặc thử rồi.
Bản thân câu hỏi không xấu, nhưng tiền đề “ý tưởng của tôi quá dễ” và “bạn đã không nghĩ ra ý tưởng hiển nhiên, dễ dàng này” có thể gây khó chịu hoặc xúc phạm. Ngược lại, khi tôi hỏi người khác, tôi cố tránh “sao không cứ”, và có lẽ tốt hơn là hỏi kiểu “tôi hiểu là có lý do nào đó nên không làm X, đúng không?” hoặc chỉ đơn giản hỏi lý do một cách tử tế.
Nếu câu hỏi xuất phát từ thiếu ngữ cảnh, có thể ngăn nó bằng cách trình bày trước vì sao các cách hiển nhiên nhất không phù hợp, hoặc nêu trước những yêu cầu khó và dữ liệu đầu vào gây vấn đề, trước khi giải thích việc mình đã làm. Nếu đó là mã đã commit, mục tiêu là giảm các bình luận kiểu nói sau trong commit hoặc merge request. Đôi khi cũng hữu ích khi không phản bác, mà trực tiếp giải thích rằng mình đã thử cách đó nhưng vì sao không được, rồi thật lòng hỏi xem họ có ý tưởng nào khác không.
Nếu đó thật sự là đề xuất tôi chưa nghĩ tới và có vẻ giải quyết được vấn đề, tôi sẽ nói đó là ý hay và nhờ họ giúp triển khai. Khi ấy có cám dỗ muốn phản ứng lại tiền đề hoặc giọng điệu của họ, nhưng tôi cố chọn cách chấp nhận và thấy hơi xấu hổ một chút.
Đây là một ví dụ áp dụng rất tốt grug brain https://grugbrain.dev/
“Nếu phải chọn giữa độ phức tạp và đánh tay đôi với khủng long bạo chúa, grug sẽ chọn khủng long bạo chúa. Ít nhất grug còn nhìn thấy được khủng long bạo chúa.”
Nếu không phải nói đùa, câu hỏi đầu tiên không giúp ích gì và gần như là hành vi xấu tính. Ai cũng thỉnh thoảng mắc lỗi.
Câu hỏi thứ hai thường có thể là phản hồi hợp lý. Kỹ năng và kiến thức của mọi người không phải lúc nào cũng trùng nhau. Thứ cực kỳ phức tạp với A có thể không như vậy với B, và ngược lại cũng có thể đúng; điều đó không nhất thiết là vì ai thông minh hơn. A có thể không biết SQL, còn B có thể không biết pandas
Giả sử trong tech stack đã có cả SQL lẫn pandas, đôi khi việc chuyển một đoạn code nào đó từ SQL sang pandas, hoặc ngược lại, là hợp lý. Có người thấy phong cách hướng đối tượng dễ hơn, có người thấy phong cách hàm dễ hơn. Điều gì hợp lý hơn không phải lúc nào cũng hiển nhiên, nên câu hỏi đó có thể là một câu hỏi hay. Nếu đề xuất dở, hãy giải thích vì sao nó dở; nếu hay, hãy cân nhắc xem có đáng làm ngay bây giờ không. Nếu ở giữa hoặc không có thời gian, thì cứ thừa nhận rồi bỏ qua
Một cách khác là đơn giản đồng ý một cách rõ ràng. Có thể trả lời: “Đúng rồi, ngu thật nhỉ?” hoặc “Đúng, có lẽ tôi không nên làm vậy”, hoặc “Tôi sẽ suy nghĩ thêm”
Khi đó đối phương khó khiến mình xấu hổ hay cảm thấy tội lỗi chỉ vì đã làm một việc chưa tối ưu. Tôi cho rằng mục đích của những câu như vậy thường là dùng sự xấu hổ để chiếm thế thượng phong. Đây là lựa chọn không tham gia trò chơi đó, và thường đó là nước đi thắng
Nếu đó là lời nói do thiếu hiểu biết, không cần phải coi nó là một cuộc công kích rồi khiến đối phương bẽ mặt để bắt họ trả giá
Tôi không tìm lại được blog hay bài viết từng đọc, nhưng thông điệp là “đừng giả định sự kém năng lực chỉ vì thấy điều gì đó chưa tối ưu trong code”. Người viết đoạn code đó có thể đã có hoàn cảnh khiến họ không thể lập tức làm “điều đúng đắn”, như deadline gấp, ưu tiên khác, hoặc các yếu tố khác
Ngay cả khi tại thời điểm viết code đó là hoàn hảo, sự phát triển của codebase và thay đổi yêu cầu cũng có thể khiến nó trở nên tệ
Ví dụ, nếu chỉ cần lưu 10 mục thì một file đơn giản có thể là lựa chọn thực tế, nhưng khi lên 10.000 mục thì có thể cần database. Nhưng nếu ngay từ đầu dùng database cho 10 mục, hẳn đã bị phàn nàn là over-engineering
Nếu có 2 class thì if/else là đủ, nhưng khi thành 20 class thì có thể cần Factory pattern; nếu làm ngay từ đầu thì trông như kiến trúc phi hành gia. Nếu cố dự đoán sự tăng trưởng như vậy mà đoán sai, ta sẽ tạo ra code phức tạp. Những dự án được phát triển liên tục sẽ có xu hướng lớn vượt khỏi chính chúng một cách có hệ thống
Cũng có hàng rào Chesterton. Thứ trông ngu ngốc trong code trước đây có thể từng thực sự quan trọng. Tệ hơn nữa, nó có thể vẫn quan trọng với một trường hợp biên hiếm gặp nào đó, nhưng ta chưa nhìn ra lý do
Tôi đã vài lần nhận được bình luận độc hại về các bài blog ở đây và trên reddit. Khi đó tôi dùng cách thêm link tới bình luận độc hại đó vào bài viết mà không phán xét, như một cách chiếu ánh sáng vào nó. Thường thì chẳng có gì xảy ra, nhưng thỉnh thoảng nó kéo cuộc thảo luận về hướng lành mạnh hơn
Tôi cũng nhận khá nhiều. Một số có lẽ là đáng, nhưng phần lớn nhiều khả năng là không. Vài bình luận nói đúng ở mức nào đó, nhưng không hữu ích hoặc trực tiếp gây hại cho cộng đồng. Nói điều đúng theo cách sai thì vẫn là nói sai
Link tới bình luận độc hại mà không phán xét không phải là ý tưởng tồi. Nếu bình luận bị đánh dấu chết thì không phải lúc nào cũng làm được, nhưng dù sao tôi cũng không đáp trả theo cùng kiểu đó. Tôi có thể làm vậy, nhưng tôi đã học được rằng xăng không phải là chất chữa cháy hiệu quả
Nếu tôi sai, tôi cố gắng thừa nhận ngay tại chính nơi đã xảy ra sai lầm đó. Tôi đặc biệt ghét kiểu xin lỗi riêng tư sau một cuộc công kích công khai
Có một ranh giới. Tôi cảm thấy mình làm việc khá tốt, đã làm trong khoảng 40 năm và học được nhiều trong thời gian đó. Tôi cũng từng làm trong những môi trường khắt khe không chấp nhận công việc kém chất lượng, nên việc làm ổn đã thành thói quen
Nhìn chung tôi tránh phán xét người khác công khai. Nó không hữu ích, và tôi cũng không phải lúc nào cũng đúng. Tuy nhiên, nếu là tình huống làm việc cùng nhau hoặc dùng thứ của người đó thì có thể khác. Tôi từng bị công kích gay gắt vì không chấp nhận rác rưởi, nhưng tôi không hành xử như Linus Torvalds. Nếu có thể, tôi nói một cách tôn trọng rằng công việc đó không thể chấp nhận được đối với tôi
Dù vậy, ta luôn có thể cải thiện và học điều mới, đôi khi từ những nơi hoàn toàn không ngờ tới. Cởi mở với việc học như vậy về cơ bản là một chính sách tốt. Tôi trở nên đúng bằng cách sai và học từ đó. “Phán đoán tốt đến từ kinh nghiệm, và kinh nghiệm đến từ phán đoán tồi”
Một trong những podcast tôi thích, well there's your problem trên YouTube, gần như luôn ghim các bình luận phàn nàn về podcast. Thường là kiểu phàn nàn ở mức “tôi không thích podcast này nên nó phải trở thành một podcast khác”, và bình luận được ghim lần nào cũng gần với cách diễn giải ngu ngốc nhất có thể về tập đó
Tôi không biết việc đó có hiệu quả trong việc giảm những bình luận như vậy không, nhưng nó có ý nghĩa là đội lên cho người tham gia diễn ngôn theo cách đó một chiếc mũ ngốc mang tính ẩn dụ
Tôi đồng ý rằng một số kỹ sư có thái độ tệ. Ai cũng có thể viết code tệ, và lập luận rằng mọi code đều tệ và đều là nợ cũng có phần hợp lý
Bài này đọc cùng “No more pink mustache” khá thú vị. Trong bài đó, Lyft được mô tả là “hỏng ở quy mô khó tin”, và nguyên nhân của chất lượng thường là tổ chức, chứ không phải người ngồi trên ghế :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
Tôi đã đọc bài này vào năm 2018 và rất vui khi nó được đưa lên lại. Đây là một trong những bài khiến tôi tự đặt câu hỏi. Nếu không thể loại bỏ chủ nghĩa tuyệt đối hay cực đoan, thì khi gặp những cuộc trò chuyện hoặc những người như vậy, ta có thể tạo ra bộ lọc nào? Tôi có mô hình của mình, nhưng tò mò người khác dùng chiến lược gì
Những người như vậy cố chiếm một vùng cảm xúc không thuộc về họ. Thường thì họ đã tính trước rằng mình “có thể làm vậy”, nghĩa là họ xem đối phương là yếu
Có ba lựa chọn. Một là bỏ cuộc, nhường vùng đó rồi tiếp tục sống; càng ít mất ngủ vì sự bất công thì càng tốt. Hai là đối đầu trực diện; họ đã sẵn sàng để đánh nhau, nhưng lập trường của họ về bản chất là phi lý, nên càng ít bị kéo vào không gian suy nghĩ của họ thì càng “thắng”. Ba là từ phía trên đi xuống, tức mang bằng chứng xã hội cho thấy họ sai vào chính không gian của họ. Trong trường hợp bài gốc, đó là những lập trình viên làm việc hiệu quả, tôn trọng công việc của nhau và không bới móc
Khi ai đó khuyên “làm thế này có thể đã tốt hơn”, điều đó không phải lúc nào cũng là công kích cá nhân hay xúc phạm năng lực của tôi
Người đưa lời khuyên có thể là một kẻ ngốc vụng về trong quan hệ xã hội, hoặc đơn giản là một kẻ hoàn toàn ngốc nghếch. Việc một phần thế giới không đồng ý với mình cũng không sao. Việc người ta nêu ý kiến trái chiều hoặc không đồng ý không có nghĩa là họ đang đe dọa mình
Một bài viết kỳ lạ. Nghe như tweet, nội dung ít, và tiêu đề không phản ánh phần thân nên trông như clickbait
Tôi không phản đối ý chính đó, nhưng cũng có mặt ngược lại. Cũng cần có khả năng tiếp nhận phản hồi
Phần lớn mọi người có thể tiếp nhận và áp dụng phản hồi. Chỉ là có những người đưa phản hồi rất tệ rồi lại cho rằng đối phương không biết tiếp nhận phản hồi
Những người này nghĩ cách phản hồi họ ưa thích là tốt nhất, rằng ai cũng phải cảm thấy giống hệt họ, và nếu không thì đối phương phải thay đổi. Tất nhiên là sai. Nhưng nếu nói điều này với họ, họ sẽ tự chứng minh vì sao ở câu đầu tiên tôi dùng từ “phần lớn”
1 bình luận
Ý kiến trên Hacker News
Nếu làm một mình, bạn có thể đưa việc cần làm vào danh sách ưu tiên, nhưng trong nhóm, những quyết định hạng hai có thể tồn tại mãi mãi hoặc bị bỏ mặc cho đến khoảnh khắc “hệ thống sập”. Sau đó, trong phần phân tích hậu sự cố, khi chỉ vào ticket đã yêu cầu sửa quả bom đó từ vài tháng trước, việc này lại bị xem là “đổ lỗi” hoặc “công kích”; rốt cuộc giải pháp dường như trở thành không bao giờ viết mã hạng hai, khiến việc lập trình càng thêm bực bội và lo âu.
Năm 2017, tôi thậm chí còn được liên hệ để sửa đoạn mã viết từ năm 2003/2004, và đoạn mã đó vẫn đang chạy trong production. Nhìn lại những đoạn mã hỏng và những chỗ từng thỏa hiệp, rồi nhận ra người chịu trách nhiệm chính là mình, là một trải nghiệm khá khiến người ta khiêm tốn; sau đó quan điểm của tôi về mã có thể bảo trì và tài liệu hóa đã thay đổi rất nhiều.
Từ các tập đoàn lớn thuộc S&P 500, công ty quy mô 100 triệu đến 1 tỷ USD, cho tới startup, những trải nghiệm như vậy với tôi là khá bình thường. Trong các trường hợp này, có những kỹ sư phần mềm và quản lý dày dạn biết đưa ra thỏa hiệp hợp lý và vẫn chăm lo nhu cầu kinh doanh; kỹ sư cũng thường xuyên tương tác trực tiếp với khách hàng.
Điều cốt lõi là sự cân bằng, và sự cân bằng đó thường được tạo ra bởi những người có khả năng phán đoán cân bằng. Nếu chỉ theo đuổi “hoàn hảo”, bạn sẽ rơi vào refactor bất tận và không bao giờ ra mắt; còn nếu phớt lờ nợ kỹ thuật hoặc chất lượng rác, theo thời gian doanh nghiệp có thể sụp đổ. Nên đứng ở đâu còn tùy vào sản phẩm, ngành, khách hàng và mô hình kinh doanh.
Tôi của quá khứ trẻ và ngây thơ, nhưng năng suất, và đã vượt qua rất nhiều ngọn núi. Mất hai ngày để hiểu lại mã, nhưng cuối cùng nó khá thông minh; có khi việc tôi của hiện tại quên sạch chỉ là do trí nhớ kém.
Tôi của tương lai sẽ sửa mọi sai lầm. Tôi tin rằng người đó già hơn, khôn ngoan hơn, có vô hạn thời gian để biến XXX và TBD thành mã thông minh, triển khai những ý tưởng hay và triển khai lại những ý tưởng chỉ tàm tạm. Nếu có comment tốt hơn, có lẽ cả ba phiên bản tôi sẽ trở thành một.
Nó không chỉ là cơ hội học hỏi đơn thuần, mà còn thể hiện văn hóa cởi mở và có tác dụng chống lại hội chứng kẻ mạo danh. Thái độ cầu toàn thì ngược lại, chỉ là “hãy cố hơn để đừng mắc lỗi”, không có gì để học mà chỉ đòi hỏi thêm nỗ lực cá nhân.
Một lần, tôi nhận thay một lỗi nhỏ của một junior khi họ đưa sai phiên bản phần mềm vào báo cáo; lẽ ra chỉ cần nói với khách hàng rằng “đã có lỗi và đây là báo cáo đã sửa”, nhưng sếp tôi chỉ nghĩ “liệu có thể giấu chuyện này và giữ thể diện rằng chúng ta hoàn hảo không?”. Cũng chính người đó lại dùng sai lầm của người khác như cơ hội để đòi giảm giá, bồi thường hoặc cung cấp miễn phí.
Nhưng như vậy vẫn ổn. Khi có lý do để thay đổi thì ta dọn dẹp; cho đến lúc đó, chúng vẫn là ví dụ cho thấy thực hành xấu và cách tiếp cận tốt hơn.
Dạo này tôi đáp: “Chắc là vì IQ của bạn cao hơn tôi. Tôi IQ thấp nên phải làm những việc ngu hơn và đơn giản hơn.” Khi đó đôi khi đối phương đỏ mặt vì nhận ra mình vừa cư xử như một gã lập dị nhỏ nhen, hạ thấp người khác mà không hề tự xét lại.
Bản thân câu hỏi không xấu, nhưng tiền đề “ý tưởng của tôi quá dễ” và “bạn đã không nghĩ ra ý tưởng hiển nhiên, dễ dàng này” có thể gây khó chịu hoặc xúc phạm. Ngược lại, khi tôi hỏi người khác, tôi cố tránh “sao không cứ”, và có lẽ tốt hơn là hỏi kiểu “tôi hiểu là có lý do nào đó nên không làm X, đúng không?” hoặc chỉ đơn giản hỏi lý do một cách tử tế.
Nếu câu hỏi xuất phát từ thiếu ngữ cảnh, có thể ngăn nó bằng cách trình bày trước vì sao các cách hiển nhiên nhất không phù hợp, hoặc nêu trước những yêu cầu khó và dữ liệu đầu vào gây vấn đề, trước khi giải thích việc mình đã làm. Nếu đó là mã đã commit, mục tiêu là giảm các bình luận kiểu nói sau trong commit hoặc merge request. Đôi khi cũng hữu ích khi không phản bác, mà trực tiếp giải thích rằng mình đã thử cách đó nhưng vì sao không được, rồi thật lòng hỏi xem họ có ý tưởng nào khác không.
Nếu đó thật sự là đề xuất tôi chưa nghĩ tới và có vẻ giải quyết được vấn đề, tôi sẽ nói đó là ý hay và nhờ họ giúp triển khai. Khi ấy có cám dỗ muốn phản ứng lại tiền đề hoặc giọng điệu của họ, nhưng tôi cố chọn cách chấp nhận và thấy hơi xấu hổ một chút.
“Nếu phải chọn giữa độ phức tạp và đánh tay đôi với khủng long bạo chúa, grug sẽ chọn khủng long bạo chúa. Ít nhất grug còn nhìn thấy được khủng long bạo chúa.”
Câu hỏi thứ hai thường có thể là phản hồi hợp lý. Kỹ năng và kiến thức của mọi người không phải lúc nào cũng trùng nhau. Thứ cực kỳ phức tạp với A có thể không như vậy với B, và ngược lại cũng có thể đúng; điều đó không nhất thiết là vì ai thông minh hơn. A có thể không biết SQL, còn B có thể không biết pandas
Giả sử trong tech stack đã có cả SQL lẫn pandas, đôi khi việc chuyển một đoạn code nào đó từ SQL sang pandas, hoặc ngược lại, là hợp lý. Có người thấy phong cách hướng đối tượng dễ hơn, có người thấy phong cách hàm dễ hơn. Điều gì hợp lý hơn không phải lúc nào cũng hiển nhiên, nên câu hỏi đó có thể là một câu hỏi hay. Nếu đề xuất dở, hãy giải thích vì sao nó dở; nếu hay, hãy cân nhắc xem có đáng làm ngay bây giờ không. Nếu ở giữa hoặc không có thời gian, thì cứ thừa nhận rồi bỏ qua
Khi đó đối phương khó khiến mình xấu hổ hay cảm thấy tội lỗi chỉ vì đã làm một việc chưa tối ưu. Tôi cho rằng mục đích của những câu như vậy thường là dùng sự xấu hổ để chiếm thế thượng phong. Đây là lựa chọn không tham gia trò chơi đó, và thường đó là nước đi thắng
Ví dụ, nếu chỉ cần lưu 10 mục thì một file đơn giản có thể là lựa chọn thực tế, nhưng khi lên 10.000 mục thì có thể cần database. Nhưng nếu ngay từ đầu dùng database cho 10 mục, hẳn đã bị phàn nàn là over-engineering
Nếu có 2 class thì if/else là đủ, nhưng khi thành 20 class thì có thể cần Factory pattern; nếu làm ngay từ đầu thì trông như kiến trúc phi hành gia. Nếu cố dự đoán sự tăng trưởng như vậy mà đoán sai, ta sẽ tạo ra code phức tạp. Những dự án được phát triển liên tục sẽ có xu hướng lớn vượt khỏi chính chúng một cách có hệ thống
Link tới bình luận độc hại mà không phán xét không phải là ý tưởng tồi. Nếu bình luận bị đánh dấu chết thì không phải lúc nào cũng làm được, nhưng dù sao tôi cũng không đáp trả theo cùng kiểu đó. Tôi có thể làm vậy, nhưng tôi đã học được rằng xăng không phải là chất chữa cháy hiệu quả
Nếu tôi sai, tôi cố gắng thừa nhận ngay tại chính nơi đã xảy ra sai lầm đó. Tôi đặc biệt ghét kiểu xin lỗi riêng tư sau một cuộc công kích công khai
Có một ranh giới. Tôi cảm thấy mình làm việc khá tốt, đã làm trong khoảng 40 năm và học được nhiều trong thời gian đó. Tôi cũng từng làm trong những môi trường khắt khe không chấp nhận công việc kém chất lượng, nên việc làm ổn đã thành thói quen
Nhìn chung tôi tránh phán xét người khác công khai. Nó không hữu ích, và tôi cũng không phải lúc nào cũng đúng. Tuy nhiên, nếu là tình huống làm việc cùng nhau hoặc dùng thứ của người đó thì có thể khác. Tôi từng bị công kích gay gắt vì không chấp nhận rác rưởi, nhưng tôi không hành xử như Linus Torvalds. Nếu có thể, tôi nói một cách tôn trọng rằng công việc đó không thể chấp nhận được đối với tôi
Dù vậy, ta luôn có thể cải thiện và học điều mới, đôi khi từ những nơi hoàn toàn không ngờ tới. Cởi mở với việc học như vậy về cơ bản là một chính sách tốt. Tôi trở nên đúng bằng cách sai và học từ đó. “Phán đoán tốt đến từ kinh nghiệm, và kinh nghiệm đến từ phán đoán tồi”
Tôi không biết việc đó có hiệu quả trong việc giảm những bình luận như vậy không, nhưng nó có ý nghĩa là đội lên cho người tham gia diễn ngôn theo cách đó một chiếc mũ ngốc mang tính ẩn dụ
Bài này đọc cùng “No more pink mustache” khá thú vị. Trong bài đó, Lyft được mô tả là “hỏng ở quy mô khó tin”, và nguyên nhân của chất lượng thường là tổ chức, chứ không phải người ngồi trên ghế :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
Có ba lựa chọn. Một là bỏ cuộc, nhường vùng đó rồi tiếp tục sống; càng ít mất ngủ vì sự bất công thì càng tốt. Hai là đối đầu trực diện; họ đã sẵn sàng để đánh nhau, nhưng lập trường của họ về bản chất là phi lý, nên càng ít bị kéo vào không gian suy nghĩ của họ thì càng “thắng”. Ba là từ phía trên đi xuống, tức mang bằng chứng xã hội cho thấy họ sai vào chính không gian của họ. Trong trường hợp bài gốc, đó là những lập trình viên làm việc hiệu quả, tôn trọng công việc của nhau và không bới móc
Người đưa lời khuyên có thể là một kẻ ngốc vụng về trong quan hệ xã hội, hoặc đơn giản là một kẻ hoàn toàn ngốc nghếch. Việc một phần thế giới không đồng ý với mình cũng không sao. Việc người ta nêu ý kiến trái chiều hoặc không đồng ý không có nghĩa là họ đang đe dọa mình
Những người này nghĩ cách phản hồi họ ưa thích là tốt nhất, rằng ai cũng phải cảm thấy giống hệt họ, và nếu không thì đối phương phải thay đổi. Tất nhiên là sai. Nhưng nếu nói điều này với họ, họ sẽ tự chứng minh vì sao ở câu đầu tiên tôi dùng từ “phần lớn”