상급 프로그래머가 주니어 개발자를 맡고 멘토링해야합니까? [닫은]

꽉 짜고지지하는 가게에서 선임 개발자와 멘토로서 주니어 개발자와 짝을 이루는 문화의 일부 여야합니까? 또는이 멘토링이보다 유기적이고 자발적인 것, 즉 요구되지는 않지만 인공적인 격려없이 발전 할 수 있어야 하는가?

나는 그것이 장려되어야하지만 필요하지는 않다고 생각한다. 선배는 후배 나 그와 비슷한 사람에게 배정되어서는 안됩니다. 그렇지 않으면 Dilbert-land에있게됩니다. "멘토-멘티"관계에는 핵심적인 수준의 우정과 건강한 상호 존중이 필요합니다. 사람들에게 가서 떠나라고 말함으로써 그렇게 할 수는 없습니다.

선임 개발자가 멘토로서 주니어 개발자와 짝을 이룬 문화의 일부 여야합니까?

예.

유기적이고 자발적인 것, 즉 필수는 아니지만 인공적인 격려없이 발전 할 수 있음

실제로 누군가를 돕기에 충분하지 않습니다.

조직에서 기존 관계를 가진 사람들은 새로운 사람들에 의해 파벌 또는 엘리트로 인식 될 것입니다. 도당은 일반적으로 분해되지 않습니다. 우리는 우리가 아는 사람들을 고집합니다. 그것은 인간 본성 의 필수 요소입니다.

30 년 넘게 컨설턴트 (100 명의 고객 참여)로서 나는 새로운 사람들이 항상 외부인 이라고 주장 할 수 있습니다 . "문화"또는 "대기"기능이 아닙니다. 사람들이 일하는 방식의 필수 기능입니다. 설립 된 직원은 어떤 것도 포함시키지 않기 때문에 컨설턴트는 자신의 입장을 구성합니다.

멘토링을 설정하는 유일한 방법은 새로운 사람들을 파벌에 삽입하는 것입니다.

"멘토"의 전통적인 의미는 다소 과제를 무시합니다. 친구를 시도하고 배정 할 수도 있습니다.

내 경험상, 새로운 팀원을 설립 한 팀원을 첫 주, 달 등의 질문에 대한 기본 연락 담당자로 사용하도록 지정하는 것이 좋습니다.

상급 개발자가 주니어 개발자를 멘토링해야합니까?

절대적으로하지. 일부 선임 개발자는 끔찍한 멘토가 될 것이며 성공적인 멘토 선박을 위해서는 인격의 일치가 필수적입니다. 그러나 선임 개발자 는 개발 팀에 대해 더 나은 것을 만들어야 한다고 생각합니다. 그것은 측면에 무언가를 프로토 타이핑하고, 프로세스 나 연습을 개선하고, 새로운 도구를 개척하고, 그룹에 기술 자료를 제시하고, 팀이나 다른 것을 이끌 수 있습니다. 다시 말해, 그들은 개인의 업무 분담보다 더 큰 것에 대한 책임이 있어야합니다.

또는이 멘토링이보다 유기적이고 자발적인 것, 즉 요구되지는 않지만 인공적인 격려없이 발전 할 수 있어야 하는가?

아니, 그 의견에도 동의하지 않습니다. 멘토링이 "유기적이고 자발적"일 것으로 예상되는 상황이 너무 많이 보였으며 너무 드물게 발생합니다. 나는 조직이 멘토 쉽에게 전염성을 가질 수있는 기회를 주어야 할 의무가 있다고 생각한다. 그러나 그것은 강제 될 수 없다. 어렵지만 가치가 있습니다. 조직이 다음과 같은 일을 할 수 있다고 생각합니다.

