어떤 TIL을 써야할까?[TIL 왜 쓰지? 20220902 TIL]

어느덧 블로그의 글이 135개가 넘었다. 올해 2,3월? 쯤 블로그를 시작한 걸 감안하면 매일 썼으니 많이도 썼다. 요즘엔 주제가 생각이 안 나서 오늘 하루를 돌고 돌아봐서 주제를 짜낼 때도 많다.(그게 정말 진정한 회고와 반성의 의미겠지?)

트레이너분께 til에 관해 어떤 글이 좋은 글이냐고 물어보았는데 (단순히는 기술을 명시하고 정의 내린 글이 나은 것인지 내가 나를 되돌아보고 반성하는 일기 같은 형식이 나은 것인지 물어보았다.) 기업 입장에서 기술을 잘한다는 것을 어필하고 싶으면 전자가 나 자신을 위해 쓴다면 후자라고 하셨다. 근데... til을.. 취직을 위해... 쓰나..?(그렇지만 그렇지 않지만 그렇다..?) 그래서 글 쓰는 걸 좀처럼 싫어하지 않는 내가 갑자기 방황하게 되었다.

 

자유야 자유~

어느 것이든 블로그가 반드시 정답은 아니니 자유라고 했는데 내가 티아이엘을 일기 형식을 취하는 이유는 다음과 같다.

 

1. 분명 코스가 끝나도 1년 뒤에도 3년 뒤에도 난 이 글을 다시 본다.

난 일기를 정말 좋아하는데 글로 쓰는 일기는 의외로 많이 담지를 못한다. ( 손으로 글을 쓰면 저어엉말 느리고 아프다.) 생각의 속도를 글이 못 따라가서 엄청 줄어든다. 근데 남에게 보여주는 블로그라 한 번 더 생각하고 내가 배운 점을 여실히 담은 이 글은 분명 내가 두고두고 와서 볼 것 같다. 근데 단순한 코딩의 정보를 담으면.. 볼 것 같지 않다.

 

2. 개발공부에서 배운 것을 인생으로 연자 시키는 글을 쓸 때 더 재미있고 배움이 확장되는 것 같다.

일기 형식을 취하지만 항상 오늘 배운 것 느낀 것을 많이 담으려 하는데 그중 하나는 글의 딱딱함을 없애기 위해서이다. 그래서 어떤 배운 사실이나 정보를 다시 녹여서 내 삶에 대입시키다 보면 비유를 하는 것 같이 재미가 있다.

그리고 사실 프로그래밍을 하며 순서대로 생각하는 능력, 문제가 생기면 하나하나씩 요인(디버깅 포인트)의 가설을 세우고 찾아가 검사하고 다시 해결하는 것, 일의 단위가 클수록 작게 나누어 검사해서 큰 것을 만들어 내는 것. 좋은 코드를 위해서 프로그램이 잘 돌아가는 것에 그치지 않고 다른 사람도 이해가 쉽고 읽기 쉽도록 가독성을 높이도록 코드를 짜고 변수를 짓는 것 등등 이 모든 것이 삶에 적용해볼 수 도 있고 그것이 실제로 되면 너무 즐겁다.

 

고민 말고 손을 먼저 움직이고 내 방식을 찾아가자.

또 공부를 하며 배운건 어떤 복잡한 선택의 순간이 오면 일단 몸을 움직이기로 했다. 블로그의 방향에 대해서니 일단 글을 쓰기로 했다. 그리고 주제는 그 고민 그 자체를 담기로 했다. 쓰다 보니 조금 진정된다. 사실 티아이엘도 누군가가 시작해 유행처럼 번진 것으로 알고 있다. 남과 똑같이 해서 특별할게 무엇이겠는가. 나는 어떻게 배운 것이든 나만의 글로 소화시키고 읽는 누군가에게 영감을 조금이라도 준다면 ( 그게 나 스스로 한 명인 것으로도 충분하다.) 만족한다. 그리고 기억보다는 기록을 이라는 말도 있듯이. 나만의 위한 1인 기록이라는 점에서도 충분하다. 

 

좋은 글이라면 그것으로도 충분하다.

반드시 기술의 설명과 정의를 나열해두지 않더라도 그 글 자체가 어떠한 가치를 지닌다면 충분하다고 생각한다. 나의 글이 글 이라는 주제 자체로 괜찮고 나를 잘 드러낸다면 나는 이것을 가지고 열심히 알리고 보여주고 함으로써라도 알릴 수 있을 것이다. 글을 썼다고 끝이 아니다. 내가 좋은 글을 썼다고 생각한다면 사람들이 봐줄 것이고 봐주지 않는다고 생각하면 이 글을 들고 내가 이런 사람입니다. 내가 어떻게 사고하고 배우는지를 잔뜩 담았어요라고 보여주면 된다. 내 캐릭터를 알아주는 그 한 명 누군가와라도 일을 시작하게 되고 소통하게 된다면 그것 또한 또 다른 시작이지 않을까.

 

결론

방식보다는 가치(본질)를 담자.
가치가 있다면 어떻게 이것을 알릴지만 고민하면 된다.
가치가 없다면 다시 써야한다.

 

오늘은 복잡한 문제를 단위별로 잘게 쪼개고 메소드화 시켜서 어려웠지만 문제점 포인트들을 하나하나 디버깅해나가며 풀 수 있었다.

또한 예전과는 달리 복잡해도 머리에 무언가 떠오르면 일단 코드로 실행시켜보았다.(그게 temporary green 일지라도)

하지만 테스트 케이스 한 두 개가 걸려 시간을 많이 먹었는데 다음에는 충분하지 못한 테스트 케이스와 애매하게 짜둔 로직이면  todo로 표시해두면 좋을 것 같다. 표시를 안 하니 어디서부터 디버깅할지 몰라서 본능적으로 몸이 거부를 하더라.