-10배 엔지니어가 되는 방법
첨부 '1' |
|
---|
+10배의 엔지니어는 신화일 수 있지만 -10배의 엔지니어는 현실에 존재한다.
-10배의 엔지니어가 되려면 매 주 400시간의 엔지니어링 시간을 낭비하면 된다.
다음 전략들을 조합해보자.
엔지니어 10명의 결과를 무효로 만든다.
개발 단계에서 가능한 최대한 요구사항을 변경한다. 비난을 피하기 위해 처음부터 요구사항을 난독화 한다.
(400시간 짜리) 바쁜 작업을 만든다.
팀에 그것과 비슷한 일을 하게 한다. 일반적인 예로 프리젠테이션, 다이어그램, 티켓관리 등이다. 무의미한 일을 계속 만든다.
(400시간 짜리) 번아웃/턴오버를 만든다.
감사할 줄 모른다. 다른 사람을 탓한다. 혼란을 야기한다. 화를 낸다. 다른 사람들을 초과 근무하게 만든다.
기술 토론에서 10명의 엔지니어를 인질로 잡는다.
엔지니어들이 아이디어를 토론하게 한다. 실용주의보다 우아함을 추구하도록 권장한다. 아무도 결정을 할 권한을 갖지 못하게 한다.
(400시간 짜리) 커뮤니케이션 비용을 더한다.
회의로 일정을 지저분하게 만든다. 눈에 띄지 않게 다른 사람의 시간을 낭비하기 위해, 긴 메시지/문서를 작성하고 가능한 널리 공유한다. 모든 의견을 반기고 참여를 목표로 한다.
10주치 임금을 클라우드 비용으로 낭비한다.
느린 프로그램을 작성한다. DB 인덱스를 사용하지 않는다. 16코어 머신에서 싱글 스레드 프로그램을 실행한다. 멋진 RAM과 GPU를 갖춘 이색적인 하드웨어를 사용한다. 거리낌 없이 RAM/디스크에 데이터를 저장한다. 어떤 것도 압축하지 않는다. 데이터 레이아웃에 신경쓰지 않는다.
쓸모없는 도구를 만든다.
기존 솔루션이 필요하지 않다고 결정한다. 한 사람만 이해할 수 있는 스크립트를 작성한다. 그 스크립트가 뭔가 중요한 작업을 한다면 문서화 하지 않는다.
(400시간 짜리) 컴파일/빌드 시간을 더한다.
느린 빌드는 시간을 낭비하고 그 시간의 복리 계산을 초래한다. 빌드 시간이 길어지면 개발자들은 주의가 분산될 수 있다. 개발자들이 컨텍스트로 다시 돌아오려면 최소 20초가 소요된다. 느린 테스트 코드를 작성해서 비슷한 효과를 낼 수도 있다.
무의미한 테스트를 작성한다.
기본 기능을 테스트하지 않고 특정 변수에 대한 종속성을 만든다. 원래의 코드가 실행되지 않을 때 까지 목업 함수를 호출한다. 이유 없이 성공/실패 하도록 테스트 코드에 미묘한 랜덤값을 적용한다.
잘못된 아키텍처에 400시간의 엔지니어링을 낭비한다.
시간이 지나면서 시스템 설계가 어떻게 발전할 것인지 전혀 고려하지 않는다. 아니면 팀이 그들의 가설을 테스트할 시간이 부족하도록 아키텍쳐 결정에 집착하게 유도한다.
배포에 400시간을 낭비한다.
가능한 많은 환경을 만든다. 프로덕션 환경과 스테이징 환경은 크게 달라야 한다. 취약한 빌드 시스템으로 취약한 코드를 실행한다. 데이터베이스를 자주 마이그레이션 한다.
10주치 임금을 불만 고객에게 낭비한다.
심각한 버그를 찾아내고 해결하는 것에 계속 실패한다. 보안 취약점에는 신경쓰지 않는다.
쓸모없는 문서를 작성한다.
개인 메시지로 코드를 설명한다. 아무도 사용하지 않는 위키문서를 작성한다.
쓸모없는 연구개발 프로젝트에 10명의 엔지니어를 잡아둔다.
유능한 엔지니어를 데려와서 잠재력을 낭비한다. 경영진에게 프로젝트의 난이도는 축소해서 말하고 유용함은 과장해서 말한다. 경영진이 프로젝트를 폐기하기 전 까지 "거의 완료"라고 말한다.
유지보수를 위해 400시간짜리 종속성을 추가한다.
엔지니어들은 각 라이브러리를 개별적으로 학습하면서 시간을 낭비하게 한다.
상황 전환을 지연한다.
절대로 실패를 인정하지 않는다. 팀을 그 매몰비용에 빠뜨린다. 상황을 개선할 수 있는 80/20 법칙을 무시한다.
10명의 0x 엔지니어를 고용한다.
기회비용은 치명적일 수 있다. 무능한 엔지니어는 팀에 직접적으로 피해를 주지 않지만, 팀에 도움이 되는 다른 사람의 자리를 차지하게 된다.
5명의 -1x 엔지니어를 고용한다.
무능한 엔지니어를 고용한 것으로 안심하지 않는다. 재앙을 일으키고 학습하지 않는 엔지니어를 적극적으로 고용한다.
10명의 -1x 엔지니어가 해고되는 것을 방지한다.
그들에 대해 문제를 일으키지 않는다. 실패의 흔적은 서면으로 남기지 않는다. 잘못된 엔지니어링을 보증 해준다.
400시간 동안 버그를 분류한다.
디버깅할 수 없는 프로그램을 만든다. 모든 것에 추상화 레이어를 반죽한다. 스파게티 코드를 작성한다. 모든 것을 초기 조건에서만 잘 동작하도록 예민하게 만든다. 순수 함수를 사용하지 않는다. 거리낌 없이 종속성을 만들어 낸다. 언제나 "내 머신에서는 잘 된다."라고 말한다.
[원문] https://taylor.town/-10x
-
가르치는 역할이 중요한 이유
지금 생각해보면 학창 시절 말도 안되는 선생이 많았던 것 같다. (선생님이라고 할 수도 없기에..) 정답이 5번이라 함 ㅋㅋㅋ 그리고 이건 저 문제 패러디.. - Read More
-
박종진의 쾌도난마 (변희재의 킬링타임; 안철수)
#헛웃음 유발 안철수의 거짓말 토크 # 박종진의 쾌도난마 (변희재의 킬링타임) - 헛웃음 유발 안철수의 거짓말 토크1 # 박종진의 쾌도난마 (변희재의 킬링타임) - 헛웃음 유발 안철수의 거짓말 토크2 -
아프리카 어느 소녀의 시
태어날 때 내 피부는 검은색 When I born, I Black 자라서도 검은색 When I grow up, I Black 태양 아래 있어도 검은색 When I go in sun, I Black 무서울 때도 검은색 When I scared, I Black 아플 때도 검은색 When I sick, I Black 죽을 때도 나는 여전히 ... -
우리 아빠가 이렇게 대단한 사람인줄 몰랐어요
MS-DOS 시절 M쉘을 만들었던 최정한 지금 봐도 정말 대단하다!! ㅎㅎ - Read More
-
얀테의 법칙
얀테의 법칙은 북유럽사람이 삶을 살아가는 사회규범, 관습이자 불문율 같은 삶의 철학이다. 덴마크계 노르웨이 작가인 악셀 산데모세가 1933년에 쓴 소설 '도망자'에 등장하는 가상마을 '얀테'를 소개하면서 지어진 법칙이다. 악셀 산데모세는 10가지 규칙을... -
-10배 엔지니어가 되는 방법
+10배의 엔지니어는 신화일 수 있지만 -10배의 엔지니어는 현실에 존재한다. -10배의 엔지니어가 되려면 매 주 400시간의 엔지니어링 시간을 낭비하면 된다. 다음 전략들을 조합해보자. 엔지니어 10명의 결과를 무효로 만든다. 개발 단계에서 가능한 최대한 ... -
인간관계 칼 같은 사람 특징
01. 쓸데없는 감정소모 하기 싫어함 02. 자신만의 관계의 정해진 선이 있음 03. 몇 번의 신호를 보내지만 알아차리지 못하면 바로 손절 04. 배려없이 막말하는 사람 이해 불가 05. 알면 알수록 괜찮은 사람 보다 처음부터 괜찮은 사람을 원함 06. 이미 충분히... - Read More
-
[인포그래픽] 한국 O2O의 모든 것
쉬운 일은 아니었습니다. 130여곳의 국내 O2O 스타트업을 업태에 맞게 인포그래픽으로 정리하는 것은 엄청난 노력이 필요하기 때문입니다. 그래픽에 들어가는 관련 스타트업의 정보 대부분은 IoT전략연구소 김학용 소장(순천향대 IoT보안연구센터 교수)의 ‘분... -
행복은 스스로 만드는 것.
너 그거 어디서 찾았어? 나 계속 찾아 다니고 있는데.. 내가 직접 만들었어!