협업 코딩이 최고의 직업 해킹인 이유

프로그래밍의 첫 단계를 밟는 것은 외국어를 배우는 것과 같습니다. 처음에는 구문이 이해가 되지 않고, 어휘가 낯설고, 모든 것이 이해할 수 없는 것처럼 보이고 들립니다. 내가 시작할 때 나와 같은 사람이라면 유창함이 불가능하게 느껴집니다.

그렇지 않다고 약속합니다. 코딩을 시작했을 때 학습 곡선이 저를 힘들게 했습니다. 나는 10개월 동안 나 자신에게 기본을 가르치는 동시에 내가 지금 사기꾼 증후군으로 인식하고 있는 자기 회의감을 없애려고 노력했다. 코딩이 협력적으로 놀라운 가능성을 열어주는 방법을 알게 된 것은 초보자 친화적인 모임에 가기 시작하면서부터였습니다. 함께 연습할 적절한 사람들의 커뮤니티만 있으면 됩니다.

저에게 그 커뮤니티는 카피라이팅에서 코딩으로 제 경력을 전환하는 데 도움이 된 무료 JavaScript 부트캠프인 Founders and Coders였습니다. 과정을 마친 지 1년도 채 안 된 지금도 소프트웨어 개발을 위해 돈을 받고 있다는 사실이 믿기지 않습니다.

협업 코딩은 문제를 해결하고 솔루션을 함께 발견하는 것입니다. 여기에는 여러 기술 회사가 인터뷰 과정에서 선별할 정도로 심각하게 고려하는 페어 프로그래밍과 같은 기술이 포함됩니다. 또한 집에서 혼자 코딩하는 것만으로도 배우기 힘든 유용한 기술을 키울 수 있습니다.

기술 산업에서 이제 막 시작했든 몇 년 간의 경험이 있든 상관없이 협업 코딩은 유용합니다. 이 기사에서는 이러한 끊임없는 기술을 통해 소프트웨어 개발 분야에서 길고 성공적인 경력을 쌓을 수 있는 방법을 살펴보겠습니다.

완벽한 페어링

페어 프로그래밍에 대한 나의 첫 경험은 Coding For Everything이라는 초보자를 위한 모임에서였습니다. 작동 방식은 다음과 같습니다. 사람들은 종종 한 번도 만난 적이 없는 사람들과 짝을 이루어 한 노트북에서 함께 JavaScript 문제를 해결합니다. 한 사람이 '내비게이터'의 역할을 맡아 작성해야 한다고 생각하는 코드를 제안합니다. 다른 사람인 '드라이버'는 노트북에 자신의 제안을 입력하고 명확하지 않은 것이 있을 때마다 질문합니다. 2시간 세션이 끝날 때까지 이 작업을 계속하면서 역할을 자주 교체합니다.

이론상으로는 간단했습니다. 실제로는 많지 않습니다.

내가 타이핑하는 동안 내가 모르는 누군가가 내 화면을 보고 있다는 것이 상당히 산만하다는 것을 알았고 역할을 바꿀 때가 되었을 때 통제권을 넘겨주기를 꺼렸습니다. 나는 탐색이 더 까다롭다는 것을 알았다. 먼저 파트너의 손을 거치지 않고 아이디어가 머리에서 컴퓨터로 들어갈 수 없을 때 당신이 말하는 모든 단어가 중요합니다. 그것은 우리 모두에게 익숙하지 않은 정도의 의사 소통을 요구했고, 나는 우리가 따로 떨어져서 일하기 위해 더 많은 것을 배울 것이라고 확신했습니다.

다행히도 우리는 그것을 고수했습니다. 나는 그 다음 주에 모임에 다시 갔다. 그 이후로 수십 명의 개발자와 수백 시간을 보냈고, 처음에 가능하다고 생각했던 것보다 더 많은 것을 배웠습니다.

페어 프로그래밍은 매우 빠르게 배울 수 있는 방법입니다. 처음의 어색함을 극복하면 이 방법의 마법은 즉각적인 결과를 얻을 수 있다는 것입니다. 주식 시장의 거품과 같은 일부 피드백 루프는 수정 사항을 생성하는 데 몇 시간, 며칠 또는 몇 달이 걸릴 수 있습니다. 페어 프로그래밍은 몇 초는 아니더라도 몇 분이 걸립니다. 세미콜론을 잘못 배치하면 두 쌍의 눈이 한 쌍보다 실수를 더 빨리 찾아낼 수 있습니다. 불량 오류 메시지에 대한 단서를 StackOverflow에서 검색해야 합니까? 당신과 당신의 파트너는 각각 다른 스레드를 읽을 수 있어 답을 찾는 데 걸리는 시간을 절반으로 줄일 수 있습니다.

