Một Ride mà bạn phải đọc ít nhất một cuốn sách mới được lên
(ludic.mataroa.blog)- Dù được công nhận là kỹ sư thuộc nhóm hàng đầu ở nơi làm việc, khoảng cách với những cao thủ thực sự vẫn có thể rất lớn, và khác biệt đó thường lộ rõ ở lượng học tập đúng cách
- Trải nghiệm từng bỏ mỹ thuật sau trung học cho thấy chỉ với một cuốn Drawing On The Right Side Of The Brain và vài giờ luyện tập, “tài liệu phù hợp” có thể hạ thấp rào cản
- Trong kỹ thuật cũng vậy, khác biệt giữa người đã đọc ít nhất một cuốn sách về một chủ đề cụ thể và người gần như chưa từng thử là rất lớn; ở nhiều nhóm nghề nghiệp, nhóm sau chiếm đa số
- Chuyên môn được phân tầng như đấu kiếm ở cấp địa phương, quốc gia và Olympic; người đọc nhiều cuốn và đào sâu sẽ tiến gần đến cuộc cạnh tranh cho những công việc hàng đầu
- Chỉ đọc sách là chưa đủ; nếu không có kỹ năng meta để chọn tài liệu tốt và loại bỏ phần dở, thì dù bám vào tài liệu về Scrum, Agile hay lãnh đạo cũng khó tạo ra kết quả
Điểm xuất phát: “thuộc nhóm hàng đầu nhưng đồng thời vẫn còn thiếu”
- Tác giả luôn được công nhận là một kỹ sư giỏi trong môi trường nghề nghiệp
- Tự mô tả rằng mình học nhiều hơn kỹ sư trung bình xung quanh tới mức có thể gấp hàng chục lần
- Từng nhận được đề nghị ở cấp senior từ một trong những công ty hàng đầu trong bang
- “Serious People” muốn tuyển lại anh, và anh nổi giận trước những commit message lười biếng
- Nhưng so với nhiều người gửi email cho mình, tác giả thấy mình rõ ràng còn thiếu sót
- Kinh nghiệm chỉ 3–4 năm, nền tảng là tâm lý học
- Ngoài các dự án cá nhân, gần như chưa từng viết test; các nhà tuyển dụng mà anh từng thấy không có test hoạt động được, cũng không có ý chí đưa test vào
- Mã cho luận văn thạc sĩ được viết mà không dùng quản lý phiên bản; anh giải thích rằng một trong những đại học hàng đầu trong nước đã không dạy quản lý phiên bản
- Tác giả dùng các ví dụ từ mỹ thuật, kỹ thuật và thể thao để lý giải mâu thuẫn này, nhấn mạnh khoảng cách giữa “người đã học đúng cách một chút” và “người gần như chưa từng thử”
Hiệu quả của “một cuốn sách phù hợp” từng trải nghiệm trong mỹ thuật
- Thời trung học, tác giả ghét mỹ thuật nhất, tự kết luận rằng mình không có chất nghệ sĩ rồi trong khoảng 10 năm gần như không vẽ gì ngoài vài khối lập phương ở mức nguệch ngoạc
- Năm 2022, anh thử khóa Drawabox, nhưng thấy nó rất nhàm chán và không có tiến bộ
- Sau đó, nhờ gợi ý trên Hacker News, anh biết đến Drawing On The Right Side Of The Brain của Betty Edwards
- Tiêu đề khiến tác giả, người đã rời khỏi ngành tâm lý học, khó chịu, nhưng có lời giới thiệu và các trường hợp trước/sau
- Những bức “sau” trông phi thực tế đến mức giống như một trò lừa giảm cân
- Bài tập đầu tiên của sách là vẽ bàn tay của chính mình tốt nhất có thể, và tác giả đã vẽ trong 30–45 phút
- Theo tiêu chuẩn lúc đó, đó là bức vẽ đẹp nhất đời anh, nhưng anh vẫn đánh giá là còn thiếu sót
- Sau đó, anh luyện bằng cách nhìn theo các đường nét của một bức tranh lộn ngược rồi vẽ lại, và khi vẽ thêm vài bức nữa, anh ngạc nhiên trước kết quả
- Khi vẽ lại bàn tay, chỉ sau khoảng 6 giờ đọc và luyện tập, kết quả đã tốt hơn trước rất nhiều
- Trải nghiệm này trở thành một ví dụ: suýt nữa anh đã bỏ lỡ niềm vui nghệ thuật cả đời, nhưng sau khi cầm đúng cuốn sách phù hợp, anh đã vượt qua rào cản
“Rào cản một cuốn sách” và phân bố kỹ sư
- Kỹ sư có thể chia rộng ra thành hai nhóm
- Kỹ sư đã đọc từ 1 cuốn trở lên về một chủ đề cụ thể nhìn chung trông rất có năng lực
- Không nhất thiết phải đúng nghĩa là sách; một lượng đủ lớn blog kỹ thuật hoặc bài giảng, dù khác nhau về hiệu quả, cũng có thể đóng vai trò tương tự
- Ở phía ngược lại là những kỹ sư và người thuộc các nghề khác gần như không thử gì trong suốt sự nghiệp; tác giả cho rằng họ là đa số
- Kỹ sư cao thủ Seth Newman mô tả chuyên gia trung bình gần giống “người mộng du đi qua đời sống làm việc”
- Có chuyển động, nhưng thiếu nhận thức để tránh việc lăn xuống cầu thang
- Bản thân tác giả tự thấy mình gần với kiểu người chỉ đọc khoảng một cuốn sách hay cho hầu hết các chủ đề liên quan đến nghề nghiệp
- Nhờ Pro Git, anh hiểu chắc mô hình dữ liệu của Git, nhưng không biết các thuật toán bên dưới
- Dù vậy, anh cho rằng chừng đó đủ để áp đảo một kỹ sư được chọn ngẫu nhiên
- Nhìn vào những dự án như Evennia, anh cũng thừa nhận có những người ở mức sâu hơn rất nhiều
- Sau khi trò chuyện với những người đạt thành tích cao ở nhiều lĩnh vực, anh nói rằng gần như lĩnh vực nào cũng có rất nhiều người thậm chí chưa từng thử một cách nghiêm túc
Chuyên môn được phân tầng vô tận
- Cuộc trò chuyện với Seth chuyển sang chuyện chuyên môn hóa sâu có thể đi xa đến đâu
- Với ví dụ bóng rổ, anh nêu một video về một người được biết đến như một trong những cầu thủ cuối bảng của NBA, 10 năm sau khi giải nghệ và cơ thể đã xuống cấp, vẫn áp đảo các tay nghiệp dư và những cầu thủ chuyên nghiệp cấp thấp
- Trải nghiệm đấu kiếm của tác giả cũng có cùng cấu trúc
- Ở Melbourne, tác giả được xem là một tay kiếm sabre khá ổn, và thắng hầu hết người nghiệp dư
- Nhưng anh bị một vài vận động viên tham dự giải vô địch bang áp đảo
- Một người từng tập cùng anh sau này vô địch Nationals của Úc, nhưng không ghi nổi một điểm trước một vận động viên đang thử sức vòng loại Olympic
- Yu Peng Kean của Malaysia thua nhà vô địch năm đó 15–1 tại Olympic 2012
- Cấu trúc tầng bậc như vậy không xa lạ, giống như việc Magnus Carlsen áp đảo những kỳ thủ đã luyện cờ cả đời, nhưng khi trực tiếp đối đầu thì cảm giác hoàn toàn khác
- Tác giả mô tả rằng vận động viên nhóm trên luôn có vẻ xa hơn một chút, nhanh hơn và chính xác hơn; đối thủ có cảm giác như một đứa trẻ lao vào người lớn
Động lực và “những người vào nhầm ngành công nghệ”
- Tác giả thừa nhận bản thân cũng gần như ở trạng thái mộng du trong những lĩnh vực như piano
- Anh cảm thấy mình thiếu năng khiếu, nhưng thực tế là anh không luyện tập đủ
- Tuy nhiên, anh không lấy piano làm nghề, và không ai trả tiền cho anh để chơi piano
- Trong lĩnh vực công nghệ, anh cho rằng xã hội đã sai khi tạo động lực để cả những người không có năng khiếu hay hứng thú cũng tham gia
- Nhiều người có thể tỉnh táo trong các lĩnh vực khác như thể thao, nghệ thuật hay toán học
- Anh cho rằng vì một số lĩnh vực có quá nhiều tiền, việc vận hành tổ chức lớn rất khó, và có xu hướng biến tiền của doanh nghiệp thành địa vị cá nhân, nên cả lập trình viên tệ và lãnh đạo tệ cũng được trả lương cao
- Anh phê phán gay gắt rằng làm PowerBI developer là một cách dễ để nhận lương trên trung bình và lêu lổng hơn 6 giờ mỗi ngày
- Trích dẫn trải nghiệm công việc đầu tiên của Christopher Hitchens, anh nhấn mạnh rằng vì quá kém đến mức không thể tiếp tục ở lại một công việc nào đó, người ta mới có thể đi sang con đường khác
Lợi thế cạnh tranh mà một cuốn sách tạo ra
- Liên hệ với bài viết very little effort của Dan Luu, tác giả cho rằng đôi khi chỉ cần rất ít nỗ lực để trở thành người đạt hiệu suất cao
- Người đạt hiệu suất cao có thể là người làm được một việc rõ ràng như lộn ngược ra sau, hoặc là người có kết quả cao hơn người khác
- Một cuốn sách thường có thể đưa bạn đến mức “thêm tính năng mới vào ứng dụng React mà không tạo nợ kỹ thuật”
- Nếu chọn một cách thông minh công việc mà xã hội tưởng thưởng, tác giả cho rằng chừng đó đủ để kiếm sống một cách có đạo đức
- Nếu đọc nhiều cuốn, bạn tiến gần hơn đến cuộc cạnh tranh cho những việc có mức lương cao nhất
- Đây là vùng mà việc có thể làm cùng một việc trong một ngày hay trong một tuần trở nên quan trọng
- Nếu đối thủ đọc N cuốn, bạn phải đọc N+1 cuốn, trở thành một cuộc chạy đua vũ trang
- Vì Deloitte và lập trình viên trung bình không đọc cuốn sách nào, tác giả cho rằng họ là đối thủ dễ đối phó
- Nếu bị ràng buộc trong tổ chức với tư cách nhân viên toàn thời gian, bạn sẽ phải làm việc với những người như vậy và có thể cảm thấy bất lực
- Nếu hành động theo kiểu mercenary hơn, bạn có thể áp đảo họ trong phỏng vấn và họp hành
- Trong phỏng vấn kỹ thuật, tác giả đề xuất hỏi ứng viên cuốn sách kỹ thuật họ thích, rồi chỉ trò chuyện với những người nêu ra cuốn mà người phỏng vấn có thể kiểm chứng nội dung; như vậy có thể lọc ra phần lớn dud candidate
- Ứng viên đã đọc một cuốn sách tuyệt vời mà người phỏng vấn không biết có thể trở thành false negative
- Tác giả đoán rằng false positive gần như sẽ không có
Những người nỗ lực nhưng không có kết quả và năng lực chọn lọc tài liệu
- Trường hợp phức tạp hơn là những người vận hành đội nhóm thực sự cố gắng nhưng không tạo ra kết quả
- Họ làm khổ kỹ sư, hoảng loạn, không hiểu tuyển dụng, đánh giá quá cao năng lực của mình, nhưng thật lòng nỗ lực
- Họ liên tục cố làm Scrum cho đúng, nhưng kết quả trông giống như người mộng du đi thẳng xuống hồ
- Năng lực họ thiếu là kỹ năng meta để biết nên đọc cuốn sách nào
- Sự khác biệt giữa Drawabox và sách của Betty Edwards là ví dụ tiêu biểu
- Drawabox nhìn bề ngoài có vẻ hợp lý, nhưng với mục tiêu của tác giả, sách của Edwards tốt hơn rất nhiều
- Tác giả cho rằng Drawabox giả định người học đã biết các mẹo cốt lõi mà Edwards nhấn mạnh, rồi chuyển sang kỹ năng cơ học
- Vì mảnh ghép bị thiếu này, có thể dù hoàn thành toàn bộ khóa học cũng gần như không tiến bộ
- Trong lĩnh vực công nghệ, tác giả thường tin tài liệu của người đã tự tay tạo ra thứ gì đó ấn tượng hơn
- Nếu có tín hiệu như duy trì mã nguồn mở hoặc kiến thức khó giả mạo, anh chấm điểm cao
- Những thành tựu mơ hồ hơn như “công ty lớn” được chấm thấp hơn, vì có thể đạt được nhờ may mắn hoặc khoác lác
- Anh cho rằng khó mà nói dối về việc code có biên dịch được hay không
- Anh cũng đưa ra vài quy tắc lỏng lẻo để đánh giá tài liệu
- Tên quá nổi bật là một điểm trừ
- Anh cho rằng sách hay thường có bìa nhàm chán hoặc tinh tế
- Nếu tiêu đề có chữ “leadership”, nhìn chung khả năng cao là nhảm nhí
- Tác giả càng khoe nhiều giải thưởng thì anh càng cảm thấy như đang nghe nói dối
- Văn phong khẩu ngữ là điểm trừ, nhưng nếu chủ đề tinh tế thì không phải khuyết điểm chí mạng
Phê phán Agile, The Phoenix Project và việc học trên LinkedIn
- Một Agile consultant được đưa vào nơi làm việc, ban lãnh đạo thì thích, nhưng lại hỏi kỹ sư “hãy chấm Agile training từ 1 đến 5 điểm”
- Tác giả cho rằng bản thân câu hỏi này vô nghĩa
- Anh nói rằng gần như có tương quan 100% giữa những người thích buổi đó và những người đọc nhầm sách
- Ngay cả trong một cuốn sách, cũng phải biết bỏ đi những phần không có giá trị
- The Phoenix Project có ý tưởng hay, nhưng trong câu chuyện chuyển đổi tổ chức, việc chỉ đặt một tác nhân xấu còn những người khác thì rất có năng lực và tận tâm là khác với thực tế ở doanh nghiệp lớn
- Cần lấy được ý tưởng hay, đồng thời nhận ra phần còn lại gần giống “leadership fanfic”
- Nếu không có năng lực chọn lọc này, việc học và tự cải thiện sẽ bị cản trở nghiêm trọng
- Khi lãnh đạo công khai tài liệu họ đọc, những trường hợp khiến người ta thấy khả năng người đó làm việc tốt là thấp sẽ lập tức lộ ra
- Nếu một lãnh đạo nói rằng họ học qua LinkedIn, tác giả cảm thấy phản cảm mạnh
Kết luận: Mở sách ra thì hiệu quả, nhưng không cần khuyên đối thủ làm vậy
- Ban đầu, bài viết dự định nhìn lại hiệu quả lớn bất thường của việc mở sách trong thời đại YouTube
- Kết luận thực tế, theo kiểu mỉa mai, lại gần với việc đừng khuyên mọi người đọc sách trong bất kỳ hoàn cảnh nào
- Nếu người khác vẫn ở trạng thái không đọc, thì với người đọc sách đó là tiền dễ kiếm
- Bài viết kết thúc bằng một câu đùa rằng bài tiếp theo sẽ chứa đầy anti-Git propaganda và các liên kết tài liệu Scrum
2 bình luận
Muốn tận dụng công nghệ thì trước hết cũng phải biết nó tồn tại để còn thử dùng, nên dù chỉ biết nông thôi cũng vẫn rất quan trọng.
Ý kiến trên Hacker News
Bài viết rất hay, nhưng dường như đánh giá thấp tri thức ngầm của một kỹ sư lão luyện mà người mới không có
Đôi khi nó trông như lẽ thường, nhưng thực ra không phải vậy, và kết quả là rất dễ dẫn đến thiếu đồng cảm. Có thể xây dựng sự đồng cảm đó bằng cách dành thời gian với trẻ em hoặc người già, hoặc đứng cùng phe để giúp một người thân đang gặp khó khăn. Nó giống như sự khác biệt giữa một người bản ngữ cứ thế nói một cách tự nhiên và một người đang chật vật học ngôn ngữ
Anh ấy gặp khó ở những chỗ tôi vẫn xem là hiển nhiên, như thụt lề nhất quán hay thực sự đọc thông báo lỗi của trình biên dịch và dùng chúng để debug. Mất vài năm anh ấy mới đạt tới mức có thể xin việc làm lập trình viên, và thực ra tôi cũng mất vài năm; chỉ là tôi đã quên mất điểm xuất phát của mình mà thôi
Kỹ sư giỏi nhất ở công ty tư vấn của tôi hầu như không đọc sách vì ADHD nặng, nhưng có kinh nghiệm thực chiến cực lớn và đọc đủ tài liệu cùng các bài blog chất lượng cao, nên có vẻ phần nào tương đương. Từng có một người rất xuất sắc nói rằng “sách không giúp ích nhiều lắm”, nhưng lại kể vanh vách năm cuốn sách đã đọc trong năm đó. Dù bản thân sách có thể không quá hữu ích với người đó, có vẻ chính kỷ luật mở ra đọc năm cuốn sách ấy đã đưa anh ta lên đỉnh
Cảm giác đó đến từ một lượng khổng lồ luyện tập có chủ đích
Đoạn “những kỹ sư trong suốt sự nghiệp chưa từng thật sự thử cho đến nơi” khớp 100% với trải nghiệm của tôi
Tôi không phải lập trình viên thiên tài; tôi nghĩ mình có đủ năng lực để tạo ra các giải pháp ổn cho những vấn đề quy mô nhỏ được giao, và cũng có cảm giác về cách tiếp cận đúng sai, nhưng thậm chí tôi cũng không chắc mình có thể phỏng vấn vào FAANG hay không. Khi làm việc tôi luôn ở trạng thái cảnh giác, như thể chỉ cần lơ mắt một chút là gremlin sẽ bò vào
Kiểu như chỉ nhìn 30 giây một PR đã được hai kỹ sư senior phê duyệt mà phát hiện ra lỗ hổng bảo mật nghiêm trọng, hoặc thấy một mẫu tải dữ liệu ổn với 5 bản ghi đã test nhưng trên dataset thực tế lại bắn 300 truy vấn cơ sở dữ liệu cho mỗi trang, hoặc thấy đoạn code dùng 75% thời gian CPU để khôi phục object ngày tháng từ timestamp rồi ngay sau đó vứt bỏ. Rốt cuộc có vẻ là thiếu tò mò, quan tâm và đam mê bẩm sinh với lập trình
Với tôi, lập trình tốt gần với tinh thần thủ công lành nghề. Khi vì yêu cầu kinh doanh mà phải triển khai một miếng vá tạm bợ, tôi có một cảm giác khó chịu khó diễn tả; nếu đó là thứ mình làm ra thì dù không quá gắn bó với chính sản phẩm, tôi vẫn muốn làm cho nó tốt. Tôi thường nghe câu “tôi không biết làm sao để nó chạy nên làm đại như thế này”, nhưng ý nghĩa thực tế gần như luôn là “cách thử đầu tiên gặp một trở ngại nhỏ nên tôi không thử tiếp nữa”. Codebase càng tệ đi thì càng khó có những đóng góp khiến mình tự hào
Tôi tự hỏi liệu chỉ là tôi đã đi làm ở những công ty đặc biệt tệ, hay toàn ngành thật sự ở mức này
Bản thân anh ấy không biết, nhưng rockstar của đội chúng tôi chính là anh ấy. Nhìn các ví dụ thì có vẻ đồng nghiệp của bạn không mấy quan tâm đến việc của họ
Tôi là người mọi người gọi khi có sự cố, khi cần xử lý bất đồng ý kiến, khi cần sửa thứ tưởng như không sửa được, hoặc khi cần tìm hiểu điều gì đó. Tôi chưa bao giờ cảm thấy mình xứng đáng, và chắc ở một nơi như Facebook tôi không trụ nổi một ngày. Tôi không có khả năng hòa hợp tốt với đội hay chịu đựng cấu trúc chính trị, nên tôi thích những góc tối
Nếu hỏi toàn ngành có ở mức này không, thì thực tế còn tệ hơn nhiều. Số người trong ngành đã đông hơn bao giờ hết, và gần như không thể tìm được người thật sự biết gì đó. Cần xây dựng một danh sách những người đáng tin cậy trong 5–10 năm, rồi tuyệt đối đừng buông, hãy giữ liên hệ với họ
Vì khó ẩn mình trong đám đông; tất nhiên ở công ty thuộc mọi quy mô đều có những người thông minh và tận tâm. Đừng cứ tiếp tục dập lửa mãi, hãy tìm đến những người chia sẻ hoặc tôn trọng các nguyên tắc của bạn, rồi sẽ ổn thôi
Tôi đã thấy quá nhiều người chỉ ném code vào issue mà không có mấy quan tâm, chú ý hay tò mò, rồi cho rằng thế là ổn. Sếp cũ của tôi tìm những người có “ngọn lửa”, và xét việc ông ấy tuyển tôi, có lẽ lúc đó tôi cũng có nó
Những lập trình viên không có ngọn lửa ấy vẫn có nơi để đi, và ngược lại tôi cũng từng thấy các tổ chức khổ sở vì cố chỉ gom những người như vậy. Nhưng cũng có nhiều sinh viên tốt nghiệp bootcamp bước vào ngành vì tiền hoặc vì nghĩ đây là nghề ổn định, và ngoài điều đó ra thì họ thường không mấy quan tâm
Nếu năm 2025 có đủ doanh thu để có thể tuyển người vào năm 2026, hãy thử gửi email cho công ty tư vấn nhé
Phần quan trọng là đọc “đúng sách”. Hồi cấp ba tôi từng đọc vài cuốn sách phát triển bản thân, và chỉ cần đọc vài cuốn là nhận ra, như chính tác giả nói, phần lớn chúng gần như là fanfic
Trong lúc đọc, tôi cứ tự hỏi “Điều này có hiển nhiên không? Mình đã biết rồi chăng?”, sách có rất nhiều ví dụ và câu chuyện, và thường thấy mô thức lấy một ẩn dụ hay khẩu hiệu đơn giản như “skin in the game” rồi mở rộng thành triết lý cho toàn bộ cuộc sống
Nhóm thứ hai nhớ thông tin tốt hơn rất nhiều. Con người bị cuốn hút bởi câu chuyện, và có lý do khiến những sử thi cổ xưa nhất đều là chuyện kể. Sách phát triển bản thân đi theo công thức đó cũng vì nó có hiệu quả. Đọc một thứ, hiểu nó, áp dụng nó, rồi thành thạo việc áp dụng đó là những chuyện rất khác nhau
Tôi cho rằng trọng tâm của những cuốn sách kiểu này là giúp người đọc hoàn toàn tiếp nhận một ý tưởng, thói quen hay quy trình nào đó, và tạo ra khả năng áp dụng nó gần như theo bản năng khi tình huống xuất hiện. Có cuốn chỉ cần là một bài blog là đủ, cũng có những đoạn dài dòng tệ hại chỉ để tăng số trang, nhưng nhiều câu chuyện và tự sự là thiết bị nhằm để độc giả tìm thấy mình trong một câu chuyện nào đó và ghi nhớ bài học thật sâu. Không thể trách một cuốn sách chỉ vì nó được đặt tiêu đề phù hợp
Tôi thường được hỏi có đọc Cal Newport không, nhưng tôi khó chịu nổi cách ông ấy trộn những nhận xét hay với những nhận xét sáo mòn rồi dựa vào ví dụ và câu chuyện. Có những chỗ cần ví dụ và chuyện kể, nhưng cách làm đó không tạo cảm giác thuyết phục. Tôi tiếc là khi viết đã không nhớ tới ba mục trên, và cũng buồn cười vì “Skin In The Game” lại chính là sách của Taleb. Không phải ý nói cuốn đó dở, chỉ là thú vị khi sách của tác giả đã giúp tôi miễn nhiễm với mô thức này lại được đưa ra làm ví dụ
Thường thì đầu sách có một hai ý tưởng hay, phần còn lại là lặp lại và đắp thêm. Vấn đề này phổ biến đến mức tôi nghĩ đa số chỉ cần nghe video tóm tắt trên YouTube là được. Một mẹo khác là luôn tìm bản in đầu tiên, vì nhìn chung chúng ngắn gọn và rõ ràng hơn
Khi bắt đầu đọc sách trở lại, thời lượng chú ý và khả năng tập trung của tôi tăng lên đáng kể, còn ham muốn lướt doomscroll cũng giảm
Nhiều điểm mà mọi người tự thấy ở mình giống ADHD cũng trùng với việc năng lực tập trung chưa phát triển hoặc bị cố ý bỏ mặc. Không phải ai cũng vậy. Nếu bạn tự chẩn đoán hoặc được chuyên gia chẩn đoán ADHD, cũng nên nhìn lại xem mình có thường xuyên rèn “cơ bắp tập trung” bằng những việc cần tập trung hay không, có tách mình khỏi rác như doomscroll hay video ngắn hay không. Có phải bạn đang tránh những việc khó như nô lệ của nỗi đau và chìm vào các hành vi làm vấn đề nặng thêm không. Tập trung là năng lực bị tiêu hao đối với tất cả mọi người
Hơi phóng đại và thực tế phức tạp hơn, nhưng về nguyên tắc chung thì tôi đồng ý. Chỉ cần thật sự quan tâm đến việc mình làm, bạn đã có thể vượt xa những người chỉ đi làm để nhận lương
Tôi đồng ý phần lớn với ý rằng “một xã hội bắt đầu dẫn dắt những người không có tài năng hay hứng thú vào lĩnh vực công nghệ thì hẳn có gì đó rất sai”, nhưng lối suy nghĩ đó dẫn tới những kết luận thú vị
Thứ nhất, toàn bộ quy trình tuyển dụng công nghệ có thể kém hiệu quả hơn vài bậc so với những gì người trong ngành vẫn phàn nàn. Ngay cả khi tìm kiếm tài năng mới vào nghề, có thể các công ty vẫn đang sàng lọc sai thứ
Thứ hai, với các nghề có “đuôi dài” như thể thao chuyên nghiệp hay nghệ thuật, động lực tài chính rất tệ. Muốn xử lý vấn đề mà tác giả thấy, cũng phải xử lý cả vấn đề này, và bản thân nó là một hố thỏ rất sâu
Thứ ba, nếu tình hình tệ đến vậy, tại sao các công ty không trực tiếp đào tạo nhân viên tại nơi làm việc
Thứ tư, chúng ta hầu như không hỏi liệu chi phí cơ hội này có đắt hơn thu nhập cơ bản hay không. Đó là vì ngày nay việc ra quyết định ở khu vực tư nhân và khu vực công có xu hướng trực giao với nhau
Ngay cả nếu họ đi hết chương trình, không ai biết sự nghiệp của họ sẽ ra sao, giả sử họ thật sự kiếm được một công việc phát triển phần mềm
Hầu hết nơi làm việc gần như coi mọi nhân viên là “đã được đào tạo đầy đủ”, và kỳ lạ thay lại xem đào tạo trong công việc như một ân huệ ban cho nhân viên. Điều này rất có thể liên quan đến văn hóa lao động công nghệ chỉ ở mỗi công ty trong thời gian ngắn
Lương trong ngành công nghệ tăng là tín hiệu cho thấy không có đủ lập trình viên. Phần lớn tăng trưởng kinh tế của Mỹ hiện nay dựa trên lập trình và công nghệ
Rốt cuộc trông giống một câu chuyện kiểu “Matlab piledriver thống trị”
Lấy đại bất cứ trải nghiệm nào trong đời mình—đọc hơn một cuốn sách, chơi guitar, có một sở thích kỳ quặc, trở thành vận động viên thể dục bán chuyên—rồi nhét vào đó để dựng nên một khung chuyện biện minh cho một bài rant dài về việc bản thân xuất sắc thế nào hoặc người khác ngu ngốc ra sao mà chẳng cần nhiều nỗ lực
Đọc sách giống chất xúc tác và điểm khởi đầu hơn, còn thứ thực sự khiến mọi chuyện khớp lại là luyện tập. Và điều quan trọng là đủ hứng thú để tự tìm hiểu và trực tiếp thử nhiều thứ
https://ludic.mataroa.blog/blog/i-will-fucking-piledrive-you...
Tôi rất đồng ý với tiền đề này. Kỹ năng của tôi chia làm ba loại: những thứ tôi tự phát minh trực tiếp từ các nguyên lý nền tảng, những thứ tôi đã đọc một cuốn sách, và những thứ tôi không làm được
Một trong những thứ tôi không làm được là tìm sách hay. Sách thì ở đâu cũng có và phần lớn là rác, nhưng những cuốn được giới thiệu thì đều tuyệt vời. Liệu có cuốn sách hay nào nói về cách tìm sách hay không?
https://www.gnooks.com/faves.php
Gnod thông thường: gnod.com
https://www.literature-map.com/
Cũng có các trang tổng hợp danh sách sách
https://www.goodreads.com/review/list/21394355-william-adams...
https://www.goodreads.com/review/list/21394355-william-adams...
Nếu không tự nhiên nhận được gợi ý, bạn có thể tìm trong phần giới thiệu/tham khảo của những cuốn bạn đã đọc và thích, các cuốn khác của tác giả bạn thích, hoặc các cuốn khác trong một bộ mà bạn đã đọc một cuốn và thấy ưng
Nếu dùng các công cụ kết hợp mô hình ngôn ngữ lớn với dữ liệu thời gian thực như Gemini, kết quả sẽ tốt hơn
Điều này liên hệ với câu “học từ những thứ người khác đã suy nghĩ và chuẩn bị trong thời gian dài, rồi tôi cố gắng tiếp thu nó trong thời gian ngắn hơn nhiều”
https://news.ycombinator.com/item?id=40147526
Đọc HN có được tính là tự phát triển bản thân không? Tôi không thể đếm nổi đã có bao nhiêu kỹ năng hay “manh mối” ý tưởng mình nhận được nhờ dành thời gian trên trang này
Nếu không có những câu chuyện ở đây, có lẽ tôi đã không nghỉ việc để trở thành founder một người. Còn liệu đó có phải lựa chọn tốt hay không thì vẫn còn quá sớm để nói
Tôi hấp thụ được rất nhiều kiến thức theo kiểu thẩm thấu mà bằng cách khác sẽ không có được. Những công nghệ tôi thực sự dùng thử chỉ là một phần rất nhỏ, nhưng tôi đã hiểu khá rõ về toàn bộ hệ sinh thái lập trình. Nó giúp tôi biết “ngoài kia có những gì” và “nên tìm kiếm cái gì”
Tuy vậy, có lẽ 95% lượng kiến thức thẩm thấu đó có thể đạt được chỉ với 10% thời gian lướt. Nhìn chung HN là cách dùng thời gian khá tốt, nhưng thường thì tôi đang cố ý lãng phí thời gian