1

마음을 가다듬고, 천천히, 꼼꼼하게, 메모하며 읽어야 할 책이다.

2

그리고 “뒤를 돌아보고, 지금을 내려다보고, 앞을 올려다” 보자. 그리고 내 손에 쥐어진 몇 구절과 생각을 읽어보자.

3

지금 그리고 이 순간, 우리는 좀 더 ‘프로페셔널’ 하게 행동하고 생각하는 방법을 알았으니 이제 실천을 해보자.

---

결과는 중요하다. 그런데 과정은 더 중요하다.

[…] “산드로.” 문들 다다랐을 때 그가 나를 불렀다. […] “일을 하는 것도 중요하지만 그에 못지 않게, 일을 어떻게 하느냐도 중요합니다.” 이 말을 끝으로 나무르는 자신의 컴퓨터로 돌아앉아 그 끔찍한 검은 배경에 초록색 글자가 나오는 편집기에 다시 타이핑을 시작했다. […] 일을 끝내는 것 자체로는 부족하다는 것, 그 일을 어떻게 하느냐가 더 중요하다는 것, 특히 팀에서 일할 때는 더욱 그러하다는 것을 배웠다. 나의 동료와 클라이언트를 존중하고, 형편없는 코드를 남겨서는 안 된다는 것을 알았다.

시간의 절대성이 실력을 보증하진 않는다.

‘상대적’ 이라는 이유는 어떤 기술, 어떤 맥락에서, 누구와 비교해야 하는지 알아야만 고참인지 여부를 결정할 수 있기 때문이다. 고참 개발자, 신참 개발자라는 것은 없다. 큰 규모의 기업 시스템용 자바 애플리케이션 개발에 경험이 많더라도 자바 스크립트로 게임을 만드는 데는 생초보일 수 있다. 애자일 방법론을 채택하고 다수와 협력하여 일하는 방법에는 매우 익숙하더라도, 다단계 구조인 관료적/정치적인 조직에서는 신입사원과 별 다를 바 없을 수 있다.

당연한데, 이상하게 어색하다.

[…] 코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 요건이다. […] 도요타가 성공할 수 있었던 중요한 요인은 절차를 개선하는 것뿐만 아니라 자동차의 품질에 이미 충분한 역량과 그를 뒷받침하는 노력이 있었기 때문이다. […] 애자일 절차를 포함해서 모든 소프트웨어 절차들은 기술적 타월함을 기본 배경으로 가정하고 있다. […] 기술적 탁월함의 개선 없이 절차만 개선하는 것은 무의미하다.

일정하게 코드를 작성하는 습관을 들여야 한다.

소프트웨어 프로젝트를 이끄는 상급자들이 소프트웨어로부터 너무 떨어져 있다는 것도 문제다. 기술적 배경이 아예 없거나, 마지막으로 코드를 작성했던 것이 언제였는지 기억이 나지 않을 정도로 실무에서 오래 벗어난 사람일 때가 많다.

기본이 되었다면 절차를 고민하자.

같은 일을 반복하면서 다른 결과를 기대하는 것은 미친 짓이다. - 앨버트 아인슈타인 / 문제는, 유지보수 비용이 높은 기존 애플리케이션을 개발했던 바로 그 잘못된 방법으로 새로운 애플리케이션을 개발하여, 몇 달 또는 몇 년 동안 똑같은 오류를 반복한다는 점이다.

경험의 축적은 코드로 완성된다.

오래 전에 작성했던 코드를 지금에 와서도 고칠 부분이 없어 보인다면, 그것은 그동안 배운 것이 없다는 뜻이다.

회사가 나를 발전시킬 순 없다. 내가 발전해서 회사가 발전할 순 있어도.

소프트웨어 프로페셔널로 대우받기를 원한다면 프로처럼 행동해야 한다. 이는 스스로를 발전시키는 데 자신의 돈과 시간을 들여야 한다는 것이다. 나 자신의 커리어를 주체로서 언제, 무엇을 배울지를 스스로 결정해야 한다. 고객, 고용자를 도와줄 수 있는 위치에 있어야 한다.

