더 자율적이고 자급 자족하는 프로그래머가 되려면 어떻게해야합니까? [닫은]

훌륭한 개발자가되지 못하게하는 가장 큰 요인은 다른 사람에 대한 의존입니다. 나는 모든 것을 깨뜨리고 모든 사람을 붙잡는 결과를 두려워하기 때문에 너무 많은 질문을하는 것처럼 느낀다. 그래서 충분한 질문을 한 후에 기본적으로 답변을 얻을 수 있도록 너무 많은 질문을함으로써 지나치게 신중합니다. 나는 그것이 나쁘다는 것을 알고 있지만 그것을 멈추고 싶다. 그중 일부는 내가 코드를 모르는 경우가 있습니다 (내가 결코 작업하지 않은 지점이거나 새로운 제품입니다).하지만 다른 것에 덜 의존하고 싶습니다. 서문으로, 이런 종류의 질문은 일반적인 패턴이나 언어에 관한 질문이 아닙니다. 일반적으로 제 질문은 회사에서 코드를 작성하는 방법과 생태계에서 작업을 수행하는 방법에 관한 것입니다. 나는 모든 단계에서 도움을 필요로하는 것처럼 느끼지 않고 사양을 가져 와서 롤을 할 수 있기를 원합니다. 이것이 정상입니까? 당신은 이것을 겪어 왔으며, 그렇다면 어떻게 극복 했습니까?

일부 새로운 개발자가 일을하고 즉시 부적절하다고 느낍니다. 나는 경력 초기에 똑같이했다. 나는 대부분의 똑똑한 사람들이 극복해야 할 적어도 두 가지 주요 문제가 있다고 생각합니다 : 시간 인식과 자신의 자연 능력.

시간 인식
똑똑한 사람들은 문제를 비교적 빨리 해결하는 데 사용됩니다. 미적분학 문제에 대해 한 시간을 보내야했을 때 놀라 웠던 기억이납니다. 문제에 60 분을 소비하는 것은 더 이상 아무것도 아닙니다. 그 시절은 끝났습니다 ... 그들을 묻고 작별 인사를하십시오. 오늘날 대부분의 소프트웨어의 복잡성과 크기는 터무니 없습니다. 사람들은 더 이상 일을 끝내기 위해 사용해야하는 모든 도구를 이해하지 못합니다. Douglas Crockford는 JavaScript 언어의 핵심 인물 중 하나라고 말했습니다.

"Misapplication of standard tools...is the new standard."

세상에는 모든 개발 도구를 배울 시간이 충분하지 않습니다.

자연 능력
지능, 문제 해결 능력 및 자연 기술을 통해 개발자 전체를 처음에 활용할 수 있습니다. 이 분야에는 더 적은 공간이 없습니다. 그래서 당신이 거의 모르는 100,000 줄의 코드, 언어 및 프레임 워크, 사람들이 당신에게 밀리는 디자인 패턴 및 패러다임, 손등을 가장 잘 알고있는 사람들, 어제 그것을 원하는 고객 및 보스 누가 당신의 세계를 기대합니까? 당신의 자연스런 능력이 실패 할 때 괴물이 되어라.

그래, 그건 정상이야 나는 아직도 내 길에 던져지는 것들 중 일부를 놀라게합니다.

무엇을 할 수 있습니까?

좋은 구식 노력으로 자연 능력을 향상시킬 때입니다. 문제를 더 작은 부분으로 나누기 위해 노력하십시오. 그리고 과거에했던 많은 일과는 달리, 이러한 문제는 해결하는 데 많은 시간이 걸린다는 점을 인식하십시오. 복잡한 문제를 조사한 지 15 분만에 포기하지 마십시오. 대신 문제를 해결하고 시계 시청을 중단하십시오. 잠시 후 문제를 다루는 30 분의 작업이 실제로는 그렇지 않습니다.

자기 확신은 자치 능력에 큰 역할을합니다. 팀, 특히 경험이 많은 노인들도 마찬가지입니다. 문제를 해결하지 않도록주의하는 것이 좋지만 계속해서 질문을해야하는 것은 아닙니다.

대신 소스 컨트롤을 사용하십시오. 변경 사항을 확인하지 않는 한 기본 제품을 손상시키고 다른 개발자를 화나게 할 수 없습니다. 또한 이해하고 테스트 할 수있는 변경 사항을 작성하고 체크인 전에이를 테스트해야합니다.

