“이론가”프로그래머가되지 마십시오

이 기사는 SO에 대한 여러 게시물에서 발견되었습니다 . 나는 6 번째 원형에 빠진다. "이론가".

"이론가"를 다음과 같이 정의합니다.

이론가는 프로그래밍에 대해 알아야 할 모든 것을 알고 있습니다. 모호한 프로그래밍 언어의 역사에 대해 강의하거나 4 시간 동안 작성한 코드가 완벽하게 최적이 아니며 실행하는 데 3 나노초가 더 걸릴 수 있다는 증거를 제공하는 데 4 시간을 소비 할 수 있습니다. 문제는 Theoretician이 소프트웨어 개발에 대해 아는 것이 없다는 것입니다. 이론가가 코드를 작성할 때, 그것은 "우아한"것이므로, 필사자 만이 이해할 수 없습니다. 그의 가장 좋아하는 기술은 재귀이며, 모든 코드 블록은 적시성과 가독성을 희생하면서 최대로 조정됩니다.

이론가도 쉽게 산만합니다. 한 시간이 걸리는 간단한 작업은 이론가들이 기존 도구로는 충분하지 않다고 결정하고 높은 표준을 충족하는 완전히 새로운 시스템을 구축하기 위해 새로운 라이브러리를 구축 할 새로운 도구를 구축해야하기 때문에 3 개월이 걸립니다. Theoretician은 프로젝트 자체의 경계 내에서 게임을하고 The Ultimate Sorting Algorithm에서 시간을 보내지 않으면 최고의 선수 중 한 명이 될 수 있습니다.

간단한 프로젝트가 무엇인지에 대해 작업 할 때도 처음부터 모든 것을 오버 엔지니어링하려고 애쓰는 경향이 있습니다. (이것은 아마도 운영 체제를 처음부터 새로 만들기 위해 약 2 년을 낭비한 이유를 설명합니다.) 결국 무의미했습니다).

이것을 피하는 데 무엇이 도움이 될 수 있습니까? 그리고 KISS 원칙에 충실합니까?

감사

본질적으로 이론가이기 때문에 민첩한 상점에서 일하면 그러한 모든 경향을 빠르고 결정적으로 치료할 수 있다고 말할 수 있습니다. 특히, 페어 프로그래밍 (이상적으로 자주 회전), 테스트 중심 개발, 타임 복싱 및 바운드 스프린트가 포함 된 eXtreme Programming 작업은 모든 동료가 볼 수있는 작업을 즉시 처리 할 수있게해주어야합니다. 분 단위로. 이것은 이론가 스타일의 작업이 번성하는 고립 된 사무실 환경에서 별도의 작업과는 큰 변화입니다. 모든 사람이 지속적으로 다른 사람에게 적극적으로 의존하기 때문에 완전한 정직과 완전 무결성이 필요합니다.

나는 여전히 내 배꼽을 소중히 여긴다. 그러나 나는 집에서 또는 메인 라인 개발의 일부가 아닌 현장 프로젝트에서 일할 수있는 드문 경우에 탐닉해야한다.

1. 개발하려는 목표를 세우십시오.

2. 가까운 미래에 달성 할 수있는 목표로 그 목표를 좁히십시오.

3. 그런 다음 다른 모든 고려 사항을 제거하고 해당 목표에 집중하십시오. 배경이 없습니다. 역사가 없습니다. 확장명이 없습니다. 일반적이거나 추상적 인 것은 없습니다.

4. 그런 다음 전달할 수있는 최소한으로 좁 힙니다. 안좋다. 융통성이 없습니다. 유지할 수 없습니다. 그렇습니다.

5. 그런 다음 가능한 최소한으로 달성하기 위해 필요한 절대 최소값으로 우선 순위를 정하십시오. 요점은 약 일주일 안에 날짜를 고르고 그 날짜를 향해 나아가는 것입니다. 일주일 안에 무언가를 전달할 수 없다면. 제한된. 초점. 손질. 줄이다.

6. 그런 다음 보풀을 제거하십시오. 일주일 밖에 없습니다. 계속 자르십시오.

7. 그런 다음 가능한 한 빨리 수행되는 축소 된 구현에만 집중하십시오. 이상적으로는 일주일도 채 걸리지 않으므로 문서를 작성할 시간이 있습니다.

저는 이론가들과 함께 일했습니다. 나는 실제로 "실패"라고 표시 될 수있는 것을하지 않기위한 변명을 "익스트라"라고 생각합니다.

하고 실패하는 것은 어렵다. 무언가를하는 것보다 이야기하는 것이 무언가하는 것보다 쉽습니다. 많은 연구와 사고는 잘못된 일을 피한 다음 사용자가 거짓말을했다는 것을 알게 된 후 재 작업하는 방법입니다.

