Computer >> Hướng Dẫn Máy Tính >  >> Lập Trình >> Lập Trình

Làm programmer giỏi không chỉ là viết code

Trong tưởng tượng bạn, programmer lý tưởng là ai? Một thiên tài máy tính code từ 7 tuổi, làm app triệu đô? Một senior developer 10-20 năm kinh nghiệm, biết mọi ngôn ngữ (nhưng chỉ cái hay) và dựng website trong lúc bạn đi lấy ly cà phê? Một nghệ sĩ code viết code đẹp đến mức khiến ai nấy cùng khóc ngỡ ngàng và cắn răng ghen tị?

Ừ, có vẻ không tồi. Nhưng bạn có tin nếu tôi nói: skill code thần thánh không phải là tất cả? Và lập trình giỏi chỉ chiếm một nửa programmer giỏi?

Rõ ràng không thể thành coder giỏi nếu không biết code. Nhưng tôi cảm thấy đôi khi khía cạnh phi kỹ thuật của programmer bị bỏ quên. Rất nhiều điều về developer chuyên nghiệp không liên quan code, mà liên quan đến việc là một chuyên gia. Chuyên gia thực sự: hoàn thành việc đúng hạn, biết làm team player (chứ không phải hero lao vào cứu thế giới), và cuối cùng là tài sản cho employer hoặc client.

Đặc điểm developer giỏi là gì? Đây là vài điều tôi rút ra – chắc chắn còn nhiều hơn.

1. Viết code sạch (Clean code).

Đây thực ra là về code. Tôi đã nói code là một phần, phải không? 🙂 Cốt lõi: code tốt trước hết phải chạy, dễ hiểu cho developer khác, và refactor không gây quá nhiều đau khổ. Code giao tiếp với máy, nhưng cũng phải giao tiếp với con người. Không đếm được bao nhiêu lần phải quay lại code cũ vài tháng, tốn quá nhiều thời gian chỉ để nhớ "tháng trước mình nghĩ gì". Function đặt tên tốt, tổ chức tốt, comment, documentation sẽ hoàn vốn gấp 10 lần về thời gian tiết kiệm cho người khác (kể cả bạn sau này!).

Tham khảo viết code tốt (non-affiliate):
Clean Code
The Pragmatic Programmer
Refactoring: Improving the Design of Existing Code

2. Cập nhật xu hướng.

Chúng ta biết xu hướng web dev thay đổi nhanh như thế nào. Không nói bạn phải là "magpie coder" (coder nghe cái mới là chạy theo). Nhưng cực đoan kia: thoải mái rồi tự mãn → thành "dinosaur coder" (coder khủng long lỗi thời) – tệ hơn nhiều. Có điểm cân bằng: giỏi vài core skill, nhưng ít nhất nắm rõ xu hướng và tin tức khác.

Một số publication giúp theo dõi ngành thay đổi liên tục. Tự do comment thêm nguồn hữu ích khác.

Hacker News
A List Apart
Smashing Magazine
CSS Tricks

3. Cởi mở với điều mới và học nhanh.

Nếu vẫn ở đầu đường học code, đừng quá khắt khe. Không nói bạn phải master Angular trong 1 tuần. Nhưng cởi mở với khả năng: giải pháp cho bất kỳ vấn đề nào có thể là điều bạn chưa biết. Và "chưa" là từ khóa quan trọng. Vì điều bạn chưa biết? Chỉ là điều bạn có thể học và thêm vào toolkit.

Quan trọng: học điều mới nhanh và hiệu quả càng tốt. Càng nhanh nắm bắt, càng nhiều thời gian code và học điều mới khác. Học kỹ năng coding bản thân là một skill có thể học.

4. Tập trung và làm việc hiệu quả.

Chúng ta biết multitasking không thể với con người, vì não hoạt động single-thread. Chỉ có thể switch task, nhưng không hiệu quả và không lý tưởng. Tùy job/hoàn cảnh, interruption có thể là phần của đời thường. Điều đó làm việc quan trọng hơn: tận dụng tối đa thời gian hữu hạn cho coding.

Cố tách biệt thời gian làm việc và không làm việc, đừng để tràn vào nhau. Ví dụ: lật Facebook vài phút/lần cắt vào productivity. Làm việc: đóng tab browser khác, làm việc liên tục đến milestone hợp lý. Dùng pomodoro timer (25 phút) giúp focus vào single task.

Đọc thêm:
Deep Work by Cal Newport

5. Ước lượng thời gian hoàn thành task chính xác.

Điều này khó, và tôi thừa nhận vẫn đang cải thiện. Nhưng đánh giá chính xác khả năng theo giờ là skill quý giá. Dù làm thuê hay freelance, ước lượng sai làm hỏng timeline project và tạo việc cho người khác. Tồi nhất: underestimate dự án → tốn tiền bạn hoặc employer.

