이번 장은 팀장의 입장이 아닌 그 위, 여러 팀들과 팀장들을 관리하는 관리자의 입장에서 생각을 한다. 전 회사에서 연구소장이 어떤 기분이었을지 생각을 하며 읽어보았다. 0. 들어가며 정말 훌륭한 리더로 성장하려면 3A 리더십을 필요로 한다. 3A Always be deciding : 늘 결정하라 Always be leaving : 늘 떠나라 Always be scaling : 늘 확장하라 1. 늘 결정하라(Always be deciding) 여러 팀으로 구성된 팀을 관리한다고 함은 기존보다 높은 수준에서 더 많은 걸 결정해야 한다는 뜻이다. 이 높이에서 우리가 내리는 결정 대부분은 여러 전략 사이의 트레이드오프들을 정확히 찾아내는 일이다. 모호한 문제를 전체적인 숲을 보며 풀어나가는 과정은 3단계로 나누..
책 리뷰
내 첫 회사를 퇴사한 지금 팀장의 입장과 팀원의 입장에서 이 글을 읽으며 많은 생각이 들었다. 0. 들어가며 이번 장은 궁극적으로 ‘책임지는 사람’의 시선으로 이야기를 진행한다. 1. 리더와 매니저 구글은 리더 역할을 두 가지로 구분해 생각한다. 관리자(manager)는 사람을 이끌고 테크 리드(tech lead)는 기술과 관련된 책임을 진다. 2. 우리에게 선장이란 선원이 아무리 많다 한들 선장이 없는 배는 그저 길을 잃은 조각배에 지나지 않다. 소프트웨어에서도 선장이 없다면 엔지니어들은 값진 시간을 허비한다. 3. 관리자와 테크 리드(혹은 둘 다) 모든 팀에서는 리더가 있지만 리더를 모셔오는 방법이 다를 수 있다. 팀에서 경험이 많은 팀원을 리더로 하거나 외부에서 리더를 모셔오기도 한다. 신생 팀의 ..
이번 장에서는 특정 ~~ 주의, ~~ 리즘뿐 아니라 다양한 관점에서 우리가 만드는 프로그램이 안전하고 누군가를 무의식적으로 공격하거나 배려하지 않는지에 대해 고민을 할 필요가 있다고 알려주고 있다. 실은 지금까지 프로그램을 만들면 학교 과제나 랩실의 연구 과제, 회사에서 특정 도메인에 대한 테스트 자동화 프로그램을 개발하였는데 이 부분에 대해서도 읽으며 고민을 할 수 있게 되었다. 0. 들어가며 다양한 계층의 사용자를 위한 제품을 설계할 때 엔지니어가 짊어져야 할 책임은 가볍지 않다. 아직 소프트웨어 엔지니어링 분야는 계속해서 개척 중이며 새롭기 때문에 사회적 약자나 다양한 문화관에 미치는 영향을 이해해가는 중이다. 우리는 성장해나가며 깨달은 부분에 대해서 다음 세대의 엔지니어들이 우리보다 나은 결정을 ..
지식 공유에 대한 문화가 없는 팀에서 대략 2년 동안 문화를 만들기 위해 노력을 해보았지만 실패하였다. 이제 2~3년 차 주니어 개발자가 파악하지 못한 이슈가 있었을 수도 있고 더 노력을 했어야 했을 수 도 있지만 결론은 문화를 만드는데 실패하였다. 이직을 앞둔 상황에서 이 장을 읽으며 다시 한번 지난 노력을 생각해보았다. 0. 들어가며 조직에는 각 분야에 대한 전문가들이 필요하다. 전문가는 문제에 대한 답을 스스로 도출할 수 있어야하고 다른 사람의 질문에 대해 답을 줄 수 있어야 한다. 지식 공유를 하기 위해서는 전문가와 더불어 지식을 전파할 메커니즘도 필요하다. 배움의 문화가 자리 잡혀 있어야 하고 이 배움의 문화가 자리잡기 위해서는 사람들에게 모르는 부분을 인정할 수 있도록 돕는 심리적 안전을 제공..
더 뒤에 어떤 내용이 나올지 모르겠지만 2장에서 내가 원하던 내용이 나왔다는 느낌을 받았다. 나도 코드 리뷰를 무서워하며 숨기려 했던 적이 있고 조금 안다고 해서 겸손보다 자만에 가까웠다. 2장의 내용은 이런 개발자들을 위한 내용이다. 1. 불안감 우리 주변 소프트웨어 엔지니어들에 대한 행동 관찰하면 이런 행동이 나타나는 경우가 있다. 코드를 숨긴다. 내가 만든 코드를 숨긴다. SCM히스토리를 제거하거나 숨길 수 있는지 찾아본다. 이 행동들은 불안감에서 비롯되었다. 내 작업물을 다른 사람들이 보고 판단하는 것을 두려워하는 인간의 본성에서 나왔을 것이라 예상한다. 사람은 누구나 비난보다는 칭찬을 받고 싶어 하는데 완성되기 이전의 작업물이라면 더욱 보여주기 불안해 할 수 있다. 문제는 이 불안감은 더 큰 문..
이직 전 책 한 권을 읽고 들어갈까 고민하던 중 요새 이 책이 그렇게 내용이 재미있고 유익하다길래 알라딘 ebook으로 사서 읽고 있다. 읽으면서 내가 느낀 내용을 각 챕터 별로 조금씩 정리를 하고자 한다. 프로그래밍? 소프트웨어 엔지니어링? 우리가 흔히 말하는 프로그래밍은 개발(development) 작업이고 소프트웨어 엔지니어링은 더 포괄적인 의미로 개발, 수정, 유지보수가 들어가 있다. 소프트웨어 엔지니어링은 더 이상 프로그래밍이 아닌 더욱 고차원의 개념이다. 수정과 유지보수는 더욱 고차원적인 개념에서 파생된 부분으로 프로그래밍과 소프트웨어 엔지니어링의 가장 큰 차이를 만들어주는 시간, (규모) 확장, 실전에서의 트레이드오프에서 비롯되었다. 시간이 프로그램에 영향을? 내가 작성을 하던, 하지 않았던..
이번에 길벗출판사 14차 리뷰어에 선정되어 [자바 코딩의 기술] 책을 받고 리뷰를 하게 되었다. 1. 책의 크기 실은 책의 페이지 수와 크기가 생각보다 중요하다고 생각한다. 너무 크고 양이 많으면 부담스럽고 너무 작고 양이 적어도 내용이 부실할 수 있는데 적당한 크기에 부담 없이 읽을 수 있는 양이였다. 2. 책의 내용 작년에 회사에 입사하여 1년동안 자바 개발자로 지내면서 느낀 점을 이번에 이 책과 비교해보려는 목적이 강했다. 책 표지의 아래에 적혀있는 문구 "현장에서 뽑은 70가지 예제로 배우는 코드 잘 짜는 법" 이란 말처럼 자바 언어로 코딩을 하는 데 있어 코드를 깨끗하게 짜는 방법과 여러 팁을 알려주고 있다. 책의 내용에서 '아니 이걸 적어놨네?' 라고 감탄하며 봤던 부분은 java doc 부분..
