선임 개발자의 조언이 나쁜지 어떻게 알 수 있습니까? [닫은]

최근에는 주니어 개발자로 첫 직장을 시작했고이 소규모 회사에서 멘토링을 담당하는 상급 개발자가 있습니다. 그러나 그는 내가 단지 동의 할 수 없었던 것들에 대해 조언을 해줄 때가 여러 번 있습니다. 나와 함께) 바쁜 일정을 감안할 때, 우리는 아마도 긴 토론을 할 시간이 없을 것입니다.

지금까지 나는 그에게 귀를 기울여 문제를 피하려고 노력해 왔으며, 현재의 모범 사례로 배운 내용을 바탕으로 반격을 제기했습니다. 그는 원래의 요점을 다시 제기합니다 (대부분의 경우 모범 사례, 유지 관리가 가능하지만 더 이상 진행하지 않았다고 생각합니다). 그것과 집에서 연구하지만 변경하지 마십시오 (나는 여전히 확신하지 않습니다). 그러나 최근에 그는 다시 나에게 다가 가서 내 코드를 보았고 왜 그의 제안으로 바꾸지 않았는지 물었다. 2 ~ 3 주 만에 3 번째입니다.

주니어 개발자 인 저는 그를 존중해야한다는 것을 알고 있지만 동시에 그의 조언에 동의 할 수는 없습니다. 그러나 나는 프로젝트를 악화시킬 것으로 생각되는 변경을 가하라는 압력을 받고 있습니다. 물론 경험이없는 개발자로서, 나는 틀릴 수 있고 그의 방법이 더 좋을 수도 있습니다. 그것은 예외 사례 중 하나 일 수 있습니다.

내 질문은 : 수석 개발자의 조언이 좋거나 나쁘거나 어쩌면 좋지만 오늘날 상황에서 구식인지 판단하기 위해 어떻게해야합니까? 그리고 그것이 나쁘거나 구식 인 경우, 내가 그를 수석으로 존중한다는 사실을 유지하면서 그의 '압력'에도 불구하고 그의 방법을 구현하지 않기 위해 어떤 전술을 사용할 수 있습니까?

먼저, 선임 개발자 인 저는 프로젝트를 이끌고있는 주니어가 자신의 관심사를 직접적이고 직접적으로 이끌어 줄 것으로 기대합니다. 그들이 동의하지 않는다면, 그것은 나에게 완벽하게 맞습니다. 경우에 따라 본인의 우려에 대해 조치를 취할 것입니다. 대부분의 경우, 그들의 관심사는 개발자 자신에 대한 무례 함이 아니라 다음과 같은 다른 이유로 인해 추론에 대한 짧은 설명을 제외하고 버려 집니다.

1. 주니어는 결정이 내려 졌을 때 이해할 수있는 모든 정보를 가지고 있지 않습니다. 경우에 따라 약간의 설명만으로도 개발자가 우려를 넘어서 이상적이지 않은 상황을 처리하는 데 도움이 될 수 있습니다.
2. 주니어는 나쁜 정보를 가지고 있습니다. 당신이 실제로 주니어라는 것을 잊지 마십시오. 이는 소프트웨어 측면에서 십대가되는 것과 같습니다. 좋은 아이디어가 많이 있다고 확신하지만 모든 것을 알지 못할 수도 있습니다. 가장 저항력있는 주니어 개발자는 코드, 회사, 세계에 가장 적합한 것이 무엇인지 확실하게 믿는 사람들입니다. 이러한 개발자들은 겸손을 습득함으로써 더 나은 봉사를 할 수 있습니다.
3. 특정 방식으로 무언가를하기로 결정한 것은 상급자의 머리 위에서 이루어졌습니다. 선배는 여전히 다른 사람을 위해 일하고 있습니다. 실제로 작업을 수행하는 데 더 좋은 방법, 작업을 수행하는 데 더 효율적인 방법 또는 더 나은 소프트웨어 / 하드웨어가있을 수 있습니다. 비즈니스는 여전히 의사 결정을 주도합니다. 비즈니스 관리자, 이사, VP 등은 종종 개발 프로세스에 영향을 미치는 결정을 내립니다. 이것들은 선배가 통제 할 수 없으며, 후배들이 그것에 대해 불평 할 때, 그들이하고있는 모든 것은 선배의 스트레스를 가중시키는 것입니다.
4. 선배는 그냥 고려할 시간이 없습니다. 마감일이 있으며 때로는 변경되는 패턴, 관행 및 행동이 해당 마감일에 비용이 많이 듭니다. 도마 위에 목이 있기 때문에 "완벽하게 쓰여진"것보다 제품을 기능적이고 정시에 꺼내는 것이 더 중요합니다.

이것들은 내 머리 꼭대기에서 생각할 수있는 것입니다. 아이디어, 실습, 개념이 당신보다 높은 누군가에 의해 무시되거나 버려 질 수있는 많은 이유가 있습니다. 그들 중 많은 사람들이 불쾌하지만, 그들은 모두 우리가 모두 인간이고 우리 모두 의견이 있다는 사실로 귀결됩니다. 그의 의견은 현재 귀하의 수치보다 우수합니다.

