후배 개발자가 선임 팀장에게 무엇을 기대해야합니까?


44

면책 조항 : 표현 된 의견은 전적으로 본인의 것이며 고용주의 견해 나 의견을 나타내지 않습니다.

소수의 개발자는 소수이고 다른 회사는 QA / 테스트, 1은 관리자 인 소규모 회사에서 일합니다. 1.5 년 전에이 회사에 합류했습니다. 3 명의 수석 개발자는 8 년 이상의 경험이 있습니다.

이것들은 내가 팀장에 대해 한 관찰입니다. (모든면에서 그들에 비해 경험이 적고 신선하다고 생각합니다)

  1. 그들은 1 : 1에 대해 결코 토론하지 않거나 절대로 주니어 제안을 고려하지 않습니다. (나는 그들이 받아들이 든 아니든, 적어도 의견을 고려해야함에 달려 있습니다)
  2. 선임 팀장으로서 새로운 기술을 사용하여 코드베이스를 리팩토링하려고 시도 할 수 있지만 (새로운 기술을 도입하는 요인이 가능하고 다른 개발자 및 인프라도 준비되어 있음),이 팀장은 새로운 기술을 사용하는 것이 안전하지 않다고 느낍니다. 그들은 최신이 아닙니다. (내가 말하고있는 이유는 현재 프로그래밍 추세가 무엇인지 모릅니다. (예 : 모 더니 저, 부트 스트랩 및 기타 많은 오픈 소스 프로젝트와 같은).
  3. 우리의 코드베이스에서 10000 개 이상의 라인이 반복되므로에 대해 이야기했습니다 DRY: Don't Repeat yourself. 그들의 답변은 "매혹적인 기사이지만 실제로는 작동하지 않는다"는 것이었다. 방금 100 % DRY로 만들지 않으면 적어도 인터페이스를 사용할 수는 있지만 고려되지 않았습니다. * (리팩터링 할 준비가되지 않은 경우 이전 코드베이스를 건드리지 않고 새로운 기능을 위해 인터페이스를 추가 할 수 있음)
  4. 모든 선임 개발자는 패치의 유지 관리 및 핫픽스를 수행합니다. 나머지 시간은 단지 엔터테인먼트 사이트에 소비합니다. 그들은 그 일을 마치게되어 기쁘다.
  5. 새로운 기술을 도입하는 것이 나쁜가? * (타당성 요인 포함)이 가능합니다.
  6. 관리자는 또한 내가 말하는 것에 대해 가장 걱정하지 않았습니다.
  7. Junior는 팀장으로부터 많은 것을 배울 수 있다고 기대합니다. * (도움말이나 수석 코딩을 요구하지 않음).

내 질문은 :

  1. 내가 제안한 변경 사항에 너무 공격적입니까?
  2. 8 년 이상의 경험이있는 선임 개발자로부터 무엇을 기대해야합니까?
  3. 회사에서 배우고 경험을 얻는 것이 잘못된 것입니까?

업데이트 :

DRY가 비현실적이라고 생각하는 이유 : OOP 개념에 관여하고 싶지 않기 때문입니다. 그들은 반복 작업에 만족합니다.

내가 제안하는 새로운 기술 :

  1. CSS, JS, SPrite 이미지 축소 사용
  2. 인터페이스 및 .net 프레임 워크 4, 제네릭 및 기타 여러 가지 사용법.
  3. modernizr, knockout js, 반응 형 부트 스트랩,

40
참고 사항 : 수년간의 경험은 아무 의미가 없습니다. "일부 사람들은 10 년의 경험이 있고, 어떤 사람들은 1 년에 10 번 반복했습니다"라는 격언이 있습니다. 얼마나 오래 있었는지가 아니라 자신의 기술과 지식을 바탕으로 기대하십시오.
Anthony Pegram

6
라비, 당신은 그들이 배우고 성장하고 있다고 믿고 싶습니다. 너무 흔한 것은 그들이 고원에 도달했다는 것입니다. 이것은 자만심 때문인지, 단순히 도전받지 않았는지, 또는 실제로 한계에 도달했는지 여부에 따라 사람마다, 상황에 따라 다릅니다.
Anthony Pegram

5
@Ravi 당신의 인식은 그들이 당신을 안내하는 팀장이라는 것이지만, 그들의 인식은 그들이 좋은 돈을 벌기 위해 팀장을 이끌고 사람들이 무엇을해야하는지 말해달라고하지 않는 것입니다. 모든 사람들이 단지 당신을 도와 주려고하지는 않습니다. 많은 사람들이 자기 개선없이 팀 리더가되어 회피 할 수 있다면 스스로 개선하지 않아도됩니다.
Jimmy Hoffa

14
당신은 이미 그들보다 앞서 있으며 그들은 그들이 당신과 함께 일할 준비가 된 위치로 자신을 높이는 데 관심이 없습니다. 회사를 해고하십시오.
user16764

5
일반적으로 나는 무언가를 더 깨끗하게하는 새로운 기술을 원합니다. 그러나 새롭고 반짝이기 때문에 많은 새로운 기술을 도입하지 않도록주의해야합니다. 프로젝트가 막 시작되었거나 새로운 기능이나 리팩토링이 필요한 경우 새로운 것을 소개 할 수있는 좋은 기회가 될 수 있습니다. 프로젝트가 안정적이거나 (사소한 수정 만 필요) 늦었다면 새로운 것을 도입하지 않는 것이 좋습니다.
marcus

답변:


30

내가 제안한 변경 사항에 너무 공격적입니까?

구체적인 내용 (당신이 제안하는 새로운 기술, 거부하는 이유, DRY가 실용적이지 않다고 생각하는 장소 및 이유 등)이 없으면, 제안에 대한 장점의 양을 평가하기가 어렵고 공격성에 중요합니다. 그들이 새롭고 시원하다고 생각하기 때문에 그들이 새로운 프레임 워크를 사용하기를 원한다면, 가볍게 밀어 올리는 것은 너무 공격적입니다. 그들이 실제로 수천 줄의 복사 / 붙여 넣기를 코드베이스에 슬 래핑하고 있다면 (즉, 쓰레기를 쓰고 있습니다) 더 많은 공격성이 필요하다고 말하고 싶습니다.

그러나 이것은 또한 당신과 그들 사이의 대인 관계 역학에 달려 있습니다. "제 제안이 회사에 도움이된다는 것을 보여줄 수 있습니까?" 대답이 '예'라면 푸시하려는 라이센스가 있다고 말하고 싶습니다.

8 세 이상인 선임 개발자로부터 무엇을 기대해야합니까?

이것은 색 영역을 실행합니다. 사무실 정치 탐색 및 기술 고려 사항 측면에서 많은 것을 배울 수있는 정말 예리한 사람들이있을 수도 있습니다. 불행히도, 당신은 또한 이것을 많이 얻습니다 . 8 년 이상의 경험을 가진 사람들은 최소한 해고 당하지 않는 최소한의 일을하는 사람들이 부족하지 않습니다. 멘토 나 정말 예리한 사람을 찾으면, 그보다 덜 일반적이기 때문에 가능한 한 많이 붙잡 으십시오.

회사로부터 좋은 학습을 기대하는 것이 잘못입니까?

배울 사람들이 있고 일부 회사에 있습니다. 당신은 일반적인 딜레마에 직면 한 것 같습니다. 그리고 .NET Rocks 사람들을 역설하면, "회사를 바꾸거나 회사를 바꾸십시오."

즉, 특정 핵심 접근 방식과 원칙을 믿고 지속적으로 팔 수없고 자신이하고 배우고 싶은 것을 배우고 배울 수있는 자유를 얻는다면 더 나은 회사를 찾는 것이 좋습니다. 당신에게 적합합니다.


1
나는 모든 새로운 것들의 데모를 보여 주었다. 여전히 그들은 불편하다. 내 업데이트 된 대답을 참조
라비 Gadag

1
당신의 아이디어가 존재하는 것에 대한 개선이 될 것 같습니다. 다음은 거부당하는 이유를 파악하는 것입니다. 당신은 노인들과 충분한 담당자를 만들지 않았습니까? 그들은 게으른? 오해? 더 나은 사례를 만들 수 있습니까, 아니면 자신을 증명 한 후에 나아갈 수 있습니까? 그렇다면, 그것을 배설하는 것이 좋은 경험 일 수 있습니다. 그들이 게으르고 무관심하다면 그렇지 않을 수도 있습니다.
Erik Dietrich

1
그들은 무관심하다.
Ravi Gadag

6
@RaviG : 물론 그들은 무관심합니다. 당신은 신선하고 새로운 개발자이며, 당신의 뱃속보다 훨씬 큰 눈을 가지고 있고, 당신의 개발자들에게 무엇을해야하는지 말하려고합니다. 경영진 이 매일 전체 제품을 바꾸는 방법에 대한 새로운 아이디어를 가질 때 충분히 나쁘다 . pfft. 가서 해봐
Steven Evers 2013

19

나는 주니어 개발자와 자주 작동하는 선임 개발자 (또는 여기에 좋아하는 다른 멋진 제목을 삽입)로 내 관점에서 이것을 쓸 것입니다.

이것은 아마도 귀하의 선배와 선임 개발자의 선상에 모두 부족할 것입니다.

주니어 개발자들이 많이 이해하지 못하는 한 가지는 주니어가되어서 새로운 기술을 사용하고 새로운 방식으로 일을 하고 팀에 잘못된 일을한다고 말하는 것 입니다. 팀은 배달 관리에보고하고 가능한 한 빨리 새로운 것을 제공하여 회사에 최대한 많은 돈을 벌 수 있도록 (또는 고객 / 고객에게 최상의 결과를 제공하도록) 경영진에 의해 추진되고 있습니다.

때로는 시도되고 입증 된 방법이 구현의 위험보다 더 큽니다 [여기에 멋진 기술 삽입] . 마감 시간이 촉박하고 작업량이 너무 많으며 트럭에 가해지는 압력이 8 년 이상 지속 된 방식이 이번에도 수행 한 방식임을 의미합니다.

당신 이 제안한 것이 실제로 그들과 회사에 어느 정도 이익이 될 것임을 팀 에게 보여줄 수 있어야 합니다. 그렇지 않으면 동료로부터 바이 인을 얻지 못하고 동료들과 함께 경영 승인을 받기 위해 판매 팀을 팔 수 없습니다.

내가 제안한 변경 사항에 너무 공격적입니까?

전체 상황을 알지 못하면 가능할 수 있습니다. 그냥 사람들이 말하는 A는 더 나은보다 B 우리가 사용해야하므로 A가 많은 땅을 보유하지 않습니다. 왜 더 좋은지 보여주기 위해 무언가를해야합니다. 크기가 클 필요는 없으며 제안 된 방법을 보여주는 작은 구성 요소 또는 응용 프로그램이라도 충분해야합니다. 그런 다음이를 제시하고 팀의 비판에 맞설 준비를 갖추어야합니다.

선임 개발 자라 할지라도 새로운 일을하는 것이 더 낫다는 것을 동료들에게 확신시키기 전에이 작업을 수행해야합니다.

8 년 이상의 경험이있는 선임 개발자로부터 무엇을 기대해야합니까?

다른 사람들이 말했듯이, 8 년 이상의 경험이 반드시 환상적이라는 것을 의미하지는 않습니다. 그러나 일반적으로, 당신은 함정 주위에 잠시 동안 있었던 누군가로부터 많은 것을 배울 수 있어야합니다. 그들도 무언가를 가르 칠 수 있습니다.

사람들은 사람들이며 모든 사람들은 자아를 가지고 있으며 (다른 사람들보다 더 큰) 새로운 사람이 와서 지난 8 년 이상 일을 잘못하고 있다고 말하는 것보다 나쁘지 않습니다. 동시에 선임 개발자 (좋은 개발자)는 건설적인 비판을 받고 결정의 이유를 분명하게 표현할 수 있어야합니다.

회사에서 배우고 경험을 얻는 것이 잘못된 것입니까?

최신 기술과 기능을 사용하지 않는다고해서 회사 내에서 학습하고 경험을 얻지 못한다는 의미는 아닙니다. 경험은 경험이며 때로는 무언가를하는 오래된 방법을 알면 새로운 방법이 더 좋은지 더 잘 이해할 수 있습니다 . 또한 새로운 방식이 더 나은 이유설명 하는 데 도움이됩니다. 두 가지를 모두 이해하고 팔려고 할 때 더 설득력있는 주장을 표현할 수 있기 때문입니다. 나는 개인적으로 현재 일하는 최신의 가장 위대한 것들을 사용하지 않지만 매일 새로운 것을 배우고 이력서에서도 여전히 좋아 보입니다.

모든 것을 말했듯이-회사가 실제로 적합하지 않고 다른 모든 것이 실패하면 새로운 직장을 찾고 싶을 것입니다.


당신의 첫 번째 요점을 언급하면서, 그것은 수석 개발자들과의 간격이라고 생각합니다. 하급 개발자가 선임 개발자가 기술을 제시하지 않으면 새로운 기술에 대한 추진의 의미를 어떻게 이해할 수 있습니까? 신뢰할 수있는 기술을 고수하고 주니어의 devs 새로운 것들을 배울시키는 사이를 강타 할 필요가 훌륭한 밸런스도있다 (할 수 있는지 신뢰할 수있는 기술의 영역 내에서 일어날 수있는 학습의 많은있다)
루돌프 Olah

12

이것을 기회 라고 생각하십시오 .

승진은 종종 더 이상 회사에 투자 한 몇 년 동안 오지 않아야합니다. 당신은 당신이 정말로 좋은 아이디어라고 생각하는 것을 얻었고, 당신의 상사 / 동료들은 듣고 싶지 않습니다.

전략은 다음과 같습니다.

  1. 멋진 일을
  2. 얼마나 멋진 지에 대한 하드 메트릭스 수집 (이 단계는 핵심입니다)
  3. 회사의 모든 사람 (소유자 / 지도자 / 노인 / 판매자-손을 can 수있는 모든 사람)에게 측정 항목을 표시하여이를 보여줍니다.
  4. 이익

그리고 나는 profit막연한 "이기는"걸음을 의미하지 않습니다 . 4 단계는 다음 중 하나 또는 모두를 얻는 곳입니다.

  1. 프로모션
  2. 인상
  3. 보너스

회사 나 재능과 이력서에 대한 놀라운 지표를 높이 평가할 수있는 새로운 회사입니다.

나는 그것을 "굉장한 것"이라고 부릅니다 . 그리고 그것은 작동합니다 .

일화 : 나는 일관되게 훌륭하지는 않지만 노력하고 5 번의 별도의 단계 (2 개의 프로모션, 3 개의 새로운 직업, 모두 상당한 임금 인상이있는 단계)를 수행했습니다.

그런 점을 염두에두고 여러분의 질문에 직접 대답해야 할 것입니다.

내가 제안한 변경 사항에 너무 공격적입니까?

얼마나 멋진 지에 대한 메트릭스와 예제를 사용하여 아직 멋진 일을 했습니까? 오래된 말이 있습니다 (있을 수도 있습니다).

Ideas are like assholes; everyone's got one, and they all stink

가서 해봐

8 년 이상의 경험이있는 선임 개발자로부터 무엇을 기대해야합니까?

진심이야? 당신은 아무것도 기대 하지 않아야합니다 . 그러나 그들이 아는 모든 것을 배우십시오. 질문을하고, 개인적으로 자신의 작업을 검토하고, 이야기를들을 때 듣고, 자신의 말에 대해 비판적으로 생각합니다. 그들은 상자에서 ... 경험 ... 몸. 그들을 열고 배우십시오. 나의 가장 친한 친구는 훌륭한 개발자이며, 나는 항상 내가 그에게서 최대한 많이 배우려고 노력하고 있다고 적극적으로 말합니다.

회사에서 배우고 경험을 얻는 것이 잘못된 것입니까?

절대적으로하지. 그것은 당신이 무엇을 학습 할 수 없음을 의미하지 않는다 하지 할 수 있습니다. 사람들은 실수를하고 회사의 실수뿐만 아니라 실수를 통해 배우게됩니다.


3
팀의 나머지 부분이 당신의 위대함을 인식 할 수있는 수준이 아니거나 위협을 느끼면 역효과를 낳을 수 있습니다.
user16764

@ user16764 : 그 시나리오가 어떤지 좀 더 구체적으로 설명해 주시겠습니까? 나는 두 가지 반응을 모두 경험했으며, 멋진 솔루션이 모두 팀에 의해 채택 된 것은 아니지만 결코 역효과를 일으키지 않았습니다.
Steven Evers

나는 OP와 비슷한 상황에 있었을 때 이것을 시도했다. 그 후 나는 a) "이 순간에 무엇을하고 있는가"15 분마다 현장 점검을 받는다. b) 5 분은 "미국과 함께하지 말아라!" c) 내가 한 문장만큼이나 해고 될 때마다 닥쳐 (또는 더 구체적으로 말하면, "측설을 당하고있다"는 말을 듣게된다) d) "회사가 향하는 방향" 에서 변경되었습니다 ". 배달을 위해 내가 한 일이 필요하다는 사실은 논쟁의 여지가 없었지만 인정되지 않았습니다.
user16764

