Một lập trình viên giỏi có thể làm việc hiệu quả gấp 10 lần so với một người tầm thường [đóng]

Tôi đã đọc một cuộc phỏng vấn với một lập trình viên tuyệt vời (không phải bằng tiếng Anh) và trong đó anh ta nói rằng "một lập trình viên tuyệt vời có thể tốt gấp 10 lần một người tầm thường" đưa ra lý do tại sao các lập trình viên giỏi được trả lương rất cao và tại sao các công ty lập trình cung cấp nhiều cơ sở cho nhân viên của họ. Ý tưởng là có nhu cầu rất lớn đối với các lập trình viên giỏi, vì lý do trên và đó là lý do tại sao các công ty trả rất nhiều tiền để mang lại cho họ.

Bạn có đồng ý với tường trình này không? Bạn có biết bất kỳ sự thật khách quan nào có thể hỗ trợ nó?

Chỉnh sửa: Câu hỏi không liên quan gì đến kinh nghiệm; Nếu bạn nói về một lập trình viên tuyệt vời với kinh nghiệm 1 năm thì anh ta sẽ có năng suất gấp 10 lần so với một lập trình viên tầm thường với 1 năm kinh nghiệm. Tôi đồng ý rằng từ những năm kinh nghiệm nhất định trở đi, mọi thứ bắt đầu tan biến nhưng đó không phải là mục đích của câu hỏi.

Một tổng quan khá kỹ lưỡng và phân tích nghiên cứu về sự khác biệt năng suất được cung cấp trong hai bài báo được viết bởi Steve McConnell :

• Sự khác biệt về năng suất giữa các nhà phát triển phần mềm và nhóm: Nguồn gốc của "10 x"

• Nguồn gốc của 10X - Nghiên cứu cơ sở hợp lệ như thế nào?

Bài viết đầu tiên ( Biến thể năng suất ... ) nêu:

... Nghiên cứu ban đầu cho thấy sự thay đổi lớn trong năng suất lập trình cá nhân được thực hiện vào cuối những năm 1960 bởi Sackman, Erikson và Grant (1968). Họ đã nghiên cứu các lập trình viên chuyên nghiệp với trung bình 7 năm kinh nghiệm và thấy rằng tỷ lệ thời gian mã hóa ban đầu giữa các lập trình viên giỏi nhất và kém nhất là khoảng 20 đến 1; tỷ lệ thời gian sửa lỗi trên 25 đến 1; kích thước chương trình 5 đến 1; và về tốc độ thực hiện chương trình khoảng 10 đến 1. Họ không tìm thấy mối quan hệ nào giữa lượng kinh nghiệm và chất lượng mã của người lập trình.

Kiểm tra chi tiết các phát hiện của Sackman, Erickson và Grant cho thấy một số sai sót trong phương pháp của họ ... Tuy nhiên, ngay cả sau khi tính toán sai sót, dữ liệu của họ vẫn cho thấy sự khác biệt gấp 10 lần giữa những lập trình viên giỏi nhất và tồi tệ nhất.

Trong nhiều năm kể từ nghiên cứu ban đầu, phát hiện chung rằng "Có sự khác biệt về thứ tự giữa các lập trình viên" đã được xác nhận bởi nhiều nghiên cứu khác của các lập trình viên chuyên nghiệp (Curtis 1981, Mills 1983, DeMarco và Lister 1985, Curtis et al. 1986 , Thẻ 1987, Boehm và Papaccio 1988, Valett và McGarry 1989, Boehm et al 2000) ...

^{Bài viết này cũng có một lưu ý phụ thú vị:}

^{Mức độ biến đổi này không phải là duy nhất cho phần mềm. Một nghiên cứu của Norm Augustine cho thấy trong nhiều ngành nghề khác nhau - viết lách, bóng đá, phát minh, cảnh sát và các ngành nghề khác - 20% số người hàng đầu sản xuất khoảng 50% sản lượng, cho dù đầu ra là chạm, bằng sáng chế , giải quyết các trường hợp, hoặc phần mềm (Augustine 1979).}

Bài viết thứ hai ( ... Nghiên cứu cơ sở hợp lệ như thế nào? ) Đã được viết chủ yếu để giải quyết đánh giá quan trọng về bài đầu tiên của Laurent Bossavit :

• phê bình gốc bằng tiếng Pháp: Văn hóa dân gian ou fait khoaifique, bình luận les différencier
• Bản dịch tiếng Anh: Sự thật và văn hóa dân gian trong công nghệ phần mềm .

