컴빅스™의 소박한 이야기

1. 딱 떨어지는 숫자는 2진수입니다. 

2. 한 손으로 31까지 셀 수 있음 

3. 만능이 아님 

4. 컴퓨터를 잘 하는게 아님 

5. 프로그래머라고 Office 시리즈에 정통한 것이 아님 

6. 아, 그 작업은 사무쪽 누님이 잘하실 겁니다. 

7. 가나 입력으로 변환한 다음에는 반드시 로마자 입력으로 돌려놓을 것 

8. 프로그램의 쓰레기 수집은 잘 하지만 자기 방의 쓰레기 수집은 잘 못함 

9. 멀티스레드 처리 작성은 할 수 있지만 멀티스레드 처리는 못함 

10. Amazon 에서 사는 건 기술서이므로, 딱히 포장물 내용을 확인할 필요는 없음

11. 쌓아놓은 책은 스택이므로 순번을 바꾸지 말것 

12. 오라일리 책은 「같은 책」이 아님 

13. 표지에 동물만 그려져 있는 책만 꽂혀있어도 그건 동물도감이 아님 

14. 프로그래밍을 안하는 날도 있음 

15. 프로그래밍 언어나 에디터에 대한 집착이 사라진다면 깨달음을 얻었거나 완전연소했거나 둘 중 하나 

16. 언어로 바람피우는 것과 인생의 바람피우기는 다른 것 

17. 「자식을 죽인다」는 말에 놀라지 말 것 

18. 일 관계로 전화를 할 때, 자식이 죽지 않으면 부모를 죽여버리라는 대화를 들어도 놀라지 말것 

19. 라이브러리라는 것은 도서관을 말하는 게 아님 

20. 「사이드 이펙트(부작용)」는 부정적인 의미로 사용하는 것이 아님 

21. 특히 「다이아몬드 상속」은 유산상속같은 이야기를 하는 것이 아님 

22. 괜히 보석 이름 같은 것을 중얼거려도 보석에 대해 잘 아는 것이 아님 

23. 루비와 펄 중에 뭐가 좋아? 라고 물어보면, 싱긋 웃으면서 펄이라고 대답할 것 

24. 「조금만 더하면」「거의 끝났어」라는 말이 나오기 시작하면 당분간 끝나지 않을 것이라고 생각할 것 

25. 갑자기 혼잣말을 하기 시작해도 정신이 이상해진 것이 아님 

26. PC 를 보고 있는 남편에게 말을 걸어도 되는 타이밍인지 아닌지 외견으로 판단하는 것은 포기하는 것이 좋음 

27. 23-24시 정도가 가장 활발함 

28. HP 는 항상 0에 수렴함 

29. 회사와 집의 구별이 그다지 없고, PC 앞에 있는가 없는가의 구별 밖에 없음 

30. 스스로가 정보수집과 오락의 경계선을 이해하지 못함 

31. 몬스터헌터는 업무 

32. 애니메이션 보는 것은 업무 

33. 일을 하는 것처럼 보이지만 실은 인터넷을 하는 것 뿐임 

34. 주말에도 스터디에 간다고 하는 것은 공부를 열심히 한다는 증거, 가사가 싫어서 그러는 게 아님 

35. 한밤에 긴급전화가 왔다면, 다음날부터의 예정은 캔슬이라고 생각합시다 

36. 밤중에 갑자기 사라져도 그냥 장애 대응하러 간 것임 

37. 오전중에 돌아오는 일이 많아져도 바람피우는 것이 아닌지 의심하지 말것 

38. 주말에만 사복으로 「출근」했다고 바람피우는 것이라고 의심하지 말 것 

39. 결혼식장에서 신랑이 사라져도 당황하지 말것. 고객이 호출한 것 뿐임 

40. 정시퇴근은 도시전설 

41. 「귀가한다」「귀가할 수 있다」라는 말은 별 도움이 안됨 

42. 10일 정도 돌아오지 않아도 당황하지 말 것 

43. 감금같은 걸 당해도 빚이 있어서 그러거나 한 게 아님 