일회성 간단한 프로그램을 작성하는 데 사용하는 작은 테스트 프로젝트도 있으므로 기본 응용 프로그램의 모든 작업에 대해 걱정할 필요가 없습니다.

마지막으로, 모든 결정에는 일정 수준의주고 받기가 포함된다는 점을 기억하십시오. 어떤 수준에서 어떤 희생을하지 않으면 앞으로 나아갈 수 없습니다. 완벽을 위해 노력하지 말고, 굉장함을 위해 노력하고, 행동에주의하십시오. 항상 비판을 받고 자신의 아이디어와 그 이유를 설명 할 준비가되어 있어야합니다. 당신이 내리는 결정을 자랑스러워하십시오. 그들이 잘못되었을지라도 배워야 할 것이 많이 있습니다.

첫 번째는 질문하는 것을 두려워하지 않습니다. 수석 건축가조차도 코드에 대해 질문하는 것을 보았습니다. 그들은 모든 것을 알 것으로 기대되지는 않는다. 그들은 일을 끝내고 나머지를 알아낼 수있을만큼 충분히 알고 있어야합니다.

아마도 가장 좋은 전술은 다음과 같습니다.

• Google에서 조사하는 방법에 대해 알아보십시오. 약간의 조사 작업으로 거의 모든 것에 대한 답변을 찾을 수 있습니다. 스택 오버플로는 해결하기 어려운 문제를 해결해줍니다.
• 디버깅하는 방법을 배웁니다. 변덕스럽고 깊은 엔터프라이즈 코드로 들어가는 데 몇 시간을 보냈습니다. 변수 X는 7이 아닌 3입니다. 코드를 읽고 디버그 할 수있는 것은 아마도 자율권을 얻는 가장 좋은 방법 일 것입니다.

"큰 그림"질문을 두려워하지 마십시오

나는 내가 물어볼 수있는 가장 작은 질문을 찾으려고 노력했지만 여전히 다른 사람들이 답을 알고있는 것으로 보이는 광범위한 질문을하면 무능한 것으로 여겨 질까 두려워서 일을 계속할 수 있었다. 나는 무지와 무능의 차이점을 이해하지 못했습니다. 무지는 단지 아직 배우지 않았으며, 지속되지 않는 한 완벽하게 수용 가능하다는 것을 의미합니다. 무식하지 않은 척하는 것이 훨씬 더 나쁩니다.

사람들의 대답이 지금까지 당신을 데려 가고 있다는 것을 알게되면 다른 물고기를 건네지 말고 물고기에게 가르쳐달라고 요청해야합니다. 자신의 부분이 전체와 어떻게 일치하는지 물어보십시오. 질문이 "어쨌든 SQL이란 무엇"과 같이 기본적으로 보인다면 나중에보다는 빨리 질문하십시오. 지금은 어리석게 보일지 모르지만 나중에 더 어리석게 보일 것입니다.

대기 시간을 줘

질문이있는 즉시 질문하지 마십시오. 복잡성에 따라 30 분에서 하루까지 어디에서나 스스로 알아볼 수 있습니다. 많은 시간을 스스로 해결할 것입니다. 그렇지 않은 경우 동료에게 효과가없는 것을 알려 주면 더 나은 답변을 얻을 수 있습니다.

또한 동료가 머리 꼭대기에서 답을 모른다면 어떻게 도착하는지주의를 기울이십시오. 생각보다 많은 도움이 필요하지 않은 경우가 많습니다. 질문을 할 시간이 없다면, 모호한 방향으로 누군가를 가리켜 서 1 분이 지나면 연락을하겠다고 말하고 보통 그들이 도착할 때까지 해결했다고합니다.

초안을 버리십시오

앉아서 머리에 나오는 모든 것을 내려 놓으면 작가입니다. 그러나 저자는 동정없이 자신의 물건의 가치를 판단하고 대부분을 파괴 할 수있는 사람입니다.
— 시도 니 가브리엘 콜레트

결코 출시되지 않는 코드를 작성하는 것을 두려워하지 마십시오. 경험이 많을수록 잘못된 길을 가고 있음을 더 빨리 알 수 있지만 잘못된 길을 가면 여전히 발생합니다. 많은 경우 솔루션의 가치가 먼저 잘못 된 것을 볼 때까지 분명하지 않습니다.

자급 자족은 함께 올 것이다

