훌륭한 코드를 작성하는 것 이상의 미래가 있습니까?

빠른 운동을 해보자. 5년 이상 개발자로 전문적으로 일했다고 가정해 보겠습니다. 수십 개의 프로젝트를 통해 실무 경험을 쌓았고 새로운 기술, 도구 및 프레임워크에 대해 학습하여 기술을 날카롭게 유지했습니다. 다양한 라이브러리에 기여하고, 작성한 코드를 정기적으로 리팩토링하고, 동료와 주기적으로 코드 리뷰를 교환합니다.

그러나 그때 누군가 당신에게 다가와 당신이 이해할 기회가 없었던 한 가지 질문을 합니다. 당신은 10년 후의 당신 자신을 어디에서 보고 있습니까?

계속해서 같은 길을 간다면 더 나은 코딩을 하고 조금 더 빠른 나이 든 개발자가 될 것이라는 생각에 대해 걱정할 수도 있습니다. 일부 개발자는 이 생각에 만족하며 그 길을 계속 가고 싶어 합니다. 그러나 다른 사람들은 당신이 겪었던 교훈과 성장의 롤러코스터가 빠르게 순항 제어 모드로 전환되고 있음을 깨달을 수 있습니다.

개발자로서 자신의 역할을 완전히 통제할 수 있다고 느끼면 더 많은 일을 하고 싶은 가려움을 느끼기 시작합니다. 그 이상은 아니지만 대신 개인의 성장이 더 필요합니다. 어쩌면 다른 것입니다.

제 경력의 지난 몇 년 동안 저는 답을 찾고 있었습니다. 저는 기술 배경을 최대한 활용하는 매우 영향력 있는 역할로 전환하는 데 성공한 많은 성공적인 개발자들과 함께 일할 기회를 얻었습니다. 그들 각각은 핵심 기술과 보완 기술 간의 균형을 기반으로 유기적 전환을 할 수 있는 다른 경로를 모색했습니다.

여기에서 어디로 갈 수 있습니까?

우리가 탐색할 수 있는 몇 가지 새로운 경로가 있으며, 이는 우리가 우리의 안락한 영역을 넘어 성장하도록 하는 동시에 우리가 열심히 개발한 기술의 혜택을 받을 수 있습니다.

개발자로서 우리가 읽는 대부분의 기사, 프로그래밍 책, 심지어 동료의 조언까지 모두 더 나은 코드를 작성하는 데에만 집중할 수 있도록 조정되었습니다. 그 외에는 더 잘 작동하는 방법이나 좀 더 철학적인 관점에서 진화하는 방법을 배우지 않습니다.

우리는 일반적으로 경력을 시작할 때 설정한 목표를 달성한 후 어떤 일이 닥쳤는지 또는 남은 평생 동안 하루에 8시간 코딩하는 것 외에 하고 싶은 일이 있는지 전혀 모릅니다. 가까운 장래에 코드 작성 이외의 다른 일을 하게 된다면 팀에 대한 우리의 기여 가능성을 과소평가하는 것이 일반적입니다. 더 영향력 있는 위치에서 우리의 관점과 기술이 확실히 필요함에도 불구하고 어떻게 더 큰 영향을 미칠 수 있는지 확신할 수 없습니다.

업계의 말을 들어라

2008년에 제가 프론트엔드 개발자로 경력을 시작했을 때 사람들의 의사소통 방식을 바꾸면서 백만장자가 된 젊은 프로그래머 Mark Zuckerberg에 대해 들어보지 못한 사람은 세상에 없었습니다. 밀레니얼 세대는 후드티를 입고 합법적으로 부자가 되는 아이디어를 낭만적으로 만들기 시작했습니다. 갑자기 제 세대의 거의 모든 사람들이 개발자가 되고 싶어했습니다.

10년이 지난 지금, 우리는 코더 붐의 진정한 영향을 느끼기 시작했습니다. 올해의 스택 오버플로 설문 조사를 통해 응답자의 3분의 2 이상이 전문 코딩 경험이 10년 미만임을 알게 되었습니다.

리더십 기술을 갖춘 숙련된 개발자가 드물다는 것을 분명히 알 수 있습니다. 따라서 이제 기업은 더 많은 후배 개발자를 감독하고 작업 품질을 유지할 수 있는 방식으로 최고의 인재를 확보할 수 있는 창의적인 방법을 찾아야 합니다. 이것은 성장하는 팀 내에서 유기적인 리더십 구조를 만듭니다.

