후배가 당신의 제안을 받아들이지 않았다면 어떻게해야합니까? [닫은]


30

저는 3-4 명의 주니어 개발자로 구성된 팀을 이끌고 있습니다. 코드 작성 외에 저의 직업은 후배들에게 감독과지도를 제공하는 것입니다.

그러나 나는 개발자들이 자신의 작업에서 자율성을 소중히 여기는 것을 완전히 이해하고 있으며, 내 생각과 알고리즘을 숟가락으로 먹이는 본질적인 동기를 파괴하고 싶지 않습니다. 나는 그들이 자신의 방식으로 문제를 탐구하고 스스로 생각하고 그들이 극복 할 수없는 문제에 직면했을 때만 나에게 오기를 원한다.

그들이 나에게 왔을 때, 때로는 알고리즘이 충분히 강력하지 않기 때문에 문제를 해결하기 위해 완전히 다른 알고리즘을 제안해야 할 것입니다 (나는 선임자이며 그 이상을 보았습니다). 물론 나는 그들의 감정을 상하게하지 않기 위해 이것을 좋은 방법으로 설명 할 것이며, 나의 해결책이 그들의 해결책보다 훨씬 우수하고, 어리석은 어조 나 비난하는 말이없는 방법을 부드럽게 설명 할 것입니다.

그러나 여전히 내 제안을 받아들이기를 꺼려하는 경우도 있습니다. 부분적으로 자체 알고리즘에 너무 많은 투자를했거나 새로운 방법을 사용하면 학습 시간이 길어지고 경영진에게 마치 마치 마치 아무데도 갈 수 없습니다. 그러나 내 마음 깊은 곳에서 나는 내 알고리즘이 알고리즘보다 훨씬 우수하다는 것을 잘 알고 있으며 그것을 채택해야합니다.

그들이 내 제안을 받아들이지 않으면 어떻게해야합니까? 그들에게 내 길을 따라달라고 부탁해야합니까, 아니면 그들의 머리를 여러 번 벽에 부딪 히고 그들이 내게 돌아 오기를 기다려야합니까? 전자를 사용하면 독재자가되지만 나중에 수행하면 소중한 개발 시간이 소요되고 버그 수정 비용이 발생합니다. 나는 정말로 딜레마에 빠졌다.


9
프로그래머들은 거만하다. 솔루션이 개발했거나 개발했기 때문에 솔루션이 우수하다고 확신하십니까? 주니어 개발자의 방법에 대한 이유를 진정으로 이해했다면 아마도 "내 방식대로"시나리오가되어야 할 것입니다.
Rig

6
안녕하세요 Graviton, 이와 같은 일반적인 직장 문제는 여기서 다루지 않습니다. 다음 사이트 제안 인 Professional Matters에 관심이있을 수 있습니다 . 이러한 일반적인 전문가 관련 질문은 주제에 관한 것입니다.

27
@MarkTrapp : 프로그래머의 팀 리더십이 주제가 아닌 것으로 생각하는 이유를 확장하고 싶습니까? 아마도 합의가있는 경우이 질문을 닫는 대신 StackOverflow로 옮기는 것이 더 좋으며 나중에 사용할 수있을 때 전문가 문제로 열어두고 나중에 마이그레이션 할 수 있습니다. IMHO, 나는 이것이 소프트웨어 개발자로서 관심있는 주제라는 것을 알고 있으며, 관리 프로그래머가 프로그래밍에 고유하다는 것을 감안할 때, 나는 이것을 주제에 대해 분명히 간주합니다. 감사.
S.Robins

35
가장 흥미로운 질문이 닫힌 이유는 무엇입니까?
ThomasX

11
나는 단순히 당신 아래에서 일하는 사람들을 관리하는 것에 관한 질문이라면 이것을 닫는 것에 동의 할 수도 있지만, 문제는 당신 아래에서 일하는 사람들의 코드를 관리하는 것에 관한 것입니다.이 사이트에는 완벽하게 좋습니다. 다시 열기로 투표
Rachel

답변:


28