Trong bài viết thứ hai, trong phần A tìm hiểu sâu hơn về hỗ trợ Nghiên cứu hỗ trợ 10 lần 10 phút McC McCell kiểm tra lại chi tiết hơn các tài liệu tham khảo được sử dụng trong bài viết đầu tiên và kết luận:

... Khi tôi xem lại những trích dẫn này một lần nữa khi viết bài viết này, tôi đã kết luận lại rằng họ ủng hộ phát hiện chung rằng có sự khác biệt về năng suất gấp 10 lần giữa các lập trình viên. Các nghiên cứu đã liên quan đến hàng trăm lập trình viên chuyên nghiệp trong một loạt các hoạt động lập trình.

... Cơ quan nghiên cứu hỗ trợ yêu cầu 10 lần cũng vững chắc như mọi nghiên cứu đã được thực hiện trong công nghệ phần mềm. Các nghiên cứu hỗ trợ cho yêu cầu 10 lần là không theo giới hạn phương pháp luận được mô tả trong Hình 1, bởi vì chúng đang nghiên cứu chính sự biến đổi của từng cá nhân (tức là chỉ bên trái của hình). Bossavit không trích dẫn ngay cả một nghiên cứu - thiếu sót hay nói cách khác - phản ánh yêu cầu 10 lần, và tôi cũng chưa thấy nghiên cứu nào như vậy. Thực tế là không có nghiên cứu nào tạo ra những phát hiện mâu thuẫn với tuyên bố 10 lần cung cấp sự tin tưởng nhiều hơn vào tuyên bố 10 lần. Khi tôi xem xét số lượng nghiên cứu đã được thực hiện, tổng hợp tôi thấy nghiên cứu này không chỉ mang tính gợi ý mà còn là kết luận, điều hiếm thấy trong nghiên cứu công nghệ phần mềm.

Để hoàn thiện, danh sách các tài liệu tham khảo được sử dụng trong các biến thể Năng suất ... cũng được trích dẫn bên dưới:

Người giới thiệu

Augustine, NR 1979. "Luật của Augustine và các chương trình phát triển hệ thống chính." Đánh giá quản lý hệ thống quốc phòng: 50-76.

Boehm, Barry W. và Philip N. Papaccio. 1988. "Hiểu và kiểm soát chi phí phần mềm." Giao dịch của IEEE về Kỹ thuật phần mềm SE-14, số 10 (tháng 10): 1462-77.

Boehm, Barry, et al, 2000. Dự toán chi phí phần mềm với Cocomo II, Boston, Mass.: Addison Wesley, 2000.

Boehm, Barry W., TE Grey và T. Seewaldt. 1984. "Nguyên mẫu Versus Chỉ định: Một thử nghiệm đa hướng." Giao dịch của IEEE về Kỹ thuật phần mềm SE-10, số 3 (tháng 5): 290-303. Cũng trong Jones 1986b.

Thẻ, David N. 1987. "Một chương trình đánh giá công nghệ phần mềm." Công nghệ thông tin và phần mềm 29, số 6 (tháng 7/8): 291-300.

Curtis, Bill. 1981. "Thay đổi lập trình viên thay thế." Thủ tục tố tụng của IEEE 69, không. 7: 846.

Curtis, Bill, và cộng sự. 1986. "Tâm lý học phần mềm: Sự cần thiết của một chương trình liên ngành." Thủ tục tố tụng của IEEE 74, không. 8: 1092-1106.

DeMarco, Tom và Timothy Lister. 1985. "Hiệu suất lập trình viên và ảnh hưởng của nơi làm việc." Kỷ yếu hội thảo quốc tế lần thứ 8 về Kỹ thuật phần mềm. Washington, DC: Nhà xuất bản Xã hội Máy tính IEEE, 268-72.

DeMarco, Tom và Timothy Lister, 1999. Peopleware: Productive Project and Teams, 2d Ed. New York: Nhà Dorset, 1999.

Các nhà máy, Harlan D. 1983. Năng suất phần mềm. Boston, Mass.: Ít, Nâu.

Sackman, H., WJ Erikson và EE Grant. Năm 1968. "Nghiên cứu thử nghiệm khám phá so sánh hiệu suất lập trình trực tuyến và ngoại tuyến." Truyền thông của ACM 11, không. 1 (tháng 1): 3-11.

Valett, J. và FE McGarry. 1989. "Tóm tắt kinh nghiệm đo lường phần mềm trong phòng thí nghiệm công nghệ phần mềm." Tạp chí Hệ thống và Phần mềm 9, số 2 (tháng 2): 137-48.

