운영체제와  jdk 버젼, jni/kni에 따라서 performance가 상당히 차이가 난다.

JNI/KNI native call은 2가지 상황에 따라서 달라질 수 있다.

첫번째, 잘 된 알고리즘 기반의 native call이 속도를 높일 수 있다.

둘째, JIT 버젼은 상당히 속도면에서 아닌 버젼과 비교할 (cost of a native call) 때, 데이터를 접근할 때(cost of accessing data from native code) 엄청난 차이가 난다. 

논문을 쓰면서 자기들이 만든 제품이 뛰어나다고 쓰다니.. 음.. 별 커다란 가치가 없는 논문이지만, native call 에 대한 performace를 제대로 체크했다는 점을 높이 산다.

참고할 만한 웹페이지

How to write unmaintainable code
http://www.web-hits.org/txt/codingunmaintainable.html

Gnu Coding Standards

Ada 95 Quality and Style Guide : Guidelines for Professional Programmers

GNAT Coding Style

Recommended C Style and Coding Standards

Kernel Korner:Proper LinuxKernel Coding Style

C++ Coding Standard

Coding Convention for C++ and Java application

C++ Coding Style : My code Style

Coding Guidelines for Integral Constant Expression

CStupidClassName

General c++ Coding standard at the NFRA

Hight-Integrity C++ Coding Standard Manual-version 2.1

Programming in c++, rules and Recommendations

UWYN c++ coding standard

Wildfire c++programming style with rationale

mozilla coding style guide

c# coding style guide

writing robust java code

ChiMu OO and Java Development : guidlines and Resources v 1.8

Desing by contract for java using JMSAssert

Java Programming style guidelines version 3.1

how to write doc comments for the javadoc Tool

java glossary: gotchas

Netscape's software coding standards guide for java

tips for maintainable java code

draft java coding standard

Java Language coding guidelines

Best practices : PHP coding Style

PHP coding standard

Delphi 4 Developer's guide coding standards document

the wdvl style guide

spelling errers in you're sights

style guide for online hypertext

css coding style




keyword : coding style, coding standard, code convention, coding guideline, programming style
언어 style, guideline, convention, standards

근 4-5개월 정도, 저는 출, 퇴근 시간을 이용하여 전철에서 틈틈이 컴퓨터 과학 분야의 기고문 또는 논문 등을 읽었습니다. 주로 역사적으로 중요한 위치에서 쓴 부분을 중심으로 자세히 보았습니다. 초심의 마음으로 컴퓨터 과학 분야의 알고리즘 혁명가 ‘다이즈크스트라’가 ACM에 기고한 논문부터 웹을 창시한 ‘팀버너스 리’가 쓴 최근 글들을 보았습니다.

 

방 한구석에 처박혀 아직도 읽지 못한 논문들과 기고문들이 지저분하게 쌓여 있습니다. 그렇게 논문을 읽고, 그에 해당하는 참조를 찾아가며 프린트하며 찾아보는 이유는 제가 공부하고 있는 내용이 진실이 아닐지도 모른 생각을 하면서부터였습니다. 그냥 이론에 갇히어 더 이상 창조적인 생각이 아니라 박제처럼 박혀 있는 죽어 있는 컴퓨터 과학이라는 느낌이 너무나 실감나게 느꼈었는지도 모릅니다.

 

학교에서 공부하던 일반적인 전공 내용보다도 컴퓨터 과학 분야의 대가들이 어떠한 삶을 살았는지, 어떤 생각을 최초에 가졌는지 궁금해 했습니다. 그들의 창조적인 생각들을 조금이나마 알아보고 제 자신이 변화하고 싶었습니다.

 

역시 한 토막 한 토막 읽을 때는 연결되지 못하는 점이라는 생각에 통합을 할 수 없었습니다. 나름대로 정리를 한다고 했지만, 머리는 더욱 더 혼란스러워 져 갔습니다. 점들이 점점 많아 지면서 명확하게 점들을 연결하는 선을 그으려고 했었습니다.

 

바로 그 와중에 ‘임백준의 소프트웨어 산책’이라는 책을 읽게 되었습니다. 희미 해진 정열, 그리고 보이지 않는 공대생의 미래라는 현실과 앞으로 내가 하고 있는 일이 과연 계속 할 수 있을지에 대한 불안한 미래가 그리 달갑지는 않습니다.

 

