반드시 읽어봐야 할 개발 학습법 19가지(4)

13. 더 나은 개발자가 되는 8가지 방법(박민우 번역)

• 배울 것이 얼마나 많은지 상기할 것.

     → 무언가를 배운다 = 그것을 모른다는 것을 깨닫는다

     → 스스로 알고 있다는 착각을 극복해야 한다.

 

• 내가 맞다는 것을 증명하려고 하지 말 것.

     → 내 코드가 잘 작동된다는 사실을 증명하지 말고, 적극적으로 어디가 잘못됐는지를 찾아야 한다.

     → 내가 놓친 결함은 결국 사용자가 발견하게 된다는 걸 유념하자.

 

• '동작하는 코드'는 끝이 아니라 시작이다. 

     → 일단 끝났다고 멈추는 것은, 스냅 사진 한 장을 찍고 그게 예술 작품이 되기를 기대하는 것과 같다.

     → 동작하는 코드를 더 낫게 만들어야 한다.

 

• 세 번 다시 작성할 것.

     → 첫째, 이슈를 해결하는 데, 그 해결책이 가능한 것임을 증명하기 위한 소프트웨어를 작성할 것.

     → 둘째, 동작하게 만들 것.

     → 셋째, 올바르게 만들 것.

     → 내 코드에 발생한 이슈를 해결하는 데, 얼마나 많은 접근법이 있는지 알게 된다.

     → 관습적 방법에만 얽매이는 것도 막을 수 있다.

 

• 코드를 많이 많이 읽을 것. 

     → 사실, 프로그래밍 스킬을 향상시키는 가장 일반적이고도 가장 값진 방법이다.

        ∵ 다른 사람들이 프로그래밍에서 발생하는 이슈를 어떻게 해결하는지 볼 수 있어서

 

     → 단, 글자만 읽지 말고 수업 or 도전 과제 쯤으로 생각하자. 셀프질문 생활화!

          ▸ 나라면 저 코드 블록을 어떻게 짰을까? - 어떻게 다르게 할 수 있을까? 다른 해결책이 있나?

          ▸ 코드를 읽고 무엇을 배웠나? - 저 기술을 내가 짠 코드에 어떻게 적용할 수 있을까? 나는 저기에 ~~~ 기술을 쓰는 건 생각도 못 해봤어.

          ▸ 이 코드를 어떻게 하면 개선할 수 있을까? - 만약 확실히 개선할 수 있고, 그게 오픈 소스 프로젝트라면 PR을 보내보자!

          ▸ 원 작성자의 스타일로 코드를 작성해보자. - 작성자의 머릿속으로 들어가는 연습이 된다. 공감능력 향상에도 도움이 된다.

          ▸ 생각에만 그칠 것이 아니라, 위의 질문에 대한 답을 어디에든 ─ 개인 저널, 블로그, 코드 리뷰 프로세스 등에 ─ 직접 적어보자.

          ▸ 복붙에 그치면 안 된다. 다른 사람의 지혜를 생각 없이 맹목적으로 받아들이는 건 결국 나에게 독(毒)이 된다.

 

• 코드를 작성할 것. (단, 숙제처럼 하지 말 것)

     → 개인적 프로젝트를 함으로써, 시장 가치를 보여줄 도구나 기술을 배우고 자신감을 얻을 수 있다.

     → 개인적 프로젝트는 미래의 고용주에게 내가 배움을 멈추지 않는 사람이라는 증거로 작용할 수 있다.

     → 개인적으로 진행하는 코딩은 '스스로' 해내야만 한다는 점이 장점이다.

     → 실패를 두려워하지 말아라. 실패하지 않을 것만 찾아서 하지 마라.

 

• 어떤 방법으로든 다른 개발자와 1:1로 일해볼 것.

     → 다른 개발자나 사용자의 피드백에 주의를 기울여 보고, 그 사람들의 비판에 어떤 공통점이 있는지 파악하자.

     → 운이 좋다면 모든 부분(코딩 기술에서부터 커리어 결정까지)에서 내가 믿고 따를 멘토를 만날 수도 있다.

 

• 도구가 아닌 기법을 배울 것.

     → 가능한 한 많은 경험을 다양한 언어와 프레임워크에서 쌓는 게 좋다.

     → 근본에 집중해야 한다. 기본은 절대 변하지 않는다. 프로그래밍보다 아키텍쳐에 더 주의를 기울여라.

 

https://mnpk.medium.com/%EB%B2%88%EC%97%AD-%EB%8D%94-%EB%82%98%EC%9D%80-%EA%B0%9C%EB%B0%9C%EC%9E%90%EA%B0%80-%EB%90%98%EB%8A%94-8-%EA%B0%80%EC%A7%80-%EB%B0%A9%EB%B2%95-45ea6cd70114

