주니어 개발자로서 배운 7가지 절대적인 진실

굉장히 좋은 글이 있어 기록하고자 글을 작성하였다.

https://monicalent.com/blog/2019/06/03/absolute-truths-unlearned-as-junior-developer/

7 Absolute Truths I Unlearned as Junior Developer

이라는 글인데 주니어 개발자로서 배운 절대적인 7가지 진실이라는 글인데 주니어 개발자로서 내가 가지고 있었던 잘못된 생각들을

글쓴이의 경험과 회고, 충고를 통해 배우고 수정할 수 있었다. 느낀 점이 굉장히 많았고 모든 것을 한글로 번역하지는 않았지만 구글 번역기 인라인을 활용해 인상적이었던 부분들을 적어두었다.

내용은 다음과 같다.

 

 

주니어 개발자로서 배운 절대적인 진실

1. 나는 시니어 개발자 입니다.

내가 결국 배운 것

모든 경험이 평등하게 만들어지는 것은 아닙니다

혼자 일하는 것보다 팀엣 일하는 것이 10배 더 많은 것을 배울 수 있습니다.

 [다른 개발자가 귀하의 코드를 검토하지 않으면 엄청난 요인으로 인해 최대한 빨리 배우지 못할 것입니다.]

That’s why mentors are so important, and the team you work with is worth so much more than a couple bucks in your paycheck. [그렇기 때문에 멘토는 매우 중요하며, 함께 일하는 팀은 급여에서 몇 달러보다 훨씬 더 가치가 있습니다.] 

혼자일하게 될 주니어 포지션을 받아들이지 말라.

 

급여만으로 역할을 수락하지 마라.

팀은 진정한 가치가 있는 곳이다.

 

직함이 당신을 만들어주지 않는다

5인 팀에서 CTO가 되는 것은 50인 팀이나 500인 팀에서 일하는 것과 다르다.

직급이 같아도 필요한 직업과 기술이 완전히 다르다.

따라서 내가 senior라는 직함을 가졌다고 해서 내가 수석 엔지니어가 되는 것은 아니다.

또한 계층적 타이틀은 본질적으로 결함이 있으며 회사간 비교가 어렵다.

제목에 집착하거나 외부 검증의 한 형태로 사용하지 않는 것이 중요하다는 것을 배웠습니다.

 

2.모두가 테스트를 작성합니다.

한가지는 말씀드릴 수 있습니다. 연구 분야의 프로그래밍은 업계의 프로그래밍과 완전히 다릅니다.

대부분의 경우 어플리케이션을 구축하지 않습니다.

알고리즘을 연구하거나 데이터 세트를 파싱하고 있습니다. 또는 응용 프로그램을 구축하는 경우 작업이 공개 자금 지원을 받을 가능성이 있습니다. 즉, 다른 사람이 무료로 사용할 수 있으며 일반적으로 오픈 소스입니다.

그리고 무엇인가가 무료라는 것은 대부분의 경우 항상 완벽하게 사용할 수 있는지 확인할 책임이 없음을 의미합니다.

그것은 이것이, 무료이기 때문입니다.

 

당신은 또한 돈을 벌거나 결과를 생산할 책임이 없지만 학계에서 개발자가 되는 것에 대해 불평하는 것과는 완전히 다른 블로그 게시물입니다.

요컨대 나는 많은 기대를 안고 학계를 떠났습니다.

업계가 어떻게 작동할 것인지에 대한 기대. 자동화된 배포가 있을 것입니다. 풀 리퀘스트와 코드 리뷰, 영광스러울 것이다! 드디어 내가 갈망했던 코드 품질! 그러나 적절한 표준과 모범사례가 있는 품질 코드를 넘어 소프트웨어 업계의 모든 사람들이 테스트를 작성한다고 저는 굳게 믿었습니다.

에헴.

스타트업에 입사한 첫날, 테스트 결과를 전혀 찾지 못했을 때의 놀라움을 상상해보십시오. 프론트엔드에 테스트가 없습니다. 백엔드에 테스트가 없습니다. 그냥, 테스트가 없습니다.

Nada. Zip. Null. Undefined.  NaN tests.

테스트가 없었을 뿐만 아니라 테스트 부족으로 문제가 있는 사람은 아무도 없는 것 같았습니다!

약간의 순진함을 가지고 테스트가 없는 이유는 사람들이 앵귤러JS에 대한 테스트를 작성하는 방법을 몰랐기 때문이라고 생각했습니다. 내가 그들에게 방법을 가르친다면 모든 것이 괜찮을 것이고 우리는 테스트를 시작할 것입니다.

Wrong!

간단히 말해서, 몇 년과 몇 년후, 우리는 코드에 자동화된 테스트를 추가하는 데 엄청난 진전을 이루었지만 생각만큼 간단하지 않았습니다. 

