프로그래머를 존중하는 방법을 배우십시오

IT인터넷이런 회사 사람들에 대한 무례함은 전문가뿐만 아니라 모든 프로그래머에게 해당됩니다. 전문가들은 많은 것을 보아도 전혀 놀라지 않기 때문에 일반적으로 피상적인 것을 사용하여 자신을 강조하는 것을 좋아하지 않습니다. 그러나 바로 그 겸손함 때문에 지식이 부족한 사람들의 공격 대상이 되기 쉽습니다. 이 무례한 현상의 보편성과 극도로 해로운 성격으로 인해 이에 대해 구체적으로 이야기할 필요가 있다고 생각합니다. 다음에서는 IT 업계에서 사람을 무시하는 문화의 근원을 지적하는 동시에 프로그래머를 진정으로 존중하는 방법을 사람들에게 알려주는 몇 가지 제안을 하고자 합니다. 이 제안들이 회사 경영에 참고가 되기를 바라며, 같은 아픔을 겪고 있는 프로그래머들에게 조금이나마 영적인 격려가 되기를 바랍니다.

프로그래머를 존중할 줄 아는 기업 문화는 항상 다음 사항에 주의해야 한다고 생각합니다.

남은 역사적 문제를 인정합니다. 컴퓨터 시스템에서

컴퓨터 과학을 어느 정도 이해하면 우리는 실제로 아직도 컴퓨터 석기 시대에 살고 있다는 것을 알게 될 것입니다. 특히 소프트웨어 시스템은 역사에서 남겨진 수많은 잘못된 설계를 기반으로 구축되었습니다. 제대로 설계되지 않은 다양한 운영 체제(예: Unix, Linux), 프로그래밍 언어(예: C++), 데이터베이스 등... 종종 우리를 괴롭힙니다. 이것이 소위 '경험'이 왜 그렇게 많이 필요한가입니다. 그러나 많은 IT 회사에서는 이를 인정하지 않습니다. "모든 것은 프로그래머의 잘못입니다!", "프로그래머로서 이것을 알아야 합니다!"라는 태도가 있습니다. "황제의 새 옷 현상": 모든 사람들은 잘못 설계된 도구를 사용하는 것을 좋아하지 않지만 다른 사람들이 자신의 능력을 비웃거나 의심할 것을 두려워하므로 누구도 감히 디자이너의 실수를 지적하지 않습니다.

저는 이러한 '해커 문화'의 반례입니다. 누군가가 특정 도구나 언어를 모른다고 나에게 조언을 요청할 때마다 나는 항상 도구 설계자를 쉽게 비웃으며 그에게 이런 쓰레기를 알 이유가 없지만 그게 전부라고 말합니다. 그런 다음 나는 그에게 이것이 무엇인지, 어떻게 사용하는지, 그리고 어떤 디자인 결함이 지금 우리의 이상한 사용법을 초래하는지에 대해 직접 설명했습니다. 모든 IT 실무자는 이러한 도구를 이렇게 취급해야 한다고 생각합니다. 태도. 그래야만 소프트웨어 산업이 잘못된 설계로 인해 어려움을 겪고 정신적인 족쇄를 겪는 대신 실질적인 발전을 이룰 수 있습니다.

간단히 말하면 매우 중요한 '태도의 문제'입니다. 이 단계에서는 잘못 설계된 일부 도구를 우회하고 이를 사용하여 작업을 완료하는 방법을 알아야 합니다. 그러나 동시에 우리는 이러한 도구를 교리로 취급하고 프로그래머를 비난하기보다는 이러한 도구의 나쁜 특성을 직시하고 인정해야 합니다. 이런 방법으로만 우리는 프로그래머의 지능을 효과적으로 존중할 수 있습니다.

필수 지식과 피상적 지식을 구분하고, '경험'을 너무 심각하게 여기지 마세요

IT기업 그런 사람들은 겉보기에 복잡해 보이는 명령줄이나 사용하기 어려운 프로그래밍 언어에 능숙하다는 것이 훌륭하다고 생각하는 경우가 많습니다. 이 사람들은 주변 동료 중 일부가 실제로 지식의 본질을 소유하고 있다는 사실을 깨닫지 못했습니다. 그들은 이러한 모든 도구를 기존 지식에서 파생할 수 있고(단순히 사용하는 것이 아니라) 심지어 더 완전하고 편리하며 설계할 수도 있습니다. 사용하기 쉽습니다. 더 나은 도구를 설계하고 제작할 수 있는 사람들은 더 중요한 업무를 맡는 경우가 많기 때문에 기존 도구의 사용으로 인해 혼란스러울 때 동료에게 문제 해결을 도와달라고 매우 겸손하게 요청하고 자신의 혼란을 대담하게 인정합니다.

