개발자의 인맥 #2
개발자 생각 #3
개발자는 기억보다 기록이 생명이다.
어김없이 오후가 되니 아무 소리도 내지 않던 메신저에서 알람처럼 소리가 나기 시작한다.
1.
(후배):
OO님, 1을 구현하려고 하는데,
A라는 [방법]을 사용하려다 보니 제대로 되지 않아요
어떤 식으로 구현할지 [ 방법] 있으세요?
<이런 대화를 하며>
원하는 것을 설명한다.
질문할 내용을 구체적인 코드로 설명한다.
(나):
글쎄? 1을 구현하려고 한다면
A [방법]보다는 B [방법]이 일반적이지 않을까?
구글링을 해보아도 레퍼런스가 풍부한 것을 보니
그쪽이 맞을 듯한데?
<이런 대화를 화며>
검색을 한다.
링크를 보낸다.
설명을 한다.
시간이 되면 소스코드를
만들어 실행된 결과를 보내준다.
...
(한참 후)
(후배):
OO님, 아까 보내주신 자료로는 해결이 안 되더라고요
그래서 제가 [검색] 한 결과 C를 가지고 [코딩] 한 후에 [실행] 해보니 되더라고요,
소스코드 공유할게요! 제 블로그나 github에도 올려놓겠습니다.
<이런 대화를 화며>
코딩 및 실행 결과 확인
되면 결과 공유
안되면 다시 검색해서 코딩 및 실행 결과 확인
(나):
어! 고마워, 나도 이번에 공부가 되었네.
원래 이렇지 않았던 것 같은데?
뭐가 바뀌었나 봐?
(후배):
네, 이번에 SDK 업데이트되면서
구글 정책이 바뀌었데요….
어? 그래? 그럼 이것도 공유해야겠군
<앞으로 목표>
해당 내용을 문서화한다.
SNS나 블로그 또는 github에 올린다.
2.
개발자는 기억을 믿지 않는다.
어떤 미션(만들어야 할 기능)을 수행하고 있을 때, 다양한 방법론이 머릿속에서 떠오르고 그로 인해 수많은 참고자료를 인터넷(사실 구글뿐이다)에서 뒤지게 된다. 그리고 참고한 자료를 토대로 “코딩(=논리적 글쓰기)”, “실행(=결과 확인)”을 반복하다 보니 머릿속에 있는 기억과 실제 코딩한 결과가 오류를 발생시키는 경우가 생긴다.
생각할 것이 많고 내용이 복잡하다 보니 하루 전에 자신이 코딩했던 내용조차 “왜 이렇게 만들었어?”라며 당황하는 경우가 종종 발생한다. 즉, 내 머릿속으로만 논리적인 사고를 만든다고 한 들, 원하는 프로그램을 만들 수 없다는 것이다.
그러다 보니 “나(내 생각)를 검증” 할 수 있는 소프트웨어 시스템이 필요하게 된다. 프로그래밍 환경에서는 아주 훌륭한 검증도구(주로 SDK 또는 IDE라고 부른다)를 다양하게 제공하지만 그래도 사람만 한 검증 및 지원 도구는 없다.
좋은 프로그래밍은 누군가 검증하고 오류를 찾아주어야 지속 가능하다.
특히 내 머릿속의 오류를 사람이 잡아주어야 할 경우가 있다.
3.
아는 것은 중요하지 않다. 질문하는 것이 중요하다.
프로그래밍에서 아는 것의 진위는 꾸준히 변한다.
어제의 당연했던 내용 또는 정책이 개발환경의 변화가 생기면서 오늘에는 의미 없는 방법이 되어버리는 경우가 적지 않다. 그래서 개발자는 지금 상황에서 중요한 것이 무엇인지 집중하고 “방법을 찾아 질문”하는 습관이 체화되어 있어야 한다. 그러다 보니 개발자는 집단지성이라 불리는 오픈소스 정신이 일반화되어 있다.
특히,
Stackoverflow
Github
Youtube
Tech 관련 블로그
는 프로그래밍을 한다면 하루에도 수십 번씩 방문하게 되는 없으면 안 될 서비스이다. 저런 서비스가 존재했기에 지금과 같은 광속의 소프트웨어 개발환경이 만들어질 수 있었던 것이다. 저곳에서 셀 수 없는 전 세계 개발자들이 “누군가의 질문”을 주제로 자기들의 노하우나 생각을 공유한다. 엄청난 양의 지식이 존재한다. 그러나 그들의 집단지성이 아무리 강력해도 지인들에게 물어보는 것만큼 빠르지는 않다. 그래서 경력 있는 개발자일수록 능력 있는 동료 개발자들과 끈끈한 네트워크를 유지하려는 경향이 있다.
4.
“동료”는 훌륭한 도구이자 스승이다.
글도 남이 읽지 않는 글은 품질이 떨어지고 오류가 많다. 마찬가지로 “코드를 봐주는(코드 리뷰) 동료”가 없는 개발자는 저품질로 갈 수밖에 없다. 그래서 좋은 회사나 좋은 팀일수록 정기적으로 서로의 “코드 리뷰”를 한다.
마찬가지로 “자영업 개발자”역시 그들만의 네트워크를 이용하여 서로의 코드를 공유하고 의견을 제시한다. 왜 이렇게 만들었는가? 이렇게 만드는 것이 효율적인가? 이렇게 만드는 것이 편한 것인가?라는 질문들을 하면서 자신의 프로그래밍 생산성에 도움 되는 코드들을 따로 모아 라이브러리화 한다.
이렇게 동료가 중요함에도 불구하고 몇몇 개발자들은 엉뚱한 생각을 하는 것을 볼 때가 있다. ”나 혼자 모두! 할 수 있다”라고 말이다 이런 말을 한다면 소통 부재로 인한 저품질의 생산성을 가진 개발자로 여겨질 수밖에 없다. 개발은 혼자 하는 것이 아니다. 같이 하는 것이다. 세상의 모든 창작은 혼자 하면 아마추어 수준을 넘어가지 못한다.
5.
볼 필요 없어요
내가 이걸 해봐서 알아요!
라는 식으로 말하는
개발자에 대한 믿음은 없다.
26년 동안 경험에서는 “해봐서 알아요” 의 유효기간은 길게는 3년을 넘지 않았기 때문이다.
반면에 “해봐야 알겠지만 자료들은 충분할 것 같아요”라고 말하는 개발자에 대한 믿음은 강하다. 개발은 “하다 보면 알게 되는 것이다" 그렇기에 꾸준히 학습하는 자세를 유지 못하는 개발자는 도태될 수밖에 없다.