이러한 개념을 염두에두고 선임 개발자에게 계속 우려를 가져야합니다. 공란을 채울 수있는 다른 선임 개발자를 찾으십시오. 많은 선임 개발자가 사람들보다 소프트웨어를 더 잘 사용하기 때문에 현재 위치에 있습니다. 일부는 그들이 인턴 일 때 누구의 엉덩이를 키스해야하는지 알고 있기 때문에 그들이있는 곳에 있습니다. 누군가를 멘토링하고 정직한 의견을 얻는 것이 무엇을 의미하는지 실제로 이해하는 사람을 찾으십시오. 그들은 당신과 동의하지 않고 당신이 가지고 있지 않은 공란을 채울 수 있습니다. 그들은 당신과 동의하고 당신의 대의를 모으거나 상황을 개선하도록 도울 것입니다.

어떤 종류의 반란도 제기해서는 안됩니다. 당신의 마음이 당신의 길이 옳다고 믿는다 고하더라도, 따라야 할 지시를 받았으며, 분명히 불법이 아닌 한 그것을 따라야합니다. 이러한 지침을 따르는 데 문제가있는 경우, 어떤 종류의 소프트웨어를 생산하는 많은 회사에서 이러한 행동 패턴이 널리 퍼져 있는지 알기 때문에 이유를 추론하려고 할 수 있습니다.

최선의 선택은 윤리적이고 전문적으로 업무를 계속하는 것입니다. 귀하가 요청한 소프트웨어를 모범적 인 방식으로 완성하고 승진시켜 상황을 피하십시오. 프로모션이 이루어지지 않으면 다른 부서 나 회사에서 기회를 추구 할 수있는 많은 참고 자료와 경험이 있습니다.

선임 개발자를 존중하십시오. 그는 당신보다 프로젝트의 성공을위한 선상에 있습니다. 그는 책임이 있기 때문에 권한도 얻습니다. 그가 무언가를 바꾸라고 말한다면 그렇게하십시오.

이미 말했듯이 문제가 생길 때 주저하지 말고 걱정하십시오.

마지막으로 그와 함께 앉아서 여기에 게시 한 것과 동일한 질문을 설명하십시오. 어쩌면 당신은 큰 것을 잃어 버렸거나 어쩌면 그는 당신의 제안에 더 많은 것을 열어 줄 것입니다. 어쨌든 그의 조언이 좋지 않다고 생각하면 그를 어둠 속에 두지 마십시오.

이런 일이 발생 하면 선임 개발자와 대화해야합니다 . 아마도 그는 코드 나 기술 / 비즈니스 요구 사항에 대해 알지 못하는 것을 알고있을 것입니다. 그렇다면 배우십시오.

개인적으로 그렇게하십시오. 도전적인 권위로 보일 수 있으며 그러한 일들이 일대일로 가장 잘 이루어집니다. 그의 선배를 인정하고 존중함으로써 타협하고 협력하려는 의지를 보여 주지만 질문에 계속 대답하십시오. 전투 프레임이 아닌 협업 프레임에서 상황에 접근하십시오. 멘토링을 요청하는 것이 좋습니다.

하루가 끝나면 자신의 생각과 (공평하기 위해서는 비교적 새롭고 테스트되지 않은) 아이디어와 균형을 맞춰야합니다. 아마도 당신은 실제로 옳을 지 모르지만,보다 숙련 된 사람들로부터 배우기 위해 최선을 다하여보다 현명한 결정을 내릴 수 있도록해야합니다. 훌륭한 선임 개발자는 주니어 개발자들과도 협력하고 멘토로 배우고 배울 수있는 기회를 환영하며 아이디어가 때로는 틀렸다는 것을 알기 때문에 건설적인 방식으로 도전하는 것을 환영합니다.

자주 말하는 방식은 상식적인 접근 방식입니다. 선임 개발자 는 프로젝트에 대해 더 많이 알지만 올바른 일을하는 방법에 대해서는 더 많이 알지 못할 수 있습니다. 그가 말한 내용을 측정해야합니다. 그는 자신이 더 나은 주장에 직면 한 상황에서 날아 다니면 나쁜 조언을합니다 . 소프트웨어 개발을 수행하는 올바른 방법이나 최소한 업계에서 인정되는 모범 사례에 대해 책을 게시하거나 쓰는 유명한 "유명인"개발자).

다음은 선임 개발자 (또는 모든 개발자)의 "나쁜 조언"의 예입니다. 느슨한 커플 링이 무엇인지, 왜 좋은지에 대해 완전히 무지하고 모든 코드를 작성하라는 메시지가 표시되는 경우 -ASPX 파일 뒤에는 선임 개발자가 단서가 없으며 그의 조언을 듣지 않아야합니다.

다른 한편으로, 그는 시스템의 특정 모듈이 어떻게 작동하는지 알려 주면, 올바른 개발 원칙에 직면하여 침을 뱉지 않는다고 말하는 것이 가장 오래 다시 듣는 것이 가장 좋습니다.