도구 사용에 능숙한 사람이라면 동료의 겸손한 요청을 자신의 '자격'을 과시하는 시간으로 여기면 안 됩니다. 이 동료는 정말 "부끄러움 없이 질문하는" 경우가 많습니다. 그가 "이해하지 못하는 것"이 ​​아니라, 단순히 관심이 없고 그러한 낮은 수준의 문제에 대해 생각할 시간이 없다는 것입니다. 그의 혼란은 종종 도구 설계자의 실수에서 비롯됩니다. 그는 이 사실을 잘 알고 있지만 예의상 도구의 디자인을 직접적으로 비난하지 않고 겸손하게 자신을 비난하는 경우가 많습니다. 따라서 동료들이 당신에게 "겸손하게 조언을 구하는 것"은 순전히 친절하고 조화로운 분위기를 조성하여 정말로 중요한 일을 하는 데 시간을 절약할 수 있다는 것입니다. 이런 겸손은 그가 당신을 숭배하고 그의 기술적 능력이 당신만큼 좋지 않다는 것을 인정한다는 것을 의미하지 않습니다.

따라서 이러한 혼란에 대한 이해를 진심으로 표현하고, 도구 설계의 불합리하고 허술한 측면을 솔직하게 인정하는 것이 올바른 대처 방법입니다. 당신이 전문가라고 생각하는 대신 이런 겸손한 태도를 취할 수 있다면, 당신의 동료들은 당신에게서 필요한 피상적인 지식을 기꺼이 "배우고" 다음 번에 이런 일을 하지 않도록 기억할 것입니다. 귀찮게 해. "이 놀라운 기술을 아는 사람은 세상에서 나뿐이다"라는 태도를 취하면 동료들은 종종 당신과 그 도구를 경멸할 것입니다. 그는 다음 번에도 이 물건을 어떻게 사용하는지 기억하지 못할 것이지만, 다시는 당신에게 도움을 청하러 오지 않을 것이고, 계속해서 그것을 미루게 될 것입니다.

명령어를 사용하지 말고 의도를 설명하세요

동료와 부하 직원은 노예도 아니고 코드몽키도 아니며, 당신을 위해 일할 필요도 없다는 점을 항상 기억하세요! 그들은 합리적인 사람들이지만 돈을 받는다고 해서 단순히 낮은 수준의 명령에 복종하지는 않을 것입니다. Google의 팀원들이 한 일은 좋은 부정적인 예입니다. 사실 이 구글러는 그냥 "이 줄을 삭제하고 이걸로 바꾸세요..."라고 말하고 싶었을 뿐인데, 이 "고급 의도"를 직접적으로 밝히지는 않고 매우 낮은 수준으로 사용했습니다. -수준의 지시: "Ctrl-k를 누르세요!..." 그리고 그 말투는 마치 무식한 초등학생에게 말하는 것 같았습니다.

Emacs 사용자 중 Ctrl-k가 텍스트 한 줄을 삭제한다는 사실을 모르는 사람이 있을까요? 실제로 Emacs 선배이자 세계적 수준의 Lisp 프로그래머를 상대하고 있습니다. 나는 모두가 여기서 문제를 볼 수 있다고 생각합니다. 이러한 낮은 수준의 명령은 논리가 불분명할 뿐만 아니라 공격적이기도 합니다. 내가 어떤 사람이라고 생각하세요? 코드몽키? 이 구글러가 자신의 높은 수준의 의도를 표현하면 다른 사람들도 심리적, 논리적으로 쉽게 받아들일 수 있을 것입니다. 예를 들어 "구성 파일에서 이 줄을 삭제하고 다음과 같이 변경해야 합니다. ."

프로젝트 관리의 다른 경우에도 유사한 기술을 사용할 수 있습니다. 사람들에게 어떤 일을 하라고 하기 전에 먼저 그 일을 하고 싶은 이유와 그 중요성을 설명하여 사람들이 이해할 수 있도록 해야 합니다. 그래야만 프로그래머의 IQ를 존중할 수 있습니다. 프로그래머는 인간이고 명령에만 복종하는 코드 원숭이가 아니기 때문입니다.

신입생이 당신에게서 배울 것을 기대하지 마세요

많은 IT 회사는 신입생을 초보자처럼 대하고 기대하는 것을 좋아합니다. 스스로 공부하도록 하라." 예를 들어 구글은 신입사원을 모두 "누글러"(새내기 구글러라는 뜻)라고 부르고, 심지어 텔이라는 뜻의 특별한 프로펠러 모자까지 준다. 아이들이 미래에 번영할 수 있도록 "위대한 구글"에게 겸손하고 배워야 한다는 점입니다.

이것은 사실 매우 잘못된 접근 방식입니다. 신입사원의 기존 배경 지식을 무시하고 "위대한 Google"의 권위에 굴복하게 만드는 것입니다. 눈에 띄지 않는 나사. 사실 구글에는 배울 만한 게 정말 많나요? 학교교육은 정말 무가치한 것인가? 그렇지 않습니다. 저는 교수님들로부터 가장 필수적인 지식을 배웠다고 솔직하게 말할 수 있습니다. 나는 구글에게서 그 어떤 기술도 배우지 않았고, 그 대신 그 어떤 구글러도 상상하지 못했던 세계 최고의 기술을 구글에게 전수했다. . 많은 박사 학생들이 Google을 경멸하는 이유는 Google이 자체 기술을 망칠 뿐만 아니라 다른 회사와 모든 학교를 능가하는 가장 발전된 제품으로 포장하기 때문입니다. 그리고 다른 사람들이 그들로부터 "배우기"를 오만하게 기대합니다.

