목차
소프트웨어 개발 분야는 빠르게 진화하고 있습니다. 발전하지 않으면 자연스레 뒤처지게 됩니다. 기술은 빠르게 변화하고 있으며, 이 변화에 적응하는 사람들은 큰 보상을 받지만, 그렇지 않은 사람들은 금세 뒤처지게 됩니다. 이 글에서는 개발자들이 흔히 겪는 뒤처짐의 원인과 이를 피할 방법에 대해 설명하고자 합니다.
피드백을 (실제로) 받지 않는다
건설적인 피드백은 개발자의 경력을 발전시키고 기술 수준을 높이는 중요한 요소입니다. Pull Request 피드백, 관리자 피드백, 팀 피드백 등 어떤 형태로든 피드백을 효과적으로 받는 것은 좋은 개발자와 훌륭한 개발자를 구분 짓는 중요한 요소가 됩니다. 만약 피드백을 효과적으로 받지 못한다면, 자신의 기술과 잠재력에 한계를 두는 셈입니다.
피드백을 잘 받는다고 생각할 수 있습니다. "난 피드백을 잘 받아들여, 개인적으로 받아들이지 않고, 피드백을 주는 사람에게 항상 친절해"라고 생각할 수 있습니다. 이것도 좋은 자세이지만, 피드백을 받는 방법은 그보다 더 깊어야 합니다. 피드백은 당신의 코드와 엔지니어링 방식을 재정의해야 합니다. 한두 번의 Pull Request에만 적용해서는 안 됩니다.
피드백을 받는 방법은 다음과 같습니다:
- 질문하라. 피드백에 대해 이해하지 못하거나 동의하지 않는다면 질문하세요. 피드백을 진정으로 이해하거나 믿지 못한다면, 그 정보를 제대로 활용할 수 없습니다.
- 기록하라. 피드백을 기록하고, 기술 저널을 유지하세요. 이를 통해 배운 내용을 검토하고 앞으로 더 나은 기술적 결정을 내릴 수 있습니다.
- 코드에 적용하라. 받은 피드백이 공감된다면 이전에 작성한 코드에도 적용하세요. 특정 코드에 받은 피드백이라면, 다른 코드에도 적용해보세요. 연습이 완벽을 만듭니다.
- 다른 사람에게 전파하라. 배운 것을 가르치는 것이 최고의 학습 방법입니다. 다른 사람에게 가르침으로써 더 깊이 이해할 수 있고, 추가로 더 배울 수 있습니다.
질문하지 않는다
소프트웨어 분야는 특이합니다. 많은 유용한 지식이 대학 강의, 책, 프로그래밍 튜토리얼에 포함되어 있지 않습니다. 그 지식은 뛰어나고 경험 많은 개발자들의 머릿속에 저장되어 있습니다. 이들은 책을 쓰지 않고, 대부분 형편없는 문서를 작성합니다.
따라서 다른 사람들에게 질문하기를 꺼리는 개발자는 항상 호기심 많은 개발자보다 뒤처지게 됩니다. 질문을 많이 하는 개발자는 업계 표준을 바로 배우는 반면, 그렇지 않은 개발자는 몇 년 후에나 배우게 됩니다.
모르겠다면 질문하세요. "이 개발자를 방해하는 건 아닐까?" 또는 "질문하면 바보 같아 보일까?"를 걱정하지 마세요. 필요한 정보를 얻지 못해 바보처럼 보일 날이 올 수 있습니다.
어려운 문제를 피한다
소프트웨어에서는 쉽게 익숙해질 수 있습니다. 익숙한 일만 계속하며 스스로 도전하지 않는다면 진정으로 복잡한 문제를 해결하지 못합니다. 쉽게 해결할 수 있는 작업만 선택하고 어려운 문제를 피하는 개발자들을 많이 보았습니다. 어려운 문제는 가장 많이 배울 수 있는 문제입니다. 스스로를 다르게 생각하게 만들고, 이러한 문제를 해결하기 위해 기술을 탐구하게 됩니다. 같은 쉬운 문제를 계속 해결한다면 개발자로서 뒤처질 것입니다.
프론트엔드 작업만 계속 선택하는 풀스택 개발자는 몇 년 후 프론트엔드 개발자로만 남게 될 것입니다. 작은 간단한 작업만 하는 백엔드 개발자는 복잡한 기능을 구현하는 방법을 금방 잊게 될 것입니다. 사용하지 않으면 잃게 됩니다.
개인 프로젝트를 하지 않는다
모든 개발자가 근무 시간 외에 사이드 프로젝트를 해야 한다고 말하는 것은 아닙니다. 하지만 모든 개발자는 자신만의 프로젝트를 시도해야 합니다. 그 주된 이유는 시스템을 종합적으로 이해하는 데 더 좋은 방법이 없기 때문입니다. 대부분의 소프트웨어 직업에서 개발자는 하나 또는 두 개의 개발 영역에 특화되는데, 이는 개발자의 기회를 제한합니다. 처음부터 프로젝트를 작업하면 지식의 빈틈을 채우고 시스템 설계, 제품 관리, 통합, 인증, 데브옵스 등을 배울 수 있습니다.
또한 사이드 프로젝트를 하는 또 다른 이유는 지식을 실제로 적용할 수 있기 때문입니다. 튜토리얼과 강사로부터 배우는 것과 자신만의 프로젝트를 구현하는 것은 완전히 다릅니다. 튜토리얼에서 배우는 경우 항상 "정답"과 누군가가 안내해 줍니다. 하지만 스스로 작업할 때는 연구와 비판적 사고를 통해 최적의 해결책을 찾아야 하며, 이는 깊은 이해를 심어줍니다.
역할이나 회사를 바꾸지 않는다
역할이나 회사를 변경하면 다음과 같은 일이 발생합니다:
- 새로운 동료와 협력하면서 새로운 것을 배울 수 있습니다.
- 새로운 작업을 하면서 다르게 생각하게 됩니다.
- 다른 기술을 사용하게 되어 능력이 넓어지고, 미래의 기회를 위해 이력서를 강화할 수 있습니다.
이러한 변화는 학습과 향상에 큰 동기부여가 되며, 이는 프로그래밍 능력을 향상시키는 부스트 역할을 합니다. 새로운 기술 스택을 빠르게 배우고 새로운 도전 과제를 해결해야 하기 때문에 더욱 그렇습니다.
프로그래밍 언어를 바꾸지 않는다
이는 많은 프로그래머에게 불편할 수 있지만, 특히 자신이 사용하는 프로그래밍 언어가 최고라고 주장하는 사람들에게는 더욱 그렇습니다. 진실은, 다양한 언어를 배우고 연습하는 데서 많은 가치를 얻을 수 있다는 것입니다. 프로그래밍 언어는 도구일 뿐이며, 작업에 적합한 도구를 선택해야 합니다. 최고의 도구는 없습니다. 더 많은 도구를 가진 개발자가 더 적응력이 뛰어납니다.
C++을 좋아하고 Javascript를 싫어할 수 있습니다. 하지만 결국 프론트엔드 개발에는 Javascript가 훨씬 적합합니다. C++로 프론트엔드 코드를 작성하려는 것은 렌치로 타자를 치려는 것과 같습니다. 다른 맥락에서는 매우 유용하지만, 해당 작업에는 적합하지 않습니다. 마찬가지로, 높은 최적화와 성능을 요구하는 애플리케이션을 작성해야 한다면 파이썬을 피해야 합니다. 파이썬이 나쁜 프로그래밍 언어는 아니지만, 해당 작업에는 적합하지 않습니다.
산업 표준과 요구 사항은 자주 변합니다. 다양한 프로그래밍 언어를 배우면 업계 변화에 따라 적응할 수 있고 항상 수요가 있을 것입니다.
끝까지 읽어주셔서 감사합니다. (_ _)
읽어주셔서 감사합니다! 😊
개발 관련 궁금증이나 고민이 있으신가요?
아래 링크를 통해 저에게 바로 문의해 주세요! 쉽고 빠르게 도움 드리겠습니다.
당신에게 도움이 될만한 유용한 개발 공부 사이트를 소개합니다 :
사이트 이동하기
'Development' 카테고리의 다른 글
| 고급 프로그래머로 인정받기 위한 필수 조건 10가지 (2) | 2024.09.02 |
|---|