후배를 고치지 만 스스로 생각하도록 격려하는 방법? [닫은]

모든 사람이 1 년 미만의 소프트웨어 개발 경험을 보유한 소규모 팀의 리더입니다. 나는 결코 자신을 소프트웨어 전문가라고 부를 수는 없지만 몇 년 동안 내가 소프트웨어를 작성하고 있다는 몇 가지 사실을 배웠다.

우리가 코드 검토를 할 때 나는 약간의 가르침과 실수를 수정합니다. "이 방법은 지나치게 복잡하고 복잡하며 여기에 이유가 있습니다"또는 "이 방법을 별도의 클래스로 옮기는 것에 대해 어떻게 생각하십니까?" 질문이 있거나 의견이 맞지 않는 의견이 있으면 괜찮아서 논의해야한다는 점에 특히주의를 기울입니다. 누군가를 고칠 때마다 "어떻게 생각하세요?" 또는 비슷한 것.

그러나 그들은 동의하지 않거나 이유를 묻는 경우가 거의 없습니다. 그리고 최근에 나는 그들이 내 말에 맹목적으로 동의하고 그들 자신의 의견을 제시하지 않는다는 더 뻔뻔스러운 신호를 알아 차렸다.

지시를 따르지 않고 자율적으로 일을하는 법을 배울 수있는 팀이 필요합니다. 주니어 개발자를 어떻게 교정하되 여전히 스스로 생각하도록 격려 하는가?

편집 : 다음은 자신의 의견을 형성하지 않는다는 명백한 징후 중 하나의 예입니다.

나 : 확장 메서드를 만드는 아이디어가 마음에 들지만 복잡한 람다를 매개 변수로 전달하는 방법이 마음에 들지 않습니다. 람다는 다른 사람들이 메소드의 구현에 대해 너무 많이 알도록 강요합니다.

주니어 (나를 오해 한 후) : 예, 전적으로 동의합니다. 확장 메소드는 다른 개발자가 구현에 대해 너무 많이 알도록하기 때문에 여기에서는 확장 메소드를 사용하지 않아야합니다.

오해가 있었으며 그 문제가 해결되었습니다. 그러나 그의 진술에는 논리의 OUNCE조차 없었습니다! 그는 내 논리를 다시 내게 되돌려 놓았다고 생각했는데, 왜 그가 왜 그런 말을했는지 전혀 몰랐을 때 이해가 될 것이라고 생각했습니다.

짧은 답변:

그들을 참여시키고 (퍼즐을 마음에 담아) 힘을 실어주십시오 (답을 신뢰하십시오).

우리를 운전하는 것은 질문입니다! 매트릭스.

일반적으로, 저의 관찰에 따르면, 주니어는 자신의 세계를 가지고 있습니다. 자신의 생각에 대한 자신의 제한적인 견해와 일부는 사물에 대한 열정 / 즐겨 찾기 / 의견입니다.

그들에게 당신이 틀렸다고 말하는 것에 대해 잘못된 것은 없습니다. 그러나 가장 좋은 것은 그들이 당신을 생각하게 만드는 것입니다. 왜? 다른 방법이 있습니까? 같은 일을하는 더 좋은 방법이 있습니까? 내가 항상 사용하는 일화 중 하나는 "이 문제에 대한 세 가지 해결책을 줘!"입니다.

그들은 이러한 솔루션에 대해 생각할 때 많은 문제를 깨닫기 시작합니다. 시간이 좀 걸리지 만 시간이 지남에 따라 사고의 한계와 단점을 시각화하는 경향이 있습니다. 그들은 그것을 "내가 생각하지 않았다!"라고 더보기 시작 했습니다. "내가 틀렸다" 는 느낌으로 집에가는 것보다 훨씬 낫다 . 또는 더 나쁜 "유효한 견해를 가지고 있어도 잘못 들었다 / 증명되었다" .

일반적으로 아주 어린 아이들은 프로세스 문제 보다는 기술적 인 문제 (예 : 디자인 패턴이 더 잘 작동하는 등)와 관련이 있지만 시간이 지남에 따라 코치하면 효과가 있습니다.

그러나 그들은 동의하지 않거나 이유를 묻는 경우가 거의 없습니다. 그리고 최근에 나는 그들이 내 말에 맹목적으로 동의하고 그들 자신의 의견을 제시하지 않는다는 더 뻔뻔스러운 신호를 알아 차렸다.

이것은 일반적으로 귀하 가 제안을했지만 나중에 제안을 무시하고 귀하의 의견에 대해 똑같이 확신하지 못하는 결과입니다 . 당신이 수석이기 때문에 그들은 싸움을 피하고 있습니다!