44. 가끔씩 일찍 돌아와도 잘렸을 걱정은 하지 말 것 

45. 여름 휴가 언제야? 라고 묻지 말 것

46. Twitter 의 post 빈도 감소나 내용에서 상대가 얼마나 바쁜지 추측해서 위로할 것 

47. 화재나 행진같은 것에 트라우마를 갖고 있을 것 

48. 남편 급여의 직능급과 기본급과 잔업수당의 비율 

49. 노동기준법 

50. OA 기기라고 적힌 우편물은 절대로 OA 기기가 아님 

51. PC 나 휴대폰, iphone 에 패스워드 락이 걸려있는 것은 보안대책을 위해서. 바람을 핀다거나 야한 것을 숨기고 있는게 아니랍니다（　＾ω＾） 

52. 컴퓨터는 이미 집에 있잖아, 라고 하지 마시길. 당신이 갖고 있는 구두나 가방과 같은 것입니다.

53. 한밤중에 컴퓨터로 동영상을 보면서 싱글거리고 있다면, 그것은 분명 Apple 의 신제품 발표이므로 신용카드를 몰수하는 것이 좋음 

54. 스티브 잡스의 프리젠테이션이 있는 다음날 아침에 갑자기 개최되는 가족회의에서 제출하는 안건에 대하여 「다른 집은 다른 집이고 우리 집은 우리 집이야!」라고 기각할 것 

55. 뭐가 뭔지 알수 없는 T 셔츠를 남편이 계속 가져와도 적당히 버리거나 하지 말 것 

56. 컴퓨터 책상에 놓여있는 피겨나 프라모델은 버리지 말 것 

57. 그것은 잡동사니도 부서진 물건도 아님 

58. 키넥트를 사려고 하는 것은 유저 인터페이스 연구 때문에 

59. 러브 플러스를 하는 것은 유저 인터페이스 연구 때문에 

60. 사용자 경험(UX)인지 뭔지 하는 주제에 CUI 를 좋아함 

61. LCD 가 달려있는 작고 비슷하게 생긴 기계를 잔뜩 갖고 있어도 전부 다른 물건이며 각자 의미가 있습니다 

62. 동작검증을 하기 위해서는 신제품이 필요하며, 그것은 Amazon 에서 배달됨 

63. 옥션 사용방법을 숙지하고, 남편이 사온 장난감을 팔아치워 용돈으로 씁시다 

64. 생일 선물은 원하는 물건을 미리 말해두지 않으면 신제품 디지털 가전(Gadjet)을 받게 됨 

65. 깜짝 선물을 준비하고 싶다면 남편의 Amazon 위시 리스트를 조사함 

66. iPhone 앱, Android 앱, Web 사이트를 만들었다는 이야기를 들으면 뭐가 뭔지 몰라도 상냥하게 대답해줄 것 

67. 쓸데없이 하이텐션으로 의미를 알 수 없는 소리를 지껄일 때에는 단순히 흥미 깊은 기술이 나와서 텐션이 높아진 것 뿐이므로, "잘 모르겠지만, 대단하다는 건 알겠다"라고 대답해주세요 

68. 갑자기 이상한 어휘가 늘었다면 니코니코 동화같은 데애서 유행하고 있는 것이라고 추측하시길 

69. 남편의 HN 과 본명을 이어보려고 해서는 안됨

70. 남편의 블로그의 과거로그를 음독해서는 안됨

71. 남편의 HN 으로 검색해서 흑역사를 알아서는 안됨 

72. 「우리 마누라가…」라고 했을 때, 그것은 프로그래머 사이에서 통용되는 전문용어입니다. 당신을 말하는 것이 아닙니다 

73. 오타쿠라고 하면 필요 이상으로 싫어하지만, 긱(Geek)이라고 말하면 기뻐합니다 

74. 침울해하고 있을 때는 「컴퓨터를 조작해서 ○○할 때 마우스를 쓰지 않고 키보드만으로 하려면 어떻게 해야해?」라고 물으면 기뻐하면서 가르쳐 줄 것입니다 

