프로그래밍 속도가 너무 느립니까? [닫은]


31

나는 업계에서 1 년을 보냈으며 특정 작업에 대한 견적을 작성하는 데 문제가있었습니다. 이 글을 닫기 전에 예, 나는 이미 읽었습니다. 견적을 요청할 때 어떻게 응답합니까? 그리고 그것은 내가 겪고있는 것과 같은 문제에 관한 것입니다. 그러나 나는 더 구체적인 경험의 척도, 수량화 또는 아마도 다른 프로그래머의 평균 성능을 찾고 있는데, 이는 내 목표를 세우고 추정해야합니다. 답은 몇 주에서 시작되었으며 하루 정도 할당 된 작업 수준에 대한 답을 더 찾고있었습니다. (QA 또는 문서 제출에는 TDD를 사용한 경우 테스트 작성에서 테스트에 제출하기 전에 페이지 작성에 이르는 실제 개발 시간 만 포함됨)

현재 현재 요금은 다음과 같습니다 (ASP.NET 웹 양식에서).

  • 지금은 하루 종일 (8 시간) 시간이 주어지면 이미 구축 된 아키텍처에 대한 그리드 목록 (복잡한 논리가없고 작성 및 읽기)이있는 간단한 데이터 입력 페이지를 개발할 수 있습니다.
  • 복잡한 기능과 업데이트 및 삭제 페이지를 추가하면 하루 종일 작업에 추가됩니다.
  • 페이지를 처음부터 시작해야하는 경우 (솔루션 없음, 기존 웹 사이트 없음) 하루 종일 다시 걸립니다.
  • (항상 그런 것은 아니지만) 새로운 것을 만났거나 아직하지 않은 경우 하루 종일 하루가 더 걸립니다.

내가 예상했던 것보다 더 긴 견적을 할 때마다 나는 다른 사람들이 내가 다른 사람들보다 많이 뒤떨어져 있다고 생각한다고 생각합니다. 한 페이지 일 때 하루 종일 걸리지 않을 것이라는 기대가 있었기 때문에 걱정입니다. 예, 확실히 개선의 여지가 더 많습니다. 항상 있습니다. 배울 것이 많다. 그러나 현재 업계에서 1 년을 넘지 않는 사람의 현재 속도가 너무 느리거나 평균 또는 평균인지 알고 싶습니다.


특정 사용 사례로 범위를 좁히기 위해 질문을 다시하는 것은 권장되지 않으며 더 나은 피드백을받지 못할 것입니다.

죄송합니다. 더 구체적인 답변을 찾으려고 노력했습니다. 다음에 염두에 두겠습니다.
Jonn

17
왜 권장되지 않습니까? 그가 찾고있는 답변이 초기 질문에 존재하지 않는다면 다른 질문을 특정 사례로 좁히는 것이 좋습니다.
Rachel

7
속도는 코더의 능력을 판단하는 유일한 척도가 아니라 품질도 필수적이라는 것을 기억하십시오. 속도 외에도 재 작업량도 고려하십시오.
Michael

@ 존-거의 4 년이되었습니다. 이 질문을 한 후 속도 / 능력이 향상되었다고 생각하십니까?
Chucky

답변:


20

당신이 직업을 위해 프로그래밍하고 있고, 당신의 상사가 당신이 물건을내는 속도에 만족한다면, 나는 당신이 잘하고 있다고 말할 것입니다. 1 년이 지났을 때, 그들은 당신의 결과에 분명히 분노하지 않습니다. 또한, 당신은 1 년 동안 있었으며, 하루 이상 사람들을 관리하고 있다고 가정하면, 여전히 녹색 일 때 학습 곡선이 있다는 것을 알고 있습니다.

추정치에 관해서는 ... 나는 5 년 동안 업계에 종사해 왔으며 (확실히 베테랑 영토는 아닙니다!) 개인 평가는 여전히 엉망입니다. 나는 과소 평가할 때마다 과대 평가하고, 제대로하는 것보다 훨씬 더 많이한다. 뭔가가 어딘가에 나타나서 물릴 것입니다. 때로는 자신이해야한다고 생각한 모든 것을하는 라이브러리를 찾을 수 있으며 반나절에 일주일의 작업이 사라집니다. 다른 경우에 바보 같은 버그는 하루 작업량을 2, 3, 4로 늘릴 것입니다.

