무엇이 개발자를 생산적이게 만드는가

• 많은 요소가 개발자 생산성에 영향을 미침
• 일부는 명확하고 측정하기 쉽지만, 다른 것들은 측정하기 어려워서 놓치는 경향이 있음

뭘 만들어야 하는지 알기(Knowing what to build)

• 잘못된 것을 빨리 만드는 것은 전혀 생산적이지 않음
  
  • 고객이 뭘 요구하는지를 알고,
  • 다른 팀들이 수용가능한 것이 무엇인지 알고(DB 테이블에 몇개의 인덱스가 가능한가, 법적으로 허용되지 않는 정보를 공유가능한가?),
  • 이전에 시도했지만 효과가 없었던 것이 무엇인지 알아야함

더 적은 일을 하기

• 일을 빨리 완료 하는 것은 좋지만, 아예 "하지 않아"도 되는 것이 더 좋음
• 회사의 프로세스는 생산성을 떨어뜨리는 "바쁜 업무"를 추가할 수 있음
  
  • 가끔은 훨씬 적은 작업으로 동일한 가치를 제공하도록 프로세스를 쉽게 조정할 수 있는 방법이 있음
• "불을 계속 켜놓기(Keep the lights on, KTLO)"위해 어느 정도의 노력은 필요할 수 있음
• 이는 지속적으로 수행해야 하지만(예: 서포트 티켓에 답변하기), 프로젝트를 진행시키지는 않는 작업
• 이런 업무들은 여러 지표(티켓 완료 수, 커밋 머지 수)로는 생산적으로 보일 수 있지만, 회사를 더 나은곳으로 이끌지는 못함

응답이 빠른 도구들

• 개발자들은 지속적으로 도구를 사용함: 에디터, git, 빌드시스템
• 이런 도구들이 추가하는 시간은 얼마나 자주 사용되는 지에 따라 꽤 많은 비용이 발생
• 시간당 드는 비용뿐만 아니라 개발자가 집중하는 것을 깨뜨림

개발자 머리속의 지식

• 측정하기 어려움
• 다른 모든 조건이 같다면, 관련 지식이 많은 개발자가 더 생산적임
  
  • 코드가 어떻게 동작하는지 알기 때문에 코드를 깊게 들여다볼 필요가 없고,
  • 도구를 사용하는 방법을 알고, 피해야하는 함정을 알고 있음
  • 올바른 질문을 함
  • 10x 개발자는 존재하며, 그들은 "코드베이스를 잘 아는 사람들"임
• 이 것은 한 팀이 총체적으로(Collectively) 그들의 머리에 보관할 수 있는 것보다 많은 것을 소유해서는 안된다는 것. (버스 넘버가 1보다 큰 것이 이상적임 : Bus Factor 이론)
  
  • 또한 소유권이 바뀌는 빈도를 최소화 하는 것이 유리하다는 것을 의미
  • 그 누구도, 그 것을 만든 사람보다는 많이 알지 못함
  • 이상적으로는 시스템을 처음 사용하는 사람들은, 그 시스템이 이미 익숙한 사람들과 작업하고 배우는 것이 좋음
• 시스템 간에 명확한 경계가 필요함
  
  • 간단한 시맨틱을 가진 깔끔한 인터페이스는 인터페이스 뒤에 있는 전체 시스템에 대해 알 필요없이 인터페이스의 속성에 대해서 생각할 수 있다는 것을 의미함
• 문서는 지식을 전달하는 좋은 방법
  
  • 개발자가 익숙하지 않은 특정작업을 수행해야하는 경우에 특히 중요함
  • 문서가 부족하면, 개발자가 작업 수행 방법을 스스로 연구해야 하고, 실수를 하고 작업을 다시 수행하거나, 다른 팀이 질문에 답변할때까지 기다려야 하므로 작업 속도가 느려질 수 있음
  • 이는 1시간 짜리 작업을 금방 2일짜리 작업으로 만들 수 있음
  • 100명의 개발자가 이 일을 해야한다면, 문서 한페이지 누락으로 인한 비용은 개발자 한명의 연간 급여에 해당할 수 있음
• 또한 전문화(Speciailization)가 증가 되어야 한다는 것이기도 함
  
  • 모든 개발자가 광범위한 작업을 수행하도록 요구하는 것은 비생산적
  • 일부 보안 시스템이나 용량 계획을 작성하는 프로세스에 들어가는 한 시간은, 문제 해결을 위해 도메인을 이해하는데 들어가는 한시간과 다름

유용한 인프라