제안 된 변경을해야하는 이유 를 이해하도록 도와주십시오 . 그들이 변화를 일으키지 않을 충분한 이유가 있다면 그들에게 귀를 기울이십시오. 가장 좋은 일을 바탕으로 토론을하고 합의에 도달하십시오.

이 방법은 다음과 같은 이유로 중요합니다.

  • 확실한 비즈니스 / 기술적 이유 때문에 그들이 변화하기를 원합니다. 이것들이 무엇인지 명확하게하는 것이 중요합니다. ( 당신 도 틀릴 수 있으므로 겸손해야 한다는 것을 기억하십시오 ....)
  • 당신은 정말로 당신의 제안에 대한 추론을 전달하고 싶어합니다. 수신자는 앞으로 비슷한 문제를 스스로 해결하는 법을 배울 것입니다. 후배들이 당신에게서 좋은 통찰력을 배우고 있다고 느끼면 더 좋은 관계를 갖게 될 것입니다.
  • 당신이 당신의 선배를 사용하고 당신이 실제로 좋은 이유가 있음을 보여줄 수 없다면 당신은 존중되지 않을 것입니다.
  • 당신의 상사는 아마 당신이 그것을 위해 "내 방식대로"하는 것이 아니라 실제 가치를 창출하는 것들에 당신의 후배들의 시간을 효과적으로 사용하고 있다고 확신하고 싶을 것입니다.

당신이 똑똑하다면 질문 을하는 것만으로 답변을 얻을 수 있습니다 . 올바르게 하셨다면, 주니어는 스스로 올바른 결론을 내릴 것입니다. 질문 예 :

  • 코드는 프로덕션 데이터베이스에 액세스한다고 가정합니다. 연결이 끊긴 개발 환경에서 JUnit이 올바르게 작동하고 올바르게 테스트 할 수 있도록 어떻게 변경할 수 있습니까? (잠재적 인 답변 : 아! 의존성 주입을 사용해야합니다 ....)
  • 침입자가 온라인 데이터 입력 양식으로 고의적으로 생성 된 SQL을 일부 전송 한 경우 어떻게됩니까? (잠재적 대답 : 아! 아마도 인터넷에서 확인되지 않은 텍스트를 연결하여 SQL 문을 구성해서는 안됩니다)

편집 : 후배에게 설득하는 것이 옳은 일이 당신의 제안을 따르는 것임을 설득하는 데 성공한다면, 그들은 여전히 여기에 추가 조언이 있습니다.

  • 그들이 꺼리는 이유 를 알아보십시오 . 결과를 얻는다면 코드를 던지더라도 문제가되지 않는다는 것을 깨닫게 될 수도 있습니다. 또는 마감일 때문에 시간 압박을 느끼는 것일 수도 있습니다. 알아야합니다. 그렇지 않으면 그들을 도울 수 없습니다 .....
  • 리팩토링 기술을 향상시키기위한 방법으로 변경 사항을 처리 할 수 ​​있다고 지적 할 수 있습니다. 리팩토링 기술이 충분하면 상당히 크고 복잡한 코드 기반도 비교적 빠르게 재사용 할 수 있습니다.
  • 모든 것이 소스 제어에있을 것이므로 필요한 경우 항상 이전 버전으로 되돌릴 수 있음을 강조해야합니다.

내가 타이핑을 시작했을 때 나는 당신의 대답을 보지 못했습니다! 내가 +1 한 이유는, 내가 쓰고있는 내용의 본질을보다 우아하고 간결하게 포착했기 때문입니다. ;-)
S.Robins

@ mikera, 그들은 내 솔루션이 더 낫다는 데 동의합니다. 단지 오래된 코드를 삭제하고 새로운 코드에 투자하는 것을 꺼려합니다.
Graviton

검은 색이나 흰색이 없습니다. 사람들은 사소한 것들에 대해 버트 러질 수 있습니다. 그들은 로봇이 아니라 인간입니다. 따라서 본인의 견해를 명확하고 객관적으로 전달하는 것이 중요하다는 데 동의하지만 외교적으로 행동하십시오. 사람들을 설득하는 방법에 대한 전체 문헌이 있습니다. 그것은 과학 자체입니다. 하나를 참조하십시오 en.wikipedia.org/wiki/How_to_Win_Friends_and_Influence_People
siamii