다음은 제가 경험 한 규칙입니다. 회사의 선임 개발자는 가장 긴 재임 기간의 개발자 일 수 있습니다. 그는 실제 기술이 없을 수도 있습니다. 그는 당신의 분야에서 가장 존경받는 개발자들 (그보다 훨씬 더 많은 경험을 가지고 있고 더 유능하고 존경받는 사람들)이 말하는 것과 반대되는 말을하고 있습니까? 만약 그렇다면, 극단적 인 상황이 없다면 조언이 나쁠 것입니다.

극도로 편향된 관점에 대한 다운 보트 / 이견을 완전히 기대합니다.

선임 개발자의 유리한 점을 이해하기 어려울 수 있습니다. 물론 그는 잘못된 길로 이끌고있을 수 있지만 대규모 프로젝트의 경우 일관성이 더 중요합니다.

50 명의 일부 개발자가 모두 고유 한 코딩 스타일, 표준, 방법론 및 디자인 패턴을 따르는 것은 완전히 혼란입니다. 일이 잘못되면 많은 다른 유형의 잘못과 옳은 일보다 일관되게 잘못하는 것이 좋습니다.

유지 관리를 수행하거나 기능을 추가하거나 "잘못된"문제를 해결해야 할 때 기존 디자인의 문제를 미리 알고 있으면 훨씬 더 쉽습니다.

정중하게 동의하지 않는 것이 좋지만 결국에는 줄을서는 것이 가장 좋습니다. 불량 팀에 속한 사람은 팀 플레이어로 간주되지 않습니다.

수석이 업계 모범 사례를 무시하는 이유를 설명 할 수없는 경우 시간을 낭비하지 마십시오. 당신은 너무 위협적이기 때문에 앞으로 나아갈 수 없으며, 어쨌든 나쁜 코드 더미를 유지하는 데 시간을 보내고 싶습니까?

대부분의 개발자는 대학을 떠날 때 독서를 중단합니다. 당신은하지 않았으므로 이미 상위 10 %에 있습니다. 요즘에는 많은 기회가 있습니다. 당신의 도시에 직업 시장이 없다면, 더 나은 도시를 찾으십시오.

와우, 그것은 당신이 당신의 기술을 빛나고 보여줄 수있는 훌륭한 기회입니다. 경력 초기에는 감독관이되어 결정을 내릴 수 없었던 사람이 있었으므로 결정을 내릴 수 없었기 때문에 그 기회를 이용하여 다음 단계의 일을 수행하는 방법을 배울 수있었습니다. 그것은 나를 승진시켰다. 당신도 똑같이해야합니다.

선임 개발자로서 이러한 유형의 수동적 공격적 nit 피킹은 나를 미치게 할 것이며, 직면 한 후에는 나에게 나쁜 리뷰를 주도록 유도 할 것입니다. 완벽한 솔루션은 팀이 함께 살 수있는 솔루션입니다.

스타일은 스타일 가이드와 출처에 따라 결정된 모범 사례에 따라 결정해야합니다. 당신이 그것에 대해 열정적이라면, 일단 결정이 내려지면 결정을 내리고 팀의 범위 내에서 협력하십시오.

HLGEM이 지적한 바와 같이, 당신은 그다지 좋지 않은 상황에 처해 있습니다.이 위치를 변장 축복으로 바꿀 수 있습니다. 귀하의 질문은 다면적이므로 부분적으로 접근하겠습니다.

나는 의심한다. 그는 모른다. 동시에, 그는 저에게 오만함을 보여 주려고 노력하여 질문을 많이하지 않습니다.

이것은 사실 일 수 있습니다. 개발 또는 멘토링 관점에서 볼 때 수십 년 동안 업계에 종사했지만 유능한 소프트웨어 리더가 아닌 개발자의 발진이 있습니다 (차이가 있습니다). 경험은 새로운 도전에 대처하고 새로운 아이디어를 시도하고 새로운 기술을 배우는 데서 오는 것이지만 대부분 의 프로그래머는 회사 사무실에서 삶을 보내며 충실한 Visual Basic 및 Java 도구를 사용하여 급여 응용 프로그램에서 세계 경주를 보지 못합니다. 차갑고 회색의 사무실로

이것에 아무 문제가 없습니다 . 많은 개발자들에게 이것이 원했던 것은 물론 상황에 완벽하게 만족하는 것입니다. 그러나 미래의 프로그래머를 육성하기위한 이상적인 상황은 아닙니다.

브라바 도와 오만은 방어 메커니즘이 될 수 있으며, 부족한 부분을 다루려고합니다. 어떻게 처리합니까? 하지 마십시오 그것을 정면으로 직면 - 리드는 무능이고, 상사가 상황을 수습하려하지 않은 경우, 당신이 그것으로 살 수있을 것이다 . 그것은 롤오버하고 죽는 것을 의미하지는 않지만 누군가가 좋은 리드가되도록 강요 할 수는 없습니다 .

그러나 그는 단지 내 코드 만 검토하며 대부분의 주석은 코딩 지침과 관련이 있습니다.

이것이 그가 좋은 프로그래머가 아닐 수도 있다는 점에서 당신이 옳다고 생각하게 만드는 것입니다. 그것은 그가 현재 당신보다 더 나은 프로그래머가 아니라고 말하지는 않습니다. 효과적인 리드. 지침은 모두 훌륭하지만 코드의 기능, 효과 및 효율성에 이어 두 번째입니다.