무작정 스스로 '배우기'를 기대하는 것이 아니라, 외부 세계에서 온 신인들이 가져온 특별한 기술을 이해하고, 존중하고, 활용하고, 그들의 고유한 강점을 발휘해야만 이러한 예리한 인재들이 성공할 수 있습니다. 무기는 유지됩니다. 날카로운 모서리와 모서리는 회사를 무적으로 만듭니다.

프로그래머의 작업량은 시간으로 측정할 수 없습니다

많은 IT 회사 경영진이 프로그래머를 추정하는 방법을 모릅니다. 작업량. 당신이 매우 능력이 있고 짧은 시간 안에 가장 어려운 문제를 해결한다면 그들은 당신을 가만히 두지 않고 다른 낮은 수준의 작업을 수행하도록 요청할 것입니다. 이는 매우 불합리한 접근 방식입니다. 예를 들어 능력이 뛰어난 직원은 F1 경주용 자동차와 같으며 다른 직원보다 수십 배의 마력과 속도를 가지고 있습니다. 물론 평범한 사람들이 해결하는 데 오랜 시간이 걸리거나 전혀 해결이 불가능한 문제도 그의 손에서 빠르게 해결되었습니다. 남들이 보면 오랜 시간이 걸리는 거리를 눈 깜짝할 사이에 주파할 수 있는 F1 경주용 자동차와도 같습니다. 시간별로 작업량을 측정하면 F1 자동차가 거리를 완료하는 데 걸리는 시간이 짧기 때문에 계산하는 작업량은 일반 자동차에 비해 훨씬 적습니다. 그렇다면 F1이 자동차에서 충분히 열심히 일하지 않고, 가능한 한 빨리 더 열심히 일하기를 원한다고 말할 수 있습니까? 이것은 분명히 잘못된 것입니다.

물리 법칙은 에너지 = 전력 x 시간입니다. 작업량도 같은 방식으로 계산해야 합니다. 프로그래머를 진정으로 이해하는 현명한 기업은 수준 높은 프로그래머가 쉬지 않고 일하기를 기대하지 않습니다. 높은 수준의 프로그래머는 종종 새로운 방법을 찾을 수 있기 때문에 한 사람이 여러 명의 일반 프로그래머보다 가치가 있을 수 있습니다. 그들이 다루는 문제는 일반 사람들보다 훨씬 더 어렵고 더 많은 정신적 에너지를 필요로 합니다. 물론 더 나은 휴식, 유지, 오락 등이 필요합니다...

물론 그렇지 않습니다. 주니어 프로그래머들이 과로를 해야 한다는 뜻이다. 프로그래밍은 힘든 정신적 활동이며, 과도한 작업과 압박감은 효율성을 저하시키고 품질을 저하시킬 뿐입니다.

다른 사람이 스스로 고치도록 두지 마세요 버그

관련 기사에서 이에 대해 논의한 적이 있습니다. 한 프로그래머에게 다른 프로그래머의 BUG를 고치도록 하는 것은 비효율적일 뿐만 아니라 프로그래머의 개인적 가치를 무시하는 것이므로 가능한 한 피해야 합니다. 누군가가 회사를 떠나고 누군가가 남긴 BUG를 고쳐야 한다면, 특히 말을 조심해야 합니다. 그 사람의 도움이 필요한 특별한 이유를 구체적으로 지적해야 하며, 이 문제는 애초에 그 사람의 문제가 아니며, 애초에 그렇게 하지 말았어야 했는데 누군가가 떠났고 다른 방법이 없다는 점을 강조해야 하며, 그리고 이런 일이 일어난 것에 대해 진심으로 사과드립니다.

이런 방식으로만 프로그래머가 이 드물고 특별한 순간에 다른 사람의 버그를 기꺼이 수정할 수 있습니다.

무료로 받기 LAMPBand of Brothers원본PHP동영상 튜토리얼 CD/"PHP에 대한 자세한 내용" Essential Edition, 공식 홈페이지 고객센터로 문의주세요 자세한 내용은

http://www.lampbrother.net

PHPCMS2차 개발http://yun .itxdl.cn/online/phpcms/index.php?u=5

WeChat 개발 http://yun.itxdl. cn/online/weixin/ index.php?u=5

모바일 인터넷 서버측 개발 http://yun.itxdl.cn/online/server /index.php?u= 5

자바스크립트강좌 http://yun.itxdl.cn/online/js/index. php?u=5

CTO교육 캠프 http://yun.itxdl.cn/online/cto/index.php? u=5

이상에서는 프로그래머를 존중하는 법을 배우는 방법을 그 내용과 함께 소개했습니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.