긍정적 사고, 음식의 절제, 규칙적인 운동

.

프로그래머에게 필요한 5가지 덕목

         

1. 모든 걸 잘 하는 게 아닌 걸 인정하자

아무리 난다 긴다 하는 프로그래머도 모든 걸 잘 할 수는 없습니다. 어떤 프로그래머도 모든걸 경험할 수 없습니다. 이걸 모두가 인정하는게 가장 중요합니다. 기획자와 프로그래머 사이에 미묘한 긴장감이 흐르면 기획자는 “내가 만든 기획들은 다른 회사에서 이미 했던거야, 그러니 너는 나에게 반박할 수 없을 걸?”이라는 생각을 가지고 접근하게 됩니다.

가끔 프로그래머에게 와서 이거 되냐고 묻죠. 된다고 얘기하면 그 때 된다고 하지 않았냐며 기획에 넣었다 그러죠. 그런데, 된다. 한다. 할 것이다. 이게 다 같은 얘긴가요? 아닙니다. 이런 문제가 일어나는 이유는 팀웍에 문제가 있기 때문입니다. 그래서 인정해야 합니다. 너와 나, 우리 모두 모든 걸 잘하는 게 아님을.

 

2. 자존심을 세우는 건 좋지만, 쓸데 없는 자존심은 버리자

프로그래머들의 성향은 자존심이 센 경우가 많습니다. 전문직종 사람들이 다들 그렇죠. 이는 본인이 하는 일에 대한 프라이드이기도 하고 자신의 두뇌에 대한 프라이드이기도 한데, 그렇게 나쁜 것만은 아닙니다. 프라이드가 적은 사람은 그만큼 책임감도 적기 때문입니다.

하지만, 내가 해본 것과 해보지 않은 것, 할 수 있는 것과 할 수 없는 것, 빨리 할 수 있는 것과 빨리 할 수 없는 것은 냉철하게 판단해야 합니다. 그래서 “난 이 기간 동안 이걸 만들 수 없다.”고 말할 수 있어야 합니다.

 

3. 기획단계부터 참여하자

이 말을 잘 이해해야 합니다. 기획에 감 놔라, 배 놔라 하라는게 아닙니다. 기획단계에서부터 서로 대화를 하라는 겁니다. 무엇을 만들기로 했으면 어떻게 해야 쉽고 빠르게 만들수 있는지 서로 대화를 해서 내가 선택한것처럼 기획자가 선택할수 있게 되면 더할나위 없이 좋겠죠. 이는 서로에게 좋은 기회일 겁니다.

 

4. 폭넓은 지식을 쌓자

프로그래머가 너무 기술만 파면 다른 파트와 대화가 안 됩니다. 폭넓은 지식을 쌓을수 있도록 노력해야 됩니다. 그래야 기획도 할 수 있고, 기획자랑 대화도 할 수 있고, 나중에는 사업도 할 수 있습니다.

 

5. 같은 프로그래머끼리 괴롭히지 말자

“내가 만들면 3일이면 되는데 저거 만드는데 뭐 이렇게 오래걸려?” 이런 말을 입에 달고 사는 사람들이 있습니다. 어떤 미국에 좋은 학교를 나온친구가 자기가 하면 일주일이면 된다고 했습니다. 그래서 그 사람에게 일을 시켰죠. 그런데 못했어요. 한 달 넘게 걸렸을 겁니다. 그 친구가 프로그래밍 실력이 없어서 못한건 아니에요. 상대 업체가 메뉴얼을 줬는데 준데로 만들어도 안됐거든요.

모든일이 각자 다 사정이 있습니다. 위와 같은 말은 절대 해선 안됩니다.

 

 

보너스, 기획자에게 부탁하고 싶은 말

 

1. 막 던지지 말자

300명이 참여한 프로젝트와 비교하지 마세요. 특히… “엑셀처럼 만들어 주세요”, “포토샵은 되던데”, “네이트온에 있는 기능은 다 있으면 됩니다”

… 이런 말은 일진 애들이 빵셔틀한테 500원 주고 2만원 어치 사온 다음 거스름돈 가져와라는 말과 같습니다.

 

