프로그래밍 관련 이야기

프로그래밍 관련 이야기 입니다 (불펌 자료임) 정리하다 나온건데, 재미있게 읽은거라 뒷북이지만 올려봐요~ ㅎㅎ 1. "오늘까지"라는 말은 "내일 아침까지"라는 말이다. (응용 : "금요일 저녁까지" 라는 말은 "월요일 출근전까지"라는 말이다.) 2. 프로그램은 내가 원하는대로 움직이지 않는다. 타이핑대로 움직인다. 3. 요구 사양은 프로그램을 완성한 후에 추가된다. 기본 사양은 완성품을 고객이 보고 나서 결정된다. 상세 사양은 사용자가 프로그램을 사용해 본 이후에 결정된다. 4. 소프트웨어 설계에는 두 개의 방법이 있다. 하나는 결함이 있을 수 없을 정도로 단순하게 만드는 방법이다. 다른 하나는, 분명한 결함을 눈치채기 어려울 정도로 복잡하게 만드는 방법이다. 5. 코드는 개발 현장에서 사용하는 것이 아니라 납품처에서 사용하는 것이다. 디버그는 납기일까지 하는 것이 아니라, 납품된 이후에 하는 것이다. 6. 프로그래머를 죽이기 위해서는 칼이 필요없다. 프로그램의 요구조건을 3번만 바꾸면 된다. 7. 다른 사람을 믿으라. 그 사람이 해결해줄지도 모른다. 주의사항 - 먼저 자신을 의심해라. 8. 개발에 마지막은 없다. 출시만이 있을 뿐이다. 9. 클라이언트의 요구사항이 제 아무리 뒤늦게 추가되어도 납기일은 변하지 않는다. 이것을「납기 불변의 법칙」이라고 한다. 10. 우리의 고객들은 물과 기능추가를 공짜라고 생각하고 있다. 11. 주머니가 짠 고객일수록 잔소리가 많다. 12. 개발 스케줄은 산수를 무시하며 짜여진다. 영업과는 1＋1=2를 이해하지 못하는 사람의 모임이다. 13. 한 명이 쓰러지면 모두가 쓰러진다. 14. 버그가 너무 심하다? 걱정마라. 어느 순간 그것은 기본 사양이 될 것이다. 15. 좋은 설계는 한 명의 천재보다 세 명의 범재를 요구한다. 나쁜 설계는 백명의 범재보다 한 명의 천재를 요구한다. 16. 고객에게 시스템 엔지니어는 부하이며, 프로그래머는 가축이다. 시스템 엔지니어에게 고객은 돈이다. 프로그래머에게 고객은 보이지 않는 악성 바이러스다. 17. 돈과 시간만 있으면, 그 어떤 시스템이라도 만들 수 있다고 생각하는가? 웃어라. 그 기회는 영원히 주어지지 않는다. 18. 품질은 사양 변경의 수와 규모에 의해, 얼마나 열화될지 결정된다. 19. 영업과는 공상이 실현된다고 생각하는 몽상가이다. 시스템 엔지니어는 넘을 수 없는 벽이 없다고 믿는 모험가이다. 프로그래머와는 몽상가와 모험가에 의해 칠흑의 바다에 내던져진 표류자이다. 20. 유능한 프로그래머가 프로그램 설계개념도를 받아들고 최초로 하는 일은, 프로그램의 목적을 이해하는 것이다. 그리고 그 다음으로 하는 일은, 지정된 방법과 시간 안에는 도저히 그 목적을 완수할 수 없다는 사실을 시스템 엔지니어에게 이해시키는 일이다. 21. 프로그램이란, 운과 감에 의해서 작성되는 기적이다. 운과 감이 없다면, 그 기간 내에 그러한 목표를 실현될 수 있을 리 없다. 따라서 사양 변경은 기적에 트집을 잡는 건방진 행위이며, 사양 추가는 기적이 두 번 일어날 것으로 믿는 무모한 행위이다. 22. 시스템 엔지니어는 지구력, 프로그래머는 순발력. 23. 정시에 퇴근하면, 일이 늘어난다. 24. 완벽한 프로그램은 완벽한 시간과 돈을 필요로 한다. 미국의 국가 예산을 무제한으로 사용하는 NASA마저도, 아직 시간과 돈이 부족하다고 한다. 25. 눈으로 훑어볼 틈이 있다면 움직여라. 뇌세포보다 CPU가 더 해석이 빠르다. 그리고, 그 사이, 쉴 수 있다. 26. 불편함을 버그라고 부를 것인가, 사양 상의 제한 사항이라고 부를 것인가는 남겨진 개발일자와 납기일에 의해 결정된다. 27. 정장 대신 캐쥬얼을 입고 출근하는 "캐쥬얼 데이"를 세간에서는 휴일이나 공휴일이라고 부르는 것 같다. 28. 프로그램은 머리로 기억하지 않는다. 몸으로 기억한다. 29. 내일 쉴 수 있다면 오늘 죽어도 괜찮다. 30. 고객은 거짓말을 한다. 영업은 꿈을 말한다. 시스템 엔지니어는 공상을 이야기한다. 프로그래머는 과묵해진다. (혼잣말은 많아진다) 31.「네, 할 수 있습니다」라고 말하기 전에 10초만 곰곰히 다시 생각해보라. 32. 프로그래머는 1분 생각하고 1일을 코딩에 소비한다. 1시간 생각하고 1시간 코딩하는 대신에 말이다. 33. 납품 이후의 디버그는 버그를 부른다. 34. 세 개의 디버그는 하나의 버그를 낳는다. 이것을 버그의 엔드리스 루프라고 한다. 35. 안 좋은 예감은 반드시 적중한다. 그러나 프로그래머는 그 안 좋은 예감에 반응하지 않는다. 그것은 시스템 엔지니어의 일이다. 36. 아수라장을 해결할 수 있는 방법은 오직, 고객이 돈을 지불하는 것 뿐이다. 37. 아마추어는 버그발견의 천재이다. 38. 아, 그건 마이크로소프트에서만 가능한 주문입니다. 39. 프로그래머가 불만이라고 생각하는 부분은 고객도 반드시 불만이라고 생각한다. 40. 건강하기 때문에, 건강을 해친다. 41. 그건, 당신이 말한 요구조건입니다만. 42. 아, 개발실의 창문은 안 열립니다. 그 이유는 옛날에 한 프로그래머가 그 창문에서··· 43. 고객은 최악의 사태를 믿지 않으며, 그 사태에 대한 준비를 악질적인 비용청구라고 생각한다. 시스템 엔지니어는 최악의 사태를 대비하고 준비하려 한다. 프로그래머는 최악의 사태를 누구보다 잘 예상하지만, 무시한다. 44. 만약 다른 직업을 갖게 된다면, 정시퇴근을「도망」이라고 부르지 않는 직업이 좋을 것 같다. 45. 시스템 엔지니어가 프로그래머에게 말하는「상식」은 3시간마다 변한다. 46. 최소한 자기가 쓴 시방서는 읽어주세요. 47. 고객이 시스템 엔지니어에게 사랑받는 방법은, 시스템 개발에는 시간이 곧 돈이라는 사실을 깨닫고 빨리 최종요구조건을 확정하는 것이다. SE가 고객에게 사랑받는 방법은, 프로그래머에게 미움받는 것이다. 48. 납기일이란, 작업현장이 우리 회사에서 고객의 회사로 바뀌는 날을 의미한다. 49. 가끔 일어나는 버그는 버그가 아니다. 스펙이다. 50. 개발비의 30%는 프로그램의 요구조건을 확정하는데 사용된다. 개발비의 30%는 프로그램의 요구조건을 변경하는데 사용된다. 개발비의 30%는 프로그램의 버그를 잡는데 사용된다. 개발비의 10%만이 프로그램의 개발에 사용된다. 출처불명 * 나쁜 코드에 대해 설명하지 말고, 코드를 새로 짜라 . * 100번 듣는것보다 10번 해보는게 낫고, 10번 해보는것보다 1번 책보는것이 현명한 판단이다. 책에는 100번 이상의 경험이 녹이있다. * 수레바퀴를 다시 발명할 필요는 없다. 다만 그놈의 바퀴가 이미 있는지 영어를 모르면 확인하기가 힘들 뿐이다. * 끝없이 의심(소스코드, 팀원, 관리자)하라. 항상 최악의 사태를 생각해야 한다. 이는 근본적으로 발전의 원동력이 된다. * 논쟁이 일어나면 자리를 떠라. 팀 내에서 알 수 없는 신비감과 심오함으로 자신을 포장하라. 이는 끊임없는 노력을 필요로 한다. * 열정이 없다면 이 일은 대학 나와서 하는 직업이 아니라 인생의 실패자 들이 모여 하는 노가다판이다. * 아랫사람에게 물어보는것을 부끄러워 하지 마라. * 개념 없는 초급 개발자와 책임감 없는 중급 개발자는 프로젝트 초기에 과감히 교체해야 한다. 독을 키우는 짓이다. * 타소스에서 문제점을 발견했다면 절대 미리 해결하지 말라. 문제가 터지기 전에 해결해봐야 당신에게 득되는게 없다. (물론 당신이 PM이 아니라면) * 그가 짠 소스에서 문제점을 발견했다면 이것이 커지기 전까지는 절대 먼저 알려주지 말라. 존경받는 프로그래머가 되는 비법이다. * 회사에서 짤리고 싶지 않은가? 모든 소스코드를 나만이 알아 볼 수 있고 수정 가능하도록 짜라. (물론 주석은 금지다) * 잘난척 하는 사람으로 평가되기 싫다면 절대로 그사람이 짠 코드의 문제점을 지적하지 마라. * 그를 설득하려고 노력하지 마라. 개발자의 고집은 답이 없다. 단 책임범위는 명확히하라. 언젠가 사고가 터질테니.. * 내 코딩 철학을 남에게 강요하지 말라. 그것은 종교와도 같아서 타인의 반감만 살 뿐이다. * 팀에서 나대지 말라. 대신 없어서는 안될 사람이 되어라. 능력을 숨기고 할 줄 알아도 요구하기 전까지는 하지 마라. * 기술은 부익부 빈익빈 효과가 크다. 서둘러 할수록 많은것을 얻게된다. * 이런 류의 질문에 대한 대답은 미묘하지만 격렬한 논쟁을 불러 일으키기 쉽다. 논쟁의 중심에는 항상 극단적인 순수주의와 허무주의 간의 충돌이 존재하며, 파국의 소용돌이 속에서 개념적 편향을 막기 위한 최선의 방법은 논쟁의 대상이 출현하게된 배경과 현재의 개념이 정립되기까지의 과정을 살펴 보는 것이다. 1. http://aeternum.egloos.com/category/SoftwareArchitecture/page/1 * 옛말에 "운전과 프로그래밍은 친한사람에게 배우지 말라" 학습 1. 초보때는 프로그램을 짜지 마라. 대신 잘 짜놓은 프로그램을 읽어라. (JDK의 Collection패키지 등) 2. 넓고 앝게 알아라. 당장 사태를 해결할 스킬은 몰라도 어떤 스킬의 종류를 사용해야 하는지는 알아야 한다. 1. 기술은 사건이 터졌을때 책이나 구글링으로로 배워서 하면 된다. 2. 하지만 구글링에 어떤 단어를 입력해야할지 모른다면 난감하다. 3. 독서 1. 정독 보다는 다독하고 시간을 두고 여러번 읽어라. 1. 어설픈 서평 보다는 목차를 먼저 읽고 책을 판단하라. 2. 책에있는 내용이 절대적이지는 않다. 1. 책의 저자가 나보다 더 무지할 수도 있다. 2. 중요하고 납득 가는 핵심만 빠르게 학습하자. 커뮤니티에서 질문하기 전에 1. http://oops.org/?t=lecture&sb=beginner&n=1 2. http://sunnykwak.egloos.com/4465577 개발자 뽑기 1. 같이 일해보지 않은 초면이라면 1. 단가가 맞고 출퇴근 거리가 짧은 사람. 2. 자신감이 넘치는 사람. 고학력 / 고학벌자. 3. 말을 조리있게 잘하는 사람. 커뮤니케이션이 잘 되는사람. 4. 급여 이외의 요구사항을 달지 않는 사람. (근퇴 등) 2. 구면이라면 1. 실력있는사람. 책임감 있는사람. 잘 노는사람. 아는척 해야하나? 모르는척 해야하나 ? 1. 외부적으로, 들킬 위험이 없다면 아는척 해야한다. 1. 특히나 "갑" 등의 비전문가를 설득시킬때 유용하다. 2. 내부적으로는 모르는척 해야 한다. 1. 정직이든 프리랜서든 잘 한다고 소문나면 더 많이 일을 시킨다. 물론 보수는 똑같다. 2. 회사 내에서 승진하고 싶다면 일을 '잘'하는 것 보다 세력이나 인맥을 키울것! 3. 개발자들 끼리는 솔직해야 한다. 1. 상대가 개발자라면 어설프게 알고 비판을 하거나, 잘 아는 척하는 것은 별로 좋지 않다. 1. 개발은 인문학이 아니다. 대화만 좀 해봐도 뻥인지 아닌지 금방 탄로난다. 2. 모르는걸 표현하고 더 많이 배울 수 있다. 잘 아는건 가르쳐 줘서 자신의 수준을 어필하자 한국 SI에서의 조언 1. 대다수의 프로젝트는 무리한 일정을 잡고 공표하지만 그 누구도 그 일정이 가능하리라 생각하지는 않는다. 1. 썩는 냄새가 진동하지만 대다수 조직은 현실을 감추려고 탈취재를 뿌려댄다. 2. 구지 여기다 대고 프로젝트가 성공할 가망이 없다는 말을 하지 마라. 불평분자로 취급될 뿐이다. 2. 당신이 유지보수할게 아니라면 따로 시간을 내어 리팩토링(또는 주석)하지 마라. 1. 당신이 유지보수를 할지.. 또는 타 업체가 유지보수를 할지는 아무도 모른다. 2. 남을 위해 구지 당신의 시간을 투자할 필요는 없다. 당장은 날코딩을 하고 일찍 퇴근해서 건강을 유지하라. 3. 유지보수가 쉽게 만들어놓을 경우 후발 업체가 사업을 가져가면 큰 손해를 본다. 4. 폭탄 돌리기 게임의 희생자가 되고싶지 않다면 무리해서 소스를 개선하려는 시도를 하지 마라. 3. 시간이 걸리더라도 가능한 부분은 재사용 할 수 있게 만들고 소스코드를 (당신을 위해서)모아라. 1. 오랜 경력에 남는건 이거뿐이다. => 무수히 많은 오픈소스가 있긴 하지만 결국 자신이 써봤거나 만든게 가장 쓰기 쉽다. 4. 개발을 즐기면서 하고 업무시간에 충분히 웹서핑 하라. => 중요한건 당신의 "퇴근시간" 뿐이다. 5. PM에게 만만하게 보이지 마라. 당신의 일만 무수히 늘어날것이다. 사람이란 동물은 잘해주면 잘 해줄수록 사람을 만만하게 본다. 1. 옛 속담 : 가는말이 고우면 사람을 얕본다. / 고생끝에 골병난다. / 원수는 회사에서 만난다. 2. 일을 빨리 하지 말라. 더 많은 일이 주어질 것이다. => 내가 일을 끝낸것을 PM이 알게 하지 말라. 6. 부사수가 들어왔다면? 1. 싸가지 없고 열의가 없는 놈은 과감히 버리자. 2. 될성싶은 놈에게는 부처의 자비를 => 아무 댓가 없이 가르쳐 주라. 풍청양이 영호충에게 독고구검을 전수했듯이.. 7. 가장 무서운 현업의 말 : "내가 이해할 수 있게 설명해 주세요." 8. 영업력과 로비/정치/제안서로 결정된다. 여기에 많게는 사업비의 30~70% 이상이 들어갈수도 있다. 고로 업체를 잘골라야 한다. 9. 명심하라. 내가 만족시켜줘야 하는 최고의 이해당사자는 고객이 아니라 PM또는 나의 직속상관이다. 퍼온글 1. - 자바서비스넷 ㅋㅋ 1. SI는 아주 효율적인 프로그램 만들어 장비를 덜 쓰면 아주 싫어합니다. 1. 프로그램이 비효율적이어서 하드웨어가 많이 필요해야 견적이 많이 나오고 2. 견적이 많이 나와야 을도 좋아하고 갑 관리자들도 떡고물을 많이 먹습니다.. 3. 그래서 갑 관리자는 효율적인 프로그램을 싫어 합니다. 2. 게다가 일을 간소화시켜주는 프로그램도 싫어합니다. 1. 현업들은 자기가 하는일이 아주 대단하고 복잡하고 어렵다고 믿고있고 그일을 처리하는데 자부심을 가지고 있습니다. 2. 그런데 프로그래머가 와서 간단히 처리하는 프로그램 만들면 배알이 꼴리죠.. 3. 그래서 이러니 저러니 헛소리하면서 자꾸 시스템을 얼렵고 복잡하고 꼬인 쪽으로 유도합니다. 4. 그래서 SI 프로그램은 쓰레기가 되고 쓰레기가 되어야 관리자 현업 업체들 모두 만족합니다. 3. 쓰레기장안에서 꽃을 피우려고 하지는 마세요.. 욕먹고 ?겨납니다. 2. 30대는 실력으로 먹고 살고, 40대는 30대 쌓은 명성으로 먹고 살고 50대는 인맥으로 먹고 산다 공돌이에 대한 실화 어느날 회사에서 한달은 걸릴듯한 프로젝트를 내줌 그리고 '3일 내에 끝내세요' 당연히 72시간 꼴닥 하고도 못끝냄 그럼 와서 미친듯이 까임 '일이라고 합니까? 거참 이런 쓸모없는 놈들을 쓰니까 회사꼬라지가 이러지. 뭐해요 사표 안내고 병신들아' 그렇게 죽도록 까이고 4일을 더 줌 '총합 일주일이니까 닥치고 끝내세요. 못끝내면 너님 다 모가지' 가금 의뢰기업 대표가 와서 진척상황 묻고 황당하다는듯이 '아직도?'드립을 날려줌 4일동안 다시 꼴닥 새서 겨우 마무리 알고보니 한달 걸릴 일이 맞음 윗사람과 의뢰기업 대표가 낄낄거리면서 담소를 나눔 '병신들, 역시 쪼으니깐 되네' 최적화 관련 조언 1. 하지마라. 2. (할수있더래도) 아직은 하지마라..100%확신이 서기전까지 3. 최적화가 정말로 필요한지 다시한번 확인하라. 4. 병목지점을 정확히 파악하고 있는지 다시한번 파악하라. 소프트웨어 업계의 오랜 격언들 1. 추측하지 말고 계측하라. 2. 컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 짤 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다. - Refactoring 3. SQL(RDBMS가 아님)은 유해하고 가능한 그것을 가지고 작업하지 말아야 한다. (By 로드존슨) 4. 미학적 만족을 위해 새로운 메소드를 만드는 것이 의미 없이 느껴질 때가 있다. 허나 코드의 느낌은 패턴보다 중요하다. (By 마틴파울러) 5. 프로그래머가 가장 경계할것은 코드의 중복이다. (By 마틴파울러) 6. 질문사항을 물어보기 RTFM (Read The Fucking Menual) 7. 화성에서온 개발자, 금성에서 온 고객.. 버뜨.. 제일 큰 문제는 안드로메다에서 온 설계자. (By 조엘) 8. 정말 그 몇 나노초를 줄이는 것이 반드시 필요한지 다시한번 생각해 보라. 9. 최고로 가는 최적의 길 : 전문가들이 사용하는 도구와 기법, 방식을 배우고 따라한다. 10. 멍청한 개발자는 자신의 경험에서 배우고, 똑똑한 개발자는 남의 경험에서 배운다. 11. 딜레이된 프로젝트의 후반부에 인력을 더 투입하면 일정은 더 늦어진다. => 설명하는것보다 직접 하는게 쉬울 수 있다. 12. 익숙한것이 올바른것은 아니다. 모르면 복잡하게 보인다. 하지만 알고나면 풍부하게 보인다. (By Holub on 디자인 패턴) 13. 이미 지연된 프로젝트에 추가 인력을 투입하는것은 일정을 더 늦출 뿐이다. - 프레데릭 브룩스 (맨먼스 미신) 1. 응용 : 0임산부가 아이를 낳기 까지는 9개월이 걸린다. 임산부가 몇명인것은 중요하지 않다. 14. 어떤 프로그래머에게 한 가지 문제가 있었다. 그는 ‘정규표현식을 이용하면 해결할 수 있겠구나’하고 생각했다. 이제 그 프로그래머의 문제는 두 개가 되었다 – 어느 포춘 쿠키에서 15. 프로그래머에서 관리자로 전환되는 과정은 일종의 "전두엽 제거수술"로 비유되기도 한다. - Dreaming in code 16. 업계 실무에서 최고수준과 평균수준이 이렇게 차이가 나는 분야는 거의 없다. 진짜 문제는 기술이 아니다. 오늘날 정말 심각한 문제는 관리다. - 1980년대 후반 미 국방과학부 특별위원회 17. 소프트웨어의 질에 대해 금전적 보상 방법을 강구하라. - 1980년대 후반 미 국방과학부 특별위원회 18. 새로운 과학의 진리는 적을 설득하거나 그들에게 빛을 보여줌으로써 승리하지 않는다. 다만.. 새로운 세대가 자라서 거기에 익숙해질 뿐이다. - 막스 플랑크 19. ORM은 컴퓨터 과학의 베트남전이다. - 테드 네워드(Ted Neward) 1. 베트남전의 가장 큰 실패 이유는 불확실한 목표였고 현재의 ORM에서도 가장 큰 문제라는것을 표현함. 20. 도서관(라이브러리) 10분이 연구실 6개월 부럽지 않다. (기존 라이브러리를 최대한 사용하는것의 중요함을 나타냄.) 소프트웨어공학 1. 방법론의 진짜 목적은 책을 팔아먹기 위함이지 실제로 누군가의 문제를 해결하기 위함이 아닙니다. - 조엘 스폴스키 (구 MS-엑셀의 관리자) 2. 소프트웨어 공학이란 사기에 가깝습니다. 물리학이 정립되기전에 제대로된 공학을 한다는건 어불성설이죠. 소프트웨어에는 물리학 비슷한것 조차 아직 없습니다. - 제록스의 소프트웨어 베테랑 L 피터 도이치 3. UML을 비꼬며 - 그것은 마치 건축설계사가 설계도를 그리면 자동으로 건물이 지어지는 것과 같았다. 게다가 설계도가 수정되면, 건물도 자동으로 다시 지어졌다. - 클레어 트리스트램 4. 소프트웨어 설계는 여자 치마처럼 중요한 부분을 가릴 만큼 길되, 흥미를 유발할 정로로 짧아야 한다. - 소프트웨어 크리에이티비티 (오랜 농담) 5. BIEGE (Better Is the Enemy od the Good Enough) : '더 나음'은 '충분한'의 적이다. - 소프트웨어 크리에이티비티 1. 만족스런 해법으로 충분한 문제라면 최적인 해법을 찾으려고 시간과 노려을 낭비하지 말라. 오래된 농담 1. 벙법론자와 테러리스트의 차이점은? 답) 테러리스트와는 협상을 할 수 있다. 2. MS방식 표준화 ( 동종기업을 먹어버림...) 프로그래밍의 도 (The Tao of Programming) By Seth Robertson 1. 관리자가 도사 프로그래머를 만나 새 애플리케이션의 요구사항을 담은 문서를 건네주었다. 관리자가 묻기를: "다섯명의 프로그래머를 투입한다면 시스템을 설계하는데 얼마나 걸리겠소?" "일년이 걸릴 것입니다." 도사가 간단하게 대답하였다. "하지만 우리는 이 시스템이 지금 당장 필요하단 말이요! 프로그래머를 열명 투입하면 어떻겠소?" 도사는 인상을 찌푸렸다. "그렇다면 이년이 걸릴 것입니다." "프로그래머를 백명 투입한다면 어떻겠소?" 도사는 가볍게 한숨을 쉬며 답하였다. "그 경우에는 시스템이 결코 완성되지 않을 것입니다." - 2. 어느날 제자 프로그래머가 간단한 회계 프로그램을 짜라는 지시를 받았다. 제자는 많은 날을 열심히 일했다. 스승이 그의 프로그램을 실행해보니 스크린 에디터와 그래픽 처리루틴 몇가지와 인공지능을 응용한 인터페이스가 구현되어 있었다. 하지만 어디에도 회계와 관련된 기능은 없었다. 스승이 이에 대해 묻자, 제자가 시큰둥하게 대답했다. "그렇게 급하게 재촉하지 마세요. 언젠가는 회계에 관련된 기능을 넣을 테니까요." 3. 도사 프로그래머 가라사대: "프로그래머는 많이 고용하고 관리자의 수는 줄여라. 생산성이 절로 향상될 것이다." 4. 관리자가 끊임없이 회의를 하면 프로그래머는 게임을 짠다. 회계사가 사분기 이익에 대해 불평하면 개발 예산은 삭감될 위기에 처한다. 수석 과학자가 푸른 하늘을 논하면 바람 구름이 몰려든다. 아, 이것은 진정한 프로그래밍의 도가 아니다. 관리자가 결론을 내면, 게임 프로그램은 잊혀진다. 회계사가 장기 계획을 세우면 조화와 질서가 회복된다. 수석 과학자가 신경 쓰기 시작하면 문제는 곧 해결된다. 아, 이것이 진정한 프로그래밍의 도이다. 5. 프로그래머는 왜 생산성이 낮은가? 그들의 시간이 회의로 낭비되기 때문이다. 프로그래머가 왜 툴툴거리는가? 관리자가 지나치게 참견하기 때문이다. 프로그래머가 왜 하나씩 회사를 떠나는가? 지쳤기 때문이다. 무능력한 관리자 밑에서 일하는 프로그래머는 자신의 직업을 소중히 여기지 않는다. 6. 관리자가 프로그래머를 찾아가서 말하기를: "당신의 출근 시간을 조정하기로 했소. 이제부터 아침 9시에 나오고 5시에 퇴근하도록 하시오." 이 말을 들은 프로그래머들은 모두 분노하였고, 몇몇은 즉석에서 회사를 그만두었다. 그래서 관리자가 말하기를: "좋아요. 그렇다면 작업 시간을 자유롭게 정하도록 하시오. 맡은 프로젝트를 스케줄에 맞게 끝내기만 하면 상관하지 않겠소." 만족한 프로그래머들은 이제 정오에 출근하여 이른 새벽까지 일했다. 7. 도사 프로그래머는 프로그램에서 프로그램으로 아무런 두려움 없이 옮겨다닌다. 관리자가 어떻게 변해도 그의 위치는 변하지 않는다. 그는 프로젝트가 취소되더라도 해고되지 않는다. 왜 그럴까? 도사 프로그래머는 도로 충만하기 때문이다. * 소프트웨어 엔지니어가 고장난 전구를 갈지 않는 이유는. - 하드웨어의 문제이기 때문에. * 프로그래머가 담배를 피우는 이유 - 경고는 항상 무시하므로. * 리눅스가 user-friendly 인 것은 맞다. 단지 친구를 가려 사귈 뿐이다. 개발자 용어집 해석 1. 고차원 : 가짜 2. 특수 프로젝트 관리자 : 자기 책상을 관리하는 사람. 3. 좋은 경험이었습니다 : 완정히 망쳤습니다. 4. 지금까지 드린 말씀에 이어서.. : 지금까지 한말은 전부 개소리 입니다. 5. 코드완료 : 테스트 안함 6. 권한이 당신에게 있습니다 : 잘못되면 책임을 지십시오 7. 이제 제 충고를 들으세요 : 내가 상사니까 내말대로 해 8. 이 코드는 유지보수가 불가능 합니다 : 나라면 다르게 설계했을겁니다. 9. 이해하도록 설명해 드리겠습니다. : 내방식대로 합시다. 10. 우수 개발 기법 : 여기서 일하지 않는 사람이 만들었음으로 우리가 하는 방식보다 대단히 우수하다. 11. 나중에 따로 고려합시다 : 무시합시다. 12. 고상한 접근방법이네요 : 멍청하시군요. 13. "획기적인 기술"이다. 자세한 기술 요소는 보안 때문에 밝힐 수 없다. (펌) 1. 나는 획기적인 것으로 알고 있는데 그건 내가 수준이 낮아서 그런 것이고 사실 별거 아니다. 2. 별거 아닌 줄 알고는 있는데 밝히면 창피하니까 자세한 기술요소는 밝힐 수 없다. 14. 세계 최초 1. 나는 세계 최초로 알고 있다. 하지만 진짜 세계 최초인지 알아보려는 노력은 별로 하지 않았다. 2. 별거 아니라서 아무도 관심을 가지지 않는 기술이다. 따라서 시장성도 없다. 3. 이미 더 좋은 기술이 있는데 나는 공부를 많이 안해서 잘 모른다. * 백신 이야기 - 재밌음! 관리자와 개발자. (출처 kldp.org) 1. 관리자들은 전자신문에서 읽은 XML, 모바일, CMS 등의 신기술을 열거할 줄 아는 것만으로 자신은 관련 기술을 이해할 줄아는, 비전이 있는 관리자라 생각한다. 2. 관리자들은 필요하다고 생각하는 기능들을 나열한, 또 데이터베이스와 서버를 나타내는 도형들을 몇개의 화살표가 이어주는 10페이지 짜리 파워포인트로 제품 설계가 끝났다고 생각한다. 3. 관리자들은 회사의 필요에 따라 프로젝트 기간을 정하고 이를 엄수하는 것은 개발자로서 최소한의 의무라고 생각한다 - 외국에서 6개월 걸리는 프로젝트를 3개월만에 끝내도 회사가 2개월안에 판매해야 이익을 볼 수 있는 경우라면 개발자 때문에 실패한 프로젝트라고 생각한다. 4. 관리자들은 개발자들이 신기술을 익히기 위해 업무시간에 스펙을 보거나 관련 사이트를 브라우징 하는 것은 업무태만이라고 생각한다. 하지만 신기술을 적용해야하는 제품을 원하는 기간에 만들 수 없다면 무능한 개발자로 취급한다. 5. 프로젝트의 설계와 테스트에는 절대 많은 시간을 투자하지 않는다. 오직 개발자의 축적된 꼼수와 밤세운 삽질로 겨우 돌아가는 제품이 완성되었을 때 버그라도 하나 발견되면 개발자는 거의 도덕적으로 큰 잘못을 저지른 것 같은 질책을 받는다. 6. 제품이 성공하면, 이는 관리자의 프로젝트 관리 능력과 비전, 그리고 무엇보다 영업팀의 적극적인 마켓팅이 주효했다고 생각한다. 그리고 인센티브도 그들이 나누어 갖는다. (개발자들에게는 "xx씨 이제 프로젝트도 끝났으니 놀겠네" 정도 인사치례를 해주는 사람들도 있다) 7. 관리자 한명을 키우는데는 많은 경험과 노하우가 필요하다고 생각한다. 영업사원 한명에게는 직책에 적합한 아이디어와 성격, 그리고 무엇보다 인맥이 중요하다고 본다. 하지만 개발자 한명은 언제든지 구직 게시판에서 데려올 수 있다. 8. 관리자가 원도우즈XP가 필요할 수도 있고 영업사원이 최신 노트북이 필요할 수 있는 것은 이해한다. 하지만 개발자가 모델링 도구나 O-R 매핑 툴, 또는 프로파일러가 필요하다는 사실은 결코 이해하지 못한다. 9. 신문에서 벤처기업의 성공담을 읽는다면 "분명 저 기에서 일하는 개발자들은 매일 밤세워 일할거야. 근데 왜 우리 직원들은 저모양이지?" 하며 10시에 퇴근하는 개발자들을 원망한다. 10. 개발자는 한번 손을 댄 제품에 대해서는 무한 책임을 진다. 고객에게 문의 전화가 오거나 문제가 생기면 "그거 누가 만들었어? xx 데려와봐"하는 식으로 이미 다른 프로젝트에 정신없는 개발자에게 책임을 떠넘긴다. 어딘가에서 불펌. 훌륭한 프로그래머는 가난하다. 그가 가난을 벗어나려면 그 "훌륭함"부터 벗어나야 한다. -------------------------------------------------------------------------------- "열심히"씨와 "훌륭한"씨는 각각 "엄청난소프트웨어회사"와 "허벌난소프트웨어회사"의 두 직원이다. 우연치 않게 두 회사에 정확히 똑같은 내용의 주문이 들어왔다. "열나어려운문제" 해결을 위한 프로그램을 작성해 달라는 것이었다. 열 심히씨는 처음 예상 소요 시간인 3개월 동안 정말 열심히 일했다. 하지만 일을 하면서 예상 외의 장애를 직면했고, 밤샘 작업까지 해가면서 3개월의 마지막 날 매니져에게 이런 말을 할 수 있었다. "정말 열나게 프로그램을 짰슴다. 밤샘도 하고요. 제가 지금까지 작성한 프로그램은 2000줄입니다. 그런데, 새로운 문제가 기술적으로 불가피하게 발생했습니다. 복잡한 버그(프로그램의 오류)도 몇 가지 해결해야 하고요. 한 달 가량이 더 필요합니다." 그러고 한달 후 열심히씨는 몇 개의 버그와 더불어 나름대로 작동하는 프로그램을 매니져와 고객에게 자랑스럽게 보여줄 수 있었다. 벌겋게 충혈된 눈과 미쳐 깎지 못한 수염, 무지무지 어렵고 복잡해 보이는 2500여 줄의 프로그램과 함께. "예상보다 훨씬 더 복잡한 문제였군요. 정말 수고하셨습니다."라는 칭찬을 들으면서. 훌륭한씨는 매니져가 "의무적으로" 잡아놓은 예상 소요 시간 3개월의 첫 2달 반을 빈둥거리며 지냈다. 매니져는 훌륭한씨가 월말이 되어서 "정말 죄송해요. 아직 한 줄도 못짰어요. 너무 어려워요. 좀 봐주세요."라고 처량하게 자비를 구할 날을 손꼽아 기다렸다. 웬걸, 마지막 날 훌륭한씨는 예의 "너무도 태연스러운" 모습으로 나타났다. 150여 줄의 프로그램과 함께. 그 프로그램은 멋지게 "열나어려운문제"를 해결했다. 하지만, 매니져가 그 코드를 들여다 보자, 한마디로 "너무도 쉬웠다." 초등학생도 생각해 낼 정도였다. 매니져와 고객은 이름을 "열나쉬운문제"로 바꾸는 데에 전적으로 동의한다. 훌륭한씨는 "이렇게 간단한 문제를 3개월 씩이나 걸려서 풀었습니까? 왜 이렇게 성실하지 못하죠?"라는 비난을 들어야 했다. 둘 중에 누가 승진을 했을까? 열심히씨는 승진하고, 급여인상을 받았다. 훌륭한씨는 급여삭감을 직면하고는 퇴사해 버렸다. 훌륭한 프로그래머는 가난하다. 훌륭한프로그래머의딜레마인 것이다. --김창준 [이 이야기는 SE계의 잘 알려지지 않은 명작 Wicked Problems, Righteous Solutions 에 나온(원래는 CACM 기사였던) 일화를 직접 각색한 것이다] 위 나라의 임금이 편작에게 묻는다. "그대 삼형제 가운데 누가 제일 잘 병을 치료하는가?" 큰 형님의 의술이 가장 훌륭하고 다음은 둘째 형님이며 저의 의술이 가장 비천합니다. 임금이 그 이유를 묻자 편작이 대답한 내용은 이러했다. '큰 형님은 상대방이 아픔을 느끼지 전에 얼굴빛을 보고 그에게 장차 병이 있을 것임을 안다. 그리하여 그가 병이 생기기도 전에 원인을 제거하여 준다. 그러므로 상대는 아파보지도 않은 상태에서 치료를 받게 되고 따라서 그간 자기의 고통을 제거해 주었다는 사실을 알지 못한다. 큰 형이 명의로 소문나지 않은 이유는 여기에 있다. 둘째는 상대방이 병세가 미미한 상태에서 그의 병을 알고 치료를 해준다. 그러므로 이 경우의 환자도 둘째형이 자신의 큰 병을 낫게 해주었다고 생각하지 않는다. 그러나 나는 병이 커지고 환자가 고통속에 신음할 때가 되어서야 비로소 병을 알아 보았다. 환자의 병이 심하므로 그의 맥을 짚어야 했으며 진기한 약을 먹이고 살을 도려내는 수술도 했다. 그런데 사람들은 나의 그러한 행위를 보고서야 비로소 내가 자신의 병을 고쳐주었다고 믿게 되었다. 내가 명의로 소문이 나게 된 이유는 여기에 있다.' -------------------------------------------------------------------------------- 훌 륭한 프로그래머는 어려운 문제를 "터무니 없을 정도로 간단한 문제"(see also RidiculousSimplicity)로 풀어내는 재주가 있다. 남들이 보기에는 그것이 너무도 당연한 해결법으로 보인다. 하지만 그들은 쉽게 생각해 내지 못한다. 그러고는 훌륭한 프로그래머를 우습게 본다. 중간치기나 하치기 프로그래머는 어려운 문제를 어렵게 혹은 더욱 어렵게 풀어내는 재주가 있다. 남들이 보기에는 그것이 너무도 기발한 해결법으로 보인다. 역시 그들은 쉽게 생각해 내지 못한다. 그러고는 중간치기 하치기 프로그래머를 대단하게 본다. see also 노자 도덕경 -------------------------------------------------------------------------------- 과 거 IBM사에서는 프로그램의 줄 수에 따라 급여를 계산했었다. (사실 지금도 이런 회사가 상당수 있다) 그런데 프로그램 줄 수가 늘어날 수록 숨겨진 버그 수와 유지관리에 드는 비용은 기하 급수적으로 늘어나게 된다. 이 문제를 해결하기 위해 프로그램 줄 수는 더 늘어나게 되고, 덕분에 프로그래머는 돈을 더 벌게 된다. -------------------------------------------------------------------------------- 남 들이 보기 쉽게 짤 수 도 있으나 어렵게 짜는 수를 일부러 부릴 때도 있는 것같네요. 위에 "훌륭한" 프로그래머가 이 세상에서 살아남기 위해선 "열심히" 프로그래머인 것처럼 해야하는 것이 아닐까요, 군발이 시절 3시간 정도 할 수 있는 일을 언제나 하루 정도 걸려서 끝마쳤죠. 만약에 그 일을 3시간에 정말 끝마쳐 버린다면 다음 프로젝트때는 그 일에 해당하는 시간을 2시간 정도를 주는 것으로 바뀌어져 버리니까요. 이건 곧 그사람의 직업관?에도 연관 되는 문제가 아닐련지. --rururara -------------------------------------------------------------------------------- 훌 륭한 프로그래머는 "터무니 없을 정도로 간단한 문제"로 풀어내는 재주가 있을 뿐더러, "터무니 없을 정도의 어려운 문제로 보이는 쉬운 문제"를 잘 섞어서 좋은 아이디어를 제시하는 재주가 있다. 당연히 중간치기, 하치기 프로그래머 모임에 있어서는 훌륭한 프로그래머가 해결안을 제시하기도 전에 간단히 배제가 되고 만다. 이유는?? 중간치기, 하치기 프로그래머가 바라보는 시선이 이미 한정되어 있기 때문에, 그 범위 밖에서 문제를 해결한다거나, 뿌리를 잘라내는 얘기는 당연히 범위 밖의 바보같은 얘기이기 때문이다.^^ 예로, 입술에 묻은 밥알을 떼기 위해서는 일반적으로 인간에게 있어 미세한 행동을 할 수 있는 손, 그 중에서도 엄지와 검지손가락이 필요하다는 전제하에서 이루어지는 중간치기 하치기 프로그래머들의 모임이 있다. 훌 륭한 프로그래머의 "입술에 묻은 밥알을 혀로 떼어 먹으면 되잖아요"란 해답은 당연히 먹힐리 없다. "어깨 반경을 좁히기 위헤 손을 직선으로 올려 팔꿈치로 90도를 꺾으면 최단거리의 궤적이 나오고, 이때 밥알의 접착성을 이용해서, 검지로만 문제를 해결해야 하는데, 접착성은 상온에서만 유지되고 밥알은 굳기 이전의 14시간 내에, 습도 70%이상에서만 해결할 수 있는 문제이고, 그 이외의 문제는 나중에 해결하자"란 답이 그 회의에서의 정답이기 때문이다. 훌륭한 프로그래머는 훌륭한 중간관리자가없이는 훌륭해질 수 없다.--cavin xper펌 야근이 암묵적으로 강요되는 분위기의 A라는 팀이 하나 있습니다. 팀원은 7명. 그 중 철수라는 개발자는 항상 더 나은 방법을 찾고 찾고 자기개발을 하는 사람입니다. 철수는 다른 팀원들과 비슷한 분량의 업무를 더 나은 방법으로 더 빨리 끝냈습니다. 다른 팀원들은 매일 야근을 하는데, 철수는 칼퇴근을 할 수 있었습니다. 그런데, 며칠후 이 팀에 새로운 일이 생겼습니다. 팀장은 누구에게 업무를 할당할까 살펴보다가, 칼퇴근을 하고 있는 철수가 가장 여유있다고 생각해 철수에게 일을 추가로 줍니다. 이런 일이 몇 번 반복되자, 철수는 더이상 자기의 개선 노력이 자기의 삶을 나아지게 하지 못하고, 일만 많아졌다는 생각을 합니다. 다른 팀원들도 철수를 보면서 자기 업무를 더 빨리 끝내봤자 일만 많아진다는 교훈을 얻습니다. 어차피 해야하는 야근. 다같이 느린 방식으로 늦게까지 일합니다. 팀의 생산성과 팀원들의 삶의 질은 매우 낮아집니다. 그런데, 처음부터 A팀이 야근을 암묵적으로 강요한 것은 아니었습니다. 이 회사에는 A팀외에도 비슷한 업무를 하는 B팀, C팀, D팀, E팀, F팀이 있습니다. A팀도 예전에는 철수와 같은 팀원들이 많아 다른 팀에 비해 효율이 매우 높은 팀이었습니다. 그래서 비효율적으로 일하는 B~F팀들은 다들 늦게까지 일을 하고 있었지만, A팀은 대체로 일찍 퇴근하는 팀이었습니다. 그러던 어느날, 경재사의 신제품에 대응하기 위해 혹은 시장 확장 등의 이유로 새로운 팀, Z가 생겼습니다. 김상무는 신생 Z팀의 팀원을 충원하기 위해 기존 팀들에서 몇명씩 뽑기로 합니다. 그런데, 가만히 보니 A팀은 다른 팀에 비해 좀 여유가 있어 보입니다. 그래서 B~F팀은 한명씩 뽑아오고, A팀에선 3명을 뽑아옵니다. 비슷한 경험을 몇 번 겪은 A팀의 팀장은 팀원을 많이 뺏긴 이유가 야근 시간임을 깨닫고 야근을 강요하기 시작합니다. 물론 간접적이고 암묵적인 방법으로... == 무능력한 개발자 출처 - okJsp 1. 첫째는 '열심히 하지만 결과를 쓸 수 었을 때'입니다. 1. 2~3주 하루 12시간씩 작업한 결과물이 아무리 좋게 보아도 변수명 바꾼 것에 불과한 듯이 보이는 상황을 대하게 되면 화를 내야하는지 그냥 포기하고 혼자 끙끙거리며 모르게 다시 만들어야 하는지 간간 깊은 고민에 빠집니다. 2. 불행하게도 저는 마음 크기가 종지만해 화를 내는 쪽이긴 합니다만, 그나마 화를 내어 놓고도 일정 때문에 제가 손을 보곤 합니다. 2. 둘째는 '자부심은 강하지만 결과과 이상할 때'입니다. 1. 스킬에 대한 중요성, 관련 경험, 학습 내용 들에 대한 자긍심이 굉장한데 비하여, 내어놓은 결과물은 예를들면 1줄짜리 쿼리를 10줄로 만들어둔데다 원하는 결과도 도출되지 않는 상황인 경우입니다. 함부로 의사를 전하면 크게 상심할까봐 참 대응하기 곤란하더군요. 3. 셋째는 '하고 싶은 것만 한다'입니다. 1. 박식한데다 경험도 풍부하지만, 하고 싶은 파트가 아니면 절대 하지 않으려는 경우로 몇명만이 단촐하게 일할 때는 여간 고로운게 아닙니다. 2. 명확히 하자면 성격 또는 게으름의 문제이겠으나, 결과적으로는 능력을 보여주지를 못하니... 4. 넷째는 '논리 결여'입니다. 1. 재미있는 것은 이런 부류의 이들이 상대적으로 사회성도 뛰어나고 자기 자신에 대한 투자에 게으르지 않다는 것입니다. 2. 충분한 학력과 현장 경험에도 불구하고 C & P에만 능숙해져 있는 것을 보면 차라리 다른 쪽으로 방향을 돌려보는 것도 좋지 않은지 권해주고 싶습니다. 5. 다섯째는 '레퍼런스를 찾기 능력 결여'입니다. 1. 농담반 진담반으로 '내 실력의 절반은 네이버와 구글이 키웠다'라고 말해도 허하게 들리지 않을 정도로 레퍼런스로 넘쳐나는 요즘임에도 불구하고 막히면 막히는 족족 포기해버리고 다른 이들의 도움을 찾는 경우로, 심하게 표현해 '귀찮다'라는 생각이 자꾸 떠오르게 됩니다. 6. 여섯번째로 '할 수 없다고 말하기 싫어하는 자존심'입니다. 1. 무능함과 '할수 없음'은 다르다고 생각하고, 대부분의 이들이 순수하게 현황을 이야기하면 함께 고민해보고 격려함에도 불구하고, 아무리 급박한 상황이라도 '못한다'라는 말을 꺼내지 않은체 폭발 직전까지 끌고가는 경우를 대하곤 합니다. 7. 일곱번째로 '내일만 커보인다' 부류입니다. 1. 남의 일은 쉬워보인다던가 하는 1차원적인 것이라면 차라리 귀여운데, 프로덕트 전체를 보지 않으려고 하며 오만해하는 경우에는 답이 없습니다. 2. 특히나 아집이 강한 이들이 이러하다면... 전 '실력으로 눌러야한다'라는 생각으로(제가 실력이 있다는 말은 아닙니다. 허허~) 멀쩡한 척 하면서 밤세워 작업한 뒤 보여주며 '쉽던데~'라고 말하는 부류이지만, 결과적으로 이런 이들과 충돌하게 되면 나중에 다시 보지 않게 될 확률이 현재까지는 100% 더군요. 8. 마지막으로... 위의 일부 또는 전부를 갖춘데다 '시간 투자'로 모든 것을 판단하려는 부류입니다. 1. 결과를 도출하였다는 사실이 아닌 아주 간단히 수치화할 수 있는 시간을 얼마나 소요했는가로 판단하는 부류이지요. 2. 이런이들이 아래 사람이라면 '나만 일한다'는 불만을 들어야하고, 윗사람이라면 '너는 왜 노냐?'라는 지적을 감수해야하며, 중간 관리자라면 '잘 가르쳐봐'라는 업무와는 전혀 무관한 교관 노릇을 감수 해야합니다. == 프로젝트 팀원분석 1. 갑(발주처) 1. 뭔가를 해야 겠는데 아직 생각이 잘 안난다. 일단 만들어진거 보고 생각해야 겠다. 2. 프로젝트롤 저비용 / 최단기간에 끝내서 높은 고과를 받을 생각에 을을 후려친다. 3. 새벽에 친구들과 술마시다가 돌연 '을'을 부른다. "와서 술한잔 하라고.. 계산도 하고.." 2. 을(프로젝트 수주사, 빅3) 1. 갑한테 어떻게하면 자기들이 열심히 챙겨주는걸로 보일까 고민하고 또 고민한다. 2. 어떻게 하면 자기는 파일 몇개만 끄적거리고 나머지는 병정 무수리들에게 떠밀까 능동적으로 잔머리 굴림. 3. 무슨무슨 박사랍시고 고급으로 와서는 겸손하게도 자료모아서 파워포인트 몇장 끄적끄적 4. 프로젝트는 무지 많이 했다고는 왔는데 현업이 물어보면 자세한건 병정무수리 책임자에게 문의하면 된다고 참으로 친절하게 안내해줌. 5. 개나소나 컨설턴트고 시스템 아키텍터임.컨설턴트랍시고 와서 맨날 인터넷 서핑하다가 가끔가다 회의 참석하고 화면 캡쳐 열심히 함. 6. 병정 무수리들을 보며 생각한다. "요즘 실력있는 개발들 씨가 말랐어.. " 3. 병정(인력파견업체 또는 하도업체 직원) 1. 상세하게 하나하나 설명하고 문서로 남겨주지 않으면 일하지 않는다. 2. 절대로 프로젝트가 성공적으로 끝나게 하고 싶은 마음은 없다. 왜냐고? 어찌됫건 일하는 시간과 월급은 똑같기 때문이다. 3. 옆에서 지켜보지 않으면 하루종일 논다. 4. 개나소나 과장, 차장이다. 경력 뻥튀기는 옵션. 4. 프리랜서 1. 어떻게 올해는 단가를 올려받을지 고심한다. 2. 어떻게 편한 프로젝트를 찾을지 고심한다. 단가와 실력과 업무량은 전혀 별개이기 때문이다.