하지만 사람들이 테스트를 작성하는 방법을 몰라서가 아닙니다.

그들을 테스트가 없는 고통을 결코 느끼지 못했거나, 레거시 테스트를 갖는 고통을 느꼈습니다.

나 자신을 위해 결코 경험하지 못한 두가지.

-결국 내가 배운것

많은 회사와 신생 기업이 테스트를 거의 또는 전혀 수행하지 않습니다.

시장에 맞는 제품을 찾기 위해 고군분투하거나 생존을 위해 고군분투할 때 많은 기업들이 초기에 테스트를 소홀히 합니다.

컨퍼런스나 오픈 소싱 코드를 후원하는 화려해 보이는 회사조차도 여전히 많은 사람들이 최소한의 테스트로 크고 복잡한 단일체를 사용하고 있으므로 개선을 위해 귀하의 도움이 필요합니다. 당신을 모집하려고 하지 않는 개발자에게 코드베이스의 상태에 대해 알려달라고 요청하십시오.

-어떤 회사도 완벽한 기술 설정을 가지고 있지 않습니다. 모든 회사에는 문제가 있고 모든 회사에는 기술적 부채가 있습니다. 문제는 그들이 그것에 대해 무엇을 하고 있느냐는 것입니다. 지원을 할 때 해야할 일이 있다는 환상을 가져서는 안됩니다. 그렇지 않으면 채용하지 않을 것입니다.

-실제 경험이 부족한 주제에 대해 지나치게 독단적인 태도를 취하는 것은 꽤 오만한 일입니다.

나는 테스트가 있어야 한다고 주장하면서도 규모 있는 프로젝트에서 실제로 어떻게 이것을 보이는지에 대한 경험이 거의 없었으면서 모든 것을 알고 있는 사람처럼 행동했습니다.

저처럼 하지 마세요. 원칙을 갖는 것도 중요하지만 다른 사람들의 경험과 관점을 이해하는데 개방적이고 진정으로 관심을 갖는 것도 중요합니다.

3.우리는 다른 사람들보다 훨씬 뛰쳐져있습니다.

일명 테크  FOMO

이것은 단위 테스트의 주제와 밀접한 관련이 있습니다. 우리 회사는 단위 테스트가 많지 않은데 다른 회사들은 많겠죠?

나는 많은 것을 보았고 내가 기본적으로 읽고 있는 다른 모든 회사를 우상화했고, 내 자신의 회사와 프로젝트가 너무 뒤쳐져 있다는 실망감을 느꼈습니다.

-내가 결국 배운 것

Many conference talks cover proof of concepts rather than real-world scenarios.:

많은 회의에서 실제 시나리오보다는 개념 증명을 다룹니다. 

특정 기술에 대한 컨퍼런스 이야기를 봤다고 해서 회사가 일상 업무에서 해당 기술을 사용하거나 모든 코드가 완벽하다는 의미는 아닙니다.

종종 컨퍼런스 연설을 하는 사람들을 실제 사례 연구보다 장난간 앱을 발표하기 때문에 둘을 구별하는 것이 중요합니다.

레거시를 처리하는 것은 완전히 정상입니다.

아니요, 하지만 진지하게, 다른 회사에는 처리할 레거시가 없다고 상상하기 쉽습니다.

그러나 컨퍼런스에서 첨단 기술 회사에서 일하는 사람들과 이야기를 나누며 시간을 보내고 나면 우리 모두가 같은 배를 타고 있다는 것이 분명해집니다.

어떤 회사가 길들이려고 하는 (또는 어떤 시점에서 길들여야 했던) 거대한 PHP 또는 Ruby 모놀리스를 가지고 있지 않습니까?

레거시 코드는 정상이며, 아직 이해하지 못하는 개념에 더 많이 노출되기 때문에 이를 다루는 법을 배우면 앱을 스크래치로부터 처음부터 빌드하는 것보다 더 많은 것을 배울 수 있습니다.

4.코드 품질이 가장 중요

예전에는 나에게 코드 리뷰를 받는 것이 잔인할 수 있었습니다.

 

-내가 결국 배운 것

good enough is good enough

코드가 얼마나 좋은 코드가 되어야 하는지에 따라 어느정도 수익 감소가 발생합니다.

작업을 완료하기 위해 완벽하게 깨끗할 피요는 없고 유지 관리해야 할 총체적 재앙도 아닙니다.

종종 좀 더 반복적이거나 조금 더 장황한 코드가 다른 사람들이 더 이해하기 쉽습니다.

또한 ‘좋은 코드’는 ‘내가 작성한 것처럼 보이는 코드’ 와 다릅니다.

 

아키텍처는 nitpicking보다 중요합니다.

