소식

제작사 |새로운 프로그래머"편집부

함수형 프로그래밍은 단순한 "함수를 사용한 프로그래밍" 그 이상입니다. 함수형 프로그래밍은 할당문 없이 프로그래밍하는 것입니다.

할당문 없이 프로그래밍을 시도하면 함수형 프로그래밍의 다른 모든 기능이 제대로 작동됩니다. 함수를 다루려면 재귀를 사용해야 합니다. 이 모든 것은 값을 할당하지 않기로 결정한 순간 자연스럽게 발생합니다. 이것이 함수형 프로그래밍의 전부입니다.

——"기능적 디자인", 로버트 c. 마틴

50년 이상의 코딩 경력

"신입 프로그래머": 인터뷰에 앞서 간단한 자기소개 부탁드립니다.

밥 삼촌:그렇습니다. 제 이름은 bob martin입니다. 어떤 사람들은 저를 bob 삼촌이라고 부릅니다. 저는 오랫동안 프로그래머였습니다.50년 이상.제가 처음 프로그래밍을 시작했을 때 컴퓨터는 넓은 방을 가득 채울 만큼 크고 가격이 수백만 달러에 달했습니다.

저는 다양한 프로그래밍 언어를 사용해 보았습니다.어셈블리 언어, cobol, fortran, pl/i, c, c++, pascal, java, c#기다리다. 수년에 걸쳐 저는 금융 시스템부터 임베디드 실시간 시스템 및 프로세스 제어 시스템에 이르는 다양한 시스템 개발에 참여해 왔습니다. 그러므로 나는 이 업계에서 광범위한 경험을 가지고 있다고 말할 수 있습니다.

또한 저는 clean code(클린 코드), "건축을 깨끗하게 하는 길"(클린 아키텍처), 그리고 오늘 우리가 토론하고 있는 책은 "기능적인 디자인》（기능적 디자인）。

"신입 프로그래머"：책을 쓰는 것 외에 여가 시간에는 무엇을 하시나요? 그런데 나는 종종 당신의 트위터를 읽었고 당신의 트윗 중 약 50%가 미국 선거와 트럼프에 대한 소셜 뉴스이고 나머지 50%는 기술 콘텐츠, 프로그래밍 및 코드에 대한 견해에 관한 것임을 발견했습니다.

밥 삼촌：물론. 선거가 없는 해에는 내 트윗의 약 90%가 소프트웨어에 관한 것입니다. 하지만 올해는 선거가 있는 해이기 때문에 다른 주제를 다루는 콘텐츠가 더 많습니다. 책을 쓰거나 프로그래밍을 하지 않을 때에는 많은 일을 합니다. 나는 자전거를 타고 여기저기 여행하는 것을 좋아합니다. 나는 또한 조종사이고 내 비행기를 타고 날아다니는 것을 정말 좋아합니다. 나는 대가족이 있다네 명의 자녀와 열 명의 손주., 저는 보통 가능한 한 많이 방문하기 때문에 시간이 매우 넉넉하게 정리되어 있습니다.

"신입 프로그래머": 프로그래밍 경력의 시작점으로 돌아가서 1970년에 프로그래머로 일을 시작했던 이야기를 들려주세요. 당시 18살이었는데, 처음 배운 언어는 어셈블리와 cobol이었는데, 처음 시작했을 때의 경험에 대해 이야기해 주실 수 있나요?

밥 삼촌: 글쎄요, 그 당시에는 대학 강좌가 많지 않았어요. 나는 당시 학교에 전혀 관심이 없었다. 당시 베트남 전쟁이 격화되어 캠퍼스에는 폭동과 불안이 컸습니다. 그리고,저는 컴퓨터 프로그래밍에 대해 많은 것을 배웠고, cobol과 fortran, 심지어 여러 컴퓨터 어셈블리 언어도 배웠습니다. 그래서 굳이 대학에 갈 필요는 없을 것 같아요。

내 프로그래밍 경력은 내가 12살이었을 때 어머니가 나에게 작은 플라스틱 컴퓨터를 사주면서 시작되었습니다. 그 장난감에는 3개의 플립플롭과 6개의 and 게이트가 있으며, 이를 작동하려면 작은 레버를 돌려야 합니다. 내부에 있는 일부 고무줄과 레버가 부품을 움직여 0부터 7까지 계산하는 등 간단한 계산을 할 수 있습니다. 7부터 7까지 센다. 카운트가 0으로 돌아간다. 또한 두 개의 비트를 추가하여 합계 비트와 캐리 비트를 생성하도록 프로그래밍할 수도 있습니다. 나는 그것에 많은 흥미로운 프로그램을 작성했습니다. 프로그래밍 프로세스는 래치에 삽입된 작은 튜브를 추가하는 것입니다. 막대가 슬롯에 들어가는 것을 방지하여 방아쇠 상태를 변경합니다.

그래서 저는 몇 주 동안 그 장난감 컴퓨터를 작동시키는 방법을 배웠고, 그 과정을 통해 저는 프로그래머가 되었습니다.나는 그때부터 프로그래머였어。

그것이 나의 출발점이었고, 아버지는 나에게 최대한 많은 정보를 주기 위해 컴퓨터와 프로그래밍 언어에 관한 책을 많이 사셨습니다. 그러다가 16세에 honeywell 200용 프로그램을 작성하는 프로그래밍 직업을 얻었습니다. 그 일은 2~3주 정도 지속됐어요.아직은 소년일 뿐이야, 여름방학 때 했었는데 너무 재미있었어요.

약 2년 후, 제가 18세가 되었을 때 저는 ibm 360용 어셈블리 언어와 cobol을 작성하는 정규직을 얻었습니다. 얼마 지나지 않아 나는 어셈블리 언어로 많은 마이크로컴퓨터를 프로그래밍하기 시작했습니다. 이들 컴퓨터가 varian corporation에서 생산될 당시에는 많은 회사들이 마이크로컴퓨터를 제작하고 있었지만 성공한 사례는 거의 없었고, 그 분야를 장악한 것은 digital equipment corporation(dec)이었습니다. 그 후 나는 1970년대 초에 생산된 장치인 pdp 8과 pdp 11을 프로그래밍하는 데 매우 능숙해졌습니다.

"신입 프로그래머": 1970년대는 world wide web이 아직 발명되지 않았고 usenet이 막 발명된 시기였습니다.나타나다. 귀하는 세계 최초의 usenet 사용자 중 한 명이며, "밥 삼촌"이라는 별명은 원래 회사 동료가 귀하에게 붙인 별명이라는 것도 알게 되었습니다. 나중에 귀하는 실수로 이 별명을 usenet의 서명으로 사용했으며 결국 이름이 별명에서 실명으로 성공적으로 변경되었습니다. 이야기를 공유해 주실 수 있나요?