2. 프로그래머의 개인 취향과 특성을 존중하자

저는 게임회사를 다니고 있습니다. 제가 본 바로는, 아티스트들에 대해서는 취향과 경험을 존중해 줍니다. 물론 경영진 앞에서는 이런 것들이 무시되기 십상이기 때문에 나름의 고충이 있지요. 그런데 프로그래머는 더 심합니다. 프로그래머들의 장단점, 취향 따위는 아예 고려가 되지 않습니다.

기획자는 다른 회사의 제품을 벤치마킹을 해서 기획을 합니다. 그리고 프로그래머에게 기획서를 주죠. 그럼 프로그래머는 연구도 하고 삽질도 하면서 프로젝트를 진행시킵니다. 당연히 야근은 필수고 과정 자체도 만족스럽지 못하며 프로그램을 완성시켜도 질이 좋지 않습니다.

 

3. 프로그래머는 시다바리가 아닙니다

우리나라는 서비스 기획자가 최고입니다. 이 나라에 있는 대부분의 회사가 그렇게 생겼습니다. 하지만 해외에서는 프로그래머가 주도하는 회사도 많습니다. 글로벌 기업의 경우에는 더욱 그렇고요. 건축현장에서도 설계자와 현장에서 일하시는분과의 마찰이 있고, 의상디자이너와 현장직 아주머니와의 마찰이 있습니다. 그래도 이 분들은 다들 전공이 그쪽입니다. 반면 소프트웨어, 웹 기획자는 전산 전공이 아니죠.

때문에 디테일한 부분에서 프로그래머가 더 많이 아는 영역이 많습니다. 많은 기획자 분들이 따라오려 노력하지만, 그 차이는 쉽지 않습니다. 그렇다면 당연히 프로그래머를 파트너로 대해야겠지요?

 

원문: 모영철 프로그램 철학 / 편집: 리승환

http://wiki.kldp.org/wiki.php/HowToBeAProgrammer#s-3.2.1

목차

Contents

1 도입

2 초보자

2.1 개인적 기능들

2.1.1 디버그 배우기

2.1.2 문제 공간을 나눠서 디버그 하는 방법

2.1.3 오류를 제거하는 방법

2.1.4 로그를 이용해서 디버그 하는 방법

2.1.5 성능 문제를 이해하는 방법

2.1.6 성능 문제를 해결하는 방법

2.1.7 반복문을 최적화하는 방법

2.1.8 I/O 비용을 다루는 방법

2.1.9 메모리를 관리하는 방법

2.1.10 가끔씩 생기는 버그를 다루는 방법

2.1.11 설계 기능을 익히는 방법

2.1.12 실험을 수행하는 방법

2.2 팀의 기능들

2.2.1 시간 추정이 중요한 이유

2.2.2 프로그래밍 시간을 추정하는 방법

2.2.3 정보를 찾는 방법

2.2.4 사람들을 정보의 원천으로 활용하는 방법

2.2.5 현명하게 문서화하는 방법

2.2.6 형편없는 코드를 가지고 작업하기

2.2.7 소스 코드 제어 시스템을 이용하는 방법

2.2.8 단위별 검사를 하는 방법

2.2.9 막힐 때는 잠깐 쉬어라

2.2.10 집에 갈 시간을 인지하는 방법

2.2.11 까다로운 사람들과 상대하는 방법

3 중급자

3.1 개인적 기능들

3.1.1 의욕을 계속 유지하는 방법

3.1.2 널리 신뢰받는 방법

3.1.3 시간과 공간 사이에서 균형을 잡는 방법

3.1.4 압박 검사를 하는 방법

3.1.5 간결성과 추상성의 균형을 잡는 방법

3.1.6 새로운 기능을 배우는 방법

3.1.7 타자 연습

3.1.8 통합 검사를 하는 방법

3.1.9 의사소통을 위한 용어들

3.2 팀의 기능들

3.2.1 개발 시간을 관리하는 방법

3.2.2 타사 소프트웨어의 위험 부담을 관리하는 방법

3.2.3 컨설턴트를 관리하는 방법

