읽게 된 계기
나에게 책을 읽는 것을 추천한 책에서 말하는 한 '장인'은 책을 읽는 것을 추천하는 여러 이유 중 하나로
이미 많은 경험을 쌓은 개발자의 이야기를 통해 내가 겪을 시행착오를 줄이고, 보다 넓은 시야를 가질 수 있다고 하였다.
나도 시행착오를 줄이고 보다 넓은 시야를 가지고, 무엇보다 책의 제목에서 말하고 있는 '소프트웨어 장인'이 되고 싶었기에 이 책을 읽게 되었다.
구체적인 이유도 있는데, '면접'에 대한 것이다.
면접자로써도 분명 필요하겠지만, 내가 참여하고 있는 커뮤니티의 운영진으로써 면접관으로 들어갈 일이 얼마 남지 않았다.
커뮤니티가 필요로 하는 지원자를 효과적으로 찾고 싶고, 보다 좋은 면접 경험을 만들고 싶다.
책의 목차 중 면접에 관한 것이 존재해 기존 우선순위보다 높혀 읽게 되었다.
읽은 후 느낀 점
결론부터 이야기하자면, 나는 이 책을 매우 추천한다.
책에서 이야기하는 많은 사례들을 통해 내가 원했던 간접 경험들과 넓은 시야를 가질 수 있었던 것은 물론
'소프트웨어 장인정신', 즉 프로페셔널리즘에 대해서 생각할 수 있게 되었고 많이 배울 수 있었다.
책을 읽기 전에는 고려하지 못했을 것들을 고려할 수 있게 되었다.
개발자라는 직업을 대하는 태도부터, 면접관 그리고 면접자로서의 태도 무엇보다 평소의 나를 꼬집는듯한 이야기들은 나를 많은 방향으로 성장시켰음을 의심치 않는다.
책을 읽고 꼬집히는 부분이 많은 만큼
지금까지 내가 가지고 있던 생각과 열정이 다른 사람에 의해 먼저 정의되고, 통념되고 있었다는 것을 알게 되었다.
이를 통해 나의 것들을 조금 더 포장해서 말할 수 있는 것은 물론, 추가적인 가치들을 얹을 수 있게 되었다.
위에서 이야기했듯이 나는 이 책을 매우 추천한다.
하지만 이제 막 개발을 시작한 도제(수습생)들에게는 추천하진 않는다.
책에서 이야기하는 개념들에 공감이 되기 힘들다고 생각하기 때문인데, 그에 반해 경험이 쌓인 개발자라면 꼭 한 번 읽어보았으면 좋겠다고 생각한다.
나에게도 더 많은 경험을 쌓은 후 다시 읽어보면 또 다르게 배울 점이 많을 것이라 생각되는 책이다.
책을 읽는 도중에 남긴 이야기는 다음 링크에서 확인할 수 있다.
밑줄 친 문장들
- 일을 하는 것도 중요하지만 그에 못지 않게, 일을 어떻게 하느냐도 중요합니다 (p.11)
- 매일 코드를 작성하는 일은 행복이었다. 그때 이후로, 아침에 눈을 뜰 때마다 오늘 할 일이 하고 싶어 기대되는 일만 하기로 스스로와 약속했다. (p.31)
- 코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 요건이다. 그에 더해 오늘날에는 테스트, 분석, 비즈니스에 대한 이해, 커뮤니케이션 능력, 보다 외향적인 성격을 소프트웨어 프로페셔널에게 요구한다. (p.41)
- 소프트웨어 장인정신은 소프트웨어 개발의 프로페셔널리즘에 대한 것이다. (p.58)
- 애플리케이션이 진화하려면 개발자들이 애플리케이션을 수정하는 일을 부담스러워해서는 안 된다. 테스트 주도 개발, 단순한 디자인, 비즈니스 용어로 표현된 코드는, 코드를 건강하고 잘 만들어진 상태로 유지하는 최선의 방법이다. (p.69)
- 소프트웨어 장인정신의 중심에는 멘토링과 공유가 있다. 소프트웨어 장인은 항상 열정적으로 자기발전을 추구한다. 이보다 더 큰 임무가 있다. 다음 세대의 장인을 준비시킬 책임이 있다. (p.71)
- 오래 전에 작성했던 코드를 지금에 와서도 고칠 부분이 없어 보인다면, 그것은 그동안 배운 것이 없다는 뜻이다. (p.77)
- 상사에게 대항할 수 없다는 불편함과 전체 상황 자체에 대한 증오 말고도 그렇게 무책임하게 밀고 나간 또 다른 원인이 우리 마음 속에 있었다. 마음 깊은 곳에서는 스스로가 얼마나 잘났는지 내보이고 싶었던 것이다. 그 일을 제대로 해내는 것이 어렵다는 것을 알았지만, 영웅이 될 수 있을 거라는 작은 가능성에 매달렸다. (p.113)
- 정직하지 못하고 불투명하면 회사 전체에 피해를 입힐 수 있다. 프로페셔널리즘은 나 자신과 팀 동료들 그리고 관리자들과 고객들에게 정직함을 의미한다. (중략) 다툼을 피하지 말고 부딪혀서 어려운 결정을 내릴 수 있어야 한다. (p.116)
- 문제를 숨기지 않고 드러내는 태도는 모두가 하나의 팀으로서 공동의 목표를 위해 일하고 있다는 징표이기 때문이다. (p.122)
- 실행 관례의 도입 자체를 관리자나 팀 구성원들에게 설득하려 하지 말고 현재 일하는 방식과 비교해서 그것이 가져올 이익에 집중을 해야 한다. 빠른 피드백 루프, 요구사항과 비용에 대한 더 나은 이해, 지식 공유, 줄어드는 버그, 전체적으로 자동화되고 릴리즈가 빨라지는 일들이 기술적 실행 관례를 도입함으로써 얻을 수 있는 가치들이다. (p.153)
- 항상 우리가 무엇을 하고 있고 그것을 왜 하고 있는지 질문해야 한다. 지금 하는 방법보다 더 나은 다른 방법이 없는가? 우리가 선택한 실행 관례가 우리 프로젝트에 적합한가? 그 실행 관례의 가치는 무엇인가? 무언가 다른 것을 시도해 볼 시점인가? (p.162)
- 어디로 가고 있는지 모르고 있다면, 결국 가고 싶지 않은 곳으로 간다. (p.168)
- (인재 채용 중) 지속적으로 배우고 혁신하고 효율적인 실행 관례를 도입하고, 프로젝트의 성과와 코드의 품질에 주의를 기울이고, 문제를 풀기 위해 스스로 협력하고, 무엇이든 더 나은 방법을 추구한다면 ... (p.178)
- 나는 항상 새로운 것을 시도하고, 배우고, 지식을 공유하고, 커뮤니티 활동에 적극적인 사람을 원했다. (p.194)
- 사람들에게 새로운 절차나 새로운 실행 관례를 강제한다고 조직을 변화시킬 수 없으며 우리는 배움의 문화를 만들어 내야 한다. 사람들 스스로 모든 것을 더 나아지게 하고 싶어하는 동기를 부여할 수 있어야 한다. (p.244)
- 잘 작성된 코드는 단순하고, 작고, 테스트 가능하며 이해하기 쉽다. 그리고 가장 중요한 부분으로 코드가 해야 할 일을 해낸다. 코드는 버그와 고통의 근원이다. 더 적게 작성할수록 더 좋다. (p.301)
- 실용주의가 없는 장인정신은 장인정신이 아니다. 장인이 가장 중요하게 초점을 맞추는 것은 고객의 만족이다. 품질은 물론이고 시간과 비용도 고객 만족을 위한 구성요소다. 고객에게 가치를 전달할 수 없다면 잘 작성된 코드라고 할 수 없다. (p.306)