밥 삼촌: 저는 클리어커뮤니케이션이라는 스타트업에서 일하고 있었는데, 그것이 제 경력의 시작이었습니다.네 번째 정류장1987년에서 1989년 사이의 어느 날. 거기서 동료가 모두에게 별명을 붙여줬는데, 내 별명은 "밥 삼촌"이었습니다. 처음에는 그가 항상 저에게 "밥 삼촌, 이건 어때요?" "밥 삼촌, 저건 어때요?"라는 별명으로 저를 부르며 돌아다니기 때문에 조금 짜증이 났습니다.

나는 그 회사를 떠나 컨설턴트가 되었고, 더 이상 나를 '밥 삼촌'이라고 부르는 사람은 아무도 없었다. 알고 보니 제목을 좀 놓쳐서 이메일 서명에 제목을 추가하는 실수를 저질렀습니다.

나는 당시 usenet에서 매우 활동적이었고 종종 comp.object 및 comp.lang.c++와 같은 뉴스 그룹에 기사를 게시했으며 사람들은 내 서명에서 "uncle bob"을 발견하기 시작했습니다. 아마도 1990년쯤에 c++ 컨퍼런스에 참석했을 때 누군가가 복도 건너편에서 저를 가리키며 "보세요, 저 사람 밥 삼촌이군요!"라고 말했습니다. 저는 이런 생각이 들었습니다. 실수를 했네요. - 그런데 'uncle bob'이 정말 좋은 브랜드라는 걸 깨닫고 그대로 두게 됐어요.

"신입 프로그래머": usenet은 귀하가 참여하는 최초의 소셜 미디어라고 할 수 있습니다. 많은 전설적인 개발자들처럼 당신도 다양한 커뮤니티나 포럼에 참여하는 것을 좋아합니다. 해시노트에 "저는 로버트 마틴입니다. 저에게 질문을 하셔도 좋습니다."라고 게시하신 것을 본 적이 있습니다. 대화. 이제 그 소통은 주로 트위터에서 이뤄지고 있는 것 같습니다.

밥 삼촌:오른쪽,지저귀다이제 나의 주요 소셜 미디어. 저는 facebook도 사용하지만 주로 가족이나 친구들과 연락을 유지하기 위해 사용합니다.

"신입 프로그래머": 처음에는 c와 c++에 매력을 느꼈지만, snobol, focal, alcom, basic 등의 언어도 흥미로 써봤다고도 하더군요. "흥미롭다"고 할 수 있는 다른 프로그래밍 언어는 무엇이라고 생각하시나요? 특히 최근 몇 년간 등장한 새로운 프로그래밍 언어 중에서 어떤 언어에 흥미를 느끼시나요?

밥 삼촌: 현재 내가 가장 흥미롭게 생각하는 언어는 다음과 같습니다.클로저, 학습에 많은 시간을 투자한 언어입니다. clojure가 실제로 있기 때문에 놀랐습니다.리스프내가 배우게 될 거라고는 전혀 생각하지 못했던 lisp의 방언.

내 경력의 첫 30년 동안 나는 lisp를 배울 생각을 전혀 하지 않았습니다. 왜냐하면 lisp가 끔찍한 언어라고 생각했기 때문입니다. 물론 나는 lisp를 전혀 이해하지 못했기 때문입니다. 어느 날 『컴퓨터 프로그램의 구조와 해석』이라는 책을 읽게 되었는데, 그 책에 사용된 언어가 바로 나를 매료시켰습니다. 갑자기 나는 lisp의 열렬한 팬이 되었습니다. 나는 a를 찾고 싶다일상 생활에서 lisp를 사용하는 방법, 그래서 클로저를 만났습니다.

클로저와 동등한jvm(java virtual machine)에서 실행될 수 있는 lisp 방언, 그것은 나에게 완벽했기 때문에 clojure 코딩을 배우기 시작했고 재미있게 하면서 나에게 큰 오락이었습니다.

기계가 인간처럼 생각하면 프로그래밍 기술은 쓸모 없게 될 것입니다

"신입 프로그래머": ai 코드에 대한 이전 의견 중 일부를 이해합니다. 귀하의 의견으로는 대규모 언어 모델이 좋을 때도 있고 어리석을 때도 있습니다. ai의 코드 설명이 약간 도움이 되었지만 여전히 맹목적으로 신뢰해서는 안 된다고 말씀하셨습니다.

밥 삼촌: 응, 프로그래머야copilot과 같은 도구에 지나치게 의존하고 도구가 생성하는 코드를 보고 무비판적으로 받아들이는 것은 위험합니다. 비판적이어야 하며 이 코드 중 일부는 괜찮지만 대부분의 경우 ai 생성 코드에 매우 주의해야 합니다. 그래서 내 제안은,조심하고, 도구처럼 사용하고, 도구를 잘못 사용하면 해를 끼칠 수 있다는 점을 항상 기억하세요.

"신입 프로그래머": 그렇다면 이제 막 배우기 시작한 프로그래머들은 ai를 어떻게 활용해 성장해야 할까요? 나는 인터뷰에서 완전히 다른 두 가지 견해를 들었습니다. 하나는 초보 프로그래머가 ai를 완전히 수용해야 한다는 것이고, 다른 하나는 ai 코드의 품질을 판단할 능력이 없기 때문에 ai가 주니어 프로그래머를 파괴할 것이라는 것입니다.

밥 삼촌: 후배 조종사가 자동 조종 장치를 사용하면 안 되는 것처럼.먼저 비행기 조종 방법을 익힌 다음 세부 사항에 주의를 기울일 필요가 없을 때 자동 조종 장치를 사용하십시오. ai의 경우에도 마찬가지이다.주니어 프로그래머는 출력 코드의 품질을 판단하는 방법을 아직 모르기 때문에 처음부터 ai에 의존해서는 안됩니다. 많은 경우 해당 코드는 나쁠 뿐만 아니라 잘못되어 전혀 작동하지 않습니다.

제가 정말 걱정하는 것은 후배 프로그래머에게 작업이 주어지고 이를 구현하기 위해 ai를 사용하기로 선택할 때입니다. ai가 코드를 제공한 후 이러한 초보자는 항상 "글쎄 ai가 제공한 코드이므로 괜찮을 것입니다"라고 생각한 다음 직업을 잃습니다. 그래서 내 제안은,경력을 쌓은 후 처음 몇 년 동안은 ai 사용을 줄여야 합니다.。

