프로그래밍을 선호하는 리드 프로그래머를위한 옵션은? [닫은]

올해 초 저는 팀의 수석 개발자가 다른 부서로 이사 한 후 수석 개발자 역할로 승진했습니다. 나는 약 5 년의 경력을 가지고 있으며 가용성과 과거 성과로 인해 프로젝트를 이끌 기위한 경영진의 주요 선택이었습니다. 나는 조금 불안했지만 경력 발전과 경험을위한 좋은 기회라고 결정했기 때문에 동의했습니다.

그러나 지금까지의 결론은 이전 개발자 위치만큼 즐기지 못한다는 것입니다. 여러 릴리스를 통해 5 명의 개발자 팀을 성공적으로 이끌었지만 코드는 거의 만지지 않습니다. 대신 코드 검토와 함께 계획 및 디자인 및 팀 관리를 수행합니다. 더 많은 것을 추적하고, 팀에 할당 할 수 있도록 작업을 계획해야 할 필요가 있습니다. 시간외 근무는 거의 없지만 일을 떠날 때마다 매일 화상을 입는다는 느낌이 들며 그 결과로 외근 시간을 즐겼다 고 생각하지도 않습니다.

내 질문 : 당신은 어떻게 그런 상황을 어떻게 처리하셨습니까? 비슷한 상황에있는 사람들에게 업무를 즐겁게하는 팀, 작업 및 시간을보다 잘 관리 할 수있는 방법을 찾았습니까? 아니면보다 개발 지향적 인 위치로 다시 전환 할 수있는 방법을 찾았습니까? 필자는 개발자의 직위가 거의 항상 높은 월급을 받는다는 것을 알고 있지만, 현재 직장에서의 즐거움에 대한 것보다 돈과 승진에 대해 덜 신경 쓰는 지점에 도달하는 것을 볼 수 있습니다.

최소 1 년 동안 조정을 시도해야한다고 생각했기 때문에 경영진과이 문제에 대해 논의하지 않았습니다.

내가 여기에 제공하는 대답은 잠재적으로 작동 할 수있는 것에 대한 최선의 추측이지만, 자신을 찾고있는 비슷한 상황에서 벗어나려고 노력하면서 나는 그것이 효과가있는 것을 보지 못했습니다. 모든 것은 여전히 ​​학습 경험이지만 팀에서 긍정적 인 추세를보고 있습니다.

저는 회사에서 팀 리더로 승진했으며 ( "디자인 리드"라고 함) 제품을 알고 경험이 풍부한 사람들이 부족하여 2 개의 다른 팀을 이끌었습니다. 몇 달 전 "일정을 돕기 위해"경영진은이 두 팀의 규모를 두 배로 늘 렸습니다.

내가하려고했던 것 ...

