실력 있는 프로그래머가 되기 위해.

난 이 글중에서 얼마나 실천할까 반성 해야 겠다.

1. 다른 사람 탓을 하기 전에 여러분의 코드를 먼저 확인하세요

여러분의 생각과 다른 사람들의 생각에 의문을 가져봅시다. 각기 다른 제작자가 만든 툴들이 서로 다른 결과물을 만들어 낼 수 있듯이 같은 제작자가 만든 다른 툴도 그러합니다. 

다른 누군가가 여러분도 풀지 못한 문제를 보고 하는 장면을 본다면, 찾아가서 무엇을 했는지 살펴보세요. 그 사람들은 아마 전혀 생각지 못한 일이거나 전혀 다른 방법으로 그 문제를 접근 했을 것입니다. 

제 개인적인 룰은 만약, 해결할 수 없고, 컴파일러가 문제라고 생각하기 시작한다면, 스택에서 문제가 생겼다고 생각하자는 것이 제 룰입니다. 이 룰은 새롭게 코드를 추가했을 때 효과적으로 적용합니다. 흰 머리를 만들어내고, 기계에 소리를 지르게 하는 멀티스레드 문제는 또 다른 차원의 문제입니다. 시스템이 멀티스레드 환경으로 오면, 간단한 코드를 위한 모든 추천 방법도 배로 어렵게 됩니다. 디버깅과 유닛 테스트 조차도 이러한 버그를 잘 찾아내기란 어렵습니다. 설계의 간소화는 무엇보다도 중요합니다. 

자, 컴파일러를 탓하기 이전에, 셜록 홈즈(Sherlock Holmes)의 충고를 기억해 봅시다. "불가능 한 점을 먼저 없애면, 무엇이든 남게 되고, 아무리 일어날 수 없는 일이라도 진실이 된다." 그리고 우리에게 적용해보면, "일어 날 수 없는 일을 먼저 제거하면, 무엇이든 남게되고, 아무리 불가능 한 일이라도 가능하게 된다." 

-Allan Kelly

2. 끝 없는 학습

우리는 흥미로운 시대에 살고 있습니다. 개발자가 세계로 퍼져나갈 수록, 여러분의 일을 할 수 있는 사람이 많다는 사실을 알게 됩니다. 여러분은 수요가 있는 능력을 계속 키울 필요가 있습니다. 만약 능력을 계속 키우지 않는다면, 여러분은 공룡 취급을 받게 될 것이고, 언젠가는 해당 직업이 더 이상 필요해지지 않거나, 다른 대체 자원이 등장하게 되면 더 이상 여러분을 찾지 않게 될 것입니다. 

그래서 여러분은 기술 숙련에 무엇을 하고 있죠? 간혹 가뭄에 콩나듯 몇몇 고용주는 너그럽게 당신에게 새로운 기술을 습득하도록 학습 기회를 충분히 제공할 수도 있습니다. 문제는 다른 분들은 그렇지 않다는 말입니다. 안전하게 기술을 습득하기 위해서는 결국, 여러분이 책임감있게 혼자서 학습 할 필요가 있습니다. 

여기 지속적으로 학습을 위한 방법이 몇가지 있습니다. 이중 대부분은 인터넷에서 무료로 진행할 수 있습니다:

• 책, 잡지를 구독하세요, 블로그와 트위터도 둘러보시구요, 웹사이트도 꾸준히 보아야 합니다. 거기서 발견한 정보를 더 자세히 알고 싶다면, 메일링 리스트에 가입하거나 뉴스 그룹에 가입하십시요. 
  
  
• 정말로 하나의 기술에 대하여 깊이 알고 싶다면, 소매를 걷고 당장 몇 줄의 코드를 작성해보세요. 
  
  
• 최고가 되고자 하는 사람은 여러분의 학습을 방해 할 수도 습니다. 항상 멘토와 같이 일하고자 노력하세요. 누구에게나 무엇인가를 배울 수 있지만, 더 똑똑하고, 경험이 많은 이에게는 상당히 많은 내용을 배울 수 있습니다. 멘토를 찾을 수 없다면, 직장을 옮기기를 고려하십시요. 
  
  
• 가상의 멘토를 정하세요. 여러분이 웹상에서 정말 재미있게 글을 읽은 책이나 글의 저자, 개발자를 찾으세요. 그리고 그들의 블로그를 구독해보세요. 
  
  
• 사용하는 라이브러리나 프레임워크의 지식을 습득하세요. 그것이 어떻게 돌아가는지 아는 것은 여러분이 해당 도구를 더 잘 사용하도록 만들어 줄 것입니다. 해당 도구가 오픈소스라면, 더할나위 없겠지요. 디버거를 사용해서 구동 중인 도구가 어떻게 동작하는지 코드를 살펴보십시요. 매우 능력 있는 사람들이 작성한 코드를 살펴보게 될 것입니다. 
  
  
• 사람은 언제나 실수를 합니다. 실수를 할 때마다, 버그를 잡고, 프로그램을 구동하세요. 무엇이 잘못된 것인지 정확히 이해하려고 노력하십시요. 누군가는 같은 문제를 인터넷에 포스팅 하는 경우도 있습니다. 구글이 정말 이런 상황에서 유용하죠. 
  
  
• 기술을 배우는 좋은 방법은 해당 기술을 가르쳐보고, 발표해 보는 것입니다. 사람들이 발표를 듣고 기술에 대하여 질문할 때 배우고자 하는 동기가 확실하게 됩니다. lunch-'n'-learn(점심시간에 학습이나 발표 세션을 갖는 행위)을 직장에서 시도해보세요. 아니면, 유저 그룹이나 지역 컨퍼런스도 괜찮습니다. 
  
  
• 관심이 있는 일정 언어나 기술 등을 위한 스터디 그룹을 개설하거나 참가해보세요. 
  
  
• 컨퍼런스에 참석해 보세요. 여건이 허락하지 않는다면, 온라인에서 무료로 나오는 컨퍼런스 발표를 살펴봅시다. 팟캐스트도 있습니다. 
  
  
• 통근 시간이 길어서 불만이라구요? 팟캐스트를 청취하세요. 
  
  
• 정적 분석 툴이 여러분의 코드에 경고를 하거나, IDE에서 경고 표시를 발견했나요? 이 도구들이 무슨 일을 왜 보고하는지 알아보세요. 
  
  
• 매년 새로운 언어를 배워보세요. 적어도 새로운 기술이나 툴은 학습을 해보세요. 이러한 작업은 여러분이 현재 사용할 수 있는 기술에서 새로운 아이디어를 가지치기 할 수 있는 좋은 기회가 됩니다. 
  
  
• 꼭 기술에 관련된 것만 배울 필요는 없습니다. 도메인 지식을 학습하는 것은 이후에 여러분이 요구사항이나 비즈니스 문제를 해결할 때에 많은 도움을 줄 것입니다. 어떻게 하면 더 생산적으로 될 수 있을까(어떻게 하면 일을 더 잘할까)는 좋은 옵션이 됩니다. 
  
  
• 학교로 돌아가서 학습을 하는 것도 좋습니다.

위 리스트를 수행하면 네오가 매트릭스에 있는 것과 같은 멋진 능력을 갖게 될 것 같습니다. 여러분은 그저 원하는 정보를 머리에 다운로드 받으면 되는 것이지요. 유감이지만, 우리는 그럴 수 없습니다. 시간이 소요되지요. 물론, 깨어있는 모든 순간을 배움에 쏟을 필요는 없습니다. 매주 잠깐씩이 좋습니다. 이러한 배움의 시간은 일을 하는 시간이 아닐 때입니다(그래야만 합니다). 

기술의 변화는 빠릅니다. 뒤쳐지지 마세요. 