"신입 프로그래머": 요즘에는 다양한 프로젝트에서 ai가 생성한 코드가 점점 더 많이 사용되고 있습니다. 코드 품질과 생성 효율성의 균형을 어떻게 유지합니까?

밥 삼촌: 나의 균형잡는 방법은ai를 사용하여 먼저 코드를 생성한 다음 정리하세요.. 나는 프로젝트에 나쁜 코드를 넣지 않을 것입니다. 따라서 ai가 생성한 코드가 작동하고 테스트를 통과하면 주저 없이 돌아가서 리팩토링하고 정리하고 개선하겠습니다. 이름 변경, 일부 기능 추출, 구조 조정 등.

왜냐하면 ai가 훌륭한 코드를 생성할 것이라고 기대하지 않기 때문입니다. 그래서 나는 그것을 정리하고 그것을 내 자신의 코드로 바꾸겠습니다. 이렇게 해서 내 프로젝트이자 내가 작성한 코드가 된다.

"신입 프로그래머": 약 5년 전 누군가가 "소프트웨어 엔지니어링의 어떤 트렌드가 과대평가되어 있습니까?"라고 물었고 당신은 마이크로서비스를 저주했습니다.지금으로부터 5년 후, 과대평가된 다른 트렌드가 있을까요?

밥 삼촌：지금 과대평가된 추세는 물론 생성 ai입니다. 의심의 여지가 없습니다.. 그것은 새로운 것이고, 새로운 것은 무엇이든 과대평가됩니다. 5년 뒤에는 모두가 뒤를 돌아보며 “우리가 너무 과대평가했나 보다”라고 말할 것입니다.

"신입 프로그래머": ai 파동이 한창일 때 옛 지인인 켄트 벡이 한 말입니다. 그는 마지 못해 chatgpt를 사용해 보니 자신의 기술 중 90%가 이제 쓸모가 없고 나머지 10%의 가치가 천 배나 증가했다는 것을 알게 되었다고 말했습니다. 생성 ai는 얼마나 도움이 될 수 있나요?

밥 삼촌: 솔직히 말해서 ai가 특별히 유용하다고 생각하지는 않습니다. 가장 간단한 경우에는 어느 정도 도움이 될 수 있습니다. 예를 들어 제가 아주 기본적인 코딩 작업을 할 때 ai가 코드를 좀 주면 제가 그걸 보고 괜찮다고 생각해서 계속 작업을 하곤 했어요. 그러면 ai는 상황에 따라 계속 작동하는 경우가 많으며 일단 상황이 흥미로워지면 ai를 점점 더 신뢰할 수 없게 됩니다.뭔가 복잡할수록 도움이 덜 된다。

ai는 작은 일을 처리할 수 있지만 디자인을 리팩터링하고 개선하려는 경우에는 전혀 처리할 수 없습니다. 게다가 ai는 테스트 작성에 있어서는 별로 도움이 되지 않습니다.

"신입 프로그래머": 코딩 학교가 쓸모없게 되기까지는 오랜 시간이 걸릴 것이라고 이전에 말씀하셨습니다. 그 순간을 식별하는 특정 시점이 있을까요? 기술에는 끝이 있을까?

밥 삼촌: 흥미로운 질문이지만 공상 과학의 관점에서 생각해 보겠습니다.미래에 인간처럼 생각할 수 있는 기계를 만들 때쯤이면 프로그래밍 기술은 쓸모없게 될 것입니다. 하지만 솔직하게 말하면 그때가 되면 모든 기술이 쓸모 없게 됩니다.그래서 나는 그것이 기대할만한 것인지 확신하지 못합니다. 만약 그런 일이 일어난다면, 제 생각에는 아주 먼 미래의 일입니다. 아시다시피 인간의 두뇌는 전체 인터넷보다 훨씬 더 복잡합니다.

"신입 프로그래머": 사실, 모두가 아시모프의 시대로 돌아가야 한다고 말씀하셨던 게 생각나네요.로봇공학의 세 가지 법칙, 비록 그것이 "로봇 노예" 종족을 만들어낸다고 해도 말이다. 철학적 관점에서 일반 인공지능(agi)을 어떻게 이해하시나요?

밥 삼촌: 네, 단기적으로는 달성하기 어려울 것 같지만 이미 유전공학 기술을 보유하고 있습니다. 우리가 생존을 위해 의식이 있는 기계를 만든다면 아시모프의 세 가지 법칙과 같은 것이 절대적으로 필요할 것이라고 생각합니다.

"신입 프로그래머": 이를 바탕으로 ai는오픈 소스이런 일이 발생하지 않도록 하려면? 인간에게는 개방형 ai가 필요한가, 폐쇄형 ai가 필요한가?

밥 삼촌: 회사마다 각자의 비밀을 지키고 싶어하는 게 분명하고, 그것 자체는 문제가 없다고 생각해요.ai의 진짜 문제는 에너지 소비다.이는 많은 에너지를 소비하며 기술이 더욱 정교해짐에 따라 계속해서 증가할 것입니다. 이로 인해 비용이 상당히 높아집니다. 따라서 우리는 오늘날 ai가 어디까지 발전할 수 있는지, 그리고 이러한 대규모 언어 모델이 얼마나 잘 할 수 있는지 확인해야 합니다. 하지만 원자력발전소처럼 많은 에너지를 소비합니다.

프로그래머의 '장인 정신'

"신입 프로그래머": ai에서 벗어나 인간 대 인간의 주제를 이야기해보자.

누군가가 "당신의 인생 멘토는 누구입니까?"라고 물었을 때 "책은 나의 멘토입니다."라고 대답했는데, 책을 통해 마틴 파울러, 켄트 벡 등 뛰어난 인물들을 만났고, 나중에는 이 두 사람과도 작업을 하게 됐어요. 그러니까 그 해처럼애자일 선언문을 작성한 17명 중 한 명, 당신의 관계가 어떤지 밝힐 수 있습니까?

밥 삼촌: 예전에는 소프트웨어 관련 모임이 많았는데 지금은 그런 모임이 많이 줄었습니다. 저는 c 언어 컨퍼런스, 디자인 패턴 컨퍼런스, 일부 일반 소프트웨어 개발 컨퍼런스 등 다양한 유형의 컨퍼런스에 참석하고 있습니다. 이러한 활동을 통해 저는 많은 사람들을 만났습니다.