1. 모든 사람 (관리자 포함)에게 내 직원과 다른 사람의 입장이 영구적 인 임무가 아님을 분명히하십시오. 모든 사람은 판에 올라 프로젝트를 더 넓게보고 건축 / 디자인 결정에 참여할 수 있습니다. 결의없이 의견이 일치하지 않는 한, 지금까지는 결코 일어나지 않았다면 마지막으로 말씀 드리겠습니다.
2. 다른 사람들이 개발하고 성장하도록 돕는 데 집중하십시오. 코딩과 디자인, 일에 대한 다른 접근 방식에 대해 다른 시간에 다른 개발자들과 (거의 철학적으로) 토론했습니다. 이러한 토론 중 일부는 실제 작업과 관련이 있으며 다른 토론은 순수한 사고 연습입니다. 나는 20 년 이상의 경험을 가진 사람이 있었고, 그의 책장으로 돌아가서 C ++ 책을 집어 들었습니다. 이러한 논의는 다소 전염성이 있으며, 이러한 주제를 충분한 시간 내에 제시 한 후에 사람들은이 주제에 대해 스스로 생각하기 시작합니다.
3. 내가 할 수있는 한 다른 사람들에게 위임하십시오. 많은 것을 살펴 보지만 모든 단일 코드 검토에 참여하지는 않습니다. 대신 나는 중급 사람들을 위해 코드 리뷰를하고 그 사람들이 더 친환경적인 사람들을 위해 코드 리뷰를 할 수있게했다. 코드 검토는 "모든 행을 읽고 가능한 모든 버그를 찾아야합니다"라기보다는 지식 전달 도구의 하나 이상으로 간주됩니다.
4. 인터페이스가 정의되고 기본 디자인이 정해지면 새로운 직원들도 클래스 내부 코딩을 최대한 자유롭게 할 수 있습니다. 예, 많은 코드가 완벽하지는 않지만 테스트를 거쳐 작동합니다. 그것이 "코드 냄새"와 관련하여 특정 주관적 경계를 넘어서고 그것을 리팩토링하지 않았다면, 특정 클래스를 분리하거나 재 배열해야한다고 제안합니다. 때로는 고통 스럽지만 며칠 후에 다시 확인하고 "나는 그것을 인정하는 것을 싫어하지만이 코드는 훨씬 나아 보입니다"라는 응답을 받으면 실제로 따뜻하고 퍼지 느낌을줍니다.
5. 사람들에게 도전하십시오. 제품에 추가 할 기능을 지정하는 대신 해당 기능을 추가하도록 요청하지만 기존 클래스의 기능 / 데이터 멤버 수를 늘리지 않고 추가하십시오. 새로운 것을 넣어야한다면, 기존의 것을 가져 와서 그것이 무엇인지 알아 내야합니다. 모든 사람들은 리팩토링에 대해 알고 있지만, 처음에는 추가적인 힘이 없다면 사람들이 실제로 그렇게하는 데 도움이 필요한 것 같습니다. 최소한 모든 코드 검토 중에이 지점을 방문하는 것이 좋습니다.
6. 균형에 관한 모든 것. 팀원 중 다른 모든 사람을 바라 보는 유일한 선임자가 될 수는 없습니다. 일주일 내내 회의와 리뷰를 할 수 없습니다. 팀이 저지르는 모든 실수를 잡을 것이라고 기대할 수는 없습니다. 하루가 끝나면 리드가되기위한 시간을 할당해야하지만 개발자가되기 위해 시간을 할당해야합니다. 코딩 할 수 없다면 미쳐 버릴 것입니다. 다른 모든 것들이 있더라도 코드 작성뿐만 아니라 실제로 정말 멋진 것들을 작성할 시간이 있는지 확인합니다. 방금 템플릿 메타 프로그래밍 서적에 손을 대고 Boost 내부를 파기 시작했습니다. 그 물건을 생각해 낸 사람들은 미쳐야합니다 (좋은 방법으로). 경영진이 왜 모든 것이 검토되지 않는지 또는 멍청한 놈이 다른 멍청한 놈 코드를 검토하는 이유에 대해 당신을 괴롭히기 시작하면, 당신은 전체 균형을 설명하고 팀에 경험이 풍부한 사람들이없고 하루가 끝날 무렵 "그게 무엇인지"라고 설명하면됩니다. 팀에 선임 직원이 있다면 권한을 부여하고 자신의 디자인 / 검토 / 다른 사람들을 도울 수있는 자유를 주어야하며 단순히 코드 생성기로 취급하지 마십시오. 권한을 부여하면 자유가오고 사람들은 자유를 사랑합니다. 자유 / 권한을 신경 쓰지 않는 개발자가 있다면 괜찮습니다. 모든 팀에는 여전히 순수한 코더가 필요합니다. 균형을 유지하기 위해 노력하십시오. 그런 다음 그들에게 권한을 부여하고 그들 자신의 설계 / 검토 / 다른 사람들을 도울 수있는 자유를주고 그것들을 단순한 코드 생성기로 취급하지 마십시오. 권한을 부여하면 자유가오고 사람들은 자유를 사랑합니다. 자유 / 권한을 신경 쓰지 않는 개발자가 있다면 괜찮습니다. 모든 팀에는 여전히 순수한 코더가 필요합니다. 균형을 유지하기 위해 노력하십시오. 그런 다음 그들에게 권한을 부여하고 그들 자신의 설계 / 검토 / 다른 사람들을 도울 수있는 자유를주고 그것들을 단순한 코드 생성기로 취급하지 마십시오. 권한을 부여하면 자유가오고 사람들은 자유를 사랑합니다. 자유 / 권한을 신경 쓰지 않는 개발자가 있다면 괜찮습니다. 모든 팀에는 여전히 순수한 코더가 필요합니다. 균형을 유지하기 위해 노력하십시오.
7. 당신의 시간은 소중합니다. 따라서 팀에게 시간이 아닌 중요한 질문을 모두 이메일로 보내달라고 요청하면 몇 시간 동안 기다렸다가 답변을받을 수 있습니다. 질문을 받으면 전체 팀을 복사해야합니다. 결국, 당신이 하루의 휴식을 취할 때, 당신은 문제를보고 그 사람을 도울 수 있지만, 여러 번, 누군가 다른 사람이 이미 당신을 대답으로 이겼을 때 당신은 아무것도 할 필요가 없습니다. 분명히 리드로서, 나는 여전히 나 자신을 이용할 수있게하고 그 사실을 분명히한다. 왜냐하면 나의 목표 중 하나는 팀의 어느 누구도 진보하지 않고 오랜 시간 동안 고착되지 않도록하는 것이다.
8. 팀이 의사 소통을보다 효과적으로하기 위해 가능한 많은 도구를 사용하도록하십시오. 예를 들어 우리는 위키 사이트를 가지고 있으며 같은 문제가 여러 번 발생할 때마다 마지막으로 위키 페이지를 만들도록 도와주었습니다.

나는 관리 담당자와 이것을 논의하지 않았습니다

아마도 이것이 도움이 될 것입니다. 당신의 불편 함을 직책과 전한다고해서 반드시 구체적인 내용을 밝힐 필요는 없습니다. 경영진은 보유하고있는 카드를 알 수 있으며, 관리가 잘되면 최고의 잠재력을 발휘할 수있는 방법을 찾게됩니다. 덜 정착하지 마십시오.