하지만, 코딩 하는 즐거움, 내가 창조할 수 있는 가상의 공간이 있다는 사실에 내가 세상에 태어나 누구보다도 생산적인 일을 하고 있는 즐거움이 고민과 번뇌를 날려 버립니다.

 

이렇게 복잡하고 명확하지 않는 상황에 ‘임백준의 소프트웨어 산책’을 도서관을 통해서 읽게 되었습니다. ‘임백준의 소프트웨어 산책’은 초보자가 읽기에 쉽지 않은 책입니다. 책 이름 그대로 산책 대신 깊은 사색이 오히려 이 책을 표현하는 말이 어울립니다. 보통 저는 산책을 할 때는 더 이상 머리 안의 책상이 복잡해 져서 더 이상 손댈 수 없는 상황에 닥쳐 있을 때입니다.  산책을 통해서 편안하게 내 머리를 쉬게 해주고 나 자신을 되돌아 봄으로서 잠시나마 머리 안의 책상을 치우고 다시 되돌아가 힘을 얻게 됩니다.

 

그리고, 산책은 혼자보다는 맘에 드는 들어 하는 회사 동료나 선배, 후배 등과 같이 걷습니다. 이런 저런 잡다한 얘기와 함께 선배는 지쳐 있는 저에게 힘이 되어 주는 말과 앞으로의 비전을 서로 얘기합니다.

 

특히 그 산책을 임백준씨와 함께 할 수 있는 기회를 책을 통해서 얻게 되었습니다. 임백준씨에 대해서 잘 모릅니다. 블로그 한 번 가지 않았고, 그저 IT잡지나 책에서 보는 대선배이지만, 산책을 통해서 선배로서 하는 말을 책을 통해서 친해 지게 되었습니다.

 

‘도대체 너를 괴롭히는 코딩이 머니? 객체에 대해서 다시 한번 생각해 볼까? 객체가 왜 만들어 질까? 그리고 디자인 패턴은 좀 알아? 리팩토링은 어떻게 생각하는데? 결국 보면 단순한 게 제일 좋은 거야. 개발 방법론은 어떤 게 좋은 걸까? 그리고, XML은 항상 좋은 건 아냐 그리고 내 예전 얘기 한번 들어 볼래?’

 

이런 저런 얘기를 듣고 결국은 이렇게 말합니다.

 

‘그냥 단순한 지식 전달뿐 아니라 알고 보면 참 별거 없어. 인생이 다 머~ 즐거운 거야~새옹지마 아냐? 힘내라~ 어깨에 힘 좀 넣고~ 파이팅!’

 

책 속의 선배가 제가 궁금했던 점을 확실하게 알려 주고 앞으로 어떻게 공부하면 되겠는지 좀 더 확실히 해주고, 초심의 마음을 건네 줍니다. 원리를 알려 주고, 더 이상 헤매지 않도록 힘을 더해 줍니다.

 

저자의 마음을 제 마음속까지 느껴 집니다. 책을 보는 제 느낌은 참 기분이 좋습니다. 회사나 학교에서 얻을 수 없는 기쁨, 바로 책 읽는 즐거움 덕택에 인생의 단 맛을 느껴 봅니다.

사람을 키우는 리더쉽은 가장 어렵다. 인내와 자제와 스스로의 괴리감과 자신감부족, 조급함때문에 쉽게 이루어 지지 않고 계속 연단되어 훈련되어져야 비로서 그 리더쉽을 통해서 조직이 발전될 수 있다.

'새로운 경험 + 상황에 맞는 교훈 * 사랑 = 성장'

이 내용은 어느 책에서 가져온 글이다. 즉 성장은 새로운 경험에 비례하지만, 상황에 맞는 교훈 과 사랑과 비교한다면 그렇게 큰 변수는 아니라는 사실이다. 즉 관리자는 사랑이라는 가장 큰 변수를 통해서 사람을 키울 수 있다. 그래서, 순간 순간 상황에 대한 놀라운 대처하는 방법을 알려주고 옆에서 인정해주고, 방향을 제시해 줄 수 있어야 한다.

하지만, 새로운 경험이 꼭 긍정적이지 않을 수도 있다. 그 때는 그들에겐 계속적인 재확신과 칭찬이 필요하다. 아끼지 말고 너는 할 수 있다, 아직 능력을 다 발휘한게 아니다. 익숙치 않아서 그렇다 하며, 확신을 주며, 이정도까지 한 게 정말 많이 오고 있다며, 관리자가 원하는 기대치만큼 오지 않더라도 격려하는 것이 중요하다.

