포스팅 이전

https://jeho.page/essay/2012/01/13/GetLastError-%ED%95%A8%EC%88%98-%EC%82%AC%EC%9A%A9%EC%9D%98-%ED%9D%94%ED%95%9C-%EC%8B%A4%EC%88%98.html

포스팅 이전

https://jeho.page/programming/2012/01/03/NTFS%EC%97%90%EC%84%9C-Sparse-%ED%8C%8C%EC%9D%BC%EC%9D%84-%EB%A7%8C%EB%93%A4%EA%B8%B0.html

얼마나 재능이 있고 열심히 공부하는지에 따라서 다르다. 만약 충분히 노력한다면 1년 반에서 2년 정도 사이에는 꽤 훌륭한 수준의 기술을 갖게 될 수 있다. 하지만 그게 끝이라고 생각해선 안된다. 훌륭한 프로그래머가 되기 위해서는 10년 정도가 걸린다.
만약 진정한 해커가 되고 싶다면 끊임없이 학습하고 기술을 다듬는데에 남은 인생 모두를 투자해야 한다.

블로그 이사했습니다.

https://jeho.page/essay/2011/12/20/linux-is-obsolete.html

포스팅 이전

https://jeho.page/essay/2011/12/19/%EA%B5%AC%EC%A1%B0%EC%B2%B4%EC%9D%98-%ED%8C%A8%ED%82%B9%EC%97%90-%EB%8C%80%ED%95%9C-%EC%9D%B4%EC%95%BC%EA%B8%B0.html

파이썬 프로그래머가 자바 프로그래머보다 똑똑하다. - 위대한 해커에서

개발자들은 스타일에 관한 이야기를 하는 것을 좋아합니다. 이 문제는 마치 "무엇이 진정한 하나의 에디터일까"에 대한 이야기처럼 자주 입에 오르내립니다. 마치 이견이 있는 것처럼 말이죠. 답은 이맥스입니다. - Effective STL에서 컨테이너들의 범위 멤버 함수를 사용하는 것은 단일 요소 멤버 함수를 사용하는 것보다 모든 면에서 좋기 때문에 이견이 있을 수가 없다는 것을 설명하면서.

블로그 이사 했습니다.

https://jeho.page/essay/2011/12/06/ken.html

블로그 이전했습니다.

https://jeho.page/essay/2011/12/05/donald-knuth.html

블로그 이전했습니다.

https://jeho.page/essay/2011/12/03/bjarne-stroustrup.html

블로그 이사했습니다.

https://jeho.page/essay/2011/12/02/linus.html

거꾸로 배우는 소프트웨어 개발 - 이호종 지음/로드북

• 개발 표준
• 코딩 스타일
• 공통 라이브러리/프레임워크
• 문서화 표준
• 개발 기반
• 소스 코드 관리 시스템
• 이슈 트래커
• 개발/테스트/운영서버 분리
• 지속적 통합
• 개발 기법
• 단위 테스트
• TDD
• 리팩터링
• 개발 방법
• 폭포수 vs. 애자일
• 조직론.
• 스크럼.
• 협업.
• 개발 관리.

위의 내용들은 소프트웨어 개발에 있어서 아주 중요한 내용들이지만 학생 때는 쉽게 접하지 못하는 내용들이다. 보통은 처음 회사에 들어가고 나서 저런 것들을 배우게 되는데, 아주 잘하는 회사도 있고 그저 그런 회사도 있기 때문에 회사를 잘 골라 들어가는 것이 중요하다.

취업이 안된다고 초조한 마음에 우선 1, 2년만 배우고 좋은 회사로 옮겨야지 하고는 저기 구로공단에 이름 없는 아무 회사나 들어가서는 안된다는 뜻이다. - 구로공단은 그냥 예로만 들었을 뿐 나쁜 의도는 없다.

그런 작은 회사들 중에는 소스코드 관리 툴도 사용하지 않는 곳이 잔뜩 하기 때문에 그런 곳에 들어가면 고생은 고생대로 하고 시간만 낭비하는 셈이다.