그런 상황에서 어떻게해야합니까?

나는이 상황을 관리자에게 알렸고, 매번 "예"라고 말했지만 그가 리드를 바꾸도록 요청했지만 심각한 조치를 취하지는 않았다.

이러한 모든 특정 지점을 관리자에게 열거하고 특정 예제를 사용하여 백업 했습니까? 당신이 단순히 그에게 가서 "나는 새로운 리더가 필요하다"고 말했다면, 그는 당신을 진지하게 받아들이지 않고 기술적 문제 라기보다는 "대인 관계 문제"로 인식하지 않을 것입니다. 이 상황에서 많은 보스들의 반응은 그것이 "자체적으로 작동"할 것이라는 희망으로 그것을 무시하는 것입니다.

몇 가지 제안 사항이 있습니다.

1. 당신이 처한 상황에 처하지 마십시오. 화재로 인한 시련은 재미는 없지만 나중에 경력에 필요한 몇 가지 중요한 연구 기술을 가르쳐줍니다.
2. 더 많은 참여를 유도하기 시작하십시오. 이것을 신중하고 정중하게하십시오 . 그가 줄 때까지 계속해서 강요하십시오. (실제로 인생의 많은 상황에서 효과적입니다).
3. 리드 가 관여 하지 않으면 다른 사람이 도와 줄 수 있는지 확인하십시오. 착유 시간에만 관심이있는 땀방에서 일하지 않는 한 회사는 다른 개발자에게 밧줄을 보여주고 코드를 검토하는 데 더 많은 경험을 가지지 않을 것입니다.
4. 새로운 직업을 주시하십시오. 난 당신이 "떠나야한다"상황에 걸 언급하지 않았다하지만 걸리는 장소에 당신의 경력을 해치지 않을 것이다 당신의 더 심각 프로그래머로 개발.

특정 문제를 해결하는 더 좋은 방법이 있다면 IT를 수행하십시오 .

코드 / 솔루션을 최고의 논거로 삼으십시오. 그렇지 않으면 당신이 들었던 것에 충실하십시오.

지목 사항

내가 주니어 였을 때 특정 코드 섹션이 최선이 아닌 상황이있었습니다. 단지 그것에 대해 논쟁하기보다는, 나는 단순히 개선 THEN 내 수석에 결과를 보여 주었다. 코드는 항상 왕이기 때문에 그는 그것을 받아 들였다.

물론 경험이없는 개발자로서, 나는 틀릴 수 있고 그의 방법은 더 좋을 수 있습니다. 따라서 내 질문은 선임 개발자 조언이 좋거나 나쁜 / 오래된 것이면 어떻게 판단 할 수 있습니까?

숙련 된 개발자가 될 수 있습니다. 그렇게 할 때까지, 당신은 주니어로서의 직관이 옳은지 아닌지를 판단 할 수 없을 것입니다.

그동안 Joel Etherton의 답변을 읽으십시오.

나는 "그것을 그의 방식으로 구현하지 말라"는 것을 강력히 권유한다.

지금까지는 옳은 일을 한 것처럼 들립니다. 당신은 겸손하고 반격을 제기했습니다. 나는 당신이 단순히 그의 방법에 동의하지 않거나 당신이 동의하지 않고 대안을 제시했는지 당신의 질문에서 말할 수 없었습니다. 결론은 항상 다른 사람의 접근 방식을 격추하려고 할 때 명확하고 신중한 대안을 제공하는 것 입니다. 그가 볼 수 있듯이, 당신은 좋은 아이디어를 가지고 있으며, 그 아이디어는 효과가 있습니다.

어느 위치에서든 우리는 항상 차선책을해야합니다. 당신이 정말로 그것을 좋아하지 않는다면, 당신은 당신이했던 것처럼하고 그것을 가져올 수 있습니다. 그 후, 보스의 길이나 고속도로. 더 밝은면에서, 당신은 후배로서의 잘못된 결정의 위험으로부터 많은 영향을받습니다.

당신이 전투를 선택하십시오. 한 시간 분량의 작업에 대해 이야기하는 경우 작업을 진행할 때까지 때때로 코드를 변경해야합니다. 다음에 큰 프로젝트를 시작하면 시작하기 전에 아이디어를 제시 할 기회를 미리 요청하십시오. 약간의 시간을 들여 놀라운 데모 또는 프로토 타입을 만드십시오.

놀랍게도 내가 한 일은 묻지 않는 것입니다. 다른 옵션이 주어지면 나는 그냥 길을 잃고 그의 길을 가지만 내 자신의 감각을 더합니다. 그것을 학습 경험으로 사용하여 능력을 키우고 여전히 학교를 구식으로 유지할 필요성을 완화하십시오.

결국 모든 선임 개발자가 새로운 방식의 작업에주의를 기울이는 것은 아닙니다. 그들은 옛날 학교 방식을 가지고 있었는데, 20 년 전에 시작한 언어에는 좋았지 만 오늘날의 세상에서 해키거나 "나쁜 냄새가 나는"것으로 간주됩니다.

