note

스스로 하려는 사람에게는 인센티브를

스스로 할 마음이 생기도록 동기부여를 하는 것도 아무나 해당되는 것은 아닌 듯 하다.

정말 하려는 의지가 있는 사람에게 재밌는 일을 시키면 좋겠다. “잘해보자” “멋진 걸 만들어보자”가 아니라 “또 뭘 해야 하는 거야?”라는 생각을 가진 사람은 그냥 재미없는 별로 생각할 필요가 없는 일을 맡기는 게 나을 듯.

대신 생각하려 하지 않는 만큼 품질은 낮을테니 철저하게 품질 관리를 위한 체크리스트를 마련해야 한다. 스스로 하지 않는 사람에게는 강제성이 더더욱 필요하게 마련이다.

note

Doxygen 적용시 고민거리

내가 제공하는 라이브러리에 대한 설명을 Header file에 적으면 해당 API를 이용하는 개발자들이 편할 것이고, source code에 적으면 소스 코드를 보는 개발자가 편할 것이고, 그렇다고 둘 다 적을 수는 없고(정보 불일치 발생 가능..)

뭐가 좋은 방법일까?

note

새로운 과제를 위해 사람들이 모였다.

그런데 뭔가 멋진 물건을 제대로 만들어보자고 모인 건지 모르겠다. 그저 한 사람이 말하는 내용을 듣기만 듣고, 시키는 게 있으면 일단 못하겠다, 우리쪽 업무가 아니라고 거부부터 하고, 피할 수 없으면 검토해 보겠다는 자세.

나는 이렇게 생각한다. 이랬으면 좋겠다. 그런 생산적인 의견을 제시하는 것이 아니라 숙제만 받아가겠다는 자세로 사람들이 모인다. 그런 사람은 필요 없는 회의 인데

note

리더는 부 관리자 외에 Think Tank를 가져야 한다.

조직의 크기가 커질 수록, 잘 알아야 판단할 수 있는 부분이나, 자신의 생각에 대한 피드백을 받고, 자신이 생각하지 못하는 새로운 정보를 얻으려면 반드시 기탄없이 의견을 줄 수 있는 사람을 가져야 한다.

그렇지 않으면 아주 예전에 습득한 것 만으로 빠르게 변화는 상황에 대처해야 하는 데 이건 거의 불가능하다고 봐야 한다.

이를 위해 자기의 지시사항을 수행하는 부 관리자외에 Think Tank가 필요하다(물론 이 둘이 같아도 문제 없다)

note

오랫동안 개발자로 남고 싶으면 나의 가치를 유지해야 한다. 이미 알고 있는 것, 널리 알려진 것의 가치는 시간이 가면서 사라지므로 새로운 지식과 경험을 추가해야 한다.

그런 노력도 안하면서 개발자로 남고 싶다면 말만 하는 것 무모한 게 아니라 무식한 거다.

note

잘 하고 싶다.

왜 이렇게 안 할까? 왜 이렇게 못 할까? 같은 궁금증을 풀고, 그렇게 “잘” 해보려면 그만한 능력과 권한을 가져야 한다.