좌절하는 팀원들에겐 더 많은 격려가 필요하다. 그러나 팀원들이 실망할 때 우리까지 덩달아 실망하는 때가 종종 있다.
그것을 잘 조절할 수 있어야 사람 키우는 조직문화를 잘 다스릴 수 있다.

결국은 사람을 키우는데 중요한 것은 바로 문제 해결 능력과 비교 될 수 있다.
문제의 마인드를 바꿀 수 있도록 해야 한다. 이 세상의 모든 조직, 관리자, 개발자들은 완벽할 수 없다. 항상 부족하고 단지 노력할 뿐이다. 문제를 어느 책에 있는 말로 바꾸어 본다.

problem 이란

predioctors 이들은 우리의 미래형성을 돕는다.
remiders 우리는 자족하지 않는다. 우리에게는 하나님과 우리를 도와줄 사람들이 필요하다.
opportunities 이것들은 우리들 틀에 박힌 모습에서 꺼내어 창의적으로 생각하게 해준다.
Blessing 이것은 우리가 대체로 통과하지 않은 문들을 열어준다.
lessons 각각의 새로운 도전이 우리의 선생이 될 것이다.
everywhere 어느 장소 어떤 사람도 여기에서 예외가 되지 않는다.
message 이것은 우리에게 잠재적인 재난에 대해 경고한다.
solvable 해결책이 없는 문제는 없다.

이렇게 문제에 대한 생각을 통해서 생산성을 높일 수 있도록, 격려를 하여 조직에 오랫동안 몸담고 그 방향을 제시해 주어야 한다. 그리고, 좋은 습관을 가질 수 있도록 격려해야 한다. 실제 조직생활 3년안에 그의 사회관, 조직관이 결정된다. 관리자는 계속적으로 팀원들에게 강조해야 한다.

'나쁜 결과 -> 부정적인 생각 -> 부정적인 생각' 이 아니라, '나쁜 결과 -> 긍정적인 생각 -> 긍정적인 생각'이 가능하도록 방향성을 제시해야 한다.

중요한 것은 주어진 상황이 맞닥뜨린 문제를 구체적으로 이해하려는 노력이지 카탈로그를 외우는지 여부가 아니기 때문이다.


철학은 남의 것을 외워서 하는 것이 아니라 자기 스스로 하는 것이다.

패턴을 학습한 프로그래머는 유지보수를 고민하게 된다. 그 것이 좋은 프로그래머이다.

리팩토링은 새로운 코드를 만들면서 미래를 향해 나아가는 프로그래밍이 아니라, 이미 존재하는 코드를 부수면서 과거로 뛰어드는 프로그래밍이다.

80:20 원칙이란 프로그램 소스코드의 80%는 소프트웨어의 전체 성능에 20%정도의 영향을 미치고, 나머지 20%가 성능의 80%를 좌우한다는 원칙을 의미한다. XML은 그래서 80%에 해당하는 소스코드에서 사용될 때 성능에 큰 영향을 주지 않지만 나머지 20%의 영역에서는 성능에 영향을 미친다.

소금을 뿌리되 넘치거나 모자라지 않게 뿌리는 요리사의 균형 감각은 음식의 맛을 좌우하는 열쇠다.

마치 중학생,고등학생들도 쉽게 읽을 수 있는 문체로서, 저자가 쉽게 써준 것에 대해서 강한 감사를 드린다.

소프트웨어 공학은 기본적으로 다양한 소프트웨어의 생산성을 높이는데 그 목적을 두고 있다. 제품이던지, 프로세스에 중점을 두고 있는 부분들이 존재하지만, 의외로 사람에 대해서는 투자하지 않는 경향이 강하다.

그리고, 사람을 중심을 두고 있어도 문화에 대해서 생각하지 않는 관리자들이 거의 없는 것 같다.
조직문화가 계속 긍정적으로 바뀌고 생산적으로 바뀌어야 함에도 불구하고, 왜 퇴보하는 것일까?

이 책을 읽고 나름대로 내 생각을 정리해서 관리자, 팀장, 팀원의 관계를 통해서 팀장의 역할을 그려본다.