75. 「시뮬레이션」이라고 말하면 혼나므로 주의할 것 

76. 이상, 이하, 미만, 보다 위, 보다 아래를 대충 섞어쓰면 기분이 나빠짐 

77. 프로그래머는 「절대로」「뭔가 이상해졌어」「아무것도 안했어」같은 말에 과잉으로 반응합니다. 홧병, 쇼크사, 자살의 위험성이 있으므로 이런 말을 사용할 때에는 세심한 주의가 필요합니다 

78. 부부싸움할 때 최대의 무기는 화이트 보드 

79. 어쩌다 아내의 방식에 불만을 표시하면 「그건 사양(仕様)이예요」라고 대답함 

80. 남편이 이건 사양이라고 말하면 그 사양은 변경되었습니다 라고 대답할 것 

81. 싸워서 꼭지가 돌아버렸을 때에는, 네트워크 회선을 끊어버리는 것이 가장 손쉽고 효과적으로 분노를 표현하는 방법입니다. 

82. 가능하면 아내와의 대화를 자동화시키고 싶어 함 

83. 아내에게는 사양 변경이 붙는 법 

84. 홈 서버를 가리키면서 쓰지도 않는데 왜 항상 전원이 켜져 있는 거야 라고 묻지 말 것 

85. 연락수단은 전화<<<<<(넘을 수 없는 벽)<<<<메일<<<<<<<IRC, Skype, etc 

86. Google Calender 에서 상대의 스터디 스케쥴을 파악할 것 

87. 집안 예정은 남편이 지정한 그룹웨어로 공유할 것. 구두(口頭)로의 통지만으로는 위험 

88. 남편이 해야할 것은 데스마치(죽음의 행진)이 아닌 여유가 있을 때 기억시켜두지 않으면 답이 없음 

89. 가정 내의 중요한 스케쥴을 끼워넣고 싶을 때에는 마감 근처의 주말은 피합시다. 어차피 집에 못 돌아옵니다 

90. 남편이 전문분야인 화제에는 신중하게 접근할 것 

91. 친구 관계의 잡담을 할 때에는 상관관계도를 그려주면 이해가 빨라집니다 

92. 단순히 이야기를 들어주기 바랄 때에서는 그렇게 명시할 것 

93. 동의해주기 바랄 때에 분석되어 정론을 들어도 화내지 마시기 바랍니다 

94. 요건은 항목별로 적어서 전하지 않으면 프로그래머 스스로가 버그를 냄 

95. 밤생활이 불만이면 Redbull 을 내밀어봄 

96. 정기적으로 자식들에게 이게 아빠야 하면서 사진을 보여주세요 

97. 남편이 「프로그래머의 아내가 알아야 할 97가지」같은 걸 트윗해도 신경쓰지 말 것 

98. 읽어보라고 한 97가지의 절반 이상이 뭔 소리인지 몰라도 어쩔 수 없음 

99. 이러니저러니 해도 아내를 사랑함. 하지만「쪽팔려서 말 못해」라고 생각해서 말로 표현하지 않을뿐.

주위 시선에서 본 프로그래머(Programmer)

코딩 잘하는 10가지 방법

1. 꾸준히 한다.

- 프로그래밍 언어도 언어(?)라서, 하루에 몰아서 하는 것보다 매일 꾸준히 하는 것이 중요하다.

경력이 많은 프로그래머들도 몇달만 코딩을 안해도 감이 많이 떨어지는 것을 느낀다.

- 특히 프로그래밍을 처음 배우는 사람이라면, 꼭 컴퓨터 앞에 앉지 않더라도 책을 항상 가까이해서 문법 및 표현에 익숙해지도록 하는 것이 중요하다. 자주보는 것이 중요하다.

2. 반복해서 한다.

- 단지 태권도 교본을 잘 이해했다고 해서 멋진 발차기를 기대할수 없는 것처럼, 책의 내용을 잘 이해했다고 해서 하루아침에 프로그래밍을 잘할 수 있는 것은 아니다.

- 이해한 내용을 바탕으로 수많은 반복연습을 통해서만 지식을 진정한 자신의 것으로 만들 수 있다. (같은 예제를 공부하더라도 이리저리 조금씩 변경해서 공부하는 것이 좋다.)

- 처음 2~3번은 자세히 보고, 그 다음 부터는 하루에 10분간 10페이지를 훑어보는 식으로 반복하자.

몇달안에 책에 있는 모든 목차와 예제의 위치와 주요내용을 모두 파악할수 있을 것이다. (적어도 언어책 한권, 데이터베이스책한권 정도는 이렇게 할 필요가 있다.)

3. 좋은 코드를 많이 보고 따라한다.

- 이미 수많은 선배들이 여러문제들에 대한 코딩을 다 작성해 놓았다. 새로운 방법으로 문제를 풀겠다고 도전하는 것은 별 의미가 없다. "이럴때는 이렇게 하는 구나..."라는 것을 배우고 유사한 상황에서 활용하면 되는 것이다. 여러분들이 해야할일은 이러한 경험들을 많이 쌓아 나가는 일이지, 기존과는 다른 새로운 코딩방식을 만들어 내는 것이 아니다.

- 좋은 코드는 보기에도 좋다. 잘정리되어 있고, 별로 특별한 것이 없다. 프로그래밍의 각요소들을 잘이해하고, 각 요소들을 적재적소에 바르게 사용하면 되는 것이다. 단지 소스의 라인수를 줄인다고해서 좋은 코딩이 아닌것이다. 로직이 소스코드에 잘드러날수있게 쉽고 평범하게 작성하는 것이 좋은 코드인 것이다. 이창호의 바둑이 평범하듯이...

4. 기본에 충실한다.

- 빨리 프로그래밍을 배워서 뭔가 해보고 싶은 여러분들의 마음을 이해하지 못하는 것은 아니다.

그러나, 프로그래밍 하루이틀 할 것도 아니고... 처음에 기본을 잘배워놓지 않으면, 그 이후에는 기회가 잘 없다. 실무에서는 매일 개발하기 바쁘고, 새로운 기술 배우기 바쁘고...

- 배울것이 많다고 생각할지 모르나, 실제로 원리는 모두 같다고 해도 과언이 아니다. 하나를 깊이있게 파고들면 나머지는 다 여러분 손에 있을 것이다.

5. 코드를 작성하기전에 순서도를 그린다.

- "프로그래밍 = 코딩" 이 아니라 "프로그래밍 = 로직설계 + 코딩" 이다. 필자가 생각하는 로직설계와 코딩간의 비율은 8:2 정도이다.

- 포토샵만 잘한다고 디자이너가 아니라는것은 여러분들도 잘알고 있을 것이다. 새로운 기술이나 프로그램을 공부하는 것도 중요하지만, 어떤 과제가 주어졌을때 이를 잘 분석하고 설계하는 능력을 장기적으로 키워나가도록 노력해야할 것이다. (다양한 주제에 대해서 문제를 풀어보고 다양한 종류의 책을 읽자.)

- 문제를 구성하고 있는 주인공들을 찾아서 나열해보라. 그리고 이들간의 관계는 무엇이고, 규칙은 무엇인지 적어보라. (머릿속으로만 생각하지말고!)

6. 주석을 가능한한 많이 적는다.

- 주석은 매우 유용하고도 중요한 요소이다. 그럼에도 불구하고 많은 사람들이 이를 소홀히 한다.

자신이 작성한 코드도 몇일만 지나면 이해가 안되는 경우가 많다. 적어도 이해하는데 시간이 걸린다. 주석은 이러한 시간들을 절약해줄것이며, 보다 에러가 적은 코드를 작성하는데 도움을 줄 것이다. 특히 여러사람이 공동작업을 하는 경우에는 더욱 더 중요하다. 서로를 위해서...

- 작업과 관련된 가능한한 많은 정보를 주석에 담도록 하자.

7. 작업일지를 작성한다.