이것은 계속 진행하는 끔찍한 방법처럼 들릴 수 있습니다. 그러나 나는 또한 선배들에게서 일을하는 많은 방법을 배웠습니다. 그러나 이것은 실제로 제 의견입니다. 결국 당신은 당신의 일에 행복하고주의를 산만하게하고 긴장을 낮게 유지해야합니다. 그리고 물건에 반대하지 않으면 스트레스가 줄어 듭니다.

연로 때문에 고위 사람들을 믿지 마십시오. 가능한 한 자주 권위에 도전하십시오. 권한있는 당국은 어떤 질문에도 설득력있게 대답 할 수 있어야합니다. 그것이 처음에 그를 권위자로 만드는 이유입니다.

누군가가 평생 신념을 가지고 있다고해서 그가 옳다는 것을 의미하지는 않습니다. 중세 시대에 사람들은 지구가 평평하다고 믿었으며 그 일부 정당한 엉덩이조차도 의심을 죽이는 것이 정당하다고 느꼈습니다. 의심 자들이 옳다는 것이 밝혀졌습니다. 나쁜 리뷰에 너무 많은.

나쁜 리뷰를 두려워하지 마십시오. 당신은 색을 판단하는 맹인을 믿겠습니까?

위의 좋은 대답은 "모범 사례"또는 "보다 관리하기 쉬운"과 같은 응답이 무언가 를 배울 수있는 기회라는 점을 추가 할 것 입니다. "그 방법이 가장 좋은 이유를 예를 들어서 차이를 이해할 수 있습니까?" 또는 "어떤 상황에서이 방법은 다른 방법보다 유지 관리하기 쉬울 것이므로 미리 계획하는 법을 배울 수 있습니까?"

선배가 옳다면 모범을 보일 수 있습니다. 만약 그가 앵무새라면 .. 그에게 호박을 막기위한 크래커를주고, 당신이 생각하는 가장 좋은 것을하십시오. 그렇지 않으면 주문할 때까지.

시니어의 역할이 멘토 역할을하는 경우 요청시 이유를 설명합니다.

HLGEM과 Jarrod가 전에 말했듯이 이것은 변장에 대한 축복입니다. 두 답변 모두 훌륭하며 몇 가지 요점을 추가하고 싶습니다.

리드가 도메인에 없기 때문에 리드가 미들웨어에 대해 많이 알지 못하므로 애플리케이션의 일부에 대한 중요한 결정을 내릴 수 있습니다. 또한 응용 프로그램의 진행 방식, 제품 사용자가 원하는 사항 및 제품 팀이 제시 한 상황을 관리자가 어떻게 해결하고자하는지에 대해 관리자와 폐쇄해야합니다. 얼마나 많은 사람들이 응용 프로그램에 대해 그런 종류의 지식을 얻을 수 있는지 알려주십시오.

대규모 팀에 속할 경우 팀원 및 / 또는 리드의 도움을받을 것이지만, 이러한 종류의 일이 일반적으로 리드를 거치며 팀의 일부 수석 개발자. 나는 한 사람의 프로젝트가 수행하기가 다소 어렵다는 것에 동의하지만 동전의 다른 쪽이 너무 크다면 왜 기회를 놓칠 수 있습니까? 배울 수있는 것을 배우고, 즐기면서 즐길 수 있으며, 너무 힘들어지면 Jarrod가 말한대로 상황에 따라 새로운 직업 / 프로젝트를 찾으십시오.

당신은 당신의 전체 경력과 같은 사람들을 다룰 것입니다. 그리고 코딩 문제에 대한 최선의 접근 방식에 동의하지 않는 사람들이 많이있을 것입니다. 내가 수년 동안 저에게 효과가 있다고 생각한 최선의 방법은 그들이 계속해서 문제를 겪고 있다면, 그들과 먼저 맞서서 다양한 가능한 해결책 중에서 해결책을 고려했으며 그 해결책을 느꼈다는 것입니다. 이 상황에서 가장 좋은 접근 방법이라고 생각한 것이 정착되었습니다.

매번 그들의 조언에 반대하는 것을 선택한다면 때때로 가끔씩 촉촉한 깃털을 부드럽게하기 위해 때때로 그들의 "조언"을주고 사용해야 할 수도 있습니다. 그들이 당신이 매번 그들의 입력을 거부한다고 느끼지 않는 한, 그것은 당신 사이의 평화를 유지하는 데 먼 길을 갈 것입니다.

또한 이들은 선임 개발자이며 그보다 오래 동안 그 환경에서 일 해왔다고 생각하십시오. 실제 코딩은 종종 모범 사례 또는 커뮤니티 승인 표준과 맞지 않습니다. 그들이 당신이 완전히 말로 표현할 수없는 특정한 방법으로 당신을 추천 한 이유가있을 수 있습니다. 따라서 동의하지 않더라도 솔루션이 더 낫다고 생각한다는 사실만으로 조언을 무시하지 마십시오.

그것은 균형에 관한 것입니다. 코딩 밸런스뿐만 아니라 팀 밸런스도 마찬가지입니다. 많은 프로젝트는 개발자가 프로젝트를 수행 할 수 없었기 때문에 실패한 것이 아니라 서로 협력 할 수있는 방법을 찾을 수 없었기 때문에 실패했습니다.

내 개인적인 경험에서 얻은 것들을 제공하고 싶습니다 .jzd가 게시 한 것에 대한 보충 답변으로 간주해야합니다 ...

