1. 개요
coder(코더) ・ scripter(스크립터)의사 코드나 명세서로 만들어져 있는 알고리즘 또는 로직을 실제 컴퓨터가 이해할 수 있는 형태로 번역하는 직업이다. 과거의 '코더'가 하던 일은 단순했기 때문에 컴퓨터에 의해 여러 차례 도태당했다.
- 1960~1980년대: 초기 컴퓨터의 경우 마우스와 키보드 같은 HID장치가 없었고, 저장매체조차 없거나 매우 용량이 적고 비쌌기에 코볼과 포트란 언어를 사용해서 코딩용지에 먼저 프로그램을 짠 후(손코딩) 천공 카드에 구멍을 뚫어 컴퓨터가 이해할 수 있는 형태로 만들어서 입출력을 하였다. 따라서 자연스럽게 프로그래머와 단순 작업자 사이의 분화가 이루어졌다. 프로그래머가 코딩용지에 이진수 1과 0을 기입을 하면 작업자는 내용은 잘 모르지만 펀치 카드에 구멍을 뚫으면 1, 안뚫으면 0 이런식으로 구멍을 뚫는 역할만 하는 것이다. HID 장치가 발전하면서 도태되었다.
- 1950~1990년대: 쓸만한 성능의 컴파일러가 아직 발명되지 않아 고급 프로그래밍 언어를 사용하면 실행 속도가 형편없던 시절이 있었다. 이 때 사람이 수작업으로 어셈블리어 코드를 작성한 뒤 병목 구간에 일일이 붙여넣는 작업을 했다. 컴파일러와 CPU 성능이 발전하면서 도태되었다.
2020년대에도 의사코드와 프로그램 코드의 차이가 큰 경우에는 코딩만 전문적으로 하는 인력이 있다, 프로그래밍 난이도가 매우 높고 까다로운 FPGA나 DSP, GPGPU, 임베디드 시스템 등은 알고리듬을 만드는 사람과 코딩하는 사람이 따로 있는 경우도 많다. FPGA는 아예 테스트와 시뮬레이션만 전문으로 하는 인력이 따로 있을 정도이기 때문에 단순한 논리로 코드몽키나 코더라고 비하당할 사람들이 아니다.
2. 확장된 의미
| 영미권의 '코드 몽키' 밈(왼쪽), 프로그래머 김포프가 말하는 코드몽키의 미래(오른쪽) | |
제 실력이 없는, 무늬만 프로그래머인 단순 코딩 노동자를 일컫는 말.
본래 사전적인 의미로서 코더(coder)는 '코딩(coding)을 하는 사람'으로, 개발자 가운데 현장에서 일하는 사람들은 코더의 정의를 만족시킨다고 할 수 있다. 하지만 고전적인 직업(목차 1.)으로서의 코더가 사라지면서 '코더'라는 말이 '지시를 받고 소스를 구현하는 정도에 그치는 비전문 인력'을 가리키게 되었고, 종래에는 '오직 코드 치는 것 밖에 할 줄 모르는 부분집합・하위 분류들'이라는 의미로 변하면서 프로그래머 중 무능한 사람을 비하하는 멸칭으로 쓰이게 되었다. 비슷한 느낌으로 해외에서는 Code Monkey(코드 몽키)라는 경멸적 용어가 쓰이고 있다. 한국에서는 장작, 땔감 등이 이를 지칭하는 은어로 사용되곤 하며, 더 노골적으로는 '코딩 노예' 따위로 부르기도 한다.[1][2] 선진국에서도 부트캠프 출신이면 가능한 한 이력을 숨기려고 한다.
의사코드(pseudo code)가 주어졌을 때 다른 사람이 만들어 놓은 소스 코드를 복사해서 문맥에 맞게 수정해서 그 의사 코드를 실제로 동작하는 코드로 구현할 수 있으면 직업을 가질 수 있다. 고졸, 문과 대졸 등 이공계 기초가 없는 사람도 6개월 정도 Full-time으로 국비 교육이나 부트캠프, 기타 학원 수업을 듣거나 IT 계열 공업고등학교를 나오면 2000년 이후에는 누구나 이 정도는 할 수 있다. 하지만 걸음마 수준으로는 코더 소리나 들으며 저임금도 벗어나기 어렵다. 무엇보다도 30-40대가 넘어 슬슬 전문가로서 힘이 붙고 노후를 준비해야 할 때 유능한 신입이 쏟아져 들어오면 언제든지 늙고 병든 자신이 대체될 수 있다는 불안에 떨게 된다.
2.1. 이들이 일으키는 문제
- 자신의 힘으로 프로그래밍을 할 수 없다.
- 코드를 최신 버전으로 개선할 수 없다. 영어가 안 되어서 한국어 번역 문서만으로 공부하다 보니 최신 정보에 소홀한 탓인 경우도 있다. 따라서 지원이 끊긴 라이브러리를 억지로 가져다 쓰는 막장 상황을 자주 일으킨다. 고객의 '레거시' 시스템에 호환성 레이어를 설치하다 안 돼서 OS 다운그레이드를 권유하는 상황까지 오면 답이 없다.
- 속도가 중요한 프로그램에서 프로그램 최적화를 하지 못 해 고객들의 불신을 받는다.
- 프로그램이 갑자기 꺼지거나 잘못된 결과를 내놓는 등의 오류가 생긴다. 왜 문제가 생겼는지 모르기에 해결도 못 한다. 그리고 보안 취약점을 막지 못 해서 중요한 비밀을 해커에게 털리거나 랜섬웨어에 감염당하고 협박을 당한다.[3]
- 코딩 업무를 해내겠다고 약속하지만 예산과 시간만 쓰고 해내지 못 한다. 잘리고 손해배상 소송 당하기 전에 이직하려 든다. 후임자가 들어오면 전임자의 삽질에도 불구하고 마감일에 맞춰 맡은 업무를 끝내야 하기에 후임자에게 욕을 먹는다. 물론 실제로 하진 않겠지만.
2.2. 코더를 벗어나지 못하는 이유
2.2.1. 완성된 개발 경험의 부족
입문자들 중 굉장히 많은 사람들이 기초적인 문법 공부에서 더 나아가질 않는다. 프로그래머는 기술직이다. 후술되어 있듯이, 과정이 어떻게 되든 눈으로 보이는 결과물을 만들어내는 게 가장 중요하다. 실무에서는 큰 의미가 없다 생각하는 사람도 있지만 현재 교육에서는 이러한 능력을 키우려면 간단한 CLI 즉 글자를 입력하여 컴퓨터에 명령을 내리는 방식에서 동작하는 프로그램을 실제로 만들어 보는 것이 코드를 자신의 의도대로 작성하는 방법을 키우는 게 좋다고 생각하여 교육을 그런 방향으로 한다. 그리고 자료구조 공부를 통해 이론적인 지식까지 갖춰야 더욱 효율적으로 프로그래밍을 하는 방법을 깨우치게 되는 것이다.C/C++와 Java는 목적 의식을 분명히 갖고 공부해야 한다.[4] 그렇지 않으면 복잡한 메모리 관리와 OOP 기법, 수많은 라이브러리 및 모듈, 그 외 각종 비즈니스 로직에 사용되는 여러 기능들만 배우다가 제대로 된 기초를 다지지도 못한 채 끝나버리는 수가 있다. 기초도 모르는 상태로 C/C++, Java처럼 문법이 어려운 언어로 구현하는 것을 고집하는 것은 자칫 시간 낭비가 될 수 있다. 알고리즘 구현이나 관련자료 검색 등 다른 부분에 쓸 수 있는 시간을 굳이 문법 성분 구현에 낭비하는 꼴이기 때문. 그리고 이렇게 낭비된 시간은 당연히 업무 효율에도 악영향을 끼치며, 나아가 인사고과에도 불이익이 된다.
이런 문제를 좀 더 잘 접근하는 방법 중 하나가 문법적으로 쉬운 언어로 working-prototype을 구현해서 테스트하는 것이다. 시스템의 복잡도 때문에 새로운 아이디어가 있다 해도 working-prototype을 구현해보기 전에는 가능한 지 아닌지 여부를 예측하기가 거의 불가능하다. 따라서 이런 작업을 할 때 가장 중요한 것은 시스템 내의 여러 서드파티 HW/SW와 함께 작동시켰을 때 작동하는지 안 하는지다. 최소한의 시간과 노력으로 알고리즘을 구현할 수 있어야만 working-prototype을 만들 수 있고 이를 통해 GO/NO-GO 타입의 의사결정을 할 수 있게 된다. 따라서 이런 종류의 프로젝트에서는 문법이 쉬운 언어로 개념을 검증한 뒤 실제 개발은 (빠른 성능이 필요할 때) 코어 부분만 C/C++를 이용하여 개선하는 식으로 이루어진다.
여러 언어를 사용하는 환경의 직군이라면 위의 방법이 좋은 선택일 수 있다. 그러나, 사용해야할 언어가 지정된 직군이라면 쉬운언어로 테스트를 하는 것이 불가능함은 물론 비효율적이다. 가장 중요한건 똑바로 설계하는 방법밖에 없다. UML을 활용하거나, 의사코드를 활용해서 설계해본 후, 이를 팀원들과 리뷰하고 코드로 변환한다.
다만, 문법적으로 어려운 언어만 알더라도 재능이 있다면 상관 없다. 정보올림피아드 출신들을 보면 문법적으로 어려운 언어들 밖에 할 줄 모르는데도 복잡한 시스템을 곧바로 만들어내기도 한다. 물론 이게 가능한 사람은 애초에 이런 글을 볼 필요가 없겠지만.
2.2.2. 직업에 대한 안일한 인식
코더들은 보통 '평생학습'보다는 '대학 때 대충 공부한 내용이나 국비교육으로 3~6개월 공부한 지식으로 안정적인 평생직장 갖기'를 선호한다. 하지만 프로그래머라는 직업은 결코 안정적인 직업이 아니다. 기술이 계속 발달하는 한 프로그래머가 안정적인 직업이 되는 날은 영원히 오지 않는다. 게다가 최근 컴퓨터공학 관련 학과의 경쟁률이 급격히 올라가고 있고, 어문계열 전공자까지 자기들 지식으로는 도저히 답이 없어서 먹고 살겠다는 심보로 IT 업계로 뛰어드는 마당이라 어중간한 레벨의 프로그래머는 앞으로 몸값이 더 낮아지면 낮아졌지, 높아지기는 힘들다고 예상할 수 있다. 단시간에 배워서 안정적인 평생직장을 가질 생각이라면 차라리 공무원이나 일반 사무직으로 가는 게 좋다.프로그래머는 평생학습으로만 명줄을 이을 수 있는 직업이며, 이 때문에 억대 연봉을 받는 탑 프로그래머들도 40대, 50대까지 신기술에 적응하기 위해서, 시장에서 퇴출되지 않으려고 예외없이 학습에 엄청난 시간을 투자한다. 보통은 학습 시간이 업무 시간의 절반에 가까우며,[5]. 20%도 안 되면 현상 유지조차 하지 못한다. 공부하기 싫어도 프로젝트를 하다보면 일이 막히니 강제로라도 배우게 되어 있으며, 이 때문에 학습과 업무가 순환 구조를 이룬다. 스스로 공부를 하든, 공부해서 얻은 지식을 다른 사람에게 전파하든, 업무의 일부이자 연장선으로 공부해야 한다. 결국에는 소프트웨어 개발을 진정으로 사랑하고 이 분야를 즐기는 사람만이 성공할 수 있고, 살아남는 곳이다.
물론 공부할 시간이 명시적으로 주어지는 건 당장 주어진 프로젝트가 없을 때뿐, 프로젝트를 진행하는 동안에는 그 프로젝트와 관련된 지식 위주로 습득해야 한다. 지금 하고 있는 프로젝트와 관련없는 학습은 또 다른 시간 낭비일 뿐이다. 프로그래밍은 꾸준한 학습을 통해 두뇌를 훈련시킨 사람이 잘 하는 것이지, 굳이 천재적인 지능이 있어야만 하는 것은 아니다. 프로그래머가 마주치는 일반적인 문제들은 지능 부족이 아니라 공부를 안 해서 해결법을 모르는 경우들이다.
2.2.3. 우물 안 개구리
21세기 프로그래머는 활동 영역이 국경을 넘어 전 세계의 지식인들과 교류하는 직업이고, 이것은 단순히 뛰어난 몇몇 소수의 경우가 아니라 기본적인 소양이 되었다. 프로그래머로서 지속적으로 살아남기 위해서는 보통은 전문・학술적 정보를 인터넷이나 전공책등을 통하여 공부해야한다. 보통은 생성형 인공지능이나 Stack Overflow나 Statalist 등 중견급 프로그래머들이 서로 문제와 답변을 주고받는 외국 커뮤니티에 들어가서 필요한 트릭을 찾아내는 편이 훨씬 유익한데, 이런 개발자 커뮤니티의 게시글에 대한 접근성은 구글 검색엔진이 압도적으로 높다.또 집단지성의 규모에서 한국어 정보와 영어 정보는 비교할 수 없을 만큼 큰 차이가 나며, 특히 IT 분야에서는 극심하다. 따라서 해외 사이트 검색을 위한 기초 영어 실력은 매우 중요하다. 어느 정도 실력이 있는 프로그래머들이 많이 상주하면서, 동시에 유동인구도 많고 활성화도 잘 되어 있는 개발자 커뮤니티는 한국에선 전멸 수준이라 영어 사이트들을 살펴봐야 한다.[6] 이런 곳에서 최소한 눈팅이라도 하려면 일정 수준의 영어 실력은 갖추고 있어야 한다.
결국 영어를 공부하지 않으면 절대로 코더 수준에서 벗어날 수 없다. 영어 공부라고 함은 회화를 유창하게 하고 문장을 잘쓰는 영어를 말하는 게 아니다. 독해하고 짧게라도 질문할 수 있는 소통영어가 중요하고[7], 이것은 개발을 웬만큼 하면서 stackoverflow좀 들락달락해봤으면 어렵지 않게 가능한 수준이다. 물론 영어를 몰라도 코딩 자체는 가능하나, 프로그래밍을 원활하게 해 주는 라이브러리, 프레임워크 등의 공식 문서는 대부분 영어로 쓰여 있다. 한국에서 나온 프레임워크는 거의 없는 거나 마찬가지이기에, 공식 문서를 읽지 않고 한국어 번역이나 블로그만 찾아다니면 단편적인 지식만을 얻을 뿐이다. 하다못해 Stack Overflow에만 들락거릴 때에도 영어는 필수이다.
2.2.4. 기타 지식 및 커뮤니케이션 부족
개인정보를 다루는 시스템 등 민감한 시스템을 만드는 경우에는 법률적 지식 및 규제도 어느정도 숙지하고 있어야 한다. 그러나 코더들은 이러한 지식을 곁다리 식으로 취급하기에, 굳이 숙지하려 하지 않는다. 때문에 이런 시스템을 전문적으로 개발하는 업체들은 단순 코더나 신입 프로그래머 보다는 경력이 어느정도 쌓인 개발자를 선호한다. 단순 코더가 이런 업체에 들어갔다가는 회사 자체가 공중분해될 수도 있으며, 어찌 들어갔다 해도 수습 기간은 다시 밟아야 한다.다만 이런 경우는 보통 중소기업에 해당되는 얘기이다. 대기업의 경우 대개 법무를 검토하는 부서가 따로 있기 때문에 일반 프로그래머가 프로그래밍할 때는 그에 걸맞게 분업을 실시하며, 이를 시험하는 부서 역시 그에 맞게 분업을 수행한다. 여의치 않은 경우에는 하청을 줄 수도 있기에 대기업에서 실질적인 개발은 하지 않는 일도 다반사다. 하지만 중소기업의 경우 그럴만한 여력이 되지 않기 때문에, 프로그래머가 법적인 문제까지 모두 검토해야 하는 가능성이 높다.
또한 팀 내 또는 팀 사이의 커뮤니케이션이 제대로 이뤄지지 않는 경우는 분업이 제대로 되지 않을 수 있기에, 이런 경우는 대기업이라고 안심할 수 없게 된다. 분업이 되지 않으면 법률팀에서 요청한 요구사항이 개발팀 프로그래머에 제대로 하달되지 않을 수도 있기 때문에, 결과적으로는 필수 기능의 결여로 인하여 프로그램 자체가 위법 프로그램이 되는 치명적인 문제가 발생할 수 있다. 뿐만 아니라 개발 과정에서는 어떻게든 팀원 교체가 일어나기 마련인데, 이 과정에서 인수인계가 제대로 되지 않으면 코딩 스타일 분쟁 등으로 분업이 실패할 수 있다. 확산성 밀리언아서의 서비스가 종료된 것도, EZ2AC의 음파 크래시 버그도 작업의 인수인계가 제대로 이뤄지지 않은 것이 결정적인 원인이었다.
2.3. 코더가 주로 종사하는 직종
SI 중에서도 하청업체로서 인건비 절감을 통해 이익을 챙기는 속칭 보도방에서 경력을 쌓는다. 하지만 이런 곳에서 쌓은 경력으로는 연봉 높은 곳으로 이직이 안 된다. 잘 풀리더라도 공공기관 인프라 구축을 맡는 SI 중소기업을 못 벗어난다. 또한, 상술했듯 법적 요구사항 등 '고급 요구사항'을 이해하지 못하는 일이 많아 주 활동 영역이 Java 웹 개발(끽해야 전자정부표준프레임워크 등)이나 모바일 웹 개발 위주로 활동이 제한될 수 밖에 없다. 이들은 연봉은 낮지만 버그가 났다 해도 단순 불편사항인 경우가 많기 때문.반면, 상대적으로 연봉이 높으나 버그 하나가 큰 위험으로 이어질 수 있는 업체는 가려고 해도 업계에서 받아주지 않는다. 우선 자동차나 의료장치, 각종 기계들의 제어장치 등을 다루는 업계는 버그 하나로 사람 목숨이 오갈 수 있기에 이런 면에 가장 민감하고, 이 때문에 코더들의 기피현상은 물론이고 업계의 경력직 선호 현상도 심한 편이다. 네카라쿠배나 MAGA 같은 대형 IT업체들도 주 코드가 자바/스프링인 경우가 많긴 하지만, 상술한 업체들에 비해 보안과 개인정보 수집 등 법적 요구사항에 민감한 편이라, 역시 (이러한 부분에 대한 커뮤니케이션도 가능한) 풀스택 수준 개발자를 요구한다. 이들 업체 사이에서 웃돈을 얹어가면서도 개발자를 모시려 하는 현상이 빈번한 것도 이 때문이다.[8] 결국 프로그래밍 자체에 대한 능력과 함께 컴퓨터과학 및 업계와 관련된 고급 지식의 이해가 중요한 것이지, 프레임워크나 언어로 좌우되는 일은 결코 아니다. 프레임워크나 언어를 따지는 개발자가 오히려 코더일 가능성이 높다.
3. 코더라고 비방하는 것도 문제
3.1. 잘못된 직장 때문
이 때는 동료들을 코더라고 비방하는 것보다 이직이 우선이다. 그렇지 않으면 허송세월할 가능성이 매우 높다. 필요하다면 연봉을 좀 낮춰서라도 자가학습이 잘 되는 회사로 가는 것이 더 낫다.먼저, 공부할 시간을 주지 않는 소프트웨어 개발 회사에서 일하고 있다면 SI/SM 외의 일감을 따 올 확률이 거의 없기 때문에 미래가 없다고 봐도 좋다. 현재 진행중인 프로젝트와 관련된 기술 서적을 도서관에서 빌려와 읽는 것마저도 불허하고 '집에서 읽어라' 같은 말을 한다든지 하는 경우다. 하다못해 Baekjoon OJ 같은 곳에서 문제를 풀 시간조차 주지 않는 것도 포함된다.
그리고 특별한 사정[9] 없이 구글을 방화벽에서 차단하고 있는 회사라면 아주 이상한 곳이므로 그만두는 게 좋다. 네이버의 경우는 Stack Overflow로 가는 링크를 제공하지 않는 경우가 많아 어쩔 수 없이 구글을 통해야만 하는데, 이걸 막는 것 자체가 공부할 기회를 안 준다는 의미이다. 게다가 CPU 스펙, 최신 보안 이슈 등의 고급 자료는 구글 검색이 아니면 제공조차 하지 않는 경우가 많은데, 이런 걸 막는 건 그 자체로 '우리 회사는 그 수준에서 남겠다'고 자폭하는 꼴이다. 이런 경우는 가급적 빨리 사직서를 제출하고 다른 곳을 찾아야 한다. 금융권의 경우 보안이라는 명목으로 구글, 네이버, 심지어 개발 툴까지 차단하는 경우가 있다. 개발자 개인의 실력 향상을 생각한다면, 은행과 금융에 관련된 기업은 피해야 한다.
그리고 장비의 성능이 부족해서 성능상 한계에 도달하고 있는데도 회사가 돈드는 게 싫다며 업그레이드를 해 주지 않는다면 그 회사는 발전 가능성이 제한된 곳이니 돈 더 받고 싶으면 이직을 알아보는 게 좋다. 그 회사의 동료들이 실력이 떨어지는 것도 회사가 장비에 돈을 안 쓰기 때문일 것이다. 돈을 아끼는 데만 집중한 나머지 꾸준히 지속적으로 더 큰 돈을 벌 기회를 걷어차고 있는 것이다. IT 개발 부서는 프로그래머의 시간이 곧 돈 버는 수단이다. 예를 들어, 대용량의 컴파일이 필요하면 안정성 높은 ECC 램이 대용량으로 장착되어 있는 워크스테이션을 써야 한다.[10] 그 외에도 요청이 들어와도 대형 모니터를 사주지 않는다든지, 상용 개발 툴 대신 공짜 툴만 쓰라고 강요한다든지, 사내 솔루션 없이 주먹구구식의 해결법을 강요한다면 이런 회사에 속한다. 그리고 이런 회사는 결코 좋은 소프트웨어 회사로 인정받을 수 없으며, 그 민낯은 결국 높은 이직률로 드러난다.
4. 대안 직업
프로그래머라는 직종은 공부를 쉴 수 없는 직종이다. 이것은 단점이 되기도 하지만 장점이 되기도 하는데 중간에 오랫동안 일에서 손을 놓고 있었어도 비교적 단시간의 학습으로 현업 프로그래머와 동등한 실력을 발휘할 수 있는 직종이기도 하기 때문이다. 하지만 그 학습 자체가 뇌 개조를 방불케하는 큰 고통을 수반하는 게 문제다.[11] 그래서 공부를 계속하고 싶지는 않은데 컴퓨터 분야에 종사하고 싶고 코더 소리는 듣고 싶지 않다면 SM 쪽에서 오퍼레이터 직종을 추천한다. 둘은 상하위의 개념은 아니고 동등한 전문성을 갖춘 직업이지만 오퍼레이터는 현장 경험과 순발력을 더 중요하게 보기 때문에 크게 학습을 할 필요는 없지만 이쪽도 전문성을 키우려면 결국 성향에 맞아야 하는 것이 문제.5. 여담
프로그래밍 언어도 인간 언어와 비슷한 면이 있기에, 인간 언어를 못 하는 이유와 유추해서 살펴보면 비슷한 면이 발견된다. 논리력이 부족하고 연습이 부족하면 문법을 외우고 있다 한들 작문, 회화 등에서 유용한 결과물을 내놓지 못한다는 점에서 비슷하다. 자세한 내용은 프로그래밍 언어 항목에 서술되어 있다.[1] 더 심한 멸칭으로는 코드싸개도 있다.[2] 비슷하게 건축 직종도 직종 내의 분야와 전문성에 따라 취급이 천차만별인데 건축 직종에서 막노동자가 최하위급 취급인 것처럼 IT업계에서는 코더가 이에 대응하는 것.[3] 프론트엔드 코더에게서 많이 발생하는 문제이기도한데 게시판을 만들면서 당당하게 하드코딩으로 만들어 비밀번호가 AES나 RSA 등 암호화 없이 DBMS에 적재되도록 한다든가 심지어는 예외처리를 하지 않아 초등학생도 배운 SQL 문법으로 2002년도에 나온 SQL 삽입 공격을 당한다든가... 캡슐화는 집어치우고 정보은닉 대신 대국민 정보 공개를 한다든가... 찾아보면 골때리는 경우가 정말 많다.[4] 자신의 진로와 맞는 방향으로 공부해야한다.[5] 프로그래머가 4시간 공부 4시간 일을 한다는 말이 있는데 상식적으로 4시간 일을 하는 사람에게 8시간 값어치를 매겨줄 기업은 존재하지 않는다. 다시 말해 프로그래머가 살아남기 위해서는 하루 8시간 일 + @의 공부 시간을 투자하는 것은 당연하며, 이는 주말에도 예외가 되지 않는다.[6] 영어사이트라고 해서 수려한 문장이나 구어적 슬랭 표현이 가득한 영미권 국가 유저들이 사용하는 사이트는 아니다. 다만 영어가 링구아 프랑카이므로 프로그래머 커뮤니티에서 다른 언어가 아닌 영어를 사용할 뿐이다.[7] 하다못해 구글 번역기를 돌리더라도 번역이 잘 됐는지는 확인할 수 있어야 한다.[8] 미국에서 개발자 연봉이 억대이니 하는 것도, 실제로는 COPPA 등 법적 요구사항이 매우 까다롭기 때문이다. 알다시피, 미국은 소송 한번 갔다 하면 억대인 경우가 많은 나라이다.[9] 중국 현지 기업에서는 구글 사용이 어렵다. 또 중요한 보안시설에서도 보안 때문에 어렵다.[10] 프로그램에 수정사항이 생길때마다, 그리고 동작을 확인할 때마다 새로 컴파일해서 확인해봐야 하는데 컴파일에만 반나절이 걸리면 어떻게 디버깅을 하겠는가?[11] 심하게는 자신이 학교에서 배울 때는 '절대로 이렇게 하지 말 것'이라고 금지하던 기법을 최신 기술에서는 '가능한 한 이렇게 할 것'이라고 오히려 권장하는 경우도 있다. 예를 들어 Map/Reduce 패턴은 과거에는 금기에 가까운 기술이었다. 또한 학교에서 시험내기 딱 좋은 재귀함수를 주구장창 시험문제로 출제하는 경우가 있는데 실무에서 그런식으로 재귀함수를 남용하면 좋지않다.