그냥 앞에 코드를 넣으십시오. 그들은 코드를 실패라고 부릅니다. 일어난다. 그러나 실패하는 과정에서 실제 요구 사항이 무엇인지 배울 것입니다. 그리고 그들이 거짓말했다는 것을 알게 될 것입니다.

이것이 그렇게 나쁜 일인지 잘 모르겠습니다. 분명히 당신은 생산적이어야하거나 일을하지 않을 것이지만, 현장에 관심이 있고, 예술의 학생이기 때문에 말하기는 나쁘지 않습니다.

나는 당신의 강점을 가지고 당신의 스타일과 선호가 유리한 기회를 찾습니다.

Erlang에서 MVC 프레임 워크를 작성하는 데 빠지거나 (흥미가있는 것) 생산성을 유지하려면 하루에 한 시간 정도 더 복잡한 작업을 수행해야합니다. 하루의 나머지 시간 동안은 단지 거친 작업에 집중하고 작업을 완료하십시오. 당신이 관심을 끄는 메모를하거나 메모를하지만 계속 진행할 수있는 흥미로운 것을 발견하면 할당 된 타임 슬롯으로 다시 돌아 오십시오.

개인적으로 나는 그들이 흥미로워 보이는 많은 URL과 도서관 서적 더미를 가지고 있습니다. 나는 아마도 그 URL의 약 10 %를 결국 얻을 수 있고 결국 책의 50 %를 읽을 수도 있지만 여전히 하루 일을 끝내고 있습니다.

나는이 문제를 직접 경험했다. 두 가지 기술이 도움이되었습니다.

1. 포모 도로 (Pomodoro) 기술이나 일련의 매우 짧은 목표를 설정하는 다른 시간 관리 기술을 사용하십시오. 향후 25 분 동안 달성 할 수있는 것을 파악해야 유용한 작업에 계속 집중할 수 있습니다.
2. 테스트 중심 개발. 코드를 작성하기 전에 구체적인 테스트를 작성해야한다면 공상을 최소화 할 수 있습니다. ( "우아한"에 대한 테스트를 작성할 수있는 방법은 없습니다.) 무언가를 얻은 후에는 리팩토링하는 것보다 더 많은 시간을 할애 할 수 있지만 최소한 상상의 이상이 아닌 실제 코드를 다루는 것입니다.

너무 자신을 두들겨하지 마십시오. 신경 쓰지 않는 사람들이 시야를 넓히는 것보다 이론가에게 집중하고 유용한 작업을하는 것이 더 쉽습니다.

stackoverflow.com을 피하십시오 . 내가 틀리지 마라-나는 큰 팬이다. 그러나 SO와 다른 프로그래밍 중심 포럼 은 선의 적을 완벽하게 만든다. . 잠시 후, 수천 명의 똑똑한 사람들이 당신의 어깨 너머로보고 있다고 느끼기 시작하고 당신이 쓰는 것만으로는 충분하지 않습니다. 작동하는 것을 이해하고 이해할 수 있도록하십시오. 개선이 필요한 경우 언제든지 다시 방문 할 수 있습니다.

또한 연결 한 것과 같은 기사를 사용하지 마십시오. 정말로 10 가지 유형의 프로그래머가 있다고 믿습니까? 아니면 당신이 아는 사람은 설명 된 범주 중 하나에 완전히 부합합니까? 이와 같은 기사에는 약간의 진실이 포함되어 있기 때문에 특정 호소력이 있습니다. 일부 고정 관념에서 자신 및 / 또는 일부 동료를 볼 수 있습니다. 그러나 범주는 점성 학적 표시만큼 많은 물을 보유합니다. 다음에 회의 후 믹서에있을 때 다음과 같이 시도하십시오. "안녕하세요, 저는 코드 카우보이입니다! 귀하의 유형은 무엇입니까?"

그것은 당신의 질문이 유효하지 않다는 것을 말하는 것이 아닙니다. 만약 당신이 생각을 지나치게 생각한다면, 그러한 경향을 피하는 방법을 배우는 것이 좋습니다. 그러나이 처벌이 당신을 비둘기 홀링으로 이야기하게하지 마십시오.

완전히 포장을 풀었을 때이 시나리오를 피하는 방법을 전체적으로 설명하는 간단한 지침이 있습니다.

가능한 가장 간단한 일을하십시오.

-켄트 벡