1. 다른 선임 개발자에게 문의하십시오.
2. 스스로 연구하십시오.

하나의 전문적인 약속에서, 나는 선배에게 멘토링을 받아야했습니다. 그는 어떤 것을 알고 있었지만 솔직히 그 정도는 아니었지만 불행히도 그것을 알지 못했기 때문에 그의 대답에 매우 확신했습니다. 나는 그가 말한 것이 잘못되었다고 느꼈다. 그가 한 일이 내가받은 MS 인증에 언급 된 모범 사례에 반했을 때 증거가 몇 가지있었습니다. 그 후 나는 다른 회사에서 일하는 다른 사람들 (스택 교환이 작동하지 않고 다시 실행되지 않음)을 요구하기 시작했고 블로그를 읽고 답을 비교하기 시작했습니다.

내가 틀렸다면 좋을 것입니다. 왜냐하면 내 행동을 바꾸었을뿐입니다.

나는 지난 몇 년 동안, 거의 모든 회사, 내가 수행하는 거의 모든 프로젝트, 거의 모든 신입 사원 (기술 / 경험 수준에 관계없이)이 '다른'것을 원한다는 것을 알게되었습니다.

코딩 표준 또는 전체 아키텍처 또는 언어 또는 방법론 일 수 있습니다. 그러나 그것은 항상 무언가입니다. 많은 경우, 그것은 단지 '최종 사용자를 위해 모든 것이 더 잘 문서화되지 않아야 하는가?'라는 명백한 내용 일뿐입니다.

당신에게 나의 충고는 저 사람이 아닙니다 .

언젠가, 당신은 그런 결정을 내리기 위해 고용되고 돈을 지불하는 킥 부치 급 상급자입니다. 그 날이 오면 가십시오! 그날까지 당신의 입장이 무엇인지 깨달으십시오. 내가 할 일이 내 상사를 행복하게하는 것이 걱정되는 한, 상사가있다. 급여 수준을 벗어난 결정을 다시 추측하는 것은 아닙니다. 확실하지 않은 경우 상사 / 관리자에게 문의하여 알아보십시오.

일반적으로 말해서, 모든 사람이 구식 접근 방식을 따르는 팀의 절반보다, 구식 접근 방식을 가진 팀의 절반보다, 새로운 접근 방식을 따르는 팀의 1/4, 최첨단 개발을 시도하는 팀의 1/4보다 더 오래된 것이 더 낫습니다. 새로운 접근 방식.

내가 분명히해야한다고 생각하는 모든 것에는 저류가 있습니다 : 싸우지 마십시오 . 그와의 관계를 유지하십시오. 소금 알갱이로 조언을 받아 책이나 이와 같은 사이트에서 확인하는 것이 좋지만 그를 공격하지 마십시오. 그가 수석 개발자이고 많은 프로젝트를 겪었다면, 그는 바보가 아니며, 그에게서 배울 것이 많이 있습니다. 당신이 이미 한 것처럼 보인다, 그의 관점을 이해하려는 당신의 욕망을 표현하십시오. 그가 틀렸다고 옳다고 확신하더라도 반대의 가능성을 받아들이십시오 (이미 이미 이해하고있는 것처럼 보입니다). 당신이 그를 틀리게 증명하려는 것이 아니라 그의 관점을 더 잘 이해하기 위해 논쟁하고 있다는 것을 분명히하십시오.

당신이 그에게 질문을 할 때 그가 즉시 당신에게 돌아 오지 않거나 그의 대답이 모호하거나 도움이되지 않는다면, 그가 당신을 날려 버린다고 가정하지 마십시오. 여기에서 이미 언급했듯이 그는 바쁘거나 스트레스를받을 수 있습니다.

인내하는 것도 좋습니다. 다르게 행동해야한다고 생각되는 것들을 머리 속에 적고 적절한 시점에 제시하십시오. "모범 사례"외에 제안에 대한 정당성이 있는지 확인하십시오. 그리고 옳은 일을하고 실수하지 않도록 조심하여 나중에 논쟁 할 때 신뢰할 수있게하십시오.

지금까지 나는 그 말을 듣고 반대 지점을 제기하여 문제를 피하려고 노력했습니다. 그는 원래의 지점을 다시 올립니다. .. 집에서 생각해 보지만 ... 아직 확신하지 못합니다. 그러나 최근에 그는 ... 내 코드를보고 왜 그의 제안으로 바꾸지 않았는지 물었습니다. 2 ~ 3 주 만에 3 번째입니다.

(작업에 대해 약간 편집되었습니다.)

이 부분은 저에 관한 것입니다. 당신이 올바른지 아닌지를 알 수있는 한 가지 방법은 그가 말하는 것을 이해하는 것입니다. 내가 읽은 것은 (내 자신의 역사로, 다른 사람들은 다를 수 있습니다) 주니어 개발자는 멘토의 말을 이해하지 않고 설명을 요구하지 않습니다. 당신이 그것을 알아낼 수있는 한 가지 방법은 그에게 분명히 해달라고 요청하는 것입니다. 또는 왜 이것이 코드보다 유지 관리가 쉬운가요? 당신이 이것에 대한 그의 대답을 모른다면, 당신은 그가 좋은 조언을하고 있는지 아닌지를 정말로 모른다.