업계는 계속해서 빠른 속도로 성장하고 있으며 개발자로서의 우리의 역할도 마찬가지입니다. 프로그래머로 출발한 이사와 관리자를 찾는 것이 더 일반적이 되었으며, 기업은 이제 개발 배경이 필요한 더 많은 리더십 위치를 공개하고 있습니다.

프로그래밍이 차기 블루칼라 직업으로 여겨졌음에도 불구하고 개발자의 역할은 조직 내에서 매우 영향력 있는 위치로 성장하고 있다고 해도 과언이 아닙니다. 그러나 그러한 전환을 통해 우리를 안내하는 서면 로드맵이나 입증된 공식은 없습니다.

우리의 옵션에는 어떤 것이 있습니까?

내 경력에서 내가 꿈꾸는 미래에 대한 두려운 질문을 받은 시점이 왔습니다. 나는 대답이 없었다. 사실, 그것은 내 마음을 넘어서지 못한 더 많은 질문을 촉발했습니다.

저는 이미 프론트엔드 리드로 일하고 있었기 때문에 코드 작성과 별개로 점점 더 많은 책임이 주어졌고, 이로 인해 프로그래밍을 하지 않을 가능성이 있는 미래에 대해 생각하게 되었습니다. 다양한 프로젝트에서 더 많은 영향을 미칠 수 있다는 가능성은 확실히 매력적이었습니다.

그래서 나는 어떤 옵션이 내 미래에 흥미로울 수 있는지 조사하기 시작했습니다. 일부 동료들이 개발자 역할에서 회사 내 중요한 위치로 성공적으로 전환한 경로를 살펴보았습니다. 대부분의 경우는 작은 조치를 취하고 적시에 적절한 장소에 있는 것으로 구성되었습니다. 그러나 전반적으로 그들은 모두 다음 세 가지 주요 활동 그룹에 참여하게 되었습니다.

1. 팀 및 프로젝트 관리
   한 무리의 사람들을 위대함으로 이끄는 것은 흥미롭게 들리지만 쉽지 않습니다. 노련한 개발자로서 동료 개발자 그룹을 팀으로 관리하거나 여러 분야의 팀에서 프로젝트를 관리하는 것과 관련된 많은 성장 옵션이 있습니다. 매우 보람 있는 옵션이지만 키보드에서 한 발짝 떨어져 위임하는 방법을 배워야 하므로 모든 문제를 개인적으로 해결하는 데 익숙한 개발자에게는 매우 까다로울 수 있습니다.
   
   우리가 프로세스와 관련 팀을 더 많이 제어할 수 있는 위치로 이동하면 코드와 관련하여 익숙한 제어를 희생해야 할 필요성이 생길 가능성이 큽니다.
2. 멘토링 및 인재 개발
   얼마나 많은 상사가 최고의 개발자를 복제하는 것에 대해 환상을 가지고 있습니까? 현실 세계에서는 여전히 이런 일이 일어나지 않을 것이므로 현명한 상사는 차선책을 수행합니다. 가장 능숙한 코더가 자신의 지식을 동료에게 적극적으로 전달할 수 있는 프로세스를 설정하는 것입니다.
   
   일부 개발자는 일상적으로 자연스럽게 이 작업을 수행하지만, 고위 개발자에게 정기적으로 시간을 할당하여 자신의 성장에 대해 작업할 수 있는 보다 공식적인 역할이 주어지면 항상 더 효과적이라는 점을 명심해야 합니다. 팀. 이것은 코드 검토, 워크샵 및 일부 동료와의 개별 평가를 통해 수행할 수 있습니다.
3. 기술 사업에 종사하다
   개발자들이 클라이언트에게 판매할 때 프로젝트가 어떻게 피칭되거나 정의되었는지에 대해 불평하는 것을 듣는 것은 매우 일반적입니다. 그리고 대부분의 경우 불평하기에는 너무 늦습니다.
   
   제 경험상 저는 개발자들이 세일 기간에 참여한 프로젝트에서 일하는 것이 더 행복하다는 것을 알게 되었습니다. 다른 누구도 단서가 없는 방에서 잠재적인 기술적 문제에 플래그를 지정하는 논리적인 동료가 있다는 것은 항상 좋은 일입니다.
   
   컨설턴트와 기술 이사의 역할은 대규모 디지털 프로젝트에서 매우 중요합니다. 클라이언트 워크샵에 개발자의 참여와 모든 프로젝트 시작 시 기술 문서 초안 작성은 잠재적으로 프로젝트 수명 주기의 판도를 바꿀 수 있습니다.

