리더의 자세 1 – 성장시키거나 받아들이거나
인수인계를 하려고 보니 이것저것 얘기해주고 싶은 것이 많다.
근데 내 생각들이 다 맞다는 보장도 없고, 블로그에나 좀 적어봐야겠다.
성장시키거나 받아들이거나
- 장기적인 안목으로 동료가 성장할 수 있도록 꾸준히 도와주거나
- 결과의 품질을 받아들이거나
지금보다 철이 없던 시절에는 "이렇게 하는 것 보다는, 요렇게 하면 더 좋을 것 같네요" 라고
조언을 하고는 했는데 몇 가지 문제가 생긴다.
- 내 제안이 나쁠 수도 있는데, 권력의 힘으로 강요하는 것이 될 수도 있다.
- 동료의 결과나 내 제안이나 사실 거기서 거기인데, 괜히 기분만 나쁘게 한다.
- 내 제안이 더 좋다고 한들, 언제까지나 일을 대신 해줄 수는 없다.
요점은 이렇다. 실무자들의 능력이 곧 팀의 능력이다. 리더가 아무리 실무를 기똥차게 한다고 해도, 모든 업무의 품질을 자신의 수준으로 끌어올리려는 것은 욕심이다. 이게 욕심이 아니라면, 아무나 뽑아서 좋은 리더에게 맡기면 된다. 굳이 개발자들이 몇 년씩 공부할 필요가 없다.
정리해보면.
동료가 더 좋은 결과물을 내놓기를 원한다면 성장시켜야한다. 이는 장기적인 관점에서 진행해야한다.
동료를 성장시킬 마음이 없다면 지금의 결과물에 만족해야한다.
당장 다그치는 것 만으로 좋은 결과물이 나오길 바란다면 아까운 인생을 허비하고 있는 셈이다.
Programming in Lua 2E 야매요약본
[옛날 블로그 글입니다. 2007/06/15]
[여전히 일본어 잘하고 싶음 -_-;;]
programminginlua2e_summary-muscly
Programming in Lua 2E 를 읽고나서 대략 정리한 내용.
팀에 PT 하려고 정리한 거라서 coroutine이나 thread, 객체지향프로그래밍 등등은 생략했다.
1시간 반 시간 잡고 했는데 반도 설명 못한듯 -_-;;
일본어 잘하게 되면 일본 개발자들 대상으로 해봐야지 ㅎㅎ
undname.exe
[옛날 블로그 글입니다. 2007/09/20]
[요새는 에러 메시지가 친절해져서 필요없을 수도..]
Visual Studio와 함께 설치되는 유틸 undname.
데코레이팅된 C++ 심볼의 이름을 언데코레이트 해주는 유틸리티.
[오늘의 문제]
Q. 분명히 제대로 lib 파일을 링크해주었는데, 왜 심볼을 찾을 수 없다는 링크에러가 나는 것일까?
[풀이 과정]
1. 링크에러 메시지를 살펴보니 다음의 심볼을 못찾고 있다.
?CreatePane@VSIDE@vsautomation@@YAPAUHVSOutputPane__@VSOutputPane@2@PAUHVSIDE__@12@PB_W@Z
2. lib 파일을 열어서 CreatePane으로 검색해보니 비슷한 심볼이 보인다. (아주 살짝 틀리다)
?CreatePane@VSIDE@vsautomation@@YAPAUHVSOutputPane__@VSOutputPane@2@PAUHVSIDE__@12@PBG@Z
3. 두 심볼을 undname 을 통해 원래의 모습을 확인해보니 차이가 명확하다.
아래는 실행 화면. 노란 부분이 각 심볼의 원래 모습.
|
C:\Documents and Settings\jp90637>undname ?CreatePane@VSIDE@vsautomation@@YAPAUH Undecoration of :- "?CreatePane@VSIDE@vsautomation@@YAPAUHVSOutputPane__@VSOutpu
Undecoration of :- "?CreatePane@VSIDE@vsautomation@@YAPAUHVSOutputPane__@VSOutpu |
4. 보아하니 lib를 만들때는 'wchar_t를 unsigned short로 다루기' 옵션으로 빌드되었고,
사용하는 쪽은 'wchar_t를 내장타입으로 다루기' 옵션으로 빌드되었다. (굵은 부분 참조)
[오늘의 교훈]
undname으로 사소한 링크 문제를 해결하자.
VC 2003에서 Win32 static library를 만드니 wchar_t를 unsinged short으로 다루더라.
반면에 MFC App는 wchar_t를 내장 타입으로 다루더라.
경험에 의한 걱정해소법
[옛날 블로그 글입니다. 2007/11/22]
[3년이 지나서 보니, "걱정한 일의 3%만 일어난다"가 맞는 것 같다. ^^;;]
1. 걱정한 일의 3%만 실제 일어난다?
승철이가 기은형 블로그에 적어둔 말.
이게 정말이라면, 큰 위안이 되는 것 같다. ㅎ
2. 사실은 안중요한 일이 아닐까?
인생 절체절명의 위기의 순간도 있겠지만,
바라는 바 대로 안되도 큰 지장이 없는 경우가 많다.
다시 말해, 어느 틈엔가 너무 좁은 시각에 얽매인다는 의미인데,
60살까지 잘 먹고 잘 살려면 어떻게 해야 하나 고민하다가도
시장에서 장사하는 할머니들이 10억씩 기부하는 기사를 보면
민망해지는 그런 느낌이랄까. ㅎ
3. 원래 사는게 그런 거 아닌가.
"원래 자기 맘대로 안되는게 세상살이"라는 진실(?)을 받아들이는 건데
얼핏 자포적인 마음가짐으로 비춰질 수 있지만
목에 힘을 빼야 좋은 노래가 나오고
주먹을 펴야 더 많은 걸 쥘 수 있는
그런 느낌의 말이다.
미천한 해석이지만, 신을 믿는 분들이 신에게 의지하고
어떤 결과가 되던 신께서 내려주신 축복임을 받아들이는 것이
이런게 아닐까 생각을 해보고.
도를 믿는 분들이 자연의 완벽함을 신뢰하고
어떤 결과가 되던 인간의 자아가 개입함이 없다면
자연이 이루어내는 완벽한 현상으로 바라보는 것도
이런게 아닐까 생각을 해본다.
이공계 종사자의 입장에서는, 남자가 아이를 날 수 있는 확률이나
살면서 아무런 문제없이 자기 뜻대로만 될 확률이나
거기서 거기이므로, 남자가 아이를 못난다고 화내지 않는다면
자기 뜻대로 안된다고 화낼 이유도 없는 것 같다.
다시 말해, "이번 일은 잘 되어야 할텐데.." 라는 걱정은
말도 안되는(?) 욕심을 부리는 건 아닐지. ㅎ
RTTI 관련 정보
[옛날 블로그 글입니다. 2007/11/29]
사내 C++ 강좌를 준비하던 중에 RTTI 구현을 좀 파고 들어봤다.
정리하고 나니 사내 강좌용으로는 좀 어려울 것 같아서
그냥 여기에 정래해 둬야 겠다 -_-;;
-
typeid() 연산자의 내부 코드의 일부 발췌 (VS7.1)
| 004283AE mov ecx,dword ptr [inptr] // intptr이 객체의 주소 004283B1 mov edx,dword ptr [ecx] // vfptr의 값을 꺼낸다. 즉, vftable의 주소 004283B3 mov eax,dword ptr [edx-4] // vftable 바로 앞의 4바이트를 읽는다. RTTI 정보 주소 004283B6 mov dword ptr [pCompleteLocator],eax // RTTI 정보 주소 얻기 성공!! |
결론은, vftable 바로 위에 RTTI 정보 (RTTI Complete Object Locator)의 주소가 보관된다.
-
RTTI 정보의 구조 (VS7.1)
아래에서 Mac 은 클래스의 이름이다.
그리고 pTypeDescriptor ( RTTI Type Descriptor)가 바로 type_info 클래스가 된다.
결론은 RTTI 정보에서 12바이트 옵셋에 type_info 클래스의 주소가 보관된다.
-
이 정보를 토대로 나만의 type_id 연산자 만들기.
확인을 위한 것 뿐이므로 범용적이지는 않다. (포인터 타입 안됨 ㅎ )
|
#include <typeinfo>
typedef unsigned int __w64 DWORD; using namespace std;
class Computer {
class Mac : public Computer {};
template < class T > const type_info& my_typeid( T& obj )
template < class T > const type_info& my_typeid( T* ptr )
cout << typeid( pm ).name() << "\n";
cout << my_typeid( *pm ).name() << "\n"; return 0; >> 결과 class Mac * |