전담 유지 보수 작업이 프로그래머의 경력을 방해합니까? [닫은]

지난 3 년 동안의 대부분의 작업은 다시 판매하기 전에 패치 작업이 필요하거나 가끔씩 개조해야하는 레거시 시스템을 유지 관리하는 작업이었습니다.

전담 유지 보수 프로그래머가 많은 프로젝트와 제한된 개발자를 보유한 회사에서해야 할 중요한 역할을 이해합니다.

그러나 나는 현재의 경력 진행 상황을 판단하고 동료들을 바라 봅니다. 계약자 및 기업 개발자 모두; 내가 만졌지만 깊이가 많지 않은 영역에서 많은 폭을 얻었으므로 나는 뒤쳐져있는 것처럼 느낍니다. 나는 블로그를 시작하고 내 작은 git-hub 프로젝트를 작업하고 정기적으로 일을 한 후에 개인 코딩을 할 시간을 갖도록 내 인생의 일정을 조정 함으로써이 문제를 해결하기 시작했습니다.

유지 보수 작업을 피하기 위해 다른 회사와 인터뷰를해야한다고 생각합니다. 3 년의 경험을 가진 사람에게 필요한 특정 수준의 지식이 특정 수준에 집중되어 있지 않기 때문에 본인은 기술 수준에서 매우 중년 생이어야합니다. 기능 개발 경로. 따라서 현재 직장 경험의 절반은 장기적으로는 무시할 수 있습니다.

그러나 이것은 내 개인적인 딜레마를 중심으로 느끼면 사과하게 만드는 주요 질문으로 이어집니다.

전담 유지 보수 프로그래밍 역할이 초기 경력에 해로운 결과를 초래합니까? 다른 프로그래머들이 이와 같은 역할을 피할 권리가 있습니까? 이 작업 라인을 수행하면 주니어로 다시 시작할 준비가되지 않은 경우 유사한 작업을 수행 할 수 있습니까?

전담 유지 보수 프로그래밍 역할이 초기 경력에 해로운 결과를 초래합니까? 다른 프로그래머들이 이와 같은 역할을 피할 권리가 있습니까? 이 작업 라인을 수행하면 주니어로 다시 시작할 준비가되지 않은 경우 유사한 작업을 수행 할 수 있습니까?

우선, 당신은 꽤 오랫동안 주니어로 간주된다는 것을 알아야합니다. 당신이 선량하기 때문에 임의의 판촉을받을 수 있으며, 이것이 당신에게 알맞은 급여를 줄 수있는 유일한 방법이지만, 다음 직장으로 가면 여전히 주니어로 간주됩니다.

둘째, 2-4 년의 경력을 가진 사람을 고용하고 있다면, 그들의 작업이 순전히 유지 관리인지는 중요하지 않습니다. 유지 보수에 10 년을 보냈고 Greenfields 프로젝트를 고용하고 있다면 질문이있을 수 있지만 처음 몇 년간 솔직히 기대합니다.

다른 한편으로, 유지 보수에서 일한 적이없는 사람을 고용하고 있다면 더 의심 스럽습니다. 첫 4 년 동안 한 "좋은"직업에서 다른 직업으로 건너 뛰는 직업에 대한 후보자들이 많았습니다. 그리고 실수하지 마십시오. 내가 고수하려는 그린 필드 프로젝트를 고용하고 있다면 코드를 유지할지 여부는 신경 쓰지 않으며 향후 개발자가 코드를 유지 관리하는 방법을 알고 있어야합니다.

이런 직업을 피하는 다른 프로그래머들은 일반적으로 직업을 방해하지 않기 때문에 재미가 덜하기 때문에 피합니다.

마지막으로, 소프트웨어 개발 작업의 매우 많은 비율 (약 80 %는 보수적으로 추측 할 것임)이 50 % 이상의 유지 관리임을 알아야합니다.

따라서 모든 것을 끝내고 귀하의 질문에 대답하기 위해 : 아니오, 나는 그것이 당신의 경력을 방해 할 것이라고 생각하지 않습니다. 너무 오래 머 무르지 않으면 경험의 일반적인 규칙은 "매년 같은 해의 경험을 얻고있는 것처럼 느끼기 시작하면 갈 시간입니다."입니다. 매년 작년보다 나아진 개발자 인 것 같은 느낌이 든다면 괜찮을 것입니다 (그리고 20 년 동안 저의 경력에도 많은 도움이됩니다).

어떤 직업에서든 귀하가받는 경험은 귀하가하는 일에 따라 다르므로 해당 경험에 근거하여 다른 직업을 신청할 때 귀하의 가능성 범위가 제한됩니다. 유지 관리에만 국한되지 않습니다. 유지 보수 또는 새로운 소프트웨어 개발 여부보다 다른 질문이 더 관련이 있다고 생각합니다.