예를 들어 디자인 패턴 컨퍼런스에서 만났어요.켄트 벡, 초기 익스트림 프로그래밍 컨퍼런스에서 만났습니다.마틴 파울러. 저는 이들 대부분을 직접 만나서 제 파트너이자 멘토가 되었습니다. 그들 역시 나의 동료이고, 함께 배우고 발전해 나가고 있습니다. 내가 배운 많은 내용은 donald knuth의 the art of computer 프로그래밍과 같은 1960년대와 1970년대의 프로그래밍 책에서 나왔고, 그 시대의 책은 나에게 매우 중요한 정보 소스였습니다.

그래서 경력 30년쯤 되었을 때 컨퍼런스에 나가서 사람들을 직접 만나기 시작했고, 이런 환경에서 우리가 창립하게 되었습니다.민첩한 회의. agile 컨퍼런스에 참석한 대부분의 사람들은 이전에 서신을 통해 또는 컨퍼런스에서 만난 적이 있어서 알고 있었습니다.

"신입 프로그래머": "애자일 개발이 정말 적용 가능한가?"라는 관점을 자주 볼 수 있습니다.

과거에는 많은 개발자들이 빠른 전달을 추구하고 소프트웨어의 품질을 무시했던 시절이 있었습니다. 이는 애자일에 대한 오해일 수도 있습니다.

밥 삼촌: 이것은 실제로 agile에 대한 오해입니다. 애자일은 더 빨라지는 것이 아니라 현재 위치를 이해하는 것입니다. 민첩한 개발을 수행하면 얼마나 많은 진전이 이루어지고 있는지, 얼마나 빨리 진행되고 있는지, 마감일을 준수하는지 여부를 정확히 알 수 있습니다. 즉, agile은 자신이 얼마나 많은 어려움을 겪고 있는지 이해하는 데 도움이 되는 훌륭한 방법입니다. 마감일이 늦어도 놀라지 않도록 보장하고, 생각만큼 빠르지 않을 수 있으므로 모든 사람에게 진행 상황에 대한 명확한 아이디어를 제공합니다.

많은 사람들이 agile이 빠른 방법이라고 잘못 믿고 있고, 어떤 사람들은 agile을 빠른 방법이라고 홍보하기도 하지만, 이는 항상 오해입니다.민첩성은 당신을 더 빠르게 만드는 방법이 아니라, 당신이 얼마나 빠른지 알려주는 방법입니다.따라서 agile은 쓸모없는 기술이 아닙니다. 프로젝트의 실제 진행 상황과 완료 날짜를 알고 싶다면 agile이 좋은 방법입니다.

"신입 프로그래머": 귀하의 트윗 중 하나가 저에게 매우 깊은 인상을 주었습니다. 즉, "agility는 원래개발자개시되었지만프로젝트 관리자애자일 운동의 초기 단계에 개입하면서 원래의 협력 관계가 파괴되었습니다. ”그 이야기를 들려주실 수 있나요?

밥 삼촌: 실제로 애자일 운동은 원래 다음과 같은 그룹에 의해 시작되었습니다.프로그램 제작자시작되었습니다. 17명의 참가자가 snowbird resort에 모여 애자일 선언문을 작성했습니다. 우리는 모두 프로그래머이거나 적어도 강력한 기술적 배경을 가지고 있습니다. 이 운동은 프로젝트 관리 관점에서 시작된 것이 아니었지만 창립자 중 한 명인 ken schwaber가 certification이라는 과정을 시작하기로 결정했습니다.스크럼 마스터(스크럼 마스터)" 과정입니다. 이 과정은 스크럼 마스터가 되고자 하는 사람들을 교육하고 팀이 스크럼을 사용하는 데 도움을 주는 방법을 가르치기 위해 고안되었습니다.스크럼 방법——이것은 민첩한 개발의 모델입니다.

프로젝트 관리자들은 큰 관심을 보였고 그러한 과정에 등록했습니다. 참가자 대부분이 프로그래머가 아닌 프로젝트 관리자였기 때문에,개발자가 시작한 운동은 점차 프로젝트 관리자가 주도하는 운동으로 바뀌었습니다.프로그래머들은 자신들이 이 계획에서 제외되었다고 느꼈기 때문에 불만을 느꼈습니다.

이 문제를 해결하기 위해 우리 그룹은소프트웨어 장인정신 운동(software craftsmanship) 프로젝트 관리자와 개발자를 다시 연결하기 위해 craftsmanship 선언문을 발표했습니다. 그러나 이는 의미 있는 성과를 거두지 못했다.

궁극적으로 우리는 프로젝트 관리를 중심으로 한 "공식적인 agile 운동"과 실제 개발자가 주도하는 agile 운동을 분리했습니다. 후자는 여전히 간결하고 질서 있게 업무를 수행하고 자신의 입장과 발전 방향을 명확히 하는 데 전념하고 있습니다.

"신입 프로그래머": 그렇다면 스크럼 마스터 역할의 의미는 무엇인가요? 이 역할은 어떤 면에서 중요합니까? 우수한 스크럼 마스터를 어떻게 육성하나요?

밥 삼촌: 스크럼 마스터는 원래 스크럼 또는 애자일 방법을 사용할 때 수행한 약속을 다른 구성원에게 상기시키는 책임을 맡은 팀의 구성원으로 설계되었습니다. 책임에는 테스트 코드가 계획대로 작성되었는지, 미리 결정된 추정 방법이 준수되었는지 확인하는 등 팀의 진행 상황을 매주 확인하는 것이 포함됩니다. 이 역할은 팀 내에서 일반적으로 다른 구성원 간에 순환됩니다. 성숙한 팀에서는 몇 주 동안 연습한 후에는 팀 구성원이 이미 확립된 프로세스를 의식적으로 실행할 수 있기 때문에 감독할 전담 스크럼 마스터가 필요하지 않습니다.그러나 프로젝트 매니저가 참여하면서 이 역할은 점차 프로젝트 관리 기능으로 진화했는데, 이는 스크럼 마스터의 원래 의도와는 거리가 멀다.그 결과 오늘날 스크럼 마스터의 역할이 크게 바뀌었습니다.

"신입 프로그래머": 방금 소프트웨어 장인정신에 대한 이야기를 말씀하셨는데, 트위터 서명에도 "장인정신" (craftsmanship), 이것은 아주 오래된 단어입니다. 오늘은 "장인정신”。

이 말은 어떻게 이해해야 할까요? 오늘날 빠르게 성장하는 산업에서 품질에 집중할 시간이 정말 없습니까? ai가 발전함에 따라 소프트웨어 제공이 더욱 빨라지는 것으로 보입니다. ai가 도움이 될 것 같아요. 그렇죠?

