어렸을때부터 무언가를 만드는 것들을 좋아했다.
영상을 만들고 싶어 편집을 배웠고, 포스터를 만들고 싶어 포토샵을 배웠다.
VR 프로그램을 만들고 싶어 컴퓨터 관련 학과를 갔다.
만드는 것을 좋아했는지, 만들어 낸 것을 보여준 뒤 잘했다는 칭찬을 듣는게 좋았는지는 모르겠다.
[만든다]는 건 결과만이 아닌 그 과정 또한 포함되는 것이라 생각한다.
과정은 그런 의미에서 또 하나의 작품이다.
고흐의 자화상이 그림만이 아닌 고흐의 인생이 있어 명화이기에
무언가를 만드는 건 곧 이야기를 쓰는 것과 같다.
만들기 위한 과정이 있어야 비로소 [만듦]이 완성되는 것이다.
작품이 [결] 이라면 그 과정이 [기승전] 인거지.
2018년 3월, 1학년 수업의 파이썬으로부터 6년이 지났다.
나는 7년차 개발자라 볼 수 있을까? 7년차는 아니더라도 좋은 개발자일까?
내가 나를 좋은 개발자라 할 수 있을까?
좋은 개발자로 불리려면 어떤 사람이 되야하는가?
개발자는 프로그램을 개발해야 한다.
좋은 개발자는 좋은 프로그램을 짜는 사람이라고 볼 수 도 있지 않나?
좋은 코드는, 좋은 이야기는 뭘까?
결론만 괜찮으면 좋은 이야기인가? 잘 돌기만 하면 좋은 코드인가?
그렇지 않다고 생각한다.
이야기엔 기승전결이 다 있어야 한다. 기승전결이 있어야 이야기를 이해할 수 있다.
독자가 읽기 쉽게 하자. 띄어쓰기가 안 맞다면 읽기가 힘들다. (아버지가 가방에 들어가실수도 있다.)
좋은 이야기를 들어야 좋은 글을 쓸 수 있다.
한번 글을 잘 썼다고 계속 잘 쓸 수 있는가? 검수 또한 필요하다.
기술문서를 작성하고 커밋메세지와 PR 등으로 개발한 과정과 이유, 목적을 기록하자.
다른 개발자가 읽기 쉬운 코드를 쓰자. 컨벤션을 맞추고 명확한 코드를 작성하자.
좋은 코드와 기술문서를 읽자. 왜 좋은지 생각하고 얻어가려 노력하자
한번 만든 프로그램을 회고해보자. 어떤 점이 막혔었는지 어떤점이 좋았는지, 아쉬웠는지에 대한 고찰은 더 좋은 프로그램을 만드는 양식이 된다.
아직 좋은 개발자가 뭔지 잘 모른다.
하지만 좋은 개발자가 되기 위한 요소들이 뭐가 있을까 고민하고, 실천하는 과정이 나를 좋은 개발자로 이끌 것이다.
그러다 보면 어느 순간 좋은 개발자라고 불리는 내가 있지 않을까