-Clint Shank

3. 일을 망치는 것을 두려워 말 것

산업계의 경력이 있는 모두는 의심의 여지 없이 스파게티 코드인 프로젝트를 경험해봤을 것입니다. 시스템은 하나의 덩어리로 되어있고, 한 개의 사항에 대하여 수정을 하면, 사이드 이펙트를 막기 위해 관리를 해야합니다. 모듈이 하나 추가될 때마다, 프로그래머는 수정 사항을 릴리즈 할 때 숨을 가다듬고 영향이 미미하길 바랄뿐입니다. 이런 일은 젠가에서 재앙을 불러일으키는 일과 똑같습니다. 이러한 변화를 일으키는 이유는 시스템 자체가 불안정하기 때문입니다. 이런 문제를 해결할 해결사가 필요합니다. 그 외에는 오히려 상황을 악화시킬 뿐입니다. 여러분은 이미 시스템에서 무엇이 문제인지 알고 있습니다. 그렇지만, 여러분은 상황을 망칠까봐 두려움에 가득차 있지요. 마치 오믈렛을 만들 때에 계란을 깨는 상황처럼요. 능력 있는 의사는 수술을 집도할 때에 어디를 절개해야 하는지 잘 알고 있습니다. 절개를 할 경우 그 부분의 상처는 일시적이며, 곧 문제점과 절개한 부분도 치료됩니다. 절개할 때의 고통이 이후의 결과에 대해 가치있는 아픔이 되는 것이지요. 수술을 받는 환자는 수술 이후에 반드시 이전보다 상태가 더 호전되어야 합니다. 

여러분의 코드도 마찬가지입니다. 코드를 수정할 때에 일시적으로 코드의 균형이 무너진다고 아무도 상관하지 않습니다. 변화의 두려움은 프로젝트가 시작할 때부터 안고 가는 것입니다. 리팩토링에 투자하는 행위는 프로젝트 라이프 사이클의 몇배의 자원을 절약할 수 있게 합니다. 추가적으로, 좋지 않은 시스템을 처리하는 여러분의 팀이 시스템이 올바르게 구동하게 하기 위해서 어떻게 해야하는지 알게 하는 일에 전문가 수준까지 끌어올릴 수 있는 기회를 제공합니다. 엉성한 시스템을 보고 화를 내기 보다 여러분이 갖춘 지식으로 도전하기 바랍니다. 좋지 않은 시스템에서 작업하는 것은 시간을 낭비 하는 것이 아닙니다. 내부 인터페이스를 재정의하고, 모듈을 재설계하고, 웹 등에서 복사해온 코드를 리팩토링하고, 상호간의 의존성(dependencies)를 줄여서 설계를 간단화 하십시요. 여러분은 의도되지 않은 기능을 가끔씩 수행하는 상황 등을 제거함으로써 코드의 복잡도를 효과적으로 낮출 수 있습니다. 이런 방법으로 상태 변환이 늦는 오래된 구조를 새것으로 바꿀 수도 있습니다. 시스템의 큰 오류를 한번에 리팩토링을 시도하는 행위는 지금까지 해온 모든 노력을 물거품으로 만들 수도 있습니다. 

큰 문제를 위해 작은 것의 고통을 감내할 줄 아는 의사가 되십시요. 이러한 태도는 퍼지기 쉽고, 다른 개발자로 하여금 문제 없는 온전한 프로젝트에서 작업을 수행할 수 있도록 합니다. 팀원 모두가 가치있다고 여기며, 프로젝트에 도움이 되며, 온전한 프로젝트 상황을 유지하기 위한 수행 목록을 지속적으로 지켜 나가십시요. 관리자에게 이런 작업이 직접적인 산출물을 생산하지 않더라도, 이들에게 비용을 감소하고, 릴리즈 일정을 더 당길 수 있다고 확신을 심어 주십시요. 절대로 코드가 엉망진창으로 되도록 내버려두지 마세요. 