8

나는 나의 마지막 팀 리더의 압도적 인 태도를 싫어했지만 그가 우수한 기술 지식을 가지고 있다는 사실 때문에 그를 존경하고 강의하지 않고 저에게 많은 것을 가르쳐주었습니다. 가장 중요하게도 그는 저의 계획을 강요하지 않았습니다. 그는 나의 계획을 가지고 악마의 옹호자를 연기하며, 나의 계획이 완벽하다는 것을 증명하도록 강요했다. 그는 허점을 찾고 왜 허점이 아니거나 저렴한 솔루션인지에 대한 나의 설명을 기다릴 것입니다. 그는 대안 솔루션이 있는지 묻고 내가없는 아이디어를 제안 할 것입니다. 나는 그의 아이디어와 그의 계획이 최적이 아니었다는 것을 평가해야했다. 만약 내가 나의 계획이 옳거나 최소한 그의 것과 같은 위험 보상 비율을 가지고 있다고 확신했다면, 그는 앞서 나갈 것이다. 내 생각에 실패하면 그의 해결책을 시도해야 할 것입니다.

자유와 마감일 사이에는 상충 관계가 있어야합니다. 마감 기한을 연장 할 수있는 사치가 없으며, 후배가이를 기각 할 수 없습니다. 일단 그들이 알고리즘을 시도하고 작동시키지 않으면, 그들은 당신의 말을 들어야 할 의무가 있다는 점을 정중하지만 확고해야합니다. 당신이 알고있는 것을 예를 들어 증명하십시오. 그러나 똑같이 중요하게 배우면 배우지 마십시오.


5

요구 사항 인 경우이를 참고하십시오. 당신이 알다시피 그것이 제안 일뿐이라면, 그들은 그렇지 않으면 자유롭게 할 수 있어야합니다. 내가 물어볼 몇 가지 질문 :

  • 특정 솔루션을 강요 할 권한이 있습니까?
  • 그 권한의 범위는 얼마입니까?
  • 해결책이 나쁘거나 다른가요?

더 많이 물어볼 수는 있지만 처음 두 가지는 당신의 권위에 초점을 맞추고 마지막 두 가지는 문제가 실제로 추진 될 가치가 있는지에 대한 것입니다.

다음 답변에는 몇 가지 추가 포인트가 있으며 여기에서는 단순히 지시를 내리기보다는 "팀"으로 이들 중 일부를 통해 작업하는 협업 프로세스로 다루어야한다고 덧붙입니다. 그들은 "이런 식으로 생각하라"는 말보다 더 많은 문제를 해결하면서 배울 것입니다.


나는 권한이 있지만 그것을 사용하지 않는 것을 선호합니다
Graviton

권위는 가장 양날의 칼입니다. 원한보다 동료의 지원을받는 것이 좋습니다. 포괄적 인 프로세스에 참여하지 않으면 종종 권한의 문제가 생길 수 있으며, 권한 주장을 지원하기 위해 자신의 관리자를 포함시켜야하는 경우, 성공적인 참여 가능성을 잃어 버릴 수 있습니다. 비슷한 상황에서 후배와 함께.
S.Robins

1
"다음 답변". 답변은 특정 순서로 표시 될 수 없습니다. 답변에서 참조 할 수있는 URL을 얻으려면 "링크"링크를 사용하십시오.

4

학습은 실제로 장애가 발생하는 경우에만 발생합니다. 장애는 동기 부 여자이며 향후 리콜을위한 메모리 신호를 제공하기 때문입니다. 이것은 본질적으로 우리가 경험이라고 부르는 것이며, 직장에서의 좋은 경험은 실패에서 실패하고 배운 것에서옵니다. 만약 당신의 후배들이 처음으로 모든 것을 올바르게 할 수 있다면, 그들은 아무것도 배우지 않았거나 후배가되지 않을 것입니다.