이 책에서 나오는 내용들을 가장 쉽고 빠르게 터득하고 싶은 방법은 이런 시스템이 잘 구축되어 있는 회사에 들아가는 것이다. 어떤 회사가 잘하는 회사인지 잘 모르겠다면 어느 정도 이름을 많이 들어봤고 개발자 수가 많은 회사를 찍는 것이 맞을 확률이 높다.
만일 그런 회사에 다니고 있지 않다면 회사를 옮기는 것도 좋다고 생각한다. 스스로 공부하면서 배울 수도 있겠지만 쉽지는 않을 것이다. 서버를 구성하는 것도 몹시 귀찮은 일인데다가, 혼자서 이슈 트래커에 이슈를 기록하고 완료하면 (왕따놀이를 하는 것도 아니고) 도대체 무슨 재미로 하나.

아래 위키 페이지에 있는 회사들은 적어도 소스코드 형상 관리툴 정도는 모두 사용할 것이라 생각한다.
대한민국의 IT기업

반면에 CI 서버를 구성해놓고, 코드 커버리지 측정이나 정적 분석 등을 자동으로 수행 하고 있는 회사는 여전히 별로 없는 것 같다. NHN에서는 위 목차의 내용을 모두 하고 있고 심지어는 코드의 라인 수 까지도 체크해서 라인이 얼마가 늘었고 라인당 버그수가 얼마인지 까지 보고 되는데 이건 얼핏 보면 한심하고 쓸데 없어 보이지만, 내 생각은 안하는 것보다는 훨씬 낫다이다.

잘 구축된 CI 서버는 마치 똑똑한 군사와도 같다. 전쟁의 상황에 대해서 지속적으로 보고 해주고 위험한 일이 발생하면 적절한 조언도 해주는 것이다.

어떤 사람들은 위에서 나오는 내용들을 꼭 대학교 커리큘럼에 넣어야 한다고 주장하는데, 거기에는 별로 동의하지 않는다. 이 많은 과정을 쑤셔넣으려면 그만큼을 빼내야 하는데 무슨 과목을 빼낼 셈인가.

Damn. We say "if it's raining, open your umbrella" and NEVER "if it's true that it's raining, take your umbrella"... Testing explicitely against boolean is as verbose and as un-natural as the second example

Writing Solid Code - Steve Maguire 지음, 나윤석 외 옮김/높이깊이

애플, 마이크로소프트, HP 같은 회사에서 15년 동안 일했던 (지금은 NHN에서 일하고 있는) 송창현 이사가 예전에 우리회사에 면접을 보러 왔을 때 잘하는 게 뭐냐고 물어봤더니,

"저는 meticulous code reader입니다. 남의 코드를 아주 꼼꼼하게 읽어줄 수 있습니다."

블로그가 아래 페이지로 이사했습니다.

https://jeho.page/essay/2011/10/05/idea-man.html

블로그 포스팅 이전

https://jeho.page/programming/2011/09/27/%EB%A0%88%EC%A7%80%EC%8A%A4%ED%8A%B8%EB%A6%AC%EC%9D%98-volatile-%EC%98%B5%EC%85%98.html

http://www.explorerplusplus.com/software/images/screenshots/screenshot_2.png

• 탭 기능을 지원한다. 물론 껐다켜면 탭들이 모두 그대로 복원되므로 자주 사용하는 위치들을 탭으로 몽땅 띄워놓고 사용하면 된다.
• 여러 인스턴스가 뜨지 않도록 할 수 있다. 프로그램을 한번 더 실행시켜도 새 탭만 하나 더 생긴다. 내가 가장 바랐던 기능이다.
• 폴더 사이즈도 표시할 수 있다. NTFS는 폴더 크기에 대한 정보를 가지고 있지 않으므로 Explorer++이 뒤에서 열심히 돌면서 사이즈를 구해낸다. 나는 이 기능은 사용하지 않는다.
• 파일 1개 짜리 프로그램이다. 나는 인스톨러로 설치안하고 바로 사용할 수 있는 이런 프로그램들이 너무 좋다.
• 오픈 소스이다.

