더 나은 개발자가 되기 위한 습관들, Quora 번역

개발새발로그가 하루가 다르게 맛집 블로그로 변모하고 있는 와중에, 메일로 매일 날아오는 Quora Digest에서 인상 깊은 주제를 보게 되었다. 나 뿐만 아니라 다른 분들에게도 도움이 될 수 있는 내용일 것 같다는 생각에 번역 욕구가 급하게 들어서 이렇게 맛집 포스팅이 아닌 번역글을 남기고자 한다. 당연하게도 본인은 전문적으로 번역하는 사람이 아니므로, 내 맘대로 편하게 옮겨왔다. 내 생각에 중요하지 않다 싶은 것은 옮기지 않은 부분도 있으니, 전문이 궁금하신 분은 아래 링크를 참조하시길. 나는 개발새발에서 언제쯤 벗어나련지

더 나은 개발자가 되기 위한 당신의 습관은?

3.1k upvotes, Jeff Nelson, Invented Chromebook, #Xoogler

내가 꾸준하게 지켜왔던 한 습관이 뭐였냐면, 내가 새로운 개념을 배우는 시점에 작은 프로토타입 프로그램을 짜는 거야. 예를 들어 내가 앉아서 책이나 웹, 강의 등을 통해 공부했다면, 30~40개의 몇 십 줄 되지도 않는 작은 프로그램을 짜보는 거지. 프로그램 하나 하나 마다 간단한 개념을 구현하는 거야. 이렇게 하면 단 기간에 많은 개념을 쉽게 익혀나갈 수 있어.

604 upvotes, Ed Prentice, Software Engineer

혁신은 상품화에서 온다. 저장소가 상품이 되니, 아마존의 유연한 저장소 서비스가 잘 팔렸어. 빠른 인터넷이 상품이 되니, 넷플릭스의 on-demand 서비스가 잘 나갔지. (on-demand service: 이용자의 요구에 따라 네트워크를 통해 필요한 정보를 제공하는 방식) 당신의 시간은 중요해. 최대한 아끼자고. 모든 것을 자동화 시키는 거야. 그래서 당신의 시간이 상품화되는 순간이 오면, 당신은 대단한 혁신을 얻을 수 있을 거야.