밥 삼촌: 이러한 대규모 언어 모델은 정말 흥미로운 도구이며 프로그래머에게 도움이 될 것이라고 생각합니다. 그러나 그들은 프로그래머를 대체하지 않을 것이며 모든 코딩을 수행하지도 않을 것입니다. 그들은 코드 작성에 능숙하지 않지만 몇 가지 흥미로운 제안을 제시할 수 있습니다. 그래서 내 생각엔그것들은 유용할 것이지만 더 이상 프로그래머가 필요하지 않게 만들기에는 충분하지 않습니다.

장인 정신은 일에 대한 태도, 태도입니다. 이를 설명하는 가장 좋은 방법은 다음과 같습니다. 직장에서 힘든 하루를 마치고 집에 돌아와 거울을 보면 "오늘 정말 수고했고 내 일이 자랑스러워요."라고 스스로에게 말할 수 있습니다.장인이 행동하는 방식.장인은 자신이 만든 작품의 품질에 만족하며, 고품질의 작품을 생산하기 위해 부지런히 노력합니다. 이것이 바로 소프트웨어 장인정신의 핵심입니다.

물론 테스트 주도 개발(tdd), 심플한 디자인, solid 원칙 등 많은 기술과 방법에 대해 논의할 수 있습니다. 많은 기술과 개념이 있습니다. 하지만 근본적인 생각은 하루가 끝나면 "오늘 정말 수고했어"라고 스스로에게 말할 수 있다는 것입니다. 불행하게도 많은 프로그래머들은 집에 가서 거울을 보고 목욕을 해야 할 것 같은 기분을 느낍니다. 왜냐하면 그들은 나쁜 하루를 보냈다고 느끼기 때문입니다. 그들은 단지 마감일을 맞추기 위해 나쁜 코드를 잔뜩 작성했고, 그런 나쁜 감정을 씻어내야 합니다. 그것이 바로 장인 정신에 관한 것입니다. 좋은 일을 했다는 사실을 알고 집에 가서 자신의 작업에 자부심을 느끼는 것입니다.

"신입 프로그래머": 귀하의 저서 "the way to clean code"(클린 코드) 또한 장인 정신의 원칙을 반영합니다. 소위 클린 코드의 "타오(tao)"는 시스템 프로그래밍보다 비즈니스 로직 구현에 더 중점을 두고 있습니까? 아니면 둘 사이에 차이가 없나요?

밥 삼촌：클린 코드는 장인처럼 일하면서 자신의 작업에 자부심을 느끼며 집에 갈 수 있도록 돕는 일련의 개념과 기술입니다.비즈니스 로직을 구현하는지, 시스템 프로그래밍을 하는지는 중요하지 않습니다. 그것은 당신이 일을 잘하고 만족감을 느끼게 하는 데 도움이 되는 일련의 기술과 개념일 뿐입니다.

"신입 프로그래머": 그 전에도 중국이나 미국의 개발자 커뮤니티를 막론하고 클린 코드가 많은 것을 의미한다고 생각하는 사람들이 많다는 것을 알게 되었습니다.추상적인. 그렇다면 지나치게 설계되고 지나치게 추상적인 코드를 작성하지 않으려면 어떻게 해야 할까요?

밥 삼촌: 네, 이것은 매우 이상한 현상입니다. 내 책 자체에서는 과도한 추상화를 권장하지도 않고, 많은 추상화를 옹호하지도 않기 때문입니다. 책에서 제안하는 바는,추상화를 아껴서 적절하게 사용하되 과도한 디자인은 권장하지 않습니다.. 분명히 어떤 형태의 프로그램이라도 가능하다고 믿는 일부 프로그래머가 있습니다.간접적인모두 나쁘다. 그들은 좋은 코드를 작성하는 유일한 방법은 다음과 같이 노력하는 것이라고 생각한다.직접. 나는 이 견해에 동의하지 않습니다. 적당한 양의 간접 및 추상화가 도움이 될 수 있다고 생각합니다. 그러나 추상화에는 비용이 들기 때문에 매우 조심해야 합니다. 따라서 문제 해결에 도움이 될 때 추상화를 사용하되 비용을 염두에 두고 아껴서 사용하십시오.

"신입 프로그래머": 아마도 이것이 얼마 전 "code cleanness"의 새 버전을 출시하겠다고 말씀하신 이유일 것입니다. 소스를 지우는 것으로 이해해도 될까요? 하지만 책을 완전히 다시 디자인하고 다시 쓰기로 결정하셨으니, 책에 새로운 이름을 붙이는 것은 어떨까요?

밥 삼촌: 책 제목은 출판사에서 정했습니다. 주로 "클린 코드"의 핵심 개념을 반복하고 싶었지만 다른 표현을 사용하고 다른 각도에서 주제를 자세히 설명했습니다.

원작은 16~17년 전, 당시 관객을 위해 쓴 것이다. 그리고 지금 나는 오늘날의 독자들을 위해 이 책을 쓰고 있습니다. 그것은 시도할 것이다지금은 더 일반적인 문제를 해결하세요. 나는 다른 언어를 사용하고 다른 접근 방식을 취하여 덜 지시적이고 더 많은 정보를 제공하고 동일한 요점을 다른 방식으로 전달하려고 노력했습니다. 메시지는 동일하지만 다르게 표현되었습니다. 나는 이 두 책이 궁극적으로 상호보완적일 것이며 독자들은 두 책을 모두 읽어야 한다고 생각합니다.

ai는 뇌가 절반밖에 없는 주니어 프로그래머입니다.

그리고 절대 자라지 않아

"신입 프로그래머": 당신의 신간 『functional design』에 대해 이야기해 보겠습니다.. 먼저, 왜 이 책을 쓰고 싶었나요?

밥 삼촌：함수형 프로그래밍은 지난 10년 동안 그 중요성이 커졌습니다. 사람들이 함수형 프로그래밍에 관심을 갖기 시작한 것은 2005년경이지만 사실 함수형 프로그래밍은 1936년부터 수학적 언어로 존재했던 오래된 개념이고, 최초의 프로그래밍 언어 중 하나가 함수형이었습니다.

초기에는 함수형 언어를 실행하는 데 비용이 많이 들고 속도가 느리며 많은 양의 메모리가 필요했습니다. 그러나 이제 컴퓨팅 성능과 메모리 리소스의 발전으로 인해 함수형 프로그래밍 비용은 거의 무시할 수 있게 되었습니다. 이는 특히 다중 스레드 프로그래밍과 관련하여 함수형 프로그래밍의 이점을 제공합니다. 함수형 프로그래밍을 사용하면 경쟁 조건이나 동시 업데이트에 대한 걱정 없이 다중 스레드 코드를 작성할 수 있습니다. 이는 함수형 프로그래밍에 할당문이 없고 변수 상태를 변경하지 않기 때문입니다.

