일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 상호배제
- core data
- 100 days of SwiftUI
- 인프런
- @state
- COLOR
- 운영체제
- 오브젝트
- Linked List
- struct
- SwiftUI
- Swift
- forEach
- 앨런
- Apple Developer Academy
- scrollview
- 동기화
- 알고리즘
- 프로세스 스케줄링
- IOS
- Codable
- 동시성
- 가상 메모리
- deadlock
- 비동기
- 데드락
- decode
- UserDefaults
- async
- Algorithm
- Today
- Total
기어가더라도 제대로
코드스쿼드 CS10 회고(2022년도 학습자) 본문
잘한 점, 아쉬운 점, 보완할 점
잘한 점
운동과 멘탈관리가 잘됐다. 20대 초반엔 취직 못하면 망하는 줄 알았는데,
점차 후반으로 갈수록 이상하게 마음이 느긋해진다. 인생 짬에서 나오는 여유랄까?
아쉬운 점
컴퓨터 앞에 앉아있다고 공부하는게 아니고, 의도적으로 수련을 해야 실력이 는다.
단순히 시간만 많이 써서 전문가가 된다면 우리는 모두 양치의 전문가여야 한다.
보완할 점
코딩엔 재능이 없으니 노력으로라도 매꾸겠다는 초심이 점차 흐려졌다. 개인의 열정으로 해결되지 않는 부분을 학습 시스템적으로 보완할 방법을 찾아야겠다.
미션이 너무 어려울 땐, 난이도를 쉽게 조절하기(짝 프로그래밍 요청, 라이브러리 만들어진 것 쓰기, 튜토리얼 문서 진행순서대로 따라가보기), 너무 쉬울 땐 좀 어렵게 조절(vim에서 코딩, 시간 제한)
CS10 회고 및 앞으로의 학습 방향
네트워크 cs, 메모리 cs, 비동기 cs가 어려웠지만 네트워크는 생각보다 깃헙 주소를 빨리 얻는 바람에 난이도가 많이 조절 되었다. 그럼에도 불구하고 미션 2까지 독파하지 못한건 많이 아쉽다.
지난 CS1~10동안 실력과 난이도의 관계를 그래프로 표현한 그림에서 위 3가지 cs에서는 불안함을 느끼는 영역에 속했다. 이때의 해결책이 장기적으론 책이나 강의를 듣는 방식이다. 하지만 우린 시간이 모자르므로 단기적인 실력향상의 방식을 이용해야 한다. 예를 들면 차고 있던 모래주머니를 풀거나(?) 전문가의 도움을 구하는 식으로 말이다. 좀 더 구체화 하자면 아래와 같다.
- 짝 코딩 요청 혹은 질문(싱하, 데일)
- 이미 제출한 사람의 기스트를 힐끔 보고 백지에서 구현하기
- 구글링을 섬세하게 수행(데일은 이 분야의 전문가이다. 번뜩이는 직감으로 소스를 물어오는 능력은 그룹원들의 감탄을 자아내기 충분했다.)
현재의 내 수준이 i라고 한다면 i+1 정도 되는 난이도로 맞춰 cs 미션을 수행했어야 궁극적인 효용이 있었을 것이다. 지난 6주간의 시간동안 내 수준(i)을 파악하기 위한 노력은 하지 못햇다. 하는 방법을 모르기도 하고, 해본적이 없는 분야기도 하기 때문이다. 확실히 학교에서 공부하던 방법과는 많이 다르다. 앞으로의 시간을 적절하게 보내기 위해 적용해 나갈 원칙들을 여기에 적는다.
- 쪼개 쪼개 쪼개
- 2:6의 법칙
- 인간은 사회적 동물
- 메이커의 눈
- 작업 시간 제한
- 아이들 장난감
0. 쪼개쪼개쪼개
이 법칙은 큰 문제를 작은 문제로 나누라는 것이다. 작고 구체적인 문제로 나눌 경우에는 문제와 목표가 더욱 구체화되고 이에 따라 본인의 효용감이 올라 못 풀 문제도 풀어 볼 수 있다. 예를 들면 http_client를 만들어 보라
는 큰 문제이다. 그치만 이를
1. NW_endpoint 객체의 프로퍼티를 조사해보고
2. NW_connection 의 메서드를 조사해보고(send, receive)
3. request line이 무엇으로 구성되어있는지, 어떻게 만들면 좋을지
4. response line을 받았을 때 어떻게 핸들링을 할지 고민하라.
라는 작은 문제로 나누고, 이를 작업 시간동안 더 작은문제의 작은문제로 나누면, 더욱 목표가 구체화 된다.
1. 2:6 법칙
이 법칙은 알고리즘 문제는 2시간 이내로 고민을 해보고, 해결할 거같은 사이즈가 나오면 문제를 풀어보는 거다. 시간을 많이 써도 안되는 문제는 분명히 있다. 지금의 지식수준으론 하루가 꼬박걸리는 문제여도 나중에 보면 1~2시간이면 풀 수 있을 수도 있다. 또한 하루 종일 공부한다고 해도 얼마하다 딴짓하는게 습성인지라, 그걸 받아들이는 전략이다. 6은 6시간을 매달려도 안되는 문제들 같은 경우는 과감히 포기한다는 것이다. 처음 공부를 하는 입장에선 모르는 것 투성이기에, 반나절 고민해봐도 뚜렷한 답이 나오지 않으면 나중을 기약하는게 맞다. 우린 할게 많다. 이 법칙의 핵심은 언제 도망을 치느냐에 있다. 언젠가 놓으면 된다는 일종의 보험은 심리적으로 최선을 하지 않게 하는 장애물이 될 수 있기 때문에, 최선을 다해보고 포기라는 부분에 주의해야한다.
2. 인간은 사회적 동물
사회적 자본에 집중해야한다는 법칙이다. 기회가 된다면 남을 돕거나, 스몰토크를 하는 부분에 더 많은 투자를 해야한다. JK의 컨퍼런스 참여차 간 미국에서 대학 동기를 만난 썰에서도 보이듯이, 코딩도 결국 사람이 하는 일인지라, 인적 네트워크의 중요성이 매우 크다. 고독한 천재에 대한 미신을 버려야한다. 애초에 협력이 주된 작업이 코딩이다. 누군가 쓴 정보 문서를 보고, 이미 만들어진 코드를 보고, 내가 만든 코드가 누군가에게 귀감이 되고(혹은 분노가 되고), 수십년 전에 만들어진 프로토콜 덕분에 통신을 하고, 이런 모든 행위가 모여 코딩을 만든다. 코딩은 혼자만 잘해서는 안된다고 이야기 하고 있다.
또한 이기적이긴 하지만, 내가 더 많은 것을 얻어가기 위해선 집단의 지능 향상에 기여했을 때 그 효용이 최대가 될 것이다. 또한 사회적 자본이 충분히 쌓인 그룹에선 질문을 하기 위한 심리적 장벽도 낮아진다. 잦은 토론과 함께 한다는 의식이 문제 해결을 내놓는 속도 또한 앞당긴다. 사담을 많이 하자!ㅋㅋ
3. 메이커(MAKER)의 눈
무엇이든 빠르게 배우는 사람들의 주된 목표는 무엇을 만들어 볼까 하는 것이였다. 공식문서 튜토리얼을 읽으면서도 이쯤 배웠으면 내가 무엇을 만들어 볼 수 있을까를 고민하는 사람이 빨리 배운다는 이야기가 있다. 대체로 새로운 언어를 배우면 처음 목표로 만들어볼 프로그램을 정하고 그걸 배우기 위한 문법까지만 빠르게 읽어보는 것이 중요한 것 같다. 이걸 우리 cs로 이야기 하자면, http와 sql을 배우면 간단한 게시판은 만들어 볼 수 있을 것이다. (호눅스는 db를 만들어보라고 하셨는데 이는 내 수준의 지수적으로 어려운 듯하다. i*
i). 그 함께 자라기에서 나온 순서는 다음과 같다
1. 튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다.
* 글자수 세는 프로그램
* 테트리스
* "The elements of computing systems"에 나오는 각종 예제를 swift로 구현
2. 공부할 때 표준 라이브러리 소스코드를 읽는다.
3. 공부 중 다른 사람의 코드에 내가 필요한 기능을 추가한다.
단순히 for in 문 문법을 읽는 사람하고, for in 문으로 타이머를 만들어보려는 사람의 응용능력은 현저히 차이가 날 것이다.
4. 작업 시간 제한
어느 분야에서든지 일반적으로 적용되는 부분이다. 실력과 난이도에서 손쉽게 난이도를 올릴 수 있는 방법인 시간 제한을 해야겠다. 미션의 예상 소요시간이 6시간이면 이걸 2시간씩 쪼개고 마지막 3번째 세션의 30분은 리드미 작성에 쓰는 방식이다. 이를 위해 타임타이머 어플을 다운로드받았다. 온라인 수업을 하다보니 딴짓을 많이 하는데 이는 회사에 가서도 그리 좋지 않은 습관이다. 다만 의도적인 휴식은 막지 않고 장려한다. 어차피 연속해서 같은 일을 오래 하지는 못할거같으니까 2시간마다 하는 일의 컨택스트를 스위칭해주려고 한다.
이 부분은 좀 수정해야겠다. 요즘은 아주 날 것 그대로의 초보자는 아니다 보니, 몰입이라는 걸 찔끔찔끔하고 있다. 그래서 한시간이 1분처럼 느껴지기도 하고 하다. 컨텍스트 스위칭은 생각보다 인간의 의식적인 자원이 많이 드는 작업이니 이건 좋지 않은 것같다. 작업시간 제한은 몰입 할 수 있는 환경을 만드는 선에서 하는 것이 좋다. 그리고 그것을 위한 환경이 있다면, 불필요한 화면전환 안하기( 검색을 하려면 정해진 시간에 하기), 카톡 알림, 슬랙 알림은 꺼놓기, 맥에 집중 모드에서 하는 것이 가장 좋다.
5. 아이들 장난감
미션을 하면서 세부적인 구현 사항이 있지만, 큰틀에서 일단 오류투성이더라도 구현이 되는 결과물을 빠르게 만들어 보는것이다. 테트리스를 예로 들어 보자.
테트리스를 만든다고 하면, 블록 구현하고, 다음 블록 시퀀스 논리 짜고, 블록 회전 로직 짜고, 사용자 입력 받고, 다 필요한 요소지만, 복잡하긴 하다. 일단 네모를 구현하고, 이것을 화면에서 조작해보는 것부터 만드는 것이 좋다. 당연히 블록이 화면을 벗어나도 된다. 아주 쉬운 부분부터 완성해나가면 성취감이 어려운 미션들을 그나마 할 수 있다고 느끼게 해 줄 것이다.
세줄요약
- 목표를 명확히 하자. 잘하고 싶은 것인가? 주목 받고 싶은 것인가? 꾸준히 하자. 아직 두각을 못내도 괜찮다. 70살까지 할거니까 그때 제일 잘하면 된다.
- 야생 학습(학교 학습과는 다른 개념)을 향상 시키는 방법을 연구하겠다.
- 회고와 커밋메시지에 3분 이상 써야겠다.
ps1. 이걸 지금 6월에 읽는데 cs10을 할 땐 각오가 대단했구나.. 내가 똑똑했구나.. 역시 무식하면 용감하다더니..ㅋㅋㅋ
ps2. 코드스쿼드 회고를 간단하게 써볼까 한다. 마지막 프로젝트가 마무리 되는 즈음에
ps3. 제목이 2202년 학습자 회고 여서 2022 로 바꿨다. 알려준 메이스에게 감사를..
'생각정리 > 회고' 카테고리의 다른 글
(데이터 주의) 2023 Apple Developer Academy 회고 (18) | 2024.05.19 |
---|---|
Apple Developer Academy - MC1 회고 (1) | 2023.04.03 |
[Apple Developer Academy in POSTEC] 1주차 회고 (0) | 2023.03.11 |
# 사전 과제 소감 (2) | 2022.07.18 |
관악산 연주대에서 코딩을 외치다. (산악회 등반 회고) (8) | 2022.06.13 |