# 내가 직접 관찰하고 발견한, 조직 내에서 프로그래밍을 가장 잘하는 사람들의 특징들 "실력이 기본이 되어야 신뢰가 쌓이거든요." https://youtu.be/tK0_wQxDkVA?t=773

# 내가 직접 관찰하고 발견한, 조직 내에서 프로그래밍을 가장 잘하는 사람들의 특징들 "실력이 기본이 되어야 신뢰가 쌓이거든요." https://youtu.be/tK0_wQxDkVA?t=773 > 오늘 제가 제 롤모델로 여기고 일하는 직장 상사와 회의 직후, 제 6년의 짧지 않은 개발 경험을 돌아보면서 어떻게 하면 프로그래밍을 더 잘할 수 있을까를 고민하며 이 글을 작성해보았습니다. 경력에 비해 실력이 부족하니 제가 더 노력할 문제입니다. 1. 단축키 활용 (겁나 집착적으로 활용) 자주 쓰는 기능에 대해서는 단축키를 "반드시" 활용한다. 마우스로 이곳저곳을 누르며 동선을 낭비하지 않는다. 2. CLI > GUI (겁나 집착적으로 활용) GUI(Graphical User Interface)보다는 CLI(Command Line Interface)를 선호한다. 실력이 더 좋을 수록 이 경향이 더 심해진다. 3. 단기보다는 장기적으로 더 이득이 되는 선택을 한다 단기적으로 이득이 되는 선택보다는 장기적으로 이득이 되는 선택을 한다. 타자를 배운다고 치면 열 손가락을 모두 활용해서 키보드를 치는 연습을 한다. 독수리 타법이나 불완전한 열 손가락 활용이 길이 들면 나중에 고치는 것이 거의 불가능해진다. 그 전환 비용을 없애거나 줄이기 위한 더 현명한 선택은 장기적으로 더 이득이 되는 선택을 하는 것이다. 기술에 대해서도 당장 실무에 활용하는 지식보다 그 근간이 되는 지식을 먼저 습득한 뒤, 추후 시간을 더 창의적이나 생산적인 방향의 활동에 투자하는 것을 선호한다. 4. 까탈스러움(picky)/눈이 높다 문제 분석에 있어서 기술적으로 본인이 그렇다고 믿는 바가 있으면 절대 그냥 넘어가는 일이 없다. 반증을 들지 않으면 믿음을 회수하지 않으며, 뭐든 뭉뚱그리고 넘어가는 법이 없다. 나는 개발 경력이 6년차가 넘어가는데도 뭉뚱그리는 경향이 심한 편이다(물론 연차 따위 실력과 무관하다. 실력이 좋으면 전문가고 아니면 아마추어다). 최근의 나는 이를 교정하려고 얘쓰고 있다. 5. 코드 리뷰에서 요구되는 수준이 높다 코드 리뷰의 수위가 높은 편이다. 실력이 더 좋을 수록 이 경향이 심해진다. 개인적으로는 내 기회비용으로서 내 실력이 크게 늘지 않았던 데에는 개발 속도를 강조하고 코드 리뷰의 벽이 낮고 코드 리뷰에서 요구되는 수준이 낮았던 것이 결정적인 영향을 준 것으로 판단하고 있다. 6. 근거 기반 사고 가끔은 내가 문제에 몰입하다 보면 그 잘하는 사람(전문가)이 실수한 부분을 찾아내기도 하는데, 그런 경우에 내가 근거를 들이밀면 결국에는 인정한다. 7. 오늘 업무를 내일로 미루지 않는다 1시간만에 할 수 있으면 1시간만에 끝낸다. 업무를 질질 끌지 않는다. 문제를 분석하고 딱 정의했던 문제의 명세대로 문제를 해결해나간다. 더할 것도 덜할 것도 없다. 문제를 뭉뚱그리고 엉뚱한 곳에서 시간을 낭비하는 정도가 덜하다. 이것 역시 내가 갖추지 못한 특징이기 때문에 해당 전문가를 보며 배우려고 애쓰고 있다. 결국, 한 마디로 본인에게 강제하는 눈높이(기준)을 높이지 않으면 실력이 정체되거나 후져지고, 본인에게 강제하는 눈높이(기준)를 높이면 실력이 좋아진다. 지난 3년 동안 프로젝트 속도에 내 숙련도를 갈아넣으면서 내 실력이 구려졌다고 생각했는데 확실히 맞았다. 높은 기준을 갖고 일하는 전문가를 만나니까 옷매무새를 고치게 된다. 망하는 조직은 결국 썩어빠진 정신을 가진 조직 내의 누군가가 만든다. 언제나 사람이 문제다.