Weinberg, Gerald M. và Edward L. Schulman. 1974. "Mục tiêu và hiệu suất trong lập trình máy tính." Yếu tố con người 16, không. 1 (tháng 2): 70-77.

Một lập trình viên thực sự khủng khiếp có thể có năng suất dưới 0 (các lỗi họ giới thiệu mất nhiều thời gian hơn để sửa chữa hơn là chỉ cần làm tất cả công việc của họ cho họ).

Và một lập trình viên thực sự tuyệt vời có thể làm những việc mà các lập trình viên nghèo và trung bình đơn giản sẽ không bao giờ đạt được, bất kể bạn dành cho họ bao nhiêu thời gian.

Vì vậy, vì những lý do này, thật khó để nói về "gấp 10 lần năng suất" hay "100 lần như năng suất".

Tuy nhiên, điều cần nhớ là hầu hết các nhà tuyển dụng lập trình viên không có nhu cầu cho họ thực hiện các nhiệm vụ khó khăn mà các lập trình viên trung bình không thể quản lý. Hầu hết các mã được viết là các trang web, dòng ứng dụng kinh doanh, ứng dụng mạng nội bộ, v.v., phần lớn thực sự không khó. Lập trình viên năng suất trong môi trường đó là người hiểu rõ nhất và thực hiện các nhu cầu của người dùng, chứ không phải là người có thể viết mã thông minh nhất.

Thật vậy, hầu hết các nhà tuyển dụng lập trình viên sẽ tốt hơn với một lập trình viên giỏi hơn là một người giỏi, bởi vì người vĩ đại sẽ chỉ cảm thấy buồn chán và rời đi. Phải tìm một kết hợp tốt giữa các lập trình viên và công việc.

Sự kiện và sai lầm của các trạng thái Kỹ thuật phần mềm (Sự thật 2, có sẵn trong bản xem trước trên amazon):

Các lập trình viên giỏi nhất tốt hơn tới 28 lần so với các lập trình viên tồi nhất, theo nghiên cứu "khác biệt cá nhân". Cho rằng tiền lương của họ không bao giờ tương xứng, họ là món hời lớn nhất trong lĩnh vực phần mềm.

(xem danh sách nguồn để nghiên cứu)

Tất nhiên, nếu bạn so sánh năng suất của một người không lập trình (hoặc một lập trình viên rất kém) với người giỏi (về kinh nghiệm và kiến ​​thức), thì sự khác biệt có thể vô cùng lớn ( n/0 == infinityđối với bất kỳ tích cực nào n), nhưng nó không công bằng cũng không so sánh hợp lý.

Mức lương của bạn có thể phụ thuộc vào nhiều yếu tố (theo thứ tự ngẫu nhiên):

• Công nghệ sử dụng
• Quốc gia / tiểu bang bạn làm việc tại
• Sự giàu có của công ty
• Loại hình kinh doanh của công ty
• Số lượng nhà phát triển trong công ty
• Bạn làm trong công ty bao lâu
• Chính trị công sở

cùng với cá nhân của bạn ...

• năng suất
• kiến thức và kinh nghiệm
• tham gia vào hoạt động kinh doanh của công ty (dành cho người khởi nghiệp)
• các kỹ năng thương lượng
• hấp dẫn và kỹ năng tình dục, lol (tốt, thông minh là gợi cảm)

Câu trả lời của tôi là "có, nhưng hãy cẩn thận với cách bạn sử dụng số liệu đó".

Một lập trình viên, như chúng ta sẽ nói, hoạt động tối ưu, là người tạo ra chức năng và gây ra ít lỗi cần sửa hơn so với bretheren hiệu suất thấp hơn của anh ta. Tôi sẽ không khó tin rằng những người này có thể thực hiện ở mức 10 lần năng suất của người khác, đặc biệt khi bạn cho rằng một lựa chọn tốt hay xấu được thực hiện trong một giờ có thể dễ dàng có 10 giờ và các lập trình viên đưa ra nhiều lựa chọn như vậy hầu hết các ngày.

Nhưng...

Bạn phải cẩn thận trong việc đo lường điều này. Tôi thực sự không tin tưởng vào hầu hết các phép đo về năng suất vì tôi đã thấy các trường hợp vô tận trong đó mọi thông số được biết đều không xem xét điều gì tôi coi là quan trọng đối với năng suất của nhóm. Vì vậy, tôi thường ghét những con số khó như vậy cho "năng suất". Dưới đây là một số ví dụ:

• Các dòng mã (LỘC) - một số liệu thường bị ghét, vì một lập trình viên thiếu suy nghĩ có thể tạo ra nhiều dòng mã khủng khiếp, dài dòng, không hiệu quả, khó gỡ lỗi trong khi một lập trình viên giỏi tạo ra một vài dòng mã thanh lịch, dễ sửa, hiếm khi bị hỏng trong thời gian nhiều hơn, nhưng đó là một sự lựa chọn tốt hơn.
• Lỗi được tạo và / hoặc thời gian để sửa - mọi người sẽ tạo ra một số lỗi và thường thì các lỗi đắt nhất được tạo ra bởi một loạt các quyết định tồi tệ mà người tạo ra vấn đề chỉ là cuối cùng trong hiệu ứng domino. Ngoài ra, trình gỡ lỗi tuyệt vời của bạn không phải lúc nào cũng là nhà thiết kế tuyệt vời của bạn - bạn cần cả hai.
• Theo hầu hết mọi số liệu, có những nhà phát triển tuyệt vời rất khó để có một nhóm, nhà phát triển 1 "siêu năng suất" đó sẽ loại bỏ 10 nhà phát triển cơ bản giỏi và tôi hiếm khi thấy ai đó có thể làm tốt mọi thứ , vì vậy chúng tôi sẽ cần hơn 1 người trong dự án.
• Không có cách nào dễ dàng giải thích cho những người tuyệt vời nhìn thấy vấn đề xảy ra trước khi họ nghiêm trọng và giải quyết chúng, đặc biệt khi vấn đề là một lỗ hổng trong quy trình - CM bị lỗi, xây dựng không hiệu quả, lỗ hổng trong thử nghiệm, lỗ hổng bảo mật - những lỗi này thường trông giống như một sự lãng phí lớn thời gian cho đến khi bạn nhận ra rằng họ cứu bạn khỏi thảm họa - không có cách nào để đo lường điều đó.
• Ngoài ra, có những người tôi cho là cần thiết trong một nhóm có quy mô nhất định mà tôi gọi là "người xây dựng sự gắn kết" - hiếm khi là năng suất cao nhất, họ thường vẫn ở mức trên 20% và họ làm công việc vô giá để giúp tăng cường những người mới, kết nối các dấu chấm và đảm bảo rằng những câu hỏi đúng được hỏi và đúng người được giữ trong vòng lặp, họ viết (không có nội dung!) phần chính của tài liệu mà mọi người đề cập đến vì đó không chỉ là tài liệu đúng, mà là nó kết hợp đúng cách Nếu bạn muốn 10 người làm việc với hiệu quả cao nhất, bạn hoàn toàn cần một trong những người này và bạn sẽ không nhận được nếu bạn đặt 10 nhà phát triển siêu hạng trong một phòng.

Nhiều hệ thống đo lường đã cố gắng tính đến các yếu tố này, nhưng tôi vẫn chưa thấy rằng có một vấn đề nào đó được tính đến, vì vậy tôi không bao giờ quá ấn tượng với các yếu tố như "một nhà phát triển giỏi có năng suất gấp 10 lần một người tầm thường "bởi vì tôi phải tự hỏi liệu số liệu có thực sự chiếm tất cả các công việc cần để đi vào một sản phẩm đang diễn ra thành công hay một nhóm phát triển mạnh, thành công.

Vì vậy, sự cảnh báo lớn của tôi là - bạn sẽ làm gì với số liệu này? Tôi sẽ sử dụng một cái gì đó như thế này để nhận thức rằng các công cụ và tài năng phù hợp có thể tạo ra sự khác biệt lớn trong cách thực hiện công việc nhưng nếu bạn cố gắng tối ưu hóa cho một nhóm nơi mỗi cá nhân tạo ra 10X sản lượng "điển hình", bạn sẽ bị ràng buộc một trường hợp thất vọng. Tốt hơn là tìm cách để nhóm của bạn thực hiện 2-3 lần những gì họ đã làm trước đây bằng cách làm việc cùng nhau tốt hơn.

Trong cuốn sách The Leprechaun of Software Engineering , Laurent Bossavit mô tả nghiên cứu về yêu cầu năng suất gấp 10 lần. Ông phát hiện ra rằng không có con số âm thanh đằng sau nó - yêu sách đã đi từ suy đoán thành "thực tế đã được xác lập" bằng một trò chơi điện thoại liên tiếp tuyên bố cụ thể hơn trong trích dẫn. Bài đăng trên blog bao gồm chương về yêu cầu 10 lần, và bao gồm các trích dẫn và trích dẫn có liên quan, là thực tế và văn hóa dân gian trong công nghệ phần mềm .

