예전에 작성했던 글을 다시 보게 됐다. 좋은 프로그래머란 무엇일까? (http://elky.tistory.com/174) 4년이 지난 지금 내가 생각하는 좋은 프로그래머란 무엇일까? (지금은 프로그래머란 표현보다 엔지니어란 표현을 좀 더 즐겨쓴다. 이것도 마인드의 변화겠지?) 우선 무엇보다 부드럽게 이야기하는 법, 대화 자세 이런건도 좋아졌고. 현실과 타협도 많이 한거 같다. 이전에는 책에서 보거나 느낀 최선을 실천하지 못하면 마음이 너무 불안했다. 그런데 그 실천이란 것을 주변 상황을 둘러보지 않고 하다보니, 이 상황에서 중요한 판단들을 놓쳐왔다. 예를 들면 원인 파악보다 중요한게 현재 상황에 대한 대처인 경우가 많다. 또한 패치가 얼마 남지 않은 상황에서 큰 설계상 오류에 대한 대처는 패치를 미루거나..
나는 처음 프로그래밍을 배울 때, 독학 기간이 길었던터라 하나 익히는데에 (특히 포인터) 꽤나 긴 시간이 필요했고, 어떤게 좋은지 나쁜지를 대부분 경험으로써 느껴왔다. 최초 설계에 구현을 어떻게든 맞추는 일도 해보고, 설계가 존재하지 않는 run and fix 프로그래밍도 해보고, 프로토타입을 많이 만들어놓고 베스트한걸 고르기도 해봤다. 다양한 방법을 경험하던중 안좋은 습관 하나가 붙었다. 너무 바쁘게 일을 하다보니 정리의 습관이 부족해 졌단 것이다. 내가 감당하기에 힘들만큼 버겁고, 많은 일이 주어지긴했지만, 그런 것들은 결국엔 다 핑계고 조급한 맘이 문제였다. 메모의 기술에 대한 서평에서 내가 메모를 기록과 증빙의 용도로 사용한다고 얘기했지만, 사실 내 머릿속에 있는 내용을 정리하는 과정으로도 많이 ..
어느 날 문득, '좋은 프로그래머'란 어떤 의미일까라는 생각을 하게 됐다. 내가 떠올린 좋은 프로그래머를 분류 해보자면 '실력은 보통이지만 같이 일하기 좋은 프로그래머', '굉장히 능력이 뛰어난 슈퍼 프로그래머', '매우 꼼꼼해서 실수를 거의 하지 않는 프로그래머' 정도로 나뉘어졌다. 생각해보니 나는 어떤 부류에도 포함이 되지 않았다. 현재 내가 생각하고 있는 좋은 코드와 개발 방향에 대한 의지가 너무 강해 같이 일하기 좋은 사람이 되지도 못했고, 슈퍼 프로그래머도 아니며, 실수 빈도도 낮지 않다. 상황이 이렇다보니 나 자신에 대한 확신을 갖기 어려워지고 있었다. 슈퍼 프로그래머는 타고 나는 것이니 패스하고 나머지 두개를 생각해봤다. 내가 같이 일하기 좋은 프로그래머가 되려한다면 어떻게 해야 할것인가? ..
- Total
- Today
- Yesterday
- CppSQLite
- 리버스 엔지니어링
- NDC2013
- EzShortcut
- 엘키
- RoR
- 멀티스레드
- 좋은 프로그래머
- 게임개발포에버
- TraceRoute
- 루비
- c언어
- 디자인 패턴
- svn
- 임백준
- 바로가기 프로그램
- Ruby on Rails
- ftp
- ruby
- MS-SQL
- 루비 온 레일즈
- 디버깅
- perfmon
- TDD
- 조엘 온 소프트웨어
- Rails
- EasyExec
- SDL
- 게임데브포에버
- SQLite Spy
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |