이 글에 대한 번역. (오역 수정 2017/8/15)
당신을 폭풍같은 프로그래머로 만들어주는 29가지 습관
프로그래밍 분야에서는 10배속(10x) 개발자라는 악명높은 신화가 있다. 10배속 개발자는 팀의 다른 프로그래머들에 비해 대충 10배는 빠르게 달성한다고 한다. 이는 꽤 뜨거운 논쟁이며, 사람들의 의견이 극단으로 나누어져있다.
몇몇 사람들은 10배속 개발자란 신화는 완전이 개소리라 한다. 다른 한쪽에선 평범한 프로그래머와 스타 프로그래머 사이에서 효율성의 차이는 100배속 1000배속까지 다양하게 나올 수 있다 말한다.
당신이 10배속 개발자에 대한 신화를 믿거나 혹은 어이없는 이야기라 생각하거나, 어느쪽이든 모든 폭풍같은 프로그래머들 사이에 공통적인 행동 양식이 있는 것은 사실이다.
사실 이러한 특별한 프로그래머들은 남들과 다르게 행동하는 29가지 일들이 있다.
만약 프로그래머로서 당신이 성장하지 못했다면, 15번째와 29번째에 관심을 특히 가져라.
1. 구글을 공격적으로 사용하라.
개발자로서 당신은, 궁금한 것을 어떻게 표현해서 검색할지. 다른 개발자의 코드는 어떻게 리뷰하는지.
그리고 겪고 있는 문제를 풀기위해 이들을 적용하는 법을 알 필요가 있다.
현재 2016년에는 , 웹에서 가능한 기술들을 활용하여, 도구 들을 적절히 조사할 수 있는 방법을 반드시 알아야 한다.
2. 끈질기게 불쾌해하라.
베테랑 프로그래머들은 새로운 기술에 대해 입문자의 위치가 된다. 그리고 스스로를 가르치도록 뛰어드는 것을 기쁘게 받아들인다.
모든 전문가들은 과거에는 초보자들이었다. 그리고 한분야에 정통한 사람이라도 다른 분야에서는 허접이 되는 수많은 기술들이 세상엔 널렸다.
3. 사소한 결정이 중요하다는 것을 깨달아라.
프로그램을 작성할때, 결정해야 하는 백만개의 선택지가 있는 것처럼 느껴질때가 많다. 작은 기능을 추가할때 조차도.
예를 들자면, 변수명을 정하는 것, 함수들을 호출하는 것, CSS 프로퍼티들을 이름 짓는것, 해시 vs 배열, 그외 다른 작은 것들 또한 큰 영향을 가질 수 있는 것으로 보인다.
새로 프로그래머가 된 이들은 이런 일들에 충분이 주의를 주지않는 경향이 있다.
하지만, 폭풍같은 개발자들은, 스스로 편하게 변수명을 짓기위해 패턴들을 만든다.
언제나 같은 방법으로 이름을 짓기에 이런 일에 대해 생각하지 않아도 될 경지에 까지 오른다.
4. 대부분의 큰 결정들은 사실 별로 중요하지 않다는 것을 깨달아라.
응용프로그램을 구축하는 동안, 이후 대부분의 코드를 작성하는 방법에 영향을 끼칠 주요한 결정들을 하게 된다.
예를 들자면, 대게 테스트 주도 개발 접근법을 사용하길 원한다. 이때 코드를 테스트하는데 사용할 수 있는 도구들이 여러개 있다.
예를들어 Ruby의 경우 당신은 MiniTest vs RSpec 사이 차이점을 심사숙고 할 것이다.
사람들은 이런 선택지들에 대해 정말 자존심 강한 자기만의 의견을 가지고 있다.
하지만 폭풍같은 개발자들은 다르게 생각한다. 그들은 그런것에 별로 관심이 없다.
그들이 중요하게 여기는 것은 테스트 코드를 작성하는 습관이며, 당신이 사용하는 특정 툴 그 자체가 그만큼 중요한게 아니란 걸 안다.
폭풍같은 프로그래머들은, 다른 개발자들이 뛰어드는 이런 병신 같은 논쟁(병림픽)에 참가하지 않는다.
그 대신 실제로 펀치를 날려 행동한다. 폭풍같은 개발자들은 명상수련자 같다.
¯\_(ツ)_/¯
5. 일에 알맞은 도구를 사용하라.
세상엔 너무나 많은 오픈소스 라이브러리, 도구, 프레임워크들이 널려 있다. 실력있는 프로그래머는 마주친 각각의 문제들에 대해 어떤 것을 사용해야 하는지 안다.
결국엔 스스로를 더 효율적으로 만들어준다면야, 배빵을 맞는 듯한 학습의 고통도 감수할 의지가 있다.
이런 의지로, 그들은 조사결과를 2~3가지 옵션으로 줄여낸다.
그리고 어떻게 자신의 환경에선 어떻게 동작할지 이해하기 위해, 가장 나은 도구를 자기 상품에 즉시 적용한다.
6. 코드 그 자체는 큰 가치가 없다는 것을 알아라.
일을 다르게 처리해보기 위해, 수백줄의 코드를 날리는 것 정도는 부담스러워 하지 말아야 한다.
대게, 어떤 접근법이 잘 안되는지 알기 위한 유일한 방법은 제대로 다시 한번 시도해보는 것 뿐이다.
많은 사람들이 코드를 갈무리하는 것을 시간낭비라고 생각한다.
하지만 그 코드들을 작성해서 얻는 그 경험들은, 바로 적재할 수 있는 코드 처럼 "성과"로서 봐야 한다.
코드 날려버리기는, 그저 결과물로 이끄는 과정의 한 부분이다.
7. 기술을 모든 시각에서 판단하라.
대게, 평균적인 개발자들은, 그 방에 있는 거대한 코끼리는 잊어버린체, 기술들을 평가하려 한다.
예를 들어, 나는 Exlixir를 고집해왔다. 이것은 환상적인 문법과 놀라운 커뮤니티, 그리고 밝은 미래를 가지고 있다. 하지만 이것은 나온지 너무 얼마 안되서, 실제로 복잡한 기능을 구현하려 한다면, 삶의 안식을 위해 오픈소스 기술을 찾아 고통스런 시간들을 보내야 할것이다.
당신은 모든 요소를 고려해봐야 한다.
8. 모르면 "나는 몰라요" 라고 말하라.
개발자로서, 잘 알지도 못하는 걸 인정하지 않는것 만큼 시간을 낭비하는 빠른 방법이 없다.
폭풍같은 개발자들은 스스로의 가치는 이미 알고 있는 몇가지 사실들에 속박당할 수 없다는 걸 안다. "그따위 것"들은 사실 별로 중요하지 않다.
당신을 가치있게 만들어 줄것은 당신이 아직 알지 못한 것들이지, 아는척 행동하는데 집착하는 것 아니다.
폭풍같은 개발자들은 모든 종류의 기술들(프로그래밍 언어, 프레임워크, 라이브러리, 등...)이란 다음날 쓸모없게 될 수 있는 것들이란 걸 안다.
그들은 프로그래밍이란걸 좀더 높은 차원에서 생각한다.
9. 에러 메시지들에서 찾은 단서를 항상 분석해라.
전통적인 교육은 실패란 나쁜 것이라 가르쳤다. 에러 메시지들은 대게 실패와 연관되 있다.
하지만,훌륭한 프로그래머는 이런 메시지들 이야말로 올바른 방법으로 스스로를 이끌 실마리라는 것을 안다. 그리고 이것이 두가지 핵심으로 이루어진 것을 안다.
-
- 실제메시지, -코드상에 현존하는 문제를 묘사한 플레인 텍스트.
- 콜 스택(더 중요한 것), - 에러가 난 정확한 라인의 코드를 알고, 왜 해당 라인 코드가 실행됬는지 이해하게 해주는 것.
개발자가 그때 그때 자꾸 비슷한 에러 메시지를 마주하게 되는건 낭비다. 당신은 반드시 문제를 해결하는 방법과 왜 그걸 고쳐야 하는지를 공부하는데 포커스를 맞춰야 한다. 이렇게하면 미래에 비슷한 에러를 더 빠르게 고칠 수 있을 것이다.
예를 들어, 루비 개발자들은 이 메세지를 보아왔을 것이다: "No Method Error on nil:NilClass". 아마 에러 메세지 없이 시작된 횟수를 합친것 보다 더 많이.
10. 시기상조의 최적화와, 멋지게 끝판을 장식하는 필.수.적.인 최적화 사이의 차이점을 알아라.
대게 코드는 등가교환을 따른다. 그리고 말그대로, 코드를 작성하는데는 못해도 두가지 다른 방법이 있다:
- 방법 #1: 가능한 직관적이고 명확한 방향으로 코드를 작성한다
- 방법 #2: 성능을 빠르게 하기 위해 혼란스러운 방향으로 코드를 작성한다.
사람들은 응용프로그램이 빠르길 원한다. 코드가 수행되는데 걸리는 시간을 염두해야 한다.
하지만, 이미 충분이 빠른 코드를 다른 개발자들에게 혼란을 주는 방향으로 바꿔버리는 게 더 최악이다.
폭풍같은 개발자들은 코드가 불명확하지만, 성능이 빠른 방향으로 작성 할 미래의 좋은 시점을 안다.
11. 자신의 실수에 대해 책임감을 가져라.
실수란 언제나 일어난다. 특히 팀으로 일할때.
팀으로 일할때 일어나는 대부분의 문제들은 코드와 없다. 멤버들 사이의 잘못된 소통으로 일어난다. 말그대로, 수많은 파티들이 이런 망할 상황에 처해있다.
폭풍같은 개발자들은 자신의 삶이 운전석에 앉은 것 처럼 여긴다. 그들이 마주하는 문제는 100%는 자신의 행동의 결과다. 그럴때 유일한 선택지가 다른 일을 찾아야 하는 것 외엔 없더라도.
그들은 다른 개발자와 프로세스, 혹은 환경에 비난을 떠넘기는데 시간 낭비하지 않는다.
사람들이 뭐라 생각할지 걱정하며 안절부절 못할바엔, 폭풍같은 개발자들은 자신이 당장 통제할 수 있는 것에 집중한다: 코드.
12. 개발 도구들을 잘쓰는 파워 유저가 되라.
만약 특정한 환경에서 코드를 작성하는데 충분한 시간을 들였다면, 당신은 이를 어떻게 사용하는지 정확하게 알아야 한다.
툴킷을 뭐로 쓰던 상관없다, 당신이 서브라임,메모장,아톰,Emacs,Vim 아니면 비주얼 스튜디오를 쓴든.
서브라임이나 아톰은 써보기 쉽다고들한다. 폭풍같은 개발자들은 대게 쉬운 도구를 마스터하는 것으로 시작하고, 의도치 않게 어려운 옵션으로 졸업 해간다.
13. Vim을 쓸줄 알아라 (최소한 조금이라도).
이 텍스트 에디터를 사용해서 허접하게라도 하려는 일을 진행할 수 있어야 한다.
능숙하지 못할 순 있다. 많은 프로그래머들이 이걸로 코드를 작성하라 하면 절대 안하려 하겠지만, 최소한 할줄은 알고 있다.
14. 익숙하지 않은 기술에 대해서는, 절대로 외주를 받지 마라.
프리랜서일의 가장 중요한 부분은 일이 얼마나 걸릴지 책정하는 것이다.
게다가 새 프로그래밍 언어나 프레임워크 밑에서는 한 두가지 일에 엄청난 시간을 써버리게 된다.
이미 알고있는게 아닌 것 대한 일정을 견적냈다가, 스스로를 곤경에 빠뜨리지 마라.
이미 알고 있는 기술들에 대한 프리랜서 일만 받아들여라.
15. 들인 시간을 신경쓰지 마라.
16. 몰아치는 비평들을 부드럽게 받아들여라.
그런일이 일어났을 때 이성적이고 논리적으로 반응할 수 있는 능력을 개발해야 한다.
17. 더 뛰어난 사람들과 함께 프로그램을 작성해라.
18. 언제나 자신의 작업물 부터 먼저 코드 리뷰해라.
이 간단한 일로 수많은 부정적인 피드백을 피할 수 있을 것이다.
19. 프리랜서 일에서 힘든 부분은 코드 작성이 아니란걸 알아라. 실제로는 모든 부분이 다 힘들다.
프리랜서 코딩 작업에 연관된 다른 모든 일들이 힘들기 때문이다.
20. 더 큰 문제들을 명확히하고, 해결하라.
최고의 프로그래머들은 손에 놓인 당장의 문제 너머를 생각하고, 좀더 넓은 시야에서 문제를 해결할 방향으로 작업한다. 이런 식의 더 큰 문제들은 다음을 포함한다:
- 일정을 맞추려고 주말까지 일하게 되는 것
- 당신의 코드에 버그가 지속적으로 발생하여 핫픽스를 계속 내야 하는 것
- 상용 사이트가 여러번 다운 되는 것
- 새로운 계획이 시작되어 이 것을 제대로 끝낼 시간이 주어지기도 전에, 더 중요한 새로운 계획이 생기는 것
만약 이러한 종류의 문제들을 적절이 다루는 법을 배운다면, 이미 당신은 폭풍같은 개발자가 되기 시작한 것이다.
21. 거대한 오픈 소스 프로젝트에 뛰어들어, 당신의 기능들에 생명을 부여하라.
솔루션을 몽키패치(역주 - 런타임 도중에 함수와 프로퍼티를 수정&확장하는 것. 소스코드가 없어도 기능 변경과 확장이 가능) 하는 법을 안다면, 당신에게 불가능은 없다.
이것을 구현 삽입하기 위해서, 개발자들은 그 기능과 관련된 프레임워크의 코드들을 제대로 이해해야 한다.
많은 개발자들이 시작하는 것 조차 두려워하고 있다. 폭풍같은 개발자는 투쟁속으로 뛰어드려는 자신을 도저히 멈출수가 없다.
22. 수많은 회의는 생략해버려라.
만약 대기업에 있다면, 미래의 목표를 얘기하는 회의, 그리고 이미 완료된 일을 계속 하는 것 만큼 시간 낭비인 것이 없다.
실제로 하는 일 보다 해야할 일에 대해 이야기 하는데 시간을 더 많이 쓰는 것은 흔한 일이다.
당신의 회사는 코드를 작성하라고 월급을 준다. 코드를 작성하는 것에 대해 토론하라고 주는 것이 아니다.
회의가 산으로 가고 있다면, 그냥 죄다 생략해버려도 상관없다. 당신이 직접 해버린다면 사람들이 당신의 시간을 더 존중해줄것이다.
23. 되돌려 줄때를 알아라.
당신의 경력이 시작 됬을때는 당신의 기술을 연마하는데 집중해야 한다.
더 많은 경험을 가진 개발자들과 일하게 될 것이고 작업의 기교들을 배울수 있도록 도움을 받을 것이다.
하지만 언젠가 당신이 주니어 개발자들에게 그 경험을 돌려줄 때가 찾아온다. 당신의 멘토가 당신에게 해주었듯이.
24. 나쁜 코드를 쓰는 법도 알아라.
가끔은, 덕 테이프 프로그래머 (그때 그때 누덕누덕 코드를 붙여대는 프로그래머) 가 되는 것도 괜찮다.
젊은 이상주의자 프로그래머 시절 때는 완전함 과 극단을 추구하는 세계가 매력적이다.
하지만 마감일, 기대치, 그리고 특정 기능의 실제 효용성 이란 현실이 주어지기 시작하면, 언제나 완벽주의자가 될순 없다.
시간이 흐르고, 언제는 지름길을 타도 괜찮고, 언제는 완벽함이 필요한지 잘 구별할 수 있어야 할때가 온다. 이것이야 말로 가장 배우기 어려운 기술중 하나이다.
25. 폐인 몰골을 하지 않아도 당신이 늦게 까지 일한 걸 알수 있게 하라.
만약 사무실에 남은 마지막 사람이 되었다면, 그저 짧은 상황보고 메일을 누군가에게 보내라. 대부분 사람들이 출근 도장에서 이미 눈치채고 당신이 정말 열심이 일했다는 것을 알게 될것이다.
26. 지도자로 일해라. 우두머리가 아니라.
폭풍같은 개발자들은 지도자들이다. 그들은 우두머리가 아니다. 이 둘 사이에는 차이가 있다.
-
- 우두머리는 사람들이 자신을 위해 일한다.
- 지도자는 다른 사람들이 따라오는 사람이다.
폭풍같은 개발자들은 그들의 팀의 지도자다. 그들에게 직위가 없을 수는 있다. 하지만 개발팀 전체가, 그들의 판단을 기대하게 되는, 그런 사람들이다.
개발팀에 있어서, 지도자와 관리자 사이에 중요한 한가지 차이점이 있다. 지도자들은 전선의 참호에서 살아간다. 팀을 위해 (경우에 따라 가장 많이) 일한다.
관리자가 이론상의 정답을 말할 순 있지만, 지도자는 충분한 맥락을 가지고 있기 때문에 지도자의 의견이 높이 존중 받는 것이다.
27. 밖에 나가서 공을 차라.
긴 시각에서 보면, 다른 개발자들과 (다른 역할의 사람들과도) 인연을 쌓는 것은 좁은 창안에 기능들을 집어 넣는 것보다 더 값진 일이 될 것이다.
28. 압박감 속에서 배워라.
대부분의 폭풍같은 개발자들은 시스템이 다운되거나, 뭔가 고장나버리고, 그것을 복구시킬 책임이 있는 상황을 경험해봤다.
많은 경우, 그들은 문제를 해결할 방법을 미리 알고 있지 않다.
폭풍이 되게위해, 벼락치기로 새로운 것을 배우는 능력을 키워야 한다.
이런 경우들이 그렇다:
-
- 성능 튜닝
-
- 서버 설정
- 다른 시스템에서의 데이터를 이전할때
침착하고, 새로운 상황에 부드럽게 항해하는 법을 배워햐 한다. 배우기는 어렵지만, 몹시 가치 있는 일이다.
이 모든 습관들이 중요하다. 하지만 폭풍 같은 개발자가 되기 위해선, 이 모든 것들 넘어, 반드시 해야하는 단 하나의 일이 있다.
29. "빠르게 움직이고, 깨부숴라"
완벽주의가 훌륭함의 적이 되게 하지 마라.
많은 경우 실수란 최고의 배움의 기회가 된다. 그러니 실수를 실패로 간주하지 마라. 대신에, 그것들을 배움의 순간으로 여기고, 객관적이고 비판적인 시각으로 이들과 맞서 싸워 당신을 프로그래머로서 성장시켜라.
인생의 다른 많은 것들 처럼, 프로그래밍 또한 당신만의 노하우를 작품에 녹여내는 작업에 가깝다.
그러니 당신이 프로그래밍 입문자라면, 그저 코딩 하라. 그리고 당신의 제조술을 향상시키기 위해, 이 수련들을 일상속에 구현하기 시작하라.
폭풍이 되고 싶나?
처음 시작은 실수를 두려워하는 마음을 극복하는 데서 온다. 이 블로그에서 내가 했던 가장 큰 실수에 대해 읽어보고, 그것이 날 어떻게 더 나은 프로그래머로 만들었는지 목격하라: The Biggest Mistake I Ever Made As A Programmer
만약 이 글이 도움이 되어, 당신이 추천버튼을 눌러 많은 사람들이 Medium에서 이글을 읽어 준다면, 나는 너무나 감사할 것이다.