작은 줄의 코드는 개선할 수 있지만 줄을 따라 더 큰 문제를 일으키는 경향이 있는 항목은 일반적으로 아키텍처입니다. 초기에 코드의 작은 비트보다 애플리케이션의 구조에 더 집중했어야 했습니다.

 

코드의 품질은 중요합니다. 오해하지 마세요.

하지만 코드 품질은 내가 생각했던 것과 달랐습니다.

Lint 및 서식 지정 또는 내가 읽은 최신 블로그 게시물에서 홍보된 스타일과 같은 것들이었습니다.

 

5.모든것을 문서화해야 합니다!!!!

처음 회사에 들어갔을 때 솔직히 다른 사람들이 작성한 코드로 많은 작업을 해본 것은 처음이었습니다.

-내가 결국 배운것

문서는 때때로 거짓말을 합니다.

문서화가 만병통치약이라고 생각하기 쉽습니다. “We need docs!” 

문서화 작업이 힘들다고 해서 전혀 가치가 없다는 결론에 도달하지는 않았지만, 올바른 방식으로 올바른 것들을 문서화해야한다는 것을 배웠습니다.

잘못된 것에 대한 과도한 문서화는 문제를 해결하려는 사람들에게 혼란을 줄 수 있는 부실함을 초래하는 경향이 있습니다.

 

적절한 경우 문서화보다 자동화에 중점을 둡니다.

테스트 또는 기타 형태의 자동화가 동기화되지 않을 가능성이 적습니다.

그래서 대신 명확한 언어로 좋은 테스트를 작성하는데 집중하려고 노력하므로 내가 작성한 코드로 작업하는 개발자는 프로젝트가 작업코드로 어떻게 작동하는지 볼 수 있습니다.

또다른 예는 길고 자세한 설치 가이드가 아닌 몇가지 설명으로 애플리케이션 설치를 자동화하는 것입니다.

 

6.기술 부채는 나쁘다

-내가 결국 배운 것

무질서하거나 지저분한 코드는 기술적 부채와 다릅니다.

무언가 ‘좋지 않다’고 해서 그것이 기술적 부채를 의미하지는 않습니다.

기술 부채는 실제로 어떤 식으로든 속도를 늦추거나 특정 종류의 변경을 어렵게 하거나 오류가 발생하기 쉽게 만듭니다. 코드가 조금 지저분하면 그냥 약간 지저분한 것입니다. 그것을 정리하는 것은 내 시간의 가치가 없을 수도 있습니다.

 

기술적 부채가 있는 것은 건강합니다.

때때로 우리는 시간을 빌리기 위해 지름길을 택하고, 이를 위해 미래에 속도의 일부를 포기합니다.

실제로 ‘기술적 부채’인 코드 조각을 갖는 것은 문제가 없는 한 해당 부채를 갚아야 할 가능성이 있다는 것을 인식하는 한 괜찮습니다.

코드베이스에 기술적 부채가 없다고 생각한다면 전달대신 세련미를 지나치게 강조할 가능성이 큽니다.

그리고 내가 그랬어!

7. seniority(연공서열)이란 프로그래밍에서 최고가 되는 것을 의미합니다.

• 내가 결국 배운것

수석 엔지니어는 프로그래밍 외에도 많은 기술을 개발해야합니다.

그 동안 내가 개발해야했던 기술의 순전히 숫자는 내가 가진 것에 비해 천문한적입니다.

의사소통 및 종속성 관리에서 컨텍스트 공유, 프로젝트 관리, 평가 및 비 개발자 동료와의 성공적인 공동 작업에 이르기까지 다양합니다.

이러한 기술을 정량화할 수 없으며 올바르게 하기 위해 많은 시행착오가 필요합니다.

 

모든 사람이 경력 중에 ‘시니어’가 되는 것은 아닙니다.

시니어리티는 오랜 경험의 결과입니다. 그러나 다년간의 경험은 연공서열의 필요조건일 뿐 충분조건은 아닙니다. 또한 올바른 교훈을 내면화하고 미래를 위해 그 학습을 성공적으로 적용하는 올바른 종류의 경험이어야 합니다.

때로는 더 큰 교훈을 완전히 실현하는데 1년 또는 그 이상이 걸릴 수 있습니다. 이것이 바로 당신이 정말 훌륭한 코더라고 해도 수년간의 경험이 여전히 중요한 이유입니다.

 

우리는 모두 어떤 분야에서는 아직 어립니다.

아무리 경험이 많아도 잘 모르는 곳이 있습니다.

모르는 것을 인정하는 것이 그 공백을 메우고 경험이 풍부한 사람들의 도움을 받는 첫번째 단계입니다.

 

 

해당 글에서 앞으로 시니어가 되기 위해 어떤 방향으로 나아가야 올바른 방향일지 접할 수 있었고

이런 방향에서 내가 가지고 있는 여러 잘못됐던 생각들을 수정하는 사람이 되겠다는 생각을 했다.