너무 많은 후배가 엉망인 경우, 회사에 직원이 잘못 배치되어있을 수 있습니다. 시간 제한으로 인해 숙련 된 직원이 위험을 최소화하기 위해 더 숙련 된 인력이 필요하지만 초급 개발자가 실수를하더라도 문제와 지연이있을 수있는 초급 개발자 뿐만 아니라 배울 수 있습니다.

마감 시간이 촉박 한 환경에서 대처할 수 있으려면 주니어가 학습하고 경험을 쌓아야합니다. 팀 리더로서 모범을 보이고 후배들에게 효율적으로 일하도록 영감을주는 것이 당신의 임무이지만, 실제로는 후배들이 실제로 무언가를 배우기를 원한다면 개인적인 자부심과 빡빡한 일정에 대한 우려를 제쳐 두어야합니다. 따라서 실패하도록해야합니다. 따라서 전화를 거는 것은 당신의 일입니다. 때때로 당신은 후배에게 실패 할 공간을 주어야하고, 검토 과정을 통해 인내심을 가지고 아이디어를 개선 할 수있는 곳을 보여줄 필요가 있습니다. 다른 경우에는 발을 내려야하지만 그렇게하는 것은 주니어의 능력에 제대로 반영되지 않는 진정한 필요가 없다는 것을 보여줄 수있는 방식으로해야합니다.

마감 기한이 촉박 한 경우 팀 내에서의 상대적 강점에 따라 작업을 예약하고 할당해야합니다. 궁극적으로 벅은 당신과 함께 멈 춥니 다. 당신이 다른 사람을 책임질 때 당신은 모든 사람의 친구가 될 수 없습니다, 당신은 어려운 상황에서 어려운 일을해야합니다. 모든 사람을 옆에 두는 방법은 우려와 문제를 통해 사람들과 이야기를 나누는 방식으로, 팀원이 특정한 방식으로 무언가를해야하는 이유를 합리적인 사례로 만듭니다.

내 개인적인 경험에서, 당신은 두 아이디어의 강점과 약점을 논의하기 위해 후배와 일정 시간을 예약하고 협력하여 문제를 해결할 수있는 최선의 해결책을 찾아야합니다. 틀린 것으로 입증 된 다음 앞으로 나아가십시오. 할당 된 시간이 끝날 때까지 둘 다 합의에 도달 할 수없는 경우, 그 시점에서 논의 된 문제와 합의에 도달하지 않았다는 점을 고려한 요약으로 회의를 마무리해야합니다. 회의 결과에 관계없이, 시간을 보낸 후배에게 감사의 말을 전하고 결정을 내릴 것임을 나타냅니다.곧. 토론을 신중하게 고려한 후에는 추가 토론을위한 추가 시간을 할당하거나 후배에게 회의 결과에 따라 어떤 계획을 세울 것인지 지시 할 수 있습니다.

그렇습니다. 시간은 때때로 소중합니다. 그러나 후배를 선택할 때는 자신의 전문성 개발에 투자하고 육성해야 할 책임이 있다는 사실을 받아 들여야하며, 결과적으로 한동안 받아 들일 필요가 있습니다. 적어도 당신은 시간이 들었습니다.


4

나는 당신이 실제로 당신의 제안을 무시하지 않는 방식으로 제시하고 있는지 질문 할 것입니다. 다음과 같은 문구를 사용하는 경우 :

내 솔루션은 그들의 것보다 훨씬 우수합니다

내 마음 깊은 곳에서 내 알고리즘이 알고리즘보다 훨씬 우수하다는 것을 잘 알고 있으며, 그냥 알고리즘을 채택해야합니다.

"나의 길은 우월하다"는 태도로 당신이 올 수 있다고 생각합니다. 그런 태도를 취하는 사람은 없습니다. 과거에 그것을 받았을 때, 나는 다른 알고리즘을 사용하여 사람을 잘못 증명하기 위해 적극적으로 나섰습니다. 후배들도 같은 일을하고있을 수 있습니다.

