디자인, 일러스트레이션, 애니메이션 또는 기타 창작 분야에서 일한다면 조만간 똑같은 난관에 부딪히게 될 것입니다. 여러분이 매일 사용하는 소프트웨어와 컴퓨터 프로그램은 단순한 "도구"가 아닙니다.컴퓨터는 그 자체의 규칙, 특성, 그리고 개성을 지닌 하나의 생태계입니다. 이러한 미묘한 차이를 이해하는 것은 컴퓨터 사용에 어려움을 겪는 것과 컴퓨터가 마치 마법처럼 느껴지는 것 사이의 차이를 만들어낼 수 있습니다.
키보드 단축키와 몇 가지 요령을 제외하면, 운영 체제, 프로그래밍, 디버깅, 기술 문화, 업무 방식 등 세부적인 내용이 아주 많습니다. 이는 창작 활동에 사용하는 애플리케이션의 디자인과 기능에 영향을 미칩니다. 이러한 세계를 내부에서 이해하면 개발팀과 더 효과적으로 협업하고, 현실적인 요구사항을 제시하며, 무엇을 만들 수 있고 무엇을 만들 수 없는지 알기 때문에 더욱 강력한 아이디어를 떠올릴 수 있습니다.
유닉스, 맥, 리눅스, 그리고 이 시스템이 생각보다 중요한 이유
많은 크리에이터들에게 있어 고전적인 논쟁은 다음과 같습니다. 디자인 작업에 맥이 좋을까요, 윈도우가 좋을까요?하지만 소프트웨어 업계에서는 이러한 논의가 종종 한 단계 더 나아가 유닉스 대 나머지 모든 운영체제라는 구도로 이어집니다. macOS와 대부분의 리눅스 배포판은 유닉스 철학을 계승하여 개발 및 자동화 작업에 매우 강력한 플랫폼을 제공하며, 이는 사용자가 사용하는 도구에 직접적인 영향을 미칩니다.
프로그래머들은 흔히 이렇게 말합니다. "유닉스 시스템 전체는 마치 하나의 거대한 개발 환경과 같습니다."터미널에서 이미지 처리, 내보내기 자동화, 렌더링 스크립트 실행, 서버 관리, 코드 컴파일 등 작고 강력한 유틸리티들을 연결하여 사용할 수 있도록 모든 것이 설계되었기 때문입니다. 그래픽 마법사에 의존하지 않고도 이러한 작업을 수행할 수 있습니다. 이것이 바로 많은 고급 크리에이티브 제품군, 게임 엔진, 3D 도구들이 이러한 환경을 염두에 두고 설계된 이유입니다.
반면 윈도우는 시각적이고 사용자 친화적인 인터페이스를 제공하지만, 역사적으로 볼 때, 이 운영체제는 심층적인 개발이나 명령줄 작업에 그다지 친화적이지 않았습니다.오늘날에는 (WSL, PowerShell 등의 등장으로) 그 격차가 상당히 좁아졌지만, 유닉스 문화는 여전히 여러분이 인식하지 못하는 사이에 사용하는 많은 소프트웨어에 스며들어 있습니다.
창작자로서 이 분야에 관심을 갖게 된 이유는 무엇인가요? 왜냐하면 시간을 절약해주는 자동화 도구, 스크립트, 플러그인은 종종 유닉스 환경에서 탄생합니다.이를 숙달한 팀에서 협업하면 프로젝트 규모가 커짐에 따라 확장이 용이한 더욱 견고하고 안정적인 워크플로를 구축할 수 있습니다.
프로그래밍은 논리, 공학, 그리고 풍부한 창의성이 어우러진 보기 드문 조합입니다.
겉으로 보기에는 프로그래밍이 순전히 차가운 계산처럼 보일 수 있지만, 실제로는 그렇지 않습니다. 수학, 공학, 그리고 무자비한 창의성이 기묘하게 뒤섞인 작품입니다.마치 여러분이 삽화나 스토리보드를 만드는 것처럼, 개발자는 소프트웨어가 여러분이 상상한 대로 정확하게 작동하도록 논리 회로를 설계합니다.
대부분의 전문가들은 다음과 같이 동의합니다. 문제 해결 능력과 창의력은 수많은 언어를 아는 것만큼이나, 어쩌면 그 이상으로 중요합니다.동일한 기능을 구현하는 데에는 여러 가지 방법이 있는 것처럼, 표지나 로고를 디자인하는 방법도 수천 가지가 있습니다. 핵심은 가장 깔끔하고 우아하며 유지 관리가 쉬운 솔루션을 찾는 것입니다.
그렇기 때문에 크리에이티브 팀이 다음 사항을 이해하는 것이 점점 더 중요하게 여겨지고 있습니다. 코드는 디자인이기도 합니다.소프트웨어 아키텍처 설계, 데이터 흐름, 내부 구조는 앱, 플러그인 또는 웹사이트에 요구할 수 있는 기능에 큰 영향을 미치며, 이러한 요소들이 없으면 프로젝트는 유지보수가 불가능한 기괴한 괴물이 될 수 있습니다.
네, 프로그래밍은 중독성이 있습니다. 많은 개발자들은 자신들의 작업을 최고의 논리 퍼즐이라고 표현합니다.규칙과 구성 요소를 직접 정할 수 있는 게임으로, 아무것도 없는 상태에서 무언가를 만들어내는 것을 즐기는 사람의 사고방식과 아주 잘 맞습니다.
컴파일, 명령줄 및 기타 코딩 "의식"
"컴파일 중입니다"라고 말하고 커피를 들고 의자에서 사라지는 사람을 본 적이 있다면, 그 이유를 알아두세요. 변명이 될 순 없지만, 완벽한 변명거리임에는 틀림없습니다.컴파일이란 소스 코드를 실행 가능한 프로그램으로 변환하는 것을 의미하며, C++와 같은 언어나 대형 게임 엔진에서는 몇 분에서 몇 시간까지 걸릴 수 있습니다.
하루하루, 컴파일 시간은 숨을 고르거나, 개념을 복습하거나, 단순히 마음을 재정비하는 데 사용할 수 있습니다.창작 환경에서 렌더링 엔진을 사용하거나 용량이 큰 게임 빌드를 할 때 비슷한 상황이 발생합니다. 컴퓨터가 작업을 완료할 때까지 기다리는 동안 대기 시간이 생기는데, 많은 팀이 이 시간을 활용하여 아이디어를 논의하고, 디자인을 다듬거나, 작업을 검토합니다.
이와 관련된 것이 바로 명령줄인데, 처음에는 무섭게 느껴지지만 일단 익숙해지면 괜찮아지는 검은 화면입니다. 그것은 일종의 마법 지팡이가 됩니다.실제로 거기서 하는 일은 축소판 프로그래밍입니다. 그래픽 인터페이스에서 하기 힘든 작업을 자동화하기 위해 스크립트 언어(예: Bash)로 명령어를 작성하는 것이죠.
뛰어난 크리에이터라면 터미널에 대해 알아야 할 네 가지 사항은 매우 유용할 수 있습니다. 수천 개의 파일 이름을 바꾸고, 일괄적으로 형식을 변환하고, 렌더링 스크립트를 실행하고, 백업을 이동하거나, 프로젝트를 동기화할 수 있습니다. 마우스를 사용하지 않고도 가능합니다. 이는 컴퓨터의 언어를 배우고 프로그래머의 사고방식에 더 가까워지는 또 다른 방법입니다.
코드의 어두운 면: 세미콜론, 버그, 그리고 끝없는 디버깅
소프트웨어의 가장 잔인한 기묘함 중 하나는 바로 이것입니다. 아주 작은 것들이 거대한 것을 파괴할 수 있다잘못된 세미콜론, 빠진 괄호, 또는 잘못된 위치에서 닫히는 대괄호는 완벽하게 구상한 수백 줄의 코드를 망칠 수 있으며, 마찬가지로 잘못 잠긴 레이어는 전체 PSD 파일을 파괴할 수 있습니다.
개발자들은 하루 중 상당 시간을 화려하지는 않지만 필수적인 업무에 할애합니다. 디버깅 오류버그를 찾는 것은 마치 이상한 곳에 숨어 있는 생물을 사냥하는 것과 같습니다. 버그가 항상 프로그램을 충돌시키는 것은 아니며, 특정 시점에 이상한 오류를 발생시키거나 특정 데이터 또는 특정 장치에서만 나타나는 경우도 있습니다.
당신의 세계에서는 이것이 다음과 같은 의미로 해석될 수 있습니다. 특정 파일 형식에서만 오류가 발생하는 도구, 컴퓨터에서는 정상적으로 보이지만 실제 운영 환경에서는 오류가 발생하는 애니메이션, 특정 브라우저에서만 제대로 작동하지 않는 웹사이트 등 다양한 문제가 있습니다.놀랍게도, 이러한 부분들은 대개 코드에 훨씬 더 심각한 버그가 있음을 보여주는 가시적인 부분입니다.
이러한 문제를 극복하기 위해 대부분의 프로그래머는 다양한 디버깅 기술을 개발합니다. 로그, 그래픽 디버거, 중단점 및 변수 상태 출력 결과를 활용하십시오....그리고 특히 찾기 어려운 버그를 발견한 사람에게는 내부적인 보상까지 제공하기도 합니다. 이것이 바로 "빠른" 변경이 실제로 그렇게 빠르지 않은 또 다른 이유입니다.
네, 맞습니다. 유머도 있습니다. 코드에 있는 많은 주석들이 풍자적인 작은 예술 작품이 되곤 합니다. "// 마법. 만지지 마세요.", "// 취했으니 나중에 고치세요." 또는 "// IE 브라우저용 해킹 (IE가 브라우저라고 가정)"참호 속 유머는 개발자 문화의 중요한 부분입니다.
게으름, 자동화, 그리고 버전 관리: 위장된 미덕
이상하게 들릴지 모르지만, 개발 중입니다. 게으름은 제대로 이해하면 직업적 미덕으로 여겨진다.핵심은 간단합니다. 반복적이고 수동적인 작업이라면, 똑똑한 누군가는 그 작업을 자동화하여 다시는 하지 않아도 되도록 만들 방법을 찾을 것입니다. 바로 이러한 "게으름"이 스크립트, 플러그인, 자동화된 작업, 매크로를 탄생시켰고, 우리는 그것들이 어디서 왔는지도 모른 채 매일 그것들을 사용하게 됩니다.
진지한 프로젝트에서 그러한 철학은 또 다른 핵심 요소에 기반합니다. 버전 관리, 그중에서도 Git이 단연 최고입니다.Git 덕분에 팀원들은 서로 방해받지 않고 같은 프로젝트에서 작업하고, 별도의 브랜치에서 기발한 아이디어를 테스트하고, 애플리케이션의 절반이 고장 났을 때 되돌리거나, 누가 언제 무엇을 수정했는지 확인할 수 있습니다.
개발자와 협업하는 크리에이티브 전문가에게는 기본 사항을 이해하는 것이 필수적입니다. 커밋, 브랜치, 병합이란 무엇인가요? 이는 여러모로 도움이 됩니다. 개발 진행 상황을 추적하고, 디자인에 영향을 미치는 변경 사항이 언제 도입되었는지 모니터링하고, 새로운 기능을 확정하고 기존 기능을 다듬는 데 집중할 시기를 더 잘 조율할 수 있도록 해줍니다.
더 나아가 이러한 자동화 문화는 겉보기에 덜 "기술적인" 작업에도 적용됩니다. 배포 스크립트, 자동 문서 생성, 매일 밤 자동으로 실행되는 테스트, 자산 변환, 이미지 압축 또는 버전 생성 파이프라인 사람의 개입 없이 다양한 장치에서 작동합니다. 이 모든 것은 같은 과정을 손으로 백 번 반복하는 것을 거부한 누군가로부터 시작되었습니다.
주석, 명확한 이름, 그리고 가독성 좋은 코드에 대한 집착
레이어 이름이 잘 지정되고 그룹이 체계적으로 정리된 디자인 파일이 무한히 높이 평가되는 것과 마찬가지로, 코드는 순서, 맥락, 그리고 적절한 태그를 필요로 합니다.그렇지 않으면, 몇 주 전에 그 글을 쓴 사람조차도 통과할 수 없는 정글이 되어버립니다.
훌륭한 프로그래머는 다음 두 가지를 매우 중요하게 여깁니다. 의미 있는 이름과 실제 맥락을 제공하는 설명변수 호출하기 userAge o totalCost 그것은 그보다 훨씬 더 많은 것을 말해준다 x o temp특정 알고리즘이 선택된 이유나 사용된 기법을 설명하는 것이 단순히 "// 두 숫자를 더합니다"라고 주석을 다는 것보다 훨씬 더 유용합니다.
실제로 이는 프로젝트에 대한 일종의 내부 "기술 스크립트"를 생성하며, 다른 개발자들이 이를 읽고 이해할 수 있게 됩니다. 각 모듈의 소프트웨어 설계 결정 사항잘 작성된 코드는 때때로 코드 자체가 최고의 주석이 될 수 있는데, 이는 잘 선택된 이름 덕분에 코드가 스스로를 설명하기 때문입니다.
명확성에 대한 그러한 집착은 여러분이 들어봤을 법한 개념들과 매우 잘 맞아떨어집니다. 예를 들어, 클린 코드, 리팩토링 또는 "반복하지 마세요"(DRY) 규칙이러한 모든 철학은 결국 동일한 것을 가리킵니다. 즉, 소프트웨어는 이해하기 쉽고, 변경하기 쉽고, 테스트하기 쉽고, 확장해도 모든 것을 망가뜨리지 않아야 한다는 것입니다.
테스팅, TDD, 그리고 "오늘 당장 작동하게 만드는 것"만으로는 충분하지 않은 이유
여러분이 사용하는 모든 프로그램의 또 다른 눈에 잘 띄지 않지만 근본적인 측면은 다음과 같습니다. 테스트 생태계의 배경단위 테스트, 통합 테스트, 자동화 테스트 또는 수동 테스트는 사용자가 요청한 옵션을 추가하는 작은 변경 사항이 시스템의 다른 20개 부분을 조용히 망가뜨리는 것을 방지하기 위해 존재합니다.
TDD(테스트 주도 개발)와 같은 방법론이 있는데, 먼저 테스트 코드를 작성하고, 그 다음 테스트 코드를 통과하는 코드를 작성합니다.언뜻 보기에는 비직관적이지만, 개발자로 하여금 처음부터 원하는 동작, 예외 상황, 그리고 시간이 지나도 모든 것이 제대로 작동하는지 검증하는 방법을 고려하도록 만듭니다.
크리에이티브 팀에게 있어 이는 매우 구체적인 결과로 이어집니다. "버튼에 작은 변경만 해주세요" 또는 "새로운 효과를 추가해주세요"와 같은 요청은 테스트 및 검증 측면에서 상당한 비용을 수반합니다.그들이 당신을 돕고 싶지 않아서가 아니라, 인터페이스에 대한 아무리 사소해 보이는 수정이라도 부작용이 있을 수 있고, 애플리케이션의 나머지 부분이 제대로 작동하는지 확인해야 하기 때문입니다.
또한 많은 기업들이 팀원들이 잠자는 동안이나 주말에 실행되는 테스트 스위트를 구축해 놓습니다. 코드가 컴파일되고, 일련의 테스트가 실행된 후, 결과가 검토됩니다.문제가 발생하더라도 최종 사용자에게 도달하기 훨씬 전에 감지됩니다. 여기에는 제작 과정에서 해당 도구를 사용하는 크리에이터도 포함됩니다.
알고리즘, 데이터 구조, 그리고 속도: 도구의 보이지 않는 엔진
파일 검색, 순식간에 적용되는 필터, 수천 개의 레이어가 있어도 유동적인 상태를 유지하는 캔버스 뒤에는 보이지 않는 무언가가 있습니다. 악의적인 의도로 선택된 알고리즘 및 데이터 구조리스트, 스택, 큐 또는 딕셔너리(해시맵)를 사용하는 것은 성능에 엄청난 차이를 가져옵니다.
예 필요한 항목을 빠르게 찾아야 할 때는 일반 목록보다 사전이 훨씬 효율적입니다.이를 통해 편집자는 대규모 프로젝트에서도 스타일, 심볼 또는 에셋을 밀리초 단위로 찾을 수 있습니다. 픽셀, 벡터, 3D 메시 또는 오디오 트랙을 저장하는 방식에도 동일하게 적용됩니다.
크리에이티브 앱이 느리게 작동할 때, 항상 컴퓨터 탓만은 아닙니다. 때로는 병목 현상이 몇 년 전에 내려진 소프트웨어 설계 결정에 있는 경우도 있습니다.혹은 "임시방편으로" 도입했다가 영구적으로 고착화시킨 빠른 지름길을 택한 경우도 있는데, 이는 많은 프로젝트에서 안타깝게도 흔히 볼 수 있는 현상입니다.
그래서 많은 전문가 조언 칼럼들이 다음과 같은 점을 강조하는 것입니다. 성급한 최적화는 피하되, 처음부터 올바른 알고리즘과 구조를 선택하십시오.이러한 견고한 기반 덕분에 확장성이 뛰어납니다. 더 많은 레이어, 더 많은 효과, 더 많은 사용자, 더 많은 장치를 지원하면서도 시스템 오류 없이 안정적으로 작동합니다.
프로그래머 문화: 엉뚱한 농담, 이진법, 그리고 "숟가락은 없다"
개발자들과 함께 일하다 보면 언젠가는 이런 말을 듣게 될 겁니다. “사람은 두 종류로 나뉜다. 이분법을 이해하는 사람과 이해하지 못하는 사람.”10을 이진수로 나타내면 2가 된다는 사실을 이용한 고전적인 농담입니다. 이런 종류의 기술적 유머는 밈, 서브레딧, 매트릭스, 스타워즈, 스타쉽 트루퍼스 등에 대한 언급 등 하나의 하위 문화로 자리 잡고 있습니다.
유명한 문구 "숟가락이 없어요" 매트릭스 비유는 인터페이스를 꿰뚫어 보고 애플리케이션의 내부 구조를 이해하는 느낌을 설명할 때 자주 사용됩니다. 프로그래밍을 알게 되면 프로그램이나 웹사이트를 보는 것은 더 이상 단순히 소비하는 것에 그치지 않습니다. 모듈, 아키텍처, 각 부분이 어떻게 통신하는지, 어디에서 오류가 발생할 수 있는지 등을 상상하기 시작합니다.
버그에 대해서도 마치 버그가 있는 것처럼 논의됩니다. 스타쉽 트루퍼스에 등장하는 생명체들: 겉보기엔 작지만 엄청난 혼란을 야기할 수 있다.공통된 언어가 공동체를 만들어내고, 유머는 거대한 시스템이 당신의 코드를 쥐고 있다는 압박감을 해소하는 한 가지 방법입니다.
창의적인 전문가에게 있어 그러한 문화와 소통하는 것은 프로그래머와의 관계를 더욱 원활하게 만들어 줍니다. 그의 농담, 언급하는 방식, 그리고 특이한 습관들을 이해하기 위해서 이는 마감일, 기술적 제약 또는 막판 변경 사항을 논의할 때 의사소통을 크게 원활하게 해줍니다.
프로그래머들이 (실제로) 어떻게 배우는지, 그리고 이것이 여러분에게 어떤 의미를 갖는지
또 하나 흥미로운 사실은 학위 과정, 부트캠프, 석사 과정 등이 있음에도 불구하고, 프로그래밍 학습의 대부분은 실제로 해보는 과정을 통해 이루어집니다.대학 과목이라기보다는 기술에 더 가깝습니다. 직접 해보고, 부수고, 고치고, 그 과정을 계속 반복하면서 배우는 거죠.
대부분의 개발자들은 다음 한 가지 생각에 동의합니다. 모든 것을 암기할 필요는 없습니다.공식 문서, 포럼, 기사, "프로그래머가 알아야 할 97가지"와 같은 책, 그리고 수많은 온라인 자료들이 있습니다. 스페인어로 된 프로그래밍 언어 튜토리얼중요한 것은 특정 문제에 필요한 지식을 검색하고 선택하고 적용하는 방법을 아는 것입니다. 마치 포토샵 단축키를 모두 외우고 있지 않아도 필요할 때 어디서 찾아야 하는지 아는 것과 같습니다.
게다가 거의 모든 사람이 전문화를 권장합니다. 분야(웹, 모바일, 백엔드, 데이터, 비디오 게임 등)를 선택하고 더 자세히 살펴보세요. 기술 전반을 섭렵하려 하기보다는, 같은 논리를 적용해 보세요. 여러분의 창작 분야에서 소프트웨어가 어떻게 작동하는지 진정으로 이해하는 것이, 모든 것을 조금씩 알면서도 제대로 익히지 못하는 것보다 훨씬 더 큰 힘을 발휘하게 해 줄 것입니다.
내부 설문조사에서 반복적으로 언급되는 또 다른 사항은 멘토와 "페어 프로그래밍"의 중요성입니다. 짝을 지어 프로그래밍하고, 다른 사람에게 코드를 검토하게 하고, 도움을 요청하고, 비판을 수용하세요.스토리보드나 무드보드를 다른 사람과 공유하고 피드백을 받아 작품을 개선하는 것과 완전히 똑같습니다.
개발자의 현실: 외로움, 집중력, 그리고 거대한 헤드폰
내부적으로 소프트웨어 팀의 일상은 크리에이티브 스튜디오와 꽤 많은 공통점을 가지고 있습니다. 화면 앞에서 보내는 수많은 시간, 긴 시간 동안 집중하는 것, 그리고 방해받는 것에 대한 애증 관계팀원 절반이 마치 의무적인 작업용 헬멧처럼 엄청나게 큰 소음 차단 헤드폰을 착용하고 있는 모습을 보는 것은 드문 일이 아닙니다.
음악이 생산성 도구가 되다: 아키텍처적 사고를 위한 간편한 리스트, 기계적인 작업을 위한 더욱 강력한 도구, 복잡한 버그 디버깅을 위한 완벽한 정적 환경헤드폰은 단순히 취향의 선택이 아닙니다. 스튜디오에서 테이블 위에 깃발이나 작은 신호를 놓아두는 것처럼, 헤드폰은 "지금은 방해하지 마세요, 집중 모드입니다"라는 사회적 신호입니다.
하지만 덜 눈에 띄는 또 다른 측면이 있습니다. 컴퓨터 앞에서 혼자 오랜 시간을 보내는 것은 고립감을 유발할 수 있습니다.많은 베테랑 개발자들은 로봇처럼 취급받는 것을 용납해서는 안 되며, 코딩 외에도 취미, 인간관계, 운동, 휴식 등 삶을 가꾸는 것이 중요하다고 강조합니다. 솔루션을 설계하는 두뇌와 인터페이스를 설계하는 두뇌는 동일하며, 각각에 필요한 공간이 있다는 것입니다.
이와 동시에, 아주 현실적인 무언가가 있는데, 그것은 바로… 프로그래밍 중독무언가에 푹 빠지면 "이 모듈만 끝내면 돼"라는 생각에 밤새도록 공부하고, 밥 먹는 것도, 잠자는 것도, 심지어 의자에서 일어나는 것조차 잊어버리기 쉽습니다. 다른 모든 창의적인 활동과 마찬가지로, 번아웃을 방지하려면 스스로 한계를 설정하는 법을 배워야 합니다.
사고방식, 자기 능력에 대한 불안감, 그리고 건전한 경쟁
프로그래밍을 시작하는 대부분의 사람들은 기술 분야 출신이지만, 그렇다고 해서 인문학 배경을 가진 사람이 재교육을 받을 수 없다는 뜻은 아닙니다.참전 용사들이 가장 중요하게 여기는 것은 고등학교 졸업장의 종류가 아니라, 꾸준함, 학습 능력, 그리고 논리적 사고에 대한 편안함입니다.
이 업계 종사자 거의 모두가 상당히 흔한 현상을 겪고 있습니다. 사기꾼 증후군"나는 아는 것이 부족해, 실수를 저지를 거야, 이 일을 해낼 능력이 없어"라는 생각은 경력에 상관없이 누구나 느낄 수 있습니다. 많은 사람들이 이러한 생각을 학습을 지속하는 동기로 삼지만, 지나친 불안감으로 이어지지는 않아야 합니다.
경쟁 또한 중요한 요소이지만, 건전한 형태의 경쟁은 오히려 다음과 같은 모습을 보입니다. 동료들 사이에서 누가 모듈을 가장 잘 최적화하는지, 누가 가장 우아한 코드를 작성하는지를 두고 경쟁하는 현상 누가 누구를 밟고 올라가는지 겨루는 전쟁과는 다르죠. 존경하는 프로그래머가 당신의 작품을 높이 평가해주는 것은 다른 창작자가 당신의 그림이나 영상을 칭찬해주는 것과 매우 비슷합니다.
이러한 환경에서는 피드백을 수용하는 법을 배우는 것이 매우 중요합니다. 칭찬을 받을 때 길을 잃지 말고, 비판을 받을 때 포기하지 마십시오.이 분야는 워낙 빠르게 변화하기 때문에 통제할 수 없는 기술이 항상 존재하고 특정 분야에 대해 더 잘 아는 사람들이 항상 있을 것이며, 이러한 상황을 받아들이고 살아가는 것이 이 업계의 일부입니다.
가장 시간이 많이 걸리는 부분은 디버깅, 좌절감 관리, 그리고 언제 전환할지 결정하는 것입니다.
최종 결과물만 보면 개발자들이 하루 종일 새로운 기능을 개발하는 데 시간을 보내는 것처럼 보일 수 있지만, 실제로는 그렇지 않습니다. 대부분의 시간은 오류를 수정하고 기존 시스템을 조정하는 데 소요됩니다.프로젝트를 진행하려면 시스템의 나머지 부분이 진행되는 것을 방해하는 작은 버그들을 해결해야 하는 경우가 많습니다.
이로 인해 좌절감이 극에 달하게 됩니다. 원인을 찾기 어려운 문제, 뚜렷한 이유 없이 실패하는 빌드, 불가능한 마감일을 요구하는 고객들많은 전문가들은 특히 복잡한 제품을 다룰 때 모든 것을 그만두고 다른 분야로 옮기고 싶었던 순간이 있었다고 말합니다.
그들이 추천하는 전략은 왠지 낯익다. 끈기, 자기 주도성, 일을 잘 해냈다는 자부심, 그리고 그 일에 대한 진정한 열정여느 까다로운 창작 분야와 마찬가지로, 그러한 조합이야말로 일이 잘 풀리지 않을 때 다시 시도하게 만드는 원동력이며, 표면적인 수준에 머무르는 사람과 진정으로 뛰어난 사람이 되는 사람을 구분 짓는 요소입니다.
일정 수준의 이직률 또한 흔한 현상입니다. 우수한 지원자는 지속적으로 채용 제의를 받습니다.여기 있는 많은 조언들이 공통적으로 말하는 것은 바로 자신의 가치관과 맞는 기업 문화를 찾아야 한다는 점입니다. 그리고 면접은 당신 또한 회사를 평가하는 자리라는 것을 명심하세요. 면접 과정에서 회사의 문제점에 대해 많은 시간을 생각하게 될 것입니다. 따라서 좋은 대인관계와 공유된 가치관은 이력서에 적힌 것보다 훨씬 더 중요합니다.
기술 면접, 팀 통합 및 의사소통
개발자 커뮤니티 내에서 기술 면접은 매우 유명하지만, 동시에 평판도 좋지 않습니다. 많은 베테랑 개발자들은 다음과 같이 생각합니다. 그것들은 과대평가되어 있고, 그 중 하나라도 실패했다고 해서 당신의 잠재력이 부족하다고 단정짓는 것은 아닙니다.일반적으로 이러한 시험들은 압박 속에서 특정 기술들을 얼마나 잘 발휘하는지를 측정하는 것이지, 장기적인 학습 능력, 협업 능력, 그리고 프로젝트를 성공적으로 완료하는 능력을 측정하는 것은 아닙니다.
대신, 소프트 스킬은 종종 모든 것을 바꿔놓습니다.의사소통하는 방법, 이해하지 못하는 부분이 있을 때 질문하는 방법, 피드백을 수용하는 방법, 다양한 배경을 가진 사람들(창의적인 사람이라면 당신처럼)과 협력하는 방법, 그리고 긴장된 순간에도 침착함을 유지하는 방법을 아는 것입니다.
회사에 입사할 때, 신입 프로그래머에게 가장 중요한 추천 사항은 무엇일까요? 질문하는 것을 두려워하지 마세요. 단, 신중하게 질문하십시오.멘토와 질문할 시간을 구체적으로 정하고, 급한 일이 아니면 말을 끊지 않으며, 질문을 철저히 준비하세요. 기술 팀에 합류할 때도 마찬가지입니다. 의사소통이 명확하고 체계적일수록 팀에 더 잘 적응할 수 있습니다.
멘토가 배정되지 않은 환경에서 가장 바람직한 조치는 다음과 같습니다. 경험이 풍부한 사람의 신뢰를 얻고 탄탄한 전문적 관계를 구축하기 위해 그 사람과 함께 말이죠. 결국 대규모 프로젝트는 코드와 디자인의 품질만큼이나 프로젝트를 구축하는 사람들 간의 관계의 질에 달려 있습니다.
궁극적으로 우리가 매일 사용하는 도구들의 놀라운 성능은 다소 인간적인 요소들의 조합에서 비롯됩니다. 끊임없이 배우고, 좌절하고, 경쟁하고, 협력하고, 이상한 이진수 농담에 웃고, 점차 아이디어를 소프트웨어로 구현하는 사람들창작자로서 이러한 호기심과 작업 방식을 이해하게 되면, 서로 같은 언어로 소통하고, 실제로 무엇을 만들 수 있는지 묻고, 컴퓨터가 상상한 대로 작동하게 만드는 거의 "마법 같은" 과정에 참여하는 것이 훨씬 쉬워집니다.