• 잠재적 인 멘토와 잠재적 인 단백질 사이의 비공식 모임
• 멘토링이 조직에 의해 공식적으로 인정 될 수있는 제안 된 방법 및 기회 )
• 멘토 교육 및 지원
• 멘토 선정 방법 및 예상 대상에 대한 안내
• 무엇을 기대하고 무엇을 제공해야하는지 멘토에게 안내
• 참여를위한 템플릿이 포함 된 멘토링을위한 제안 된 (또는 시행 된) 패턴-예를 들어, 매주 만남을 통해 3 개월의 경험이자 새로운 개발자가 일어나도록 돕는 목표를 미리 알고 있다면 더 쉽게 샷을 줄 수 있습니다. 그리고 회사에가는 것. 더 이상으로 발전하지는 않지만 사람들이 시작할 수있는 장소를 제공합니다.

일부 사람들은 그런 식으로 연결되지 않았기 때문에 요구 사항을 만들면 잠재적으로 역효과를 낼 수 있다고 생각합니다. 즉, 멘토로 생각되는 사람들을 식별하고 멘토링에서 더 적극적인 역할을 수행하는 방법에 대해 접근해야합니다 (아직 그렇지 않은 경우). 이 예제 별 접근 방식은보다 자연스러운 멘토링을 포착하고 고무시킬 수 있습니다.

정기적으로 발생하는 그룹 활동을 예약하면 팀이 젤리를 도울 수 있습니다. 이것은 팀 점심과 같은 완전한 사회적 활동이거나 주간 프로그래밍 북 클럽과 같은 프로그래밍에 대한 학습을 ​​포함하는 활동 일 수 있습니다.

그룹 코드 검토처럼 작동하는 시스템에서 정기적 인 "미니 사후 상실"을 수행 할 수도 있습니다. 그룹 환경에서 검토를 수행하면 한 가지 이점은 원래 코드를 작성한 사람이 아니라 모든 사람이 피드백의 혜택을 볼 수 있다는 것입니다. 일을 시작하기 위해 자신의 코드를 판단하는 데 편안한 자원 봉사자를 구해야하고 시민권을 유지해야합니다.

저는 주니어와 시니어 프로그래머라는 용어를 좋아하지 않았습니다. 예를 들어, 나는 한동안 프로그래밍을 해왔고 어떤 분야에서는 경험이 있지만 다른 분야에서는 매우 녹색입니다. 예를 들어, 우리는 WPF로 전환하고 있으며, 수많은 창에서 응용 프로그램 경험을 제공하지만 WPF는 여전히 새롭고 독창적입니다. 따라서 저는 "고급"프로그래머이지만, '총'경험이 적은 사람을 길거리에서 고용 할 수 있으며,이 시점에서 WPF 응용 프로그램을 나보다 더 좋고 빠르게 프로그래밍 할 수 있습니다.

말할 것도없이 WPF 응용 프로그램에 적용 할 수있는 훌륭한 응용 프로그램 설계 및 아키텍처 경험은 많지 않지만 제 한계를 알고 있습니다.

언젠가 멘토가되고 다른 사람들의 멘티가되어야한다고 생각합니다.

지식이있을 때 멘토가되고 다른 사람들이 멘티가되는 것을 두려워하지 않는 팀원이 있으면 유익한 경험을 갖게됩니다.

개발자가 겸손하고 새로운 아이디어에 개방적이고 필요할 때 다른 사람들을 도울 수있는 개발 환경을 조성 할 수 있다면 sempai-kohai 관계가 자연스럽게 나옵니다.

멘토링을 강요하면 개발자가 서로를 재전송 할 수있는 카스트 시스템이 만들어 질 것입니다. 모든 개발자를 동일한 수준에서 동일하게 취급하는 것이 좋습니다.

이 산업은 매우 다릅니다. Senority가 항상 더 좋은 것은 아닙니다.

때때로 선배들은 후배들에게 멘토링을 받아야합니다.

나는 두 가지 일을 모두하는 환경에있었습니다.

