- 개발/관리도구
- Build your personal knowledge base with Trilium Notes
- Proposal: Go 2 transition
- malloc / free replacement for unmanaged, linear memory situations (e.g. WASM, embedded devices...)
- Do not use Task Manager for Memory Info: Process Explorer를 대신 사용하자.
- Microsoft Changes Job Interview Process--No More Brain Teasers
- PRU tips: Understanding the BeagleBone's built-in microcontrollers
- [pdf] Minimalism - A Practical Guide to Writing Less Code
- Why is Python so slow?
- [B급 프로그래머] 모바일 앱이 아닌 웹 사이트부터 시작해야 하는 이유(본인이 쓴 글)
- "파이썬 앱 패키징·배포를 더 쉽게"··· '파이옥시다이저' 프로젝트 시작
- Software Engineering at Google
- Maven Central mirror hosted on Google Cloud Storage
- Gaia - Build powerful pipelines in any programming language.
- 나이 든 개발자는 무엇으로 살아야 할까?
- Software Engineer Level comparsion(페북, 구글, 아마존)
- Explore Kubernetes - All of DigitalOcean’s Kubernetes resources and guides, all in one place
- Python is now available on Windows 10 via the Microsoft Store
- Bytecode compilers and interpreters
- Interesting comment in the source code of sqlite
- 알고리즘 학습에 대한 조언
- Merlin is a cross-platform post-exploitation HTTP/2 Command & Control server and agent written in golang.
- Pathfinding for Tower Defense
- CNCF Survey: Use of Cloud Native Technologies in Production Has Grown Over 200%
- Learning KVM - implement your own Linux kernel
- [pdf] Essential C
- Microsoft Open-Sources the UEFI Core Used by Surface Devices and Hyper-V
- Five Things Every Developer Should Know about Software Architecture
- bake - A cargo-like buildsystem and package manager for C/C++
- 리눅스의 페이지 캐시와 버퍼 캐시
- What Your Computer Does While You Wait
- Extreme Pipelines
- Gravitee - UNLEASH THE POWER OF YOUR APIS
- Do you need a web framework for Go?
- 구글 고 버전 1.12, 무엇이 달라졌나? 구 버전과의 비교분석
- [B급 프로그래머] 소프트웨어 엔지니어들이 읽기 어려운 코드를 만드는 이유는?(본인이 쓴 글)
- Crypto 101 is an introductory course on cryptography, freely available for programmers of all ages and skill levels.
- SSH Examples, Tips & Tunnels
- [pdf] Do Developers Understand IEEE Floating Point?
- Free Sheels for a Free World
- Awesome golang Security resources
- A TODO app using grpc-web and Vue.js
- [pdf] Microsoft Word for Windows 1.0 Postmortem (1989)
- [pdf] White book: Software Architecture, all you need to know
- Inside Stack Overflow’s Monitoring Systems
- 루비 2.6 릴리즈 및 주요 문법 변경 사항 소개
- Sloc Cloc and Code Revisited - Optimizing an already fast Go application
- Node.js Fundamentals: Web Server Without Dependencies
- 고성능 서버/데이터베이스
월요일, 1월 07, 2019
[B급 프로그래머] 1월 1주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문)
토요일, 9월 01, 2018
[B급 프로그래머] 8월 5주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문)
- 개발/관리도구
- Django provides a small set of tools that come in handy when writing tests.
- Changing Our Approach to Anti-tracking
- CLI: improved
- Java's new Z Garbage Collector (ZGC) is very exciting
- [번역] 더 나은 폼 디자인하기
- [마이크로서비스] 아키텍처 구축하기
- The State of Java Serialization
- Civilization written by JavaScript
- CS520 Theory of Programming Languages, Fall 2018, KAIST
- Monitoring and Observability
- Monitoring in the time of Cloud Native
- Amazon Lightsail 업데이트 – 신규 인스턴스 타입 추가 및 가격 대폭 인하
- Jib, a Java Container Image Builder from Google
- Pandoc - a universal document converter
- RSSHub is a lightweight and extensible RSS feed aggregator, it's able to generate feeds from pretty much everything.
- Monitoring Isn't Observability
- 5 automation trends in software development, quantified
- Serverless computing update: The latest on the top 4 platforms
- Build a Chat App with Socket.io, MongoDB, Express, Vue.js 2 and Node.js (MEVN)
- Windows의 네트워크 연결 문제 해결
- I Contribute to the Windows Kernel. We Are Slower Than Other Operating Systems. Here Is Why.
- 메모리 특강
- text tetris
- Why is a Java guy so excited about Node.js and JavaScript?
- Crafting Interpreters
- How World of Warcraft Was Made: The Definitive Inside Story of Nearly 20 Years of Development
- The Age Of Invisible Disasters
- Browsix - UNIX IN YOUR BROWSER TAB
- Introduction to Go Modules
- arduino-cli - Arduino command line interface
- 9 AWESOME TIPS FOR GO DEVELOPER
- Remote Code Execution on a Facebook server
- Java, 추천 프레임워크 및 라이브러리
- GIF 사용을 멈춰주세요!
- The Rise and Rise of JSON
- The Behavior of Channels 번역 문서
- ThinkPad Compact USB Keyboard with TrackPoint - Korean: 예전 씽크패드 키보드 생각남...
- #noprojects - A Culture of Continuous Value
- PyPy.js is an experiment in building a fast and compliant python environment for the web.
- Workman Keyboard Layout - The Layout Designed with Hands in Mind
- Set up a personal IPSEC VPN in the cloud
- 리눅스 서버 60초안에 상황파악하기
- Getting to Know Graal, the New Java JIT Compiler
- What Did Ada Lovelace's Program Actually Do?
- pycon2018 슬라이드 링크들
- Parallel Programming with Python
- BackYourStack - Discover the Open Source projects* your organization is using that need financial support.
- SCALe (Source Code Analysis Lab) is a static analysis aggregator/correlator which enables a source code analyst to combine static analysis results from multiple tools into one interface, and also provides mappings for diagnostics from the tools to the SEI CERT Secure Coding standards.
- gdb-dashboard - Modular visual interface for GDB in Python
- Introduction to Go Modules
- GoAWK: an AWK interpreter written in Go
- How To Write Unmaintainable Code
- Create a simple cross-platform desktop game with Go
- tinygo - Go compiler for small devices, based on LLVM.
- CLI Love Inside
- git-bug - Distributed bug tracker embedded in Git
- 고성능 서버/데이터베이스
- Amazon Aurora – PostgreSQL을 통한 장애 복원 기능 활용하기
- JDBC Internal - 타임아웃의 이해
- InnoDB Progress Information
- Real world SSD wearout
- 공식 한국어 분석 플러그인 “노리”
- PostgreSQL Accessing MySQL as a Data Source Using mysql_fdw
- AWS의 클라우드 구성 오류 문제, 해법은?
- Question about Semi-Synchronous Replication: the Answer with All the Details
- An introduction to distributed systems
- Using AWS EC2 instance store vs EBS for MySQL: how to increase performance and decrease cost
화요일, 8월 12, 2014
[B급 관리자] 리더에게 가장 필요한 기술
하버드 비즈니스 리뷰 기사 중에 The Skills Leaders Need at Every Level라는 내용이 올라와서 재미있게 읽었다. 독자 여러분들께 여러 관리 위치에서 리더에게 가장 필요한 기술을 정리해드리겠다.
- 다른 사람들에게 영감을 주고 동기를 부여하는 능력(38%)
- 진실성과 정직을 보여주는 능력(37%)
- 문제 해결과 이슈 분석 능력(37%)
- 결과를 이끌어내는 능력(36%)
- 힘있고 왕성한 의사 소통 능력(35%)
- 협동과 팀워크 배양 능력(33%)
- 관계 형성 능력(30%)
- 기술적이고 전문적인 지식(27%)
- 전략적인 균형 감각(24%)
- 타인 계발(21%)
- 혁신 능력(16%)
- 변화 능력(16%)
- 그룹을 외부 세상과 연결하는 능력(12%)
- 도전적 목표 수립 능력(10%)
- 자기 계발 능력(9%)
사람들이 조직 상위로 올라갈수록 필요한 근본적인 기술은 급격하게 변하지 않는다. 물론 상대적인 기술의 중요도는 바뀌기 마련이라서, 중간 관리자는 문제 해결 능력이 아주 중요하다. 위로 올라가면 힘있고 왕성한 의사 소통 능력이 중요해진다.
스스로에게 현 상황에서 어떤 역량이 가장 중요한지 물어보는 이외에도 향후에 어떤 역량이 중요해지는지 물어보기 바란다. 앞으로 나갈 방향은 언제나 자기가 정하니까.
EOB토요일, 3월 09, 2013
[B급 관리자] 사후분석 AAR(After-Action Reviews)
Replacing the Performance Appraisal을 읽다 보니 AAR이라는 낯익은(?) 단어가 눈에 띄웠다. 한국어로 번역하면 '사후 분석'인데, 베트남 전을 거치며 땅에 떨어진 가치, 진실성, 책임과 의무를 회복하는 수단으로 1973년부터 미 육군에서 활용하기 시작한 방법이다. 단순히 정해진 작업만 하는 대신 작업(품질, 효율, 성과)을 개선하려 노력해야 마땅한 모든 조직(특히 사람 목숨이 걸려있거나 사회를 지탱하는 기간 시설을 운영하는 분야)에서 이 기법을 활용하고 있다.
AAR의 핵심이자 매번 수행할 때마다 물어봐야 하는 중요한 네 가지 질문은 다음과 같다.
- 어떤 일이 일어나리라 기대했는가?
- 실제로 어떤 일이 일어났는가?
- 여기서 긍정적인 요소와 부정적인 요소는 무엇인가?
- 무엇을 배웠으며, 다음에는 어떻게 더 잘 할 수 있는가?
AAR의 목적은 잘못이나 문제점을 바로잡으려는 데 있지 않고 생각하는 방법을 바로잡으려는 데 있다. 미육군은 잘못된 가정이 잘못된 행동의 가장 큰 요인이라는 사실을 배웠기 때문에, 잘못 자체를 꾸짖고 비난하는 대신 잘못된 행동을 이끈 사고 방식을 수정하는 방법을 활용하고 있다. 잘못 자체를 꾸짖고 비난할 경우 이를 감추기에 급급하므로 (특히 군대 같은 조직에서) 나중에 더 큰 문제가 일어날 가능성이 높기 마련이다. 로마 시절의 '전투에 패했다고 지휘관의 목을 함부로 치지 않는' 정책과 유사한 측면도 있다는 생각이다.
미 육군은 AAR 질문으로 끝나지 않고 마무리 과정에서 다음과 같은 추가 질문을 하도록 권장하고 있다.
- (생각처럼 잘 되었고 생각만큼 잘 되지 않은) 이번 경험에서 조직이 배워야 할 내용은 무엇인가?
- 앞으로 어떻게 지금과는 다르게 행동해야 하나?
- 여기서 배운 교훈과 결론을 누가 알 필요가 있는가?
- 여기서 배운 교훈을 향후 써먹기 위해 지식 관리 시스템에 누가 입력해야 하나?
- 의사 결정과 계획을 위해 이런 교훈을 리더십 과정에 누가 추가해야 하나?
오류나 실수를 비난하는 조직에서는 사소한 실수조차도 경력에 치명타를 가하기 때문에 이런 질문들을 함부로 하기가 어려울 것이다. 하지만 이런 폐쇄적인 문화는 지속적인 학습과 개선을 가로막는 강력한 방해물이므로 문제점을 깊숙히 숨기는 과정을 반복하다 결국 곪을만큼 곪아 터져 백약이 무효인 순간에 도달하기 마련이다. 원문에도 나오지만, 이런 폐쇄적인 문화를 벗어나려면 AAR 기저에 깔린 배경 사상인 "용서와 기억"이라는 두 단어를 항상 기억하고 실천해야 할 것이다.
보너스: 기업에서 AAR을 활용하는 방법은 실패를 자산으로 만드는 방법: AAR(한국어)에 일목요연하게 정리되어 있다. 이 글을 읽고 AAR에 관심이 가는 독자분들께서는 꼭 읽어보기 바란다. 그리고 지난번에도 한번 소개했지만 [독서광] Managing the Unexpected(영어책이다)도 읽어보면 큰 도움이 되겠다.
EOB금요일, 2월 08, 2013
[B급 관리자] 기가옴 창립자인 옴 말릭의 발표 자료
웹 2.0을 표방하며 업계의 새로운 뉴스를 실어나르는 기가옴을 창립한 옴 말릭의 "Lessons Learned Evolution of a Founder"라는 발표 자료를 읽었는데, 좋은 부분이 눈에 띄여 자체적으로 정리할 겸(요즘 머리가 나빠서... 뭐든 잘 잊어먹는다. T_T) 독자 여러분들께도 소개하겠다. 지난번 인라인으로 올려드린 Papperman의 호응이 좋아 오늘도 발표 자료를 인라인 코드 형태로 삽입해봤다.
본문 중에서 가장 마음에 들었던 부분은 그림으로 캡쳐해서 올려놓은 "Openness is not just a word, it is a state of mind"였다. "'열린 마음'은 단순히 단어라기 보다는 마음의 상태"라는 요약은 소위 말해 잘 나가고 있는 회사를 설명하는 가장 중요한 특징을 정확하게 집어낸 문구가 아닐까? 솔직히 여기저기서 남발하는 "우리 회사는 개방적입니다"라는 말을 들을 때마다 부지불식간에 거부감이 드는 이유는 리더들이 '행동'은 뒷전에 두고 '말'만 남발한 결과가 아닐까 싶다. 막대한 부와 명예는 제쳐두더라도, 평평한 조직에서 '열린 마음'을 바탕으로 응집력 있는 팀을 만들어 역경을 극복해나가며 함께 웃고 일하고 배울 수 있다면 그 자체만으로도 엄청난 성과라는 생각이다. 영어도 어렵지 않고 분량도 짧으니 리더십에 대해 통찰력을 얻고 싶은 분들께서는 한번 읽어보시면 좋겠다.
특별 보너스: 자세한 배경 설명이 필요하신 분들께서는 블로그 글인 Evolution of a Founder: Lessons I have learned를 참고하면 좋겠다.
EOB수요일, 6월 06, 2012
[B급 관리자] What distinguishes the top 1% of PMs from the top 10%?
지난번에 올린 [B급 프로그래머] What makes a good engineering culture? 글을 독자 여러분께서 너무나도 열렬히 성원해주셨기에, 오늘은 후속타를 한번 소개해보겠다.
역시 Quora에 다음과 같은 질문이 올라왔다.
Product Management: What distinguishes the top 1% of product managers from the top 10%?
역시 한글로 번역하자면 "최상위 1% 제품 관리자를 상위 10% 제품 관리자와 구분하는 특징은 무엇인가?" 정도로 보면 되겠다. 이번에도 아마존의 제품 관리자가 직접 대답한 내용이 인상 깊어서 간략하게 요점을 정리해보았다.
- 크게 생각한다: 1% PM의 사고는 지금 당장 투입 가능한 가용 자원이나 오늘날 시장 환경에 제약을 받지 않는다. 이들은 판을 뒤집을 큰 기회를 기술하고 이를 활용하도록 튼튼한 계획을 짠다.
- 의사 소통한다: 1% PM은 반박하거나 무시하기 힘든 주장을 펼친다. 가용한 자료를 적절히 활용하지만 또한 이들은 인원수, 돈 기타 자원을 댈 수 있는 권력자를 설득해 장애물을 해결하도록 다른 쪽 주장, 신념, 계기에도 관심을 기울인다.
- 단순화한다: 1% PM은 20%의 노력을 들여 기능이나 프로젝트의 80% 가치를 얻는 방법을 안다. 이런 작업을 반복적으로 수행하는 방식으로, 제품이나 사업 측면에서 복합적인 효과를 얻는다.
- 우선 순위를 정한다: 1% PM은 프로젝트를 순차적으로 진행하는 방법을 안다. 이들은 단기적인 승리와 장기적인 플랫폼 투자의 균형을 적절히 맞춘다. 또한 적극적인 프로젝트 진행과 방어적인 프로젝트 진행의 균형도 맞춘다. 적극적인 프로젝트는 사업을 키운다. 방어적인 프로젝트는 사업 진행 과정에서 위험을 방어하며 질질 끌지 않도록 막는다(운영, 기술 빚 줄이기, 버그 수정).
- 예측하고 측정한다: 1% PM은 프로젝트의 이익을 적절히 예측하는 능력이 있으며, 과거 경험을 적용하고 비교 가능한 벤치마크를 지렛대로 활용해 이를 아주 효율적으로 수행한다. 또한 프로젝트를 시작하고 나서 이익을 측정하고, 이런 지식을 향후 우선순위 조정과 예측에 활용한다.
- 실행한다: 1% PM은 (뭐가 되었거나) 일단 결과를 낸다. 출시에 필요한 거라면 뭐든 한다. 이들은 임무 범위에 제약이 없다고 생각한다. 필요에 따라 사람을 모으고, 사업을 만들고, 내부 전문가와 드잡이도 벌인다.
- 기술적인 트레이드 오프를 이해한다: 1% PM이 전산학을 전공할 필요는 없다. 하지만 기능의 기술적인 복잡성에 대해 개괄적으로 이해할 수 있어야 한다. 이들은 개발팀과 함께 올바른 기술 트레이드 오프를 결정해야 마땅하다.
- 좋은 설계를 이해한다: 1% PM이 좋은 설계자가 될 필요는 없지만, 위대한 설계의 진가를 알아보고 훌륭한 설계를 좋은 설계와 구분해야 마땅하다. 이들은 설계 담당자에게 위대한 설계와 좋은 설계의 차이점을 명확하게 말할 수 있어야 하며, 좋은 설계에서 위대한 설계로 발전하기 위한 방향을 제기해야 마땅하다.
- 문구를 효율적으로 쓴다: 1% PM은 작업을 마치기 위해 필요한 문구를 간결하게 작성해야 마땅하다. 이들은 장황하게 쓸 때마다 직전 단어의 가치를 희석하는 단어가 포함된다는 사실을 이해해야 한다. 단지 충분함을 넘어서 핵심 문구를 위한 완벽한 단어를 찾으려 시간과 정열을 쏟아야 한다.
좋은 PM이 되기는 어렵고 위대한 PM이 되기는 더욱 어렵다. 위에서 제시하는 1% PM의 좋은 특징을 다시 한번 생각해보면서 프로젝트를 진행하면 도움이 되지 않을까?
EOB일요일, 8월 29, 2010
[독서광] 공피고아: 어떤 조직에서도 승승장구하는 사람들의 비책

