Programmer thế hệ 10x được hiểu là người có khả năng làm việc gấp 10 lần người khác, chúng ta có thể hình dung programmer thông thường là người làm tốt công việc nhưng không thể có khả năng gấp 10 lần như programmer 10x được. Thật ra cụm từ “normal programmer” nghe khá hơn khi nói ai đó có khả năng thường thường so với những người giỏi programming.

Cộng đồng programming biết rất rõ khi có ai đó phủ nhận những programmer 10x: Làm sao mà có programmer 10x được!. Thực ra nếu biết tìm ở đâu, thậm chí sẽ có programmer 100x lận ấy!


Nếu bạn xem programming như một quy chuẩn tuyến tính, rõ ràng những programmer 10x nghe thật vô lý. Làm sao một người có thể chạy nhanh hơn người khác 10 lần chứ? Hay một công nhân xây dựng làm việc gấp 10 lần so với công nhân khác trong cùng khoảng thời gian? Tuy nhiên, programming là một quy chuẩn sáng tạo theo một cách đặc biệt. Thậm chí một programmer không tham gia vào thiết kế một chương trình, việc bổ sung yêu cầu một bản thiết kế phụ cho chiến lược bổ sung sau đó.


Vậy nếu như thiết kế và bổ sung một chương trình không phải những yếu tố tuyến tính như kinh nghiệm, khả năng code, kiến thức, nhận biết vấn đề, thì có thể đó không phải lợi thế tuyến tính, họ làm việc cùng nhau theo rất nhiều hướng để tạo ra một chương trình. Tất nhiên hiện tượng này xảy ra nhiều hơn khi một programmer có thể đảm nhiệm cả việc thiết kế và bổ sung cho chương trình đó. Nhiệm vụ càng được định hướng rõ, những programmer 10x tiềm năng càng dễ dàng đột phá cho mục tiêu của mình.


Khi nhiệm vụ sắp tới quá cứng nhắc, với hướng dẫn cụ thể các công cụ và cách thực hiện thì hiệu suất công việc của programmer 10x giảm đi: có thể khai thác khả năng thiết kế cục bộ để hoàn thành công việc tốt hơn, nhưng không thể thay cách làm bằng phương pháp trước đó, có thể gồm cả phần loại trừ thông số kỹ thuật khỏi dự án, vậy nên trông có vẻ như nhau nhưng đã giảm đáng kể công sức cần bỏ ra.

 

Là programmer trong 20 năm, tôi đã làm việc chung với những programmer khác, hướng dẫn họ để đạt mục tiêu được giao, những thử thách tới Redis và các dự án khác. Nhiều người cùng lúc nói tôi chính là một programmer tốc độ. Họ biết tôi không phải kẻ nghiện việc, tôi cũng sẽ xem như nói tôi code nhanh.


Dưới đây là danh sách những phẩm chất tôi tin sẽ thay đổi rõ rệt năng suất cho programmer.


* Khả năng program cơ bản: hoàn thành task phụ


Một trong những giới hạn hay thế mạnh rõ ràng nhất của một programmer chính là hoàn tất task phụ của những nhánh nhỏ trong một chương trình: có thể là một tính năng, một thuật toán hay vài thứ đại loại vậy. Ngạc nhiên là khả năng sử dụng programming cơ bản rất cần thiết để làm việc tuy nhiên không khá phổ biến như mọi người nghĩ. Trong team của tôi có những programmer rất kém, họ thậm chí không biết những thuật toán phân loại đơn giản nhưng làm việc tốt hơn trong khi những programmers rất thạo lý thuyết nhưng thực hành dở tệ.

 

* Kinh nghiệm: so với người khác

Bằng kinh nghiệm tôi muốn nói đến một loạt giải pháp cho các task định kỳ. Một programmer giàu kinh nghiệm sẽ luôn biết cách xử lý những task phụ. Nó giúp tránh được rất nhiều công việc và đặc biệt là một thứ vũ khí tối tân tránh các lỗi thiết kế khó nhằn.

 

* Sự tập trung: Thời gian thực và thời gian giả thiết

Số giờ để viết code không phải vấn đề nếu không nhìn vào chất lượng trong thời gian đó. Thiếu sự tập trung có thể sinh ra nhiều yếu tố chủ quan và khách quan. Yếu tố chủ quan chính là sự trì hoãn, thiếu đam mê (bạn không thể làm tốt công việc nếu bạn không yêu thích nó), thiếu sức khỏe, vận động, mất ngủ. Các yếu tố khách quan như họp hành triền miên, môi trường làm việc không có văn phòng, đồng nghiệp phá rối thường xuyên và nhiều hơn nữa. Cố gắng cải thiện việc tập trung và giảm đi sự gián đoạn là những tác dụng góp phần tăng năng suất công việc. Đôi khi để có sự tập trung phải cần đến những phương pháp tuyệt đối. Đơn cử như tôi chỉ đọc email trong khoảng thời gian nhất định chứ không trả lời tất cả ngay.

 