학교를 졸업 한 첫 직장에서 멘토가 배정되었습니다. 나는 그 남자를 좋아하지 않았고 나는 모든 것에 대해 그에게 동의하지 않았다. 나는 그와 함께 일하라고 강요 당했고, 고용주가 실수했다고 확신했지만, 회고에서는 많은 것을 배웠다.

몇 년 간 빨리 발전해 왔으며 이제는 개발자를 각자의 태도로 대하는 회사에서 일하고 있습니다. 개발자들은 촉박 한 마감일을 겪고 있으며, 다른 사람들을 윙으로 묶어 밧줄을 보여주기 위해 시간을 보내는 개발자들에게 허용되는 경우는 거의 없습니다. 부끄러운 일이라고 생각합니다. 주니어 개발자들이했던 것과 똑같은 일로 어려움을 겪고 있지만 멘토가 없으면 더 오래 걸립니다.

나는 신입 사원들이 "그들을 도와 줄 수있는 도움에 감사하는 것"때문에 "멘토"라는 명성을 얻었습니다. 내가 알 수있는 한, 이것은 평범한 생산성 검토를 기꺼이 받아 들여 기꺼이 올바른 일을 할 수 있다고 말하는 멋진 HR 방법입니다. 주니어 개발자가 효과적으로 작업을 수행하고 신속하게 개선 할 수 있도록합니다.

저는 그것이 우리의 후배 직원들이받을 자격이 있고, 후견과 경험의 혜택을 누리면서 제가 처음 일한 회사와 저를 멘토링 한 그 사람이 당시에 생각했던 것보다 훨씬 더 많은 것을 생각했다고 생각합니다.

이 모든 것이 멘토를 할당하지 않아도되기를 바라지 만, 작업에 널리 퍼져있는 유일한 방법 일 것입니다. 그렇지 않은 경우, 그 일을하는 사람들에게 적법하게 제공해야합니다. 쉬운 일이 아니다. 대인 관계 기술과 공학 기술이 필요합니다. 시간이 많이 걸립니다.

선임 개발자는 코드 변경을 넘어서야합니다. 그러나 그들이가는 방향은 모든 선임 개발자에게 동일하지 않아야합니다.

일부는 멘토링에 적합합니다. 다른 사람들은 아키텍처 개선 계획 및 구현, 새로운 기술 평가, 프로세스 개선 계획 및 선도 (예 : 지속적인 통합, TDD 등) 여부에 관계없이 다른 고위급 목표를 추구해야합니다.

기본적으로 노인은 단지 주니어보다 몇 년 동안 코드를 절단 한 사람이되어서는 안됩니다. 팀의 성공에 기여할 추가 책임을 기꺼이 감수 할 수있는 사람이어야합니다. 후배 멘토링은 중요하지만, 중요한 것은 아니며 모든 사람에게 적합한 것이 아닙니다.

인간이 강제적 인 활동, 행동 및 관계 에 대해 자연스럽게 노력하기 때문에 그러한 멘토링을 의무화하는 것은 비생산적 입니다. 더 좋은 방법은 좋은 멘토링을하는 사람들에게 보상 하여 사람들이 멘토링하기를 원하는 것입니다.

물론 이것은 이런 맥락에서 "좋은"측정 문제를 일으킨다. 불완전하지만 쉽게 구현되는 솔루션은 1 년 후 (아마도 익명으로) 신규 이민자가 회사 및 / 또는 코드 기반에 통합하도록 도와 준 상위 3 명의 이름을 작성하도록하는 것일 수 있습니다. 그 후에는 이름이 가장 많이 언급 된 사람들에게 보상 할 수 있습니다. 그러나 금전적 보상은 여기에서 작동하지 않습니다. 사회적 보상을 찾는 것이 좋습니다.

팀 리드 구조, 코드 검토로 이어지는 트릭을 수행해야합니다 ...

