- Một lập trình viên đã ngừng viết và hoạt động trực tuyến suốt nhiều tháng vì sợ hãi chia sẻ rằng mình sẽ ngừng tự kiểm duyệt, đồng thời thú nhận những thiếu sót về kỹ thuật lẫn cá nhân mà trước đây không thể thừa nhận
- Thừa nhận rằng bản thân đã không hiểu khái niệm đa hình (polymorphism) trong hơn 10 năm, đã mất kỹ năng SQL, và phần lớn mã nguồn từng được triển khai mà không có kiểm thử tự động
- Chia sẻ về việc từng cố theo kịp thay đổi trong tech stack của công ty nhưng rồi dừng học C# và Blazor, thực tế là vẫn yêu Ruby nhưng không thể dùng nó trong công việc, cùng áp lực tâm lý khi quản lý và đồng nghiệp đều đọc blog của mình
- Kể lại trải nghiệm bị bắt nạt trên mạng sau khi gửi một PR được viết bằng AI, cùng những cảm xúc thẳng thắn về làm việc từ xa và quan điểm rằng các quy trình phát triển phần mềm tùy biến trong tổ chức là không cần thiết
- Khép lại bằng quyết tâm buông bỏ nỗi sợ, tiếp tục học tập liên tục và viết công khai mà không còn tự kiểm duyệt nữa
Khởi đầu: điều khiến tôi quyết định dừng sợ hãi và tự kiểm duyệt
- Từ sau tháng 4, đã có một quãng thời gian tôi quá sợ hãi đến mức không thể đăng bài, và tôi đã cắt đứt hoàn toàn khỏi mạng xã hội, các trang tổng hợp tin tức và cả diễn đàn
- Tôi cảm thấy mình không thể kéo dài trạng thái này thêm nữa nên đã quyết định vượt qua nỗi sợ và viết lại
- Tôi đã sống trong trạng thái che giấu rất kỹ vì không muốn để lộ những lỗ hổng nền tảng của mình, nhưng rồi tôi bắt đầu nhìn thấy rằng rất nhiều lập trình viên thực ra cũng làm việc với những khoảng trống kiến thức tương tự
- Cách học của tôi từ trước tới nay giống như một khối nấm nhầy chỉ phình to ở những vùng đang dùng đến, còn những kiến thức không dùng tới thì cứ thế khô héo đi
- Gần đây tôi bắt đầu bù đắp lại phần nền tảng, và trong lúc tái cấu trúc những gì đã học thành bài viết và lời nói, cảm giác nhẹ nhàng thừa nhận “mình không biết” cũng dần hình thành
- Khi trực tiếp cảm nhận được rằng nền tảng có thể học lại, tôi bắt đầu có được cảm giác rằng không bao giờ là quá muộn
Quãng thời gian hơn 10 năm không hiểu đa hình
- Từ năm 2012 tôi vẫn nghĩ mình đang viết mã hướng đối tượng, nhưng rồi tôi phải tự thừa nhận rằng cho đến tận khoảng 1 năm trước, tôi vẫn chưa thực sự hiểu đa hình
- Tôi đối diện với thực tế rằng những gì mình đã viết cho đến nay, thay vì là hướng đối tượng, thực ra gần với lập trình có cấu trúc hơn
- Tôi chưa từng nghĩ đến chuyện thay thế câu lệnh điều kiện bằng các lớp để thay đổi thiết kế
- Nhờ đọc bài của Sandi Metz và tài liệu của Martin Fowler, tôi mới hiểu được khái niệm này khá muộn, và điều đó khiến tôi thấy rõ mình đã bỏ lỡ quá nhiều thứ
-
Vì sao khó nói ra điều này
- Tôi từng là người đảm nhận vai trò đánh giá các khái niệm hướng đối tượng trong phỏng vấn tuyển dụng, nên việc thừa nhận rằng chính mình lại không biết đa hình là điều rất nặng nề
- Điều đó phơi bày nguyên vẹn việc ở giai đoạn đầu sự nghiệp, tôi thiên về học công cụ hơn là học nguyên lý, và cũng không dễ để đối diện với thực tế rằng vì không học chuyên ngành CS, tôi đã bỏ lỡ quá nhiều nền tảng
Trải nghiệm quên mất SQL
- Đã từng có thời tôi luyện bài tập theo sách SQL và viết JOIN cùng subquery rất thành thạo
- Nhưng khi công việc thực tế chuyển hẳn sang frontend và tôi không còn dùng SQL nữa, đến một lúc tôi nhận ra cả một kỹ năng đã biến mất khỏi đầu mình
- Tôi vẫn nhớ các câu truy vấn cơ bản, nhưng nếu phải giải thích sự khác nhau giữa left join và outer join, tôi sẽ phải mở lại tài liệu
-
Vì sao khó thừa nhận điều này
- Khi còn trẻ, tôi từng tin rằng dù vài năm trôi qua, kiến thức và kỹ năng vẫn có thể sống lại chỉ cần một gợi ý nhỏ
- Giờ đây tôi cảm nhận rõ thực tế rằng khả năng đó không còn giữ nguyên nữa, và điều tác động mạnh nhất là SQL chính là kỹ năng đầu tiên biến mất hoàn toàn khỏi trí nhớ của tôi
- Việc công khai viết về tuổi tác và những thay đổi trong dòng chảy ký ức không hề dễ dàng
Thực tế là tôi đã phát triển phần mềm mà không có kiểm thử tự động
- Tôi tự thừa nhận rằng hơn 95% mã nguồn từng được triển khai cho đến nay đều chạy trong production mà không có kiểm thử tự động
- Ở giai đoạn đầu sự nghiệp, tôi thậm chí còn chưa tiếp xúc với khái niệm kiểm thử, còn thời làm Ember thì việc tận dụng công cụ test đúng cách cũng không dễ
- Gần đây tôi thường xuyên xử lý mã legacy nên không có đủ thời gian để làm công việc chuẩn bị nhằm biến mã thành thứ có thể kiểm thử được
- Tôi chỉ có thể kèm kiểm thử ở những subsystem mới được xây dựng
-
Vì sao khó nói ra điều này
- Đây là sự thú nhận khiến tôi cảm thấy nặng nề nhất và có thể gây tổn hại lớn nhất cho sự nghiệp
- Theo tiêu chuẩn của Uncle Bob, mã chạy trong production mà không có kiểm thử có thể được xem là một thái độ thiếu đạo đức, và tôi sợ phải đối diện với khoảng cách giữa chuẩn mực đó và thực tế của bản thân
- Tôi thấy rằng nếu điều này bị công khai, nó rất dễ dẫn tới những đánh giá bất lợi trong quá trình tuyển dụng, nên tôi đã trì hoãn cả việc ghi chép hành trình học tập của mình
Vì sao tôi không học tiếp Blazor
- Khi công ty quyết định chuyển từ Angular sang Blazor, tôi là người duy nhất trong nhóm không có kinh nghiệm C#, nên đã vội vàng bắt đầu học để đuổi kịp
- Nhưng vài tháng sau quyết định chuyển đổi bị hủy bỏ, và động lực học tập của tôi biến mất hoàn toàn, đến mức không đọc hết nổi cuốn sách
- Vốn dĩ C# hay .NET cũng không phải ngôn ngữ tôi muốn dùng cho side project, nên điều này chỉ làm lộ rõ rằng tôi học nó hoàn toàn vì công việc
-
Vì sao khó viết về điều này
- Trong một bài trước đó, tôi đã trực tiếp hứa sẽ viết tiếp phần sau, và việc không giữ được lời hứa đó nhưng lại đi viết bài khác khiến tôi ngày càng thấy khó chịu
- Vì bài viết về Blazor từng có lượng xem rất cao, tôi sợ rằng thừa nhận mình đã đổi hướng sẽ trông giống như một thất bại
Mong muốn được dùng Ruby nhiều hơn
- Ruby đến giờ vẫn là ngôn ngữ khiến tôi thấy thoải mái và vui nhất, là thứ tôi tự nhiên muốn chạm vào khi làm ví dụ, mã nguồn mở, kata, hackathon
- Nhưng từ năm 2013 đến nay, chưa một lần nào tôi được trả lương để viết Ruby, còn trong công việc tôi dùng những ngôn ngữ như TypeScript
- Tôi rất quý những đồng nghiệp mình đã cùng làm việc ở nhiều công ty, nên thay vì chọn ngôn ngữ, tôi tiếp tục chọn con người và chấp nhận thỏa hiệp về ngôn ngữ
- Tôi muốn dành buổi tối và cuối tuần cho Ruby, nhưng giữa các nghĩa vụ khác và những mục tiêu học tập khác, thực tế là tôi hầu như không có đủ thời gian để dùng Ruby như mong muốn
-
Vì sao khó nói ra điều này
- Quản lý và CTO của tôi đều đọc blog này, nên tôi sợ rằng việc nói mình muốn dùng Ruby nhiều hơn sẽ bị hiểu như tín hiệu sắp nghỉ việc
- Tôi cũng không muốn bị nhìn như người đang cố ép công ty dùng một ngôn ngữ mà nơi đó không quen thuộc
Bị bắt nạt trên mạng vẫn đau đớn ngay cả khi đã trưởng thành
- Khi tôi gửi một bản vá nhỏ do LLM tạo ra cho một dự án mã nguồn mở và chia sẻ trải nghiệm đó trên diễn đàn trực tuyến,
tôi đã phải đối mặt với một làn sóng công kích cá nhân dữ dội như vô dụng, ghê tởm, nguy hiểm
- Những cuộc tấn công ấy không dừng ở trong trang web mà còn lan sang các website khác, email, SMS và điện thoại, khiến tôi trực tiếp cảm thấy mình không còn an toàn
- Tôi đã yêu cầu quản trị viên diễn đàn xóa tên thật của mình, nhưng ngược lại nhiều PII hơn lại bị gắn vào hồ sơ,
và tôi còn phải chứng kiến cả việc một dòng mô tả sai sự thật nói rằng tôi bịa chuyện về các liên hệ từ bên ngoài bị đóng đinh vĩnh viễn vào đó
- Cuối cùng tôi không còn cách nào khác ngoài việc vô hiệu hóa tài khoản và rời khỏi trang web
-
Vì sao khó viết về điều này
- Cuộc quấy rối kéo dài nhiều ngày đó là trải nghiệm trực tuyến độc hại nhất mà tôi từng gặp, và cho đến giờ dư âm của nó vẫn còn
- Tôi luôn sợ rằng nếu kể công khai câu chuyện này, những kẻ đó có thể lại tìm đến tôi
- Việc nghĩ đến khả năng thông tin sai lệch còn sót lại trên hồ sơ gây ảnh hưởng xấu đến việc làm càng khiến tôi khó mở lời hơn
Nghĩ rằng đội SaaS không cần một “quy trình đặc biệt”
- Trong ngành phần mềm đã có sẵn những quy trình được mài giũa qua hàng chục năm,
và các cách làm như Agile, Lean, Kanban, XP đều đã tồn tại như những cấu trúc được kiểm chứng
- Tôi dần đi đến nhận định rằng với năng lực có hạn của công ty, nên tập trung vào phát triển sản phẩm thay vì tiêu tốn nó để sáng chế ra một quy trình mới
-
Vì sao khó nói ra suy nghĩ này
- Khi viết, tôi luôn có thói quen dựa trên những chủ đề mình thực sự hiểu rõ, và trong trường hợp này, động lực lại đến từ một quy trình phát triển phần mềm tùy biến do đồng nghiệp cùng công ty đề xuất
- Tôi cảm thấy có nguy cơ bài viết sẽ bị nhìn như một lời công kích công khai nhắm vào một đồng nghiệp cụ thể hoặc chính ý tưởng của họ
- Tôi ngưỡng mộ khả năng viết của những người như Kent Beck hay Martin Fowler, những người có thể giải thích cách cộng tác tốt hơn mà vẫn không chĩa thẳng vào đồng nghiệp đã mắc sai lầm
- Tôi cảm thấy mình vẫn chưa có đủ cảm giác cân bằng đó, nên đã do dự khi viết
Cách làm việc từ xa thực sự cản trở cộng tác
- Làm việc từ xa giải quyết được nhiều vấn đề, nhưng tôi vẫn không thể xóa đi cảm giác rằng bản thân việc phát triển phần mềm vận hành tốt hơn khi mọi người ở cùng một không gian
- Gọi video là một hình thức giao tiếp băng thông thấp, ít tín hiệu cảm nhận, khiến ta mất đi nhận thức ngoại vi và khó phát hiện lúc đồng nghiệp đang gặp khó khăn
- Việc nhờ giúp đỡ cũng trở nên nặng nề hơn, còn những cách tư duy gắn với không gian như bảng trắng hay sticky note thì rất dễ bị phá vỡ trên công cụ trực tuyến
- Mâu thuẫn cũng leo thang nhanh hơn vì con người trên màn hình dễ bị gán thành hình ảnh của “phe đối địch”
-
Vì sao khó viết về điều này
- Sau COVID, công ty tôi trở thành công ty làm việc hoàn toàn từ xa, và nhờ đó tôi mới có thể xây dựng một cuộc sống với 27 mẫu đất và cả bò sữa cho gia đình
- Vì tôi đã có một cấu trúc sống khó lòng chuyển trở lại thành phố, nên việc nói rằng mình không thích làm việc từ xa
khiến tôi cảm thấy như đang tự tạo ấn tượng bất lợi với công việc hiện tại và cả mọi công việc remote mà sau này tôi có thể ứng tuyển
Kế hoạch sắp tới
- Qua bài viết này, tôi cảm thấy mình đã lại bước được bước đầu tiên để vượt qua nỗi sợ,
và từ giờ tôi dự định sẽ tiếp tục học nền tảng, đồng thời ghi lại mọi điều đã học một cách không che giấu
- Với những ai có trải nghiệm tương tự, muốn giúp đỡ, hoặc tò mò về bài viết tiếp theo,
tôi hướng dẫn cách theo dõi tin tức qua Mastodon, RSS và mailing list
1 bình luận
Ý kiến Hacker News
Tôi cũng thích làm việc tại văn phòng, nhưng điều đó không có nghĩa là ủng hộ RTO (quay lại văn phòng). Chỉ đơn giản là xu hướng cá nhân của tôi thôi.
Có vẻ như sự bất an và hội chứng kẻ mạo danh trong ngành khiến mọi người trở nên gay gắt. Nếu ai cũng thành thật hơn thì có lẽ sẽ dễ chịu hơn.
Và thú thật thì tôi chưa từng viết gì phức tạp hơn Fibonacci bằng Lisp hay Haskell. Đầu óc tôi không vận hành theo cách đó
Tuy nhiên, bài gốc lại diễn đạt trải nghiệm của mình như thể một chân lý khách quan áp dụng cho tất cả. Đặc biệt, cách dùng ngôi thứ hai khiến nó nghe rất ngạo mạn.
Cách nói quan trọng không kém gì nội dung. Với những chủ đề nhạy cảm như làm việc từ xa, càng phải cẩn trọng trong cách diễn đạt.
Tôi cũng từng phải làm việc từ xa vì vấn đề sức khỏe của gia đình, nên giọng điệu của bài viết khiến tôi thấy nó quá hời hợt và bực mình.
Cuối cùng, trước khi nói mọi người đang phản ứng thái quá, trước hết nên nhìn lại xem cách diễn đạt của mình ảnh hưởng đến người khác thế nào
Thay vì nói chuyện ngoài hành lang, chúng tôi giải quyết vấn đề qua chat nhóm, và mọi người đều rất tích cực giúp đỡ.
Giờ đây ngược lại tôi lại có cảm giác chúng ta dùng công cụ còn kém hơn trước
Khi những không gian có thể nói chuyện ẩn danh dần biến mất, một văn hóa khó có thể phát biểu tự do đã hình thành
Khi đó nếu thất bại thì chỉ cần sang chỗ ngồi bên cạnh để giải quyết, còn bây giờ nếu thất bại thì coi như hết
Vì thế mọi người đổ lỗi sự cô đơn cho làm việc từ xa
Bây giờ có nhiều người được điều chỉnh về mặt xã hội hơn, nên lại yếu trong giao tiếp bất đồng bộ
Mật độ đọc được tín hiệu phi ngôn ngữ thấp hơn, nên cũng ít manh mối xã hội hơn
Rất nhiều lập trình viên đang đi theo lộ trình sự nghiệp hơn là sự hứng thú.
Tôi đã phải học lại SQL đến ba lần. Công nghệ cứ thay đổi liên tục nên không thể nhớ hết mọi thứ.
Điều quan trọng không phải cú pháp mà là khả năng giải quyết vấn đề và hợp tác.
Tôi nghĩ AI khó mà thay thế được điều đó
Có hiệu ứng lây lan của sự tập trung. Không gian làm việc chung làm tăng năng suất
Cánh cửa là công cụ tốt nhất để điều tiết giữa hợp tác và tập trung.
Nó là tín hiệu rõ ràng hơn nhiều so với trạng thái “away” trên mạng
Việc ép người khác phải đến văn phòng chỉ để phục vụ sự tập trung của một ai đó là vô nhân đạo
Không phải làm việc từ xa là xấu, mà có thể chỉ là tác giả từng làm ở một công ty có hệ thống hỗ trợ tệ
Tôi cũng thường xuyên nói “tôi không biết”. Đó là đặc điểm của những người có EQ cao
Khi live coding bằng Kotlin, tôi đã hoảng vì không nhớ ra cú pháp switch.
Điều đó khiến tôi nhận ra ngay cả ngôn ngữ dùng hằng ngày cũng có thể quên rất nhanh
Khái niệm thì còn lâu, nhưng cú pháp chi tiết thì biến mất rất nhanh
Nhưng thực tế là bầu không khí hiện nay khiến ngay cả việc nói về nỗi lo đó cũng khó khăn.
Tôi cũng thích viết code với Claude, nhưng đồng thời vẫn thấy sợ.
Nếu chúng ta là thế hệ hiểu rõ nhất bản chất của sự thay đổi sắp tới, thì chúng ta nên thảo luận về nó
Vấn đề là, có thể nó chỉ đang nâng năng suất của những người thiếu năng lực mà thôi
Nhưng nếu doanh nghiệp bắt đầu dùng AI cho vai trò quản lý, chỗ đứng của lập trình viên con người sẽ thu hẹp lại.
Từ bây giờ nên chuẩn bị chuyển sang những vai trò như chuyên gia tư vấn hiệu suất AI