• 작업중인 특정 기술이 얼마나 널리 퍼져 있습니까? 더 이상 사용되지 않고 다른 곳에서 거의 사용하지 않는 것을 유지 관리하는 경우 향후 경력 기회가 제한 될 수 있습니다 (그러나 널리 사용되지 않는 시스템 / 플랫폼 / 기술 용 새 소프트웨어 개발).
• 현재하고있는 일이 미래에하고 싶은 일에 어떻게 도움이됩니까? 지적한대로 유지 관리 작업은 중요하며 항상 주변에있을 것입니다. 이런 유형의 프로그래밍에 중점을 둔 경력에는 아무런 문제가 없습니다. 시스템 관리자에게는 항상 많은 가능성이 있습니다. 그러나 아마도 당신이 하고 싶은 것이 아닐 수도 있습니다 . 현재 작업에서 관심있는 내용을 준비하지 않는 경우 문제가됩니다.

그러나 나는 너무 걱정하지 않을 것입니다. 당신이 말하는 한 가지는 :

나는 내가 만졌지만 깊이는별로없는 영역에서 많은 폭을 얻었습니다.

이것이 문제로 사용될 수 있기 때문에 이것을 문제로 생각하지 마십시오. 폭 넓은 경험이 있다는 것은 "그렇다, 나는 그렇게했다"라고 말할 수있는 다양한 것들이 있다는 것을 의미한다. 많은 직업이 여러 가지 다른 기술과 작업에 대한 경험을 요구합니다. 하나의 기술에 대한 경험이 많은 개발자보다 유리할 것입니다.

또한 많은 작업에는 유지 관리와 새로운 개발이 혼합되어 있습니다. 더 많은 새로운 개발을 원한다면 기존 유지 관리 경험을 사용하여 더 많은 개발 경험을 제공하는 혼합 역할로 전환 할 수 있습니다.

결론적으로, 이력서가 생각보다 낫습니다. 경험의 강점을 얼마나 잘 분석하고 응용 프로그램 및 인터뷰 과정에서 그 강점을 전달하는지에 대해 많은 정보를 얻을 수 있습니다.

전담 유지 보수 프로그래밍 역할이 초기 경력에 해로운 결과를 초래합니까?

다음과 같은 가정하에-예 :

• 이 경력 은 다양한 기술력에 대한 전문 지식을 의미합니다.
• X는 당신의 사고 방식을 "설정"하기에 X 년 이상을 보낸다는 것입니다.
• 당신은 옆으로 아무것도하지 않습니다.
• "전용 메인테이너"(아래 편집 참조)를 사용하면 유지하기 위해 코드를하지 않는 의미 뿐만 아니라 새로운 기능을 최소 필요 - 코드 새로운 것을,하지만 당신은 거의 항상 코드가 유지되거나 심지어 유지 관리 모드에서 프로젝트를 수행하는 것을 버그 수정을위한 코드 변경.

그렇다고 항상 그런 것은 아닙니다 .

소프트웨어를 유지 관리하는 사람들 은 연구를 거의 권장하지 않으며 (아래의 EDIT 참조), 새로운 라이브러리 나 DB를 연결하고 작동 방식을 찾는 데 며칠을 보낼 수 없습니다. 기존 코드베이스를 최소한으로 변경하여 나중에 문제에 접근하는 방식을 "형성"하는 것은 꾸준한 작업입니다. 나는 이것이 가져올 수있는 나쁜 일에도 불구하고 "코드 변경이 적을수록 좋을 것"이라고 명시 적으로 명시한 소프트웨어를 유지 하는 정책 을 가지고있는 몇몇 회사를 언급 할 수 있습니다.

다른 프로그래머들이 이와 같은 역할을 피할 권리가 있습니까?

나는 자신의 직업을 좋아하고 자신이 있는 곳에서 편안하기 때문에 다른 것을 정확하게 신청 하고 싶지 않은 아주 좋은 유지 관리자를 알고 있습니다. 모든 사람이 때때로 새로운 것을 배우는 것을 좋아하지는 않습니다. 따라서 선호도에 따라 피하거나 찾으십시오.

이 작업 라인을 수행하면 주니어로 다시 시작할 준비가되지 않은 경우 유사한 작업을 수행 할 수 있습니까?

더 자주-예. 당신은 이미 그 경험을 가지고 있기 때문에, 당신은 이미 "로프를 알고 있습니다"등. 그러나 교대는 확실히 가능 하며 주니어 포지션을 신청하지 않고도 일어날 수 있습니다. 당신은 이미 일을 제쳐두고 시작했습니다. 그것은 실제로 매우 가치가 있으며 당신이 발견 한 '기술 격차'를 줄일 수 있습니다.

편집 : Dan은 유지 보수 작업을 종종 연구를 통해 수행 할 수 있다고 지적했습니다. 사실입니다. 이 문제를 더 잘 해결하기 위해 위의 답변을 두 곳에서 변경했습니다.