한 명 이상의 후배를 담당하는 선임 직원이 있습니다. 나는 그것이 자발적인 도움이 아니라 공식적인 과정이어야한다고 믿는다. 그런 의미에서, 고위 구성원은 새로운 이민자가 생산 한 업무의 질에 대한 책임이있을 것입니다. 이 접근 방식에는 2 가지 이점이 있습니다. (최소한) 경영자에게 경영 스타일을 지시하고 후배가 양질의 코드를 생산하도록하십시오.

프로그래밍 하는 모든 것에 따라 다릅니다 . 그러나 나는 신입 사원이 하급이든 아니든 신입 사원을 멘토링하여 해당 직무에 가장 적합한 교육을 받기를 원합니다.

아닙니다. 이는 선임 및 후배 개발자의 수가 항상 동일하다는 것을 의미하기 때문입니다. 멘토가되기를 원하지만 페어링을 시행하는 선임 개발자들을 격려하는 것은 정말 나쁜 생각 일 수 있습니다. 멘토링 관계를 지원한다는 아이디어는 훌륭하며 여기서 버리면 안됩니다.

인공적인 격려는 여기서 나쁜 생각이 아닙니다. 모든 주니어 및 시니어 개발자에게 약간의 종교적 영향과 역효과가 있더라도 멘티와 멘토가 될 것이라고 말합니다.

멘토링을 처리하는 방법에 대해 회사 내에 알려진 프레임 워크가 있다면 좋을 것입니다. 그러나 이것이 존재하지 않으면 열쇠는 멘토와 멘티 사이에 몇 가지 다른 순간이 있습니다.

1. 현재 상태-지금 상황은 어디입니까? 멘토가 해결에 도움을 줄 수있는 현재의 과제는 무엇입니까?
2. 미래 상태-원하는 것 : 힌트, 해결책, 질문, 누가 물어볼 것인가?
3. 회고-무엇이 변화를 일으켰습니까?
4. 향후 변경-이전에 수행했던 것보다 더 잘 작동 할 수있는 향후 시도는 무엇입니까?

적어도 그것들은 논리적 하향식 접근 방식을 취하기 위해 내가보고 이해할 수있는 상태입니다. 다른 사람들은 훨씬 더 유기적이고 자유로운 형태를 원할 수도 있습니다. 열쇠는이 관계에서 의사 소통하는 연습을 통해 연마되어야 할 기술을 갖도록 각 측면을 얻는 방법에 대한 아이디어를 얻는 것입니다. 각 측면은 관계에서 무언가를 얻어야하며 피드백이 큰 문제이기 때문에 이런 종류의 관계를 갖는 데에는 몇 가지 일반적인 기본 규칙이 있어야합니다.

이것에 얼마나 많은 시간을 소비하는지는 현실적으로 어떤 일을하고 있는지, 기술을 개발하고 관계를 구축하는 데 어느 정도의 시간을 할애해야하는지에 대한 현실적인 질문입니다. 일주일에 한 시간을 원하는 몇 쌍을 볼 수 있지만 다른 사람들은 하루에 두 시간을 원할 수도 있습니다. 공식적인 멘토링 관계에 있지는 않지만 상급자와 후배가 함께 일할 수있는 다른 상호 작용이있을 수 있음을 잊지 마십시오.

멘토링 시스템에 대한 두 가지 다른 시도를 보았습니다. 내가 가장 좋아했던 것은 선임 개발자가 주니어 개발자를 돕기 위해 수행 한 특정 작업 세트를 가지고 있었기 때문에 멘토링의 길을 열었습니다. 예를 들어, 처음 6 개월 동안 선임 개발자 일대일 코드 검토자가 매우 유용 할 수 있으며 멘토링으로 이어질 수 있습니다. 내가 싫어하는 것은 여분의 바쁜 일처럼 느껴졌고 수행중인 작업과 직접 관련이없는 것처럼 보였습니다. 예를 들어 매주 30 분 동안 지정된 멘토와 만나십시오. 멘토 관계의 두 멤버가 일반적으로 일주일 동안 서로 상호 작용하지 않았고 서로의 프로젝트와 관련이없는 경우 특히 짜증났습니다. 전문적으로 성장하는 데 초점을 맞추기보다는 매우 강요하고 부담스러운 느낌이 들었습니다. 마지막으로 원하는 것은 멘토 관계가 상담 세션처럼 느껴지는 것입니다.