Những gì ông tìm thấy là một cái gì đó như thế này: một người nào đó vào năm 1968 đã thực hiện một nghiên cứu so sánh những người giải quyết một vấn đề gỡ lỗi cụ thể và thấy rằng một số người trong số họ đã làm điều đó nhanh hơn gấp 10 lần so với những người khác. Từ điều này, chúng tôi có thể kết luận rằng một số người giỏi hơn gấp 10 lần trong việc giải quyết vấn đề đó , hoặc chúng tôi có thể kết luận rằng một số người đã gặp may mắn , hoặc nhiều điều khác nhau. Một số người đã chọn trích dẫn điều này là (tất cả đều là paraph cụm từ) "một nghiên cứu (Sackman et al, 1968) đã tìm thấy một số lập trình viên làm việc nhanh hơn 10 lần so với những người khác". Sau đó, nó trở thành "các nghiên cứu đã chỉ ra rằng các lập trình viên giỏi tốt hơn gấp 10 lần so với trung bình" thì cuối cùng "đó là kiến ​​thức phổ biến rằng năng suất lập trình viên thay đổi gấp 10 lần giữa các cá nhân". Sau đó, một người nào đó thu thập tất cả các trích dẫn này, trích dẫn sai một nguồn gốc để nói "nhiều nhà nghiên cứu tin rằng".

Tất nhiên, nó sẽ không phải là một trò chơi trên điện thoại nếu chỉ có tính xác thực của xác nhận thay đổi: số nhân tăng lên 11 và hơn thế nữa.

" Lập trình viên năng suất trong môi trường đó là người hiểu rõ nhất và thực hiện các nhu cầu của người dùng, không phải là người có thể viết mã thông minh nhất. " (Từ câu trả lời của Carson63000 )

Điểm mấu chốt đó kết hợp với bethlakshmiĐiểm của làm cho một điểm rất lớn. Một nhà phát triển tuyệt vời có thể trở nên tuyệt vời trong một lát thực tế của anh ấy / cô ấy nhưng tan vỡ ngay khi thế giới thay đổi. Có thể theo kịp nhu cầu của doanh nghiệp là quan trọng hơn nhiều so với bất cứ điều gì khác. Vào cuối ngày, trừ khi doanh nghiệp của bạn là công nghệ, doanh nghiệp không quan tâm đến công nghệ; họ cần giải pháp. Vì vậy, tuyệt vời với các mẫu thiết kế không có nghĩa là ngồi xổm một cách khéo léo cho người dùng cuối, những người chỉ cần kết xuất dữ liệu để hiển thị trên trang web. Tôi đã thấy các nhà phát triển tầm thường bảo đảm cho mình một công việc bằng cách phục vụ cho doanh nghiệp hỗ trợ họ trong khi các nhà phát triển tuyệt vời chán nản và bỏ đi để tìm kiếm một thách thức không bao giờ kết thúc. Tùy thuộc vào tổ chức và dự án của bạn, bạn có thể cung cấp cho các nhà phát triển bị thách thức này nhưng rất có thể, sẽ có lúc bạn không nên ' t cần lượng điện năng xử lý đó. Những nhà phát triển này không thích ngồi yên như một bộ xử lý. Họ sẽ tắt máy và khởi động lại ở nơi khác.

Cuối cùng, tôi sẽ nói là ổn khi biết người biểu diễn "chủ chốt" của bạn là ai, nhưng một "nhóm" phát triển vẫn là một nhóm. Để nhắc lại bethlakshmi, " bạn sẽ làm gì với số liệu này?"Nếu bạn cần một đội hoạt động như một đội, tôi sẽ không tập trung vào các số liệu như thế này. Tôi sẽ nhận ra rằng ngay cả người chơi nhỏ nhất vẫn là một phần quan trọng của đội. Thậm chí, chỉ giảm 60% năng suất của khóa của bạn Người chơi, một người chơi đó có thể cung cấp cho đội của bạn thứ gì đó cần. Tìm hiểu xem đó là gì và cố gắng nhân nó. Đừng đốt cháy người chơi chính của bạn bằng cách giả sử anh ta nên dẫn dắt đội, tìm cách nhân lên sản lượng của mình, bằng cách làm ô nhiễm những người chơi khác bằng sự vĩ đại đó. Điều này đòi hỏi một chút sáng tạo, không chỉ là những con số. Cuối cùng, bạn có thể biết rằng điều làm cho một lập trình viên giỏi thậm chí không phải là lập trình viên, đó có thể là đồng nghiệp của anh ta, cơ hội của anh ta tại nơi làm việc hoặc thậm chí có thể là bạn.