① 더 영리하게 일하기 [코딩호러가 들려주는 진짜 소프트웨어 개발이야기]

1부 더 영리하게 일하기

예전에 <코딩호러의 이펙티브 프로그래밍>을 읽으면서 느꼈지만 제프 앳우드의 블로그 퀄리티는 일주일에 3개에서 5개의 글의 올렸다던 그의 말에 따르면 정말 대단하다. 이 책 역시 그의 블로그 연재 글을 묶어 낸 책인데 개발과 관련해 효율적으로 일을 하는 법, 프로그래머가 되기 위한 테크트리, 개발 분야중 특별히 웹 디자인에 대한 이야기 그리고 사용자에 대한 이야기 등등을 다루고 있다.

아래는 책을 읽으며 받은 인사이트들을 모으면서 글을 정리하려 하는데 인사이트가 너무나도 많아서 2부로 내용을 나누었다. 책의 내용을 너무 많이 가져온 것이 아닌가 싶기도 했다. 솔직히 말해서는 소프트웨어 엔지니어라면 꼭, 아니더라도 엔지니어와 함께 일하는 사람들에게도 이 책을 읽어볼 것을 권하고 싶다.

쓸데 없는 일 줄이기

스케줄에 느슨한 부분이 없는 밤샘작업 환경을 개선하려면 톰 데마르코의 책 <슬랙>을 참고할 것.

아주 많은 실패 없이는 혁신이나 진정한 실험이 불가능하다.

자기가 보기에 개선되어야 하는 그럴듯한 아이디어가 있으면 그것이 어떤것이든 실제로 실험해 보는게 단순히 묵과되는 것이 아니라 오히려 장려되기 시작하면 그것은 일을 일처럼 느끼지 않게 만드는데 큰 도움이 된다.

위세이브는 배후에 놓인 아이디어에 대한 관심과 열정을 보고 직원을 채용한다. 일단 채용한 이후에는 그들을 느슨하게 방임한채 지속적으로 대화를 나눈다. 이것이 우리가 일하는 방식이다. 그리고 믿거나 말거나 이러한 방식은 아주 효과가 있다.

다른 사람들에게 영향을 미치기를 조금이라도 원한다면 그들을 설득할 수 있어야 한다는 진실 말이다.

설득을 얻는 유형

• 그의 아이디어가 전체적으로 봤을 때 상당히 괜찮다.

• 그는 위에서 아래로가 아니라 아래서 위로 가는 방식으로 일했다.

• 그는 다른 사람들에게 권고하기 전에 자기자신의 생각에 본을 보이는 방식으로 주변 사람들의 신뢰를 얻었다.

• 그는 바퀴가 굴러가기 시작할 때까지 참을성 있게 기다렸다.

정말 설득력을 갖추기 위해서는 더 크고 웅장하고 영감을 자극하는 이야기를 말할 수 있어야 한다.

"나는 해마다 '버밍엄 감옥으로부터의 편지'를 다시 읽는다. 그것이 가장 설득력 있는 에세이라고 생각하기 때문이다." 그것이 왜 효과가 있는가? 어떤 데이터를 인용하는가? 어떤 기법이 그 에세이를 그토록 강하게 만들어주는가?

설득에 관한 글에서 많은 말들이 와 닿았다. 그는 '침묵을 지키거나, 빈둥거리며 서 있거나, 혹은 얼굴도 없고 목소리도 없는 군중속에 파묻히는 방법들을 써서 무언가 훌륭한 것을 성취한 사람은 없다' 며 자신의 일과 삶에서 효과적인 변화를 원한다면 다른 사람을 어떻게 설득하는지 배워야 한다고 말했다. 이것은 회사를 운영하는 대표나 자신의 프로젝트를 마케팅 해야하는 (즉, 설득해야 하는) 소프트웨어 엔지니어나 사실은 어느 누구에게도 필요한 말이긴 하다.

전문가는 다른 사람들에게 자기가 아는 것을 말하는 것이 아니다. 그것은 바로 어떤 질문을 할지 아는 것, 자신의 지식을 주어진 특정한 상황에서 어떻게 적용할지 아는 것을 의미한다. 전문가가 된다는 것은 합리적이고 상황에 매우 적절한 방향을 제시할 수 있음을 의미한다.

프로젝트 관리자에게 추천하는 책, 요한나 로스맨 <실천가를 위한 실용주의 프로젝트 관리: 위대한 관리의 비밀>

…이 소프트웨어 개발자는 자기가 해야 하는 일의 전체 목록을 가지고 있지 않다. 즉, 당당하게 99퍼센트 일이 완성됐다고 주장하고 있기는 하지만 앞으로 남은 일에 얼마나 더 시간을 쏟아부어야 하는지 전혀 모른다.

90퍼센트 완료에서 더 나아가지 못하는 상황을 피하기 위한 조치

