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

(jeremymikkola.com)

86P by xguru 2023-08-07 | favorite | 댓글 7개

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

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