선임 프로그래머의 신뢰 회복

상사는 내가 생각하는 것만 큼 똑똑하지 않다는 것을 알았습니다.

내 경험의 예 :

저는 주니어 프로그래머입니다. 저는 두 명의 팀, 상사 (고급 프로그래머)와 저의 팀에서 일하고 있습니다.

우리 회사에서 근무하는 내부 웹 애플리케이션을 개발하는 일을 맡았습니다. 백엔드를 프론트 엔드에 작성했습니다 (데이터베이스 디자인이 이미 있고 서버 기술이 선택되었습니다). 그는 웹 응용 프로그램의 작동 상태를 관찰하여 정기적으로 내 진행 상황을 확인하고 웹 응용 프로그램이 나오면 기뻤습니다. 웹 응용 프로그램을 마쳤을 때 그는 최종 제품이 얼마나 좋은지 기뻐했습니다.

며칠 전 그는 코드에 관심을 가지기 때문에 내가 어떤 기술 (프론트 엔드)을 사용했는지 알려주었습니다. 웹 응용 프로그램의 프런트 엔드에는 Javascript 프레임 워크 (Backbone.js)를 사용했습니다. 내가 왜 그런 짓을 할 것인지 물었을 때. 내 응답은 프레임 워크가이 앱에 잘 맞는다고 생각했기 때문에 처음부터 코드를 작성하는 것보다 코드를 더 잘 구성하는 데 도움이 될 것입니다.

따라서이 예를 들어 내 질문은 다음과 같습니다.

상급 프로그래머가 후배 프로그래머의 능력에 대한 자신감을 잃어버린 경우 후배에게 신뢰를 얻기 위해 무엇을보고 싶습니까?

편집 : 훌륭한 답변과 지원 피드백에 대해 모두 감사합니다!

그가 제작 한 제품은 마음에 들었지만 Backbone 사용에 문제가있는 경우 원하는 기술 스택에 대한 대화가 필요합니다.

개발자는 쉽게 사용할 수있는 도구를 사용해야하므로 작업 흐름을 원활하게 이동해야합니다. 그가 당신이 처음부터 프런트 엔드를 구축 할 것을 기대했다면, 그는 명백하고 정당한 이유가 있어야합니다.

그가 처음에 제품을 즐겼다는 사실은 당신이 잘하고 "똑똑하다"는 증거입니다.

tl; dr 당신은 잘했습니다. 선배와상의하고 그가 당신에게 기대하는 것을보십시오.

그는 그런 결정을 내릴 때 나에게 "상위"인 것처럼 보이지 않습니다. 나는 항상 "사각형 바퀴 재발견"안티 패턴 대신 적절한 프레임 워크를 사용하는 경향이있다. 그가 진정으로 선임이라면 그는 좋은 프레임 워크의 가치를 이해하고 알 것입니다. 기껏해야 다른 MVC JavaScript 프레임 워크보다 훨씬 이전에 Backbone.js의 선택에 의문을 갖기를 기대합니다. 그는 주니어로서 당신을 올바르게 멘토링하고 확인하는 데 실패했으며 (마음으로) 올바른 개발 경로를 따라 당신을 돕습니다.

자신의 지시가없는 (가정) 프로젝트를 개발할 때 올바른 선택을하고보다 유능한 개발자가되기 위해 노력하고있는 것 같습니다. 나는 그에게 당신이 선택한 프레임 워크, 왜 프레임 워크가 적절하다고 느꼈는지 설명하고, 문서화되고 지원되는 프레임 워크를 사용했기 때문에 프로젝트가 완료되었고 부분적으로 만족한다고 지적 할 가치가 있다고 생각합니다. 진전을 이룰 수 없다면 그의 눈에는 더 나아질 가치가 없을 것입니다. 당신 만이 대답 할 수 있습니다.

대부분의 답변과 의견은 귀하와 노인이 일종의 토론이 필요하며, 선임자가 귀하의 선택에 동의하지 않더라도 귀하의 결정을 강화하고 방어하는 것이 중요 할 수 있다는 올바른 아이디어를 가지고 있습니다 .

노인으로보고 싶은 것에 대한 귀하의 질문에 대답하려면 :