내가 과거의 상사 중 한 명으로부터 배운 가장 좋은 점은 팀원들에게 먼저 토론을 요청하고 (여기서 평등하다고 느끼는 것) 모든 논쟁이 소진 된 후 한 가지 질문만으로 회의실에 들어갔을 것입니다. 불일치 점? " 요점은 사람들은 항상 토론과 토론에 참여하는 것을 좋아하지만 다음 번에 자신의 (유효한) 요점을 행동으로 취하지 않으면 토론에 참여할 가치가 없다고 생각합니다.

소프트웨어뿐만 아니라 모든 곳에서 궁극적으로 가장 능력이 뛰어난 팀원 만이 시스템에 의문을 제기 하지 않고 대답 할 것 입니다.

후배들이 스스로 생각하기를 원한다면 시정하지 말고 스스로 시정하도록하십시오 .

그들의 해결책에 대해 당신이 옳지 않다고 생각하는 것을 말하지 말고 그들에게 적절한 질문을하십시오. 귀하의 예에서 확장 방법을 사용하는 사람이 람다를 생성하기 위해 알아야 할 사항에 대해 물어볼 수 있습니다. 때까지 같은 질문을 계속 그들은 그것이 문제입니다 것이 좋습니다. 그렇게하면 솔루션이 왜 문제가 될 수 있는지 이해했으며, 솔루션이 잘못되었다고 말하면 외부 판단이며 쉽게 무시할 수 있다는 것을 알게됩니다. 그들이 스스로 실현 (약간 자극)하면, 그것이 얼마나 근거가 있는지 깨닫고 실수로부터 배울 가능성이 훨씬 높아집니다.

또한 이것은 주니어가 디자인을 방어 할 수있는 기회를 제공합니다. 아마도 문제에 대해 생각하고 관심사를 해결하는 데 정당한 이유가있을 수 있습니다. 즉, 정정 할 필요가 없습니다. 그것은 당신이 경영진에 의해 지배하고있는 모든 인식 (그러나 의도하지 않은)을 줄입니다.

주니어 개발자가 여러 명이므로 코드 리뷰는 1이 아닌 그룹으로 작성됩니다.

"어떻게 다른 문제를 해결할 수 있을까?"라는 그룹에 질문하여 다른 주니어 개발자들이 먼저 구현을 제안하도록 허용하십시오. 다른 팀 구성원이 말한 후에 아이디어가 비슷한 것을 제안하지 않은 경우에만 구현을 추가하십시오.

그런 다음 주니어 개발자들에게 그것이 무엇인지 알지 못하고 최고의 구현을 선택하도록 안내하려는 의도로 다른 구현의 상대적인 장단점에 대한 원탁 토론을하십시오.

주니어 개발자를위한 신뢰 구축 자로서, 그들이 최선의 선택이라고 생각한 것을 고른 대안을 반 명백한 결함이있는 짚맨으로 만들고 원래의 구현이 가장 좋은 이유에 대한 토론을 지시하는 경우를 시작할 수 있습니다.

프로그래밍 작업을 처음 시작했을 때 나는 당신이 묘사 한 것과 똑같은 일을했습니다. 다른 말을 할 충분한 경험이 없었기 때문입니다.

실제로 방법론과 아이디어를 논의 할 수있는 능력은 경험을 통해 배우고 다양한 접근 방식과 새로운 기술에 대해 읽는 것이 었습니다. 팀이 스스로 생각하기 위해서는 "과도하게 복잡하고 복잡한"코드와 같은 문제에서 어떤 문제가 발생할 수 있는지 실제로 알아야합니다.

개별 사고를 용이하게하는 좋은 방법은 Stack Overflow 또는 Programmers SE와 같은 프로그래밍 웹 사이트를 살펴 보는 것입니다. 나는 이것들이 내가 거기에 있었던 다른 기술들에 대해 배우는 데 도움이되었고 맹목적으로 동의하는 대신 팀의 선임 멤버들과 토론을 할 수 있다는 것을 알고 있습니다.

요점은 경험이 없으면 선임 회원의 제안이 항상 그들에게 잘 들린다는 것입니다.

귀하의 게시물에서 상호 작용은 거의 모든 것을 가르치는 핵심 원리를 보여줍니다 그들은 당신이 말한 생각하는지 설명하도록 요청 하고 응답을주의 깊게 듣고 :이 수정 될 필요가 정확히 무엇을 말할 것이다.

나는 25 년 전 수학 교사로부터이 속임수를 뻔뻔스럽게 도난 당했으며 그 이후로도 실패하지 않았습니다. 수업 시간에 교습 조교로, 소프트웨어 디자인에 대해 이야기 할 때 직장에서, 8 살짜리가 학교 과제에 대해 이야기 할 때 수업에서 사용했습니다.

물론 방금 말한 내용을 반복하도록 요청하는 데 항상 둔감 할 수는 없으므로 전략을 조정해야합니다. 예를 들어, 다음은 OP의 후속 진술을 "탐색"질문으로 다시 표현하는 방법입니다.

