눈높이에 맞게 단어를 선택하라
•
내 가치를 어려운 단어를 동료 앞에서 늘어놓는 것으로 증명하려하지 말자. 문제를 해결해내 보이는 모습으로 증명하자.
•
문제를 해결하기 위해선 소통이 필요하고 소통 과정에선 눈높이를 맞추는 과정이 필요하다.
•
지식의 완성도는 그것을 누군가에게 나누어줄 때마다 견고해진다.
일정은 협의하는 것이다
•
내가 제시하는 일정을 사람들이 잘 못 믿는 것 같다면 다음을 생각해보자.
◦
나는 정말 제대로 된 일정을 산정할 수 있는가?
◦
나는 내가 약속한 일정을 잘 지켰는가?
•
일정을 물어볼 때 최악의 대답은 나도 모른다, 해봐야 안다다. 사전조사가 필요한데 최소한 3일 정도 필요합니다. 최악의 경우 시간이 길어질 수 있지만 조사 완료 후 피드백을 드리겠습니다.는 어떨까?
•
우리가 실력 있는 개발자라고 인정받고 싶다면 개발 일정을 거의 정확하게 예측할 수 있는 역량을 키워야 한다. 당신은 프로 개발자이고 프로는 일정을 산출할 수 있어야 한다. 비즈니스 세계에서 일어나는 모든 개발 활동은 곧 투자이기 때문이다.
누구나 빌드할 수 있어야 한다
•
레포지토리에 커밋된 소스는 누구나 빌드할 수 있는 완성된 상태여야 한다. 빌드하기 위해 사전 작업이 필요하다면 이들도 함께 커밋되어있어야 한다.
•
필자는 다음과 같은 기준을 추천한다.
오늘 아침에 새로운 프로그래머가 팀에 합류했다면 그 개발자 스스로 개발환경을 구축하고, 소스를 내려받고 자신의 개발 PC에서 구동할 수 있어야 하며
오늘 오후에는 본인이 작업한 내용을 빌드하고 테스트하고 심지어 배포까지 할 수 있어야 한다.
동기식으로 일할 것인가? 비동기식으로 일할 것인가?
•
우리는 굉장히 빠른 연산을 수행해내지만 이를 출력해내는 입과 손은 연산 속도를 따라가지 못해 여기서 오는 병목현상에서 문제가 발생한다.
•
소프트웨어의 서로 다른 문맥들이 무언가를 교환하는 것에 대입해 효율화한다는 관점에서 비슷한 노력을 기울인다면 프로젝트의 목표에 좀 더 빨리 다다를 수 있을 것이다.
좋은 개발팀에서 일하고 싶다면
•
개발팀의 본질적인 존재의 목적 관점에서 봤을 때, 좋은 개발팀이란 그 존재의 목적에 부합하는 팀이다. 즉 사용가능한 소프트웨어를 만들어 내는 팀이다.
◦
자유를 보장하는 팀보다 오히려 절제된 통제 속에서 주어지는 자율적인 참여를 통해 나의 잠재력을 끌어내는 곳을 선택하는 것이 좋다.
◦
반대의견을 자유롭게 낼 수 있는 팀이어야 한다. 어떠한 불이익도 있어서는 안 된다.
◦
의사결정은 의사결정자만 하는 것이 낫다. 모두를 만족시킬만한 의사결정은 좋지 않은 의사결정일 확률이 높다.
◦
제품에 대한 애정과 야심이 있어야 한다.
◦
어제보다 더 나아지고자 하는 미래 지향적 상승 의지가 느껴져야 한다.