-Mike Lewis

4. 전문적인 프로그래머

전문적인 프로그래머에게 가장 중요한 특성을 꼽자면 개인적인 책임감이라고 할 수 있습니다. 전문적인 프로그래머는 그들의 경력, 평가, 일정에 충실하고, 실수조차, 그리고 장인 정신에 막대한 책임감을 갖습니다. 전문적인 프로그래머는 이런 맡은 소임을 다른 사람에게 떠넘기지 않습니다. 여러분이 전문가라면, 여러분의 경력에 책임을 가져야만합니다. 여러분은 지속적으로 학습할 책임이 있습니다. 산업계와 최신 기술을 파악 할 의무가 있습니다. 너무나 많은 프로그래머가 자신들을 교육시켜야 하는 의무는 고용주에게 있다고 생각합니다. 미안하지만, 틀려도 한참 틀렸습니다. 의사가 저런 사고방식을 가졌다고 생각하십니까? 변호사는? 절대 아닙니다. 그들은 스스로 자비를 들여서 자기 자신을 단련합니다. 이들은 업무 외 시간의 대부분을 저널이나 판례등을 읽으며 보냅니다. 뒤쳐지지 않도록 노력합니다. 우리도 그래야만 합니다. 여러분과 고용주의 관계는 계약 관계로 명쾌하게 나뉩니다. 다시 말해서, 고용주는 여러분에게 돈을 지불할 뿐이고, 여러분은 그에 상응하는 실적을 약속했습니다. 이게 계약의 전부입니다. 

전문가는 자신이 작성한 코드에도 책임감을 갖습니다. 이들은 코드가 정확하게 돌아가는지 확인하기 전까지는 코드를 릴리즈 하지 않습니다. 잠시만 생각해봅시다. 여러분조차 확신이 없는 코드를 릴리즈하는 당신이 어떻게 전문가라고 생각할 수 있겠습니까? 전문 프로그래머는 QA가 아무런 문제점도 찾지 않기를 원합니다. 이는 개발자 자체적으로 수 많은 테스트를 수행하기 때문입니다. 물론 사람은 실수를 하기 때문에 QA도 문제점을 찾아냅니다. 그러나 전문가로서 우리의 태도는 QA에게 아무런 문제점도 넘기지 않는다는 전제를 갖고 가야만합니다. 

전문적인 프로그래머는 팀플레이어입니다. 그들은 자기 자신의 결과뿐만 아니라 전체 팀의 산출물에도 책임감을 갖습니다. 동료 개발자를 돕고, 가르쳐주기도 하며, 반대로 배우기도 하고, 필요하다면 다른 사람의 역할도 마다하지 않습니다. 누군가가 능력이 부족하다면 결국에는 그 부분을 다른 사람이 채워야만 한다는 사실을 잘 알고 있습니다. 

전문가는 거대한 버그 리스트를 참지 못합니다. 거대한 버그 리스트는 헐렁하게 되어있습니다. 이슈 트래킹 데이터베이스에서 수 천개의 이슈가 있는 시스템은 무관심이 불러일으킨 비극입니다. 사실 대부분의 프로젝트에서는 무관심의 징조가 생기면, 이슈 트래킹 시스템이 필요한 시점입니다. 거대한 시스템만이 매우 거대한 버그 리스트를 보유하고 있기 때문에 이들을 다루기 위해서는 자동화가 필요합니다. 