소프트웨어 엔지니어가 회사에 기여도와 조직문화는 전혀 정비례는 아닌 듯 싶다. 즉, 이것은 관리자와 엔지니어간의 이질적인 간격이 존재함이 분명하다. 회사가 직원들에게 주는 불신임, 우울감, 허탈감은 분명 관리자의 책임이다.

관리자는 문화를 만들어야 한다.

팀장은 팀을 조직하고 생성하는 일만 할 뿐 아니라, 팀의 목적을 분명히 하고, 상급을 적절히 주며, 비젼을 만들어 주어야 하고, 교육을 시켜 주니어 엔지니어들의 캐리어를 높여 강한 팀을 만들 수 있도록 노력해야 한다.

개인적으로 가장 중요한 덕목은 커뮤니케이션 능력이다.
하루종일 앉아서 코딩을 하면서 신경질을 내는 사람보다는 웃으면서, 바쁘지만 여유있게 주위 팀원을 챙겨주고, 목적을 확실하게 만들어주는 일을 만들어야 하며, 항상 앞에 서서 팀의 방향성을 리드할 수 있어야 한다. 그러기 위해서는 팀원들의 사기를 복돋아 줄 수 있고, 팀원 각각의 고충을 풀어주지는 못하지만, 들을 수 있어야 한다.
또한 관리자들의 요구사항을 잘 적절하게 막아줄 수 있는 능력, 커뮤니케이션 능력이 있어야 한다.

팀의 비젼을 공유할 수 있도록 함으로서, 요구사항에 근접할 수 있도록 마음이 오픈이 되어야 한다. 진실된 작은 소리는 시끄러운 아우성보다 더 잘 들린다고 한다. 즉, 실력이 없더라도, 엉뚱한 질문을 하더라도 이해시킬 수 있어야 한다.
프로세스에 너무 얽매이지 않도록, 독력해야 한다.

두번째 중요한 덕목은 실력이다.
아무리 커뮤니케이션 능력이 좋더라도, 실력이 않좋으면, 팀원은 팀장을 무시할 수 있을 수 있다. 항상 공부하는 자세가 되어 방향성을 제시할 수 있어야 한다. 물어보는 것을 다 해결하는 사람보다는 방향성을 제시할 수 있는 사람이 되어야 한다. 팀원이 헤메는 것을 막고 바로 갈 수 있도록 가이드를 해야 한다.

세번째 중요한 덕목은 분석능력이다.
즉, 주어진 요구사항을 분명히 깨닫는 것이 중요하다. 고객의 불확실한 명세사항을 무조건적으로 따르는 것이 아니라, 고객의 가장 중요한 부분, 일을 적게 하려는 것을 캐취하는 것이 중요하다. 그래서, 간결하게, 또는 문제를 해결할 수 있는 방법을 고객에게 또는 시장에게 제시할 수 있어야 한다.

네번째 덕목은 교육 개발 능력이다.
멘토링과 코치능력, 팀원 각자의 개발능력 향상을 위한 교육, 세미나에 참석을 독려 혹은 경력관리가 가능하도록 노력해야한다.즉, 팀원들을 고객처럼 생각하고, 만족시킬 수 있는 능력을 가져야 한다. 슈퍼 소프트웨어 엔지니어가 되도록 여러가지 정보들을 줄 수 있어야 하며, 틈틈히 세미나를 이용하여 개발능력을 향상시킬 수 있어야 한다.

다섯번째 덕목은 용기이다.
관리자는 성과를 보고 싶어한다. 또는 좋다고 하는 프로세스를 팀에게 적용시키고자 한다.
팀장은 적절한 안목이 있어야 한다. 즉, 팀의 문화, 조직의 문화가 프로세스 성숙도를 측정하는 기준과 맞지 않는다면, 회사의 가치를 더 우선순위를 두어야 한다. 즉, 문화를 바탕으로 프로세스가 바뀌는 것이지, 프로세를 무조건으로 신봉해서는 되지 않는다. 관리자 혹은 팀원에게 욕을 먹더라도 중용의 자세가 중요하다.
그냥 아는 것도 아니고, 신봉도 아닌 그 중간적인 성격을 지닌 프로세스를 적절하게 이용해야 한다.