클라우드에서 벗어나기위한 한 가지 방법은 이론적 API 또는 프레임 워크를 작성하는 것 외에도 실제 애플리케이션을 처음부터 끝까지 작성하도록하는 것입니다. 시간 상자를 무언가 주위에 놓고 그 시간 안에 "완료"하려고합니다. 프레임 워크를 작성하려면 디자인 패턴과 아키텍처를 잘 이해해야하지만, 정해진 시간 안에 완전한 응용 프로그램을 작성하려면 수퍼 웰 디자인 프레임 워크를 작성하는 것과 다른 기술이 필요하다는 것을 알았습니다.

신청서를 작성하려면 어느 시점에서 지구로 내려 와서 끝내야합니다. 구속 조건이있어 디자인을 희생하거나 마음에 들지 않는 방식으로 기능을 구현해야 할 수도 있습니다. 나는 당신과 같습니다-백만 번 물건을 쓰고 다시 쓰는 경향이 있지만 일정 시간 내에 해야하는 작업에 직면하면 내 전투를 선택하고 가장 중요한 것들.

단순 :

1. 실용적이 되십시오 .

Theorician의 반대편 (프로그래밍 영역의 정보 / 지식 측면에서 이점이있는)은 Pragmatic입니다.

이 답변에 설명 된대로 KISS, DRY, SOC 및 기타 사고 방식을 적용 한다는 것은 실제적인 행동을 의미합니다.

이 책을 읽으면 실용적으로 배울 수 있습니다.

http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=sr_1_1?ie=UTF8&qid=1302893763&sr=8-1

이론과 실천이 혼자가 아니라 함께 작동한다는 것을 잊지 마십시오. 많은 연습이 없다면 지식은 아무것도 아닙니다. 많은 지식이 없으면 연습을 빨리 향상시킬 수 없습니다.

연습을 많이하십시오. 그리고 많은 것을 배우십시오. 그러나 한 사람이 다른 사람을 극복하지 못하게하십시오.

프로젝트에서 마감일을 설정하십시오. 그것에 충실하십시오. 그런 다음 마감일 전에 프로젝트를 완료하는 방법에 대해 실용적으로 생각하십시오. (실제로 책을 읽으십시오) 그런 다음 코딩을 시작하고 알아야 할 내용을 읽기 시작하십시오. 읽기에서 코딩 및 제한 또는 읽기 시간으로 전환하십시오.

흠 ... 아마도 타임 라인 아래에서 응용 프로그램을 작성해야하는 회사에서 일자리를 구하려고 할 수도 있습니다. 나는 아마도 적어도 직장에서 당신이 할 수있는 한 이론가가되는 것에서 멀어 졌다고 스스로 말할 것이다. 그러한 유형의 일을하는 것은 그 자리와 시간이 있으며 자신을 발전시키는 데 중요합니다. 그러나, 나는 그런 종류의 능력을 인정하지만 비즈니스 세계, 특히 내가 일하는 곳에서는 그런 곳이 없습니다. 때로는 몇 주 안에 응용 프로그램을 작성하고 클라이언트가 어제 원하는 응용 프로그램이 빠르게 진행되는 개발 환경! 저는 놀라운 개발자들에게 축복을 받았으며 모든 사람들이 팀으로 일하도록하는 데 시간이 걸렸습니다.

나는 가능한 한 똑똑한 사람이 있었지만, 당신처럼 항상 잘 작동 할 때조차도 코드를 마지막으로 조금씩 짜야했습니다. 환경에서 제공하는 것과 동일합니다. 우리가 제 시간에 물건을 꺼내야 할 때 그것은 모두 매우 시원했지만 시간 낭비였습니다. 종종 이러한 측면 프로젝트가 팀을 백업하고 결국 다른 사람들의 압력을 느끼기 시작했고 그는 형성했습니다. 제품을 밀어 내야하는 다른 훌륭한 개발자들과 팀 환경에서 작업을 시작하는 것이 좋습니다. 나중에 물건을 리팩토링하고 다시 실행하거나 가장 킥-머스 MergeSort를 작성할 시간이 항상 있습니다. 그러나 때로는 제품이 작동하는 지점으로 제품을 가져 와서 고객에게 전달해야하는 경우가 있습니다.

평범한 단어의 의미에서 '이론가'가되는 것은 아무 문제가 없습니다. 좋은 지식과 독창적 인 아이디어의 금광이므로 배경 지식과 최신 CS 연구를 이해할 수있는 능력이 있습니다.

이 글의 후반부에서 '진짜 질문'이 더 분명해집니다. 구체적인 프로젝트 목표를 알고 다른 목적이 아닌 그 목표를 향해 노력하십시오. 이 경우에는 자기 훈련의 문제 일뿐입니다. 이에 대한 자세한 내용은 S. Lott의 답변을 참조하십시오 :).