더 까다로운 문제의 경우 몹 프로그래밍이 한 단계 더 향상될 수 있습니다. 이 방법을 사용하려면 한 사람이 입력하는 동안 팀의 여러 부서가 동일한 컴퓨터 화면 주위에 모여 실시간으로 솔루션을 브레인스토밍해야 합니다.

"같은 시간, 같은 공간, 같은 컴퓨터에서 같은 일을 하는 모든 천재들."

— Woody Zuill, 애자일 코치 및 몹 프로그래밍 트레이너

비효율적인 작업 방식처럼 보일 수 있지만 Woody Zuill과 같은 몹 프로그래밍 옹호자는 모든 사람이 작성되는 코드를 실시간으로 검토하기 때문에 개별 코드 검토의 필요성을 제거함으로써 실제로 시간을 절약할 수 있다고 말합니다. 생산성은 제쳐두고, 모빙은 코드뿐만 아니라 다른 사람들이 문제에 접근하는 방식에 대해서도 배울 수 있는 환상적인 방법이라고 생각합니다. 페어 프로그래밍이 노출되는 관점의 수를 두 배로 늘리면 몹 프로그래밍이 훨씬 더 많은 통찰력을 얻을 수 있습니다.

그렇다고 해서 짝짓기(또는 실제로 무리를 짓는 행위)가 평범한 항해라는 말은 아닙니다. 처음에 제가 힘들었던 것은 어리석게 들릴 수 있다고 생각되는 질문을 하기 위해 자존심을 한쪽으로 치우는 것이었습니다. 이러한 상황에서는 파트너가 같은 생각을 할 수 있음을 기억하는 것이 좋습니다. 특히 둘 다 이제 막 시작하는 경우 더욱 그렇습니다.

직장에서 더 나이가 많은 사람과 짝을 이루고 있는 자신을 발견했다면 주저하지 말고 그들의 두뇌를 골라 당신의 호기심으로 감동을 주세요. 당신보다 조금 앞서 있는 사람이라도 선배에게는 일어나지 않을 일을 생각할 수도 있습니다. 내가 가장 좋아하는 페어 프로그래머 중 일부는 나보다 몇 개월 더 경험이 있지만 그들은 항상 내가 어떤 실수를 저지르고 올바른 방향으로 나를 인도하는지 정확히 알고 있는 것 같습니다. 이 개발자들이 어리석은 질문 같은 것은 없다고 말할 때 그들은 정말로 그것을 의미합니다. 최고의 페어 프로그래머는 환상적으로 보일 필요가 없고 어리석게 보일까봐 두려워하지 않고 자유롭게 이야기합니다.

페어 프로그래밍은 연습이 필요하지만 완성할 가치가 있습니다. 연구에 따르면 문제를 해결하기 위해 짝을 이루는 프로그래머는 더 자신감 있고 생산적이며 작업에 몰두하는 경향이 있습니다. 다음 직업을 찾고 있든 새로운 직원을 채용하든 상관없이 페어링은 중요합니다.

리소스 및 추가 읽을거리

• "프로그래밍 역할 쌍", Jordan Poulton, GitHub
• "Google을 거대하게 만든 우정", James Somers, New Yorker
• "Mob Programming: 전체 팀 접근 방식", Woody Zuill, YouTube

공학적 공감

스스로 JavaScript를 가르치기 시작했을 때 내 코드는 침실 바닥과 매우 흡사했습니다. 정리할 수 밖에 없을 때까지 더 지저분해지고 지저분해졌습니다. 내 웹 브라우저가 그것을 이해할 수 있는 한 나는 그것이 어떻게 보이든 상관하지 않았다.

내가 다른 사람들의 코드를 검토하기 시작할 때까지는 내 코드를 검토하는 사람들에게 훨씬 더 많은 공감을 보여야 한다는 것을 깨달았습니다.

공감은 모든 개발자의 무기고에서 가장 과소평가된 도구일 수 있습니다. 이것이 IDEO가 사용자 연구를 디자인 프로세스의 중심에 두는 이유이며 Etsy가 디자이너와 제품 관리자에게 엔지니어링 순환을 수행하도록 요청하는 이유입니다. 공감은 우리의 일이 다른 사람들에게 어떻게 영향을 미치는지 볼 기회가 있을 때 나타납니다. 협업 코딩이 그것을 구축하는 좋은 방법이라는 것은 놀라운 일이 아닙니다.