3.2.4 딱 적당하게 회의하는 방법

3.2.5 무리 없이 정직하게 반대 의견을 내는 방법

3.3 판단 능력

3.3.1 개발 시간에 맞춰 품질을 조절하는 방법

3.3.2 소프트웨어 시스템의 의존성을 관리하는 방법

3.3.3 소프트웨어의 완성도를 판단하는 방법

3.3.4 구입과 개발 사이에서 결정하는 방법

3.3.5 전문가로 성장하는 방법

3.3.6 면접 대상자를 평가하는 방법

3.3.7 화려한 전산 과학을 적용할 때를 아는 방법

3.3.8 비기술자들과 이야기하는 방법

4 상급자

4.1 기술적 판단 능력

4.1.1 어려운 것과 불가능한 것을 구분하는 방법

4.1.2 내장 언어를 활용하는 방법

4.1.3 언어의 선택

4.2 현명하게 타협하기

4.2.1 작업 일정의 압박과 싸우는 방법

4.2.2 사용자를 이해하는 방법

4.2.3 진급하는 방법

4.3 팀을 위해 일하기

4.3.1 재능을 개발하는 방법

4.3.2 일할 과제를 선택하는 방법

4.3.3 팀 동료들이 최대한 능력을 발휘하게 하는 방법

4.3.4 문제를 나누는 방법

4.3.5 따분한 과제를 다루는 방법

4.3.6 프로젝트를 위한 지원을 얻는 방법

4.3.7 시스템이 자라게 하는 방법

4.3.8 대화를 잘 하는 방법

4.3.9 사람들에게 듣고 싶어 하지 않는 말을 하는 방법

4.3.10 관리상의 신화들을 다루는 방법

4.3.11 조직의 일시적 혼돈 상태를 다루는 방법

5 참고 문헌

5.1 책

5.2 웹 사이트

6 역사 (2003년 5월 현재) / History (As Of May, 2003)

6.1 피드백 및 확장 요청 / Request for Feedback or Extension

6.2 원본 / Original Version

6.3 원저자의 경력 / Original Author's Bio

"프로그래머가 되고 싶은데 수학을 못해요"라는 질문에 대한 답...

제가 수학성적을 60점에서 100점으로 올린방법은 아래 링크에 있습니다.
http://kblog.popekim.com/2012/05/60-1...

좋은 프로그래머가 되는 24가지 방법

http://techit.co.kr/9411

1. 프로그래밍에 열정이 있어야 한다. 열정이 없고 즐기지 못하면 평생 지속하기 어려운 일이다. 지금 환경이 있는 열정도 꺾어버릴 만큼 열악하다면 심각하게 변화를 생각해야 한다.

2. 프로그래밍 기초 원리를 이해해야 한다. 원리를 모르면 근본적인 해결능력이 떨어지고 수준 높은 개발을 하기 어렵다.

3. 문제 해결 능력을 키워야 한다. 개발자의 가장 중요한 핵심 역량이다.

4. 창의적인 사람이 되라. 대부분의 좋은 해결책은 창의력에서 나온다.

5. 다른 사람의 소스코드를 이해할 수 있는 능력을 키워야 한다. 다른 사람의 소스코드에서 많은 것을 배울 수 있다.

6. 수학을 잘 해야 한다. 수학을 못하면 값싼 쉬운 개발 밖에 못한다. 수학에 관심을 가지고 재미를 느껴보는 것도 한 방법이다.

7. 좋은 커뮤니케이션 스킬을 갖도록 노력해야 한다. 프로그래밍은 컴퓨터와 얘기하는 것이 아니고 사람들과 얘기하는 것이다.

8. 협업 능력을 키워라. 다른 사람과 일을 나눠서 할 수 있어야 내 몸값이 비싸진다. 혼자 일하는 것만 잘하면 평생 혼자 일해야 한다.

9. 논쟁(debate) 능력을 키워야 한다. 고급 개발자가 될 수록 토론하는 일이 늘어날 것이며, 좋은 토론이 좋은 소프트웨어를 만든다.

