유일한 개발자이자 그 결과 [폐쇄]


16

저는 회사에서 유일하게 개발자입니다. ASP.NET 4.0, jQuery 및 SQL Server 2008에서 프로그래밍을 수행하고 데이터베이스 및 웹 서버 (win 2008 r2)를 유지 관리합니다.

나는 모든 것을 나쁜 방식으로 할 수 있다고 생각하면서 동시에 내가 좋아하는 것을 구현할 자유를 즐긴다. 나는 애자일 등과 같은 어떤 종류의 방법도 아닌 SDLC 다이어그램을 사용하지 않습니다. 여러 개의 작은 프로젝트를 처리합니다. 나는 자유 시간을 사용하여 최신 기술을 유지하고 새로운 것을 배우고 테스트합니다. 나는 지난 7 년간 이것을 해왔다.

  1. 더 많은 개발자가 프로젝트에 참여하는 회사로 업무를 전환 할 때 조정이 어려울까요?
  2. 나는 어떤 디자인 패턴을 따르지 않기 때문에 직업을 찾거나 새로운 직업에 적응할 때 나에게 맞지 않을까요?
  3. 당신이 생각할 수있는 다른 장단점이 있습니까?

답변:


8

이 상황이 자유롭고 마음에 든다면이 문제를 문제로 여기는 곳을 좋아하지 않을 것입니다 (이 울타리를 뛰어 넘어서 내가 알고 있음).

실제로 미래의 직업에 유리하게 작용합니다.

피에르 (Pier)가 말한 바와 같이 프로 / 콘 결정에 대해 논쟁 할 사람이 없다는 것은 문제이지만, 다른 회사의 동료는 당신이하려는 일에 귀를 기울이고 인내심을 가지고 있고 강한 의견은이 역할을 훌륭하게 수행하며 때로는 외부 관점이기 때문에 동료보다 낫습니다. (지금은 더 큰 가게에서 일하고 있는데도 여전히 비슷한 문제를 해결하고 디자인의 미래 문제를보기 위해 다른 사람들이하는 일을 계속하는 데 도움이됩니다)

내가 고독한 개발자 였을 때 내가 겪었던 또 하나의 문제는 경영진의 나쁜 방향에 맞서 싸울 시간이되었을 때 나를 백업 할 사람이 없다는 것이었다. 마일리지는 다를 수 있지만, 당신이 고독한 개발자이고 모든 경영진이 비 기술적이라면, 왜 그들에게 무언가를해야하거나하지 말아야 할지를 설명하기가 매우 어려워 질 수 있습니다. 최신 꿈은 현재 기술로 구현하려고 시도하는 것이 합리적이지 않습니다.


5
유일한 기술자가되는 다른 문제는 고열과 심한 구역질이 있고 웹 서버가 다운되는 경우입니다. 버스에 부딪히면 랩탑을 병원에 가져 오는 것 이외의 백업 계획이 있기를 바랍니다.
David Thornley

1
그것은 문제이지만, 자원이 너무 얇아지면 규모가 큰 회사에서도 종종 문제가됩니다.
Bill

35

혼자있을 때 아무도 당신이 틀렸다고 말할 수 없습니다

그래서 당신은 알지도 못하고 한동안 잘못된 길로 갈 수 있습니다.

이런 이유로 개발에 관해 이야기 할 수있는 사람을 찾아 보시기 바랍니다. 온라인뿐만 아니라 실제, 물리적으로도 가능합니다.

회사를 그만 둘 필요가 없습니다. 유일한 사람이라는 것도 장점이 있습니다.


3
이것은 환상적인 조언입니다 ...
webdad3

4
키워드는 "may"입니다. 개발자가 다양한 기술과 방법론, 더 중요하게는 주변 데이터에 대한 교육을 받기 위해 양심적으로 노력한다면 하위 수준의 작업을하고 있다고 믿을 이유가 없습니다. 물론, 개발자들은 진공 상태에서 작업하는 사람들 그들이 알고있는 것을 그냥 스틱은 아마 자신이 점차적으로 폐기하고 있습니다.
Aaronaught

피에르의 의견에 동의하면, 두 개발자는 [코드 또는 db 또는 그 어느 것보다 훨씬 더 나은 방법으로 생산할 수 있습니다]. 개발자 수가 많을수록 혜택이 증가하지만 수익이 감소합니다.
jamesbtate

5

필자는 특정 기술을 알고있는 회사에서 유일하게 프로그래밍 방식을 수행 한 사람과 비슷한 상황에서 계약자로 일했습니다. (또한 다른 도구를 알고있는 다른 개발자 및 내가 한 일을 정확하게 수행 한 다른 개발자와 팀 환경에서 일했습니다.)

유일한 프로그래머라는 장점

  • 언급했듯이 학습 할 수있는 도구 나 언어를 자유롭게 사용할 수 있습니다. 다른 사람이 Current Technology Y를 사용하는 동안 동료가 New Technology X에 대한 작업 권한을 얻기 위해 항상 사례를 만들 필요는 없습니다.
  • 더 많은 책임이 있습니다. 기본적으로 각 프로젝트에서 프로젝트 리더 및 개발자의 역할을 수행하며 새로운 것을 식별하고 구현할 수 있으면 효과적으로 부서 책임자이기도합니다. (판매원에게이 사실을 알리지 마십시오. 의사 결정자와 대화하기를 좋아하며 대화 할 시간이 없습니다.)
  • 수행 한 작업에 대한 신용에 대해서는 의문의 여지가 없습니다. 분명히 일을 한 사람은 당신과 당신 자신입니다.
  • 실제로 자신의 프로젝트에서 작업하는 데 더 많은 시간을 할애하고 기본적으로 다른 사람의 프로젝트에 대한 회의에서 더 적은 시간을 할애 할 수 있습니다 (그러나 지원 담당자, 가능한 백업 등).

단점

  • David가 의견에서 지적한 것처럼, 귀하는 유일한 개발자이므로 귀하 없이는 개발이 완료되지 않습니다. 나는 한 번은 형제에게 직장에서 특정 프로젝트에 대해 "남자"였다고 말했다. 그는 나의 상황을 정확하게 설명했다 : 나는 갇혔다. 나는 그 프로젝트를 제거 할 수 없었기 때문에 그 회사로 이사 할 수 없었습니다. (그도 옳았습니다. 어느 정도는 그것을 지원할 수있는 사람에게 건네주기까지 오랜 시간이 걸렸지 만 수개월의 훈련이 필요했습니다.) 당신없이 할 수 있습니다.
  • Pierre가 지적한 것처럼, 사이트에는 코드 검토를 수행하거나 모범 사례를 공유 할 사람이 없습니다. 동료에게 다양한 방법으로 연락 할 수 있지만, 동료를 어깨에 대고 5-10 분 동안 코드를 보도록 요청하는 것만 큼 효과적인 것은 없습니다.
  • 비슷한 맥락에서 새로운 도구를 경험하는 데 어려움이있을 수 있습니다. 오프 사이트 교육은 휴가 시간만큼 드물게 발생할 수 있습니다. 언어 2.0 앱을 계속 사용할 사람이없는 회사에서는 일주일 동안 언어 3.0을 보지 않아도된다는 불만이 있습니다.
  • 경력 발전은 관리하기가 매우 어려울 수 있습니다. 노력할 수있는 입장이 없을 수도 있고 직책을 변경하기가 어려울 수도 있으며 연말 검토에는 참조 프레임이 없으므로 다른 사람이 없으면 훌륭한 작품이 크게 눈에 띄지 않을 수 있습니다. 그 이유는 아무도 당신이하는 일을 실제로 이해하지 못합니다.

프로그래머 팀의 일원으로 일할 회사로 이사하기로 결정했다면 솔로 경험이 크게 해칠 것 같지는 않습니다. 디자인 패턴에 대한 경험이 부족하다고해서 반드시 배우려는 의도만큼 중요하지는 않습니다. (배경이 비슷한 후보에 대해 인터뷰하고 회사가 사용하는 모든 방법을 경험하는 상황이있을 수 있지만 기본적으로 모든 사람에게 해당됩니다.)

