사람이 좋은 프로그래머인지 나쁜 프로그래머인지 관리자는 어떻게 알 수 있습니까?

프로그래밍 팀과 부서를 수행하는 대부분의 회사에서 코드를 디자인하고 작성하는 프로그래머와 관리 업무를 수행하는 관리자로 구성됩니다. 코드를 작성하지 않는 것 외에도 관리자는 일반적으로 팀이 개발 한 코드를 보지도 않고 작업 기계에 적절한 IDE가 설치되어 있지 않을 수도 있습니다.

그러나 관리자는 사람이 잘 작동하는지, 무언가를 담당해야하는지 또는 특정 개발자가 가장 중요하고 책임있는 작업에 할당되어야하는지 판단해야합니다. 마지막으로 관리자는 일반적으로 분기 별 보너스를 할당합니다!

위의 내용을 효과적으로 수행하기 위해 관리자는 사람이 다른 프로그래머와 마찬가지로 훌륭한 프로그래머인지 알아야합니다 . 문제는 그들이 어떻게합니까? 그들은 사람들이 작성한 코드조차 보지 못하고 프로그래머가 개발 한 구성 요소의 품질을 직접 평가할 수는 없지만 누가 좋은 코더인지 누가 "나쁘지 않은지"에 대한 추정치는 정확합니다. 대부분의 경우!

비밀은 무엇입니까?

일반적으로 관리자는

• 프로그래머가 작업을 수행합니까?
• 동료들은 어떻게 생각합니까? 그들이 쓰는 코드는?
• 프로그래머가 관리자와 명확하게 통신합니까?
• 프로그래머는 새로운 것을 배우는 것을 좋아합니까? 그들은 다른 사람들을 잘 멘토링합니까?
• 그들은 일을 끝내기 위해 많은 관리주의가 필요합니까?
• 프로그래머는 그들의 일에서 즐거움을 얻는 것처럼 보입니까?

일반적으로 직원의 코드를 보지 못하거나 이해하는 것은 사실이지만 직원의 위의 코드는 직원이 고용주가 부과 한 프로그래밍 역할에 얼마나 적합한 지 측정하는 합리적인 대리 역할을합니다. 누군가 일을 끝내지 않고, 동료들로부터 낮은 점수를 받고, 잘 의사 소통 할 수없고, 다른 기술에 좌절감을 느끼면 익숙해지며, 항상 감독이 필요하며, 항상 불만족 스럽습니다. ' 이 작업에 잘 맞습니다. *

그러나 다른 맥락과 환경에서 그들은 매우 행복하고 열정적 일 것입니다. 어쩌면 그들이 반대 하는 그런 종류 의 프로그래머 일 수도 있고, 다른 상황에서 아주 잘 프로그래밍 할 수도 있습니다. "프로그래머"는 다른 장소에서 매우 다른 작업을 의미 할 수 있습니다. 그러나 관리자는 주로 "프로그래머"역할과 직원이 얼마나 잘 맞는지에 관심이 있습니다.

관리자가 코드를 보지 않는다는 주장에 동의하지 않습니다. 팀을 관리 할 때 모든 엔지니어의 결과 중 일부를 살펴 봤습니다. 큰 것은 코드입니다. 그러나 이메일, 디자인 문서, 백서 등이 유일한 요소는 아닙니다.

그러나 이것이 유일한 요소는 아닙니다. 한 사람이 모퉁이에 앉아 화려한 코드를 작성 하지만 대화 할 수있는 짐승이고 질문에 대답하지 않고 상태를 공유하지 않으며 개발 문제가 발생할 때 타협하지 않는 경우-나는 확실하지 않습니다. 팀에 자산. 특히 적당히 괜찮은 코드를 작성하지만 위의 모든 작업을 수행 할 수있는 사람과 비교하십시오.

다음은 보상을 제공 할 수있는 위치에있을 때 살펴볼 내용이지만, 절대적으로 장의 반응이라는 큰 경고가 있으므로이 중 어느 것도 정량화 할 수 없습니다.