하급 개발자가 희미하게 실망하더라도 자신의 결정을 옹호하고 방어 할 수 있는지 알고 싶습니다. 내가 제품에 만족했지만 구현에 만족하지 않으면 주니어는 제품을 제공 할 때 내 사양에 더 구체적이어야한다고 지적 할 것입니다. 나는 그들이 그들의 입장을 견딜 수 있기를 원하지만, 그러한 경우에 올바른 선택을하지 않았을 수도 있음을 인정하고 싶다.

추신 : 저는 제가 새로운 것을 배울 수있는 기회를 제공하기 때문에 전문적인 수준에서 잘못되고 싶어하는 선배라고 언급해야합니다. 그리고 나는 스프린트 / 작업이 끝날 때 놀라지 않도록 팀의 다른 사람들이 일을하는 방법을 알고 싶습니다.

우선, 이것이 실패가 아니라 기회로 여겨 져야한다고 생각합니다. 기대치에는 분명히 불일치가 있으며, 그것이 어디에서 왔는지, 모든 것을 제대로 되찾기 위해 어떤 일이 일어나야하는지 명확하지 않습니다.

둘째, 현재의 고장으로 생각하거나 원하지 않는 전력 관계를 설정한다고 생각하는 것처럼 똑똑하지 않은 경우. 따라서 결정을 내릴 수 있다고 생각되면 기꺼이이를 방어 할 수 있어야합니다.

나는 대화를 원한다는 duggieawesome에 동의하지만 충분하지 않습니다. 들어가고, 디자인 아이디어를 토론하고, 자신이 한 일을 설명하고, 추론을 변호 할 준비를해야합니다. 또한 하나의 정답 만이 아니라 선임 프로그래머가 다른 디자인을 선호하는 데 정당한 이유가있을 수 있다는 점에 동의해야합니다. 당신이 알고있는 것에 대해 (당신이 더 잘 알고 있어야한다고 결정하지 않는 한, 그것은 또 다른 문제입니다).

디자인은 대개 트레이드 오프의 문제라는 점을 명심하십시오. 장단점에 대해 기꺼이 논의하고 장래에 설계 장단점을 논의 할 수 있도록하기 위해 둘 다 무엇을 할 수 있는지 알고 싶습니다. 어쩌면 두 사람이 당신과 같은 페이지에 더 많은 것을 기대하고 있습니까? 당신의 상사가 바보 일 수도 있습니다 (때로는 일어날 수도 있습니다)? 요구 사항에 대해 알고있는 것을 고려했을 때 실제로 잘못된 결정을 내렸습니까? 그러나 열린 마음과 확신을 가지고 실제로 이에 대해 이야기 할 의향이 있습니다.

편집 : 나는 똑똑한 것에 대해 뭔가를 추가하고 싶습니다. 내가 아는 가장 똑똑한 사람들은 모두에게서 배울 것이 있다고 생각하는 사람들입니다. 닫혀 있고 올바른 방법이 하나만 있다고 생각하는 사람들은 디자인과 같은 분야에서 상상력이 좋은 결정을 내릴 수 없으며 모든 사람들로부터 배우려는 사람들이 할 수있는 방식으로 사물을 연결할 수 없습니다. 아이디어를주고 받거나 기꺼이 공유하고 심지어 바운스하는 것은 똑똑하고 자신감이 있다는 표시입니다. 디자인의 차이가 반드시 다른 것보다 낫다는 것은 아닙니다. 유능한 디자이너를 가정하면 다른 디자인은 다르게 최적화됩니다.

나는 당신이 잘못한 것이 없다는 일반적인 견해를 가지고 있습니다. 수석 개발자는 응용 프로그램을 개발하는 방법과 결과에 관심을 가져야합니다. 프로젝트가 완료된 후 들어 와서 프로젝트 수행 방식이 마음에 들지 않는다고 말하는 것은 그다지 전문적이지 않습니다.

그러나 주요 질문에 대답하기 위해 : 상실된 후 당신에 대한 선배의 의견을 어떻게 되 찾을 수 있습니까? 우선, 당신이 그 일을했다고 생각하는지 물어보십시오. 이해하지 못하고 메모를하면 질문하십시오. 배우고 싶다는 것을 보여 준다.

둘째, 다음 작업에서 설명에서 빠진 것이 있으면 아이디어를 생각 해낸 다음 수석 개발자가 아이디어를 실행하십시오. 방법을 묻지 마십시오. b / c 이것은 여러분의 의견에 도움이되지 않습니다. 그러나 자신의 아이디어와 자신의 솔루션을 생각해 내면 올바른 길을 가고 있는지 물어보고 노력하고 있으며 작업을 수행하는 데 필요한 기술을 갖추고 있음을 보여줍니다. " y, y를 할 때 x 를 사용할 계획입니다 . 어떤 생각 이 있으 십니까?" 라는 간단한 이메일처럼 간단 합니다.

셋째, 그들이 어떻게 지내고 있는지 알기 위해 머리를 대면 코드를 보지 않고 떠나지 마십시오.

기본적으로 통신 회선을 엽니 다. 선임 개발자는 귀하 또는 귀하의 코드에 맞는 유형이 아닌 것 같습니다. 관련된 모든 사람들이 무언가가 나중에보다 빨리 빨리 생각되지 않는 것을 발견하는 것이 좋습니다.

배트에서 바로 알아 내야 할 한 가지는 당신이 선택한 프레임 워크를 포괄적으로 방어 할 수 없었기 때문에 낙심했는지, 또는 프레임 워크를 사용했기 때문인지입니다.

전자의 경우, 프로젝트에 포함시키기 위해 제 3 자 코드를 평가하고 선택하는 방법을 배우고, 그 결정을 상사에게 표현하는 방법을 알고 정당화 할 수 있도록 준비하는 것이 중요합니다. 이것은 배우기 까다로운 기술이지만 경험이 있습니다. 프로젝트에 타사 라이브러리를 포함하자마자 다른 개발자가 완전히 이해하지 못하고 완전히 제어 할 수없고 버그를 포함 할 수있는 구성 요소를 도입하기 때문에 배우는 것도 좋은 기술입니다. 보안 허점 및 기타 알아야 할 사항.

처음부터 쓰지 않아서 실망했다면 그것은 완전히 다른 문제입니다. 그는 프레임 워크 (위에서 설명한 것과 같은)의 사용을 삼가야 할 충분한 이유가 있거나, 회사 정책에 반대하거나 회사가 선택할 수있는 프레임 워크의 선택을 제한 할 수도 있습니다. 어느 쪽이든 그는 당신에게 그 사실을 알리고 그가 실패했다는 사실을 알리지 않았어야했다. 반면에 그는 프레임 워크에 편견이있을 수 있습니다. 왜냐하면 프레임 워크가 야기 할 수있는 문제에도 불구하고, 당신도 알고 있듯이 큰 이점도 있기 때문입니다. "이것은 이미 발명되지 않은 증후군"으로 인해 이미 완료되어 공개적으로 이용 가능한 작업을 다시하는 것을 의미하더라도 모든 것을 스스로 만들어야한다고 생각할 수도 있습니다.

그가 왜 프레임 워크를 사용하여 실망했는지 설명하지 않았다는 것은 확실히 효과적인 의사 소통 실패입니다. 그는 대답이 "아무것도"될 수 없을 때, 당신이 잘못한 것을 궁금하게했다. 그는 또한 당신이 스스로에게 질문을하게했고, 그것은 당신이 미래에 당신 자신의 주도권을 사용하는 경향이 줄어 듭니다. 좋은 프로그래머가 가질 수없는 한 가지 특성이 있다면 이니셔티브가 부족한 것입니다. 나는 그것이 의도하지 않은 것이라 확신하지만, 그의 태도는 당신이 그 일을 어떻게 성취했는지에 대한 작은 세부 사항을 잘 수행 한 것에 대한 찬사를 갑자기 철회함에 따라 사기를 손상시키고 있습니다.

그가 선임 프로그래머이기 때문에 그를 완전하게 만들지 않습니다.

당신의 후속 의견은 상사가 화가 나서 뭔가 새로운 것을 배워야한다는 말입니다 ....

언급하지 않은 내용이 더 없으면 HIM에 짜증이 날 것입니다.

새로운 기술을 배우는 것은 우리 업무의 큰 부분이며 모든 팀은 학습과 자기 개선을 수용해야합니다.

그러나 경영진은 걱정할 다른 것들이 있습니다. 그들은 마감 기한이 있으며, 훈련 예산이 제한적이거나 없습니다.

관리 측면에서 볼 때 다른 사람이 사용자 대신 프로젝트의 2 단계에서 작업하고있을 수 있습니다. 당신은 상사에게 그 일을하도록 귀를 표시 한 사람이있을 수 있으며, 그 사람은 이제 새로운 것에 대한 학습 곡선을 가지고 있다는 것을 알고 있습니다.

그리고 지금 이전 BUT의 BUT ....... 이것은 당신의 보스 결함입니다. 당신이 새롭고 후배라면, 그는 적어도 몇 가지 지침을 제공했을 것입니다. 어느 정도까지는 기술 사용에 대한 지침을 요청할 수도 있습니다.

시니어 프로그래머이고 주니어 프로그래머의 능력에 대한 자신감을 잃어버린 경우, 주니어에게 무엇을보고 자신감을 되찾고 싶습니까?

귀하가 사용한 프레임 워크를 사용하는 방법을 배우고 싶지 않다고 말한 경우 , 질문은 다음과 같아야한다고 생각합니다. " 선임 프로그래머 인 경우 귀하가 주니어 프로그래머라면 어떻게해야합니까? "

전문 개발자는 학습을 중단하지 않습니다. 이제까지. 그렇게하면 정체 될 것입니다. 그리고 그것은 어떤 지역에서는 좋을 것입니다. 뱅킹에는 운영에 많은 레거시 시스템이있어 유지 관리가 필요하므로 매우 느리게 이동하는 기존 시스템에 대한 지식이 좋습니다. 저의 친구가 은행에서 COBOL을 수정하여 수정 한 소스 코드가 약 30 년 동안 건드리지 않았 음을 발견했습니다 (원래 저자는 대학의 COBOL 강사였습니다). 오래된 시스템을 새로운 시스템에 통합해야하므로 새로운 것을 배우십시오.

수석 개발자로 돌아갑니다. 당신은 " 그는 새로운 것을 배워야한다는 것에 대해 화가났다 " 고 말했다 .

나는 항상 배우고 있습니다. 매년 고용주가 교육 청구서를 수령하기를 정말로 원하지만 그들이 실제로 필요하다고 생각하는 것에 가까운 것을 지출하는 경우는 드물지만, 고용 가능한 상태를 유지하여 2000 파운드의 지역 어딘가에서 지출해야한다는 것을 알고 있습니다 매년 자체 교육에 GBP (약 $ 3000 USD)가 부과됩니다.

선임자가 새로운 것을 배우지 않으면 의사 결정을 내리기 시작하고 (아마도 이미 그럴 가능성이 있음) 처리하는 코드의 품질이 틀에 박혀 있고 얻을 필요성을 느끼지 않기 때문에 코드 품질이 떨어집니다. 그 틀에서.

내가 함께 일한 최고의 개발자 중 한 명은 내가 볼 기회가 없었던 모든 종류의 것을 아는 주니어 개발자였습니다. 그는 종종 압도 당했던 식탁에 많은 것을 가져 왔습니다. 그러나 나는 그의 노력에 고마움을 느꼈으 며, 그 어떤 것에도 결코 낙담하지 않았습니다. 그가 모든 가능성을 인식하고 팀에 제시하는 데 시간이 걸렸다는 것이 기뻤습니다. 그는 이제 팀을 이끌고 테이블에 물건을 가져 오는 개발자와 그들이 배우는 것에 대해 계속 이야기합니다.

수석 개발자는 학습해야합니다. 그들은 자신의 부족함을 감추기 위해 감동적인 단어 (예 : "불쾌감")를 사용하지 않는 법을 배워야합니다. 그들은 새로운 프레임 워크를 배워야합니다 (모든 것을 배울 수없고, 그것이하는 일과 문제를 해결하는 방법을 배우고, 미래에 필요하다면 더 깊이 배우는 데 시간을 투자 할 수 있습니다). 그리고 그들은 항상 계속 배워야 할 직장에 있다는 것을 배워야합니다.