확장 메서드를 만드는 아이디어가 마음에 들지만 복잡한 람다를 매개 변수로 전달하는 방법이 마음에 들지 않습니다. 이 복잡한 람다 는 어떻게 다른 사람들 이 메소드의 구현에 대해 너무 많은 특정 사실을 알도록 강요 합니까?

강조하려는 문제를 이해하지 않으면이 질문에 올바르게 답할 수 없습니다. 방금 말한 것에 대한 분석이 필요한 질문으로 설명을 끝내는 것이 학습 과정의 속도를 높이고 수정해야 할 피드백을 제공한다는 것을 알았습니다.

일반적으로 사람들이 원하는 것을 말하지 않으면 듣는 일을해야한다는 의미입니다. 청취는 판단을 통과하기 전에 설계 이유를 듣는 것을 의미합니다. 그것은 단지 그들에게 반대 하는 것이 좋다고 말하는 것이 아니라, 단지 그들이해야 할 말을 정직하게 고려하고 교정하는 것이 아니라 그것을 증명함으로써 그것을 증명 하는 것을 의미합니다. 솔루션에 대한 좋은 점을 찾고 해당 사항을 통합하도록 솔루션을 수정하십시오.

또한 예를 들어 이끌어야합니다. 나는 엄청나게 멋진 코드를 작성한다는 것을 의미하지 않으며, 자신의 디자인에 대한 의견을 요청하는 것을 의미합니다. 사실 후에 코드 검토를 기다리지 말고 모든 과정에서 함께 작업하십시오. "내 인터페이스가 너무 복잡해 보이지만이를 단순화하는 가장 좋은 방법은 확실하지 않습니다." 먼저 자신의 아이디어에 편견을주지 않고 답변 할 시간을주십시오.

이 문제를 해결해야 할 때 나는 다음과 같이 (정직하게) 말했습니다.

알다시피, 그것은 내가 생각하지 못했을 정말 창의적인 솔루션입니다. 확장 성 / 어떻게 개발이 더 빨라지거나 유지 관리가 더 쉬워 지도록 개념적으로 더 간단한 접근 방법이 있다고 생각하십니까? / 안타깝게도 프로젝트의 나머지 아키텍처와 실제로 맞지 않는다고 생각합니다. 구성은 어떻게 생겼습니까?

이것은 보통 사람들에게 새로운 방향을 제시하기에 충분했습니다.

책임은 그들을 도울 수있는 것입니다.

나는 과거에 한두 팀을 이끌었고 후배를 빛나게 한 것 중 하나는 개인적인 책임의 부담이었습니다. 자신의 행동이 한 시점에서 자신에게 연루 될 수 있음을 알게되면, 대개 자신이하는 일에 조금 더 자신을 투입합니다. 그들이 그들의 일을 느낄 때, 좋은 결과가 훨씬 더 만족 스럽다는 것은 말할 것도 없습니다.

나는 그들이 맹목적으로 당신을 따르고 있다는 사실에 대해 너무 걱정하지 않을 것입니다. 이것이 그들이 주니어로해야 할 일입니다. 문제는 그들이 코드 검토에서 다루는 항목이 사라지고 끔찍한 소프트웨어 개발자, 끔찍한 관리 및 끔찍한 코드가있는 다른 곳에서 작업 할 때까지 실제 항목을 이해하지 못할 것입니다.

그때까지 그들은 습관적으로 좋은 관행을 배웠으며 다른 사람들이 저지른 코딩 및 디자인 실수를 통해 살아야 할 것이며 이제는 제대로 설계되지 않은 소프트웨어로 작업해야합니다.

이것은 경력의 어느 시점에서 필연적으로 불가피 할 것입니다. 좋은 코딩 표준과 실습에 익숙해 져 훌륭한 서비스를 제공하고 있습니다. 불행하게도 우리 대부분은 어려운 길을 배워야했습니다.

주어진 예를 바탕으로 질문에 대한 귀하의 의견을 따르는 것이 가장 좋은 방법 일 것입니다. 당신이 당신의 의견과 함께 질문을한다고해서 그들에게 최소한 그들이 어떤 것을 구현할 수있는 방법에 대해 생각해야한다고 단순히 동의하거나 동의하지 않는 것은 아닙니다.

예를 들어 "확장 메서드를 만드는 아이디어가 마음에 들지만 복잡한 복잡한 람다를 매개 변수로 전달하는 방법이 마음에 들지 않습니다. 람다는 다른 사람들이 메서드 구현에 대해 너무 많이 알도록 강요합니다. 더 나은 방법을 생각할 수 있습니까? 정보를 많이 노출시키지 않는이 확장 방법을 구현 하시겠습니까? "

이를 통해 개발중인 결함을 볼 수 있으며 동시에 애플리케이션에 도입 된 문제를 해결할 수 있습니다.