• 상태 -명확하고 정확하며시기 적절합니까? 논의 될 때, 그 사람은 현재의 문제에 대해 현재의 이슈에 약간의 모호한가? 불이 붙었을 때 적기를 올릴 올바른 판단을 내립니까?
• 문제 해결 -질문과 답변이 모두 중요합니다. 그 사람은 언제 도움을 청해야하는지 또는 언제 어디서 바퀴를 돌고 있는지 알고 있습니까? 더 나은 방법은 다른 사람들이 문제를 겪을 때 해결책을 찾거나 문제의 일부가되는 데 도움이됩니까? 당신의 전문 분야에 문제가 없을 때 물러서야하는 좋은 감각조차도 몇 가지 가치가 있습니다. 또한 그룹이나 회사 외부로 나가거나 이와 같은 사이트 또는 다른 인터넷 답변으로 이동하는 것이 중요합니다.
• 비 항구 유지 회사에서도 처리에 대한주의가 일반적으로 명백합니다. 누군가가 시스템을 무력화하는 경우 시스템을 떠나는 혼돈 속에서 볼 수 있습니다. 다른 사람이 다른 사람의지도 나 아키텍처를 준수하지 않아 다른 사람의 기능을 정리하는 경우 문제가 있습니다. 보너스 포인트는 일관성과 품질을 보다 쉽게 만드는 방법을 찾는 사람들에게 제공 됩니다.
• 완료율 vs. 버그 vs. 복잡성 -작업은 완료하지만 올바르게 수행하십시오. 모두에게 몇 가지 버그가 있지만 그 사람이 신속하고 버그가있는 작업을하면 문제가 있습니다. 나는 일반적으로 이것이 일상적인 의미에서 평가할 수있는 것이 아니라는 것을 알았습니다. 그것은 릴리스 나 단계 또는 회계 분기를 되돌아보아야합니다.

그리고 다른 사람들의 의견. 나는 종종 다양한 엔지니어들이 프로젝트의 다양한 부분을 담당하는 위치에있었습니다. 때때로 팀장이 이끌고 때로는 특정 제작물 (예 : "빌드 녀석")의 소유자 일 수도 있습니다. 사람들은 극단에 대해 이야기하는 것을 좋아합니다. 영웅주의 행위 또는 문제가있는 아이들의 좌절. 일반적으로 이러한 문제에 대한 후속 조치에서 두 당사자에 대해 많은 것을 알았습니다.

인간 관리 와 관련된 요소도 있습니다 . 다른 엔지니어와 정확히 같은 엔지니어는 없습니다. 그래서 그들은 모두 같은 빛으로 빛나지 않습니다. 하나는 화려한 버그없는 코드를 작성하지만 다른 하나는 모든 사람의 코드를 손상시키는 교차 절단 문제를 해결하는 데 도움이됩니다. 하나는 개인적이고, 하나는 글을 쓰는 것이 좋습니다. 하나는 오전 9시에 일관되지 않으며, 하나는 오후 3 시까 지입니다. 뒤로 물러서야 할 필요가 있습니다. 팀에 가장 유익한 것이 무엇인지, 그리고 개인적인 편견의 요인이 무엇인지 파악하십시오. 00 AM).

이는 관리자의 기술 전문 지식에 따라 크게 다릅니다.

• 대부분의 경우, 그들은 아마도 당신이 어떻게 의사 소통 하는지 판단 할 것입니다 . 관리자와 의사 소통 하는 방법 및 동료와 의사 소통하는 방법
• 관리자와 더 가까운 수석 개발자 가 있다면 운이 좋으면 관리자가 수석 개발자의 의견을 구할 수 있습니다.
• 관리자의 주요 책임은 작업을 완료하는 것 입니다. 그는 사업 계획을 달성하기 위해 다양한 결과와 목표를 달성해야합니다. 따라서 결과에 직접적인 영향을 미치는 것처럼 보일 수 있다면 이것은 당신에게 잘 어울릴 것입니다.

일반적으로 그렇지 않습니다.

이것이 프로그래밍이 "레몬 시장"인 이유입니다. http://en.wikipedia.org/wiki/The_Market_for_Lemons

코드가 엉망이되어 일반적으로 알기 전에 2-3 년이 아닙니다. 프로그래머는 일반적으로 18 개월을 유지하므로 실패시 범인을 보지 못합니다.

예를 들어 릴리스에는 4 개월이 걸리고 수백 번 반복되는 등 관리자는 사용자의 말을 들어야합니다. 어쩌면 상태와 혼합 된 오류에 대해 수동으로 많은 수의 배포 파일과 수동으로 읽는 로그 파일을 편집하고 있습니까? 그들은 그것이 더 잘 이루어질 수 있다는 것을 모른다.

따라서 정직하고 전문적인 자세로 개선하십시오. 경험이있는 관리자는 좋고 나쁜 행동의 패턴을보기 시작합니다.

