그룹 멘토링과 지인찬쓰 교차검증
본 게시물은 멘토님이 전해주신 객관적 사실만 전달하기 보단
그룹 멘토링 및 다양한 지인찬쓰를 들으며 제가 해석하고 인식한 내용입니다!
1. 그룹 멘토링에서 생각해 볼 것
1) 애매하게 아는것, 명확하게 아는것의 구분
기술 관련 이야기를 하다보면 애매하게 아는것과 명확하게 아는것 모두 이야기를 하게 되는데
애매하게 아는것에 대해 대화를 진입할때 스탠스를 확실히 하여 내가 이 개념을 명확하게 아는지
여부를 상대방이 어느정도 인식 할 수 있게 해줘야겠다는 생각이 들었습니다.
동시에 시니어 개발자의 경우 지금까지 학습한 지식이더라도 이것이 객관적 사실인지 판단.검증하기
가 쉽지 않을텐데 어느정도 수준까지 가야 명확하게 알고 표현 할 수 있는건지에 대한 기준치를 책정
해야 할 지에 대한 의문도 생겨서 아직도 어렵게 느껴지는 부분 입니다.
2) 양날의 검? 꼬리물기 질문
동료평가에서 활용해볼만한 꼬리물기 질문
멘토링에서의 꼬리물기 질문을 통해 우리가 얼마나 연속적인 질문에 대해 취약한지 체감 할 수 있었
습니다, 반대로 만약 내가 디테일하게 잘 알고있는 영역으로 질문을 이끌어 갈 수 있는 능력을 키운
다면 그 또한 무기가 될 수 있다고 느껴져 바로 개선되진 않겠지만 조금이나마 대처방법을 생각 할
수 있는 기회가 되었습니다.
2. 그룹 멘토링 + 지인찬쓰 교차한 생각
1) 클러스터에서 잘하는 카뎃이 현업에서도 잘하는가?
클러스터 내에서 개인과제를 조금 더 잘하는 사람이 있다해도 그 격차는 카뎃이 느끼는것과
멘토님이 느끼는것은 확연히 다른 부분이 있어보였습니다. 카뎃 사이에서 잘한다는 평이 있어도
재능 수준은 비슷한 수준인 경우가 대부분이라 하셨습니다. 이는 42에 오기전 각자의 공부기간이
다르기 때문에 조금 인풋을 많이 투자한 카뎃이 더 더은 성과를 내고 있다고 해석 되었고
여러 지인찬쓰 멘토링을 들으며 든 생각은 개발실력이 정말 뛰어난 개발자도 필요하지만,
현업에서 일을할때 가장 중요한건 커뮤니케이션 능력이라는 것을 직.간접적으로 느끼게 되었습니다.
2) 그렇다면 어떤 개발자가 되어야 하는걸까? (현재 진행 고민중) 있는걸 잘 쓰는 개발자 , 새로운 것 을 만들어내는 개발자
IT 분야는 이미 오픈소스.공개자료 방향으로 발전하는 상황
-있는걸 잘 쓰는 개발자
-있는걸 디테일하게 보는 개발자
-새로운 것 을 만들어내는 개발자 등...
우리는 어떤 개발자를 지향해어야 되어야 하는 것 일까요?
뒤늦게 개발을 시작한 사람이 새로운걸 만들어낼 수 있을까 하는
꼬리에 꼬리를 무는 많은 생각이 현재 진행형 상태로 남아있습니다.
다만 고민하는 과정에서 하나 해결된건 개인과제에 있어 새로운 코드를 만들어내겠다 하는
부담스러운 목표 보다는 수정이나 확장성 용이한 코드를 작성하는쪽을 목표로 삼는것도
충분히 좋은 목표점이 되지 않을까 하는 생각을 가지게 되었습니다.