프로젝트가 끝나면 회사 나 프로젝트 외부에서 더 프로그래머 지향적 인 위치를 찾으십시오.

기술에 대한 관리가 적고 기술적 인 "손"을 원하는 경영진과상의하십시오.

PM 개발자 대 리드 개발자 인 것 같습니다. 나는 수석 개발자가 더 많은 코딩을하는 것을 고려할 것입니다.

고용주 관점 :

당신이 현재 직장을 즐기고 좋은 역사를 가지고 있다면, 나는 당신을 계속 유지하고 당신을위한 장소를 찾고 싶습니다. 그래서 나는 그들과 이야기하는 것에 대해 걱정할 필요가 없습니다.

훌륭한 개발자는 귀중한 일이지만, 저글링 행위보다 코딩 및 디자인에 더 많은 가치가 있다는 것을 판매해야합니다.

승계 계획을 수립하여 퇴근 할 수있는 길을 알려주십시오. 기본적으로 현재 팀에서 두통을 일으키는 일에 관심이있는 사람을 찾으십시오. 다음 6-9 개월 동안 훈련하여 한 번에 하나씩 작업을 수행하십시오.

주간 상태 업데이트와 같이 쉬운 것을 먼저 선택하십시오.

• 상태 업데이트를 할 때 옆에 앉으십시오.
• 다음 상태 업데이트를 수행 할 때 옆에 앉습니다.
• 학생들이 스스로 할 수 있도록하고 최종 결선 전에 검토하십시오.

그런 다음 추가 책임의 위엄을 넘길 때까지 점진적으로 추가 작업을 수행하십시오.

이처럼 덜 바람직한 일자리가 더 많이 지불되는 이유는 그들이하지 않으면, 더 높은 수준의 기술 공급과 수요가 필요하기 때문에 당연하지 않기 때문입니다.

당신이 더 높은 지불을 유지하기 위해 ... 그것은 내가 있다면 당신이 주위에 머무르고 있다고 듣고 싶습니다, 당신은 필요할 때이 사람을 도울 것입니다, 새로운 사람들에게 멘토가 될 것입니다, 디자이너 / 핵심 두뇌가 될 것입니다 / 프로젝트 리더보다는 도메인 전문가. 기본적으로 이것은 귀중한 위치입니다. 다른 사람이 뛰어 다니면서 저글링 행동을 할 수 있습니다 (더 분명히 지불하십시오).

나는 당신이 6-9 개월 계획을 고용주에게 제시한다면

• 다른 책임자에 대한 코딩에 중점을 두는 것이 더 나은 방법이라고 생각하는 이유를 잘 설명합니다.
• 누가 누구를 대체해야합니까 아니면 누군가를 찾아야합니까? 이것이 제가 생각하는 핵심 결정자가 될 것입니다.
• 6 개월 동안 새로운 사람에게 어떤 책임을 물려 주어야합니까?
• 디자인, 코드 리뷰 등에 앉아 책임을 져야 할 책임이있는 책임자
• 임금 인상에 대한 아이디어는 (원래와 지금 사이의 어딘가에) 그들이 이것을 가져 오게 할 것입니다.

당신이 저를 위해 계획으로, 고용주로서 함께한다면, 나는 그런 일을하는데 당신과 함께 일하게되어 기쁩니다.

행운을 빕니다.

나는 정확히 당신의 상황에 있었다. 답은 관리자와의 관계에 달려 있습니다. 제 경우에는 매우 좋은 것이 었으므로 언젠가 그를 제쳐두고 일을 즐기지 않고 너무 스트레스를 받고 코딩으로 돌아가고 싶다고 말했습니다. 그는 들어 와서 나가는 것보다 그 말을 듣는 것이 훨씬 더 행복했습니다. 그래서 우리는 다른 사람이 팀 리더로 인계 할 계획을 세우고 코딩으로 돌아 가려고했습니다.

게시물에서 명확하지 않은 2 가지 질문 :

• Google, Microsoft 또는 Fog Creek과 같이 작성하는 소프트웨어에서 직접 돈을 버는 회사에 있습니까?

• CEO는 기술자입니까, 아니면 비즈니스 역할을 통해 일어 났습니까?

기술자 CEO가있는 소프트웨어 회사 인 경우 걱정하지 마십시오. 기업 리더십은 귀중한 개발자가 누구인지 파악하고 유지하기 위해 필요한 모든 조치를 취할 것입니다. 임원이 "사람 관리"또는 "예산 관리"라는 줄무늬를 가진 사람들이라면 모두 걱정해야합니다. 내부 IT 부서에있는 경우 두 배로 걱정하십시오. 이 경우, 일과 삶의 균형이 개발자 유지에 대한 보상이라는 사실을 인정해야합니다.

마지막 요점-당신을 행복하게 할 수있는 일을하십시오. 이와 같은 직업 선택에 대한 다른 사람들의 조언은 그들을 행복하게 만드는 것에 관한 것이며, 이것은 당신에 관한 것입니다.