코드 작성이 과학이라면 모든 개발자는 거의 동일 할 것입니다.
예술에서와 마찬가지로 두 개발자는 동일한 결과를위한 코드를 작성하는 동안 동일한 생각이나 인식 또는 주관적인 진실을 가지고 있지 않습니다.
어떤 사람들은 원하는 결과를 내기 위해 고군분투하지만, 몇몇 사람들에게는 마치 프로그램을 만들거나 문제를 해결하기 위해 앉아있는 순간에 깨달음을 얻는 것처럼 거의 자연스럽게 다가옵니다.
안에 블로그 게시물 , Steve McConnell (소프트웨어 엔지니어링 전문가로 인용)은 개별 프로그래밍 생산성의 큰 변화를 발견 한 원래 연구가 Sackman, Erikson 및 Grant에 의해 1960 년대 후반에 수행되었다고 썼습니다. 그들은 최고의 프로그래머와 최악의 프로그래머 사이의 초기 코딩 시간의 비율이 약 20 대 1이라는 것을 발견했습니다. 그들은 프로그래머의 경험과 코드 품질 또는 생산성 사이에 아무런 관계도 발견하지 못했습니다.
이 연구에는 결함이 있었지만이를 고려한 후에도 데이터는 여전히 최고의 프로그래머와 최악의 프로그래머 사이에 10 배 이상의 차이를 보여줍니다.
로버트 발레타 순 가치 2017
Arkenea에서 우리는 개발자를 고용 한 경험이 5 년 이상이며 훌륭한 프로그래머에게 좋은 프로그래머를 말하는 것이 초기에 그랬던 것처럼 어렵습니다.
독특한 도전이 아닙니다. 산업 전반에 걸쳐 많은 대기업과 기업이 동일한 문제로 어려움을 겪는 것을 보았습니다. 많은 사람들이 다양한 테스트를 통해 필터링 프로세스를 만들었지 만 실제로 아티스트를 테스트 할 수 있습니까?
정답은 아니오입니다.
프로그래머가 훌륭한 자원인지 판단 할 때 좋은 코드를 작성하는 것이 유일한 요소는 아닙니다.
그러나 방법이 있습니다. 훌륭한 프로그래머와 좋은 프로그래머를 구분하는 다른 지표 (코드 작성의 질과는 별개)가 있습니다.
Christopher Burke,에 대한 응답 Quora , 문제를 해결하기 위해 작업 프로그램을 작성할 수있는 사람은 누구나 프로그래머라고 강조했습니다. 반면에 좋은 프로그래머는 다른 사람과 협력하여 대인 드라마가 거의 또는 전혀없이 고객이 적시에 사용하기에 적합한 유지 보수 가능하고 우아한 프로그램을 낮은 결함률로 만드는 사람입니다.
그러나 훌륭한 프로그래머를 만드는 것은 알고리즘과 아키텍처를 직관적으로 이해하고, 거의 감독없이 자체적으로 일관된 대규모 시스템을 구축 할 수 있고, 새로운 알고리즘을 개발할 수 있으며, 라이브 시스템을 깨지 않고 리팩토링 할 수 있으며, 기술 분야의 비 기술 직원과 효과적이고 일관성있게 커뮤니케이션 할 수 있다는 것입니다. 비 기술적 문제, 자존심을 억제하는 방법을 이해하고 자신의 기술을 다른 사람에게 가르 칠 수 있습니다.
그러나 내 경험상, 나는 그의 프로그래머에 대한 정의를 좋은 프로그래머의 정의와 동일시하고 좋은 프로그래머에 대한 그의 정의를 위대한 프로그래머의 정의와 동일시 할 것이다.
크리스토퍼가 훌륭한 프로그래머라고 부르는 사람은 자신의 경력의이 단계에 도달했을 때 반드시 코드를 작성하지 않을 것이라고 말하고 싶습니다. 그 사람은 회사 및 개발 팀과보다 전략적으로 협력하여 제품 방향을 제시 할 것입니다. 본질적으로 CTO와 같은 사람입니다.
문제가 해결 될 때까지 기꺼이 문제에 머 무르려는 의지 (문제에 앉아있는 것과 혼동하지 않음)와 창의적으로 해결할 수있는 능력은 훌륭한 프로그래머에게만있는 매우 바람직한 기술 또는 적성입니다.
켈리 피클러 순 가치 2016
그래서 전형적인 질문입니다. 훌륭한 프로그래머를 어떻게 식별합니까? 이 사람은 문제의 근원에 빠르게 도달 할 수 있습니다. 그 또는 그녀는 즉시 해결책을 제공하지는 않지만 빠르고 효과적으로 해결책을 찾을 수있는 경로를 계획 할 수 있습니다.