공피고아라는 특이한 이름을 자랑하는 이 책은 지난번에 소개한 [독서광] 일개미의 반란: 우리가 몰랐던 직장인을 위한 이솝 우화를 선물한 꼬양이(역시 꼬양이는 이런 부류의 책을 즐긴다. ㅋㅋ)가 추천해서 급히 구입한 책이다. 시중에 흔하디 흔한 사내 정치 본격 입문서 중 하나처럼 보일지도 모르겠지만, 기존 싸구려 처세술(?) 책과는 뭔가 다른 내용이 담겨 있다. 제목인 '공피고아(攻彼顧我)'는 바둑의 기본 전략에서 빌어온 단어이며, "상대를 공격하기 전에 나를 먼저 돌아보라"는 뜻이라고 한다. '정치 게임'을 벌여 상대방을 구워삶은 방법이 아니라 나 자신을 어떻게 되돌아볼지 생각하게 만드는 내용이 이 책의 핵심이다.
이 책은 직장에서 일어나는 여러 가지 사례와 이런 사례를 풀어내기 위해 삼국지에서 적절한 내용을 찾아 설명하고 있다는 점에서 이솝 우화와 직장인의 자세를 혼합해서 설명하는 '일개미의 반란'과 유사한 형태를 보인다. 하지만 우화를 중심으로 풀어가는 '일개미의 반란'과는 달리 사례를 중심으로 풀어가기에 또 다른 맛을 느끼게 만들어준다. 아주 적절하게(읽어보면 무슨 말인지 이해가 갈 것이다) 삼국지에 나오는 예를 들기 때문에 삼국지와 친하지 않은 사람들이라도 어렵지 않게 읽을 수 있으리라 본다. 꼬양이처럼 삼국지를 좋아하는 사람이라면 뭐 두말할 나위도 없이 재미있게 읽을 수 있을테다.
이 책의 장점은 지독한 '현실성'이다(삼국지를 토대로 설명한다고 쌍팔년도 책으로 오인하면 대단히 곤란하다). 이 책을 읽으면서 곳곳에서 데자뷰를 느꼈다. 과거 B급 관리자 주변에서 일어난 황당무개한(지금 생각하면 그리 황당하지도 않다) 일과 가슴 아픈 추억들이 아련하게 되살아나는 동시에 현재 전개되고 있는 여러 가지 시츄에이션(의도적으로 외래어를 썼다. ㅋㅋ)이 머리 속에 그려졌다. 부하로서 상사를 바라보는 시각, 상사로서 부하를 바라보는 시각이 이 책에는 공존하고 있으므로 양쪽에서 서로를 어떻게 바라봐야 제대로 일이 전개되는지 좀더 명확하게 머리에 그려졌다는 점이 가장 큰 수확이다.
지금까지 B급 관리자가 저지른 모든 실수가 주마등처럼 스쳐지나가 몸둘바를 모르겠다. 하지만 과거는 과거! 앞으로는 정신 차리고 제대로 뭔가를 해봐야겠다. 샌드위치도 아닌데 아래 위로 치여서 눈물만 흘리고 있는 중간 관리자들에게 그야말로 강력하게 추천하고, 회사라는 정글에서 살아남기 위해 필사적으로 노력하는 신입 + 신입 티를 막 벗은 사원들에게도 역시 일독을 추천한다. 결론: 2010년 하반기 회사원의 필독서.
EOB
토요일, 8월 07, 2010
[독서광] 프로그래머의 길, 멘토에게 묻다