새로운 도구 세트 작업

계속해서 성장하기를 원하고 단순히 코드를 작성하는 것 이상의 일을 하고자 하는 미래를 시작하고 싶다고 가정해 보겠습니다. 우리가 향하고 있는 방향에 대한 아이디어가 있으면 아직 도약할 준비가 되어 있지 않을 가능성이 큽니다. 결국 우리는 우리를 더 나은 개발자로 만드는 기술을 습득하는 데 집중해 왔습니다.

배워야 할 것이 많다는 것을 깨닫고 나면 올바른 기술 세트를 작업하기 시작해야 합니다. 이번에는 다를 것입니다. 우리는 새로운 언어, 프레임워크 또는 라이브러리를 배우지 않을 것입니다. 우리는 과거에는 중요하지 않다고 느꼈지만 이 불확실한 영역에서 다음 단계를 수행하는 데 중요한 기술을 비축해야 합니다.

의사 소통

어느 회사에서나 일을 하고 있는 사람이라면 누구나 생각할 수 있는 일입니다. 커뮤니케이션은 모든 유형의 조직 내에서 협업의 핵심으로 알려져 있습니다. 불행히도 프로그래머는 수년 동안 이 분야에서 무료로 입장할 수 있었습니다. 논리적인 사고를 하고 열심히 일하고 열정적인 개인을 찾아야 하는 필요성으로 인해 실제로 훌륭한 의사 소통 기술이 필요하거나 사회적으로 매우 어색한 무리가 없어도 우리가 번창할 수 있었습니다.

다른 팀 및 고객과 함께 일하고 싶은 열망이 있다면 커뮤니케이션의 모든 측면을 개선하기 위해 노력해야 할 것이 매우 분명합니다. 일대일 미팅, 프리젠테이션, 중요한 이메일 모두 지금부터 꼼꼼히 다듬어야 합니다.

소유권

논리적 사고방식은 우리가 업무를 조직하는 방식에 영향을 미쳤습니다. 개발자로서 우리는 일반적으로 작업이 시작되는 곳과 끝나는 곳을 흑백으로 구분합니다. 이것은 우리가 수행해야 하는 작업을 명확하게 이해할 수 있게 해주지만 때때로 우리의 경계를 확장하고 안락한 영역 밖에서 일하는 것을 방해할 때 긍정적입니다.

비즈니스의 첫 번째 순서는 우리가 참여하는 작업의 모든 측면에 대한 소유권을 가져오는 것입니다. 개발자의 작업이 끝나는 지점을 정의하는 경계를 흐리게 함으로써 우리는 새로운 책임을 맡을 수 있고 결국 다른 역할로 전환할 수 있습니다.

지도

우리가 경력에서 어디로 향하든지 우리는 팀원들이 우리를 신뢰해야 합니다. 비록 잠시 동안 완전히 명확하지 않더라도 우리가 올바른 방향으로 가고 있음을 알 수 있도록 해야 합니다.

이를 달성하기 위해 우리는 우리의 지식을 증명할 수 있어야 하고, 우리의 결정에 확신을 가질 필요가 있을 것이고, 확실히 우리의 실수를 인정하고 그것들로부터 빨리 배울 수 있어야 할 필요가 있을 것입니다.

이것은 간단한 작업이 아니며 목록에서 확인할 수 있는 것도 아닙니다. 우리가 개발 거품 밖에서 계속 성장하기를 바라는 한 우리의 헌신이 필요합니다.

일하러 가다

경력에서 도약하고 싶다는 확신이 들면 올바른 방향으로 움직이기 시작해야 합니다. 첫 번째 단계는 옵션을 탐색하고, 추구할 경로를 결정하고, 해당 경로가 현재 역할과 어떻게 일치하는지 확인하는 것입니다.

당신의 회사는 당신이 멘토나 매니저가 될 수 있는 공간을 제공합니까? 그곳에서 성공할 가능성이 있다고 생각합니까, 아니면 다른 곳에서 계속 성장해야 한다고 생각하십니까? 이것들은 스스로에게 물어야 하는 질문 중 일부일 뿐이며 팀원 및 관리자와의 대화로 이어질 수도 있습니다.

새로운 방향으로 한 발짝 내딛기 위해서는 노력을 기울이고 열린 마음을 갖고 필요한 만큼 여러 번 실패하고 다시 시도할 수 있을 만큼 회복력이 있어야 합니다.