더 좋은 방법은 사람과 함께 앉아 알고리즘을 논의하는 것입니다. 그것이 효과가 없을 것이라고 생각하는 이유를 지적하고 그들이 열린 마음으로 당신에게주는 대답을 들어보십시오. 알고리즘이 올바르게 작동하도록 수정할 수 있는지 확인하십시오.

주니어가 가진 것이 확실히 효과가 없다면 왜 효과가 없는지 설명하십시오. 어떤 부분이 잘못되었거나 나중에 다시 작성하거나 비즈니스 모델에 맞지 않는 부분 그들이 당신의 이유를 잘 이해하도록하십시오. 그런 다음 알고리즘이 작동하는 부분과 코드가 실패하는 부분을 지적하면서 알고리즘을 설명하십시오.


3

우선, 주니어가 당신의 제안을 채택하지 않은 진짜 이유를 알고 있습니까?

때때로, 당신은 주니어가 실제로 새로운 관점과 최신 CS 교육으로 인해 선배보다 더 나은 것을 쓸 수 있다는 것을 알고 있습니다. 선배로서 더 많은 실제 사례를 보았을 것입니다. 그러나 종종 선배들이 때때로 겪는 나쁜 함정은 모범 사례가 시간이 지남에 따라 바뀔 수 있다는 사실을 잊어 버리는 것입니다. 그러나 이러한 사이트에서 자신을 업데이트하고 있기 때문에 이것이 적용되지 않을 것입니다. ;)

선배의 "아우라"가없는 후배들에게 다가 가서 그들과 레벨 용어로 이야기하고 그들이 작성한 코드에 호기심을 나타내도록 제안합니다. 질문하고 답변을 들으십시오. 다음과 같은 비난적인 방법으로 묻지 마십시오.

"귀하의 코드는 융통성이 없으므로이 코드로 변경해야합니다 ..."

대신 물어

"누군가 코드를 처리 할 수 ​​있다면 어떨까요? ... 전략 패턴이 도움이 될 것 같습니다. 어떻게 생각하십니까?"

이것은 내가 아는 것처럼 그들을 내려다보고있는 교수 / 강사보다 더 건강한 대화에 참여하는 데 도움이 될 것입니다. 또한 그들의 추론과 관점을 더 잘 볼 수 있도록 도와줍니다.


2

저장소에 대한 푸시 액세스를 제어합니까?

오픈 소스에서 푸시 액세스는 항상 품질을 담당하는 게이트 키퍼가 제어합니다. 그들이 추진하고있는 커밋을 적극적으로 모니터링하고 있다면, 커밋이 어디에서 개선 될 수 있는지 잘 알고 있어야합니다.

그들이 코드를 해킹하거나 향상 시키나요? 코드 작동 방식에 대한 내부 정보를 볼 수있는 기회가 있으면 스타일에 더 잘 적응하는 방법을 배울 수 있습니다. 열린 마음으로 제안을 받아들이지 않고 제안을 추진하는 경우 귀하의 의견을 경청하는 경향이 적습니다.