• 인프라는 장애물이 아니라 도움이 되어야 함
• 수행해야하는 모든 작업에 합리적으로 밀접하게 얼라인 되어야함
• 인프라의 모든 부분들은 특정 유스케이스를 염두에 두고 설계되지만, 프로젝트에서는 가끔 이런 유스케이스를 벗어나는 경우가 있음
  
  • 이럴때 "우리 인프라만을 이용해야함" 또는 "우리 인프라에서는 이런 것을 못합니다" 라는 말을 들으면 답답함
  • 이러면 인프라 주변에서 일을 해야하거나, 인프라 오너들에게 요구사항을 설득하는 회의에 들어가서 시간을 낭비해야함

적은 기술 부채

• 기존 코드는 언제나 당신이 하려는 작업에 완벽하게 적합하지 않음
  
  • 원래의 코드 작성자는 당신이 어떤 변경을 하게 될지 볼 수 있는 "수정구슬"이 없었음
  • 하지만 일부 코드는 다른 코드보다 훨씬 변경하기 쉬움
• "어떻게 X를 할수 있을까요?"에 대한 답이 "이 모든 것을 다시 설계해야 합니다"가 되면 안됨
• 기술 부채가 많다면, 기능을 조금만 변경해도 시스템을 더 크게 변경해야함
• 기술 부채를 줄이면 (a)이해해야 하고 (b)변경해야할 노출 영역을 최소화 할 수 있음
• 기술 부채를 갚기 위한 프로젝트는 완료가 되어야함
  
  • 중간에 포기하거나 우선 순위를 낮추면 시스템이 처음보다 더 나빠질 수 있음

낮은 실패율

• 도구 실행 실패, 빌드 실패, 배포 실패 또는 프로덕션 오류로 인한 회귀등이 일어나는 경우 시간을 낭비한 것
• 이런 실패확률을 낮추면 생산성이 향상됨
• 실패를 경험한 엔지니어 외에도, 실패한 시스템을 소유한 팀의 시간을 낭비하게 되는 경향이 있음(같이 실패를 분석하고 고쳐야 하기 때문)

생산적인 관행은 실용적(Productive practices are practical)

• 특정 문제를 해결하는 방법을 배우는 가장 좋은 방법은 프로토타입을 작성하는 것
• 만약 환경이 프로토타이핑을 방해한다면, 가장 생산적인 접근방식도 방해받을 수 있음
• 모니터링 도구를 사용하는데 어려움이 있다면, 개발자는 더 적은 수의 대시보드를 만들고, 더 적게 측정할 것이며, 의사 결정들이 덜 데이터 기반이 될 것
• 반대로 큰 변경사항을 더 작은 코드 리뷰로 작게 분할하면, 코드를 더 쉽게 리뷰하고 배포할 수 있음

엔지니어가 얼마나 집중할 수 있는지

• 엔지니어는 제작 일정에 따라 작업하고, 집중할 수 있어야 함
• 그 포커스는 회의와 인터럽트를 통해 훔칠 수 있음
• 인터럽트에는 느린 CLI 명령, 느린 테스트, 수행 방법을 몰라서 조사해야하는 작업들도 포함됨
• 한 주에 너무 많은 일에 대해서 생각하는 것도 집중하는 능력을 해침
• 다가오는 데드라인이나, 매니저에게서 답변 받지 못한 질문들은 다른 것에 집중하려고 할때도 정신적인 RAM을 차지힘

작업 마무리

• 50%를 구축하는 것은 50%의 생산성이 아니라 0%의 생산성임
• 버려지는 일 만큼 생산적이지 못한 것은 없음
• 중간에 프로젝트를 포기하는 것이 올바른 결정인 경우가 있기도 함
  
  • 매몰 비용 오류와 싸우는 것은 때때로 옳은 일
  • 하지만 프로젝트가 완료되기 전에 우선 순위를 변경하는 일관된 패턴이 있어서는 안됨
  • 이럴 경우 팀의 생산성이 0 으로 떨어질 수 있음

    #마무리

• 이런 다양한 요소들을 측정하기 위해 항상 대시보드를 구축할 수는 없지만, 위와 같은 것들이 생산성에 어떤 영향을 미치는 지는 알수 있음
• 이런 문제를 해결하면 수행하는 작업의 양이 크게 증가할 수 있음
• 일부 문제는 놀라울 정도로 쉽게 고칠 수 있음
  
  • 문서를 작성하는데 몇시간을 들이면, 회사에서는 수천 시간을 절약할 수 있음
• 나무를 빨리 잘라야 할 때는, 톱날을 가는 것부터 시작할 것

---

https://news.hada.io/topic?id=10222

무엇이 개발자를 생산적이게 만드는가 | GeekNews

https://jeremymikkola.com/posts/developer_productivity.html

Jeremy Mikkola - What makes developers productive?