여섯번째 덕목은 계획성이다.
월요일에는 항상 일주일을 시작하는 맘으로 전체 회의를 열고, 어떤 방향으로 나가야 할지, 점검을 꼭 하도록 해야 한다. 헛다리 짚지 않도록 해야 하며, 계획적으로 나가야 한다. 각자 팀원 개개인의 역량을 체크를 해야 한다.
이 때 가장 중요한 부분은 커뮤니케이션 능력이다. 아무리 계획성을 가지고 있어도, 짜증이나 무표정으로 말하는 팀장보다는 당연히 웃으면서 즐거운 분위기에서 하는 게 훨씬 낫다.

커피를 마시고, 쇼파에 앉아서 즐거운 마음으로 주말을 어떻게 쉬었냐 하며, 부드러운 분위기에서 시작하는 것이 가장 좋다. 회의실로 바로 가는 일은 팀원들에게 경직된 마음을 줄 수 있으며, 특히 월요일이라는 분위기에 적응하지 못하는 팀원들에게는 독이 될 가능성이 높다.

가장 먼저 자신의 솔직한 얘기를 통해서 웃으면서, 월요일 아침을 잘 시작하는 방향이 중요하다.

소프트웨어 회사의 분위기가 항상 이렇지는 않을 것이다. 늘 일에 쪄들고 고생할 수 있지만, 반드시 중요한 부분은 팀장과 팀원들간의 신뢰성을 그 기반으로 하는 것이다.

이상으로 조직문화를 아름답게 바뀌기 위한 나름대로의 제안을 해보았다. 책의 내용은 참고용이고, 내가 나름대로 생각했던 부분을 반드시 적용하도록 하는 것이 가장 중요할 것이다.

글 단어나 문장자체가 어려워서 이해하기 어려운 부분이 있었다.
나름대로 이해하고, 내 언어로서 표현해 본다.

베네바 부시는 전쟁속에서 많은 고민들을 했던 거 같다. 1945년 7월 The Atlantic지에 등재한 논문 'As we may think'는 어투상에서 느끼는 많은 상황을 해결하려고 노력한 거 같다.

정보가 많아지고, 커지고, 저장을 해서 컨설팅을 받아야 하는 상황이 생기고 있다. 즉, 과거의 정보를 이용하여 새로운 이론이나 학문을 증진시켜야 할 필요성이 생기고 있다.
기계의 속도는 점점 빨라지고, 분석기가 쓰임이 효율적으로 증대되고 있다. 하지만, 지금의 컴퓨터 언어로서는 특징에 맞는 정보를 저장하기 어렵다.

또한 입력을 하고, 그 입력된 정보를 통해서, 처리되고, 분석되어서 서로간의 커뮤니케이션이 효율적으로 증대할 수 있으며, 기계에 인간이 맞춰가는 것이 아니라, 인간이 기계의 능력을 초월하는 아이디어를 통해서 기계를 보다 인간과 비슷하게 만들 수 있는 시스템을 그려 보았다.

Memex, 그 그계를 통해서 다양한 정보들을 저장하고, 그 저장된 정보들을 확장하여, 능력을 극대화시켜서, 경험을 쌓는 것, 역사학자가 주욱 역사들을 기록하는 것처럼 기록하여 인류가 저지른 문제들을 최소화하고, 실수를 다시 일으키지 않도록 하는 것이다.


이 메멕스가 html로 비슷하게 보는 경우가 있지만, 개인적으로는 이 메멕스는 일종의 Web DataBase 같은 개념으로 생각을 했다. 누가 언제든지 접근할 수 있으며, 항상 저장된 페이지를 통해서 진화하는 시스템을 생각하는 것으로 받아들인다.

부시의 논문이 어려워서 이해를 많이 하지 못해서 가슴이 너무 아프다. 영어 공부를 많이 해야겠다는 생각이 들었다..

요약본이다.

버그의 종류
1. 자료의 비정상적인 흐름을 통제하지 못해서 발생하는 버그
2. 논리의 정확하지 않은 정의에 의해 발생하는 버그
3. 프로그램의 외부의 요인(라이브러리, 운영체제, 아키텍쳐, 프레임워크)에 의해 발생하는 버그

또다른 버그의 종류 분류
1. 일관성이 없는 UI
2. 기대에 미치지 못하는 기능
3. 낮은 성능
4. 크래쉬 및 데이터 충돌

버그의 한예
STL의 자료구조에 대한 동기화 문제
-> 해결 뮤텍스를 이용하여 동기화 해결

