코딩을 업그레이드하는 것만으로는 더 나은 개발자가 될 수 없는 이유

Techlead Skyeng Kirill Rogovoy(깜박임)는 모든 좋은 개발자가 최고가 되기 위해 개발해야 하는 기술에 대해 컨퍼런스에서 프레젠테이션을 합니다. 나는 그에게 이 이야기를 Habra 독자들과 공유해달라고 요청했고 Kirill에게 발언권을 제공했습니다.

좋은 개발자에 대한 통념은 다음과 같습니다.

1. 깔끔한 코드를 작성합니다
2. 기술을 많이 알고 있다
3. 코딩 작업 속도 향상
4. 다양한 알고리즘과 디자인 패턴을 알고 있습니다.
5. Clean Code를 사용하여 모든 코드를 리팩터링할 수 있습니다.
6. 프로그래밍 이외의 작업에 시간을 낭비하지 않습니다.
7. 당신이 좋아하는 기술의 100% 마스터

이것이 HR이 이상적인 후보자를 보는 방식이며 그에 따라 공석도 이와 같습니다.

그러나 내 경험에 따르면 이것은 사실이 아닙니다.

첫째, 두 가지 중요한 면책 사항:
1) 내 경험은 제품 팀입니다. 아웃소싱이 아닌 자체 제품을 보유한 회사; 아웃소싱에서는 모든 것이 매우 다를 수 있습니다.
2) 당신이 후배라면 모든 조언이 적용되지는 않을 것이고, 내가 당신이라면 지금은 프로그래밍에 집중할 것입니다.

좋은 개발자: 현실

1: 평균 코드보다 좋음

좋은 개발자는 멋진 아키텍처를 만들고, 멋진 코드를 작성하고, 버그를 너무 많이 만들지 않는 방법을 알고 있습니다. 일반적으로 그는 평균보다 더 잘하지만 전문가 중 상위 1%에는 속하지 않습니다. 내가 아는 가장 멋진 개발자들 대부분은 그렇게 뛰어난 코더는 아닙니다. 그들은 자신이 하는 일에 있어서는 훌륭하지만 엄청나게 놀라운 일을 할 수는 없습니다.

2: 문제를 만드는 대신 문제를 해결합니다.

외부 서비스를 프로젝트에 통합해야 한다고 가정해 보겠습니다. 우리는 기술 사양을 받고, 문서를 보고, 뭔가 오래된 것을 확인하고, 추가 매개변수를 전달하고, 약간의 조정을 하고, 어떻게든 모든 것을 구현하려고 노력하고, 몇 가지 비뚤어진 방법이 올바르게 작동하도록 만듭니다. 우리는 이렇게 계속할 수 없다는 것을 알고 있습니다. 이 상황에서 개발자의 표준 행동은 비즈니스로 돌아가서 다음과 같이 말하는 것입니다. “내가 이런 일을 했는데, 이건 그렇게 안 되고, 저건 전혀 안 되니까 직접 알아내세요. ” 비즈니스에는 문제가 있습니다. 무슨 일이 일어났는지 조사하고, 누군가와 소통하고, 어떻게든 문제를 해결하려고 노력해야 합니다. 고장난 전화가 시작됩니다. "그에게 말하면 내가 문자를 보내겠습니다. 그들이 무엇을 대답했는지보세요."

그러한 상황에 직면한 좋은 개발자는 직접 연락처를 찾고, 전화로 연락하고, 문제에 대해 논의하고, 아무것도 해결되지 않으면 적합한 사람들을 모아 모든 것을 설명하고 대안을 제공할 것입니다. 더 나은 지원을 제공하는 외부 서비스). 그러한 개발자는 비즈니스 문제를 보고 해결합니다. 그의 작업은 그가 비즈니스 문제를 해결할 때 종료되고, 무언가에 직면할 때가 아닙니다.

3: 목발을 짚고 쓰더라도 최대의 결과를 얻기 위해 최소한의 노력을 기울이려고 노력합니다.

제품 회사의 소프트웨어 개발은 ​​거의 항상 가장 큰 비용 항목입니다. 개발자에게는 비용이 많이 듭니다. 그리고 좋은 개발자는 기업이 최소한의 비용을 지출하여 최대의 돈을 얻고 싶어한다는 것을 이해합니다. 그를 돕기 위해, 좋은 개발자는 고용주를 위한 최대 이익을 얻기 위해 최소한의 값비싼 시간을 사용하기를 원합니다.

