프로그래머 혹은 해커로써의 철학들..

1. 필요는 발명의 어머니이다.

2. 좋은 프로그래머는 어떤 프로그램을 만들어야 할 지 안다.
위대한 프로그래머는 어떤 프로그램을 다시 만들어야 할 지 (그리고 재사용해야 할 지) 안다.
(Good programmers know what to write. Great ones know what to rewrite(and reuse))

위대한 프로그래머의 중요한 특징 중 하나는 건설적인 게으름이다. 그들은 들인 노력으로가 아니라 결과로 평가받는다는 것을 알고 있으며 완전한 무에서 시작하는 것보다는 부분적으로나마 좋은 해결책에서 시작하는 것이 거의 항상 더 쉽다는 것을 알고 있다.

- 에릭 S. 레이먼드의 『성당과 시장』中...

3. ``가지고 있는 것을 버릴 계획을 세우라 ;
언젠가는 버리게 될 것이다 (Plan to throw one away; youu will anyhow)''

4. 적절한 태도를 가지고 있으면 흥미로운 문제가 당신을 찾아갈 것이다.
(If you have the right attitude, interesting problems will find you)

5. 프로그램에 흥미를 잃었다면 프로그램에 대한 당신의 마지막 의무는
능력있는 후임자에게 프로그램을 넘겨주는 것이다.
(When you lose interest in a program,
your last duty to it is to hand it off to a competent successor)

6. 사용자들을 공동개발자로 생각하면 코드가 다른 어떤 방법보다도
빠른 속도로 개선되며 효율적으로 디버깅할 수 있다.
(Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging)

7. 일찍 발표하고 자주 발표하라. 그리고 사용자들의 소리에 귀를 기울이라.
(Release early. Release often. And listen to your customers)

8. 충분히 많은 베타테스터와 공동개발자가 있으면 거의 모든 문제들은
빨리 파악될 것이고 쉽게 고치는 사람이 있게 마련이다.
(Given a large enough beta-tester and co-developer base,
almost every problem will be characterized quickly and
the fix obvious to someone)

9. 자료구조를 훌륭하게 만들고 코드를 멍청하게 만드는 것이 그 반대의 경우보다 훨씬 잘 작동한다. (Smart data structures and dumb code works a lot better than the other way around)

10. 베타테스터들을 가장 중요한 자원으로 여긴다면 그들은 정말 가장 중요한 자원이 되어준다.
(If you treat your beta-testers as if the're your most valuable
resource, they will respond by becoming your most valuable resource)

11. 좋은 아이디어를 생각해내는 것 다음으로 중요한 일은 사용자들이 알려준
좋은 아이디어를 깨닫는 것이다. 때로는 이편이 더 나을 수도 있다.
(The next best thing to having good ideas is recognizing good ideas
from your users. Sometimes the latter is better )

12. 종종 가장 충격적이고 혁신적인 해결책은 당신 자신이 문제에 대해서 가지고 있는 개념이 잘못되어 있다는 것을 깨닫는 것에서 나온다. (Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong)

13. ``(설계에 있어서) 완벽함이란 더 이상 추가할 것이 없을 때
이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다.
(Perfection (in design) is achieved not when there is nothing
more to add, but rather when there is nothing more to take away)''

14. 어떤 도구든지 기대하는 방법으로 쓸모가 있어야 하지만
정말 위대한 도구는 사용자가 전혀 기대하지 않았던 용도에 알맞게 된다.
(Any tool should be useful in the expected way,
but a truly great tool lends itself to uses you never expected)

15. 어떤 종류든 게이트웨이 소프트웨어를 만들려고 한다면 데이터 스트림에
가능한 한 최소한의 조작만 가하라 -- 그리고 수신자가 강제로 하게 하지 않는다면
정보를 *절대로* 잘라버리지 말라.
(When writing gateway software of any kind, take pains to disturb
the data stream as little as possible -- and *never* throw away
informtion unless the recipient forces you to!)

16. 언어가 튜링-컴플리트하지 않다면 구문상의 유연성이 필요하다.
(When your language is nowhere near Turing-complete,
syntactic sugar can be your friend)

17. 보안시스템은 그것이 보호하려고 하는 비밀만큼만 안전하다.
가짜 비밀들에 주의할 것.
(A security system is only as secure as its secret.
Beware of pseudo-secrets)

18. 재미있는 문제를 풀어보고 싶다면 자신에게 재미있는 문제를
찾아 나서는 것부터 시작하라.
(To solve an interesting problem, start by finding a problem
that is interesting to you)

19. 개발 조정자가 최소한 인터넷만큼 좋은 매체를 가지고 있으며
강제력을 사용하지 않고 어떻게 이끌어야 할 지 알고 있다면
한 명 보다는 여러명의 리더가 필연적으로 더 낫다.
(Provided the development coordinator has a medium at least
as good as the Internet, and know how to lead without coercion,
many heads are inevitable better than one)