기록은 소중한 것이다.

[…] 모든 소프트웨어 개발자는 경험 수준과 관계없이 블로그가 있어야 한다고 본다. 경험과 발견을 공유함으로써 훌륭한 프로페셔널 커뮤니티를 이루는 데 도움이 되어야 한다.

활용해봐야 겠다.

다음의 웹사이트들에서 유익한 코딩 카타들을 다양하게 찾을 수 있다. , codekata.pragprog.com, kate.softwarecraftsmanship.org

‘아니오’가 아니라 ‘대안’이 더 중요하다.

우리는 전혀 프로답지 못했다. 한번도 ‘아니오’라고 말하지 않았기 때문이다. […] 우리가 영웅이 될 수 있다는 망상에 사로잡혀 프로페셔널하게 행동하지 못했다. 우리는 ‘아니오’라고 말할 수 있어야 했다. […] 모든 ‘아니오’에는 반드시 하나 이상의 대안들이 따라와야 한다. ‘아니오’라고 대답하기 전에 문제를 분석해서 대안이 있어야 한다.

품질은 모든것에 앞선다.

첫 번째 일정을 맞추기 위해 코드의 품질을 희생한다면 그 다음번, 그리고 그 이후의 일정을 지키기가 점점 더 어려워질 것이 뻔했다. […] 우리 업계는 이제서야 코드의 품질이 프로젝트의 성공을 보증하지는 못하더라도 실패의 핵심 요인이 될 수 있다는 것을 배우고 있다. […] 어떤 결정을 하든지 간에, 심지어 저품질을 선택해야 하는 경우에서도 항상 품질이 좋기를 희망한다.

그리고 관리는 항상 해야 한다.

코드는 기계장치라기보다는 유기물이다. 코드는 정원처럼 지속적인 유지보수가 필요하다. […] 나쁜 코드를 다루어야 하는 기업은 경쟁력이 떨어지게 된다. 새로운 기능을 구현하거나 기능을 변경하는 데 드는 비용이 발목을 잡는다. […] 가장 큰 문제는 나쁜 코드가 개발자 외에 다른 사람드렝게 보이지 않는다는 점이다. 개발자가 아닌 다른 사람이 문제를 인지했을 때는 이미 늦은 상태다. […] 결과적으로 팀 전체적으로 디버깅 시간을 늘리는 것이다. 이렇게 낭비되는 모든 시간들을 생각해보자. 매일, 매주, 매달, 매년. 이 모든 시간 낭비가 개발자들이 단위 테스트를 작성할 ‘시간이 없기(!!)’ 때문에 발생한다.

프로페셔널의 기본은 ‘윈윈’이다.

고객이나 고용주가 자동화 테스트, 애자일 방법론과 같은 것을 언급할 수도 있지만 결국 관심이 있는 사항은 투자한 만큼 이득이 되돌아오느냐다.

울컥했다.

어디로 가고 싶은지 커리어의 방향을 확실할 수 없을 때는 모든 문들을 열어보기 시작해야 한다. 우리에게 기회가 나타날 수 있는 상황들을 만들어 낼 필요가 있다. 다른 세상으로부터 고립되어 집안이나 사무실에만 웅크려있기만 하는데 제발로 찾아와 노크를 하는 기회를 가져다 줄 사람은 없다. […] 밖으로 나가서 교류를 해야 한다. 세상이 나에게 접근할 수 있어야 한다.

인재가 뭔지 모르니, 못 뽑을 수 밖에…

[…] 모든 회사들이 최고의 인재를 원한다고 표방하지만 최고의 인재가 실제로 어떤 의미인지는 잘 모르는 경우가 허다하다. 회사들의 실재 채용 공고를 살펴보면 이러한 문제가 쉽게 드러난다.