3F
1. Fact
- 코딩테스트 준비(코드트리)
- 코드숨 과제
- 프로그래머스 커뮤러닝 신청
2. Feeling
- 약간의 불만을 느꼈다.
3.Finding
- 라인 인턴 서류에 합격했다.
-> 회사에 대한 지원을 중심으로 준비를 해나가는 것이 효과적이다
-> 목표가 명확할수록, 목표에 대한 due가 있을수록 준비 과정이 효율적이고 효과적이다.
-> 하나 하나의 기회를 소중하게 생각하고 지원서를 제대로 작성해야겠다.
-> 많이 배울 수 있는 기회인것 같다.
- 지금까지 해온 과정들을 리디자인했다.
(1) CS 면접 준비에 있어서 인프런에서 새 강좌를 결제했다
-> 지금까지 Bottom-Up 방식으로 준비를 해왔던 것 같다.
-> 생각이 바뀐 점은 Bottom-Up방식과 Top-Down 방식을 결합할 때 더 효과적이라는 점이다.
-> 예를 들어, 이전에는 면접 전날까지 Real MySQL 책을 꼼꼼히 찾아서 읽곤 했다
-> 이런 방식은 기술 면접 준비에 효과적이지 않다.
-> 왜냐하면 기술 면접이란 '내가 아는가'에 관한 것이 아니라,
'내가 알아야 하는 것(=상대방이 나에게 알기를 기대하는 것)을 내가 아는가'에 관한 것이기 때문이다.
-> 따라서 '내가 알아야 하는 것'의 범주를 우선적으로 이해하고, 그것부터 우선순위에 두고 학습을 해야 한다.
(2) 코딩테스트에 있어서 프로그래머스 커뮤러닝을 신청했다.
-> 마찬가지로 코딩테스트도 Bottom-Up 방식으로 준비를 해왔다
-> 이 경우 스스로 '기본기 부족'을 문제로 정의하고, 그것을 해결하려고 시도했던 것이다.
-> 이 경우 문제점은
(1) 문제 정의가 너무 broad함
(2) 나의 개인적인 지식과 경험의 범주하에서의 문제 정의임
-> 즉, 실제 문제는
(1) 내가 인지하지 못하는 범주에 있거나
(2) 그것이 문제라 하더라도 그것'만'이 문제가 아니다.
-> 즉, 그것 이외에도 여러 문제가 존재한다.
- 초보 혹은 주니어 레벨에 많이 하기 쉬운 실수가 이런 경우인것 같다.
(1) 자신의 지식, 경험 범주 내에서 문제를 정의하고, 문제 해결을 시도함
-> 예를 들어, 자동차가 고장이 나서 움직이지 않는다고 가정해보자.
그런데 나는 본네트를 열어볼 줄 모르지만, 바퀴가 구멍이 났는지 판별할 줄 안다.
-> 이 때, 나는 바퀴에 구멍이 났다는 것을 보고, 그것을 열심히 메꾸고,
다시 자동차를 움직이려고 하지만, 자동차가 여전히 움직이지 않는다.
-> 그래서 나는 바퀴를 다시 열심히 살펴보지만, 바퀴는 고쳐져서 이상이 없다.
그래서 계속 바퀴를 열심히 봐도, 여전히 자동차는 움직이지 않는다.
-> 이 경우 바퀴에 문제가 있는 것 뿐만 아니라 + 자동차 엔진에 문제가 있기 때문에
자동차가 움직이지 않는 것이다.
즉, 자신의 문제 정의가 1) 틀리거나 혹은 2) 부분적인 관점에서의 문제 정의
일 수 있음을 알아야 한다.
특히, 중요한 의사결정일수록 문제 정의 과정에서 다각도로 여러 가지를 고려해야 한다.
-> 충분한 시간을 문제 정의에 투자하고, 이것을 체계적으로 정리해야 한다.
-> 마치 사업을 하기 전에 사업 계획서를 작성하는 것과 같다.
-> 그리고 자신의 문제 정의가 틀렸을 가능성을 인지하고, 나보다 더 숙련되고 나은 문제 해결자에게
나의 문제 정의 과정을 공유하고 피드백 받는 것이 시행착오를 줄일 수 있다.
-> 즉, '문제가 무엇인지를 모르는 것'이 가장 큰 문제이며,
이를 극복하기 위해서는 지적 겸손을 갖고, 항상 나보다 나은 사람들에게 질문하고 배워야 한다.
(2) 문제 정의는 적절했으나, 문제에 대한 솔루션이 적절하지 않음
-> 예를 들어, '스프링에 대한 지식이 부족함'을 문제로 정의 내리고,
'블로깅을 하는 것'을 문제에 대한 솔루션으로 했다고 생각해보자.
이를 통해 내가 기대하는 바는 '지식이 축적되고, 개발 역량이 향상 되는 것'이다.
하지만 열심히 블로깅을 해도 실력이 늘지 않는다.
-> 이 경우는 내가 '블로깅을 하는 것'에 있어서 방식이 잘못된 것이다.
-> 이 경우 마찬가지로 '솔루션'에 대해서도 배워야 한다.
-> 어떻게 글을 작성해야 효과적인지, 다른 사람들은 어떻게 글을 작성하고
왜 그렇게 글을 작성하는지를 배워야 한다.
- 왜 불만을 느꼈는가?
-> 요즘 식단 관리를 하고 있다.
-> 식단 관리를 하다가 보면 음식을 지나치게 적게 먹을 때가 있고,
그로 인해 학습 시 집중력이 떨어질 때가 있다.
-> 이것이 학습 효율을 낮추고, 불만으로 이어진다.
-> 이 부분에 대한 문제를 인지하고 개선해야 하낟.
- '열심히' 편향, '실행' 편향이 있다.
-> 즉, '열심히'하는 것을 중요하게 여기고, '열심히' 하지 않으면 스스로 불안하게 느끼는 것을 의미한다.
-> 김창준님의 '함께 자라기'를 보면 'A작업', 'B작업', 'C작업'이라는 용어가 나온다.
-> 이 때, 'A작업'은 '무언가를 하는 것',
B작업은 'A작업을 개선하는 것',
C작업은 'B작업을 개선하는 것' 을 의미한다.
-> 예를 들어 개발을 하는 것이 'A작업'이라면,
개발을 회고하는 것이 'B작업'이고,
회고에 대해 학습하는 것은 'C작업'이다.
-> 현실에서는 열심히 하는 것이 성과로 이어지지 않는 경우가 많다.
-> 이 경우 'B작업', 'C작업'이 제대로 이루어지지 않은 것이다.
-> '열심히'하는 것, '실행'을 하는 것이 중요하지 않다는 것은 아니다.
-> 다만, 내가 사용 가능한 시간이 100이라면, A작업 뿐만 아니라, B작업, C작업에도
고르게 시간이 분배되어야 한다.
-> 개발을 잘하는 사람들은 이러한 습관을 갖고 있다.
- 나의 노력이 좀 더 많은 성과로 이어지게 하려면
(1) 접근 방법(노하우)에 대해 배우고
(2) 계획을 규칙적인 실행이 가능하도록 재설계하고
(3) 통찰을 향상시킬 수 있는 구조를 만들어야 한다.
- 올바른 노하우를 습득하는 것의 중요성을 과소평가해서는 안된다.
- 모르는 용어는 바로 바로 정리를 해야 한다
- 프로그래머의 기본은 컴퓨터를 잘 아는 것이다.
-> 이는 컴퓨터 하드웨어에 대한 지식도 포함된다.
- 코드란, 기본적으로 테스트되어야 하는 것이다.
-> 자신이 작성하는 코드는, 자신이 작성하는 도중에도 항상 테스트되어야 함을 인지해야 한다