전문가는 일을 망치지 않습니다. 이들은 자신의 실력에 자신감을 가지고 있지요. 코드를 깔끔한 상태로, 읽기 쉽고, 구조화가 잘 되어있도록 유지합니다. 표준을 따라서 최고의 예제만을 배경으로 삼습니다. 전문가는 절대로 서두르지 않습니다. 여러분이 수술 중에 유체이탈을 하고 심장 수술이 진행 중인 여러분의 몸을 보고 있다고 상상해보세요. 의사는 문학적으로 표현하자면 데드라인이 있습니다. 그는 반드시 당신의 심장과 폐에 공기를 불어넣고 있는 기계가 몸에 무리를 일으키기 전에 수술을 끝내야만 합니다. 여러분은 의사가 어떻게 행동하기를 원하십니까? 일반적인 소프트웨어 개발자처럼 일을 서두르다 모든 것을 망치기를 원하십니까? 그가 "다음에 다시 고치도록 하지." 하는 걸 원하는 건가요? 아니면, 규율에 따라서 천천히 그가 행동 할 수있는 최대의 침착함으로 수술을 집도하기를 원하나요? 일을 망쳐버리기 원하나요, 전문가답게 행동하길 원하나요? 

전문가는 책임감을 갖습니다. 이들은 자신의 경력에 책임을 지며, 제대로 작동하는 코드를 작성하고, 장인 정신을 갖추고, 마감기한이 가까워졌다고 서두르며 자신의 철학을 버리지 않습니다. 대신, 압박이 올때, 자신을 더 채찍질하여 규율을 지키도록 노력합니다. 

-Robert C. Martin (Uncle Bob)

5. 코드 분석 툴에서 이득을 얻기

테스팅의 가치는 개발자의 프로그래밍 여정에서 일찍부터 가치를 지닙니다. 최근에는, 유닛 테스트, 테스트주도 개발, 애자일 개발방법의 등장으로 개발의 전체 과정에서 테스트를 수행하도록 하는 방법이 테스팅의 가치를 입증하고 있습니다. 하지만, 테스팅은 코드의 품질을 향상시키는 사용할 수 있는 많은 도구 중 하나일 뿐입니다. 

시간을 되돌려봅시다. C가 새로운 신드롬을 일으킬 때가 좋겠군요. CPU의 속도와 저장공간이 귀하던 그 시절 말입니다. 가장 처음 나온 C 컴파일러는 이 시대상을 반영하듯 구문 분석을 하는 횟수를 적게합니다. 컴파일 도중 확인 할 수 있는 오류의 수가 전체 오류에 비해 적다는 뜻입니다. 이를 보충하기위해, Stephen Johnson은 lint(코드에서 불필요한 부분을 제거해주는 툴)를 구현했습니다. Lint는 자매격인 C컴파일러의 정적 분석을 수행합니다. 정적 분석툴은 명성을 얻긴 했지만, 너무 많은 불필요한 경고 표시를 제공해서 항상 이 경고를 따를 필요는 없었습니다. 

현재의 언어와 컴파일러, 정적 분석툴의 생태계는 너무 다양합니다. CPU와 메모리의 가격은 충분히 저렴해졌기때문에 컴파일러는 더 많은 검사를 통해 더 많은 에러를 검출합니다. 이제 거의 모든 언어는 적어도 하나씩 코딩 스타일 위반, 잦은 실수, 널포인터의 해제 등 가끔은 잊고 넘어가는 에러를 검출하는 툴을 가지고 있습니다. C의 splint나 Python의 Pylint과 같이 조금 더 세련된 툴도 있습니다. 이런 툴은 설정 파일을 통해 어떤 에러나 경고를 커맨드라인이나 IDE상에서 알려주도록 합니다. Splint는 심지어 어떻게 작성하면 더 프로그램이 잘 구동하는지 주석으로 팁을 알려주기도 합니다. 

