- Bob, kỹ sư huyền thoại của Facebook, đã ra mắt Facebook Groups và liên tiếp tạo ra thành quả trong các hackathon ngay cả khi không có môi trường phát triển cầu kỳ
- Anh chỉ dùng Sublime Text mặc định và log
printf; môi trường đó có tô sáng cú pháp không chính xác, không có live reloading hay debugger - Trong khi đó, các lập trình viên xung quanh lại xem cấu hình công cụ phức tạp như tô sáng cú pháp và snippet cho Vim,
tmux,mosh, phím tắthphpd, bí danh Git là cốt lõi của năng suất - Chiến thắng hackathon của Bob chịu ảnh hưởng lớn hơn từ cảm quan sản phẩm và trực giác, tức khả năng phán đoán nên làm gì, chứ không phải từ thiết lập trình soạn thảo
- Cách làm việc mới có thể tạo ra thay đổi, nhưng rốt cuộc thành quả vẫn đến từ giải quyết đúng vấn đề
Khác biệt giữa công cụ phức tạp và kết quả thực tế
- Bob là kỹ sư làm việc năng suất cao đã ra mắt Facebook Groups và là nhân vật huyền thoại liên tục đưa ra sản phẩm trong các hackathon
- Khi đó, một đồng nghiệp ám ảnh với năng suất đã dùng tô sáng cú pháp và snippet tự làm cho Hack, phương ngữ PHP của Facebook
- Chạy
tmuxtrênmosh, đồng thời còn cấu hình cả phím tắthphpdtùy chỉnh và bí danh Git
- Chạy
- Trái ngược với điều đó, cách làm việc của Bob rất đơn giản
- Anh dùng Sublime Text không thiết lập gì thêm, nên khoảng một nửa màu mã nguồn hiển thị sai
- Thay vì live reloading hay debugger, anh chèn
printfvào mã rồi chờ log xuất hiện
- Trong hackathon hôm đó, Bob đã chiến thắng, và sản phẩm được nhớ là tính năng hỗ trợ bài đăng mua bán trong Facebook Groups
- Tính năng này về sau phát triển thành Facebook Marketplace
Quan trọng là làm gì hơn là làm như thế nào
- Nếu quá tập trung vào công cụ phức tạp, bạn có thể bị cuốn vào làm như thế nào mà bỏ lỡ làm cái gì
- Yếu tố cốt lõi tạo nên năng suất cao của Bob không phải thiết lập trình soạn thảo mà là cảm quan sản phẩm và trực giác
- Trên X mỗi ngày đều xuất hiện những cách làm việc mới như thể sẽ thay đổi mọi thứ, và một số trong đó thực sự có thể tạo ra khác biệt
- Nhưng điều quan trọng nhất không phải bản thân công cụ hay cách làm việc, mà là giải đúng vấn đề
1 bình luận
Ý kiến trên Hacker News
Chia con người thành hai kiểu là người thợ trân trọng công cụ và người ám ảnh công cụ là sai. Công cụ tốt không phải đồ chơi mà là phương tiện phục vụ mục đích, và tôi cũng từng dành nhiều ngày để tạo shell script, hàm Emacs, công cụ bố trí cửa sổ... phù hợp với luồng làm việc của mình
Kết quả là tô sáng cú pháp, điều hướng/phân tích mã, bố trí màn hình, thao tác Git đều chỉ cần vài lần bấm phím, và những thứ làm đứt mạch tập trung đã biến mất. Hãy đầu tư vào môi trường làm việc như ghế ngồi, shell prompt, trình soạn thảo, nhưng khi đã thấy thoải mái rồi thì nên quên nó đi và tập trung vào vấn đề thực sự
Tuy vậy, việc tinh chỉnh công cụ bất tận có thể là dấu hiệu đang né tránh những nhiệm vụ nặng nề và không thú vị, và đây không phải vấn đề đơn giản có thể đổ lỗi cho bản thân công cụ
Đặc biệt, công cụ trong thời đại LLM khiến người ta phải liên tục qua lại giữa nhiều agent và terminal. Việc chuyển ngữ cảnh liên tục này cướp mất niềm vui và trạng thái nhập tâm, nên mong là ai đó sẽ tìm ra lời giải
Tôi đã thấy nhiều kỹ sư dành nhiều thời gian cho tối ưu thiết lập môi trường hơn là cho việc thực sự tạo ra thứ gì đó, và bản thân tôi cũng từng như vậy. Nghĩ rằng 90% thời gian lập trình là gõ phím nên phải tăng tốc độ nhập là sai; 90% thời gian nên dành cho suy nghĩ, và phần lớn trong đó là để đọc
Việc viết mã ở thời điểm thích hợp gần như là thao tác gõ để cụ thể hóa lời giải đã hiểu sẵn
Xét ở khía cạnh AI hạ thấp rào cản ban đầu, nó cũng là một dạng cải thiện môi trường khác. Trước đây khi từ vai trò QA muốn chuyển sang developer, tôi từng đi du lịch khắp châu Âu và học InterviewCake, nhưng lại phí thời gian chỉnh cấu hình editor nhiều hơn là giải bài toán
Đây cũng có thể là triệu chứng của ADHD. Gần đây sau điều trị bằng thuốc, năng suất của tôi thay đổi rất lớn, và tôi gần như muốn khóc khi nghĩ mình đã lãng phí nửa đời để hoàn thiện cấu hình thay vì làm công việc thật sự
Có những công ty được VC rót vốn nhưng lại không thể tạo ra sản phẩm mà người ta thật sự dùng hoặc trả tiền. Họ cố chứng minh định giá bằng cách cho thấy mình bận rộn và năng suất đến mức nào, và cơn sốt AI cũng có thể nằm trong cùng mạch đó ở chỗ chỉ tập trung vào năng suất và phương pháp hơn là vào việc sẽ tạo ra cái gì
https://components.news/the-gamer-and-the-nihilist/ so sánh các startup hư vô kiểu này với các studio game làm ra sản phẩm mà người ta thực sự trả tiền để dùng. Trong một nền kinh tế nơi app năng suất chiếm gần 40% kết quả trên Product Hunt, lao động đôi khi được đổ vào việc trông như đang tạo ra thứ gì đó hơn là thực sự tạo ra nó
Tôi chỉ làm hoặc dùng công cụ năng suất ở mức đủ để không bị tụt lại, còn hơn thế thì xem là cái bẫy. Trước kia tôi kiểm tra mỗi quý một lần, nhưng từ sau AI thì đang dành 1~2 ngày mỗi tuần cho công việc meta là cải thiện công cụ, và tôi đoán điều này sẽ giảm đi khi các công cụ liên quan được chuẩn hóa
Nếu hình ảnh chuyên gia công cụ quá mạnh, bạn không chỉ bỏ lỡ công việc thực sự có giá trị mà còn bị đánh giá như người sở hữu bí kíp năng suất bí mật. Nếu khác biệt thực tế không lớn như kỳ vọng, người khác thậm chí có thể mất niềm tin vào các phán đoán khác của bạn
Tôi càng ít ngồi trước máy tính thì lại xử lý được càng nhiều việc, và khi giảm từ 3 màn hình xuống còn 1 thì năng suất tăng đáng kể. Tôi giải quyết hầu hết vấn đề khi cắt rau hay cắt cỏ; ngồi trước thứ công nghệ phát sáng không có nghĩa là sẽ đưa ra quyết định nhanh hơn hay tốt hơn
Lý do tôi thường cho kết quả tốt hơn đội phát triển của khách hàng cũng là vì tôi không phải nhân viên chính thức nên có thể dừng lại đủ lâu để suy nghĩ chậm rãi. Áp lực phải giữ trạng thái xanh trên Teams và những kiểu diễn kịch năng suất như vậy tạo ra các quyết định ngu ngốc trong nhiều tổ chức
Nghĩ về lý do năng suất tồn tại, tôi đi đến giả thuyết rằng đó là nỗ lực nhằm giảm đau đớn. Nhiều kiểu tối ưu hiệu năng, bao gồm cả năng suất lập trình viên, thường trở thành nơi trú ẩn để kỹ sư né tránh những nỗi đau như sự mơ hồ của miền bài toán, chính trị nội bộ, thiếu rõ ràng, hay rủi ro thất bại
Nhưng để giải quyết vấn đề thực tế, ta phải đối mặt với thực tại: xem xét luồng công việc của người dùng đến mức tẻ nhạt, đề xuất rõ ràng chiến lược chung để có được sự hợp tác của người khác, v.v. Không cần phải tôn vinh đau đớn, nhưng một kết quả tốt luôn hàm chứa sự rèn luyện kiểu vận động viên, và ta cần nuôi dưỡng khả năng kiểm soát nỗi đau cần thiết trên sân đấu
Điểm mấu chốt là nó có dễ được công nhận hay không. Công cụ hào nhoáng thì ai cũng nhìn thấy và trầm trồ, nhưng rất ít người nhận ra một sản phẩm hay tính năng mới tuyệt vời từ một editor trống hoặc phần code khung. Vì vậy sự chú ý đổ dồn vào công cụ dễ nhìn thấy, còn câu hỏi khó và mơ hồ là nên tạo ra cái gì thì bị lảng tránh
Tôi áp dụng tiêu chuẩn kiểu Marie Kondo cho công cụ. Nếu dùng không thấy vui và nó cũng không làm cuộc sống dễ hơn thì bỏ đi; còn nếu có thì giữ lại
Năm 2004, một nhóm nhỏ mà phần lớn là lập trình viên junior được tham gia khóa đào tạo Java rất tốt và rất toàn diện. Trước khóa học, mọi người tranh luận kịch liệt và ám ảnh chuyện cấu hình IntelliJ với Eclipse, nhưng giảng viên lại bất ngờ khuyên chỉ nên dùng công cụ JDK mặc định và Notepad
Mục đích là để mọi người học điều gì đang diễn ra bên trong, và ông ấy cũng nói năng suất có lẽ sẽ không khác biệt nhiều
Lý do người ta ám ảnh việc tối ưu môi trường là vì mối liên hệ giữa công sức tập trung và phần thưởng rất dễ thấy, cụ thể và mang tính vật lý. Còn việc học trừu tượng thì không như vậy. Có nhiều bài toán học tập hơn nhiều so với chuyện tối ưu cái ghế, nên sẽ rất tốt nếu có cách khiến việc học trừu tượng cũng trở nên cụ thể hơn
Đây không phải chuyện năng suất, mà là niềm vui khi chơi với đồ chơi