저를 정말로 걱정하는 부분은 그가 여러 번 바꾸라고 요청했지만 그렇지 않은 것입니다. 그의 입장에서 볼 수있는 한 가지 방법은 다음과 같습니다. 그는 당신에게 변화를 요청하고, 이유를 묻고, (당신의 마음에 맞는) 이유를 제시하며, 당신은 변화를 거부합니다. 당신은 설명을 요구하지 않기 때문에, 그는 당신이 그 이유를 이해한다고 가정하고, 그것을 변경하기에는 너무 게 으르거나 너무 완고합니다.-선임 개발자가 당신에 대해 생각하는 것이 좋은 것도 아닙니다. 날 믿어, 이런 식으로 명성을 얻는 것보다 질문하는 것이 훨씬 낫다.

몇 가지 생각 :

1 / 작동합니까? 그의 길은 효과가 있습니까? 그의 길이 열등한 객관적인 이유가 있습니까?

객관적인 이유로, 나는 모호하지 않고 측정 할 수있는 것을 의미합니다 (성능, 버그, 코드 길이 ...) 그의 솔루션이 효과가 있고 솔루션이 좋지 않다는 것을 나타내는 객관적인 메트릭이 없다면, 그렇게하십시오. 그의 방식은 더 좋을 것입니다 ... 아마도 나머지 코드베이스와 더 일관성이 있고 작업을 더 쉽게 사용하고 재사용 할 수 있기 때문입니다. 당신은 그것을 좋아하지 않을 수도 있지만, 그것은 그게 아닙니다.

작동하지 않거나 중요한 메트릭을 수행하지 않으면 솔루션을 구현하고 솔루션과 솔루션을 비교 한 다음 시도해 보았지만 성능을 발휘할 수는 없지만 (메트릭 제공) 물어보십시오. 구현에 실수를 한 경우 또는 모르는 요구 사항이있는 경우

2 / 스타 프로그래머들은 말합니다 ... 왜 젠장? 계획, 디자인, OOP 대 절차 적, 단위 테스트, 예외 처리, 소스 제어 등 여러 가지 주요 주제에 대해 유명한 프로그래머가 서로 대립 할 것입니다.

두 솔루션 간의 작업성에있어 유일한 차이점이 누가 그것을 선호하는지는 건너 뛰십시오. 마음에 들지 않는 패러다임에서 일하면서 필요한 정신 운동의 이점을 누릴 수 있습니다

당신이되고 싶은 사람들 에게서만 조언을 받아야한다는 생각에 기초하여, 당신이 그와 같이되기를 원한다면 선임 조언이 좋다는 것이 정답입니다.

내가 포럼에 게시하고 다른 사람들로부터 답장을 받음으로써 내가 분류 한 대부분의 문제는 이렇게 약 1 년 동안 살아 남았습니다.

그런 상황에서 어떻게해야합니까?

솔직히 말해서 이것은 많은 기술 작업과 같습니다. 당신은 당신이해야 할 경우 스스로 (인터넷과 그것의 경우 도움으로) 어려운 문제를 해결할 수있는 자기 시작해야합니다.

코드 검토를 받고 건축 설계에 대한 도움을받는 관점에서, 훌륭한 관리자가 있었더라도 "정적 변수 앞에 s_"를 붙여야하는 코드 검토를 수행 한 적이 없습니다.

배우고 배우는 법을 배울 기회를 가지십시오. 그것들은 미래에 사용할 수있는 기술이 될 것입니다.

경영진이 실제로 업무를 수행 할 수있는 능력을 이해하지 못한다고 생각하면 잘못되었을 수 있습니다. 경영진은 아마도 그가 당신을 대신하고 당신의 일을 인수한다면 당신의 리드는 완전히 쓸모가 없다는 것을 이해할 것입니다.

그들이 당신을 재배치하지 않은 진짜 이유는 당신이 그들에게 제시하는 모든 도전에도 불구하고, 당신은 여전히 ​​그 일에 가장 적합한 사람 이기 때문 입니다. 그들은 분명히 당신의 작품을 다른 사람에게 넘겨 줄 위험을 감수하기에는 너무나 가치가 있습니다.

경영진의 지능을 과소 평가하지 마십시오 ...

그들은 대부분의 개발자들이 신용을주는 것보다 훨씬 더 똑똑합니다. 관리를 시작할 때까지 이것을 이해하지 못했습니다. 그들은 또한 당신의 리드가 실제로 얼마나 쓸모 없는지 알고 있지만 아마도 그 문제를 해결할 힘이 없을 것입니다.

당신을 위해 그림을 그리겠습니다. 회사에서 5 년의 경험을 가진 Lead A는 무능합니다. 관리자는이 사실을 알고 상위 관리자에게 리드 A를 해고 할 것을 권장합니다. 상위 관리자는 자신이 무능한 지 몇 년 전에 왜 다루지 않았는지 묻습니다. 관리자 A는 급여가 부풀어 오르는 급여가 있기 때문에 특히 나빠 보입니다.