Lưu ý nhanh: không cần chính xác đến giờ X, viết trên đá. Thường cho range, hoặc nói không ước lượng được vì cần thêm info về project. Cách bắt đầu ước lượng: track thời gian khi code. (Cái này đi kèm #4, vì ước lượng tốt hơn khi không lướt Reddit nửa ngày).

6. Giải thích concept kỹ thuật cho người non-tech.

Đúng, nó frustrating. Khi bạn bơi lội trong block code và method, rồi phải nổi lên thế giới thực giải thích cho người không phải programmer? Tại sao họ không đọc source code hiểu ngay?

Coder điển hình: người cô đơn chỉ muốn hụt hẫng hang động đất hack bàn phím, không bị làm phiền bởi thế giới bên ngoài. Tôi thừa nhận: khi đắm chìm debug vấn đề khó, bị ngắt quãng làm vỡ nhịp và cáu kỉnh. Nhưng giống bạn, người non-tech bạn làm việc cùng có chức năng sống còn. (Đầu tiên: họ nói chuyện với mọi người, bạn không phải!)

Làm việc tốt với team = giải thích code cho họ hiểu, theo cách họ hiểu. Bước 1: hiểu rằng bạn nhìn thế giới qua bài toán code, người khác vận động quanh tiền, deadline, client.

Nếu nói chuyện theo thuật ngữ và vocab của họ, bạn sẽ đi xa như team player. Ví dụ: được yêu cầu thêm feature. Thay vì hét "Ngu lắm không làm!" chạy về hang, hãy giải thích: feature đó thêm 20h làm việc, deadline có thể phải lùi.

7. Đừng mang ego vào nơi làm việc.

Đạt 100% mỗi ngày bất khả thi trừ người cực xuất sắc. Nhưng có thể thử không bị điều khiển bởi ego. Nghĩa là: không chỉ lo mình đẹp. Muốn project, team, company cũng đẹp. Nếu nỗ lực giúp người khác và đảm bảo thành công chung, không chỉ bản thân, mọi người sẽ thích làm việc cùng bạn.

Nếu đạp người khác để đạt mục đích cá nhân, bạn tự đốt cầu. Bạn sẽ ở giữa khi nó sập. Có thể có lợi ngắn hạn, nhưng bạn thực sự muốn thành "keo ly" mà ai cũng ghét làm việc cùng?

8. Đừng giấu lỗi lầm.

Không ai thích sai. Chỉ là con người. Nhưng làm professional, phải chinh phục bản năng giấu lỗi.

Nếu sai làm ảnh hưởng tiêu cực đến project, điều tốt nhất cho bản thân và đồng nghiệp: thú nhận ngay lập tức. Báo cho sếp, client, ai cần biết, và bắt đầu xử lý (triage). Che giấu hy vọng không ai biết có thể thành công đôi khi, nhưng nếu bị phát hiện → phá vỡ niềm tin nghiêm trọng, có thể nguy hiểm project thậm chí việc làm.

Không cần báo mỗi lỗi nhỏ. Nhưng lỗi cần thời gian sửa thêm hoặc làm hỏng thứ quan trọng → hãy "thú nhận". Tốt hơn cho dài hạn.

9. Biết nhờ giúp đỡ và giúp đỡ người khác.

Đừng ngại hỏi khi kẹt hoặc không hiểu. Làm project có deadline, đừng mất giờ tự mò khi nhờ giúp có giải pháp < 1 giờ.

Cần cân bằng: tự đi xa nhất có thể bằng Google, StackOverflow, Slack. Nhưng có xu hướng, nhất là ở công ty, muốn independent, làm mọi thứ không cần giúp. Thực sự tốn thời gian. Khó, nhưng nuốt nhục 인정 cần giúp. Sẽ học nhanh và xong việc nhanh hơn.

Mặt bên: giúp người khác khi họ cần. Khi mới bắt đầu web dev, tôi nhờ nhiều người senior ở công ty, giúp rất nhiều. Khi đã senior hơn, người mới thường nhờ giúp. Bị ngắt quãng không vui, nhưng cũng là một phần team player. Nếu đang deep coding, báo "vài phút nữa quay lại". (Trừ khi vấn đề thực sự urgent).

Khi ai nhờ giúp, hãy giúp cách giúp họ thành công lần sau. Thay vì chỉ cho đáp án, cho context để hiểu nguyên lý và cách fix. Cái gọi là "dạy người câu cá" 🙂

Có điều nào cộng hưởng hoặc đánh trúng tim bạn? Không đồng ý điều nào? Comment bên dưới tự do nhé!