나쁜 점

• 잘 뒤진다.
• 안 예쁘다. 토탈 커맨더보다는 조금 더 나은 것 같기도 하지만.

근데 난 작명할 때 ++ 이란 말 좀 쓰지 말았으면 좋겠다. 발음하기도 어려운데다가 정말 촌스럽지 않은가?

프로그래머 그 다음 이야기 - 임백준 외 지음/로드북

얼마전에 나온 신간이며, 프로그래머들이 가볍게 읽어보기 딱 좋은 책이다.
6명의 프로그래머에 대한 에세이들이 있는데 1번타자인 임백준씨의 글을 가장 재밌게 읽었다.

잠시동안 관리자의 역할을 맡게되면서 프로그래밍 실력이 떨어질까봐 걱정하는 마음.
옆의 똑똑한 동료들과 경쟁을 하고 함께 토론을 하면서 실력을 재보고, 또 그들을 도저히 이길 수 없겠다는 한계를 느끼며 좌절하는 감정들을 솔직하게 잘 썼다. 이런 것들은 프로그래밍이라는 것을 정말로 진지하게 생각하고 좋아하지 않으면 느낄 수 없는 감정들이다.

미국 회사들의 분위기를 엿볼 수 있는 것도 좋았다.
아, 그런데 임백준씨도 그렇지만 많은 사람들이 한국에서 일하는 프로그래머들이 너무도 힘든 삶을 살고 있는 것으로 생각한다.
정말 그런가? 나는 비록 경력이 5년 정도 밖에 되지 않고 회사도 2군데 밖에 다녀보지 않았지만 여태까지 그런 것은 느껴보지 못했다. 뜨거운 여름날에 와이셔츠가 온통 땀으로 쩔어서 영업하러 나갔다가 잘 안풀리고 들어와서 욕이나 실컷 얻어먹는 세일즈맨들에 비하면 시원한 사무실에 앉아서 커피 한잔 하며 코딩하는게 얼마나 편안한가.

사람들은 항상 자신이 하는 일을 더 고되고 힘들게 포장해서 자랑스럽게 말하는 경향이 있는 것 같다.
- 우리 부대군기는 진짜 빡셌어.
- 요즘 어린 애들은 버릇이 없어. 우리 때는 그런거 상상도 못했는데.
- 니가 몰라서 그렇지 우리 부서가 얼마나 힘든데.

프로그래머로서 스트레스를 받는 순간이 있다면 기능을 정해진 시간에 맞춰서 구현해낼 수 있을까 하는 약간의 초조함과 동료와 기술적으로 의견 충돌이 발생했을 때, 그리고 심각한 버그를 보고 받았는데 문제가 잘 안 풀릴 때 정도이다.

다른 직종에서 일을 해본적은 없기 때문에 비교해서 생각해볼 수는 없지만, 사람들이 생각하는 것처럼 프로그래머가 못해먹을 직종은 아닌 것 같다. 진짜 못해먹을 일 하면서 사는 사람들이 얼마나 많은데.

임백준씨의 에세이는 아주 즐겁게 읽은 반면에 다른 에세이들에서는 별로 재미를 느끼지 못했다.
이 책에 나오는 프로그래머들은 열심히 살아왔고 좋은 프로그래머들임에는 분명하지만 옆자리에서 흔히 볼 수 있는 평범한 프로그래머들이다. 그럼에도 불구하고 이미 프로그래머로써 무언가 큰 것을 이룬 사람들처럼 자서전을 쓰듯이 글을 썼기 때문에 재미가 떨어지지 않았나 싶다.

그러고 보니 정말로 무언가 큰 것을 이룬 국내 최고의 프로그래머들을 불러다가 어떻게 공부했는지 에세이를 써보라고 하면 그것도 참 재밌는 책이 될 것 같다.