10. OOP를 완전히 이해해야 한다. OOP는 좋은 Architecture의 핵심이고, 협업능력을 키울 수 있게 해준다.

11. 남이 이해할 수 있는 문서를 작성할 수 있어야 한다. 문서 작성은 평생 따라다니는 중요한 업무이다. 문서작성을 못하는 개발자는 값싼 개발밖에 못한다.

12. 적어도 한가지의 개발언어는 완전히 마스터를 해야 한다. 마스터한 개발언어로는 어떠한 문제도 풀 수 있어야 한다. 모든 개발언어는 원리가 비슷하므로 다른 개발언어도 쉽게 배울 수 있다.

13. 적어도 한가지의 스크립트 언어를 구사할 수 있어야 한다. 간단한 툴은 쉽게 만들어 쓸 수 있다. 스크립트 언어로 쉽게 할 수 있는 일을 C언어로 작성하고 있다면 당장 Python을 공부해라.

14. 비즈니스를 이해해야 한다. 훌륭한 아키텍트가 될 것이다. 좋은 Architect는 비즈니스 전략에서 나온다. 비즈니스에 관심이 없다면 당장 돌아가는 Software는 만들 수 있어도 좋은 Architecture는 못 만든다.

15. 주변에 나보다 훨씬 뛰어난 프로그래머를 둬라. 끊임 없이 배울 수 있다. 주위의 뛰어난 개발자를 경쟁상대라고 생각하지 말고 스승으로 생각해라. 그도 나를 스승으로 생각할 것이다.

16. 끊임 없이 새로운 기술을 익혀라. 전쟁에서 쓸 무기가 많아질 것이다. 몇 가지 소수의 익숙한 기술만 고집하면 도태될 수 있다.

17. 습관적으로 주석을 달아야 한다. 주석은 남을 위해서 다는 것이 아니고 프로그래밍의 일부이다. 주석이 없어도 이해가 가능한 코드를 작성하는 것이 좋지만 그래도 주석은 꼭 필요하고 Doxygen등의 주석을 꼭 이용해라.

18. 남이 이해하기 쉬운 코드를 작성해야 한다. 나중에 내 발목을 잡지 않을 것이다. 내가 좀더 위로 올라가기 위해서는 아래가 자유로워야 한다.

19. 리뷰와 친해져야 한다. 평생 리뷰를 하며 사는 것이 프로그래머의 인생이다. 리뷰를 하지 않으면 발전하기 어렵다. 리뷰는 지금 프로젝트의 문제도 해결해줄 뿐만 아니라 내 프로그래머 인생의 가장 좋은 스승이다.

20. 건강을 유지해라. 건강을 잃으면 실력이고 뭐고 다 필요 없다. 야근도 좋지만 좋은 음식을 먹고 꾸준히 운동도 하자.

21. 좋은 의자를 사라. 건강을 지켜주고 효율을 높여준다. 프로그래머에게 의자는 침대보다 오래 머무르는 곳이다. 비싸고 좋은 의자일수록 좋다.

22. 인생을 즐길 줄 알아야 한다. 프로그래머로 오래 지속하고 싶으면 인생 자체를 즐기는 다양한 방법을 익혀야 한다.

23. 소프트웨어 공학을 익혀라. 주먹구구식 개발에서 벗어나게 해주고 프로그래밍이 더 이상 노동이 아니고 즐겁게 개발을 하게 해준다. 스펙과 설계문서를 작성하고 좋은 개발시스템하에서 적절한 프로세스를 적용해서 개발하는 것이 가장 빠르게 소프트웨어를 개발할 수 있는 방법이라는 것을 경험하고 깨달아야 한다.

24. 높은 연봉을 받을 수 있도록 꾸준히 노력하라. 위의 23가지 방법들을 따라 한다면 저절로 연봉이 높아질 것이다.좋은 프로그래머가 되기 위해서는 주변의 환경도 중요하지만 본인의 의지나 습관도 매우 중요하다. 주어진 환경에 수동적으로 적응하기 보다는 좋은 프로그래머가 되기 위한 자신만의 방법들을 만들어 나가면 좋겠다.