피어 코드 검토(서로의 코드에 실수가 있는지 확인하는 행위)는 우리에게 공감을 촉구합니다. 검토자로서 누군가가 당신이 비판하려는 코드를 작성하기 위해 상당한 노력을 기울였다는 것을 인식하는 것이 중요합니다. 따라서 판단을 암시하거나 작업을 하찮게 만들 수 있는 문구를 사용하지 마십시오. 코드를 참조할 때 질문이 있는 특정 기능과 줄을 보여주고 리팩토링하는 방법을 제안하려고 합니다. 학습 리소스를 공유하는 것은 솔루션을 숟가락으로 먹이는 것보다 더 도움이 될 수 있습니다. 코드 리뷰에서 받은 가장 유용한 피드백 중 일부는 교육 기사, 비디오 및 팟캐스트 권장 사항의 형태로 제공되었습니다.

코드에 대한 좋은 문서를 작성하는 것도 큰 도움이 됩니다. 명확한 설치 지침이 포함된 추가 정보를 만드는 것만큼 간단한 작업은 코드로 작업해야 하는 모든 사람에게 공감을 표시합니다. GitHub 설립자 Tom Preston-Werner는 개발에 대한 readme-first 접근 방식을 옹호합니다.

“잘못된 사양을 완벽하게 구현하는 것은 가치가 없습니다. 같은 원칙에 따라 문서 없이 아름답게 제작된 라이브러리도 거의 무가치합니다. 당신의 소프트웨어가 잘못된 문제를 해결하거나 아무도 그것을 사용하는 방법을 알아내지 못한다면 뭔가 아주 나쁜 일이 벌어지고 있는 것입니다.”

— Tom Preston-Werner, GitHub 설립자

문서화를 성공적인 온보딩의 필수 요소로 여기는 기술 설립자들과도 이야기를 나눴습니다. 한 CTO는 주니어 개발자가 팀에 합류한 후 6개월 이내에 생산성 수준에 도달하기 위해 고군분투한다면 코드베이스가 충분히 문서화되지 않았다는 의미라고 말했습니다. 작성한 복잡한 기능에 설명을 추가하는 데 몇 초 밖에 걸리지 않지만 다음 팀에 합류하는 사람의 노력을 절약할 수 있습니다.

리소스 및 추가 읽을거리

• "공감 및 끌어오기 요청에 대해", Slack Engineering, Medium
• "Readme 기반 개발", Tom Preston-Werner, GitHub
• "Google이 완벽한 팀을 구축하기 위한 탐구에서 배운 것" Charles Duhigg, New York Times Magazine

애자일 성취

CGI 영화를 만드는 데 들어가는 수백만 시간의 작업에서부터 대규모 예산의 비디오 게임 출시로 이어지는 집중적인 개발 문제에 이르기까지, 우뚝 솟은 기술적인 성취에는 상상할 수 없을 정도로 많은 노력이 필요합니다. 현재 고용주의 코드베이스를 처음 보았을 때, 나는 그 모든 것의 방대함에 충격을 받았습니다. 도대체 누가 이걸 어떻게 지었 을까?

정답은 올바른 협업 프레임워크가 주어지면 모든 사람이 누구 보다 훨씬 더 많은 것을 구축할 수 있다는 것입니다. 협업 코딩을 장려하는 회사에서 소프트웨어는 고독한 천재의 노력에서 나오지 않습니다. 그 대신, 훌륭한 팀이 놀라운 일을 하는 데 도움이 되는 협력 방법이 있습니다. Founders and Coders의 개발자들은 'Agile'로 알려진 인기 있는 소프트웨어 개발 방법론을 실천하고 있으며, 제 경험에 따르면 이는 교차 기능 개발 팀에 '기능적'을 적용합니다.

전체 책이 Agile에 대해 작성되었지만 다음은 핵심 개념을 요약한 것입니다.

• 제품 개발 팀은 큰 작업을 '사용자 스토리'라는 작은 단위로 나누고 우선 순위를 지정하고 '스프린트'라는 2주 주기로 전달합니다.
• 프로젝트가 계속되는 한 주기가 반복되고 새로운 제품 요구 사항은 향후 스프린트를 위한 작업 백로그에 입력됩니다.
• 팀은 진행 상황을 논의하고 방해 요소를 해결하기 위해 매일 스탠드업 회의를 개최합니다.
• 이 프로세스는 점진적이고 반복적입니다. 소프트웨어는 조각으로 빌드 및 제공되며 연속적인 스프린트에서 개선됩니다.

