OKR 진행 현황
1. 수습 통과하기(Done)
- LMS console: DynamicRule console migration 프로젝트(CRUD 기능 구현): 60%(7/31)→ 80%(8/31)
- LMS console: 내부 엔진 내 날짜 수정 기능 구현(첫 PR approve!)(
프론트 100%& 백 90%)
백엔드 개발자 커리큘럼 달성
- Java/OOP
이것이 자바다 2권 끝내기(15/16) → 사실상 stop..- Spring
스프링 핵심 원리 강의 끝내기 → Done!~~- 블로그 글쓰기
비개발
[동료 피드백 회고]팀원들이 본 3개월 간 내 본모습은?
개발
Introduction
8월을 전반적으로 돌아보니 차아아아암 많이도 놀았다. 20대의 마지막 여름인만큼 후회없이 보내고자 work hard, play hard를 잘 실천했다.
아쉽진 않았지만 9월은 다시 Study hard하는 페이스를 되찾아야겠다고 다짐한다. 다시 공부 텐션 끌어올리자.
이전 달 Try 실천 현황 체크부터 한다.
- 리드님께 현재 개발 진행 상황 보고 후 상담하기(Done)
구조 단순하게 가더라도 빠르게 기능 쳐낼 것인가?- 아니면 현재 구조 계속 공부하면서 지금 속도를 유지할 것인가? → 전혀 느린 게 아니며 장기적으로는 이게 훨씬 빠른 속도를 가져온다는 답변. 아예 맨 처음부터 만드는 거라면 1번이 나을 수 있지만 지금은 기존 코드 기반으로 작업하는 것임! 기존에 왜 이렇게 쓰여졌는지 학습해가면서 해라고 피드백. 조급해하지 말고 지금 속도로 간다.
- 7시간 취침 → (No)
- 지키려고 계속 체크. 근데 실제로 몇 회 달성했는지 횟수를 세지는 않았음. 횟수 셀 필요.
- 아침에 2시간 공부(정 안되면 아침 1시간 / 저녁 1시간으로 쪼개기) → No
- 매일 1일 1커밋을 했으나 정확히 시간 베이스로 측정하지는 못함.
1. Keep
코드 중심으로 개발 아티클 작성하기
저번 동료 피드백에서 들었던 말 중에 주의 깊게 새긴 말이 있다.
코드로 기여하시는 데 더 도움이 되기 위해, 개념, 지식적인 깊이도 중요하지만, 간단한 것이라도 실제 코드를 많이 작성해보는 것도 균형을 맞춰보시는 건 어떨까요?
빠르게 성장하기 위해서는 아웃풋 중심으로 학습해야 한다.
이제까지는 인풋을 때려넣는데 주력했지만 앞으로는 글과 코드 중심으로 공부하는데 더욱 주력할 예정이다.
그런 맥락에서 이번 달에 작성한 개발 아티클인 [Java]SimpleDateFormat을 쓰면 안된다고? (feat.Thread-Safe) 에서는 처음으로 깃허브에 예제 코드까지 같이 준비해서 업로드했다.
피쳐 예제는 마쳤고 테스트 코드만 짜면 되는 다음 아티클 역시 깃헙에 미리 예제 코드를 올려둔 상황.
앞으로도 내 글을 보는 사람들이 보다 쉽고 편하게 해당 내용을 공부하고 이해할 수 있도록 글쓰기 및 코딩에 심혈을 기울여야겠다. 이것과 관련해서는 아래에 하나 얘기해볼 예정.
1일 1커밋 (29/31)
계속해서 꾸준히 작업 중인 1일 1커밋.
이번 달 역시 간단한 수준의 코딩도 종종 있었으나 전반적으로 매일 조금씩이라도 공부의 끈을 놓지 않는데 많은 도움을 주었다.
저번 달보다 훨씬 잘 논 것에 비해 커밋 놓친 횟수가 오히려 적어서 기분은 좋다.
하지만 저번 글에서 말했던 것처럼 커밋을 무조건 다 채워야 한다는 강박보다는 꾸준히 공부하는 마인드셋을 유지한다 정도로 적당히 텐션 주는 선에서 쭉 가보련다.
2. Problem
데일리 리포트 작성에 소홀해짐
8월 전반을 휴가, 휴식으로 보낸 건 오케이. 하지만 그 외 일하는 시간에까지 영향을 주는 건 좋지 않았다.
이건 의지가 박약해서 문제가 아니라 박약한 의지를 어떻게 해결할 것인지에 대한 환경설정의 부재가 문제였다.
지금은 데일리 리포트를 작성하는 패턴이 순전히 개인의 의지에만 기대는 구조이기 때문이다.
아, 데일리 리포트 써야겠다! 라고 계속 떠올리게끔 하는 건 개인 에너지 관리 측면에서도 좋지 않다. 이 시간 관리를 위임할 수 있는 환경이 필요하다. 뽀모도로 타이머를 하나 구입하는 것으로 해결해보자.
블로그 글 작성 횟수가 현저히 내려감
블로그 글을 거의 쓰지 않았다. 8월 달에는 총 4개의 아티클을 발행했는데 그 중 개발 관련 글은 한 개 뿐이다. 8월은 노는 달이라고 규정했기에 오케이!했지만 그렇다고 가만히 있을 수는 없다. 9월은 다시 원래 텐션을 유지해본다. 달에 발행하는 글 수가 기본으로 두 자릿수는 채웠기에 이번 9월도 10개 이상 글 쓰기에 도전한다. 글감은 하도 많아서 문제일 정도이니 글을 쓰는 데 집중하도록 하자.
글을 너무 지엽적으로 작성한다(Ex. Only 트러블 슈팅만 쓸 거야?)
회고글을 쓰는 오늘, 이전부터 SNS를 통해 알고 지냈던 기획자 분께서 나와 비슷한 시기에 개발자로 전향해 토스에 입사했다는 소식을 들었다.
축하하는 한편, 어떻게 준비하셨는지 궁금해 피드를 다보가 개발 블로그를 하시는 걸 발견했다. 오잉?하고서 들어가봤는데 정말 대단하다는 말밖에 안 나올 정도로 글을 잘 쓰셨다.
댓글에서 출간 제의를 받을 정도로 반응까지 좋았다. 원래 콘텐츠를 제작하는 분이신데다 글을 엄청 잘 쓰시긴 했는데 개발 관련 아티클에서도 그 빛이 드러나니 멋졌다. 솔직히 부러웠다. 일목요연하면서도 탄탄한 구성과 적절한 비유로 많은 주목을 이끌었더라.
그걸 보고 다시 내 글을 봤다. 글쓰기에 나름 자부심이 있었지만 프로를 지냈던 사람과 아마추어의 차이는 어쩔 수 없었나보다. 갑자기 글 하나하나가 초라해보였다. 하지만 다시 생각해보니 오히려 그분 글 덕분에 어떻게 보완하면 좀 더 사람들에게 좋은 영감을 줄 수 있을지 고민할 수 있었다.
가장 크게 느꼈던 차이는
- 비유 및 유려한 문장 표현으로 쉽게 이해하도록 돕고
- 가독성을 위해 문단을 잘게 쪼갰으며
- 글의 구성을 잘 짰다는데 있다.
여기서 또 재밌던 포인트는 그분 블로그에서 반응이 좋은 글은 트러블 슈팅보다는 개념을 설명하는 류의 글이 더 많았다는 점이다. 확실히 트러블 슈팅 해결기는 독자가 해당 문제를 겪은 사람에 한정되기 때문에 보다 널리 읽히기에는 어려움이 있다. 개발 내에서도 특정 직군에 한정된 내용이 아닌 모두가 공감 가능한 CS 지식을 쉽게 쓴 글이 대표적이다.
반응 좋은 글을 작성하는게 목적은 아니지만 영감을 주는 글을 쓰는 개발자가 되는 것이 방향성이기에, 더 많은 사람들에게 좋은 영감을 주기 위해서는 글의 주제를 다양하게 가져갈 필요가 있다. 요즘 쓰는 글은 죄다 트러블 슈팅 작업기이기에 이 부분은 좀 더 신경쓰면 좋은 글을 쓸 수 있겠다.
3. Try
- 뽀모도로 타이머 구매 → 7월 Try item(2시간 공부 & 데일리 리포트) 측정 시도
- 9월 블로그 글 10회 이상 작성(개발 아티클 7회 이상)
- 개발 아티클 중 개념 관련 글 4회 작성
- 프로그래머의 뇌: 외재적 부하 vs. 내재적 부하
- Checked vs. Unchecked Exception
- 로그 관리의 중요성
- 도커 뽀개기