어느 분야나 마찬가지겠지만, 프로그래머로서 어떤 경력을 밟아 어떻게 발전해 나갈지에 대해 다들 고민이 많으리라는 생각이다. 특히 향후 전망이 그리 밝지 않은 상황에서는 더욱 더 고민이 될 것이다. 그렇다면 어떻게 해야할까? 가장 좋은 해법으로 직접 깨달음을 얻으면 된다. 하지만 직접 깨달음을 얻기 위해서는 무척 힘든 길을 걸어야 한다는 문제점이 있다. 차선책은? 바로 다른 사람에게서 배우는 방법이다.
"프로그래머의 길, 멘토에게 묻다"는 원서 제목("Apprenticeship Patterns")이 암시하듯 도제(apprentice) 시스템에서 살아남아 장인이 되기까지 필요한 패턴을 정리한 책이다. 따라서 이 책은 프로그래머 세상에서 장인이 되기를 원하는 사람을 위해 필요한 조언을 담고 있다고 보면 틀림없다. 여기서 _프로그래머 세상_이라는 말에 밑줄을 그을 필요가 있다. 관리자 세상에서 장인이 되거나 큰 돈을 벌려고 마음 먹은 사람이라면 굳이 아까운 돈과 시간을 낭비하며 이 책을 읽을 필요가 없기 때문이다. 하지만 프로그래머로서 열정이 있는 분이라면 이 책을 읽어보면 도움이 될 것이다(다시 말해, 나이 40 넘어서까지 프로그래머로서 경력을 계발하려고 마음먹은(물론 가능할지 불가능할지는 또 다른 문제지만...) 분들께는 추천한다).
이 책은 장인 정신, 견습 과정, 도제 시스템 관점에서 소프트웨어를 설명하고 있으므로, 체계적이고 시스템으로 동작하고 과학적인 뭔가를 기대한 사람이 읽으면 뜬 구름 잡는 기분이 들 위험성도 있다. 물론 소프트웨어는 예술과 과학, 반복적인 작업과 창의적인 작업, 새로운 개발과 유지보수가 섞여 상당한 불협(?)화음을 내는 분야라는 사실을 돌이켜보면 장인 정신 관점에서 도를 닦으며 자신을 수양하는 방법도 그리 나쁘지는 않아 보인다. 하지만, "납기 준수"가 최고 목표가 되어버릴만큼 급하게 돌아가는 세상이라 과연 내일 점심값을 걱정하지 않고 초심으로 돌아가 수련에 임할 수 있을지는 각자 가치관과 판단에 맡기겠다.
이 책을 읽다보니 시간이 걸리더라도 정석대로 도를 닦는 미래의 장인과 수단과 방법을 가리지 않고 (심지어) 자신의 몸까지 축내가며 사파 무공을 마구 시전하는 무협지의 악당들이 머리 속에서 싸우는 바람에 마음이 편하지 않았다. 과연 "정의의 Force"가 이길지 "악의 Force"가 이길지 정말로 궁금하다. 참고로 B급 _관리자_는 다스베이더 편에 붙었다. T_T
뱀다리: i) 이 책을 쓴 저자들이 목과 어깨에 힘을 좀 뺐으면 좋을 뻔 했다. 자칫 프로그래머용 자기 계발서(읽을 때만 기분 좋은...)가 될 가능성도 엿보였기 때문이다. ii) 한국에서 멘토나 장인을 찾기보다 낙타가 바늘 귀에 들어가는 모습을 목격할 확률이 훨씬 더 높다. 기본적으로 대한민국에서 소프트웨어 개발(아니 프로그래머)은 극히 일부 개발자를 제외하고 부가가치가 낮은 서비스 직업에 불과하기 때문이다(증거: 한국에서 SI나 용역이 아닌 튼튼한 순수 패키지 소프트웨어 개발 회사가 몇 개나 존재하는지 한번 세봐라. 만일 정말 전도유망한 순수 패키지 소프트웨어 개발 회사를 아시는 분이 계시면 추천 댓글을 달아주시기 바란다. 기회가 생길 때마다 적극적으로 인재를 추천해드리겠다.). 따라서 대단한 개발자가 있다면 부가가치를 창출하기 위해 회사에서 절대로 가만히 놓아두지 않으며, 피터의 원칙에 따라 가장 바보가 되는 지위(즉 관리자)까지 승진시켜버릴 거다.
EOB




