레벨 2가 마무리되었다. 유후!
쓸 얘기가 너무나 많지만, 생각의 전환이 있던 세부분에 대해서만 적어보려고한다!
가장 좋은 코드를 짜는 것을 목표로 하지 않았다.
대신, 작성한 코드 한줄 한줄에 충분한 이유를 댈 수 있기
를 목표로 했다.
요구사항은 계속 변화하고 그에따라 적절한 코드도 변한다.
이런 상황에서는 기존의 코드를 새로운 요구사항과 관점에 대고 계속해서 비추어봐야할 것이다.
그렇다면, 기존의 코드를 작성한 이유가 명확해야 이러한 판단이 쉬울 것이다!
이 때, 이유와 맥락이 일관되어야 설득력이 더 있기때문에,
내가 선호하는 기준과 가치가 무엇인지 점차 알아가고 일관되게 적용하는 것이 좋겠다.
(추가로 협업을 할 때 의견 교환을 위해서도 이유를 충분히 갖는 것은 역시 중요해보인다.)
레벨2를 진행하며 여러 트러블 슈팅을 겪었다.
이 때, 완벽히 문제를 해결하는 것
을 목표로 하지 않았다. 나만의 결론을 내리는 것
을 목표로 한다.
그리고 이 경험을 직관을 발전시키는 기회로 삼는다.
이유가 만들어짐
이 때, 한번에 결론 내려고 하지 말자. 상황에 따라 이전에 내린 결정이 달라진다.
대신, 결론을 만들 때, 현재 상황, 2. 선택, 3. 변경에 대한 추측을 코드에 남겨놓는다.
그래야 추후 결정을 바꿔야할 때, 자신에게 피드백을 줄 수 있고,
나중에 비슷한 상황이 발생했을 때 대처할 수 있는 직관을 발전시킬 수 있다.
영속성 컨텍스트와 lazy loading, identity type 등을 학습하면서 계속해서 헷갈리고, 주위에 물어보니까 민망하기도 했었다.
하지만 그때마다 완벽히 다 알겠다고 오버하지 않고 지금 필요한 정도만 학습
하곤했다.
그리고 다음에 더 학습해야하는 상황을 만나면 다시 공부하고, 이렇게 점점 채워지는 느낌
을 느끼며 학습했다.
그리고 이번에 4개의 미션에 대한 WIL을 쭉 순서대로 읽어보면서, 이 방식을 통해 지식이 정교화되었다는 것이 느껴졌다.
예를들어, 미션 3때 영속성 컨텍스트가 어떤 역할을 하는지 아리송하며 여러 질문들을 적어놨는데,
미션 4가 끝날 때 쯤에는 영속성 컨텍스트를 이해하고 그 역할에 따라 osiv를 끌지 말지까지 장, 단점을 고려해 정리해둔 것처럼 말이다.
그러다보니 더이상 불안하지 않았다. 내가 지금 다 이해하지 못하는 것도 괜찮다. 학습은 계속 이어지는 거니까!
기능 구현만 빠르게 하고 pr을 보내는 방식을 레벨2 내내 고수했다.
어떻게 보면 나쁜 코드 단순하고 빠르게 작성해보기
를 했다고 할 수 있다.
하지만 이 방식의 확실한 장점을 느꼈다.
- 나쁜 코드를 작성해봐야 무엇이 문제인지 보인다. 어떻게 개선해야할지가 빠르게 보인다.
내가 생각한 개선할점과 주위에서 지적한 개선할점을 비교해보는 것도 도움이 된다.
- 오버하지 않을 수 있다. 필요한 수준의 설계만 도입할 수 있다.
간단한 방법을 두고 복잡한 개념을 도입하는 건 '최선'이 아니라 '차악'이라는 리뷰어의 말에 공감한다.
(가능할 거 같다는 이유 하나로 굳이 어려운 방식을 도입했다가 1년 넘게 온갖 장애처리로 애를 겪을 수 있다는 이야기도 해주셨다.)
‘완벽한 설계를 위해 고민을 너무 오래하지 않고 일단 짜고 고치는 것’이 나에겐 맞다는 걸 발견하게 되었다.
학습해야할 내용이 많다보니 학습의 방향과 깊이 조절 실패가 발생할 수 있었다.
따라서, 이런 질문들을 스스로와 주위에 자주 하며 메타인지를 하고자 했다.
- 현재 주기의 나의 목표가 무엇인지,
- 그 목표에 비춰봤을 때 내가 몰입하고 있는 주제가 적절한지,
- 내가 투자하고 있는 시간이 적절한지
(특히 이번에는 ‘커리큘럼 키워드’가 제공되어 비춰보기 좋았다.)
추후에 팀프로젝트나, 회사에서도 내가 하고 있는 일에서 주기적으로 한발짝 떨어져서 위의 질문들을 할 수 있겠다.
페어하면서 느꼈다.
내가 사용법 찾으려 공식 문서 등을 읽을 때 후루룩 읽고 아 어려운데? 하는 경우가 꽤 있다는 걸.😂
따라서 찬찬히 문서를 읽어보는 학습 방법으로의 보완을 해보고 싶다.
함께 작업할 때 커뮤니케이션의 기본이라고 할 수 있는 부분이다.
페어 프로그래밍을 할 때, 페어의 코드로 진행하는 경우가 생기면서
같은 작업을 하고 있는 사람들인 ‘우리’가 같은 맥락을 공유하고 있는지
가 작업의 여러 측면에 영향을 미쳤다.
충분히 정리하여, 가능한 빠르게, 솔직하게
나의 상태와 맥락을 공유하자!
더 나아가 동료의 상태와 맥락도 먼저 물어보며 공유를 활성화시키는 팀원이 되어보자!
(러쉬와의 페어에서 특히 느꼈다👍)
코드 리뷰나 서로의 코드에 대해 자주 묻는 상황이 발생하다보니
과연 나는 상대방이 심리적으로 받아들이기 쉬운 형태로 의견을 전달하는 동료인가?
하는 고민이 들었다.
나는 자유로운 비판을 통해 근거가 풍부해지는 대화를 추구하는 편이었다.
있는 그대로 의견을 전달하고, 그것을 방어하는 과정에서 근거가 풍부해지고, 돌려 말하는 리소스가 덜 발생하지 않나?라고 생각했다.
하지만, 이것이 상대를 방어적으로 대답하게하는 대화 방식일 수도 있겠다는 생각이 들었다.
리소스가 덜 발생했으니까 결과적으로 좋은거지!라고 생각했으나,
커뮤니케이션이라는 것이 그렇게 정량적으로만 되는 게 아니라는 것이다.
추천받은 책 인간관계론에서도 이에 대한 언급이 나온다.
인간은 자신을 보호하게 되어있고 방어적인 생각이 들면 추후에 긍정적인 태도로 다시 바뀌기 어렵다는 것.
이 점에 있어서, 페어 미션 또는 대화를 하면서 눈에 들어오는 크루들의 자세가 있었다.
바로, 타인의 관점에서 생각하는 자세였다. 타인의 세계를 이해하려는 자세.
그래서 관점을 나에서 타인으로 옮겨보는 연습을 실행해보고 있다.
내 입장에서는 리소스더라도 타인의 세계를 이해해보고, 그 사람의 기분을 생각해보는 연습 같은 것!
순간 순간에 몰입해 자주 인사이트를 얻는다.
진심으로 한다. 몰입을 자주 하다보니 순간마다 깨닫는 점이 항상 생긴다.
회복 탄력성이 좋다.
이건 원래 회복 탄력성이 좋지 않은 것이 단점이었는데 유강스와 여러 실험을 통해 이제는 오히려 장점이 되었다.
분위기를 편하게 만드는 데 자신이 있다.
농담과 실없는 대화가 좋다. 매순간 하고 싶은 대화와 장난이 번뜩 떠오르는 나로서 누구와도 아이스 브레이킹을 하고 대화하는 것에 두려움이 없다.
- 개발이 계속해서 재밌는 개발자
- 기술적인 협업, 인간적인 대화 모두 즐거운 동료로서의 개발자
맞다. 사실 관점이 '나'에 향해 있는 개발자상이다.
아직 사용자를 겨냥한 프로젝트를 해보지 않아서 ‘어떤 서비스를 개발하고 싶은 개발자’의 상은 아직 떠오르는 것이 없다. 이 부분은 레벨 3 프로젝트를 하면서 찾게 될 것이 기대된다!
우테코같은 환경에서 평생 일하면 평생 즐겁겠다는 생각을 했다.
여기서 우테코 환경의 어떤 점이 나를 즐겁게하는지를 통해 일하고 싶은 회사상을 알게되었다.
- 동료와의 대화를 통해 성장할 수 있는 환경
주위 크루들과 코드에 대해서 이야기하다보면 내 근거와 세상이 더 넓어지는 감각이 매일 든다.
이 감각이 너무 좋다.
- 인간적인 호감을 가지는 사람들과 함께하는 환경
인간적인 호감이 있는 사람들과는 코드에 대한 얘기든 프로젝트든 즐겁다.
우테코가 그렇다. 매일 가는 게 기대되고 설렌다.
쓰고보니 레벨 3가 너무 기대된다. 와라 레벨3!!
정말 구체적으로 커비만의 학습방식을 써내려간 것을 보면, 레벨2 목표를 성공적으로 달성했다고 볼 수 있겠네요. 같은 크루로 생활하면서 커비가 새로운 도전을 많이한 것을 느꼈던 것 같습니다. 새로운 도전을 과감히 하는 것도 커비의 장점이에요. ‘러쉬와의 페어에서 특히 느꼈다’ 굉장히 뿌듯한 문장이네요ㅋㅋ 저도 페어하면서 많이 배웠습니다. 레벨3도 화이팅💪🏼