정답이없는 상황이 있습니다 (예 : 코딩 스타일 기본 설정). 이 경우 회사 전체 정책을 수립 (또는 시행)하여 코드 스타일이 기본 코드베이스와 일치하도록 조정되어야한다는 것을 이해하십시오. 이미 확립 된 스타일 가이드 라인 (예 : C # 용 Microsoft 스타일 가이드)을 사용하는 것이 특히 팀의 새 개발자에게 가장 적합한 방법입니다.

그들의 코딩 기술에 대한 포괄적 인 진술을하고 있다면, 그들의 선택에 대한 추론을 완전히 이해하지 못할 가능성이 매우 높습니다. 질문의 소리만으로 오만하게 들립니다. 젊은 개발자들에게 당신의 접근 방식을 강요함으로써 무엇을 얻거나 희생합니까?

스스로에게 물어보아야 할 중요한 질문 은 코드베이스의 품질을 유지 / 향상 시키거나 동료들보다 우위 / 우월성을 주장하기위한 제안입니까? 전자는 단순한 품질 관리이며 정당화 될 수 있습니다. 사다리는 귀하의 권리 여부에 관계없이 팀 역학에 해 롭습니다.

어느 쪽이든, 솔루션을 동료에게 푸시하려면 실제로 우수하다는 구체적인 증거가 있어야합니다. 성능이 크게 향상되면 개선하기에 충분히 쉬워야하며 성능에 중요한 응용 프로그램을 제외하고는 노력할만한 가치가없는 것은 없습니다. 자신의 개인적 우월감을 정당화하기 위해 다른 사람에 대한 당신의 노력을 강요하는 것은 당신이 '고대 노인'으로 선정되는 것으로 끝날 것입니다.

참고 : 수년 동안 내가 만난 최고의 재능있는 프로그래머는 항상 그들이 접근 한 방식의 배경을 뒷받침하고 설명하려는 사람들이었습니다.


2

글쎄, 이것은 젊은 프로그래머가 작성한 코드에 매우 많이 첨부되어 흥미롭고 자연스럽게 보입니다. 어쩌면 동일한 시간에 도착하는 데 꽤 오랜 시간을 보냈거나 좋은 사이트에서 선택했을 것입니다 (실제로 Hey Jon skeet는 이것을 썼습니다. 남자!!).

그럼에도 불구하고 여기에 첨부 된 기본 문자열에는 집중해야 할 코드가 첨부되어 있으며 실행 및 예상 결과가 그 이름보다 더 중요하다는 것을 이해시키기 위해 상당한 노력을 기울여야한다고 생각합니다. 이 코드를 푸시하기 위해 소스 리포지토리에 에칭되었습니다. 코드가 더 나은 이유와 향후 작업을 위해 코드를 유지 하는 면에서 선을 그려야 합니다.

몇 가지 실패가 눈에 that다는 점을 고려하십시오 (어떤 첨부 파일에 대해서도 몇 가지 마음의 상처가 필요합니다). 그러나 점진적인 노력으로 나는 그들이 와서 당신의 노력을 더 잘 이해할 수 있다고 생각합니다. 약간의 시간과 실패는 내가 생각할 것입니다. 그들에게 그것을 강요하는 것은 몇 가지 성공 사례를 끝낸 다음 종말과 반란이 될 것입니다.


2

사람마다 스타일이 다릅니다. 10 명의 다른 사람을 찾아서 사소한 문제가 발생하면 10 가지의 "코딩 표준"스타일을 사용하여 10 가지의 다른 접근 방식을 제공합니다.

요점 : 중요한 것을 고르십시오. 후배가 올바른 해결책을 제시하지 않는 무언가가 당신에게 제시되면, 비효율적으로 (여기서 나 지시가 아닌 +1 차수) 또는 보안 허점을 만들면 문제와 이유를 설명하십시오. "이 작업을 수행했을 것입니다."라는 의견이 있다면, 그 작업을 훌륭하게 수행 한 것입니다. "그 일"을 수행 한 후 "다른 작업"을 수행했지만 문제가 여전히 충분히 해결되었습니다 (위의 내용 참조). 다음 기능으로 넘어가거나 수정하십시오.

훌륭한 리더가되는 학습의 일부는 실제로 중요한 것과 그렇지 않은 것을 인식하는 것을 배우는 것입니다. 또한 그룹을 통해 모든 것을 조사해야하는 경우 그룹의 성능에 잠재적 병목 현상이 발생합니다.

편집 : 귀하의 제안이 진품이며 가려지지 않은 요구 사항인지 확인하십시오. 제안은 그저 자유롭게 따라갈 수있는 제안입니다. 요구 사항 인 경우 그대로 명시하십시오.


2

다른 사람들이 지적했듯이, 주니어 개발자에게 제안 사항을 실제로 증명하고 있으며 그와 같이 문구가 표시되어 있다면 그들이 따라하지 않으면 화가 났을 때 근거가 없습니다. 그렇게 할 이유가 많지 않습니다. 마찬가지로, 당신은 그들이 어떤 방식으로 일을하는 실제 방향이 아니기 때문에 당신의 제안을 따르지 않기 위해 그들을 rate 아갈 수 없습니다.

주니어 개발자가 원하는대로 작업을 수행하도록 시도하는 것과 관련하여 다음과 같습니다.

  • 귀하의 용어를 제어하는 제작 제안하는 것은 메이킹과 동일하지 않습니다 추천 결정적으로 제공하는 등 동일하지 않습니다 방향 . 이에 따라 용어를 사용하여 요점을 파악하고 무언가를 수행하는 방법이 더 나은 방법이라고 생각되면 권장 사항이라고 알려주십시오. 마찬가지로, 주어진 방식으로 작업을 수행하는 것이 절대적으로 중요하다면 (즉, 시간 지연을 견딜 수없는 경우), 무딘 상태에서 작업 수행 방향을 지시하십시오.
  • 주니어 개발자는 문구를 어떻게 표현하든 관계없이 학습 과정을 계속 진행하고 있습니다. 특별한 이유가없는 한 항상 말하고있는 내용 뒤에 어떤 종류의 추론을 제공하십시오. 이 경우에도 대부분의 사람들은 "이러한 방식으로해야하는데 스스로 신경 쓰지 않지만 이미 결정을 내 렸습니다"라는 문구를 따라 말하면 대부분의 사람들은 이해할 것입니다. 그들은 상당히 합리적인 경향이 있습니다.
  • 그것이 진정한 제안이라면 아이디어가 실제로했던 것보다 실제로 더 나은지 확인하십시오. 그렇지 않다고 생각되면 개발자와 함께 앉아 코드 및 개념 검토를 수행하여 솔루션을 정당화 할 수 있습니다. 일단 그들이 다른 사람에게 설명하기 시작하면 올바른 질문을하면 더 나은 방법을보고 스스로 기록 할 수 있습니다.
  • 솔루션이 원래 제안한 내용과 유사한 경우 세부 사항을 간략하게 언급하지 마십시오. 제안한 내용을 고려하여 제안한 내용에 따라 약간 다르게 수행하거나 원래 개념을 변경했을 수 있습니다.

2

이것은 단위 테스트에 대한 완벽한 소개입니다. 하급 개발자에게 솔루션이 있다면 테스트 할 수 있어야합니다. 코드를 강조하기 위해 단위 테스트를 생성하도록합니다. 그런 다음 단위 테스트를 검토하십시오 . 테스트에 구멍을 표시 할 수 있으면 테스트를 다시 실행하고 압력 하에서 용액이 깨지는 것을 쉽게 확인할 수 있습니다.

이를 통해 솔루션이 더 나은 이유를 보여주고, 코드가 변경 될 때 재사용 할 수있는 단위 테스트를 제공하고, 주니어 개발자에게 유용한 학습 경험을 제공합니다. 그리고 누가 알더라도, 그들의 해결책이 훌륭하다는 것을 알 수 있습니다.


2

어느 시점에서 당신은 담당해야합니다. 당신은 그들이 그들의 의견을 표명하려고 노력하는 것처럼 들린다. 당신의 제안은 완벽하지 않을 수 있습니다. 다른 개발자들은 당신을 이해하지 못하거나 동의하지 않을 수 있습니다. 그들은 아마 서로 동의하지 않을 것입니다. 당신이 책임지고 있다면 민주주의가 아닙니다. 그들은 일을 할 때 알았습니다.

그들이 당신을 따라야 할 상황이 없다면, 당신은 그들의 상사로서의 자격이 없으며 그 목적을 달성하지 못합니다. 팀에서 역할을 사용하지 않을 계획이라면 권한이 아닌 리소스가되도록 역할을 변경하십시오. 어느 시점에서 당신은 가능한 시간 제약 하에서 할 수있는 최상의 코드를 제공해야하며, 모든 코드 라인이 끝날 때까지 모든 코드 라인에 대해 다시 토론하고, 연구하고 토론 할 수 없습니다.

명령을 내립니다. 결과에 따라 생활하십시오. 경험을 통해 배우십시오. 존중은 양방향 거리입니다. 당신은 그것을 보여주고 있지만 그렇지 않습니다.


나는 이것을 백만 번 찬성했다.
HLGEM
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.