솔로 취미 프로젝트가 종종 '기능성 크립'에 빠지는 만성 땜장이로서 아무도 사용하지 않는 것을 만드는 데 시간을 낭비하는 것이 얼마나 쉬운지 압니다. Agile이 사용자 스토리의 우선 순위를 지정하여 전체 팀이 사용자가 실제로 관심을 갖는 기능을 제공하는 데 집중할 수 있도록 하는 방식을 좋아합니다. 작업을 마친 후에도 계속해서 사용할 수 있는 제품이나 서비스를 구축한다는 공통의 목표를 중심으로 여러분 모두가 단결되어 있다는 사실은 동기를 부여합니다.

작업을 작은 사용자 스토리로 나누는 것도 프로그래밍 세션을 타임박스로 묶는 좋은 방법입니다. 자신이 얼마나 깊은 곳에 있는지에 상관없이 핵심 기능에 대한 작업을 마치는 것은 항상 책상에서 떨어져 휴식을 취하라는 좋은 알림입니다. Agile은 그렇지 않으면 부족할 수 있는 협업 코딩에 구조를 제공합니다.

한편, 일일 스탠드업은 당신을 가로막는 모든 것에 대해 자유롭게 이야기할 수 있는 기회를 제공하고 스프린트 회고전은 주요 승리를 공유하고 팀이 개선할 수 있는 부분을 정확히 지적할 수 있는 공간을 제공합니다. 이러한 의식은 협동심과 책임감을 키우고 혼자 할 수 있는 것보다 함께 더 많이 배울 수 있도록 도와줍니다.

이러한 애자일 원칙을 모두 실행하는 것은 어려울 수 있습니다. 특히 팀 구성원 중 누구도 이러한 방식의 작업에 익숙하지 않은 경우에는 더욱 그렇습니다. Founders and Coders에서는 대부분의 학생들이 매일 스탠드업을 하는 습관을 들이는 데 시간이 걸립니다. 그러나 18주간의 프로젝트 기반 실습 후에 프로세스와 커뮤니케이션 기술이 엄청나게 향상되었음을 알게 됩니다. 첫 번째 클라이언트 작업을 맡을 때쯤이면 팀에서 전체 스택 웹 앱을 구축하는 방법에 대한 훨씬 더 명확한 정신적 모델을 형성하게 됩니다.

Agile을 배우는 가장 좋은 방법은 다른 사람들과 흥미로운 프로젝트를 만드는 것입니다. 해커톤에 참석하는 것은 잠재적인 협력자와 연결하는 훌륭한 방법입니다. 많은 오픈 소스 프로젝트는 kanban 프로젝트 보드를 공개하므로 다양한 기여자가 작업 중인 GitHub 문제를 볼 수 있습니다. 초보자의 여러 기여를 환영하며 종종 자신을 미해결 문제에 할당하고 끌어오기 요청을 제기할 수 있습니다.

대부분의 기술 회사는 어떤 형태의 Agile에 가입하기 때문에 고용주가 인터뷰에서 이에 대해 묻는 것은 드문 일이 아닙니다. 당신이 가진 모든 경험은 Agile을 염두에 두고는 고사하고 공동으로 코딩한 적이 없는 다른 지원자와 차별화될 수 있습니다.

리소스 및 추가 읽을거리

• "애자일이란 무엇입니까?", 스티브 데닝, Forbes
• "애자일 수용", Darrell K. Rigby, Jeff Sutherland, Hirotaka Takeuchi, Harvard Business Review
• "멋진 첫 풀 리퀘스트 기회", Shmavon Gazanchyan, Deloitte Digital

원격 협업 코딩 도구 권장 사항

지난 몇 년 동안 원격 작업 도구는 Gatsby 및 Zapier와 같은 저명한 회사가 이제 "원격 우선"이 될 정도로 발전했습니다. 이것이 추세로 바뀔지는 두고 볼 일이지만 원격 개발 팀이 남아 있다고 해도 과언이 아닙니다.

이러한 정신을 바탕으로 다음은 귀하와 귀하의 팀이 멀리서 공동으로 코드를 작성하는 데 도움이 되는 몇 가지 도구입니다.

이 기사를 읽으면서 한 가지 빼면 팀 플레이어가 개별 기여자보다 우선시되기를 바랍니다. 격주로 마스터해야 할 최신 프레임워크가 있는 것처럼 보이는 분야에서 우리의 기술 기술은 소프트 기술이 아닌 방식으로 늙습니다. 결과는 다른 사람들과 잘 협력할 수 있는 개발자는 항상 자신의 능력이 필요하다는 것을 알게 된다는 것입니다. 협업 코딩은 학습을 위한 효과적인 방법일 뿐만 아니라; 누구나 충분한 연습과 인내로 개발할 수 있는 인기 있는 기술입니다.