사람이 좋은 프로그래머인지 나쁜 프로그래머인지 관리자는 어떻게 알 수 있습니까?

나는 총체적인 일반화로 시작할 것이다. 대부분의 관리자는 "나쁜"프로그래머로부터 "좋은"프로그래머에게 말할 수 없다.

그렇게함으로써 대부분의 관리자 (만났거나 일한)가 프로그래머에서 "좋은"것으로 간주하는 것은 다른 프로그래머가 "좋은"것으로 간주하는 것과 같은 기술이 아닙니다.

그들은 그걸 어떻게 햇어?

결과 지향적 인 관리자는 "똑똑한"및 "완료된 작업"과 같은 것을 찾습니다. 시간과 예산에 맞춰 작업을 수행하는 한 스웨트 팬츠에서 일하기 위해 출연한다면 그들은 신경 쓰지 않을 것입니다.

프로세스 지향 관리자는 "작업 수행 방식"에 더 관심이 있습니다. 이것은 제 시간에 일을하고 올바른 옷을 입고 TPS 보고서에 올바른 표지를 가지고 있음을 의미합니다.

무언가를 책임 져야하는 사람은 잘 작동합니다

"책임"이되기 위해서는 코드 작성과 다른 기술이 필요합니다. 사람이 팀을 이끌 기 위해 필요한 기술을 가지고 있다면, 그 사람은 그렇게해야합니다. 현재 수행중인 직무의 주요 직무를 기반으로 사람들을 홍보하면 결국 무능한 수준에 도달하게됩니다. 이것을 피터 원칙 (Peter Principle )이라고 합니다.

분명히 실제로 코드를 읽고 버그 추적 시스템을 더 깊이 탐구하고 진행 상황을 이해하는 프로그래밍 리터럴 매니저가 항상 도움이됩니다. 모든 버그가 동일하게 생성되는 것은 아니며 제 시간에 나쁜 코드를 전달하는 것은 중요하지 않습니다. 많은.

그러나 이것은 이상적인 경우입니다. 관리자가 비 기술적 인 관점에서 프로그래머의 측정을 얻으려면 몇 가지 제안이 있습니다.

• 현재 지정된 요구 사항을 충족하기 위해 수행하는 데 문제가있는 부분을 신속하고 규칙적으로 / 일관되게 강조 표시하고 그로 인해 완전히 성가신 경우가 있습니다 (이러한 문제가있을 정도로 복잡하지 않은 경우 소프트웨어 개발입니다). 실제 개발 프로젝트가 아닙니다).
• 그들이 무언가에 대해 확신이 없다면, 즉시 그렇게 말하십시오. 자신의 능력에 자신감이있는 프로그래머 만이 실제로 그렇게 할 것입니다. 반대로 자신의 깊이가 심각하지 않다는 것을 아는 사람은 숨어 숨어있는 경향이 있습니다.
• 팀의 다른 프로그래머는 다른 프로그래머에 대해 무엇을 말하고 / 내포합니까? 절반 정도의 관리자라면 특히 통합 테스트 / 버그 수정 시간 동안 프로그래밍 팀과 함께 할 것입니다. 따라서 이런 종류의 피드백을받지 못하면 다른 사람이 작업을 수행해야합니다.
• 그리고 내가 가장 좋아하는 것 : 'tomcat'프로그래머라고 부르는 것. 잠시 후 여러 프로그래머가 항상 같은 프로그래머의 책상 주위에서 밀링하는 것을 알고 있다면 (그들이 일을하고 문제가있는 문제를 논의하고 시원하고 재미있는 웹 사이트의 거주자 찾기가 아니라고 가정 할 때) ... 다른 프로그래머가 이유가 있습니다. 그 사람의 책상에 끌고 있습니다. 팀 리더가 아닌 경우 최대한 빨리 팀 리더가되어야합니다.

이 중 일부 또는 전부가 적용되는 경우, 좋은 프로그래머가 될 것입니다. 좋은 프로그래머는 코딩 능력을 평가할뿐 아니라 다른 사람들과 의사 소통 할 수있는 것과 같은 다른 유용한 것들을 평가합니다. ;-)

관리자는 사용자가 작성한 코드가 언제 화려한 지 또는 큰 요인으로 개선 될 수 있는지 알지 못할 수 있지만, 그가 아는 ​​것은 다음과 같습니다. 다른 사람들이 만드는 문제를 해결하기 위해 믿을 수있는 사람입니까? 고객이나 사용자가 관리자에게 이관 한 문제를 발견 했습니까? 시계에 중대한 재난이 있었습니까 (사용자 테이블 삭제, 백업 설정을 잊어 버렸거나 다른 고객이 보지 말아야 할 독점 데이터가있는 고객에게 전자 메일을 보냈습니다. 등) 사람들이 등 뒤에서 좋고 나쁜 것을 말합니까?