동일한 작업을 반복해서 반복하고 처리량을 최대화 한 것처럼 느껴지면 다른 작업으로 이동하도록 요청해야 할 수도 있습니다. '교차 수분 (cross-pollination)'및 기타 PHB 친화적 용어는 개발자에게 확실히 도움이됩니다. 한 달 이상을 다른 것에 투자하면 더 적합한 것을 찾을 수 있습니다. 그렇지 않은 경우 또는 웹 양식에서 멀리 떨어져 있지 않으면 변경 사항이 아무런 해를 끼치 지 않으며 도움이 될 약간의 지식과 경험으로 돌아올 수 있습니다.


저의 관리자는 이해하지 못했지만 저에게서 더 많은 것을 기대하고 더 빠른 결과를 기대하고 있으며, 이것이 저를 부적절하게 느끼게하는 것입니다.
Jonn

3
관리자에게 항상 자신의 생각을 물어볼 수 있습니다. 그런 식으로 당신은 알게 될 것입니다. 개선 할 수있는 방법에 대한 좋은 제안이있을 수 있습니다. 또는 그들은 당신이 훌륭하게하고 있다고 말할 수도 있고 걱정할 것이 없습니다. 장점 : 잘못하고 있더라도 자기 인식과 사전 대응을 보여줍니다. 단점 : 지연되는 것을 깨닫게 할 수 있습니다. 다른 방법으로, 당신은 잘하고 있고, 두려움을 잃을 수 있다는 말과 두려움을 가져 오는 자신을 증명하려는 소망을
품고 있습니다

10

녹색 프로그래머로 1 년을 관리했다면 운이 좋을 것입니다. 생산성이 충분하지 않아서 9 개월 (실제 프로그래밍은 3 개월) 후에 다른 부서로 이사했습니다. 그리고 저는 점점 더 많은 것을 배우면서 프로세스를 즐기고 꾸준한 속도로 물건을 전달했습니다. 내가 기업 프로그래밍에서 일한 것은 처음이었습니다.

아마도 작업을 수행 할 때 풍선 껌과 거의 함께 유지되지 않는 제로 테스트를 통해 가장 오염되지 않고 가장 신뢰할 수있는 코드를 작성하는 것이 더 좋을 것이므로 관리자는 벤치 마크를 위해 충분한 "확률 성"을 얻게됩니다.


7

5 년에서 10 년 동안 프로그래밍 한 사람에 비해 약간 느리게 진행될 수 있지만 시간이 많이 걸립니다. 당신은 아마 처음 배웠을 때와 같은 시간의 1/10에 일을하고있을 것이며, 계속 쉬워 질 것입니다. 그것은 인생에서 대부분의 것들입니다. 처음 배울 때 속도가 느리고 점차 더 좋고 빠르며 효율적입니다. 충분히 오래 연습하면 "지식"이 될 수 있습니다.


2

세부적인 작업을 수행하거나 매우 정확한 견적을 얻을 때마다 다소 독창적 인 일을하는 경우 항상 어려울 것입니다.

나는 개인적으로 도전을 좋아하지만 때로는 작업 목록이나 타임 라인을보고있는 경우 약간 바보처럼 보일 수 있습니다.

때로는 테스트를 수행하는 경우 수행 한 작업의 복잡성에 따라 제공 한 예제가 상당히 빠르다고 말할 수 있습니다. 나는 당신의 글 머리 기호 안의 항목이 적어도 하루에 할당 된 경우에도 각 항목, 일부 항목이있는 프로젝트를 수행했습니다.


1

내가 예상했던 것보다 더 긴 견적을 할 때마다 나는 다른 사람들이 내가 다른 사람들보다 많이 뒤떨어져 있다고 생각한다고 생각합니다.

문제를 자세히 살펴볼 때 아무도 더 이상 더 오래 추정하지 않으면 모든 추정치가 너무 짧은 경향이 있습니다.

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