왠만하면 후기 안쓰는데. 책 초반부의 인용구만 조금 정리해 보겠다.

알지 못하며 그 사실도 모르는 자, 바보로다. - 그를 멀리하라!
알지 못하나 그 사실을 아는 자, 못 배운 자로다. - 그를 가르치라!
알고 있으나 그 사실을 모르는 자, 잠든 자로다. - 그를 깨우라!
알고 있으며 그 사실을 아는 자, 깨우친 자로다. - 그를 따르라!
- 이자벨 버턴 부인(Lady Isabel Burton)(1831~1896)이 저서 "The Life of Captain Sir Richard F.Burton" 중에서 인용한 아랍 속담

이 책의 목표는 우리가 전문 소프트웨어 개발이라는 분야의 새내기로서 맞닥뜨리게 될 힘든 결정의 시기에 도움을 주고자 하는 것이다.
초년병 시절에 봤었더라면 조금 더 도움이 되지 않았을까 하는 생각이 드는군.

패턴 언어는 그것을 사용하는 각 사람에게 새롭고 독특한 건물을 무한히 다양하게 창조할 수 있는 힘을 부여한다. 이것은 그가 통상적으로 사용하는 언어가 그에게 무한히 다양한 문장을 창조하는 힘을 주는 것과 마찬가지다.
- 크리스토퍼 알렉산더, "The Timeless Way of Building", p.167

소프트웨어 장인정신 선언

뜻을 품은 소프트웨어 장인으로서, 우리는 소프트웨어 개발을 수련하고 다른 이들의 학습을
돕는 것으로 전문적인 소프트웨어 개발의 기대치를 높이고 있다. 이와 같은 작업을 통해 우리는 아래와 같은 결론에 이르렀다.

   우리는 동작하는 것을 넘어서 잘 짜인 소프트웨어에,
   변화에 대응할 뿐 아니라 지속적으로 가치를 더하는 일에,
   개인들 그리고 그 사이의 상호작용에 더해서 전문가들의 공동체에,
   고객과의 공동 작업 뿐 아니라 생산적인 파트너십에 가치를 둔다.
   즉, 우리는 왼편의 항목을 추구함에 있어서 오른편의 내용이 필수불가결함을 알게 되었다.

-------------------------------------------------------------------------------------------------------------------------

견습과정은, 기예를 통달하겠다는 필생의 열정을 서서히 불어넣는다는 점에서 중요하다.
이는 끊임없이 배우고자 하는 열정을 점점 쌓이게 하며, 그런 과정 속에서 견습생은 탁월한 개발자가 될 수 있다. - 피트 맥브린, "Software Craftsmanship"


견습과정이란 무엇인가?
학습 상황이란 본질적으로, 자기가 무엇을 하고 있는지 정말로 알고 있는 누군가르 ㄹ도우면서 배워가는 상황이다. - 크리스토퍼 알렉산더 외, "A Pattern Language", p.413

우리는 견습 개발자들을 양성하는 데 필요한 시간을 감수해야 한다. 왜냐하면 우리가 당면한 문제는 희소함이 아니라 풍부함에 있기 때문이다. (중략)
오늘날 개발자들은 필요 이상으로 많지만, 좋은 개발자는 부족하다.
- 피트 맥브린, "Software Craftsmanship", p.93

특정한 기술 분야에 집착하지 말고, 개별 상황에 알맞은 해법을 고를 수 있도록 광범위한 배경 지식과 경험을 충분히 쌓아두어야 한다. - "실용주의 프로그래머", p.xviii

첫 번째 언어
훌 륭한 표기법은 두뇌로부터 모든 불필요한 일을 덜어줌으로서 좀 더 높은 수준의 문제에 자유롭게 집중할 수 있도록 해주면, 실제로 인류의 지적 능력을 고양시킨다. 어떤 업계든 그 속에서 쓰이는 기술적인 용어들은 사용법을 훈련 받은 사람들이 아니면 이해하기 힘든데, 이 용어들이 어렵기 때문에 그런 것은 아니다. 오히려 그런 용어들은 언제나 일을 더 쉽게 만들 목족으로 고안되어 왔다.
 - 알프레드 노스 화이트헤드, "An Introduction to Mathmatics"