[번역] 더 나은 개발자가 되는 8 가지 방법

 

 

 

 

 

14. 개발 배우기가 정말 어려운 이유 (E. Trautman 원저, Sigrid Jin 번역)

 

코딩 자신감(confidence)과 숙련도(Competence). 아마도 개발자로서 직업을 얻기까지 많은 사람들의 자신감이 그래프와 같은 너울을 탈 것이다.

 

• 1단계, 강의로 학습하며 자신감이 솟아나는 단계(The Hand-holding Honymoon)

      재미 & 즐거움으로 가득찬 단계. 코딩이 어려워 보이기는 하지만, 정리된 자료가 많아서 볼 것이 가득하다.

      기본적 문법을 배우고 높은 수준의 성취도를 느끼고 있을 것이다. (뜨끔... 이거 내 얘긴가...ㅎ)

 

        →  1단계에서 살아남는 방법

              ▸ 여러 다양한 컨텐츠로 시작해 보기. 기초는 어차피 비슷하니까 누가 뭐라 하든 신경 끄기.

                    ex, Khan Academy 챌린지, 생활코딩 Web 강좌, 노마드 코더 클론코딩, 커넥트재단 부스트코스, 인프런 강좌, 스터디파이

 

              ▸ 나와 잘 맞다고 생각하는 컨텐츠 하나를 골라 끝까지 다 듣고, 스스로 만들어보는 연습하기.

 

• 2단계, 혼돈의 카오스(The Cliff of Confusion)

      강의 다 보고, 강좌 모두 수료한 뒤 느끼는 단계. "생각보다 뭐가 이렇게 어려워!!!!!!"를 깨닫게 된다.

      아직 스스로 뭔가를 할 수 있는 단계는 아닌 것 같다. 계속 디버깅 등 스스로 뭔가 시도를 하고는 있지만,

      어떻게 다른 사람들에게 물어봐야 잘 물어봤다고 할 수 있는지 명확하지 않은 상태.

 

        →  2단계에서 살아남는 방법

              ▸ 다른 사람들과 함께 하기.

              ▸ 다른 사람의 코드 읽고 좋은 패턴에 익숙해지려고 노력하기.

              ▸ 어떤 의도로 작성된 코드인지 파악하기.

              ▸ 자그마한 것으로 시작하고 계속 만들어 보기.

              ▸ 디버깅에 익숙해지고 작은 문제라도 해결할 수 있는 능력 기르기 필수!!★★★

 

• 3단계, 절망의 한가운데에 놓임(The Desert of Despair)

      지리멸렬^*에 빠지고 지루한 단계. 새로운 길 하나하나가 옳은 것 같지만, 정작 나는 제자리 같다.

      어려움을 이겨낼 자료를 찾아 계속 헤멘다. 이 단계에서 신기루에 빠지지 않도록 조심하자!

           ^{* 지리멸렬(支_{가를 지}離_{흩어질 리}滅_{멸망할 멸}裂_{찢길 렬}): 이리저리 흩어지고 찢기어 갈피를 잡을 수 없음.}

 

     

내가 학습해야 할 내용은 일주일이나 한 달 안에 끝낼 수 있는 것이 아니다.
누군가 단기 속성으로 끝낼 수 있다고 하더라도 속아 넘어가지 말 것!

 

 

나는 절망에 허우적거리고 있지만, 숙련도는 계속해서 늘고 있다..!!

 

        →  3단계에서 살아남는 방법

              ▸ 분명한 목표 가지기.        "목표 없이 이곳저곳 기웃대지 말고, 여유부릴 시간 있으면 공부해라."

              ▸ 분명한 길을 걷기.        "나를 목표로 이끌어줄 그런 분명한 길을 걸어라. 그럼 이게 꼭 필요한 공부인지 판단할 수 있게 된다."

              ▸ 집중하기.        "코딩이 어려워진다고 금방 질려 다른 거 하지 말고, 코딩에 오로지 집중해라."

 

• 4단계, 놀라운 성장(The Upswing of Awesome)

      "아하, 이제 어떻게 개발해야 하는지 알겠다!"고 끝이 없는 미로를 빠져나갈 방법을 찾아낸 단계.

      아직 내 코드는 어떤 틀에 갇힌 느낌이고 위태위태해 보이지만, 일단 작동한다는 것에 자신감을 얻은 상황.

      주변에선 "우와, 너 대단하다!" 추켜세워주지만, 정작 나는 내 코드를 까 보는 것이 아직 두렵다.

      자신 있게 내세울 수준(production-ready)의 코드를 짜는 방법을 찾지 못했다.

 

                   "하.. 도대체 진짜 기업에서 요구하는 수준까지 도달하려면 기술 격차(gap)을 얼마나 줄여야 하는 걸까?"

 