프로그래밍에서 달성하고 일을 성취하는 것부터 작동하는 소프트웨어를 제공하는 데까지 집중하십시오. 그것은 당신의 우선 순위를 정합니다.

이것을 달성하는 방법은 또 다른 이야기입니다. 가장 좋은 방법은 일부 프로젝트를 고안하고 모든 단계를 거쳐 프로덕션으로 시작하는 것입니다. 그 후에는 이전과 다른 사고 방식을 갖게됩니다.

이 게시물에 대한 감사합니다. 그것은 내 일을 더 가치있게 만듭니다. 소프트웨어 개발자로 일하는 정보 아키텍처 교육도 마찬가지입니다. 종종 나는 "무엇을 바꿀까"보다는 "무엇을 바꿀 것인가"로 어려움을 겪고 있습니다. 관계가 너무 많고 똑똑하고 일반적인 것들이 너무 많아서 작동 방식을 찾는 데 너무 오래 걸립니다.

그래서 나는 질문을하기 시작했고, 이것이 어떻게 그리고 어디서 만들어 졌는지 알게 될 때까지 더 많은 질문을합니다. 그리고 말해 줄 게요-효과가 있습니다. 화재에 대한 의문이 많을수록 원래 아키텍처를 유지하는 것이 중요하며 마지막으로 기본으로 돌아가는 것이 중요합니다.

if (weWantToMakeChangesToCodeLaterOnAndProbablyBySomeOtherProgrammer)
{
    Console.Writeline("We need to keep the code readable and simple enough ");
    Console.Wrietline("to make it easy for him/her to understand it!");
}

상사에게 멘토를 요청하고 멘토가 말한대로하십시오.

어려운 부분은 계속 초점을 맞추고 있으며 "운영 체제를 다시 작성하자"는 사용자가 맡은 작업을 마치는 데 실질적으로 도움이되지 않는다는 것을 인식하고 있습니다 (이는 프로젝트 관리자가하지 않는 이유입니다).

또한 멘토가 코딩 하기 전에 모든 디자인을 검토 하고 코딩 후 실제 코드를 검토하도록하십시오 . 이를 통해 수행해야 할 작업에 계속 집중할 수 있습니다.

나는 오버 엔지니어링을하는 것과 같은 유혹을 가지고 있으며, 그것을 극복하기 위해서는 자기 훈련과 조직이 필요합니다. 다른 사람을 코딩 할 때는 다음과 같이하십시오.

1. 개별 작업을 시작할 때 몇 분 동안 기능, 품질, 배달 날짜 등 실제로 필요한 것이 무엇인지 생각하십시오 .
2. 코드의 고객 목표를 염두에두고 하위 작업, 하위 작업 등으로 나누는 방법 을 계획하는 데 시간을 더 투자 하십시오.
3. 각 항목의 시간을 추정하여 미지수에 대해 최대 50 %를 더하십시오. 항목이 4 시간 이상 걸리면 좀 더 세분화하십시오. (대학 프로젝트를 수행하는 경우 스프레드 시트를 사용하지만 여러 고객의 컨설턴트로 Redmine이라는 문제 추적 시스템을 사용합니다.)
4. 가장 중요한 것은 내가 생각해 낸 항목 만 수행하십시오 .

물론 일이 일어납니다. 때로는 더 많은 일을해야한다고 생각합니다. 그래서 # 1부터 시작합니다. 때로는 작업이 생각보다 훨씬 오래 걸릴 것입니다. # 1부터 다시 시작하십시오. 때로는 디자인에 대한 자세한 내용이 나중에 필요하다는 것을 미리 알고 있으므로 # 1에서 다시 시작하는 재 추정 하위 작업을 계획합니다.

내가 이것을 더 많이할수록 나는 그것을 더 잘 얻는다. 자기 훈련은 운동을 통해 강화되는 정신 근육이며, 또한 시간이 오래 걸리고 기술적 인 균형을 유지하는 데 도움이됩니다. 패튼 장군의 인용을 기억하는 것이 도움이된다는 것을 알게되었습니다.

고독한 개발자 인 나의 워크 플로우는 이것을 Kanban 보드를 포함한 Agile의 측면과 결합합니다. 때로는 접선을 벗어나지 만 일주일에 몇 시간으로 편차를 제한하려고 시도하며 꽤 잘 작동합니다.

민간 산업에서 일할 계획이라면 "이론가"충동을 통제하는 것이 정말 중요합니다. 내가 아는 가장 뛰어난 프로그래머는 실리콘 밸리에 살고 있지만 완벽한 코드를 너무 늦게 제공하는 것으로 유명하기 때문에 수년간 일하지 않았습니다.