또 다른 잠재적 시나리오는 다음과 같습니다. Lead A는 중요한 누군가와 친한 친구입니다. 정치적으로 너무 뜨거워서

어느 쪽이든, 대규모 조직이 양탄자 아래에서 무능한 사람들을 청소하는 것이 더 쉽다는 것과 같은 장기간의 실수로, 그들은 너무 많은 피해를 입을 수없는 수년간의 "경험"에 적합한 바쁜 일과 가짜 힘을줍니다. . 불행히도 많은 조직이 실제로 이를 수행하여 실제로 문제를 처리합니다.

물론 이런 종류의 조직의 관리자는 이런 종류의 사람들이 조직에 가져올 수있는 장기적인 문제를 해결하는 것보다 이런 방식으로 나쁜 재능을 다루는 것이 단기적으로 더 낫기 때문입니다.

따라서 근시안적이고 비 윤리적이지만 많은 개발자들이 실제로 인정하는 것보다 조금 더 똑똑하다는 것을 인정해야합니다.

으아 아아아 이 질문은 많은 것을 생각 나게합니다. 먼저 마지막 직장에서 관리자 중 한 명과 어울릴 수 없다고 말할 것입니다. 성격 문제가 아니 었습니다. 통신 문제였습니다. 나는 XYZ와 특정 관리자가 ABC라고 말한 것을 중단시킬 것이라고 말했다. 1 년 이상 그 관리자와 일하지 않으면 의사 소통이 잘되지 않을 것입니다.

지난 주. 한 남자가 싱글 톤에 대해 나에게 말다툼했다. 나는 그들이 좋지 않으며 절대 사용해서는 안되며 절대 사용할 이유가 없다고 말했습니다. 나는 그를 연결 http://www.gmannickg.com/?p=24 는 AND 가에 링크 깊이 문서에서 더 많은논쟁 후 며칠. 다른 프로그래머 (DudeB)의 날은 적절할 때 싱글 톤 만 사용한다고 언급했습니다 ( 'never'로 추가했습니다). DudeB는 그것에 대해 아무 말도하지 않았지만 DudeB는 DudeB가 모든 스레드가 싱글 톤에 액세스했기 때문에 메모리 경합이있는 프로젝트에 있다고 말했다. 이것을 언급하고, 기사를 보여주고, 메모리 논쟁을 언급 한 후 내가 주장한 사람은 싱글 톤에 대해 이야기하는 것을 좋아하지 않기 때문에 동의 한 것에 동의해야한다고 말했다.

포인트입니다. 때때로 당신은이 사람처럼 잘못 죽을 수도 있습니다 (어쩌면 누군가가 나와 함께 싱글 톤에 대해 의견이 일치하지 않을 수도 있습니다). 내 수석 프로그래머였던 관리자와의 상황에서 나는 단지 명시 적으로 요청받은 일을하고 그 직장에서 품질을 다시 심각하게 고려하지 않았습니다. 나는 허용 될 때 내가 좋아하는 일을했지만 항상 내가하도록 요청받은 것을했지만 동의하지 않으면 적어도 한 번은 올릴 것입니다.

나는 이것에 대해 완전히 다른 논쟁의 여지가 있습니다.

종종 사람들은 대부분의 산업에서 이익 극대화와 손실 최소화에 관한 최종 목표를 느슨하게합니다. 나는 이것이 무의미하게 들린다는 것을 알고있다. (따라서 부정적인 점들) 그러나 당신이 결과를 만들지 않는다면 경험과 궁핍은 거의 중요하지 않다.

사람들은 회사의 직접적인 결과에 거의 영향을 미치지 않는 매우 간접적 인 순간에 대해 속일 수 있습니다.

당신이 가장 좋은 방법에 대해 옳다고 생각한다면, 그것이 더 나은 측정 가능한 결과를 만들어내는 방법을 보여주는 것 입니다.

나는 하루가 끝날 무렵에 당신이 좀 더 경험과 존경을 얻을 때까지 헛된 것 같습니다. 이것을 학습 경험으로 사용하고 여전히 같은 방식으로 느끼면 2 년 이상 후에 다른 회사로 이동하십시오. 그때 당신과 당신의 선배들의 좋은 아이디어를 조합하여 새로운 고용주에게 깊은 인상을 줄 수 있습니다. 물론 경력 초반에 잘못된 결정을 내렸다고 생각한 이유 중 일부를 배우기 위해 주니어 개발자가있을 수도 있습니다.

[재 게시 : 어떻게 든 여기에 두 번째 계정을 만들었 기 때문에]

그러나 최근에 그는 다시 나에게 다가 가서 내 코드를 보았고 왜 그의 제안으로 바꾸지 않았는지 물었다 .

제안 또는 명령 / 지시 / 지시문 / 무엇이든 명확해야합니다.

제안 = 나는 이런 식으로하는 것이 낫다고 생각합니다. 그러나 그것은 당신의 선택입니다.

주문 등 = 나는 이런 식으로하고 싶다; 그리고 그것은 나의 선택입니다.

그것이 진정한 제안이라면, 원하는대로하고 코드를 세우십시오. 그것이 명령이라면 (그리고이 멘토는 이런 식으로 당신에게 권위가 있습니다)-그들이 말하는대로하십시오.