1
@ user16764 : 솔루션의 효과에 대한 하드 데이터를 수집하고 이력서에서 그 일자리를 구했습니까? (편집은 : BTW, 그것은 완전히 사람들이 그렇게 한 것을 최대 f'd 것)
스티븐 에버스

1
@ user16764 : 객관적으로,이 사실에서 객관적으로 보여줄 수 있다면,이 특별한 경우에, 당신이 한 일은 대단한 일이며, 사람들은 다른 사람들이하는 일을 행하기 위해 줄을 서려고 노력합니다. 평생 학습과 우수성으로 다른 모든 사람들을 끌어 올 수는 없지만, 그들은 당신을 반대쪽으로 끌 수 있습니다.
Christopher Creutzig 2016 년

4

창의력을 발휘해야한다고 생각합니다. 선배들이 연기 한 부수적 인 프로젝트 요청에 대해 물어보십시오. 독립적으로 작업하거나 다른 주니어 개발자를 고용함으로써 처음부터 많은 새로운 것을 적용 할 수 있습니다. 그것이 더 나은 것이 아니라는 것을 알고 놀라지 마십시오.

다른 접근 방식은 자체 코드 분기를 수행하고 리팩터링 프로세스를 거치는 것입니다. 나는 당신이 한 말을 기반으로 생산에 들어 가지 못할 수도 있지만 최소한 기술을 향상시켜야합니다.

누가 알다시피, 그들은 당신이 어떻게 모든 사람의 일을 더 쉽게 할 수 있는지 볼 수 있으며 프로그래밍에서 '게으름'의 진정한 사용을 받아 들일 것입니다.

다른 모든 방법이 실패하면 새로운 기술을 이력서에두고 다른 직업을 찾기 시작하십시오.


1

누군가가 8 년 동안 프로그래머로 일하고 있다고해서 그가 좋은 프로그래머라는 의미는 아닙니다. 내 생각에 좋은 프로그래머 serior 프로그래머를 만드는 것은 무엇입니까? 경험뿐만 아니라 새로운 사고, 기술, 기술 등을 배우는 것이 의지입니다. 항상 더 나아지고 개선 될 것입니다. 소위 "고급"프로그래머들은 오래전부터 사라진 언어로 된 오래된 프로그래밍 방식으로 쌓여 있습니다. 새로운 개념과 아이디어는 필요하지 않기 때문에 새로운 개념이나 아이디어가 아닙니다. 그들은 "경험"을 얻었다.

수년간의 경험보다 개선하고 배우려는 의지가 훨씬 더 중요합니다. 배우고 자하는 주니어 개발자는 이미 모든 것을 "알고있는" "고급"개발자보다 훨씬 더 좋습니다.


1

내 회사에서 일하십니까?

그러나 진지하게, 이것은 많은 대기업에서 매우 일반적인 스레드 인 것처럼 보입니다. 변화는 어렵고 비용이 많이 든다. 때때로 당신은 그것의 한가운데서 돌아 가기에 너무 늦을 때까지 얼마나 많이 알지 못합니다.

예를 들어 우리 회사는 여전히 코볼 기반 메인 프레임 화면에서 Java로 마이그레이션하고 있습니다. 10 년 전의 표준으로 기술을 최신 상태로 유지하려고 할 때 Spring 또는 JSF에서 누군가를 판매하는 것은 어렵습니다. 그래서, 내가 한 일이 제한적 인 성공을 거두었을 것입니다 (저도 JR 개발자입니다). 예를 들어보십시오. 더 많은 첨단 기술을 아는 것만으로는 충분하지 않으며이를 입증해야합니다. 다른 모든 사람들이 업무를 수행 할 때 다운 시간이있는 경우 읽을 책을 가져 오십시오. 구현에 관심이있는 기술 중 하나에 대해 설명하십시오. 그들이 유투브를보고있는 동안 당신이 그것을 읽는 것을 보았을 때 (정직하게 당신의 작전 단위가 그것을 포착하지 못하고 사람들이 해고 당했다고 말하면) 그들은 당신이 무슨 말을하고 있는지를 믿지 않을뿐만 아니라 독서.

예를 들어 수석 건축가와의 경험에 대해 말씀 드리겠습니다. 똑똑한 사람이지만 일반적으로 새로운 기술에는 관심이 없습니다. CVS (버전 관리)에서 어떻게해야하는지 물어 보면서 "오, 저는 서브 버전을 사용하는 데 익숙합니다. 그들은 이런 식으로합니다. 도와 주셔서 감사합니다." 이로 인해 CVS와 Ant vs. SVN 및 Maven에 대한 몇 가지 대화가 생겨서 도서관에서 책을 빌려서 확인했습니다. 최종 결과 : 우리는 올해 언젠가 새로운 시스템으로 옮길 것입니다. 열쇠는 그들이 잘못하고 있다는 것을 전달하지 않고 개방적이고 도움이되는 것입니다. 결국 더 좋은 방법이 많을 수 있지만 제대로 작동하면 잘못된 방식으로 작동하지 않습니다. 모든 종류의 무례한 태도는 대부분의 경우 뜨거운 물에 빠질 것이므로 조심하십시오.

그들이 단지 수용 적이 지 않다면, 당신은 수요가 많은 큰 분야에 있다는 것을 명심하십시오. 호기심이 많고 빠른 학습자가 다른 직업을 찾으면 훨씬 더 많은 직업을 얻게 될 것입니다. 나에게 돈만큼 중요합니다. 인터뷰에서 "오, 여러분은 xxx 기술을 사용합니까? 그들이하는 일에 열정이있을 때 많은 사람들이 사랑합니다.


0

나는 당신이 당신의 공격성에 옳다고 생각합니다. 열정적 인 사람들과 함께 일하는 것은 큰 기쁨이며 정신적으로 죽은 사람들과 함께 일하는 것은 큰 형벌입니다. 8 년의 경험은 아무 의미가 없습니다. 물론, 당신이 옳지 않을 수도 있습니다. 종종 신기술이 마케팅과 밀접하게 결속되어 항상 더 나은 것은 아닙니다. 그러나 당신이 옳지 않다면, 선배들은 당신이 틀린 곳을 설명해야합니다. 그렇지 않으면 직장에서 어떤 이점도 얻지 못합니다. 어쩌면 당신은 젊고 뜨겁습니다. 그렇다면 이것이 장점입니다. 성장할 수없는 직장에서 시간을 보내지 마십시오. 솔루션에 대해 토론하고 다른 사람의 피드백을받을 수있는 새로운 직업을 찾아야합니다.

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