1. (vim과 같은) 강력한 IDE를 사용하고 당신에게 딱 맞게 설정해. Build/Test/Deploy/Run를 수행하는 하나의 명령어를 위해 노력하라고.
   
   
2. 만약 당신이 무언가 반복적으로 같은 일을 하고 있다면, 원클릭으로 그 일을 수행할 수 있도록 만들어. 알아서 돌아가도록 하면 더 좋고.
   
   
3. 각종 단축키, Unix 명령어를 숙지해둬. 대부분의 IDE라면 당신의 복잡한 build 명령어나 터미널 명령어를 실행시켜 줄 수 있어. (단축키, UNIX 명령어와 IDE가 합쳐진) 이렇게 강력해진 것들이 당신의 시간을 엄청나게 절약 시켜줄거야.
   
   
4. 질문을 던져야 해. 그리고 나서는 더 많은 질문을 던져야 하지. 당신이 이해하기 어려운 일이 벌어졌다면, 왜 그런 건지 생각해봐야 해. 그리고는 도대체 이게 어떻게 이 지경이 된 건지 알아야 하지. 그제야 이딴 것은 집어 치우고 대안을 찾아서 제안할 수 있어. "이건 왜 그런 거죠?"라고 묻는 신참에게 완벽하게 설명해줄 수 있을 때까지 스스로에게 질문하라구. 난 꽤 자주 놀라는 게, 많은 개발자들이 "이건 원래 이렇게 해왔어" 라는 식으로 치부해버린다는 거야.
   
   
5. 현재 상황에 도전해서 더 좋은 대안을 제시해봐, 그리고 그것을 직접 개발하면서 스스로 발전하는 거지. 만약 당신의 테스트 코드가 부족하다면? 또는 테스트 코드가 하루/일주일에 고작 한 번 씩 돌아간다면? 당신 스스로 local CI 전문가가 돼보는 거야. 테스트 코드의 중요성을 당신의 팀에게 전파하고, 당신이 개발해. 만약 당신이 그렇게 해서 스스로의 작업을 향상 시킨다면 당신의 팀도 따라올 거야.
   
   
6. 동료들 말고 스스로와 경쟁해. 웹앱을 만들어본 적이 없나? 만들어 봐. Python 안해봤어? 그걸로 드론 납치도 할 수 있다고.
   
   
7. 온전히 당신 소유의 것이 있어야 해. 굳이 프로젝트일 필요는 없어. 당신만의 행사(meet up, hackathon 등)를 열어도 좋고, 게임이나 웹사이트, 블로그도 좋지.
   
   
8. 뭔가를 가르치는 것이 도움이 돼. Java, public speaking, writing, chess, vim, tennis.
   
   
9. 훌륭함의 선봉이 되고자 노력해. class/component 중에 쪼까 구린 부분이 있다? 바로 고쳐. 당장 작업을 하면 되지. 당신의 코딩을 대충 하지마. 똑똑한 결정을 내리고, 그 결정의 장단점을 분석해서 그렇게 결정을 내린 이유를 증명해야해. 꾸준히 당신의 코드를 향상 시킬 생각을 하라구. 한 시간 정도면 해결할 수 있는 TODO를 적어 놓느니 바로 해치워버려.
   
   
10. Stack Exchange 사이트에서 당신이 자신 있는 주제(프로그래밍 언어라든지)로 슥 훑어봐. 그러다가 당신이 모르는 것이 나왔다면 최대한 빨리 당신의 지식을 다 뒤엎어버리고 새로 배우는 거야. C 좀 하나? branch prediction이 뭔지 아나? 여기서 알려 줄 거야, 배우라구.
    
    
11. Stack Exchange에서 당신이 익숙하지 않은 주제들도 훑어봐, Everyday's a school day.
    
    
12. 소통하는 법도 배우는 거야. 글, 발표, 문제 풀이, 작지만 강렬한 프로젝트, 크고 작은 여러 규모의 팀 등 모든 게 소통이지.
    
    
13. 당신이 하는 모든 것을 문서화해야 해. "왜 내가 이 일을 했었지?"에 대한 대답을 찾아볼 수 있고, 비슷한 문제에 직면했다면 과거의 솔루션을 찾아볼 수 있지. 당신 생각의 과정을 기록하고, 잊어버리기 쉬운 매우 중요한 키 정보들을 저장해두는 거지. 나도 자주 내 다이어리에서 지난 작업들을 휙휙 돌아본다고.
    
    
14. 코딩하기 전에 먼저 구상하고 문서로 만들어. system diagrams, class hierarchies, flow charts 등을 사용해서 당신의 코드가 어떻게 작동하는 지 보여줘봐. 만약 사람들이 다른 생각이 있다면 (그리고 그렇게 다르게 하길 원한다면) 실제로 이미 코딩을 했을 때보다 훨씬 가볍게 계획을 바꿀 수 있지. 내가 보기에 얼척없이 멍청한 생각을 하는 사람들은 거의 없었어, 쉽게 무시할 만한 생각은 없지.
    
    
15. 구체적으로 일해. 그니까 당신의 새로운 작업을 위해 도표를 제작해서 모두에게 보여주고 최대한 자세하게 설명을 해주는 거야. 모든 사람이 당신의 도표에 동의하는지 확실하게 하라고. 만약 누군가 당신의 도표에 손을 대고 싶어한다면 그 내용도 추가하거나 알맞게 수정해서 항상 최신의 도표를 유지해두는 것이 좋아.
    
    
16. 무의식적인 편견과 남성 특권에 대해 알아둘 필요가 있어. MBTI를 파악해서 당신이 어떤 성향의 사람인지를 아는 것도 중요하지만, 어떤 성향의 사람과 잘 맞는지를 조사해두는 것이 더 중요해. 감성 지능이 뭔지도 알아둬. (타인의 감정을 이해 및 수용하고 자기 감정을 조절하는 능력) 한 사람 한 사람이 모두 당신과 다르기 때문에 어떻게 그 사람과의 원활한 관계를 유지할 수 있을 지 연구해야 하지.
    
    
17. 정규적으로 팀을 위해 뭔가 해. 쿠키를 가져오던지, 마술을 알려주던지. 팀 문화라는 것을 세우고, 동료들도 같이 세울 수 있도록 독려하는 거지. 팀원의 공헌을 높이 사주고 헐뜯을 생각일랑 마. 결속이 잘된 팀은 막을 수가 없다고.
    
    
18. 사람들과 함께 일하는 법을 배워야 해. 난 개인적으로 이 글을 매우 재밌게 읽었어.
    
    
19. 다른 사람들의 코드를 이해하고 사용해봐. 지금 당신이 xml parser, csv parser, git hook 이런 거를 직접 만들고 있다면, 뭔가 잘못 생각하고 있을 가능성이 높아.
    
    
20. 당신이 코드를 다 짰고, 문제 없이 작동했고, 테스트 케이스도 모두 통과 했다면? 처음으로 돌아가서 다시 한 번 살펴보고 마무리 해. 테스트도 다시 한 번 돌려보고 말이지. 근데 조금 더 마무리를 할 수 있어. 당신이 놓쳤을 가능성이 높은 것들을 알려주지. class 하나는 한 구역의 책임을 지고, 하나의 함수는 한 가지 일만 해야 하는 건 알고 있겠지. 함수는 웬만하면 20라인을 넘지 않는 게 좋아. 스스로 잘 표현할 수 있는 naming을 했겠지? 마지막에 철저한 재 검사는 당신과 당신의 팀에게 10배의 보상을 줄 거야.
    
    
21. 참여해! 책임을 지는 것을 두려워 하지마. 뭔가가 별로면 당신이 고치면 돼. 마감 시한이 다가오고 있다면, 해결책을 제시하고 동료들도 현 상황을 인지하게 해줘. 신입 개발자라도 할 수 있는 일이야. 책임을 지고 참여한다는 것은 프로젝트의 큰 그림과 방향을 이해하고 있어야 할 수 있는 일이야. 마감 일도 알고 있어야 마감 일이 다가오고 있는 걸 알겠지? 다시 말하지만, 참여해서 시간을 아끼자구!
    
    
22. 적당한 때에 당신이 배운 것들을 팀과 공유하는 것이 좋아. Java의 finally block 안에서 exception을 던지면 세상 어떤 일이 벌어지는게 알게됐나? 나에게도 알려줘.
    