• 각 항목이 얼마나 오래 걸리는지 보기. 하루 이상의 태스크는 작게 나눈다.

• 업무 진행상태를 시각적으로 보여주는 방법을 찾을 것.

• 업무 진척을 그래프나 목록으로 관리할 것

목록 없이 스케줄을 세우는 것은 중력의 법칙을 거스르는 것과 같다. 해야할 일의 전체 목록을 보여줄 수 없다면 업무의 첫 목록은 그러한 목록을 만드는 일이다.

여기까지는 경험으로도 크게 느꼈던 이야기 이다. 우리 팀도 처음에는 주먹구구식으로 하다 스크럼을 쓰기 시작했고 현재는 아사나, 슬랙, 트렐로 같은 도구를 사용하고 있다. 전체적인 스케줄은 구글 스프레드시트로 관리를 하고 있는데 단순하고 간단하긴하지만 동기화 관점에서 썩 좋은 것은 아니라 전체 업무를 정리할 수 있는 방법을 찾아보고 있다.

하룻밤 사이 성공을 거둔다는 개념은 상당히 왜곡된 생각이며 심지어 위험하기까지 하다. 뭔가 새로운 것을 시작한다면 멀고 긴 여행을 염두에 둬야 한다. 그와 반대로 매우 빠르게 움직여야 한다. 비즈니스 계획은 자신의 경력개발과 다르지 않다. 더 열심히 일하라는 것이 아니라 더 영리하게 일하라는 것이다.

블로그도 마찬가지로 매주 한 두개 정도 알찬 글을 올리는 일을 한 해동안 지속해야 약간의 독자층을 기대할 수 있다. 저자는 3년동안 매주 3개에서 5개정도 글을 끊임없이 작성했다.

프로그래밍

코딩에 대한 열정은 경이로운 일이다. 하지만 이미 자기가 충분한 능력을 가지고 있다는 사실을 여러 차례에 걸쳐 증명한 기술에 대해 계속 아무 생각없이 반사적으로 파고드는 경우가 너무나도 많다. 진정으로 더 나은 프로그래머가 되고 싶다면 프로그래밍 주변에 있는 다른 모든 것들에 열정을 쏟아야 한다.

사용자, 업계 전반, 그리고 비즈니스에 대해 배워야 한다. 더 많은 일에 관심을 가질수록 더 나은 프로그래머가 될 수 있다.

좋은 개발자들은 프로그래밍을 잘한다. 그러니 위의 말은 기본 전제는 프로그래밍에 능숙해야 함을 의미하지만 프로그래밍처럼 다른 분야와 접목할 수 있는 분야는 드물다. (바로 디자인이 생각나긴 하지만) 그러니 어떻게 보면 많은 분야에 관심을 많이 가지는 사람들이 프로그래밍에도 어울릴 수 있다고 생각한다.

확실히 세상의 모든 사람들이 프로그래머인 우리가 그런 것처럼 무의미한 규칙과 무의미한 결론을 통해 희열을 맛보는 사람이 아닌 것은 분명하다. 나는 그 이유를 도대체 납득할 수가 없다.

기술적 숙련도와 관련없이 적당한 품질을 유지하는 방법은 사용법을 잘 따라하는 것이다. 2000년무렵 조엘 스폴스키가 작성한 체크리스트

1. 소스코드 관리 시스템을 사용하는가?

2. 한방에 코드를 빌드할 수 있는가?

3. 매일 빌드하는가?

4. 버그 데이터베이스를 사용하는가?

5. 새로운 코드를 작성하기 전에 버그를 수정하는가?

6. 최신 내용이 반영된 스케줄을 가지고 있는가?

7. 요구사항 명세를 가지고 있는가?

8. 프로그래머들은 조용한 작업환경에서 일하는가?

9. 돈 주고 살 수 잇는 것 중 가장 좋은 도구를 사용하는가?

10. 테스터들이 따로 있는가?

11. 인터뷰를 수행하는 후보자들이 인터뷰 도중에 코드를 작성하는가?

12. 무작위 사용성 테스트를 수행하는가?

중복된 코드가 눈에 띌 때마다 그것을 위험신호로 보면 된다. 복잡성은 비용을 수반한다. 비용을 한 번 이상 지불하지 말자.

각각의 변수, 코드 한 줄, 함수, 클래스, 프로젝트는 오직 하나의 일만 수행해야 한다. 그렇지만 안타깝게도 우리는 그 하나가 무엇인지를 마지막 순간에 이르기까지 알지 못하는 경우가 대부분이다.

여기까지의 인사이트는 현재 프로젝트를 잘 운영하고 있는지 한 번씩 되돌아보게 해주는 말들이었다. 2부에서는 좋은 프로그래머가 되기위한 여러 구루의 조언과 웹 디자인 및 사용자에 대한 내용을 정리하려고 한다.