여기에는 두 가지 극단이 있습니다. 하나는 일반적으로 아키텍처나 리팩토링 등의 문제 없이 목발만으로 모든 문제를 해결할 수 있다는 것입니다. 우리 모두는 이것이 일반적으로 어떻게 끝나는지 알고 있습니다. 아무것도 작동하지 않으며 프로젝트를 처음부터 다시 작성합니다. 또 다른 경우는 작업에 XNUMX시간, 리팩토링에 XNUMX시간을 소비하면서 각 버튼에 대한 이상적인 아키텍처를 생각해 내는 경우입니다. 이러한 작업의 결과는 훌륭해 보이지만 문제는 비즈니스 측면에서 단순히 다른 이유로 인해 첫 번째와 두 번째 경우 모두 버튼을 완료하는 데 XNUMX시간이 걸린다는 것입니다.

좋은 개발자는 이러한 극단 사이에서 균형을 맞추는 방법을 알고 있습니다. 그는 맥락을 이해하고 최적의 결정을 내립니다. 이 문제에서는 XNUMX개월에 한 번씩 만지는 코드이기 때문에 저는 버팀목을 자르겠습니다. 하지만 이번 버전에서는 아직 개발되지 않은 수백 가지의 새로운 기능이 제가 성공하느냐에 달려 있기 때문에 모든 일을 가능한 한 올바르게 수행할 것입니다.

4. 자체 비즈니스 관리 시스템을 갖추고 있으며 복잡한 프로젝트를 수행할 수 있습니다.

원칙에 따라 작업 얻는 것들 완료 – 어떤 종류의 텍스트 시스템에 모든 작업을 기록할 때 합의 사항을 잊지 말고 모든 사람을 격려하고 정시에 모든 곳에 나타나며 현재 중요한 것이 무엇인지 중요하지 않은 것이 무엇인지 파악하면 작업을 잃지 않습니다. 그러한 사람들의 일반적인 특징은 당신이 그들과 어떤 것에 동의할 때 그들이 잊어버릴까 봐 전혀 걱정하지 않는다는 것입니다. 그리고 당신은 또한 그들이 모든 것을 적고 그 대답이 이미 논의된 수천 가지 질문을 묻지 않을 것이라는 것을 알고 있습니다.

5. 조건과 소개에 대해 질문하고 명확히 합니다.

여기에도 두 가지 극단이 있습니다. 한편으로는 모든 소개 정보에 대해 회의적일 수 있습니다. 이전 사람들은 몇 가지 솔루션을 생각해 냈지만 더 잘할 수 있다고 생각하고 디자인, 비즈니스 솔루션, 아키텍처 등 이전에 나온 모든 것에 대해 다시 논의하기 시작합니다. 이는 개발자와 주변 사람들 모두에게 많은 시간을 낭비하고 회사 내 신뢰에 부정적인 영향을 미칩니다. 다른 사람들은 그 사람이 돌아와서 모든 것을 망칠 것이라는 것을 알기 때문에 결정을 내리기를 원하지 않습니다. 다른 극단은 개발자가 입문, 기술 사양 및 비즈니스 희망사항을 돌에 새긴 것으로 인식하고, 해결할 수 없는 문제에 직면했을 때만 자신이 하고 있는 일이 과연 실행되고 있는지에 대해 생각하기 시작하는 경우입니다. 좋은 개발자는 여기서도 중간 지점을 찾습니다. 그는 작업이 개발에 들어가기 전에 자신 이전에 내린 결정이나 그 없이 내린 결정을 이해하려고 노력합니다. 기업은 무엇을 원하는가? 우리는 그의 문제를 해결하고 있나요? 제품 디자이너가 솔루션을 생각해 냈지만 솔루션이 작동하는 이유를 이해하고 있습니까? 팀 리더가 이 특정 아키텍처를 생각해낸 이유는 무엇입니까? 명확하지 않은 것이 있으면 가서 물어봐야 합니다. 이러한 설명 과정에서 훌륭한 개발자는 이전에 누구에게도 발생하지 않았던 대체 솔루션을 볼 수 있습니다.

6. 주변 사람들과 프로세스를 개선합니다.