346 upvotes, Jeff Standen, programmer for 23+ years, creator of Cerb

1. Spike 먼저 해보는 것.
   
   이 습관은 내가 Agile/eXtreme programming을 접하게 된 초기에 어려움을 겪으며 생긴 습관이야. Spike solution은 제대로 요건에 맞춰서 일을 시작하기 전에 내가 제대로 이해하고 있는 것이 맞는지 확인하기 위해 일회용 프로토타입을 만드는 것을 얘기해.
   
   근데 이건 일반적인 프로토타입과는 조금 다른 의미를 가지고 있어. 당신이 공부하면서 해낸 spike solution은 결국엔 버려야 한다는 점이야. 상용 레벨에서 쓰이지 않을 코드이고 검토 받지 않아도 되기 때문에 당신은 자유롭게 지름길을 택하고 빠르게 이것 저것 해볼 수 있지. 현재 구상의 어느 부분이 제대로 파악이 안 됐는지를 디자인/아키텍쳐 결정을 해버리기 전에 점검할 수 있다는 점에서도 많은 도움이 돼.
   
   
2. 논리에 맞는, 의미가 있는 잘게 쪼개진 commit 단위.
   
   CVS나 Subversion을 쓰던 때는 파일의 부분적인 commit을 한다는 것은 매우 어려운 일이었어. 근데 Git이 등장하면서 거대한 파일의 고작 몇 줄만 commit하는 일이 겁나게 쉬운 일이 되어버렸지. remote repository에 push 하기 전에 local에서 rebase나 merge 하는 것도 말이야. 큰 기능을 만드는 과정을 작은 단위의 commit으로 축적할 수 있게 되면서, 나의 업무 생산성은 하늘 높이 폭발해버렸어! 작은 단위의 commit이 나의 뇌 건강을 지켜주어서 더 중요한 것들을 생각할 수 있었지.
   
   
