에서 처리 내 낡은 동료의 질문, 다양한 사람들은 동료를 처리하기위한 전략을 논의 내키지 팀의 자신의 워크 플로우를 통합.
가능한 경우 현대 기술과 도구를 모르고 약간 무관심한 동료를 "교육"하는 전략을 배우고 싶습니다 .
최근까지 회사의 다른 부분에서 상대적으로 고립 된 프로그래머와 함께 일하기 시작했습니다. 그는 광범위한 영역 지식을 보유하고 있으며 가장 중요한 것은 많은 지원자들이 부족한 것으로 보이는 훌륭한 문제 해결 능력을 보여주었습니다 .
그러나 내가 본 실제 (C #) 코드는 VB6 일에 대한 후퇴입니다. 절차 적 구조, 헝가리어 표기법, 전역 변수 (남용 static), 인터페이스 없음, 테스트 없음, 제네릭 사용 안함, 던지기 System.Exception... 아이디어를 얻습니다.
이 프로그래머는 나보다 상당히 나이가 많으며 적어도 첫인상으로 는 적극적으로 긍정적 인 변화를 찾지 않습니다 . 나는 그것이 주제가 어떻게 브로치되는지에 대한 문제라고 생각 하기 때문에 변화에 저항 하지 않는다고 말하지 않을 것이며 , 나는 준비하고 싶다.
프로그래머는 완고한 경향이 있으며, 총을 타 오르고 찢어 버리기 위해 코드 검토 및 엄격하게 시행되는 정책을 시행 하는 것은 내가 원하는 최종 결과를 얻지 못할 가능성이 높습니다 . 이것이 신입 사원, 주니어 프로그래머라면 "멘토"자세를 취하는 것에 대해 두 번 생각하지는 않지만 숙련 된 직원을 우둔한 초보자로 취급하는 것은 극도로 조심 스럽습니다. 현장의 특정 발전에 발 맞추어).
온화한 설득과 비 물질적 인센티브를 통해이 개발자의 코드 품질 표준 인 데일 카네기 방식을 높이려면 어떻게해야합니까? 적대적인 상황을 만들지 않고 미묘하고 점진적인 변화에 영향을 미치는 가장 좋은 전략은 무엇입니까 ?
다른 사람들, 특히 리더 개발자들이 이런 상황에 처한 적이 있습니까? 관심을 자극하고 긍정적 인 역 동성을 창출하는 데 어떤 전략이 성공 했습니까? 어떤 전략 이 성공 하지 못하고 피하는 것이 좋을까요?
설명 :
나는 실제로 여러 사람이 질문의 모든 세부 사항을 실제로 읽지 않고 개인적인 감정을 바탕으로 대답하고 있다고 생각합니다. 다음과 같은 내용을 암시해야하지만 지금은 명시하고 있습니다.
이 동료는 나이에 따른 나의 "노인"입니다. 나는 그의 직함, 영향력의 영역 또는 조직에서 몇 년이 나의 것을 초과한다고 말한 적이 없으며, 사실 그 어느 것도 사실이 아닙니다. 그는 주요 개발 상점에 흡수 된 LOB 프로그래머입니다. 그게 다야.
나는 신입 사원, 하급 프로그래머, 또는 밤새 회사를 변화시킬 계획이있는 다른 순진한 바보가 아닙니다. 저는 기본적으로 소프트웨어 프로세스를 담당하지만 "리드"로 일한 많은 사람들이 알듯이 책임이 항상 조직도와 정확하게 상관되는 것은 아닙니다.
나는 사람들에게 내 길 을 얻는 방법, 지옥이나 높은 물을 오는 방법을 묻지 않습니다 . 내가 원한다면 그렇게 할 수 있었고, 그 결과로이 사람은 분개하고 /하거나 그만 둘 수있었습니다. 변화를 추진 하는 사회적 , 협동적인 방법을 찾고 있음을 이해하십시오 .
의 언급 "... 전역 변수 ... 아니 시험 ... 던지는
System.Exception" 입증하기 위해 의도 된 문제는 단지 피상적 인 미적 없습니다 . 상대적으로 작은 CRUD 앱에서 작동 할 수있는 방법은 대기업 앱에서는 작동하지 않을 수 있으며 실제로 지금까지 코드가 실제로 통합 테스트를 통과 한 것은 없습니다.
제발, 액면가로 질문을하고, 내가 말하고있는 것을 실제로 알고 있음을 인정하고, 실제로 질문 한 질문에 대답 하거나 계속 진행하십시오.
추신 : 전제와 논쟁하기보다는 건설적인 조언을 해주신 분들께 진심으로 감사드립니다. 나는 실제 경험의 방식으로 더 많은 것을 듣기를 희망하면서 이것을 오랫동안 열어 둘 것입니다.