• 도메인에서의 경험과 노출이 증가했습니다.
• 기존 시스템과 그 동작, 의존성을 이해하기 위해 관찰 기술과 분석 기술을 향상 시켰습니다.

자주 질문하면 두 가지가 모두 부족하다는 위험이 있습니다.

도메인, 기술, 플랫폼, 언어를 변경하면 정사각형으로 돌아갑니다 (거의 비슷한 문제와 이전 가능한 지식을 다루는 향상된 능력을 고려하지 않음)

실제로 필요할 때 질문하지 않으면 많은 귀중한 생산 시간이 낭비됩니다.

당신이 잘못했을 경우 가능한 피해의 정도에 대한 가정을 떨어 뜨리는 것이 유리할 것입니다. 또는 당신의 가정에 대한 실제 평가를 얻기 위해 당신이 생각할 수있는 것 많은 경우에 당신이 놓친 점과 각도를 밝힐 수 있습니다.

신중하게 행동하는 것이 좋지만 최선을 다하면 질문의 본질을 결정하기 시작합니다. 종이에 적고 난이도를 조사하는 것이 가장 좋습니다.

1. Google / 포럼을 사용하거나 더 오랫동안 작업하여 알아낼 수 있습니까?
2. 엉망으로 만들면 많은 비용을 들이지 않고 해결할 수 있습니까?

나는 당신이 일하고있는 것을보고 직접 결정을 시작한다고 말하고 싶습니다 (물론 응용 프로그램 사양 내에서 유지하십시오). 지금까지는 먼 변화에 대한 변화와 단순한 변화에 대한 느낌이 좋아야합니다. 간단한 것부터 시작하십시오. 당신이하고있는 일이 옳다고 생각한다면 그렇게하십시오.

당신은 것입니다 실수를하고 사람들은 매우 중요하다. 그들이 다음에 더 나은 일을 할 수있게 해주는 일이 생길 때 가능한 모든 것을 배우십시오.

더 작은 결정에 익숙해지면 더 큰 결정을 내리십시오. 프로젝트 / 환경 / 팀에 따라 이것과 얼마나 멀리 갈 것인지 결정해야합니다.

그것이 의사 결정 측면입니다. 당신이해야 할 또 다른 일은 당신의 결정을 안내하는 데 도움이 될 수 있도록 뇌를 계속 먹이는 것입니다. 기술을 다루는 사이트를 따르십시오. 단순한 것에서부터 기괴한 것까지 모든 것을 다루는 거의 모든 것에 대한 온라인 자습서가 있습니다. 사람들이 특정 결정을 내리는 이유를 사람들에게 물어 보지 마십시오. 정보를 찾는 사람으로서 대립하지 말아야합니다. 대부분의 사람들은 기꺼이 설명하기를 좋아하며 그들로부터 많은 것을 배울 수 있습니다.

기술 지식이 있으면 나머지는 지혜와 자신감이며 경험이있는 사람들입니다.

내가 초보자가 질문을 할 때는 항상 사용 가능한 도구를 사용하여 자신에 대한 부분적인 답변을 얻으려고 노력했습니다. 내가 할 수있는 한, 내가 도움을받을 사람이 바쁘다는 가정하에 가능한 한 명확하고 간결하게 질문을 표현하는 방법을 정확하게 알아낼 것입니다. 약간의 준비로, 나는 누군가가 그들에게 질문을하도록 신경 쓰지 않았다고 생각한다. 그리고 실제로 나는 그들이 그것을 즐겼다는 인상을 받았다. 나중에 도메인 전문가가되었을 때 나는 내 시간을 존중한다는 사실을 분명히하는 사람들을 돕는 것을 좋아했습니다.

내가 한 다른 일은 매일 시스템의 아키텍처를 선택하는 것이 었습니다. 다른 포스터는 현대의 거대한 시스템이 무엇인지, 용어를 다루기가 얼마나 어려운지에 대해 언급했습니다. 그래서 나는 코드 둘러보기를 진행할 것입니다. 현명한 진입 지점에서 시작하여 코드를 추적하고 작동 방식에 대한 메모를 적어두고 때로는 스스로 대답 할 수있는 질문을하고 때로는 다른 사람들에게 묻습니다. 이런 종류의 친숙 함과 도메인 역량은 시간이 걸리지 만 속도를 높일 수는 있습니다. 더 많이할수록 원하는 방식으로 더 빨리 자급 자족 할 수 있습니다.