clojure를 배우면서 이것이 코딩하고 문제를 해결하는 재미있는 방법이라는 것을 알았습니다. 객체 지향 프로그래밍이나 구조적 프로그래밍 같은 다른 도구와 결합해야 한다고 생각합니다.그러나 최근 몇 년 동안 일부 기사에서는 함수형 프로그래밍이 객체 지향 프로그래밍에 반대되며 객체 지향 프로그래밍이 시대에 뒤떨어졌다고 주장했습니다. 나는 이 견해에 동의하지 않았고 이 책을 쓰기로 결정했습니다.

이 책에서는 함수형 프로그래밍, 객체 지향 프로그래밍, 구조적 프로그래밍이 함께 작동하여 더 나은 시스템을 구축하는 방법에 대해 설명합니다. 기본 개념부터 시작하여 점차적으로 디자인 원칙과 패턴을 구축하고 최종적으로 이를 완전한 작은 애플리케이션으로 결합합니다. 독자님들의 이해를 바랍니다함수형 프로그래밍은 단독으로 존재하지 않습니다., 지난 50년 동안 우리가 배운 모든 내용과 함께 작동합니다.

"신입 프로그래머": csdn 개발자 커뮤니티에서도 신간 관련 질문을 많이 모아봤는데, 왜 선택하셨는지 가장 궁금해하시는 분들이 많더라고요.클로저스칼라 대신 책에 코드를 작성하시겠습니까? solid 원칙이 기능적 디자인에도 적용된다는 것을 증명하기 위해 클래스와 상속을 지원하지 않는 보다 기능적인 언어를 사용하고 싶기 때문입니까?

밥 삼촌: 이유 중 일부물론. clojure는 "순수한" 함수형 언어는 아니지만 함수형 프로그램을 작성하는 데 매우 도움이 됩니다. 하지만 제가 clojure를 선택한 또 다른, 아마도 더 중요한 이유가 있습니다.클로저는 매우 간단하다。

내가 이 책에서 전달하고 싶은 것은 복잡한 함수형 프로그래밍 언어를 가르치는 것이 아니라 함수형 프로그래밍에 대한 생각이다. 특히 문법이 복잡한 언어를 가르치고 싶지 않습니다. clojure의 구문은 매우 간단하며 복잡한 구문이 거의 없습니다. clojure를 배우는 것은 쉽고 clojure 코드를 읽으면 이를 마스터할 수 있습니다.

그래서 책에서 코드를 보여줄 때 clojure의 작동 방식을 자세히 설명하지 않고 대신 몇 가지 기본 개념을 설명하고 나머지 대부분은 독자가 이해할 수 있도록 합니다. 또한 관심 있는 독자들이 참고할 수 있는 다른 문서도 추천합니다. 하지만 전반적으로 clojure는 이해하기 매우 쉽기 때문에clojure나 함수형 프로그래밍에 대해 잘 모르는 독자의 경우 언어 자체에 신경 쓰지 않고 함수형 프로그래밍의 개념에 더 집중할 수 있습니다.

"신입 프로그래머": 누군가 당신의 다음 책에 언급되기를 원한다면 가장 멋지다고 생각하는 코드 조각을 제출하면 된다고 트위터에서 말한 적이 있습니다. 이런 일이 자주 발생합니까? 일반적으로 몇 명이 코드를 제출합니까? 중국 개발자도 제출할 수 있나요?

밥 삼촌：예, 저는 그 내용을 트윗했고 꽤 많은 응답을 받았습니다. 어떤 사람들은 github 링크를 통해 또는 직접 코드 조각을 보냅니다. 나는 아마도 다음 책에서 이 코드 중 일부를 사용할 것입니다.중국 개발자가 매우 깔끔하다고 생각하는 코드를 제출하고 싶다면 기꺼이 고려해 보겠습니다.하지만 책의 길이가 제한되어 있고 모든 사람의 코드를 넣을 수 없기 때문에 모든 사람의 코드를 사용하겠다고 약속할 수는 없습니다.

"신입 프로그래머": 디지털교과서와 온라인 학습 플랫폼에 대한 혁신적인 아이디어가 있나요? 요즘 사람들은 종이책을 덜 읽는 것 같아요. 이러한 새로운 형식은 프로그래밍을 가르치고 배우는 방식에 어떻게 혁명을 일으킬 것입니까? 다음 세대에게 프로그래밍을 어떻게 가르칠 계획인가요?

밥 삼촌:물론,우리는 이제 주의 집중 시간이 20분 미만으로 줄어든 디지털 시대에 살고 있습니다. 하지만 정말로 뭔가를 배우고 싶다면, 속도를 늦추고 공부에 집중해야 합니다. 내 최근 책 중 몇 권이 함께 왔습니다.동영상콘텐츠, 독자들은 책에 있는 url을 통해 프로그래밍 세션의 실시간 데모를 시청할 수 있습니다. 텍스트와 비디오의 이러한 조합은 매우 효과적입니다.

게다가 아주 흥미로운 방법이 있는데,온라인 강의. 예를 들어, 인쇄된 자료를 읽은 후 해당 강의를 보려면 특정 url을 방문하라는 메시지가 표시됩니다. 나는 이런 방법들이 매우 유용하다고 생각한다.

종이책의 시대는 아직 끝나지 않았다고 생각합니다. 전자책, pdf, 온라인 리더 버전으로 변환할 수 있지만 교과서는 사라지지 않습니다. 텍스트는 정보 밀도가 매우 높은 매체로 동영상이나 강의에 비해 밀도가 높으며, 학습 진행을 제어하기에도 편리합니다. 따라서 텍스트와 비디오를 병행하여 다양한 학습 형식을 조합하는 것이 더 효과적일 수 있다고 생각합니다.

"신입 프로그래머": 귀하의 책은 초보자부터 노련한 전문가까지 모든 수준의 전문 지식을 갖춘 독자를 대상으로 작성되었습니다. 이는 콘텐츠의 깊이와 폭의 균형을 맞추는 데 있어 확실히 다른 과제를 제시합니다.

밥 삼촌: 내 책은 실제로 초보자와 전문 프로그래머 등 다양한 그룹의 사람들을 대상으로 하고 있습니다. 핵심은 한 쪽이 소화하기 너무 어렵게 만들거나 다른 쪽을 지나치게 단순화하지 않고 두 유형의 독자 모두에게 가치를 제공하는 것입니다.