우리 주변에는 일일 회의, 모임, 스크럼, 기술 리뷰, 코드 리뷰 등 수많은 프로세스가 진행되고 있습니다. 훌륭한 개발자는 일어나 이렇게 말할 것입니다. 보세요, 우리는 매주 모여서 같은 것에 대해 토론합니다. 왜 그런지 모르겠습니다. 이 시간을 Contra에 보내는 것이 낫습니다. 또는: 연속 세 번째 작업의 경우 코드에 들어갈 수 없고 명확한 것이 없으며 아키텍처에 구멍이 가득합니다. 어쩌면 우리의 리뷰 코드가 형편없어서 리팩터링이 필요할 수도 있습니다. XNUMX주마다 모임을 리팩토링합시다. 또는 코드 검토 중에 동료 중 한 명이 특정 도구를 충분히 효과적으로 사용하지 않는 것을 발견하면 나중에 와서 조언을 주어야 한다는 의미입니다. 좋은 개발자는 이런 본능을 가지고 있으며 자동으로 그런 일을 합니다.

7. 관리자가 아니더라도 남을 관리하는데 탁월하다

이 스킬은 '문제를 만드는 것보다 해결하는 것'이라는 주제와 잘 맞습니다. 종종 우리가 지원하는 공석 텍스트에는 관리에 대한 내용이 없지만 통제할 수 없는 문제에 직면했을 때 여전히 다른 사람을 어떤 식으로든 관리하고 그들로부터 무언가를 달성해야 합니다. 잊어 버렸습니다-밀고 그들이 모든 것을 이해했는지 확인하십시오. 좋은 개발자는 누가 무엇에 관심이 있는지 알고, 이 사람들과 회의를 소집하고, 계약서를 작성하고, 여유 시간에 보내고, 적절한 날에 상기시키고, 개인적으로 직접적인 책임이 없더라도 모든 것이 준비되었는지 확인합니다. 그러나 그 결과는 구현에 따라 달라집니다.

8. 자신의 지식을 교리로 인식하지 않고 끊임없이 비판을 받습니다.

자신의 기술에 대해 타협할 수 없고 잘못된 돌연변이 때문에 모두가 지옥에서 불타버릴 것이라고 비명을 지르는 이전 직장의 동료를 누구나 기억할 수 있습니다. 좋은 개발자는 업계에서 5년, 10년, 20년 동안 일하면 자신의 지식 중 절반은 썩은 것이고 나머지 절반은 자신이 아는 것보다 XNUMX배는 모른다는 것을 이해합니다. 그리고 누군가가 그의 의견에 동의하지 않고 대안을 제시할 때마다 그것은 그의 자존심에 대한 공격이 아니라 무언가를 배울 수 있는 기회입니다. 이를 통해 그는 주변 사람들보다 훨씬 빠르게 성장할 수 있습니다.

이상적인 개발자에 대한 내 생각을 일반적으로 받아 들여지는 것과 비교해 보겠습니다.

이 그림은 위에서 설명한 포인트 중 코드와 관련이 있는 점과 그렇지 않은 점을 보여줍니다. 제품 회사의 개발은 프로그래밍의 2/3에 불과하고 나머지 XNUMX/XNUMX는 코드와 거의 관련이 없습니다. 그리고 우리가 많은 코드를 작성하더라도 효율성은 이러한 "관련 없는" XNUMX/XNUMX에 크게 좌우됩니다.

전문화, 일반주의 및 80-20 규칙

어떤 좁은 문제를 해결하는 방법을 배우고, 오랫동안 열심히 공부했지만, 쉽고 간단하게 문제를 해결했지만, 관련 분야에 대한 전문 지식이 없으면 이것이 전문화입니다. 일반주의는 훈련 시간의 절반을 자신의 역량 분야에 투자하고 나머지 절반은 관련 분야에 투자하는 것입니다. 따라서 첫 번째 경우에는 한 가지 일을 완벽하게 수행하고 나머지는 제대로 수행하지 못하며 두 번째 경우에는 모든 일을 어느 정도 잘 수행합니다.

80-20 법칙은 결과의 80%가 20%의 노력에서 나온다는 것을 의미합니다. 수익의 80%는 20%의 고객에게서 나오고, 이익의 80%는 20%의 직원에게서 나옵니다. 교육에 있어서 이는 우리가 처음 80%의 시간을 투자하여 지식의 20%를 얻는다는 것을 의미합니다.