만약 위와 같은 방법으로도 해결이 되지 않는다면, 여러분은 컴파일러나 IDE, lint가 잡아내지 못하는 간단한 버그나 규약 위반을 찾아내려 할 때에는 여러분 자신만의 정적 툴을 만들어 내십시요. 생각만큼 어렵지 않습니다. 대부분의 언어(특히 동적 언어)는 표준 라이브러리로서 추상적인 문법 트리를 산출해내거나 컴파일러를 제공합니다. 여러분이 사용중인 언어의 개발팀이 사용하는 정적 분석과 동적 테스팅을 위해 만들어진 숨겨진 보석인 이 라이브러리는 알아둘 만한 충분한 가치가 있습니다. 예를 들어 파이썬의 표준 라이브러리에는 컴파일된 코드나 오브젝트 코드를 위한 바이트 코드를 해독하는 디스어셈블러도 포함하고 있습니다. 이러한 점은 컴파일러 제작자인 파이썬 개발팀에게 방해물처럼 보이지만, 매일 매일 놀랍게도 유용하게 사용되고 있습니다. 이 라이브러리는 해결 할 수 없는 익셉션에 의한 상황에서 명령어와 스택 상황을 정확하게 디스어셈블링 할 수 있습니다. 

그러니, 품질 보장의 마지막 순서로 테스팅을 하지 마세요. 분석툴을 사용해서 이득을 얻고, 여러분만의 툴을 만드는 것에 두려워 하지 마세요. 

-Sarah Mount

6. 동료를 위한 우분투 코딩(Ubuntu Coding)

우리는 누군가를 위해서가 아니라, 매우 개인적인 문제를 해결하기 위해 코드를 작성합니다. 그리고 그렇게 생겨난 코드는 문제를 우리 나름대로의 해석을 담고 있습니다. 그렇지만, 우리는 개인적으로는 고립되어 있을지라도, 팀의 일원으로 존재합니다. 우리는 혼자서 작성한 이 코드가 누군가에 의해 사용되고, 확장되며, 전적으로 신뢰할 것을 쉽게 잊고 있습니다. 소프트웨어 작성의 사회적 측면을 간과하기는 매우 쉽습니다. 소프트웨어를 작성하는 일은 기술적인 측면과 사회적 측면이 결합된 작업입니다. 우리는 고개를 들고 우리가 혼자서 일하지 않는다는 사실을 인지할 필요가 있습니다. 그리고 개발팀 뿐만 아니라 모두의 성공을 위해 우리의 작업을 공유할 책임이 있습니다. 

혼자서도 좋은 품질의 코드를 생산할 수 있습니다. 혼자서 모든 나머지를 희생하면서요. 하나의 관점으로 보면, 이러한 방식은 자기중심적 접근입니다(오만함이 아니라 개인적인 접근입니다). 코드를 생산할 때에 Zen의 관점도 바로 이런 것입니다. 필자는 항상 매 순간 순간을 충실하도록 노력합니다. 왜냐하면 이러한 태도는 양질의 코드를 생산할 수 있기 때문입니다. 그렇다면, 팀원들은 어떨까요? 다른 팀원들도 저와 같은 생각으로 임할까요? 

Zulu에서, 우분투의 철학은 다음과 같이 표현합니다. "Umuntu ngumuntu ngabantu," 우리말로 표현해보면, "개인은 다른 사람을 통해 온전한 사람이 된다." 입니다. 필자는 여러분의 좋은 반응을 통해 더 나아집니다. 뒤집어 생각해보면 제 기분이 좋지 않을 때, 일을 하면 더 좋지 않은 결과를 얻게 되는 셈입니다. 앞의 격언을 개발자에 국한하여 생각해보면, "개발자는 다른 개발자들을 통해 온전한 개발자가 될 수 있다."가 됩니다. 코드의 측면으로 생각해보면, "코드는 다른 코드를 통해 코드로 인정받을 수 있다."로 표현할 수 있습니다. 

제가 작성한 코드의 품질은 여러분이 작성하는 코드의 품질에도 영향을 미칩니다. 제 코드의 질이 낮다면요? 설령 여러분이 매우 깔끔한 코드를 작성하더라도 여러분의 코드에서 제 코드를 사용하는 순간 그 코드의 질은 떨어지게 될 것입니다. 이러한 피해를 최소화하기 위해 패턴이나 기술이 동원될 수도 있습니다. 그렇지만, 코드의 효과가 이미 작용한 이후 입니다. 저는 여러분에게 필요한 양보다 더 많은 일을 요구하도록 하게 될 것입니다. 왜냐하면 간단히 말해서, 저는 제 순간을 열심히 할 때 여러분을 고려하지 않았기 때문입니다. 

