같은 프로그래머의 일일 생산성 차이에 대한 연구가 있습니까?


10

인터넷에서 최고의 프로그래머의 생산성과 최악의 생산성 사이에 큰 차이를 논의하는 활동이 많이있었습니다. 이 주제를 조사 할 때 일반적인 Google 결과는 다음과 같습니다. http://www.devtopics.com/programmer-productivity-the-tenfinity-factor/

같은 프로그래머의 일상 생산성 차이에 대한 연구 나 진지한 논의가 있는지 궁금합니다.

개인적으로 매일 매일 할 수있는 양에는 큰 차이가 있으므로 다른 사람이 같은 방식으로 느끼거나 연구를 수행했는지 궁금합니다.


나는 수요일부터 주중까지 가장 잘 작동하며 월요일은 졸린 악몽과 같습니다!
superM

1
그것을 게시하고 우리는 그것을 검색하고 답변으로 게시합니다;)
PhD

1
@ 누풀, 롤! 이것은 재미 있지만 신화가 태어난 방식입니다. 누군가는 무언가를 말하고, 다른 사람들은 진실을 위해 그것을 취합니다)))
superM

1
"Workhorse Programmer"의 생산성은 숙면, 카페인 공급 및 산만 함 (일부 가족 포함)에 엄격하게 비례합니다.
Yusubov

당신은 발머 피크를 참조 할 수 있습니다 . 이것은 잘 연구되었으며 모든 코더에게는 가치있는 목표이지만 달성하기가 매우 어렵습니다. 아들 아, 당신에게 행운이 있기를 바랍니다.
호버크라프트 가득한 뱀장어

답변:


8

직장에서 매일 생산성 차이에 중점을 둔 연구 를 찾았 습니다. 엉뚱한 독서 후에, 연구는 매일 효율성에 차이가 있음을 시사하는 것 같습니다. 수집 된 데이터는 월요일이 가장 생산적인 날이며 화요일-목요일은 그리 늦지 않으며 금요일은 약 2/3 정도 효율적인 것으로 나타납니다. 토요일은 금요일의 절반 정도이며 일요일에는 거의 모든 작업이 수행되지 않습니다.

또한 많은 답변에서 알 수 있듯이 적용 가능한 수많은 요소가 있으므로 측정하기가 매우 어렵다는 점도 지적합니다. 이 연구는 또한 컴퓨터 과학 또는 관련 분야에만 국한 되지 않습니다 .


+1-흥미 롭습니다. 대규모 x 회사 연구는 단순히 근무 시간을 측정하는 것처럼 보이지만 단일 회사 연구에는 몇 가지 흥미로운 조치가 있습니다.
spining_plate

+1-요일별 오류율 섹션이 마음에 듭니다.
Vivian River

그런 기사를 어디에서 찾습니까 !!! 정말 좋습니다. 나는 킨들에게 그것을 다운로드하면서 작동하도록 읽는다)))
superM

1

원격으로 통계적으로 유효한 것을 얻는 것이 어떻게 가능한지 알지 못합니다. 특정 날짜에 어떤 유형의 작업이 할당되었는지에 따라 많은 차이가 있습니다. 내가 가장 간단한 일을하고 있다면 확실히 더 많은 것을 성취 할 수 있지만, 많은 연구가 필요한 일을 할 때는 진전이 덜한 것 같습니다. 고객 회의, 요구 사항 반송, 불량 부전공 학사 또는 계정 관리자 등도 마찬가지입니다. 생산성에 영향을 줄 수있는 가능한 요소가 너무 많아서 풀리지 않는 질문입니다.


많은 시간과 돈이 있다면 측정 가능한 데이터 (코드 라인, 체크인, 회의, 모든 비즈니스 자료)를 수집하여 1 년 또는 2 년 동안 회사 직원을 측정 할 수 있습니다. 승격 또는 일부 주관적 관리 메트릭을 사용하고 해당 데이터에 대해 PCA / PRC를 수행하면 하드 데이터와 소프트 평가를 연관시키는 메트릭을 생성하기 위해 가장 큰 차이를 포착하는 더 작은 요소 집합을 제공 할 수 있습니다. 이것은 항상 사실이 아니다 생산성 => 직무 수행을지지하지만, 시작이다
spinning_plate

그러나 유효한 통계 샘플을 얻으려면 모든 언어와 성별, 대기업, 소규모 회사 및 다양한 기업 문화의 개발자를 테스트해야합니다. 데이터에 영향을 줄 수있는 가능한 요소를 적절하게 다루는 통계 연구 및 샘플 선택을 설계하고 수행하는 것이 가장 어려운 부분이었습니다. 작은 샘플을 사용할 수있는 동질성이없는 경우 통계적으로 유효한 샘플 크기는 누군가가 합리적으로 지불 할 수있는 것보다 훨씬 큽니다.
HLGEM