가르치고 글을 쓸 때 나는 듣는 사람이나 독자가 나만큼 똑똑하고 내 내용을 이해할 수 있다고 가정합니다. 그들 입장에서 약간의 노력이 필요할 수도 있지만, 나는 그들이 이해할 것이라고 확신합니다. 독자의 능력에 따라 내용을 조정하지 않습니다. 나는 마치 동료에게 말하듯이 내 메시지를 직접 전달할 뿐입니다.

어쩌면 나는 더 많은 경험을 갖고 있을 수도 있고, 더 많은 일을 겪었고 더 많은 실수를 저질렀을 수도 있습니다. 그래서 나는 내 경험과 이야기를 공유할 수 있다. 하지만 속도를 늦추거나 지나치게 단순화하지는 않겠습니다.

"신입 프로그래머": 지난 몇 년간 프로그래밍을 가르치는 방식을 어떻게 바꾸셨나요? 진화하는 기술 환경에 발맞추기 위해 어떤 새로운 접근 방식과 교훈을 채택하셨나요?

밥 삼촌: 초기에는 주로 사용했습니다.투명 필름, 프로젝터를 통해 코스 콘텐츠를 표시합니다. 일반적으로 콘텐츠를 페이지별로 표시하기 위해 큰 필름 더미를 준비합니다. 시간이 지나면서 지금은아이패드프레젠테이션을 하고, 프로젝터에 연결하고, apple pencil로 ipad 화면에 그림을 그리면, 모든 것이 실시간으로 큰 화면에 표시됩니다.

코로나19 팬데믹 기간 동안 우리는 zoom과 같은 원격 교육 도구를 통해 가르치기 시작했습니다. 이제 대부분의 교육은 원격으로 이루어집니다. 저는 아직도 슬라이드 프리젠테이션과 스크린 드로잉을 사용하고 있으며 이러한 방법은 여전히 ​​유효합니다. 유일한 차이점은 원격 교육에서는 청중의 반응을 직접 볼 수 없다는 점이며 이는 경험이 적습니다.절반은 재미。

"신입 프로그래머": 전염병이 가져온 또 다른 변화는 많은 프로그래머들이 ai로 대체될까 봐 걱정하고 있다는 것입니다. 예전에 기능적 디자인을 배우면 직업을 유지하는 데 도움이 된다는 글을 봤는데, 좀 더 자세히 설명해주실 수 있나요?

밥 삼촌: 기능적 디자인과 기능적 디자인 책의 개념은 실제로 당신이 좀 더 성숙한 프로그래머가 될 수 있도록 돕기 위해 고안되었습니다."도구 상자"에 새 도구 추가. 함수형 프로그래밍도 좋은 도구이고, 객체 지향 프로그래밍도 좋은 도구이며, 구조적 프로그래밍도 좋은 도구입니다. 테스트 중심 개발은 훌륭한 도구이므로 미리 준비해 두는 것이 가장 좋습니다. solid 원칙도 훌륭하며 반드시 도구 상자에 있어야 합니다. 그래서 이 책의 목적은 개발자의 도구 상자를 확장하는 것인데, 이는 확실히 당신의 직업을 유지하는 데 도움이 될 것입니다.하지만 ai로 대체되는 것에 대해 너무 걱정할 필요는 없다고 생각합니다. 이것은 내 생애에 일어날 가능성이 낮고, 당신의 생애에 일어나지 않을 수도 있고, 결코 일어나지 않을 수도 있습니다. 인간 수준의 지능을 갖춘 기계를 볼 수 없을 것 같은 느낌이 듭니다.

"신입 프로그래머": 기능적 디자인과 객체지향 프로그래밍에 관해 많은 분들이 어느 것이 더 좋은지 물어보셨을 거라 생각합니다. 그런데 제가 묻고 싶은 건, 당신은 그렇게 생각하시나요?현재 ai는 어느 쪽이 더 낫나요?예를 들어, 함수형 프로그래밍이 ai 코드 생성에 더 적합합니까? 상태가 없고, 사용 시 함수가 생성될 수 있으며, 각 함수는 ai가 자동으로 생성하고 검증할 수도 있습니다. 그렇다면 ai가 기능적 디자인을 더 잘한다면, 기능적 프로그래밍만 아는 프로그래머들은 더 큰 위기에 직면하게 될까요?

밥 삼촌：상관없어 ai는 아무것도 할 수 없으니까, 객체 지향 또는 구조화된 코드보다 기능적 코드를 생성하는 데 더 나을 것이 없습니다.ai라고 생각하시면 됩니다.뇌가 절반만 있고 제대로 성장하지 못하는 주니어 프로그래머. 그것은 당신에게 몇 가지 제안을 줄 것입니다. 그 중 대부분은 별로 좋지 않으며, 그 중 일부는 괜찮을 수도 있지만 ai가 작성한 코드는 항상 지저분하기 때문에 변경해야 합니다.

ai는 그것이고 도움이 될 수 있지만 ai를 수용하기 위해 경력 방향을 조정해서는 안 됩니다. ai는 도구이고 사용법을 배울 수 있지만 특정 ai 도구 때문에 진로 계획을 바꿔서는 안 됩니다.

ai 프로그래밍을 접했을 때 어떻게 해야 할지 모르겠다면 어떻게 해야 할까요?

그럼 끄세요

"신입 프로그래머": 새로운 사람이 당신에게 와서 "첫 번째 프로그래밍 언어로 어떤 언어를 선택해야 합니까?"라고 묻는다면 일반적으로 어떻게 대답하시겠습니까?

밥 삼촌: 음, 자바를 선택하시면 됩니다. 그러고 보면 c#도 아주 좋은 언어입니다. 클로저도 좋습니다. c언어도 가능합니다. c++는 조금 어렵고 복잡하지만 선택 사항이기도 합니다. go 언어도 참 좋은 언어네요...

사실 어느 쪽을 선택하느냐는 그다지 중요하지 않습니다. 프로그래밍은 프로그래밍이므로 어떤 언어로 시작하는지는 중요하지 않습니다. 가장 중요한 것은 다음 언어를 배워야 한다는 것입니다. 하나의 언어에서 멈추지 마세요.하나를 배우고, 어느 정도 능숙해질 때까지 몇 달을 보낸 다음, 또 다른 언어를 배우고, 매년 새로운 언어를 배우세요. 언어를 배우는 것을 재미있다고 생각하고, 아직 배우지 않은 언어를 찾아보세요. 직장에서 한 번도 사용하지 않을 수도 있고, 다시는 사용하지 않을 수도 있지만, 1~2년에 한 번씩 새로운 언어를 배우는 습관을 들이세요.어디서 시작하는지는 중요하지 않습니다. 중요한 것은 계속해서 배우는 것입니다.

