[번역] - 40년 경력 프로그래머 (3) -Noah Gibbs

이 글은 noah gibbs의 The Forty-Year Programmer 의 번역 본입니다. 오역,의역 혹은 번역이 어색한 부분이 있을 수 있습니다. 😅

일과 커리어을 혼동하지 마세요 (Don't confuse Work and Career)

저도 언젠가 은퇴하고 싶지않을까요 ? 그렇죠. 하지만 저는 일을 멈추지 않을거에요. 돈 때문에 싫어하는 일을 그만할거예요 특히 멋진걸 배울게 없다면 말이죠. 현재 YJIT에서 제가 하고있는작업은 돈을 받고 하고 있지 않습니다. 하지만 급여를 받지 않는다면 지출 보고서는 손도 대지 않을 것이고 상태 업데이트도 거의 작성하지 않을 것입니다. 시스템 관리자 업무나 Git 기록 정리도 훨씬 덜 할 것입니다. 일과 커리어를 혼동하지 마세요. 둘은 같은 것이 아닙니다. 거의 관련이 없습니다. 소프트웨어를 작성하는 것은 놀라운 일입니다. 경력을 쌓는것 이상으로 좋습니다.

이게 제가 음악가 이야기를 계속하는것에 대한 또 다른 이유입니다. 돈을 받고 음악을 만들고 연주하는 사람들이 있습니다. 하지만 많은(대부분)의 음악가들은 돈을 받지 않으면서 음악을 합니다. 그 일은 흥미롭고 강력하며 만족스러운 일입니다. 하지만 일은 일에 관한 것이고 , 직업은 일을 할 수 있도록 길을 열어주는 것입니다. 저에게 소프트웨어 개발은 그런 일입니다. 여러분도 마찬가지신가요 ?

하지만 가장 중요한 것은 언제 어떤 종류의 조언을 받고 있는지 알고있는것입니다. 업무에 대한 조언 을 받을수 있습니다. 아니면 일에 대한 조언을 받을수도있겟죠 둘 중 하나를 다른 것으로 착각하면 그 조언은 별 의미가 없습니다. 게다가 사람들은 일과 직업, 경력 등의 단어를 혼용해서 사용하기도 합니다. 따라서 듣는것 만으로는 뭐가뭔지 구분하기 쉽지 않을겁니다.

레벨로 정의된건 없습니다.(There are No Defined Levels)

배움에 순서가 중요하지않다면 레벨 1 레벨 2 같은건 실제로 없습니다. 또는 다른 레벨, 어떤 언어나 기술을 먼제 배워야 하는지에 대해 다양한 추천을 받을 수 있고, 괜찮습니다. 그러나 자신의 길을 개척하며 독학하는것이 기본을 하지 않고 못했다는 의미는 아닙니다. 결국 중요한 것이 있으면 필요하다는 것을 깨닫고 다시 시작합니다.

그렇지 않을 수도 있습니다. 하지만 대부분 그럴 것입니다.

해마다 누군가 기본적인것을 저버리는 끔찍한 일을 저질렀다는 무서운 이야기를 듣게 됩니다. 실제로도 그런일이 일어납니다. 예를 들어, 모든 모듈이 서로의 변수를 직접 설정하는 끔찍한 스파게티 코드를 15년 동안 작성할 수도 있습니다. 계속 시도하다 보면 그것이 왜 나쁜지 알아내거나, 그 문제에 대한 새로운 해결책으로 새로운 스타일을 발명하고 이상한 것을 잘하게 될 것입니다. 한 프로그래머의 새로운 패러다임은 항상 다른 프로그래머에게는 이상한 것 입니다.

문제는 더 나아지기 위해 계속 노력하지 않을 때입니다. 새로운 실수를 계속 저지르다 보면 유용하거나 아름답거나 기괴한 것들을 배울수 있습니다. 개선하려는 노력 없이 같은 일을 계속한다면 더 나아지지 못할 것입니다.

그사실은 누군가 만들어 놓은 레벨디자인을 따라하더라도 마찬가지입니다.

이소룡은 "나는 만가지 발차기를 할수있는사람은 두렵지않다고" 말했습니다. 그러나 그는 "한가지 발차기를 만번 연습한 사람을 두려워 한다" 라고말했습니다.

성장의 비결은 관심을 가지고 개선하는 것입니다. 한 가지, 또는 열 가지, 또는 충분히 오래 지속한다면 백 가지에 집중하면서 그렇게 할 수 있습니다. 아마 만 가지를 관리하기는 어려울것입니다. 하지만 정말 열심히 노력한다면 제생각이 틀렸다는 걸 증명할 수 있을 겁니다. 당신은 이상한일을 해볼 필요가 있습니다.

이상한 것으로 불리는 새로운 패러다임은 우리가 새로운 일에 능숙해지는 방법입니다. 매주 화요일마다 완전히 새로운 일 해보기 가 당신의 한 목표라면 그냥 계속 해보세요 그것이 나쁘다는것을 알게 될수도 있고, 그걸 정말 잘하게 될 수도 있습니다.

더 잘할수록 남들과 똑같이 보이지 않습니다.(The Better You Get, the Less you Look Like EveryBody)

초기 교육 (코드 스쿨, 블로그 포스트, 대학 강의, 책)은 종종 조립 라인처럼 느껴지기도 합니다. 함수 작성, 디버깅, 추정, 팀과의 대화 등 매우 기본적인 기술을 가르치면서 각 기술에 기본적인 수준의 역량을 갖추도록 하려고 합니다.

예를 들어 수석 엔지니어의 경우 필요한 기술 목록이 있지만 목록에 있는 기술이 더 많고 기술 수준도 더 높아야 한다고 생각하기 쉽습니다. 하지만 전혀! 그렇지 않습니다.

직급뿐만이 아닙니다. 오픈소스의 '레벨'도 존중의 수준입니다.

빙고 카드 크리에이터의 패트릭 맥켄지처럼 아주 간단한 코드를 가지고 그것에 대해 (영어로, 사람들에게) 아주 자세하게 글을 쓰면 큰 존경을 받을 수 있습니다.
회사 창립자처럼 정말 수익성 있는 글을 써서 존경받는 사람이 될 수도 있습니다. 또는 모호한 언어(하스켈, 아시나요?)처럼 깊고 복잡한 것을 쓰면 존경받는 사람이 될 수도 있습니다. 이러한 길은 기본적인 역량 외에는 서로 공통점이 거의 없습니다.

무언가를 정말 잘해야 하고, 그것이 인기가 있거나 수익성이 있거나 어떻게든 '대박'을 터뜨려야 합니다. 이것은 매우 모호하게 들릴 수 있습니다. 또한 주관적인 기준이기도 합니다. 빌 게이츠 수준의 소프트웨어로 돈을 벌려고 하스켈(복잡하고 심오하며 비평가들의 찬사를 받았지만 수익성은 그다지 높지 않음)을 작성했다면 큰 실패가 될 것이고, 그 반대의 경우도 마찬가지일 것입니다. 그리고 관련 기술도 완전히 다릅니다.

그렇기 때문에 "저는 15년 경력의 소프트웨어 엔지니어인데, 보통 연봉이 얼마인가요?"와 같은 질문을 하는 것은 어리석은 일입니다. 15년이라는 경력은 옆에 서 있는 15년 경력의 엔지니어와 거의 차이가 없어야 할 정도로 많은 경력입니다. 책을 쓰셨나요? 돈을 벌 수 있는 대규모 프로젝트에 참여했나요? 흥미로운 오픈소스 프로젝트를 진행했나요? 그 15년 동안 무엇을 했나요? "저는 20년 경력의 뮤지션인데 시간당 얼마를 받아야 하나요?"라고 묻는 것과 같습니다. 이 질문에 대한 간단한 답은 없으며, 있어서는 안 됩니다.

급여만 중요한 것이 아닙니다. "저는 15년 경력의 소프트웨어 엔지니어이기 때문에 이 프로젝트를 이끌 수 있는 능력이 있는 거죠?"라고 질문할 수 있습니다. 물론 대답은 "그럴 수도 있습니다."입니다. 다음 제 질문은 "그 15년 동안 무엇을 했습니까?" 입니다.

요약 및 개인적인 생각 ✨

1. 일과 커리어을 혼동하지 마세요.

• 직업 ,일 (career,work) 를 혼용해서 사용하는 일이 많습니다. 정말 궁금하거나 질문하고싶은것이 일에관한것인지 업무에 관한것인지 스스로에게 질문해 볼 필요가 있습니다.
• 직업에 매몰되거나 집착하지마세요! 프로그래밍을 하는것 프로그래밍 하는것 자체를 즐겨야합니다.

2. 레벨로 정의되는 것은 없습니다.

• 소프트웨어, 프로그래밍 이란 개념, 분야가 출현한지 오래되지 않았지만 많은 기술과 패러다임등이 나오고 사라지곤 합니다.
• 점차 분야가 발전하면서 배울게 많아지고 있습니다. 그러나 누군가가 만들어 놓은 레벨디자인( xx 순서 등) 은 결국 그사람이 정의한것 뿐, 정말 중요한건 어느 레벨이라기보다는 관심을 가지고 계속 발전하려는 태도 입니다.

3. 더 잘할수록 남들과 똑같이 보이지 않습니다.

• 경력이 중요한 것이아니라 당신이 지금까지 무엇을 해왔는가 에 대한 물음을 던진다. 저는 경력xx입니다. 보다는 xx프로젝트 등을 했으며 xx에서 어떤 성과가 있었습니다. (당신이 무엇을 할 수 있는가)