근래에 Medium이라는 플랫폼을 구독중이다.
기술 및 삶의 전반적인 부분에 대해서 토픽을 골라서 구독이 가능한데,
내가 관심있는 토픽과 관련된 글들에 대해 매일 아침 이메일로 전송이 된다.
그 중에 나와 같은 배경을 가지고 있는 재밌는 필자의 글이 있어서 번역하면서 요약을 해보고자 한다.
복사, 붙여넣기 개발자의 고백
개발 경력 내내 코드 복사붙여넣기로 살아남았다. 일했던 모든 팀에서 더 똑똑한 개발자들이 하는 일을 관찰하고 그들을 따라 했다. 정말 천재일지도 모른다고 생각되는 놀라운 개발자들과 함께 일했으며, 그들 각자로부터 조금씩 노하우를 가져와서 자신의 경력을 가속화했다. 이러한 인물들에게서 배운 교훈들이 평범함에서 자신을 구원하고 다른 개발자들에게도 도움이 될 수 있다고 말한다. 좋은 것을 경험하기 전까지는 무엇이 나쁜지 인지하기 어렵다고 느낀다.
이런 슈퍼스타 개발자들을 만나기 전에는 30대에(ㅎㅎ) 코딩을 배운 후 고용된 사실에 행복했으며 해고당하지 않는 것이 주된 목표였다. 평균적인 개발자가 되는 것을 목표로 삼았지만 그것조차 미치지 못했다. 부족한 개발자들이 흔히 하는 말들
•
"제 환경에서는 작동합니다,"
•
"어떻게 작동하는지 몰라요, 그냥 돼요. 건드리지 마세요."
•
"저는 코드만 씁니다. 비즈니스가 어떻게 돌아가는지는 몰라요,"
•
"보기엔 괜찮네요!"
이 모든 말들을 자신도 했다. 특히 마지막 말 때문에 해고당할 뻔한 적도 있었다.
가장 똑똑한 개발자들로부터 배운 3가지 핵심 교훈이 있다.
첫 번째: 일을 올바르게 해내는 것과 완수하는 것 사이의 균형을 잡자.
첫 번째는 Don이라는 천재 개발자로부터 배운 것이다.
그는 테스트 코드를 전혀 써본 적이 없던 자신에게 테스트 작성을 가르쳤고, 도구를 효율적으로 사용하기 위한 키보드 단축키의 중요성을 알려주었으며, 테스트가 없는 기능은 절대 받아들이지 않았다.
또한, 도움을 요청했을 때 바로 답을 주기보다 문제의 근본 원인을 찾을 방향을 제시해주었다.
그와의 9개월간의 작업은 경력에 가장 큰 영향을 미쳤으며, 테스트 작성 기술, 도구 학습의 중요성, 일을 올바르게 해내는 것과 완수하는 것 사이의 균형을 배웠다.
두 번째: 꼼꼼한 코드리뷰를 하자.
두 번째는 Parker라는 코드 리뷰를 철저히 하는 사람에게서 배운 것이다.
이전에는 코드 리뷰를 마치 우편 사무실 직원처럼 "보기엔 괜찮네요!"라고 형식적으로 승인했다.
이는 팀에 시니어 개발자들이 많아 스스로 잘 검토했을 것이라 믿었기 때문이었다.
어느 날 Parker에게서 명백한 오류가 있는 시니어의 코드를 승인한 것을 지적받고는 고통스럽고 부끄러움을 느꼈다.
최소한의 것도 하지 못해 앱을 망가뜨릴 뻔했다는 것을 깨달았다.
이 일 이후 사과하고 팀에서 두 번째로 훌륭한 코드 리뷰어가 되겠다고 다짐했다.
Parker의 코드 리뷰 과정은 다음과 같다:
1.
먼저 로컬에서 코드를 실행하고 기능 테스트를 한다.
2.
새 코드를 줄 단위로 살펴본다.
3.
명확하지 않은 부분은 질문하여 이해를 확인한다.
4.
큰 리뷰는 개발자와 만나 코드를 설명하게 한다.
5.
컨텍스트 스위칭을 피하기 위해 오전에 먼저 리뷰를 한다.
이 방법을 따르면서 연말 리뷰에서 여러 팀원들과 매니저로부터 꼼꼼한 코드 리뷰에 대해 칭찬을 받았다.
세 번째, 비즈니스에 도움이 되는 개발을 하자.
세 번째는 James에게서 배운 것이다.
엔지니어링 매니저로서 기술 로드맵을 만들 때, NextJS, TypeScript, Kubernetes 같은 새로운 기술 도입에 들떠 있었지만, James는 "이런 것들을 하는 요점이 뭔가요?", "이것이 분기 비즈니스 목표에 어떻게 도움이 되냐"고 핵심을 찔렀다.
기술은 비즈니스를 지원해야 하고 그렇지 않으면 "그냥 화려한 장식(fancy fluff)"일 뿐이라고 명확히 했다.
이를 통해 비즈니스가 실제로 필요로 하는 것에 맞춰 로드맵을 수정하게 되었다.
비즈니스는 사이트 로드 시간을 200밀리초 줄이는 것보다 다른 흥미로운 도전 과제들을 필요로 했다.
의도는 좋았지만 방향이 잘못되었음을 깨달았다.
결론
결론적으로, 이 세 사람은 경력의 중요한 시점에서 필요한 영웅이었다.
그들의 습관, 프로세스, 사고방식을 많이 받아들이고 자신의 루틴에 적용했으며, 전반적으로 잘 맞았다.
또한, 다른 개발자들에게 빌런(부담이 되거나, 대충 코드를 짜거나, 작업을 오래 끄는 사람)이었을 수도 있음을 인정한다.
"방 안에서 가장 똑똑한 사람이라면, 당신은 잘못된 방에 있는 것이다"라는 말처럼, 이러한 경험을 통해 성장했다.
핵심 교훈 중 하나는 불편함을 쫓아야 한다는 것이다.
자신보다 더 많이 아는 사람들 주변에 머물고 그들을 연구하는 것이 어떤 분야에서든 평균보다 조금 나은 사람이 되는 가장 효율적인 길이라고 생각한다. (테스트를 작성하고, 비즈니스 맥락을 신경 쓰고, 코드 리뷰를 진지하게 하라는 교훈 외에도 말이다).
불편함을 쫓아 성장하는 방향성을 걸어간다는 건 굉장히 어려운 일인 것 같다.
나는 꼼꼼한 성향도 아니고, 그 불편함을 감소하고자 하는 사람도 아닌 것 같다. (영어 했을 때를 제외하고는..)
선천적으로 그렇게 해야 마음이 편한 사람은 아닌 것 같다.
당사자들은 스트레스 받겠지만 가끔 부럽긴하다.
관심이 부족한걸까, 기술이 부족한걸까, 열정이 부족한걸까.. 등 성장이 멈춘 것 같은 느낌에 다양한 고민들을 했던 것 같다.
여러가지 요인이 있겠지만, 2~3달 전부터 인지했던 “꼼꼼함”에 대한 방향성도 불편함을 기꺼이 받아들이겠냐는 취지와 동일한 맥락인 것 같다.
앞으로 업무를 진행하면서도 계속해서 내 자신에게 질문을 해봐야겠다.
“업무를 하면서 귀찮고 불편했는가?”
그렇지 않았다면, 나는 해당 업무를 또 성장의 기회로 삼지 않지 않았을까..