코더는 코딩만 하고, 디자이너는 디자인만 하고, 분석가는 분석하고, 관리자는 관리만 하면 된다는 아이디어가 있습니다. 내 생각에는 이 아이디어는 해롭고 잘 작동하지 않습니다. 이것은 모든 사람이 보편적인 군인이 되어야 한다는 것이 아니라 자원을 절약하는 것입니다. 개발자가 관리, 설계 및 분석에 대해 최소한 조금이라도 이해하면 다른 사람의 개입 없이도 많은 문제를 해결할 수 있습니다. 어떤 종류의 기능을 만들고 두 개의 SQL 쿼리가 필요한 특정 상황에서 사용자가 해당 기능을 어떻게 사용하는지 확인해야 하는 경우, 이로 인해 분석가의 주의가 산만해지지 않는 것이 좋습니다. 기존 버튼과 유사하게 버튼을 삽입해야 하고, 일반적인 원리를 이해하고 있다면 디자이너가 개입하지 않고도 할 수 있으며, 회사에서는 이에 대해 감사할 것입니다.

전체: 한 기술을 한계까지 연구하는 데 시간의 100%를 사용하거나, 80개 영역에 동일한 시간을 사용하여 각 영역에서 최대 XNUMX% 레벨을 올릴 수 있습니다. 이 순진한 수학을 따르면 같은 시간에 XNUMX배의 기술을 얻을 수 있습니다. 이는 과장된 표현이지만 아이디어를 잘 보여줍니다.

관련 기술은 80%가 아닌 30~50%까지 훈련할 수 있습니다. 10~20시간을 투자하면 관련 영역이 눈에 띄게 향상되고 해당 영역에서 발생하는 프로세스에 대해 많은 이해를 얻게 되며 훨씬 더 자율적이게 됩니다.

오늘날의 IT 생태계에서는 가능한 한 많은 기술을 보유하고 그 중 어느 하나에도 전문가가 되지 않는 것이 좋습니다. 첫째, 특히 프로그래밍과 관련하여 이러한 모든 기술은 빠르게 사라지고, 둘째, 99%의 시간 동안 우리는 기본 기술뿐만 아니라 확실히 가장 정교한 기술도 사용하지 않기 때문에 코딩에서도 충분합니다. 멋진 회사들.

그리고 마지막으로 교육은 투자이며, 투자에는 다각화가 중요합니다.

무엇을 가르칠 것인가

그렇다면 무엇을, 어떻게 가르칠 것인가? 강력한 회사의 일반적인 개발자는 정기적으로 다음을 사용합니다.

• 통신
• 자기 조직
• 계획
• 디자인 (보통 코드)
• 때로는 관리, 리더십, 데이터 분석, 글쓰기, 채용, 멘토링 및 기타 여러 기술

그리고 실제로 이러한 기술 중 어느 것도 코드 자체와 교차하지 않습니다. 별도로 교육하고 업그레이드해야 하며, 이를 수행하지 않으면 매우 낮은 수준으로 유지되어 효과적으로 사용할 수 없습니다.

어떤 분야에서 발전할 가치가 있나요?

1. 소프트 스킬은 편집기에서 버튼을 누르는 것과 관련되지 않은 모든 것입니다. 이것이 바로 우리가 메시지를 쓰는 방법, 회의에서 행동하는 방법, 동료와 소통하는 방법입니다. 이것들은 모두 명백한 것 같지만 매우 자주 과소평가됩니다.

2. 자기 조직 시스템. 개인적으로 이것은 지난 한 해 동안 매우 중요한 주제가 되었습니다. 내가 아는 모든 멋진 IT 작업자 중에서 이것은 가장 발전된 기술 중 하나입니다. 그들은 매우 조직적이며 항상 말한 대로 수행하며 내일, 일주일 후, 한 달 후에 무엇을 할 것인지 정확히 알고 있습니다. 모든 문제와 모든 질문이 기록되는 시스템을 자신을 중심으로 구축하는 것이 필요하며, 이는 작업 자체를 크게 촉진하고 다른 사람과의 상호 작용에 큰 도움이 됩니다. 나는 지난 XNUMX년 동안 이 방향으로의 발전이 기술 향상보다 훨씬 더 발전했다고 생각하며 단위 시간당 훨씬 더 많은 작업을 수행하기 시작했습니다.