그렇습니다 .... 단일 회사에 대해이 작업을 수행하는 것은 주관적인 평가가 필요하기 때문에 일반화되지 않습니다. 한 프로그래머의 관리의 평가는 기업에서 매우 다른 될 가능성이 높습니다
spinning_plate

1

나는 당신이 틀렸다는 것을 의심하고 업계의 모든 사람이 프로그래머와 개발자 사이에 차이가 있음을 두 가지 모두 확인했을 것이라고 생각하지만 문제는 그보다 훨씬 더 흥미 롭습니다. 연결 한 기사는 흥미로운 요점을 제공합니다. 개발자의 모든 정의에 맞는 우수한 생산성 메트릭을 찾을 수는 없습니다. 6 가지 아키 타입 (농담이기 때문에 5 개, 5 개)은 다른 기준을 가지고 있습니다. 주력 사는 더 많은 코드를 생성 할 수 있지만 혁신가는 새롭고 미친 일을 생각하기 때문에 그런 것이 아닙니다. 좋은 코더가되는 길은 여러 가지가 있으며 모든 사람이 자신의 의견에 동의하는 것은 아닙니다.

이것은 아마도 일상 업무의 차이에도 적용됩니다. 예를 들어 KLOC로이를 측정 할 수 있지만 이는 아마도 생산성의 한 측면 일뿐입니다. 이를 개선하면 생산성을 향상시킬 수 있지만, 측정 기준 / 생산 모델에 통제 할 수없는 요인 (예 : 회의)이 포함되어 있지 않지만 요인 (KLOC)과 관련성이 높은 경우 할 수있다

원본 용지 간단하고 정량화 할 수있는 퍼즐을 해결 조치 문제. 현실 세계에서는 그렇게하기가 어렵습니다. 따라서 따뜻하고 퍼지 방식을 사용하여 그날 얼마나 생산적인지에 대한 주관적인 판단 (또는 관리자)을 제공 할 수 있습니다. 이.

스스로 측정하고 싶다면 대답은 아마도 당신과 당신의 직장에 달려있을 것입니다. 몇 주 동안 로그를 유지 한 다음 재미있게 데이터를 분석하십시오. 몇 가지 아이디어 : 기본 질문에 대답하기 위해 데이터를 무작위로 두 세트로 분할하고 t- 검정을 수행하면 매일 변동성이 있는지 알 수 있습니다. 요일별로 버킷을 작성하고 분산 분석 또는 쌍별 t- 검정을 수행하여 요일에 차이가 있는지 확인할 수 있습니다.


질문자에게 자신의 질문에 대답하라고 말하지 마십시오. 그는 연구가 존재하는지 아는 사람이 있는지 묻습니다. 적절한 답변은 "직접 할 것"이 아닙니다.
David Cowden 2016 년

@David Cowden-그는 또한 주관적인 의견을 요구하고 있습니다. 나는 이것이 어려운 질문이며 왜 좋은 조치가 없을지에 대한 HLGEM의 답변과 비슷한 의견을 제시하고 있습니다. 또한, 나는 이것에 대한 연구가 그의 특정 직장에 적용되지 않을 수도 있다고 지적하려고합니다. 나는 이것이 일상적인 변동성에 대한 연구가없는 이유와 관련이 있기 때문에 부적절한 반응이라고 동의하지 않습니다.
spining_plate

@ spinning-plate 그런 다음 명확하게 설명하십시오. 물론, 연구가없는 이유에 대한 해설이 있지만, 첫 번째 대답은 "직접 측정하십시오. 대답은 아마도 당신과 당신의 직장에 따라 다를 것입니다." 그다지 도움이되지 않는 것 같습니다.
David Cowden 2016 년

그것은 공정하다 ....
spining_plate

1

모든 직업에는 동일한 변동성이 있습니다. 야구 투수는 완벽한 경기를 펼치거나 몇 이닝 후에 풀을 뽑습니다. 의사는 생명을 구하거나 수술에서 실수를합니다. 코미디언은 기립 박수를 받거나 무대를 빠져 나와 침묵합니다.

명백한 것 외에 : 카페인 수준, 수면량; 운도 있습니다. 동료가 올바른 질문을하는 경우 며칠 동안 문제를 일으킨 문제를 해결하는 단서가 될 수 있습니다.

미국에서는 표준화 된 시험 전에 "많은 수면을 취하고 좋은 아침 식사를하기 전에"같은 조언을합니다. 이것은 일반적인 생산성에 관한 좋은 조언이지만 성공을 보장하지는 않습니다.

모든 사람은 하루 중 가장 생산적이거나 가장 예술적이거나 가장 뚜렷한 느낌을받습니다. 불행히도 모든 사람이 같은 시간이 아닙니다.

프로그래머에게 최고의 4 시간 블록이 수요일 10:17에서 14:17 현지 도움임을 알지 못합니다.


0

간단한 답변이 있습니다. 왜 다시 검색해야합니까 :)

"Workhorse Programmer"의 생산성은 숙면 , 카페인 공급 및 산만 함 (일부 가족 포함 )에 엄격하게 비례합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.