1. 관리자가 코드를 평가하지 않는 대부분의 경우 동료가 공식적으로 또는 비공식적으로 코드 작업을 시도 할 때 평가합니다. 상사는 동료의 의견 (공식적이든 비공식적이든)을 어느 정도 사용합니다.
2. 일반적인 신뢰성과 작업 진행 및 완료 속도는 코딩 능력과 별도로 매우 중요한 요소 인 경우가 많습니다.
3. 통신. 많은 일을하고 잘 수행하고 있다면 관리자가 이에 대해 알아야합니다! (물론 자랑하지 마십시오). "관리자 관리"를 배우고 단순히 수동적이지 마십시오. 상사가 당신이 어떻게 일하는지 알도록 도와주세요.

관리자는 코더 자체이므로 간단한 관찰만으로 코더가 좋은지 여부를 파악할 수 있습니다.

관리자가 코더가 아닌 경우 (그리고 소프트웨어 비즈니스에 종사하는 경우) 문제가 있습니다.

관리자로서 다음은 프로그래머를 평가할 때 살펴본 것입니다.

• 동료 피드백. 팀의 프로그래머와 다른 팀의 프로그래머에게 직원에 대한 피드백을 보내달라고 요청했습니다.

• 동료 존중 . 프로그래머가 해결할 수없는 문제에 부딪쳤을 때, "어떻게 조언을 구하자"고 말합니다.

• 일을 끝 냅니다. 나는 "X를 원한다"고 말하고 다음날 X는 끝났습니다.

• 똑똑한 것들을 얻습니다 . 나는 "X를 원한다"고 말하고 다음날 X는 끝났을뿐만 아니라 모든 X와 같은 것들이 해결되고 더 이상의주의가 필요하지 않습니다.

• 나를 고치세요 . 저는 "X를 원합니다"라고 말하고 프로그래머는 "X는 옳지 않습니다. 우리는 Y를해야하는데 여기에 이유가 있습니다."라고 말합니다.

훌륭한 관리자는 많지 않습니다 (관련 질문 참조 : 사람이 좋은 관리자인지 나쁜 관리자인지는 프로그래머가 어떻게 알 수 있습니까?). 사람을 잘 관리하는 것은 어렵고 많은 시간과 노력이 필요합니다. 5 명을 관리하자마자 프로그래밍 할 시간이 거의 없었습니다. 8 명 이상의 사람들을 관리 할 때는 더 이상 사람들을 관리 할 수 ​​없었습니다.

귀하의 질문의 전제는 관리자가 실제로 코드를 보지 않는다고 주장한다는 점에서 다소 결함이 있다고 생각합니다. 관리자가 동료 엔지니어 였고 코드 검토에 적극적으로 참여한 많은 상황에서 일했습니다.

그러나 비전문가가 소프트웨어 엔지니어를 담당하는 상황은 분명히 많으며 자신의 지식과 경험에 의존 할 수 없습니다.

이 경우 담당 관리자는 엔지니어 동료에게 조언을 요청합니다. 그들은 엔지니어와 상호 작용하는 조직의 비 기술적 인 사람들에게 책임 강화에 적합한 우수한 기술을 보유하고 있는지 묻습니다.

무책임한 사람들은 그들의 "장 (gut)"반응과 함께 갈 것입니다.

그것은 쓰레기 촬영이지만 항상 다른 곳에서 더 좋은 것을 끝내고 희망 할 수 있습니다.

내가 근무하는 곳에서 직원 평가가 이루어지면 관리자는 직원과 정기적으로 상호 작용하는 사람들에게 비공식 익명 질문자를 보냅니다. 동료 개발자와 고객 모두. 이를 통해 동료 개발자는 관리자가 간과 할 수있는 코더로서 성능에 대한 정보를 제공 할 수 있습니다.

관리자는 측정 가능한 것을 살펴 봐야합니다. 수행 한 작업, 작업 품질 측면에서 작업의 어떤 측면을 측정 할 수 있습니까? 많은 오류가 발생하거나 최종 사용자가해야 할 일을 허용하지 않는 한 양질의 업무를 수행하고 있는지 알 수 없습니다.