- 과학자들이 매일 연구한 내용을 일지로 적듯이 여러분들도 일지를 적어보자. 오늘은 이렇게 저렇게 해봤는데 잘안되었다... xxx.java의 코드를 이렇게 바꾸었다. 몇시몇분에 xx로 백업받아 놓았다... 라는 식으로 가능한한 자세히 적도록 한다. 이렇게 함으로써 여러분들의 경험을 기록 으로 쉽게 보관할수 있으며, 문제해결에 많은 도움이 된다.

8. 자신의 소스를 가꾼다.

- 보통 코딩을 마치고 나면, 모든 것을 덮어두곤 한다. 원하는 결과를 얻었다고 거기서 그치지 말고 이제 로직과 코드를 보다 효율적으로 개선할 방법이 없는지 고민해보자. 글을 써놓고 좋은 글로 만들기 위해 읽고 또 읽고 다듬듯이 코드를 다듬어보자. 여러분들의 코드를 구사하는 능력이 보다 향상되어가는 것을 느낄 수 있을 것이다.

- 여러분들을 위한 제안은 작은 프로그램을 만들어서 오랜기간동안 점차 발전시켜 나가는 것이다. 새로운 기능들을 하나씩 추가해가고, 기능을 발전시켜나가보자. 이과정을 통해서 여러분들의 실력 은 몰라보게 향상될 것이다.

9. 생각하라.

- 항상 머릿속에 한 가지 문제를 준비하라. 지하철을 기다리거나, 화장실에서 볼일 볼때 문제를 풀어보자. 유레카를 외치고 뛰어나올지도...

10. 좋은 책을 선택한다.

- 공부를 시작할때 제일 먼저 하는 일은 아마도 책을 고르는 일일 것이다. 보통 책하나에 수십시간을 학습하게 되는데, 책을 잘못선택한 경우 수십시간과 노력을 허비하는 셈이다. 바른 책을 고르는 일은 쉬운일이 아니지만, 최소한 몇시간을 투자해서 최선의 선택을 하도록 노력

해야 수십시간을 허비하는 일이 없을 것이다.

- 책을 고르는 법은 여러가지가 있겠으나, 가장 중요한 것은 본인이다. 서점에서 같은 종류의 몇가지 책을 놓고 서로 비교해보면, 시간을 들인 만큼 보다 나은 선택을 할 가능성이 높아진다.

- 많은 컴퓨터 서적이 독자들의 선택을 어렵게 하고, 컴퓨터 업계 특성상 좋은책을 만들기 보다 빨리찍어서 파는 것이 더 중요해진 요즘. 독자들의 바른 선택이 보다 나은 책이 출판되는 것을 가능하게 한다는 것을 알았으면 한다.

 프로그래머의 변명 Top 20.

20위 : 거참 이상하네. 

19위 : 전에는 그런 적이 없었는데...... 

18위 : 어제만 해도 잘 됐어요. 

17위 : 어떻게 그럴 수가...... 

16위 : 그건 하드웨어 문제에요. 

15위 : 뭘 어떻게 했길래 그렇게 만들었어요? 

14위 : 데이타를 이상하게 입력했을 겁니다. 

13위 : 이번에는 그 모듈에 손도 대지 않았어요! 

12위 : 최신 버전이 아닐 겁니다. 

11위 : 정말 흔치 않은 우연이군요. 

10위 : 이 모든 걸 내가 다 테스트 할 순 없잖아요! 

9위 : 이게 그 원인은 절대 아닙니다. 

8위 : 될 겁니다. 테스트는 안 해봤지만...... 

7위 : 누군가 내 소스코드를 바꿔놨군. 

6위 : 바이러스 검사는 하셨나요? 

5위 : 작동은 안되지만, 써 보시니까 어때요? 

4위 : 지금 가지신 시스템에서 그 버전을 사용하시면 안됩니다. 

3위 : 왜 꼭 그 방법으로 사용하려고 하세요? 

2위 : 프로그램이 날아갈 때까지 넌 뭐했어? 

1위 : 그 문제는 해결된 줄 알았는데......