3. 항상 코딩하기.
   
   최근까지 나는 웹 기반의 기업 협업 및 자동화 플랫폼 (PHP/MySQL), 클라우드 기반의 실시간 지표 수집기와 round-robin hash를 이용한 API (Node.js/Redis), iOS 보드 게임 (Swift/SpriteKit), 웹 기반 SaaS를 위한 특별한 URL 기반의 cronjob 비슷한 대체재 (Java)를 만들었어. 수 많은 framework와 프로그래밍 언어를 다루는 것은 추상적으로, 그리고 알고리즘적으로 생각할 수 있게 하는 데 도움을 줘. 그리고 PHP 프로젝트를 하면서 Eclipse RCP, Tapestry, Hibernate 같은 도구들을 사용하면서 많은 것을 배웠어. Java같은 기업 레벨 IT환경이 PHP에서는 갖춰지지 못했었던 2000년대 초반에 특히 그랬었지. Unity/C#으로 네트워킹과 메세지 지향적인 구조에 대해서도 많이 배웠었어.
   
   내가 한 가지 플랫폼에만 붙어있었다면 앞서 말했던 것들을 나는 알지 못했을 거야.
   
   
4. 간단한 코드를 짜는 것.
   
   예전의 나는 스스로 도전하는 정신으로 코딩에 많은 공을 들였었어. 지금은 우아하지만 간결한 코드 (모두가 그 코드를 보면 "아 나도 이렇게 할 수 있는 건데"라고 생각이 들 수 있는? 설사 그럴 능력이 없는 사람이라도 말이야)를 짜기 위해 도전하고 있지. 간단함은 복잡한 노력이 반복되면서 나오는 엑기스 같아. Antoine de Saint Exupéry가 한 말이 있지. "더 이상 추가할 것이 없을 때가 아니라 더 이상 뺄 것이 없을 때, 완벽함을 성취한다고 볼 수 있다." 간결한 코드는 오랫 동안 돌보지 못했던 프로젝트라도 금방 파악하게 해주고, 다른 사람들도 참여할 수 있게 해주지.
   
   
5. 최적화는 나중에.
   
   다른 사람들에게 똑똑하게 보이기 위해 성급한 코드 최적화를 하는 실수를 범하기 쉬워. 파레토 원리를 생각해봐. "코드의 20%에 해당하는 부분이 전체 일의 80%를 수행한다" 코드를 짜고 돌려보면서 성능 문제가 있다면 병목 현상이 가장 크게 생기는 부분에 집중해야해.
   
   "성급한 최적화를 하지 말라"고 해서 "코드는 개똥같이 짜도 돼"라고 한 건 아니야. 항상 간결하고 우아한 코드를 위해 노력해야 하는 건 당연하지만, 이미 잘 작동하는 코드의 뭔가 먼지같은 개선을 위해 하루를 날리진 말라는 말이야. 생산성이 떨어질 뿐더러, 오히려 코드를 복잡하게 만들고 일반화하기 더 어렵게 할 수도 있지.
   
   
6. (이후 내용 생략)

---

원문 링크

https://www.quora.com/What-little-habits-made-you-a-better-software-engineer