코드스테이츠 SEB 1일차 리뷰 - 오리엔테이션 ~ Learn how to learn
지난 주에 코드스테이츠의 소프트웨어 엔지니어링 부트캠프에 지원했었는데 오늘 드디어 1일차 오리엔테이션을 수강했다.
오리엔테이션을 하면서 구글 캘린더로 계획된 일정들이 공유되었다.
(생각보다 일정이 빽빽하게 되어있어서 처음에 좀 당황했다 ;;)
오리엔테이션 종료 후에는 각자 자율로 정해진 학습일정을 지정된 학습플랫폼을 통해서 소화하면 된다.
1. 학습 툴 설정
오리엔테이션 중에도 학습 툴 설정관련 내용으로 시간이 좀 소요되었는데
그냥 단순하게 크롬 브라우저를 제외하고 주로 사용되는 학습 툴은 구글캘린더, 노션, 디스코드, 줌 그리고 깃허브였다.
사실 깃허브를 제외하고는 이미 주구장창 써본 경험이 있어서 나는 사전에 어느 정도의 셋팅을 마친 상황이었다.(oh....)
(경험상 당일 날 툴 설정하는데 에러 뜨고 하면 머리에서 에러난다. 그래서 미리 했다)
2. 페어 프로그래밍
위의 캘린더를 볼 때 pair / ~ 라고 표시된 스케줄은 2인으로 함께 프로그래밍을 한다고 한다.
어느 직종이나 마찬가지지만 다른 사람과 상호작용이 발생되는 직종에서는 커뮤니케이션이 중요하다.
이러한 부분은 개발자도 마찬가지며 커뮤니케이션 능력 향상을 목적으로 커리큘럼에 반영하였다고 설명해줬다.
처음 이런 구조가 있다고 들을 때, 그냥 서로 작성된 코드 리뷰 정도만 하면 되지 않나 생각했는데
커뮤니케이션 능력이라는 장점을 생각하니 고개를 끄덕였다.
페어로 할 때 역할은 2개로 나뉘어지는데 한 명은 네비게이터, 한 명은 드라이버로 역할을 맡는다.
각 역할에 따른 구체적인 내용은 아래 간략하게 정리해봤다.
- 네비게이터 : 숲을 보는 역할, 문제 해결 위한 전체 방향 제시. 코드 직접 안침
- 드라이버 : 나무를 보는 역할, 네비게이터와 함께 문제 해결 방향 고민, 코드 직접 작성
실제로 들어가게 된다면 줌 등을 통해서 드라이버는 코딩 화면을 띄우고, 네비게이터와 함께 코드 작성을 진행한다고 이해된다.
이러한 내용이 거의 글로 알려주고 있었는데 친절하게도 동영상으로 좋은 페어 프로그래밍 예시와 나쁜 페어 프로그래밍 예시 동영상도 있었다.(나쁜 페어 프로그래밍 예시를 보는데 처음보다가 웃겨서 한번씩 다시 봤다... 그 뭔가 약간 요상한 분위기가 웹드 좋좋소 같은 느낌이었다.)
3. 수도코드(pseudo code)
수도코드란 프로그래밍 언어로 코드를 작성하기 전에, 무엇을 어떤 과정을 통해서 만들지 사람 언어(한국어나 영어)로 먼저 작성하는 것이다.
대부분의 작업을 하기에 앞서서는 그에 맞는 계획을 수립한다.
특히 프로그래밍의 경우에는 목표하는 결과물을 설정하고 생각보다 뭘 써야되는 건지 감은 오는데 막상 코딩을 치려면 막히는 경우가 많다. (맞아 내 이야기다 - 예전에 그 쉽다는 파이썬 공부 해보다가 머리 깨지는 경험을 너무 많이 했다.)
그럴 때마다 사람 언어로 먼저 순서들을 짜보고 그걸 프로그래밍 코드로 옮기는 작업을 많이 해봤다.
코드스테이츠에서는 페어와 코드를 작성할 때 수도 코드부터 작성해보는 것을 권장한단다
4. 학습 전략
단기간 내에 많은 지식을 학습하는 부트캠프의 특성 상 이에 따른 학습 전략도 소개해줬다.
1. TIL (Today I Learned)
이 TIL 학습전략 소개와 더불어 블로깅에 대해서 커리컬륨 상에서 일부 언급해준다.
(그래서 지금 블로그에 글을 정리하는 거다... ㅇㅇ. 블로그 상에 나의 학습 내용을 정리하면서 어떤 발전과정을 밟아왔는지 설명할 수도 있다.)
위 과정을 통해서는 큰 키워드별로 내가 배워야 할것과 배운 것들을 머릿 속에서 정리하는 과정이 이루어진다.
결과적으로 나무를 보지 않고 숲을 보는 학습 과정으로 소개되고 있다.
구체적인 순서는 다음과 같다.
1) 내일 배울 개념에 대해 간략한 리스트업
2) 세부적인 개념 채워넣기
- 리스트업한 키워드에 추가적으로 개념들을 달아넣는다.
3) 체크하기
- 학습을 하면서 내가 이해가 된 TIL 항목을 체크하고 이해되지 않은 개념은 체크 하지 않는다.
4) 다시 읽기 & 검색 & 질문하기
- 앞서 체크가 되지 않은 개념들은 따로 다시 읽기 & 검색 & 질문하기를 거치면서 해결을 진행한다.
5) 넘어가기
- 위의 과정을 다 해도 해결이 안되면 일단 넘어가고 주말에 한다.
2. SQ3R 방법론
: 자신이 읽은 내용을 더 잘 이해하고 기억하도록 돕는 5단계 학습 방법론
- Survey : 목차 훑기
- Question : 질문 정리하기
- Read : 궁금한 점을 찾고 적극적으로 읽기
- Recite : 책을 덮고 최대한 무슨 내용이었는지 생각하거나 적기
- Review : 기억한 것이 맞는지 확인하기
3. 알고리즘 디자인 실력 증진방법
1) 어려운 문제를 풀면, 해법의 통찰만을 유지하고, 새로푼다.
- 우선 40분 ~ 1시간 가량 레퍼런스 코드 없이 문제 풀이
- 충분히 고민 후, 문제풀이가 어려울 시 레퍼런스 코드 확인
- 코드를 모두 지우고 다시 푸는 과정 진행
2) 해법이 내가 희망하는 만큼 명료하고, 직접적일 때까지 반복
- 수도코드를 활용하여 문제 풀이. 레퍼런스 코드를 수도코드화
- 내가 쓴 수도코드와의 차이 비교
3) 비슷한 문제를 공략할 일반적인 룰 발견
위와 같이 일부 학습 전략, 공부법을 소개해줬는데 커리큘럼에서도 자신이 이해하기 편한 방법으로 공부하는 것이 최선이라고 이야기한다.
앞으로 부트캠프 코스 진행하면서 나에게 맞는 적절한 공부법을 찾는 것도 하나의 과제일 것이다.
5. 질문하는 방법 - Agora States
코드 스테이츠에서는 질문하는 것에 있어서 적극적으로 권장한다.
물론 회사나 팀 내에서 누군가에게 질문을 하기 전에는 그 내용들이 검색으로 끝날 내용이면 검색으로 먼저 시작해야한다.
(이런 이야기는 커리큘럼에서도 "검색이 질문의 시작" 이라고 적혀있다.)
예전 마케팅 회사에 일할 때도 어느 신입 사원이 나도 모를만한 걸 가져와서 나한테 물어보면 일단 어이가 없었다.
그럼 일단 함께 구글에 검색하면서 답을 찾아주는데 답을 찾아주고 나면 "다음에는 구글에 먼저 찾아보고 오세요."라고 꼭 말했다.
구글은 정말 훌륭한 선생님이다.
그치만 질문을 할만한 질문인데 스스로 질문을 한다는 것에 부담을 느껴서 질문을 못 하는 경우도 있다.
그러한 경우라면 스스로 질문을 하는 연습을 할 필요성이 있다 생각된다.
(물론 너무 말도 안되는 걸 가져오면 안되지만...)
평소에 질문을 많이 안해본 사람이라면 오히려 일단 질문을 해보고 까이면서 학습하는게 좋을 수도 있다.
이런 유형의 사람도 이전 회사에서 만난 적이 있었는데 그 사람한테는 그냥 일단 질문을 하라고 시켰다.
(그리고 말도 안되는 소릴 하면 다음 질문할 때는 이렇게 하라고 하나하나 알려줌)
내가 생각하기로 질문을 하기 전에 다음과 같은 것을 고려해봐야 한다고 본다.
1) 검색하면 나올만 한가?
- 즉, 이 회사에만 국한되어서 내부에 물어볼만한 내용인가? 아니면 범위가 넓어서 외부(구글 등)에 검색해도 나올만한가?
(간단한 엑셀 함수 같은 걸 구글링 안해보고 나한테 물어보면 일단 한번 째려봐줬다)
- 커리큘럼에도 나오지만 내가 발생시킬 수 있는 질문의 90% 이상은 이미 웹상에서 누군가 물어본 주제다. 대부분은 검색하면 나온다.
2) 내부에 물어봐야 한다면... 그 질문의 핵심만 정리
- 간혹 자기가 이 질문에 대한 요지말고 그 백그라운드가 별 연관성도 없는데 다 이야기 해주는 사람이 있다.
- (대표님이 오전에 저한테 갑자기 미팅 가시기 전에 이걸 시키고 가셨는데 뭔지 모르겠어요...)
- 위 괄호 내용은 정말 최악의 질문이다. 그냥 파일 하나 나한테 보내주고 알려달라고 한다. 재밌는 건 위와 같이 질문하던 사람이 많다.
- 사실 질문받는 사람의 포지션과 그 사람이 이해할 수 있는 범위를 내가 알 수 있다면 거기에 맞춰서 더 핵심적인 부분만 전달할 수 있을 것이다.
물론 부트캠프 커리큘럼에서 위와 같은 내용은 없지만, 내 스스로 체화하고 있는 과정은 위와 같아서 한번 적어봤다.
아고라 스테이츠(Agora States)
코드 스테이츠 내에서 운영하는 질의응답 및 토론 플랫폼이다.
GitHub상에서 운영되고 있는데 질문을 올리면 24시간 내에 답변이 달린다고 한다. (oh....)
하지만 역시 질문하는 방법을 연습하는 연장선인만큼 그 질문을 작성하는 기준이 존재한다.
질문 템플릿에 맞춰 작성은 물론이고 권장되는 가이드도 있는데 가급적 길게 5~6문단이 넘어가게 작성하면 안 된다.
물론 이 과정에서 질문을 작성하면서 퇴고까지 해야되는 경우가 있다.
무슨 질문을 하는데 퇴고까지 하냐라고 할 수 있지만 나는 한 개의 답을 구해내는 것보다 내가 정확하게 원하는 답을 구해내는 그 방법을 학습하는게 더 중요하다고 생각한다.
결국에는 나중에도 실무에서 누군가에게 질문을 하고 서로 간에 답을 구해야하는데 내가 질문을 제대로 못 하는 상태이다 가정해보자.
고통받는 건 질문을 받는 상대방도 그렇겠지만 최종적으로는 나도 답을 구하지 못하기 때문에 고통 받는다.
(예전에 회사에서 질문의 요지를 이해 못해서 답답해하는 답변자와 자신의 질문이 형편 없어서 결국 야근까지 하는 질문자의 모습을 몇 번 봤다)
우선 오늘은 거의 오리엔테이션에 앞으로 이어질 부트캠프 간에 있을 내용들에 대한 가이드 학습이었다.
원래는 블로그를 통해 TIL을 기록하고자 목표했는데 내일부터 본격적인 학습이 시작될 예정이므로 오늘은 그냥 TIL이라기 보다는 가볍게 내용을 정리하면서 마음의 소리를 일부 적어봤다.
내일부터는 제대로 TIL을 작성하면서 남은 기간 동안 화이팅 해보겠다.