귀하의 업무에 관리자 비용이 들기 때문에 고용을 계속하려면 재정적으로 수익성이 있어야합니다.

나는 이것이 최선의 방법이라고 말하지는 않지만 고객 만족을 기반으로 할 수 있습니다. 그들이 응용 프로그램을 좋아하고 버그의 양을 받아들이고 적시에 새로운 기능을 추가한다고 생각한다면 개발자가 실제로 그렇게 나쁠 수 있습니까?

물론 그들은 할 수있었습니다. 두 사람의 작업을 수행하는 10 명의 직원이 있기 때문에 코딩을 통해 무력을 발휘할 수 있습니다. 또는 앱을 너무 싸게 판매하기 때문에 고객이 만족합니다.

이 방법의 또 다른 문제점은 비 기술적 인 관리자가 고객 피드백을 받기 전에 응용 프로그램이 거의 완료 될 때까지 기다려야한다는 것입니다. 앱을 출시하기 위해 1 년 동안 만 앱을 빌드하면 아무도 좋아하지 않습니다.

사람들에게 '그냥 작동하게하라'고 말하면 인생은 더 단순해질 것입니다. 사람들이 올바른 프로세스를 이해하고 준수하게하면 많은 문제가 해결됩니다. 현실적인 마감일을 요구할 수 있습니다. 어떤 바보라도 비현실적인 요구를 겪고 재능있는 사람들을 잃을 위험이 있습니다.

나는 기술팀에 속한 대부분의 사람들이 누구를 and 고 누가 suck는지 알고 있다고 생각합니다. 당신이 엄청난 회전율을 갖지 않는 한, 크림은 위로 올라가고 죽은 무게는 가라 앉습니다. 미숙 한 개발자는 항상 일종의 문제가 있습니다. 코드를 확인하기 전에 코드를 테스트하여 빌드가 중단되는 것을 잊어 버리고 무언가를하지 않을 때 항상 변명합니다.

나는 누군가가 좋은 프로그래머 인지 알지 못한다고 생각합니다. 그들은 누군가가 좋은 개발자 인지 확인합니다 . 프로그래밍은 개발 활동이지만 개발에는 많은 것들이 있습니다. 따라서 버그 추적 시스템, 소프트 기술, 헌신, 의사 소통 등에서 수행 한 작업에 많은 결함이 있는지 여부를 판단하고 시간이 적절한 지 확인합니다.

일부 전문가들은 때때로 잊고 화나게하는 것은 우리의 작업이 프로그래밍 일뿐 아니라 수행해야 할 다른 것들도 매우 중요하다는 것입니다. 관리자는 코드가 자신에게 중요하지 않기 때문에 코드가 어떻게 보이는지 살펴 보지 않지만, 팀원이 책임감 있고 존중하며 전반적인 고품질 작업 을 수행하는지 확인합니다 .

때로는 코드가 과대 평가되었다고 생각합니다.

개발자의 펙킹 순서를 잘 이해하지 못하는 사람은 거의 없습니다. 모두 자신이 최고의 개발자라고 생각합니다. 나쁜 개발자가 누구인지 모르는 사람은 그 자체가 나쁜 개발자입니다. 어쨌든, 당신이 주위를 돌아 다니면서 누군가와 함께 일하는 개발자에게 순위를 매기도록 요청한다면 대부분의 사람들에게는 쉬운 일이라고 확신합니다. 따라서 누가 성과를 잘 발휘하고 평균 또는 나쁜 성과를 낼지 결정하는 데 마술은 없습니다. 하지만 실제로는 그렇지 않습니다. 대부분의 관리자는 그들에 의해 혼란스러워하지만 개발자는 그렇지 않습니다.

그 후, 순위를 결정하는 것은 관리자의 편견입니다. 코딩은 엔트리 레벨 작업이므로 코딩에 능숙하지만 원하는 프로모션을 얻지 못할 수도 있습니다. 다른 사람들은 디자인이나 건축 측면을 가장 중요하게 생각합니다. 또한 요구 사항 정의 및 수집 (예 : 비즈니스 분석)이 가장 중요하다고 생각하는 사람들도 있습니다. 관리자에게 중요한 것이 무엇인지 알고 싶은데 최고 성과 순위를 얻지 못한 경우 최고 성과 순위를 얻으려면 어떻게해야합니까? 당신은 그 대답에서 그들에게 너무 중요한 것을 배우고 그 중요한 분야에서 뛰어나게하는 것은 당신에게 달려 있습니다.