피드백을 통해 역량을 기르는 단계.

 

        →  4단계에서 살아남는 방법

              ▸ 모범 사례(best practice)를 찾아 따라하기.

                     내 스스로 하던 코딩과 어딘가 차이가 있을 것이다.

 

              ▸ 내 상황을 계속해서 점검하기.

                     몰랐던 부분을 점검하고 고쳐나가야 한다.

 

              ▸ 하기 싫어했던 것을 공부하기.

                     평소에 자주 쓰진 않지만 업무 수행에 꼭 필요한 중요한 것들을 공부하자.

                       ex, 테스트 하기, 데이터 모델링, 구조 짜기, 배포하기 등

              ▸ 제일 중요한 건 뭐니뭐니 해도 피드백!!!★★★

 

 

 

초심자 → 고수로 갈수록 참고할 수 있는 자료의 양이 줄어든다.

 

 

시기에 따라 습득해야 할 지식의 범위...ㅎㄷㄷ.....

 

 

종합하면 이러하다.

 

https://brunch.co.kr/@jypthemiracle/14

[번역] 개발 배우기가 정말 어려운 이유

 

 

 

 

 

15. 고퀄리티 개발 콘텐츠 모음

 상당히 다양한 것들이 있어서, 또한 공부하는 언어마다 필요한 내용이 다를 거라서, 여기는 링크만 추가하기로 하고 넘어간다..ㅎㅎ

 

https://github.com/Integerous/goQuality-dev-contents

GitHub - Integerous/goQuality-dev-contents: { 고퀄리티 개발 컨텐츠 모음 }

 

 

 

 

16. 개발자의 성장에 대한 이야기(주니어, 기술, 팀, 이직, 자기PR) (LANDVIBE)

• 주니어 개발자의 성장

     → 신입으로 입사후 약 3년차가 되는 사람들이라고 보는 것이 일반적!

 

• 분야 정하기.

     → 스타트업: 분야를 정하지 않고 처음부터 제너럴리스트가 되는 것은 위험!

     → 대기업: 보통 팀이 정해지며 스페셜리스트가 되어간다.

 

• 좋은 리더와 함께 일하기.

     → 나를 성장시켜주는 리더와 함께 일해라.

     → 개발 지식이 많으면서 계속 새로운 것을 공부하는 분 밑에서 일을 하면 나도 자극을 받아 성장할 수 있다.

     → 개발 지식만큼이나 소프트 스킬도 중요하다.

          ▸ 커뮤니케이션

          ▸ 리더십

          ▸ 의사결정 방법

 

• 팀워크

     → 혼자 개발한 것이 많다는 건 고작 "나는 프로그래밍을 좋아하고 열정이 있어요."만을 말하는 것이다.

     → 훌륭한 제품의 99% 정도는 팀이 함께 만든 것이다.

     → 리더십만큼 팔로어십도 중요하다.

 

• 사용하는 언어와 프레임워크 분석하기

     → 도구를 사용하려면 사용법을 정확히 익혀야 하듯이,

       개발자로서 빠른 성장을 위해서는 사용하는 언어와 프레임워크의 분석이 필요하고, 그래야 더 나은 제품을 만들 수 있다.

     → 해당 언어나 프레임워크를 설명하는 책 또는 인강 보는 것을 추천.

     → 그 프레임워크가 오픈 소스라면 소스 코드까지 분석해 볼 것을 추천. 투자 가치가 있음.

 

• 이직 준비

     → 회사에서 시키는 일만 하면 이직할 때 곤란해질 수 있다. 경력이 꼬일 수 있으니까.

     → 경력 관리가 중요하다. (타의에 의해 이직해야 할 일이 생길 경우, 연봉 깎이거나 백수 된다.)

     → 이직할 회사에서 면접을 본다고 상상했을 때, 과연 내가 매력적인 지원자로 보일지 생각해 보기.

 

• 4년차 이상 개발자의 성장

     → 남들보다 확실하게 뛰어난 분야가 있는 게 좋다. (차별화)

 

• 한 가지 기술에 집중

     → 4년차 이상이 되면 한 가지 기술을 깊게 보는 능력이 충분히 된다. 다만, 많은 사람들이 할 수 있는데 하지 않는 거다.

     → 노는 시간 절반만 줄여서 좋아하는 기술을 깊게 파 보자.

                    ex, 해당 언어나 프레임워크 오픈 소스에 참여하기

 

• 자기 PR

     → 혼자 열공하고 조용히 지내는 것보다 이왕이면 외부에 내 실력을 보여주는 게 좋다.

     → 꼭 뛰어난 실력이 있어서라기보다 노력하는 모습을 보여주는 것도 의미가 있다.

 

https://www.youtube.com/watch?v=nN7MgO3d6cE