저는 항상 제 코드를 깔끔하게 작성하려고 노력합니다. 하지만 우분투의 코딩을 보고 있으면 아직 더 나아 질 수 있는 부분이 존재 합니다. 우분투의 코드는 어떻게 구성되어 있을까요? 우분투 코드는 깔끔하고 훌륭하게 보입니다. 이건 마치 코드가 아니라 유물처럼 보입니다. 코드가 유물을 제작하는 행위처럼 보입니다. 우분투처럼 여러분의 친구를 위해 코딩을 하는 것은 여러분의 가치를 팀이 영위하게 하고, 여러분의 철학을 팀원에게 불어넣어 줍니다. 다음 사람이 여러분의 코드를 수정하게 될때, 어떠한 방식으로든 더 나은 사람이 되고, 더 나은 개발자가 될 것입니다. 

Zen은 자유분방합니다. 우분투는 수 많은 사람을 위한 Zen입니다. 그렇기 때문에 자신을 위해 코드를 작성하지 않습니다. 

-Aslam Khan

7. 자기 자신이 작성한 코드에 관심을 갖기

훌륭한 코드를 작성하는 프로그래머는 셜록 홈즈가 필요 없습니다. 그렇지 않은 프로그래머는.. 글쎄요. 필요할 것 같군요. 그들은 나머지가 힘들게 치워야 할 거대한 쓰레기를 생산합니다. 여러분은 훌륭한 코드를 작성하기를 원하죠? 그렇다면, 여러분은 훌륭한 프로그래머가 되기를 원해야 할 것입니다. 

좋은 코드는 공기중에서 갑자기 튀어나오는 물질이 아닙니다. 식물을 일정하게 심었을 때 운좋게 튀어나오는 것도 아닙니다. 좋은 코드를 작성하기 위해서는, 부단히 노력해야 합니다. 그리고 여러분이 정말로 좋은 코드에 관심이 있을 때 양질의 코드를 얻게 될 것입니다. 

좋은 프로그래밍은 기술에 능숙하다고 해서 생산되지 않습니다. 저는 훌륭하고 인상적이며, 언어의 표준을 가슴 깊이 이해하는 유능한 프로그래머를 만난적이 있습니다. 하지만, 이들도 더러운 코드를 작성합니다. 읽기도 어렵고, 쓰기도, 수정하기도 어렵습니다. 매우 간단한 코드를 작성하도록 고수하는 겸손한 프로그래머도 보았지만, 우아하고 인상적인 프로그램을 작성하는 사람은 이 일을 즐기는 사람이었습니다. 

소프트웨어 회사에서의 제 경험을 비추어 볼 때, 저는 "태도"에서 일반적인 프로그래머와 훌륭한 프로그래머와의 진정한 차이가 발생한다고 생각합니다. 훌륭한 프로그래밍은 전문적인 접근을 통해 가능한 최고의 소프트웨어를 작성하도록 노력하고, 실제 세계의 통제와 회사의 압박 속에서 노력하는 방식입니다. 

산으로 가는 코드는 좋은 의도들로 포장되어 있습니다. 훌륭한 프로그래머가 되기 위해서는, 여러분은 이 생각들을 버리고, 진정으로 코드를 생각하는 의도를 찾아야 합니다. 이를 테면, 긍정적인 접근을 촉진하고, 건강한 태도를 키워주는 것을 볼 수 있습니다. 위대한 코드는 장인에 의해 한땀한땀 만들어 집니다. 허울만 있는 프로그래머가 만들어낸 코드가 아니며, 자칭 코딩 구루가 대충 뱉어낸 코드도 아닙니다. 

-Pete Goodliffe

출처 : 한빛 미디어