개발자 명심보감

새로운 기술을 공부하다 보면 이런 의문이 생긴다.

나는 제대로 공부하고 있는 건가?

개발공부는 혼자 배우는 일이 많다.

그래서 피드백을 받기 힘들다.

특히 군대처럼 상명위복 구조에서 내 방식에 대해서 옳다 틀리다 판단해줄 내 업무를 미리 경험해본 선배가 없을 가능성이 많다.

그럼 어떻게 척도를 판단할 수 있을까?

지금 시대는 무인도에 떨어져서 생존하는 (그러나 유투브, 책의 도움이 있는)
"자신을 돌봐줄 사람은 자신밖에 없다."

그래서 자기자신을 객관화 하고 인지할 수 있는 메타인지 훈련이 필요하다.

메타인지를 통해 내 자신을 객관화 했다 치면 그걸 뭐랑 비교하냐

그 비교대상을 특정 기술, 프레임워크가 아닌 Sofrtware 를 잘 하는 존재가 있어야 한다.

예를들어 SwiftUI를 배우고 있다. 그런데 나는 이전 UIKit을 잘한다.

그럼 UIKit을 잘 하는 내 자신과 객관적으로 비교하는 것 이다.

하지만 이때 UIKit 을 본질까지 꿰뚫고 있어야 그 존재가 버팀목이 되어줄 수 있다.

껍데기만 알면 안되는 것 이다.

좋은 성과는 얼마나 문제에 대한 본질에 가까워져 있는가 에서 나온다.

그럼 이런 의문이 들 수 있다.

지금 일하기도 바쁜데 언제 본질까지 공부하고 앉아있냐?

이러한 공부 과정은 일과 떨어져 있으면 의미가 없다.

문제 하나하나에 대해서 해결하는 과정 중 끝까지 파봐야 한다는 것이다.

그럼으로써 그 문제에 국한된 경험일 수 있지만 문제를 해결하는 일반적인 시야 를 가질 수 있게 되는 것 이다.

(그리고 면접때 이러한 얘기를 심도있게 전달 할 수 있어야 한다.)

얼마나 엔지니어적으로 근성과 깊이가 있는지를 보여주는 척도인 셈이다.

하지만 무조건 깊이, 오래 파본다고 좋은건 아니다.

본인이 이러한 문제를 해결했는데 어떻게 해결했고 푸는 과정중 한 뎁스씩 들어갈 때 마다 그 깊이에서의 중요한 것, 흥미로운것 에 대한

스스로의 가치 판단이 있어야 한다.

결국 문제를 해결하는 과정에서

• 문제 파악
• 해결하려는 노력 (가지판단과 끝까지 파보는 엔지니어적 마인드)
• 더 좋은 방법은 없는지
• 누군가에게 이 과정을 잘 전달할 수 있는지 (스토리 텔링)

이 중요한 셈이다.

결론적으로 어떤 기술을 공부할 때 개발자 명심보감을 정리해 보자면

1. 기술에 대한 지식, 학습 과정을 본인을 객관화 해라 (메타인지)
2. 객관화한 자신을 자신이 본질까지 아는 다른 기술에 대한 본인과 비교해라
3. 그러기 위해선 최소 하나이상의 본질까지 아는 기술이 필요하다.
4. 좋은 성과는 문제에 대한 본질에 얼마나 가까운지에서 결정된다.
5. 일과 문제해결은 동일선상에 있어야 한다.
6. 문제를 해결할 땐 끝까지 파보도록 해야한다. (엔지니어적 마인드)
7. 끝까지 파보는 와중에도 그것이 중요한 건지 가치판단을 해야한다.
8. 누군가에게 이 과정을 잘 전달할 수 있으면 좋다.

만약 이 과정을 통달하고 본인의 성장도 하며 팀으로써도 성장을 한다면 더 좋지 아니한가