부록을 읽으면서 이런 생각을 했다. 저자는 왜 굳이 하나뿐인 부록에 'A'라는 이름을 붙여, 마치 여러 부록이 있을 것처럼 기대하게 만들었을까? B, C 등 부록을 더욱 풍부하게 구성하려 했지만 여러 가지 이유나 개인적인 사정으로 결국 부록 A만 작성할 수밖에 없었던 걸까?개인적으로 이런 궁금증이 생기다보니, 내 마음대로 던진 질문에 다양한 추측과 상상을 토대로 답을 해봤다. 부록이라는 것은 내용을 보완하거나 추가 설명을 하기 위한 것이다. TDD를 떠올려보면, 군더더기를 작성하지 않으려 한다. 그런 관점에서 저자도 처음에는 여러 부록을 작성하려고 했지만, 시간이 지나 생각하다보니 부록 자체를 군더더기라고 생각하고 계획했던 부록들을 모두 삭제하려 했을지도 모르겠다. 하지만 이대로라면 소프트웨어 장인정신에..
소프트웨어 장인을 '열정'이라는 한 단어로 요약한 점이 흥미로웠다. 처음에는 마음가짐, 이어서는 삶의 철학, 마지막에는 이데올로기라는 표현으로 점점 의미를 확장하는 과정도 재미있었다. 그리고 결국 그 모든 방향이 열정으로 수렴된다는 느낌을 받았다.책 중간에 '복잡한 코드일수록 뛰어난 개발자'라는 레거시한 분위기에 대한 언급도 기억에 남았다. 과거의 나를 돌아보면, 일부러 복잡하게 만들려고 노력한 적은 없지만, 단순함을 의도적으로 추구한 적도 거의 없었던 것 같다. 지금 생각해보면 단순함은 오히려 더 깊은 고민과 많은 노력이 필요한 결과물이었고, 그래서 진짜 실력을 보여주는 지표라는 말에 동의했다.소프트웨어 장인으로서 철학과 이데올로기에 열정을 다해 업계의 수준을 높이는 일은 분명 가치 있는 일이라고 생각..
이 장은 내가 고민해온 실용주의적인 개발 태도를 다시 한 번 돌아보게 하는 내용이었다. 특히 TDD에서 느낀 '군더더기 없음'과 연결되어 마음에 크게 와닿았다. 필요한 것을 필요한 시점에, 필요한 만큼만 하는 태도는 단순해 보이지만 실제로는 쉽지 않다. "목적과 다른 방향으로 정렬된 것은 모두 군더더기다"라는 내 생각처럼, 불필요한 요소를 제거하고 본질에 집중하는 것이야말로 실용주의의 핵심인 것 같다. Spring Framework가 '경량 프레임워크'라고 불린 배경도 같은 맥락이라고 생각한다. 실제로 Spring이 결코 가볍지는 않지만, 당시의 EJB에 비해 불필요한 요소를 덜어낸 '실용적 선택'이 가능했기에 '경량'이라는 말이 붙은 것으로 기억 한다."품질을 희생해야 한다고 말하면서도 결과물의 품질이..
이번 챕터에서 특히 인상 깊었던 부분은 '당신의 학습과 시행착오에 대한 경험은 다른 사람들의 학습 곡선을 단축시키는 데 도움이 될 수 있다.' 는 말이었다. 나 역시 누군가의 한 마디 덕분에 며칠씩 헤맬 문제를 단숨에 해결했던 경험이 있다. 그래서 누군가 가볍게 지나가는 말로 툭 내던지는 말도 가볍게 여기지 않으려고 하는 편이다. 직접 겪지 않았다면 시간과 에너지를 적지 않게 써야 했을 문제를 비교적 저렴한 가격으로 얻는 셈이기 때문이다. 그럼에도 불구하고 가끔은 반대의 입장에 '내가 왜 굳이 먼저 나서야 하지?' 라는 생각이 드는 것도 사실이다. 내가 쌓아온 시간과 노력이 가볍지 않았기 때문이고, 그만큼 쉽게 내어주고 싶지 않다는 마음도 어딘가에 있는 것 같다. 소프트웨어 장인의 마음가짐을 가지려면 아..
이 장은 소프트웨어 장인은 꾸준히 배우고 배움을 전파해나가는 모습을 보인다는 얘기를 하는것 같았다. 기술 수준이나 경력도 중요하겠지만, 멈추지 않고 배우는 태도도 못지않게 중요하다는 것으로 느꼈다. 평소에 혼자 공부하고 정리하는 습관이 있어서인지 이 이야기들이 어렵게 다가오지는 않았다. 혼자서 책이나 강의를 듣고 필요하면 직접 테스트도 해보면서 익혀가는 방식이 내게는 익숙하다. 예전에 몇번 책읽기 모임에 참여한 경험이 있는데, 그 기억 덕분에 이 장에서 말하는 '함께 배우는 문화'에도 공감이 됐다.요즘에 비해 예전에는 배움에 대한 의욕이 훨씬 많았었다. 그래서 주변 사람들에게도 그런 열정을 기대했고, 함께 뭔가를 해보고 싶다는 생각도 자주 했던 것 같다. 하지만 마음과 다르게 반응이 없거나 흐지부지되는 ..
이번 챕터는 양이 많은건 아니었지만, 묘하게 깊은 인상을 남겼다. 최근에도 그렇고 한번씩 내가 느끼는 감정들과 겹쳐서 그랬는지도 모르겠다. 누군가에게 긍정적인 영향을 주겠다는 욕심이 있는것도 아니고, 대단한 사람으로 내비치길 바라지도 않는다. 천천히라도 같이 흘러가야한다는 마음가짐으로 함께하면 좋겠다는 생각을 가지고 있었는데, 가끔은 그저 불필요한 짐처럼 여겨지는 순간들이 있다. 겉으로 드러나지 않더라도 그런 느낌은 묘하게 사람의 동기를 갉아먹는다. 이번 장을 읽으며 내가 느낀 이 감정들이 결코 개인적인 일만은 아니며, 팀이나 조직 전체에 얼마든지 번져나갈 수 있는 요소라는 생각이 들었다. 본문에 나온 실패 사례는 규모도 크고 경제적인 손실도 컸지만, 본질은 다르지 않다고 생각했다. 나 역시 몇 번의 실..
책에서 말하는 잘못된 면접 방식들을 읽으면서 과거의 경험들이 생각났다. 손코딩, 전화면접, 알고리즘 문제 풀이 같은 방식들 말이다. 당시에는 '이게 진짜 실력을 보여줄 수 있는 방식인가?' 하고 의문을 품기도 했다. 왜냐하면 실무에서는 그렇게 일을 하지 않기 때문이다. 하지만 워낙 그런 방식이 업계에서 당연하게 여겨지다 보니 그것을 이상하다고 생각하지 못하고 당연히 그래야 하는 것으로 받아들였다. 지금 생각해보면 그건 면접을 '시험'처럼 여기는 문화 때문이기도 하겠지만, 면접자가 을의 입장에서 '평가 대상'으로 여겨지는 구조에서 비롯된 것 같다. 여전히 많은 면접은 일종의 권력 구조 안에서 이루어진다. 갑과 을이라는 보이지 않는 프레임 속에서 지원자는 설명하고 증명해야 하는 입장이고, 기업은 판단하고 결..
면접이 기업 입장에서 일방적으로 지원자를 평가하는 자리가 아니라, 지원자도 기업을 평가하고 알아가는 시간이라는 말에 공감했다. 처음에는 그렇게 생각하지 못했지만 몇년 전부터는 그런 생각을 가지기 위해 노력 중이다. 하지만 실제 면접 상황에서는 그렇게 행동하기가 정말 쉽지 않다. 왜 그런지 잠깐 생각해봤는데, 보통 지원을 한다는 것 자체가 이미 그 기업에 들어가고 싶은 마음이 있다는 뜻이고, 그 마음이 무의식적으로 '을'의 자세를 만들도록 프레임을 씌우는 것 같다. 반대로 기업 입장에서는 자신들이 '선택하는 입장'이라는 인식을 가지게 되는데 이것으로부터 자연스럽게 갑과 을의 구도가 만들어지는 것 같다. 물론 겉으로는 그런 분위기를 감추려 애쓰지만 면접이라는 구조 자체가 가진 비대칭적인 힘의 관계는 여전히 ..
개발자가 한 회사에서 오랫동안 같은 기술만 다루며 일하게 되는 상황에 대해 공감 했다. 회사에서 맡은 업무는 보통 시간이 지나면 익숙해지고, 반복적인 일처럼 느껴지기 쉽다. 처음에는 배우는 게 많아도 점점 새로운 것이 줄어들고, 일 자체가 루틴해진다. 그만큼 한 회사에서 계속 성장하고 새로운 경험을 쌓는다는 건 쉽지 않은 일이다. 그래서 자연스럽게 이직이라는 선택이 등장하는 것 같다. 국내 IT 업계에서도 개발자들의 이직 주기에 대한 조사들이 많이 있다. 예전에 어떤 커리어 플랫폼에서 봤던 기억으로, 개발자들이 평균적으로 이직을 고려하는 시점은 입사 후 약 2.7년 정도라고 했다. 당시에는 급여 외에 다른 생각은 하지 못했는데, 업무의 생소함이 사라지고 새로운 도전이 줄어드는 시점과 겹친다고 볼 수 있다..
소프트웨어 장인으로서 자신의 커리어를 소중히 여기고 돌보라는 말은 맞는 말이다. 하지만 실제로 그렇게 살기란 쉽지 않다. 나도 번아웃이 왔을 때는 아무것도 손에 잡히지 않고, '이 일을 왜 하고 있는 걸까' 같은 생각만 가득했다. 이런 상황에서도 장인의 마음가짐을 계속 유지할 수 있을까? 번아웃이 온 상태에서도 그런 태도를 가질 수 있을까? 아니면 애초에 그런 장인의 마음가짐이 있었다면 번아웃이 오지 않았을까? 질문만 머릿속에 계속 맴돌고 아직 명확한 답을 찾지 못했다. 특히 번아웃이 왔을 때는 스스로를 돌보고 마음가짐을 챙기기보다, 그저 지금 이 상황에서 벗어나고 싶다는 생각밖에 안 든다. 사실은 그조차도 힘들다. 상황을 바꾸겠다는 생각조차 들지 않을 만큼 무기력한 때도 있다. 그래서 그런 마음을 가지..