흰 띠를 매라!
대개 발걸음 하나하나마다 새로 시작한다는 느낌이 들어야 한다.
이것이 초심이며, "되고 있음"의 상태다.
- 순류 스트키(Shunryu Suzuki), "Zen Mind, Beginner's Mind"
 
위 로 오르기 위해서는 당신이 이미 잘 하는 것을 내려놓아야 한다. 그리고 골짜기로 미끄러져 내리기도 하면서 단단히 디디고 선 곳을 떠나야 한다. 만약에 이미 잘 하는 것을 내려놓지 않는다면, 꾸준히 진전할지는 몰라도 고지에는 결코 오를 수 없을 것이다.
- 제리 와인버그, "Becoming a Technical leader", p.42

열정을 드러내라

장 인들은 소프트웨어 개발이라는 기예를 기꺼이 배우고자 하는 열성적인 견습생만 채용한다.  견습생들은 소프트웨어 장인정신 개념에서 필수적인 부분이다. 그들은 일에 대한 의욕과 배움에 대한 추진력을 가지고 와서는 다른 모든 이들에게 퍼뜨리기 때문이다.
- 피트 맥브린, "Software Craftsmanship"

전반적인 이해력은 서로 다른 여러 수준의 경험이 상호 연관될 때 더욱 높아질 수 있다. 그 무엇도 당연하게 여기지 않는 신참들과, 알 것은 다 안다고 생각하는 고참들이 더 자주 밀접하게 소통할 때가 거기에 해당된다.
- 칼 와익,칼린 로버츠, "Collective Mind in Organizations", p.366

견 습생은 장인들로부터 배움을 얻지만, 장인도 견습생에게서 배운다. 열정이 있는 초보자는 장인을 스스로 일신하게 할 뿐 아니라 외부에서 들여온 새로운 아이디어로 장인의 의욕을 불러일으킨다. 잘 선택된 견습생은 마스터마저도 더욱 생산적이 되게 할 수 있다.
- 피트 맥브린, "Software Craftsmanship"

구체적인 기술
지식을 가진 것, 그리고 그 지식을 써서 소프트웨어를 만들어 내는 역량과 실무 능력을 갖춘 것은 다르다. 여기에 장인정신의 역할이 있다.
- 피트 맥브린, "Software Craftsmanship"

무지를 드러내라
내일 나는 더 어리석게 보일 필요가 있으며, 거기에 대한 느낌도 더 나아질 걱이다. 가만히 있으면서 일이 어떻게 돌아가나 살피는 것은 별로 효과가 없는 것 같다.
- 제이크 스크럭스(Jake Scruggs), "My Apprenticeship at object mentor"

무지에 맞서라
만 일 우리가 독립성을 가치 있게 여긴다면, 현재 체제의 지식, 가치, 사고방식에 내 생각을 맞추려는 경향이 점점 늘어가는 것이 불안하다면, 우리는 자신의 유일함에 대해 스스로 방향을 잡아가는 법에 대해, 자발적으로 학습하는 법에 대해 배울 수 있는 환경을 조성하고자 할 것이다.  - 칼 로저스(Carl Rogers), "On Becoming a Person"

깊은 쪽
무참한 실패를 맛본 적이 한 번도 없다면, 당신은 뭔가 가치 있는 일을 시도했던 적이 한 번도 없었다고 봐야 한다.
 - 크리스토퍼 호킨스, "So You Want To Be a Software Consultand?"

한발 물러서라
당 신이 가려는 곳을 바라본 다음에 지금 어디쯤 있는지를 보면, 항상 터무니 없다는 생각이 들 겁니다. 그러고 나서 당신이 걸어왔던 길을 돌아보고 있노라면 그 속에서 어떤 패턴 같은 것이 드러날 거예요. 그 패턴으로 당신의 앞길을 비추어 본다면, 가끔은 그 무엇인가를 찾아낼 수 있을 겁니다.
 - 로버트 퍼식(Robert Pirsig), "Zen and the Art of Motorcycle Maintenance"