IME, 멘토 관계 개발에 의지 할 수 없으므로 최소한 수석 개발자와 주니어 개발자를 정규 쌍으로 묶인 비즈니스 활동 세트 (코드 검토, 디버깅, 쌍 프로그래밍 등)에 연결하여 잠재적 인 멘토를 제공하십시오. 첫째, 좋은 생각입니다. 이상적으로, 선임 회원은 그 역할을 위해 자원 봉사해야하며 개인적인 이익을 인식 할 수 있어야합니다. 현재 회사에서 선임 개발자는 거의 프로젝트를 이끌고 있으며, 자신의 프로젝트 팀을 구성한다는 이점이 있습니다. 다른 회사에서는 멘토가 종종 관리 트랙을 조사하고있었습니다.

젊은 개발자를 고용하는 모든 회사에는 합리적으로 효과적인 멘토링 프로그램이 있어야한다고 생각합니다. 그러나 기본 개발자의 위치가 모든 수석 개발자가 개발의 수준에 관계없이 많은 개발자가 멘토링에 불쾌하다는 단순한 이유 때문에해야한다고 확신하지 않습니다. 불행히도 영토와 함께합니다. 우리 중 일부는 당신이 좋아한다면 훌륭한 사람들이 아닙니다.

반면에, 그것에 능숙한 사람들이있는 경우, 그들은 실제 개발 결과가 떨어지기 때문에 블랙 마크가 아니라 인식해야한다. 예를 들어, 메모장과 Javac를 사용했습니다.

균형 잡힌 관리가 필요합니다. 나는 그것이 일반적인지 확신하지 못한다.

멘토링이 작동하려면 경영진이 이것이 중요하다는 것을 인식하고이를 위해 시간을 할당하고 적극적으로 권장해야합니다!

과제를 100 % 예약 한 사람에게는 문자 그대로 멘토링을하거나받을 시간이 없으며 그렇게되지 않습니다.

일반적으로 멘토 선박은 선임에서 팀장 또는 관리자로 전환하기에 좋은 발판입니다. 멘토십을 PDP (개인 개발 계획)의 발전 또는 회사가 사용하는 장점 계획과 연계시키는 것이 더 효과적입니다. 새로운 개발자에게 지식을 전수하고 능력을 키울 수 있도록 급여 인상과 경력 개발을 적어도 부분적으로 묶는 것은 관리 및 직원 이직의 변화를 극복 할 수있는 강력한 IT 직원을 구축하는 데 중요합니다. 핵심 목표를 제공하고 직원과 협력하여 개선 할 수 있도록하는 것이 리더십으로의 성장의 일부입니다. 선배 평가를 성장의 일부인 후배 성과와 연계시키는 것이 불공평하다고 생각하는 사람들을 위해. 대부분의 경우 임금 삭감에 대해 이야기하는 것이 아니라 증가 또는 둔화 개선에 대해 이야기하고 있습니다.

내가 처음 팀에 왔을 때 나는 주인과 수석 개발자에게 지시를 주었다. 나는 그들에게 무엇이든 물어볼 수 있고 둘 다 대답 할 것이다. 그러나 나는 적시에 그것을 알아낼 수 없다면 그들을 귀찮게하지 않을 정도로 충분히 존중했습니다.

그것은 훌륭하게 작동했지만 다시 유머 감각이 좋은 사람들이 필요할 수 있습니다.