김철수 - 개발자의 글쓰기

 

개발자의 글쓰기. J에게 추천받은 책이다.

나름 재미있게 읽었다. 표지 디자인도 귀엽고, 당연한 내용이지만 사실 일을 하면서 터득할 수밖에 없는 내용을 섬세하게 담았다. 그리고 개발자 뿐만 아니라 개발자와 협업하는 직군들도 읽으면 좋을 것 같다.

개발가이드 작성법 중,

 

거칠게도 공손하게도 쓰지 말자. 세상 어떤 일이든 100% 확신할 수는 없다. 하지만 개발문서는 독자에게 여지를 줘서는 안 된다. 개발자가 독자에게 여지를 10% 주면 독자는 30%, 50%로 부풀린다. 그래서 개발자가 시킨 대로 하지 않고 우물쭈물하거나 엉뚱한 일을 한다. 호의가 계속되면 권리인 줄 알듯이, 개발문서가 너무 공손하면 독자를 가이드할 수 없다.

해당 부분은 엄청 인상 깊은 부분이었다. 왜냐면 나는 비슷한 느낌으로 실수를 한 적이 있기 때문이다.. 개발을 하다보면 공식 가이드 문서를 읽기보단 일단 블로그를 찾고 따라하다가. 어느 순간부터 이 얘기면 대충 할 수 있을 것 같은데? 하면서 이거저거 시도해보다가 갑자기 아무 것도 되지 않아서 다시 처음부터 공식 개발가이드를 읽기 시작한 적이 참 많다... (..)

 

그 외에도 나온,

비즈니스를 이해하는 장애 보고서 쓰기.

 

1. 장애 보고서는 개발자가 원할 때 쓸 수 없다.
2. 장애의 1차 원인은 대부분 다른 원인의 결과이다.
3. 장애 보고를 받는 윗사람은 대부분 개발자가 아니다.
4. 장애를 해결했다고 해서 100% 해결한 것은 아니다.

특히 3번의 '개발자가 아니다'라는 점은 많은 생각을 하게 만들었다...ㅋㅋㅋ

당연하지만, 우리는 협업하는 다른 직무에 대해 '협업적으로 필요한 용어'만 익히고 더 많은 용어를 익힐 생각을 하지 않는다. 특정 회사에서는 이런 용어를 많이 쓰겠지만 다른 회사에서는 다른 용어를 더 많이 쓸 수도 있다. 협업 시에 타 직군과 소통하며 사용하는 용어들을 잘 설명하기 위한 노력을 할 필요가 있다고 느꼈다.

 

또한, 글쓰기를 계획적으로 쓰지 않으면 구구절절하게 내용을 적고 있어서 깔끔하게 쓰기 어렵다는 점이다. 자기소개서를 쓸 때에도 이 비슷한 생각을 한 적이 많아서, 엄청 길게 의식의 흐름대로 글을 적은 후 반절 이상의 분량을 날리고, 순서를 변경하며 글을 썼다. 애초에 글을 잘 쓰는 사람들은 처음부터 목차를 정하고 > 그에 맞는 소제목과, 요약 정리글을 쓰겠지만 그게 어렵다면 그냥 긴 글에서부터 정리하듯이 나눠나가는 것이다.

가볍게 읽기에 좋은 책이었던 것 같다.