리눅스 문제 분석과 해결, Mark Wilding/Dan Behman, 에이콘, ****

간만에 읽을 만한 책이라 판단되어 허겁지겁 읽어내려 갔지만, 결코 만만히 읽어치울 수 없어 마음을 고쳐잡고 찬찬히 읽고 있는 책. 어떤책인지 판단할 만큼 충분히 읽지는 못했지만 남은 부분이 무척이나 기대되는 책이다. 전반적으로 John Robbins가 쓴 Microsoft의 Debugging Applications 이란 책의 리눅스 버젼이라고 생각하면 크게 틀리지 않을 것 같다. 두 책 모두 stack이나 calling convenstion, Assembly level의 디버깅등 고급 디버깅 기법을 설명하고 있다. 단지 서로의 OS환경에 좀 더 의존하고 있기는 하지만, 이런 기술은 결국 하나로 통하기 마련아닌가? 여기서 어떤 책이 더 좋은지를 논할 필요는 없을 것 같다. 두 책 모두 훌륭해 보이며 둘 중 하나를 읽었다 하더라도 여전히 남은 하나를 읽을 가치가 있어 보인다.

여러개의 프로젝트에 참여하기

개발을 하다 보면 종종 여러개의 프로젝트에 동시에 참여하게 되는 경우가 있다. 프로젝트의 진행에는 강약이 있기 마련이지만 여러 프로젝트의 중요 일정이 겹치게되면 감당할 수 없을만큼 많은 일들이 동시에 주어지기도 한다. 서로 다른 프로젝트의 리더가 중요하고 급한 일이라고 각기 다른 일을 던져주고 빠른 피드백을 원한다면 일의 우선 순위를 어떻게 잡아야 할까?

한국적인 정서에서 두 프로젝트 리더를 모아놓고 "두분이서 협의해서 우선순위를 정해주세요" 라고 요청하는 것은 거의 자살행위에 가까워 보인다. 경우에 따라 조금 가혹한 평가일 수도 있지만 적당히 일의 우선 순위를 정해서 상사가 기분나쁘지 않게 적당히 완급을 조절하며 업무를 처리하는 것도 개인의 능력이라고 할 수 밖에 없을 것 같다. 일단 현재 내가 바쁘다는 사실을 인지시킬 수 있다면 어떻게든 상사의 기분을 상하지 않게 주어진 일의 기한을 연장하거나 다른 사람에게 양보? 할 수 있을 것이다.

자신에게 마이너스인지 알면서도 일이 바뻐 눈코뜰 새 없을 때 새로 업무를 던져주는 상사를 보며 인상을 찌푸리는 것은 내가 어쩔 수 없는 까칠한 인간이기 때문일까? 싸가지가 없어서 일까?

하여간 이런 방법으로 상사에게 눈치를 주어 일을 조금 덜 배정 받는 것은 정말 세련되지 못한 방법이다.. 그러지 말자..ㅠㅠ