프로그래밍은 대부분 사고(思考)의 과정 (2014)

 (agileotter.blogspot.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 코드로 보이는 산출물은 하루 작업 전체가 아니라, 읽기·조사·디버깅·검증·결정 끝에 남은 순수 결과물에 가까움
  • 여러 해 동안 프로그래머들에게 던진 비공식 질문에서, 6시간짜리 변경을 diff만 보고 다시 입력하는 데 가장 흔한 답은 약 30분이었음
  • 이 비율은 과학적 연구가 아니라 설문과 diff 관찰에 기반하지만, 프로그래밍을 1/12은 동작, 11/12는 사고로 보는 실용적 기준이 됨
  • 소프트웨어 개발은 공장식 제작보다 설계 작업에 가깝고, 최초 설계 뒤의 복제는 기계가 거의 0에 가까운 한계비용으로 수행함
  • 관리와 프로세스가 타이핑 시간을 늘리는 쪽으로 최적화되면 빗나간 효과를 낳으며, 사고의 품질을 높이는 환경과 협업 방식이 더 중요함

6시간 작업을 다시 입력하는 데 걸리는 시간

  • 가정은 회의와 방해가 거의 없는 좋은 날에 프로그래머가 6시간의 진지한 프로그래밍을 했다는 상황임
  • 퇴근 전 diff를 출력했지만, 밤사이 버전 관리 시스템이 망가져 전날 백업으로 복구되며 하루 작업이 사라짐
  • 질문의 핵심은 diff를 건네받은 프로그래머가 그 6시간의 작업을 코드베이스에 다시 입력하는 데 얼마나 걸리느냐임
  • 여러 해 동안 컨벤션, 고객사, 동료, 처음 만난 프로그래머에게 이 질문을 던졌고, 가장 흔한 답은 약 30분이었음
  • 6시간에는 30분이 12번 들어가므로, 이 관찰은 프로그래밍이 1/12은 동작, 11/12는 사고라는 표현으로 이어짐

비율의 성격과 한계

  • 이 수치는 철저한 과학 연구에서 나온 값이 아니며, 좋은 기록을 남긴 공식 조사도 아님
  • 목표는 프로그래밍 활동의 통계적·수학적 법칙을 찾는 것이 아니라, 합리적인 질문에 대한 합리적인 답을 찾는 데 있었음
  • 어떤 회사도 하루 작업 전체를 실제로 삭제해 실험을 증명하거나 반박하려 하지 않았기 때문에, 근거는 추정과 일일 diff 관찰에 머묾
  • 많은 changelog와 diff를 살펴본 결과, 좋은 날의 순수 변경량은 대체로 30분 ± 10분 정도로 보였음

타이핑은 병목이 아니다

  • “타이핑은 병목이 아니다”라는 말은 오래전부터 스티커와 소셜 미디어에서 반복되어 왔음
  • 일부 프로그래머에게는 타이핑 자체가 병목이 될 수 있지만, 빠른 코드 생산의 핵심은 보통 타이핑 속도나 도구 숙련만이 아님
  • Quora의 “How do programmers code so quickly?”라는 긴 글에서 한 응답자는 근육 기억, 도구 숙련, 디버깅 능력, 타이핑 능력, 정보 검색 능력을 언급했음
  • 그러나 빠른 코드 생산에서 타이핑과 도구는 보조 수단에 가깝고, 무엇을 해야 하는지 판단하는 시간이 더 큰 비중을 차지함

소프트웨어 공장과 설계 작업의 차이

  • 물리적 제품 생산에서는 눈에 보이는 작업 대부분이 움직임이며, 철을 굴리고 찍고 누르고 밀링하고 배치하고 조립하는 행위가 작업처럼 보임
  • 현대 공장은 CNC 기계처럼 추상 모델, 즉 데이터를 기반으로 정확한 움직임을 수행하고, 인간은 기계를 직접 수작업하는 대신 관리함
  • 소프트웨어 쪽의 공장은 이미 완성되어 있으며, 사용자는 “copy”나 “download” 버튼을 눌러 bit-perfect copy를 얻음
  • 최초 모델이 존재하면 이후 복제의 한계비용은 사실상 0에 가까우며, 소프트웨어는 지적 재화임
  • Uncle Bob Martin은 소프트웨어 개발이 제작 작업이 아니라 설계 작업이며, 최초 설계 이후의 복제는 기계가 거의 0 비용으로 수행한다고 말해 왔음
  • 프로그래머, 테스터, PO, Scrum Master, 소프트웨어 관리자는 고객과 커뮤니티가 사용할 복제본의 기반이 되는 데이터 모델을 설계함

지적 작업은 관찰하기 어렵다

  • 산업시대식 사고는 소프트웨어 개발을 공장처럼 보려 하고, 개발자는 실제 프로세스에 해가 되더라도 물리적 노동처럼 보이게 하라는 압박을 받음
  • 지적 활동은 관찰과 측정이 어렵고, 80% 완성된 아이디어에는 물리적 형태가 없음
  • 실험, proof-of-concept 코드, 메모가 있을 수는 있지만, 물리적 작업처럼 정확한 완료율을 보여주지 못함
  • 제조 중인 의자는 50% 지점에서 대략 50% 완성된 것처럼 보이고, 완성되면 완성품처럼 보임
  • 의자 설계는 70% 이상 진행되기 전까지 종이에 존재하지 않을 수도 있으며, 설계가 끝나기 전에는 실제로 70% 완료인지도 알기 어려움

30분짜리 변경이 6시간의 일을 뜻하는 이유

  • 30분은 하루 종일 썼다 지우고 편집하고 다시 만든 코드의 순수 결과물을 재현하는 시간이지, 투입된 노력 전체가 아님
  • 프로그래머는 결함과 보안 취약점을 피하기 위해 코드를 쓰는 동안 계속 평가하고 가설을 세움
  • 코드 텍스트는 실행 시 프로그램이 무엇을 해야 하는지만 담고, 왜 그 방식을 택했는지, 시스템의 다른 부분에 어떤 영향을 주는지, 어떤 오류를 넣었다가 제거했는지는 대체로 남기지 않음
  • 실제 작업의 대부분은 변경 자체가 아니라 변경 방법을 결정하는 데 있으며, 기존 코드를 이해해야 하므로 지저분한 코드나 설계가 드러나지 않는 소스에서는 시간이 더 듦
  • 프로그래머의 결과물은 공유 코드베이스에 통합되므로 사회적 맥락을 가지며, 다른 프로그래머·테스터·운영 담당자가 작업을 이해하도록 돕는 일도 코드에는 드러나지 않는 비용과 이익을 만듦

코드 줄 수는 진척의 척도가 아니다

  • 6시간의 지적 작업은 읽기, 조사, 결정, 확인, 검증, 검토를 거쳐 코드베이스의 순수 변경 30분치로 바뀔 수 있음
  • 이는 추가된 코드 줄 수를 뜻하지 않으며, 버그 수정과 기능 추가를 했는데도 주말의 코드 줄 수가 주초보다 줄어드는 경우가 있음
  • 팀의 상위 관리자가 SLOC를 진척 지표처럼 보고하고 있다는 사실을 모른 채, 여러 주 동안 음수 코드 줄 수를 기록해 문제가 된 적이 있었음
  • 프로그래머가 실제로 한 일은 읽기, 학습, 이해, 추측, 조사, 디버깅, 테스트, 컴파일, 실행, 가설 수립과 반증에 가까움
  • 많은 작업은 결국 생각하고 결정하는 일로 남음

덜 쓰는 것이 빠른 개발일 수 있다

  • Quora 응답 중 하나는 키보드 위에서 손가락이 움직이는 모습은 보이지만, 사용자와 대화하고 동료와 문제를 논의하고 조사하고 생각하는 시간은 보이지 않는다고 했음
  • 다른 응답자는 고객이 “요구사항”이나 “must have”라고 부르는 불필요한 생각을 제거하도록 돕는 것이 해결책 전달을 가장 크게 가속한다고 했음
  • 또 다른 응답자는 뛰어난 개발자가 키보드를 만지기 전에 요구사항을 이해하고 적절한 해법을 구상하면서 작업의 90% 이상을 수행한다고 했음
  • “무엇을 쓰지 않을지 알기”, “덜 하기”, “더 작은 단계로 일하기”, “먼저 무엇을 할지 파악하기”가 반복적으로 등장하는 답변임
  • 더 많이 타이핑하거나 더 많이 복사·붙여넣기 하는 사람은 사고와 이해가 부족할 수 있고, 그 결과 오류와 다른 프로그래머의 이해·수정 부담이 늘어날 수 있음

프로세스는 사고를 위해 설계되어야 한다

  • 프로그래밍이 1/12의 동작과 11/12의 사고라면, 사람들에게 시간의 11/12 동안 타이핑하라고 압박해서는 안 됨
  • 필요한 것은 사고의 품질을 높이는 재료, 환경, 프로세스임
  • 반대로 하면 시스템을 잘못된 효과에 맞춰 최적화하게 됨
  • 소프트웨어에 대해 함께 생각하고 결정을 더 쉽게 내리도록 시스템을 의도적으로 만들 때 생산성이 높아질 수 있음
  • 업무 중 학습을 실험하며 사고가 최적화되는 시스템을 만드는 방법을 고민해야 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 기사 속 “정말 뛰어난 개발자는 키보드를 만지기 전에 작업의 90% 이상을 끝낸다”는 말은 때로 맞지만, 사람들이 머릿속에 많은 제약과 개념을 동시에 담아둘 수 없다는 사실을 놓친다고 봄
    아무것도 쓰지 않고 순수하게 생각만 할 수 있는 범위는 매우 제한적이라서, 가능한 접근법이 하나라도 떠오르면 완전히 명세화된 설계로 다듬기 전에 거의 바로 키보드를 잡는 편임
    실제 코드를 써보며 여러 접근을 시험해보면 처음에 최고라고 생각한 해법이 덜 유망해 보였던 해법보다 훨씬 나쁜 경우가 많았고, 실행되는 구체적인 코드만큼 문제를 잘 드러내는 것은 없음
    결국 코딩은 아이디어를 코드로 물질화해 검증하는 과정이고, 첫 번째 반복을 버린다는 프로토타이핑 관점처럼 코드 작성도 사고 과정의 일부로 봐야 함

    • 그 문장을 읽고 같은 생각을 했고, 아마 Linus Torvalds 같은 사례를 떠올린 것 같음
      전설처럼 Git을 한 달쯤 생각한 뒤 6일 만에 완성했고 7일째 쉬었다는 식인데, 보통 사람들, 특히 내 경우는 무엇을 쓸지 생각하고, 쓰고, 테스트하고, 다시 생각하고, 일부를 고치는 식의 상호작용에 가까움
      결국 최종 동작 버전에 도달하는 과정은 어느 정도 예술에 가까움
    • 보통 반복하는 편임
      대략적인 아이디어를 잡고 나면 문제가 생길 가능성이 가장 높아 보이는 “끈적한” 부분부터 코드를 쓰기 시작함
      모든 문제를 미리 예상할 수 없어서 실제로 부딪혀봐야 하고, 이 방식은 많은 작업을 버리게 만들 때가 많음
      제대로 가고 있다는 확신이 들기 전까지는 문서를 거의 쓰지 않는데[0], 그래야 내가 Concrete Galoshes[1]라고 부르는 상태를 줄일 수 있음
      [0] https://littlegreenviper.com/miscellany/evolutionary-design-...
      [1] https://littlegreenviper.com/miscellany/concrete-galoshes/
    • 애플리케이션 전체를 머릿속에서 설계하려면 사용하는 플랫폼과 기술의 함정에 아주 익숙해야 함
      그걸 익히는 유일한 방법은 많은 실전 코딩과 능동적 학습이고, 같은 기술 스택을 계속 반복해 쓴다는 뜻이기도 함
      같은 스택에 머물러 문제 자체에 집중하는 방식을 선호하지만, 여기서 말하는 “훌륭한 개발자”는 도구 선택 면에서는 꽤 일차원적일 가능성이 큼
    • 먼저 거시적 수준에서 생각하고, 마인드맵과 다이어그램으로 연결과 구조를 정리함
      나이가 들수록 미시적 결정보다 아키텍처가 중요하다는 점이 너무 분명해짐
      미시적인 것은 최적화할 수 있지만, 거시적 결정은 대개 영구적임
    • 이게 TDD를 쓰는 이유라고 늘 생각했음
      테스트 안에서 코드를 설계하고 구현을 어느 정도 이끌게 하는 경우가 많음
      머릿속에서 최종 결과를 상상한 뒤, 시스템에 좋은 API라고 생각되는 형태로 테스트를 쓰고 거기서 출발함
      결과적으로 코드는 기본적으로 테스트 가능해지고, Red → Green → Refactor를 여러 번 돌면서 만족스러운 상태에 도달함
      다른 사람들도 이렇게 일하는지 궁금함

  • Jonathan E. Steinhart의 책 “The Secret Life of Programs”에 나온 설명이 가장 좋았음
    컴퓨터 프로그래밍은 두 단계라는 내용임: 1. 우주를 이해한다 2. 세 살 아이에게 설명한다
    자신이 이해하지 못하는 일을 하는 프로그램은 쓸 수 없고, 맞춤법 규칙을 모르면 맞춤법 검사기를 만들 수 없으며, 물리를 모르면 좋은 액션 비디오 게임을 만들기 어렵다는 뜻임
    좋은 프로그래머가 되려면 다른 모든 것에 대해 가능한 한 많이 배워야 하고, 문제의 해법은 예상치 못한 곳에서 자주 나오므로 당장 관련 없어 보인다고 무시하면 안 됨
    두 번째 단계는 세 살 아이처럼 세상을 매우 엄격하게 보는 기계에게 아는 것을 설명하는 일임
    아이에게 “신발 어디 있어?”라고 물으면 “저기”라고 답할 수 있는데, 질문에는 답했지만 사실 신발을 신고 나가자는 의도를 추론하지 못한 것임
    아이들은 자라며 유연성과 추론 능력을 배우지만, 컴퓨터는 Peter Pan처럼 절대 자라지 않음

    • 비슷한 책 추천이 더 있는지 궁금함
    • 프로그래밍은 대부분 생각이지만, 생각하는 방식은 여러 가지가 있음
      사람과 문제마다 맞는 사고 방식이 다르고, 여러 방식으로 생각하고 프로그래밍하는 법을 배우면 선택할 도구가 늘어남
      그래서 프로그래밍이 반드시 한 가지 올바른 방식으로 일어나야 한다는 식의 주장은 마음에 들지 않음
      “자신이 이해하지 못하는 것을 프로그램으로 쓸 수 없다”는 말도 사실이 아니며, 어떤 것이 실제로 어떻게 동작하는지 이해하기 위해 소프트웨어를 쓰는 경우가 많음
      물리 모델링도 현실에 대한 완전한 충실성이 목표가 아니라 게임의 사용자 경험과 난이도 사이 균형을 찾는 탐색일 때가 많음
      프로그래밍은 탐색적 인지 도구가 될 수 있고, 대부분의 생각이 항상 먼저 와야 한다는 뜻은 아님
      제너럴리스트나 독학자를 좋아하지만, 좋은 프로그래머가 되기 위한 필수 첫 단계는 아님
      아이들이 “엄격한 세계관”을 가졌다기보다는 사회적 함의를 항상 추론하지 못하는 것이고, 컴퓨터도 알려진 사실에서 논리적 결론을 도출하도록 프로그래밍될 수 있음
      여러 나이의 아이들, 세 살 아이에게도 무언가를 설명해봤지만, 그 경험은 컴퓨터 프로그래밍과 전혀 비슷하지 않았음

  • 이 수치가 사실상 맞다고 꽤 자신하지만, 아직 어느 회사도 이 실험을 증명하거나 반박하려고 하루치 작업을 통째로 지우는 데 동의하지 않았음
    예전에 훨씬 더 참을성이 많았던 시절, 매일 밤 모든 코드 변경을 검토하고 마음에 안 드는 것은 삭제하는 상사가 있었음
    그 상사는 버전 관리가 과하게 복잡하다고 믿어서, 자기 집의 네트워크 드라이브에 원격 접속하는 방식을 회사 표준으로 삼으려 했음
    그래서 가끔 다음 날 출근하면 전날 작업이 지워져 있었고, 결국 몰래 SVN을 설치하기 전까지는 전날 작업을 다시 만드는 데 아주 능숙해졌음
    엣지 케이스 테스트까지 포함해도 한 시간 넘게 걸리는 일이 드물었음

    • 표본은 작지만 첫 임베디드 직장 2곳 중 2곳 모두 네트워크 공유와 복사·붙여넣기로 코드를 버전 관리했음
      첫 직장에서 일종의 트라우마가 생겨 두 번째 직장에서는 바로 Git 저장소가 있냐고 물었는데, 상사는 Git을 Github과 같은 것으로 생각하고 코드를 공개하고 싶지 않다고 답했음
      나중에 더 큰 회사에 인수되며 인트라넷 접근권이 생겼고, 그 안에서 GitLab 인스턴스를 찾아 대부분 혼자 작업하던 내 코드를 거기에 버전 관리하고 문서화했으며 GitLab Runner까지 설치함
      코드 실행 방법도 단계별로 문서화해뒀고, 해고될 때 코드를 넘기라기에 전부 보여주고 재현 방법을 알려줬더니 상사가 꽤 감명받고 고맙다고 했음
      형편없는 직장에서 내가 옳다고 생각한 방식대로 밀어붙인 덕분에 약간은 좋은 영향을 남겼을지도 모름
      그 GitLab을 찾기 전에는 네트워크 공유에 원시 Git 저장소를 만들고 거기로 푸시했음
    • 나쁜 상사였는지 선승이었는지는 끝내 알 수 없음
    • 더 큰 문제는 관리자가 코드에 개입한다는 점임
      좋은 의도로 하더라도 관리자가 코드나 리뷰에 관여하면 거의 항상 팀에 순손실이 됨
    • 2000년대와 2010년대에 Microsoft Office 제품을 진지하게 써본 사람이라면 이게 사실임을 알거나, 5~10분마다 반사적으로 저장을 누르게 됨
    • 두 번째로 다시 만든 작업이 더 나았는지 나빴는지 궁금함

  • 비프로그래머에게 보내기 좋은 글임
    프로그래머에게 도메인 지식이 필요하듯, 프로그래머에게 무언가를 얻어내려는 사람도 프로그래밍을 조금은 이해해야 함
    아주 작은 diff라도 디버깅, 설계, 학습 때문에 몇 시간이 걸릴 수 있음
    산출물의 양만 보고 감흥을 못 느끼기는 쉽지만, 누군가에게 설명을 듣는 것과 스스로 몇 시간 동안 벽에 머리를 박으며 알아내는 것은 완전히 다름

    • 내가 낸 가장 작은 코드 조각들이 대개 가장 오래 걸렸고, 가장 큰 영향을 줬으며, 이해하고 나면 가장 만족스러웠음
      성능을 100배 개선하는 한 줄 커밋을 찾는 데 며칠이 걸리고, 동시에 동기화 회의에서는 왜 티켓이 움직이지 않는지 설명해야 하는 식임

  • 그래서 도메인 지식이 핵심임
    금융 분야에서 일하며 트레이딩 데스크에 앉아 여러 거래소를 보고, 이런저런 전략을 구현하는 코드를 작성해왔음
    비즈니스가 무엇을 해야 하는지 모르면 컴퓨터가 무엇을 해야 하는지도 생각할 수 없음
    이 관점에서는 코더를 번역가처럼 훈련하는 것이 말이 될 수 있음
    내 번역가 친구는 여러 언어의 문법과 관용구를 잘 알고 새 언어도 우리가 새 프로그래밍 언어를 배우듯 익히지만, 제약 산업에 대해서도 상당한 시간을 들여 배웠고 이제 의료 문서를 번역함
    변호사와 회계사도 언어 장벽이 있는 직업임
    전문가가 되면 법, 회계, 소프트웨어의 언어를 배우지만, 좋은 전문가는 전문 언어가 아니라 비즈니스 언어로 답을 줌
    덜 좋은 변호사는 법률 용어로 가능한 모든 결과를 말해주고 결정은 맡기지만, 좋은 변호사는 사소한 가능성은 많아도 실무상 같은 위치의 고객들은 이 비즈니스 목표 때문에 모두 X를 한다고 말해줌
    첫 트레이딩 직장에서는 한 트레이더가 Excel VBA 모듈을 만들어 종목을 훑어 거래 대상을 찾는 절차를 돌리고 있었음
    버전 관리 없이 디스크에 저장된 파일뿐이었는데, 새로 온 사람이 몇 주 안 돼 그 VBA 모듈 전체를 지운 채 저장해버렸고 백업도 IT의 도움도 없었음
    그 트레이더는 얼굴이 빨개졌다가 진정한 뒤, 어차피 백업이 있어야 했고 VBA로 뭘 하고 있었냐는 현실을 받아들이고 앉아서 80년대 터미널 화면이 한 글자씩 찍히듯 전체를 다시 타이핑해냈음

    • 잘 아는 도메인과 새로운 도메인에서 개발하는 것은 큰 차이가 있음
      좋은 해법을 만들려면 먼저 그 도메인에서 경험이 있어야 한다는 게 내 신조임
      지금은 새 도메인 경험을 얻기 위해 대부분의 시간을 쓰고 있고, 필요한 지식을 빨리 쌓으려고 도메인 전문가 옆에 앉아 있음
    • 소프트웨어 엔지니어이면서 CPA인 경험상, 회사들은 대체로 그런 도메인 지식을 크게 신경 쓰지 않음
      내 배경 같은 사람보다 회계 관련 소프트웨어를 15년 만든 소프트웨어 엔지니어를 선호하고, 그 사람을 회계사와 30분 대화시키는 쪽을 택함
    • 프로그래밍은 너무 넓은 분야라 전체에 적용되는 일반화를 하기가 매우 어려움
      프로그래밍이 반드시 어떤 한 방식으로 작동해야 한다는 처방이 반복해서 보이지만, 하위 분야마다 작업 유형이 크게 다름
      모든 분야에 적용되는 완벽한 단일 방법론을 배우거나 가르치려 하기보다, 여러 접근법과 방법론을 담은 도구가방과 각각이 잘 맞는 상황을 이해하는 편이 낫다고 봄
    • 맞지만, 우리나라의 모든 회사에는 경업 금지 조항이 있어서 도메인 지식을 배워도 현재 고용주가 해고하면 다음 직장에 옮겨 쓸 수 없음
      그래서 산업을 넘나들며 이전 가능한 일반 프로그래밍 기술에 집중하게 됨

  • Bjarne의 PPP 책[0] 초반에도 비슷하게 나옴
    “최고의 프로그래머들조차, 특히 최고의 프로그래머들은 대부분의 시간을 코드 작성이 아니라 문제 이해에 쓴다. 문제 이해에는 진지한 시간이 들고 상당한 지적 노력이 필요한 경우가 많다. 많은 프로그래머가 프로그래밍이 흥미롭다고 말할 때 가리키는 지적 도전이 바로 그것이다”라는 취지임
    최근 첫 페이지에 올라왔던[2] 새 판[1]도 샀음
    [0]: https://www.stroustrup.com/PPP2e_Ch01.pdf
    [1]: https://www.stroustrup.com/programming.html
    [2]: https://news.ycombinator.com/item?id=40086779

    • 대체로 맞지만, 가장 큰 문제는 같은 논쟁을 계속 반복하는 데 시간을 쓴다는 느낌임
      어떤 데이터베이스를 쓸지, 어떤 언어가 최고인지, 코드와 데이터베이스에서 null을 허용할지, API 형식, 로그 형식 같은 것들임
      특별히 흥미롭지도 않고 가끔 재검토할 필요는 있지만, 최근 세 회사에서 겪은 이런 시간 소모는 대부분 이미 해결됐어야 할 문제처럼 느껴짐
      사실 회사가 강한 사고방식을 갖고 있으면 설령 의심스러워도 훨씬 생산적일 수 있음
      Perl, MongoDB, CGI를 쓴다고 못박혀 있었다면, 그 스택에도 불구하고 최근보다 더 생산적이었을 것 같음
    • 가장 어려운 부분은 쓰기 전 설계 단계든, 프로토타입이나 이전 반복에서 배운 뒤든 무엇을 코딩하지 않을지 알아내는 것임
    • *Bjarne

  • “프로그래밍은 대부분 생각이다”는 깊은 진리처럼 스스로에게 말하는 문장 중 하나지만, 관찰로서는 별로 생산적이지 않음
    프로그래밍이 생각이라는 점은 모든 지식 노동이 생각인 것과 정확히 같은 의미임
    디자인도 대부분 생각이고, 회계도 대부분 생각이며, 관리도 대체로 생각임
    의미 있는 차이는 생각 자체가 아니라 무엇에 대해 생각하느냐임
    관리자는 사람 문제를 디버깅해야 하므로 사람들과 많은 시간, 즉 회의가 필요함
    개발자는 컴퓨터 문제를 디버깅하므로 컴퓨터와 많은 시간이 필요함
    여기에 분명한 긴장이 있고 어느 극단도 통하지 않으니, 서로의 업무를 덜 방해하도록 균형을 찾아야 함

    • 이 글은 프로그래머가 아니라, 프로그래밍이 대부분 타이핑이라고 생각하는 관리자 같은 비프로그래머를 위한 글이고, 우리가 타이핑하지 않을 때 무슨 일이 일어나는지 설명하는 글임
    • 예전 박사과정 교수는 단축키와 매크로를 외우지 않고 일하면 손을 키보드에서 떼는 데 하루에 얼마나 많은 시간을 잃는지 끝없이 말했는데, 그것보다는 훨씬 생산적인 관찰임
    • 프로그래밍에서 중요한 차이 하나는 같은 일을 더 적은 코드로 하는 편이 나은 경우가 많다는 점임
      난해한 코드 골프식 코드를 말하는 게 아니라, 생산한 모든 것을 유지보수해야 한다는 측면임
      유지보수에는 별 관심이 없고 텍스트가 만들어내는 감정에 더 신경 쓸 소설가와는 분명히 다름

  • “직무 중 학습을 실험해 사고가 최적화되는 시스템을 만들려면?”에 대한 최고의 최적화는 방해를 줄이는 것임
    연구에 따르면 방해는 프로그래밍에 파괴적인 영향을 줌
    방해 뒤 업무 재개에 10~15분이 걸리고, 프로그래머가 하루에 얻는 방해 없는 2시간짜리 세션은 하나뿐일 가능성이 높으며, 편집·검색·이해 중인 때가 방해하기 최악의 시점임
    이런 방해를 추적해 보여줄 방법이 있는지 궁금함
    [0] http://blog.ninlabs.com/2013/01/programmer-interrupted/

    • 관리자에게 1시간짜리 회의를 6시간에 걸쳐 10분씩 나눠 하자고 하면 정말 이상한 표정을 볼 수 있음
      그런데 개발자들은 끝없는 회의, Slack/Zoom의 짧은 핑과 동기화 사이에서 몇 시간짜리 코딩 작업을 끝내야 한다고 기대받음
      가끔 주말에 집에서 일해야 했을 때, 방해 없는 주말의 작업 품질이 정신없는 평일보다 훨씬 낫다는 걸 봤음
    • 그래서 80%는 밤에 일함
      모두에게 맞지도 않고 모든 경우에 맞지도 않으며, 나머지 20%는 낮에 일하는 사람들과의 조율이지만, 몇 시간씩 이어지는 좋은 무방해 세션에서 나오는 생산성은 비교가 안 됨
      다시 말하지만 모두에게, 아마 대부분에게 맞는 방식은 아님
    • 높은 시간 수요와 방해 때문에 재택근무할 때 대략 한 자릿수 배 정도 더 생산적임
      집에서는 아무도 나를 방해하지 않고, 방해가 오더라도 언제 반응할지 스스로 정할 수 있음
      특히 어려운 문제를 다루는데 10~20분마다 방해가 들어오면 그냥 접는 게 낫고, 그렇지 않으면 나중에 두통을 부르는 엉망인 코드를 만들 가능성이 큼
    • 대기업에서 사람들이 시간을 어떻게 쓰는지 추적하는 도구 개발 프로젝트를 이끈 적이 있음
      개인정보를 존중하도록 설계해서 웹브라우저를 사용했다는 사실은 기록하지만, 사내 인트라넷인지 fb.com인지 같은 구체 URL은 기록하지 않았음
      가끔 팝업으로 사용자가 스스로 생산성을 평가하고 자유 텍스트로 코멘트를 남기게 했으며, 사람들이 초인처럼 보이려고 거짓말하지 않도록 사용자 ID와 연결하지 않았음
      Windows 프런트엔드와 Scala 백엔드를 만들고 개발자, 변호사, 재무 담당자를 포함한 자원자 그룹에 배포했지만, 첫 데이터 분석 뒤 흥미로워지던 시점에 시간과 예산이 떨어져 논문으로 내지는 못했음
      Rescue Time( https://www.rescuetime.com/
      ) 같은 기존 도구도 봤지만, 내부 생산성 데이터를 외부 클라우드에 저장하는 것은 받아들일 수 없다고 판단했음

  • 좋은 프로그래밍은 때로 대부분 생각이지만, “어떤 계획도 적과 처음 접촉한 뒤에는 살아남지 못한다”는 말이 맞음
    실용적인 프로그래밍은 계획과 IDE에 코드를 올려보는 일의 신중한 조합이고, 그 균형은 사용 사례에 맞춰 바뀌어야 함

    • 프로그래밍은 단순한 생각이 아니라 대부분 정찰임
      며칠 동안 코드를 쓰지 않는다면 문제 표면을 완전히 알고 있거나 그냥 추측 중인 것임
      후자라면 생각할 거리가 그리 많지 않음
    • IDE로 첫 실행을 해보는 것은 게임 레벨을 처음 깨는 것과 비슷함
      두 번째는 더 빨라짐
      생각을 “도구의 도움을 받는 사고”로 확장할 수 있다는 데 동의함

  • Peter Naur의 Programming as Theory Building을 반복한 표현이고, 내가 프로그래밍의 본질을 이해하는 데 결정적이었음
    프로그래밍은 프로그램 자체를 만들어내는 일이 아니라, 세상의 일에 대한 특정한 통찰을 형성하는 일이며, 최종적으로 출력되는 코드는 자신이 구축한 이론의 단순한 표현일 뿐임

답변달기