같은 라인을 따라 팀에 대한 경험 부족은 많은 모자를 착용하는 능력과 균형을 이룹니다. 훌륭한 팀 플레이어이지만 프로젝트를 관리하는 능력을 개발하지 않는 개발자가 있습니다. 당신은 이미 그렇게 할 수 있음을 보여주었습니다.

솔로 개발자 인 경우 비슷한 개발자가 사용하는 도구 및 기술에 대해 약간의 시간을 보내야하므로 직접 사용하지 않더라도 해당 도구가 존재한다는 것을 알고 있으며 인터뷰 중에 "예, MVC 프레임 워크에 대해 조금 읽었지만 직접 사용하지는 않았습니다." 다른 개발자들과 연락을 유지하기 위해 할 수있는 일을하십시오. 현지 사용자 그룹 회의에 가서 블로그를 읽고 댓글을 달거나 (또는 ​​자신의 블로그 중 하나를 유지), 때때로 워크숍에 참석하고, 웹 세미나를 시청하십시오. (사내 교육을 위해 lynda.com과 같은 사이트를 고려할 수도 있습니다. 다른 곳에서는 1 주일 동안의 회의만큼 좋지는 않지만 자신의 시간에 비디오를보고 공황 상태로 전환 할 수는 없습니다. 사무소 밖.)


2

이러한 상황에서는 매일 프로그래밍 기술이 저하됩니다. 코딩은 프로그래머의 직업 중 가장 쉬운 부분입니다.

솔루션을 구현하기 위해 팀과의 커뮤니케이션 / 작업은 매우 어렵습니다. 그 기술은 그것을 통해서만 갈 수 있습니다. 또한 팀의 일원 인 경우 대부분의 회원은 현재와 마찬가지로 기술을 따라 잡으려고 노력하므로 팀이 큰 것을 찾을 가능성은 훨씬 더 큽니다.

이것을 개인적으로 공격하는 것을 삼가십시오. 나는 또한 고독한 프로그래머이지만 최대한 빨리 팀을 찾고 있습니다.


혼자서 개발한다는 것은 종종 유용한 도구 인 'cardboard programmer'를 놓치는 것을 의미합니다. 기본적으로 다른 사람이 문제를 설명하도록하는 것은 종종 해결책이 설명 중반에 제시됨을 의미합니다 (다른 쪽이 제안을 할 수 있기 전에)
Phil Lello

0

@Pierre 303 답변 100 %에 동의합니다. 또한 자신에게 올바른 관행을 가르치기 위해 스스로 가져 가야한다고 덧붙입니다. 인증도 도움이 될 수 있습니다.

예, 작업을 전환하면 어려울 것입니다 ... 현재 익숙하지 않은 프로세스뿐만 아니라 성격도 가지고 있습니다. 프로그래머는 경쟁이 치열합니다. 지금 당장 그 문제를 다룰 필요는 없습니다. 그러나 프로그래머가 1보다 크면 1

좋은 공연이있는 것 같아요.

그냥 내 2 센트.


0

대규모 개발실에서 찾을 수있는 대부분의 표준 / 실습을 상황에 쉽게 적용 할 수 있다는 사실을 놓친 것 같습니다. 한 사람 팀에 대한 이러한 조정은 이전에 다루어졌습니다. 지침을 찾기 위해 조금만 검색하십시오.

개인 프로젝트에 민첩성을 적용하는 방법은 무엇입니까?


SDLC, Agile 등의 모든 방법론을 사용하여 complate 샘플 프로젝트를 찾을 수있는 링크가 있습니까?
bp581

'Agile'과 'Scrum'과 같은 단어에 너무 매달리지 마십시오. 성공적인 팀이 이미 사용하고있는 방법에 대한 공식적인 정의. 그러나 환경의 자연스런 곳에서 일할만큼 운이 좋지 않은 경우에 유용합니다.
Phil Lello
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.