3. 적극적이고 개방적이며 계획적인 사람입니다. 주제는 매우 일반적이고 중요하며 IT에만 국한되지 않으며 모든 사람이 개발해야 합니다. 사전 대응은 조치를 취하기 위한 신호를 기다리지 않는다는 것을 의미합니다. 당신은 사건에 대한 반응이 아니라 사건의 근원입니다. 열린 마음은 새로운 정보를 객관적으로 처리하고 자신의 세계관과 오래된 습관에서 벗어나 상황을 평가하는 능력입니다. 계획은 오늘의 작업이 주, 월, 연도의 문제를 어떻게 해결하는지에 대한 명확한 비전입니다. 특정한 일을 넘어 미래를 내다본다면 필요한 일을 하는 것이 훨씬 쉬울 것이고, 시간이 지나도 그것이 낭비였다는 것을 깨닫는 것을 두려워하지 않을 것입니다. 이 기술은 경력에 특히 중요합니다. 수년 동안 성공적으로 결과를 얻을 수 있지만 잘못된 곳에서 잘못된 방향으로 움직이고 있다는 것이 분명해지면 결국 쌓인 짐을 모두 잃을 수 있습니다.

4. 관련된 모든 영역은 기본 수준에 이릅니다. 모든 사람은 자신만의 특정 영역을 가지고 있지만 일부 "외국" 기술을 향상하는 데 10~20시간의 시간을 투자하면 일상 업무에서 많은 새로운 기회와 접점을 발견할 수 있다는 점을 이해하는 것이 중요합니다. 경력이 끝날 때까지 충분합니다.

읽을 내용

자기 조직화에 관한 책은 엄청나게 많고, 몇몇 이상한 사람들이 조언 모음집을 쓰고 훈련을 모으는 것은 업계 전체입니다. 동시에, 그들이 인생에서 무엇을 성취했는지는 불분명합니다. 그러므로 저자에게 필터를 씌우고 그들이 누구인지, 그 뒤에 무엇이 있는지 살펴보는 것이 중요합니다. 나의 발전과 전망은 네 권의 책에서 가장 큰 영향을 받았는데, 모두 위에서 설명한 기술 향상과 어떤 식으로든 관련되어 있었습니다.

1. 데일 카네기 “친구를 사귀고 사람들에게 영향을 미치는 방법”. 소프트 스킬에 관한 컬트 북, 어디서부터 시작해야 할지 모르겠다면 이를 선택하는 것이 윈윈(win-win) 옵션입니다. 예제를 기반으로 작성되었으며 읽기 쉽고 읽은 내용을 이해하는 데 많은 노력이 필요하지 않으며 습득한 기술을 즉시 적용할 수 있습니다. 전체적으로 이 책은 사람과의 소통이라는 주제를 다루고 있다.

2. 스티븐 R. 코비 “성공하는 사람들의 7가지 습관”. 소규모 팀을 거대한 팀으로 전환해야 할 때 시너지 효과 달성에 중점을 두고 사전 대응성부터 소프트 스킬까지 다양한 기술을 혼합합니다. 읽기도 쉽습니다.

3. 레이 달리오 "원칙". 저자가 40년간 경영해온 회사의 역사를 바탕으로 개방성과 적극성을 주제로 풀어낸다. 힘들게 얻은 많은 삶의 사례는 사람이 얼마나 편견과 의존성을 가질 수 있는지, 그리고 그것을 제거하는 방법을 보여줍니다.

4. 데이비드 앨런, “일 처리하기”. 자기 조직화를 배우기 위한 필수 독서. 읽기가 쉽지는 않지만 삶과 일을 정리하기 위한 포괄적인 도구 세트를 제공하고 모든 측면을 자세히 검토하며 정확히 필요한 것이 무엇인지 결정하는 데 도움이 됩니다. 그녀의 도움으로 나는 나머지를 잊지 않고 항상 가장 중요한 일을 할 수 있는 나만의 시스템을 구축했습니다.

단지 읽는 것만으로는 충분하지 않다는 것을 이해해야 합니다. 일주일에 적어도 한 권의 책을 삼킬 수 있지만 효과는 며칠 동안 지속되고 모든 것이 제자리로 돌아갑니다. 책은 실제로 즉시 테스트할 수 있는 조언의 원천으로 활용되어야 합니다. 만약 당신이 이것을 하지 않는다면, 그들이 줄 것은 당신의 시야가 어느 정도 넓어지는 것뿐입니다.

출처 : habr.com