이러한 작업은 반드시 이런 식으로 수행해야하며 훌륭하다면 가능합니다! 그러나 기존 시스템의 AFAIK 가장 헌신적 인 테이너는 정책이나 관리의 기대를 가지고 있다는 마감일 - 다시, 더 자주 못하는 것보다 - 적어도 가능한 변화와 함께 문제를 해결하기로 강요. 종종 이런 식으로 할 수 있어도 원하지 않는 압력이 충분히 높습니다. 특히 코드가 아닌 경우 (Ryle 및 Naur에 따라) 이론이 없으면 수정보다 더 많은 피해를 입을 위험이 있습니다.

그럼에도 불구하고 주목해야 할 점은 글로벌 데이터가없고 내 경험을 바탕으로 이야기하는 것입니다. OP로 근무한 상황에서 4-10 년 동안 경험이있는 직원을 관리자로 채용했으며 많은 관리자와 이야기를 나 talk습니다. 전담 관리자 로서 일하는 사람들을 알고 있습니다. 새로운 작업을 코딩하는 사람뿐만 아니라 프로젝트를 유지 관리하는 코드도 있습니다. 전담 관리자는 버그와 패치 만 수행하고 새로운 기능은 하나도하지 않습니다. 이전 프로젝트이기 때문에 이제는 "유지 관리 모드"뿐입니다.

기능 개발의 특정 경로에 중점을 둔 경험이 3 년인 사람에게 필요한 수준의 지식을 갖지 않기 때문에 나는 기술 수준이 매우 중학교라고 스스로 표현해야 할 것입니다.

옳은. 당신은 "삼년 X, Y 및 Z를 사용하여 처음부터 시스템을 설계 경험"당신이 말을 거라고 말할 수 없을 것 "삼년 경험을 만들고 유지 X, Y를 사용하여 처음부터 시스템을, 그리고 Z"당신이 원하지 않는다면 당신의 이력서에 바로 거짓말.

유지 보수 작업을 피하기 위해 다른 회사와 인터뷰를해야한다고 생각합니다. 3 년 동안 경험이있는 사람에게 필요한 지식 수준이 특정 분야에 집중되어 있지 않기 때문에 본인은 기술 수준이 매우 중학교 인 것으로 나타납니다. 기능 개발의 경로는

"처음부터 시스템을 설계하고 구축합니다"라고 말하고 싶을 때는 주니어로 분류해야합니다.

IT에서 매우 일반적인 것은 (그리고 이것이 당신이하는 일이라고 말하고 있지는 않습니다) 사람들은 X 년 동안 일해 왔기 때문에 X 년의 경험을 가지고 있으며 {불확정 한 수 년} 후에 그들은 선임 {Widget} 개발자로 간주되어야합니다.

자, 내가 잘못하지 마라. 유지 보수 작업에는 아무런 문제가 없다. 모두가 언젠가는 그것을해야한다. 그러나 당신이 깨달은 것은 너무 오래 붙어서 고생하는 것이 어려울 수 있다는 것이다. 앞으로 그 역할에서 벗어나십시오. 이것은 종종 새로운 기술 / 도구 / 방법을 배우지 않고 "고착"되는 것과 밀접한 관련이 있습니다.

이상적으로는 "새로운"시스템 작업과 레거시 작업이 혼합되어 있어야합니다.

긍정적 인면에서, 당신은 아마도 많은 다른 아키텍처들 (좋은 것과 나쁜 것), 다른 접근법들, 나쁜 결정들이 어떻게 레거시 프로그래머들이 나중에 더 열심히 일하게 만드는지를 볼 수있을 것입니다. 이것들은 강조 될 수있는 것보다 모두 긍정적입니다.

행운을 빕니다!

이것을 다른 각도에서 보면, 유지 보수 전문가로 자신을 파는 것이 시장성있는 기회라고 생각합니다.

여러 프로젝트가 진행중인 소프트웨어 회사의 소유자로서, 최소화해야 할 가장 큰 위험 중 하나는 배를 뛰어 넘는 개발자와 그에 따른 코드 유지 관리입니다.

따라서 유지 보수 전문가로서 서비스를 제공하게되면 유지 보수 작업에 대한 열정을 키울 수 있다고 가정하면 (당신이 경험에 대해 블로그를 준비한 이후로 추측 될 것입니다.) 장기 유지 관리를 위해 코드를 리팩토링, 최적화 및 문서화하여 개발자의 다양한 프로젝트 중 하나입니다. 보증을 뒷받침하는 기록이 있습니다.

내 조언은 이것을 제대로 시도하는 것입니다. 자신을 유지 보수 전문가로 지정하고 블로그를 양성하십시오. 당신은 뭔가에있을 수 있습니다.