"신입 프로그래머": 후배 프로그래머들에게 오픈소스 프로젝트 참여를 추천하시겠습니까? 당신이 직접 참여한 인상적인 오픈소스 프로젝트는 무엇이며, 그 이야기를 공유해 주실 수 있나요?

밥 삼촌: 제 아들과 저는 20년 전에 프로젝트를 시작했고 지금도 계속 진행 중이며 훌륭한 프로젝트입니다. 나는 더 이상 참여하지 않지만 다른 많은 사람들이 계속 참여하고 있습니다.

주니어 프로그래머이거나 젊은 프로그래머이고 새로운 아이디어를 배우고 싶다면 오픈 소스 프로젝트에 참여하는 것이 좋습니다. 끌어오기 요청을 제출하고 가능한 한 기여해 보세요. 이는 첫째로 다른 사람을 도울 수 있는 좋은 방법이고 둘째로 훌륭한 학습 기회입니다. 어쨌든, 당신 말이 맞습니다. 저는 사람들에게 오픈 소스 프로젝트에 참여하도록 적극 권장합니다. 이는 경력을 확장할 수 있는 좋은 방법입니다.

"신입 프로그래머": '35 위기'에 대해 아시나요? 많은 프로그래머는 특정 연령에 도달하면 두 가지 경로에 직면합니다. 관리자로 전환하거나 은퇴하는 것입니다.

밥 삼촌: 기술업계가 젊은 층을 선호하는 점을 고려하면 이는 정말 큰 문제입니다. 실제로 한 개발자가 저에게 비슷한 질문을 한 적이 있는데, 선명하게 기억나네요. 그의 정확한 말은 다음과 같았습니다: "밥 삼촌, 왜 70세에도 여전히 프로그래밍을 하시나요?" 그의 말이 맞습니다. 저는 이제 71세이고 여전히 코드를 작성하고 있습니다.

프로그래밍이 젊은이들만을 위한 것이라는 생각은 사실 환상이지만 실제로는 매우 영향력 있는 환상입니다. 이런 환상이 존재하는 이유는 지난 70년 동안 프로그래머에 대한 수요가 로켓처럼 치솟았기 때문입니다.

이렇게 생각해보세요. 5년마다 전 세계 프로그래머의 수가 두 배로 늘어납니다. 이는 5년마다 프로그래머 수를 두 배로 늘려야 한다는 의미입니다. 이는 전 세계 프로그래머의 절반이 경력이 5년 미만이고 프로그래머의 4분의 3이 경력이 10년 미만이라는 것을 의미합니다. 즉, 전 세계 프로그래머의 4분의 3이 35세 미만이라는 뜻입니다. 그래서 주위를 둘러보면 온통 젊은이들뿐이다. 당신은 그 늙은 프로그래머들이 모두 어디에 있는지 물을 수 있습니다.사실, 우리 모두는 여전히 거기에 있지만 그 숫자가 그렇게 눈에 띄지는 않습니다.

이는 프로그래밍이 젊은 사람들에게만 적합하다는 착각을 불러일으키지만 실제로는 완전히 잘못된 것입니다. 진정으로 강력한 프로그래머가 되려면 축적하는 데 오랜 시간이 걸립니다. 10년의 경험을 갖는 것이 좋다고 생각하는 선배 프로그래머도 있을 수 있지만, 5년만 더 지나면 더 나은 프로그래머가 될 수 있습니다.

따라서 코드 작성을 정말 좋아한다면 이것이 자신이 가장 좋아하는 것이라고 생각하고 계속하고 싶다면 포기하지 마십시오. 꼭 관리자가 될 필요는 없습니다. 관리를 잘하는 사람이 있으면 하게 해주세요. 계속해서 코드를 작성하고 싶다면 계속하세요. 직업을 바꾸거나 일찍 은퇴할 필요는 없습니다. 36세가 되었다고 해서 뇌가 잘 작동하지 않는다는 뜻은 아니다. 실제로 지금 이 업계에는 수많은 새로운 사람들이 쏟아져 나오고 있고, 젊은이들뿐만 아니라 모든 연령대의 사람들이 프로그래밍을 배우고 있습니다.그렇다고 기회가 없다는 뜻은 아닙니다.

"신입 프로그래머": 이는 이제 많은 프로그래머들이 ai를 직면할 때 자기 회의감을 느낀다는 사실을 상기시켜 줍니다. 그러나 사실 자기 회의는 새로운 것이 아니며 많은 노련한 프로그래머들은 이전 시대에도 같은 문제를 겪었을 것입니다. 이전에 자기 의심을 느낀 적이 있습니까?

밥 삼촌: 제가 처음 프로그래밍을 시작했을 때 저는 아직 어렸어요. 저는 제 이름을 알릴 수 있을 거라고 늘 느꼈어요. 이때 나는 한 번도 자기 의심을 품지 않았습니다.

대신 나는 실수를 하고, 해고당하고, 또 다른 좌절을 경험하기 시작했습니다. 이때 자기 의심은 실제로 좋은 것입니다.적당한 양의 자기 의심은 실제로 꽤 건강합니다. 시간이 지나면 대처하는 법을 배우기 때문입니다.당신은 "좋아, 나는 이러한 실수를 피하는 방법을 알고 있습니다. 나는 완벽하지 않다는 것을 알고 있지만 집중하고 조심하고 다른 사람들과 대화하는 한 이러한 문제를 천천히 해결할 수 있을 것입니다."라고 생각합니다. 그러한 자기 의심을 극복할 것입니다. 사실, 자기 회의의 기간을 겪는 것이 반드시 나쁜 것은 아닙니다. 이를 통해 성장하고 강해질 수 있습니다.

"신입 프로그래머":마지막으로 현재 개발자들에게 조언을 해주실 수 있나요? 특히 ai 프로그래밍에 대해 혼란스럽거나 헤매는 프로그래머라면 더욱 그렇습니다.

밥 삼촌：ai 프로그래밍에 직면했을 때 무엇을 해야 할지 모른다면 ai를 끄십시오. 그냥 무시하세요.한 달 더 시간을 들여 직접 코드를 작성하고 ai를 켜세요. 그러면 코드를 보고 무엇을 하려는지 확인한 다음 더 나은 제안을 제공할 수 있을 것입니다.