Rắc rối luôn phát sinh khi không có mục tiêu tối thiểu cho những rắc rối khổng lồ phát sinh trong kế hoạch, hoặc là tiền đề cho mục tiêu khó nhằn hơn, vì có áp lực trong các tính năng cơ bản hay không. Một designer sẽ rất khó nhận ra những bộ phận khó hoàn tất, không cân bằng giữa nỗ lực và lợi thế. Một dự án được hoàn thành nhằm tối đa nguồn thu và chỉ tập trung vào những khía cạnh chính trong một khoảng thời gian xác định hợp lý nhất. Cụ thể khi thiết kế Disque, một message broker, đôi khi tôi nhận thấy việc cung cấp những lệnh, sắp đặt nỗ lực nhất cho mesages, tất cả những khía cạnh của dự án sẽ có khả năng được cải thiện: sẵn có, ngôn ngữ query và tương tác với khách hàng, đơn giản và hiệu suất.

 

* Sự tối giản

Tiêu đề đã nói lên tất cả. Để hiểu được Tối giản là gì, hãy kiểm tra lỗi thường phát sinh ra sao. Tôi tin hai lý do chính là không sẵn sàng buông bỏ bớt design, và các lỗi tích dồn trong hoạt động design.

Nếu mỗi lần công việc đi sai hướng, chúng ta mất nhiều thời gian hơn để giải quyết. Lỗi design đầu sẽ không re-design trong cùng hệ thống, nhưng sẽ tạo ra sản phẩm theo hướng phức tạp khác để giải quyết sai sót trước đó. Do đó, dự án trở nên phức tạp hơn và kém hiệu quả trong các bước tiếp theo.

Có thể đạt được sự tối giản với “proof of concepts”, có thể tìm ra nhiều design đơn giản từ programmer để bắt đầu từ những thứ dễ thấy nhất và hướng giải quyết trực tiếp. Sau đó, kinh nghiệm và khả năng cá nhân sẽ hỗ trợ design và tìm ra cách phù hợp cho các design phụ cần sửa.

Tuy nhiên, khi cần những giải pháp phức tạp thì phải mất thời gian để lựa chọn phương án đơn giản hơn, và chỉ làm theo cách đó nếu không còn lựa chọn nào.

 

Chủ nghĩa hoàn hảo gồm hai biến thể: văn hóa xây dựng hiệu suất dễ dàng nhất trong chương trình, và một là đặc điểm cá nhân. Trong cả hai trường hợp, tôi thất một trong những khó khăn lớn nhất cho programmer là chuyển giao mọi thứ nhanh chóng. Chủ nghĩa hoàn hảo và nỗi lo bị mọi người đánh giá sẽ giới hạn lại những lựa chọn để việc trau chuốt design chỉ dựa vào thang đo tâm lý hay tiêu chuẩn thông thường mà sự vững chắc, đơn giản, khả năng chuyển giao đúng giờ đều vô nghĩa.

Khi giải quyết các task phức tạp, hiểu biết về cấu trúc data, những hạn chế cơ bản về toán và không biết thuật toán cơ bản thì sẽ rất phù hợp với các task có mẫu cụ thể, chắc chắn sẽ giúp tìm ra được design phù hợp.

Không cần phải là siêu chuyên gia, nhưng ít nhất phải nắm chắc các giải pháp tiềm năng cho một vấn đề. Ví dụ như bỏ bớt design ( ngoại trừ vài trường hợp lỗi) và biết các chuyên gia đánh giá các yếu tố theo xác suất, có thể kết hợp với nhau và tránh giải pháp khó nhớ, chậm chạp và phức tạp, mang lại sản phẩm tuyệt nhất.

Những vấn đề trong program phát sinh như không biết làm việc ra sao khi sử dụng các ngôn ngữ cấp cao. Điều đó dẫn đến việc re-desinging và re-implementing một dự án lỗi vì vấn đề cơ bản nằm ở công cụ hoặc thuật toán sử dụng. Thông thạo ngôn ngữ C, biết cách vận hành CPU, cốt lõi vấn đề là gì và lệnh hệ thống được thực hiện ra sao, có thể lật ngược tình thế.

* Kỹ năng debug

Tìm ra bug dễ mất rất nhiều thời gian công sức. Tổng thời gian định vị được một bug để fix lại từng bước có thể ảnh hưởng rất nhiều tới hiệu suất của programmer trong khi viết những code đơn giản sẽ không chứa quá nhiều bug.

Chẳng có gì lạ khi những đặc điểm trên có thể tăng output lên 10 lần. Đơn cử design bắt nguồn từ những model khả thi có thể đơn giản hơn mấy lần những mẫu dự phòng. Có một cách để đơn giản hóa gọi là “opportunistic programming”. Ở mỗi bước develop, loạt tính năng được dùng để tối đa ảnh hưởng lên người dùng thường xuyên của chương trình, với công sức bỏ ra ít nhất.

Nguồn: Antirez

Related