Dev here with 25+ years experience in big enterprise companies and small spunky startups in Silicon Valley. Currently a senior director at a company you’ve heard of. I used to think that if your code wasn’t perfectly linted, had 100% unit test coverage, every E2E UX case covered - basically follow all the things you are taught as a young programmer - that you were a shitty programmer and should maybe be fired. We prioritize this stuff, but really it means almost nothing. At the end of the day nobody but a very small group of people, other developers, care about the things we would find someone and stab them in their sleep over (e.g.: tabs vs. spaces). The real key to success in this industry is this: think like a normal person that isn’t enveloped in programming. Don’t call yourself a programmer no matter how cool it makes you feel. Everyone else thinks of it as “plumber” unfortunately. Highly paid, self absorbed plumbers is all we are to the vast majority of the public. Not the data structure oracle math god that we wish we were viewed as. If you can prioritize the things that your customers want you will be successful. That is almost never enforcing tabs vs. spaces. So when I see a eldritch horror like this that is successful software, it really makes me envious of this particular block of code. If only I had spent more time making a cool game than worrying about my module loader patterns and what state management solution I created. Maybe then I would have something to show for all my effort other than my current job. Looking at this barf wasn’t programming horror, it was a programming honor. 

실리콘밸리의 대기업과 작고 활기찬 스타트업에서 25년 넘게 일해온 개발자입니다. 현재는 누구나 알만한 회사에서 시니어 디렉터로 일하고 있습니다.

예전에는 코드가 완벽하게 린팅(linting)되지 않았거나, 100% 유닛 테스트 커버리지를 갖추지 못했거나, 모든 E2E(End-to-End) UX 시나리오를 커버하지 못한다면, 기본적으로 당신은 형편없는 개발자이고, 아마 해고당해야 한다고 생각했었죠.

우리는 이런 것들을 우선시합니다. 하지만 솔직히 말해, 이런 것들은 거의 아무 의미도 없습니다.

결국, 이런 것에 신경 쓰는 사람은 극히 적은 개발자들뿐입니다. 우리가 탭(tab)과 스페이스(space) 문제로 밤에 찾아가서 찌를 만큼 민감하게 여기는 것들은 사실 대다수의 사람들에게 전혀 중요하지 않습니다.

이 업계에서 성공의 진짜 핵심은 이것입니다: 프로그래밍에 사로잡힌 사람이 아니라, 보통 사람처럼 생각하라.

그리고 프로그래머라는 이름을 자랑스럽게 붙이지 마세요. 아무리 멋지게 느껴진다 하더라도요. 세상 사람들은 프로그래머를 그냥 "배관공" 정도로 생각합니다.

안타깝게도요. 높은 연봉을 받는, 자기중심적인 배관공.

사람들이 우리를 바라보는 시선은 데이터 구조를 통달한 수학의 신 같은 게 아닙니다. 우리가 그렇게 보이길 바랄지라도 말이죠.

만약 고객들이 원하는 것에 우선순위를 둘 수 있다면, 당신은 성공할 겁니다.

그리고 그 우선순위는 절대 탭(tab)이나 스페이스(space)를 강제하는 일이 아닙니다.

그래서 이런 "엘드리치 호러" 같은 코드를 성공적인 소프트웨어로 볼 때, 솔직히 부럽기까지 합니다.

내가 모듈 로더 패턴이나 내가 만든 상태 관리 솔루션에 대해 고민하느라 시간을 낭비하지 않고, 멋진 게임을 만드는 데 더 많은 시간을 썼다면 어땠을까 싶습니다.

그랬다면 지금 내 노력의 결과물로 현재 직업 외에 뭔가 더 보여줄 수 있는 게 있었을지도 모르죠.

이 "토사물" 같은 코드를 보면서, 나는 프로그래밍의 공포가 아니라 프로그래밍의 영광을 느낍니다.

---

언더테일 게임 코드에 대해서 사람들이 별로라고 말할때 어느 25년차 프로그래머가 말한건데

이거 번역한 후에 인쇄한 후에, 항상 포기하고 싶을때 읽어봄.