쓰레드 사용 가이드 라인
1. 메인쓰레드로 충분한 처리가 가능하고 불가피한 이유가 없다면 불필요한 쓰레드를 만들어 구조를 복잡하게 만들지 마라.
2. 어떠한 자료구조이든 사용될 때 여러 쓰레드에 의해 이 자료구조가 접근될 수 있음을 항상 고려하라.
3. 불가피한 경우가 아니라면 여러 개의 쓰레드에서 동시에 접근 가능한 글로벌 변수와 스태틱 변수를 사용하지마라. 글로벌 변수와 스트택 변수를 사용시에는 개발 팀 전체의 코드 리뷰를 거쳐서 반드시 사용해야 하는 타당성을 입중해라.

커널오브젝트(뮤텍스, 이벤트, 세마포어)를 다룰때, 커널오브젝트의 이름 명명 규칙, 커널오브젝트의 시큐리티 속성을 조심스럽게 다루어야 한다. 제대로 짓지 않은 naming, 혹은 NULL값을 할당함으로서, 오류를 일으키지 않도록 해야 한다.

MSDN을 참조할때는 API의 설명외에도 Remarks와 Requirement를 반드시 확인해야 한다.
(용용 : API를 설계할때, 가장 중요한 점은 바로 이해하기 쉬운 문구를 써야 한다는 것이다. 글을 보고도 이해를 할 수 없다는 것은 가장 불쌍한 것이다. 특정 뛰어난 아키텍트의 api 설계 원칙에 의해서 설계되어도 다른 팀원들에게 이해되지 않는 문구로 설명해놓으면, 결국 잘못된 쓰임새로 인식하게 되고, 버그를 생성하게 되는 요인으로 작용하게 된다.
api를 설계할때는 충분하게 이해되기 쉬운 구어체가 쓰여야 하면, 적절한 예면, Remark, Requirement를 잘 기술해야 한다.
다른 팀원들에게도 쉬운 이해를 도울 수 있으며, 자신에게도 도움이 될 수 있다.)

실수를 줄이기 위한 개발 시스템, 조엘 테스트
1. 소스코드 관리시스템을 사용하고 있습니까?
2. 한번에 프로젝트의 빌드를 만들어 낼수 있습니까?
3. 일일 프로젝트 빌드(Daily Build)를 하고 있습니까?
4. 버그 추적 시스템을 운영하고 있습니까?
5. 코드를 새로 작성 전에 버그를 수정합니까?
6. 개발 일정을 지속적으로 업데이트하고 있습니까?
7. 명세서를 작성하고 있습니까?
8. 조용한 작업환경에서 일하고 있습니까?
9. 돈이 허락하는 한도 내의 경제적인 범위애서 최고 성능의 도구를 사용하고 있습니까?
10. 테스터를 별도로 두고 있습니까?
11. 프로그래머 채용 인터뷰때 코딩 테스트를 합니까?
12. 무작위 사용편의성 테스트를 수행하고 있습니까?

거시적인 관점에서의 개발추
1. 연구/개발
2. 판매/마케팅
3. 고객지원

요약본이다.

프로그램 소스코드는 고수는 더 기억을 잘한다.
실험에 따르면, 고수는 한번 이상 본 코드를 기억해내는 능력이 월등하며, 코드를 보는 순서가 다르다는것.
OOP의 고수는 짧은 시간 내에 주로 클래스들의 관계, 책임등ㅇ을 읽어낸는 반면, 하수는 주로 어떤 콘트롤 구조가 사용되었는지에 주목했다.
OOP세상에서는 아무래도 고수의 코드 이해 능력이 더 뛰어날 수 밖에 없다.

의도적 수련은 반복적이다. (전문가일수록 일주일중 공휴일까지 하루에 투입하는 의도적 수련의 양이 일정했다) 그리고, 피드백을 거의 즉각적으로 받을 수 있다는 것 , 나중에 오류 수정이 가능하다는 것, 실수에 대한 부담이 크지 않다는 것, 자신이 한 것에 대해 생각해 볼 여유가 주어진다는 것 등이다.

프로그래머의 직업적 특성
1. Use what you know
2. Fell it work
3. Share the experience
4. Wait for insight
5. Refactor to include it

수련의 의미
전무가들일수록 수련을 즐긴다.
전문가들일수록 일정 수준에 오른 이후에도 꾸준히 수련을 계속하며, 그 활동 자체에서 큰 즐거움을 얻는 것으로 알려져 있다. 고수가 되는 길은 오히려 '고수'보다 '길'에 대한 집착에 나오는 것일 수 도 있다.