Stack Overflow에서 10주년이 다가오고 있습니다. 수년에 걸쳐 사이트 사용에 대한 나의 접근 방식과 사이트에 대한 인식이 많이 바뀌었으며, 내 경험을 여러분과 공유하고 싶습니다. 그리고 저는 사이트 커뮤니티나 문화 생활에 별로 관여하지 않는 일반 사용자의 관점에서 이에 대해 쓰고 있습니다. 요즘은 제가 작업하고 있는 제품인 VS Code에 관련된 질문들만 답변을 드리고 있습니다. 하지만 저는 다양한 주제에 관한 토론에 적극적으로 참여하곤 했습니다. XNUMX년 안에 나는 50개의 질문을 하고 575개의 답변을 주었습니다., 수많은 다른 사람들의 댓글을 살펴보았습니다.

존 스키테 Stack Overflow의 문화를 설명했습니다. 내가 할 수 있는 것보다 훨씬 더 훌륭하고 권위 있는 일을 하게 될 것입니다. 이 출판물은 이 기사의 일부 장에 영향을 주었지만 전반적으로 이 내용은 Stack Overflow에 대한 내 경험, 사이트의 좋은 점과 나쁜 점, 현재 이 사이트를 어떻게 사용할 수 있는지에 대한 솔직한 반성입니다. 이 논의는 사이트의 작동이나 역사에 대해 깊이 파고들지 않고 상당히 피상적일 것입니다.

제가 10년 동안 Stack Overflow를 사용하면서 배운 내용은 다음과 같습니다.

질문을 할 수 있어야 합니다.

언뜻 보면 이보다 더 간단한 것은 없습니다. 텍스트 필드에 몇 단어를 입력하고 "제출"을 클릭하면 인터넷이 마술처럼 모든 문제를 해결하는 데 도움이 될 것입니다! 하지만 실제로 결과를 얻기 위해 그 빌어먹을 필드에 어떤 단어를 입력해야 하는지 알아내는 데 거의 10년이 걸렸습니다. 사실 저는 아직도 매일 그것에 대해 배우고 있어요.

좋은 질문을 하는 것은 정말 과소평가된 기술입니다(좋은 이슈 보고서를 작성하는 것도 마찬가지입니다). 첫째, 질문이 "좋은"지 어떻게 판단할 수 있습니까? 스택 오버플로 제안 힌트, 이는 좋은 질문의 다음 특성을 나열합니다.

• 사이트의 주제와 일치합니까?
• 객관적인 답변을 의미합니다.
• 아직 요청되지 않았습니다.
• 연구되었습니다.
• 일반적으로 쉽게 재현할 수 있는 최소한의 예를 사용하여 문제를 명확하게 설명합니다.

좋습니다. 하지만 실제로 "명확한 문제 설명"은 어떤 모습일까요? 어떤 정보가 관련되고 어떤 정보가 관련되지 않습니까? 때로는 좋은 질문을 하려면 먼저 답을 알아야 할 것 같은 느낌이 들 때가 있습니다.

불행하게도 작은 텍스트 필드는 여기서 도움이 되지 않습니다. 그렇다면 너무 많은 사용자가 품질이 낮은 질문을 게시하는 것이 놀라운 일입니까? 때때로 그들이 얻는 유일한 대답은 혼란스러운 문서에 대한 링크뿐입니다. 그리고 그들은 여전히 ​​운이 좋을 것입니다. 품질이 낮은 질문 중 다수는 조용히 반대표를 받고 끝없는 질문 속으로 사라집니다.

좋은 질문을 하는 것은 기술이다. 다행히도 개발이 가능합니다. 나는 대부분 많은 질문과 답변을 읽고 무엇이 효과가 있었고 무엇이 효과가 없었는지 지적하면서 배웠습니다. 어떤 정보가 유용하고 어떤 정보가 짜증스럽나요? 습득한 지식을 실제로 사용하고 질문하는 것은 여전히 ​​​​두려울 것입니다. 최선을 다하고 결과를 통해 배우십시오. 나는 초기에 무지한 질문을 해서 약간 당황스럽다는 점을 인정해야 합니다. 아마도 이것은 이 사이트를 방문한 이후로 질문 기술이 많이 향상되었다는 것을 증명할 수도 있습니다.

나쁜 질문과 좋지 않은 질문은 같은 것이 아닙니다

나는 알약을 설탕으로 코팅하지 않을 것입니다. 일부 질문은 단지 나쁩니다.

스크린샷과 "WHY DOESN'T THIS WORK!?!"라는 문구로 구성된 질문입니다. - 나쁜. 왜? 저자가 거의 노력을 기울이지 않은 것은 분명합니다. 이것은 질문이라기보다는 “나를 위해 이 일을 해주세요!”라는 요구입니다. 내가 왜 이런 일을 하겠습니까? 내 시간은 처음부터 배우기를 원하지 않고 내 도움에 감사하지 않는 사람을 돕는 데 낭비하기에는 너무 소중합니다. 스택 오버플로가 무엇인지 알아보세요.

이제 "내 페이지에서 파란색 테두리를 제거하는 방법"이라는 질문을 생각해 보세요. 이 질문은 CSS 개요 속성에 대해 설명하는 여러 단락의 텍스트로 구성되어 있지만 "CSS" 또는 "개요"라는 단어를 명시적으로 언급하지 않습니다. 이와 같은 질문은 많은 스택 오버플로 지침에 어긋날 수 있지만 동의하지 않지만 나쁜 질문은 아닙니다. 저자는 무엇을 제공해야 할지 모른 채 적어도 몇 가지 정보를 제공하려고 노력했습니다. 인식하고 배우려는 의지와 마찬가지로 시도도 중요합니다.

그러나 많은 Stack Overflow 기여자는 두 질문을 모두 반대표와 닫기와 같은 방식으로 처리할 것입니다. 이는 실망스럽고 경험이 없는 많은 사용자가 더 나은 질문을 하는 방법을 배우고 사이트 작동 방식을 이해하기 전에 꺼지게 됩니다.

정말 나쁜 질문은 시간을 들일 가치가 없습니다. 그러나 별로 좋지 않은 질문을 하는 사람들은 의도치 않게 그렇게 한다는 점을 명심해야 합니다. 그들은 좋은 질문을 하고 싶어하지만 방법을 모릅니다. 새로 온 사람들을 맹목적으로 설명도 없이 처벌한다면 그들은 어떻게 배울 것인가?

좋은 질문이 답을 보장하는 것은 아니다

스택 오버플로는 일반적으로 많은 사람들이 대답할 수 있는 간단한 질문에 더 빠른 답변을 제공합니다. JavaScript 또는 HTML의 이진 검색에 대해 질문이 있습니까? 아주 멋진! 한 시간 안에 XNUMX개의 답변을 받으세요. 그러나 질문이 복잡하거나 구체적일수록 표현의 질에 관계없이 답변을 얻을 가능성이 줄어듭니다.

응답을 받을 가능성도 시간이 지남에 따라 빠르게 감소합니다. 질문이 피드의 여러 페이지 깊이로 들어가면 내용이 사라집니다. 일주일 후에는 올바른 지식을 가진 누군가가 귀하의 질문을 우연히 발견하게 되기를 기도할 수 있습니다(또는 아낌없이 클릭해 주십시오).

정답이 마음에 들지 않을 수도 있습니다

매달 저는 소위 인기 없는 답변에 대해 여러 번의 반대표를 받습니다. 본질적으로 “이유는 그렇게 설계되었기 때문이다”, “그건 불가능하기 때문에...”, “먼저 고쳐야 할 버그다”라고 말하는 종류의 답변들이다. 위의 모든 경우에 대해 작성자는 솔루션이나 해결 방법조차 받지 못합니다. 그리고 사람들이 답변의 내용이 마음에 들지 않으면 반대표를 던질 것이라고 생각합니다. 나는 심지어 그것들을 이해하지만 이것이 대답이 틀렸다는 것을 의미하지는 않습니다.

물론 그 반대도 마찬가지입니다. 좋은 답변이 반드시 듣고 싶은 내용을 알려주는 것은 아닙니다. 가장 좋은 답변 중 일부는 먼저 원래 질문에 대한 답변을 제공한 다음 문제 해결을 위한 다른 접근 방식을 설명합니다. 때로는 사용자의 질문에 답변한 다음 그렇게 하지 않는 것이 왜 권장되는지에 대한 긴 텍스트를 작성합니다.

태도 표현이 찬성, 반대 투표 또는 좋아요 버튼으로 단순화될 때마다 중요한 구별이 사라집니다. 이 문제는 인터넷에서 자주 발생합니다. 얼마나 많은 소셜 네트워크를 통해 "나는 이것을 지지한다"와 "내가 그것을 좋아하지 않거나 동의하더라도 그것은 좋은 말이라고 생각한다"를 구별할 수 있게 합니까?

전반적으로, 월간 반대 투표에도 불구하고 저는 Stack Overflow 커뮤니티가 공정하게 투표했다고 믿습니다. 우리는 이 길을 고수할 것입니다.

나는 Stack Overflow에 대해 거의 묻지 않습니다.

이 사이트를 오래 사용할수록 이에 대해 질문하는 빈도가 줄어 들었습니다. 이것은 부분적으로 나의 직업적인 성장 때문입니다. 내가 직장에서 직면하는 많은 문제는 너무 복잡해서 간단한 질문으로 표현할 수 없거나 너무 구체적이어서 누구도 나를 도와줄 수 없습니다. 나는 사이트의 한계를 깨달았기 때문에 좋은 답변을 거의 확실히 얻지 못할 질문은 피합니다.

하지만 여기서는 새로운 언어나 프레임워크를 배울 때에도 질문을 거의 하지 않았습니다. 그가 그렇게 천재라서가 아니라, 정반대입니다. 단지 몇 년 동안 Stack Overflow에 있었던 후에, 질문이 있을 때, 제가 그 질문을 가장 먼저 하는 사람이 아닐 것이라는 깊은 확신에 이르렀을 뿐입니다. 검색을 시작하면 거의 항상 누군가가 이미 몇 년 전에 같은 질문을 한 것을 발견합니다.

다른 사람의 질문을 관찰하는 것은 제품에 대한 새로운 사실을 배울 수 있는 좋은 방법입니다.

지금은 작업 중이에요 VS 코드, 그래서 vscode 태그가 붙은 질문을 보는 습관을 들였습니다. 이는 내 코드가 실제 세계에서 어떻게 사용되는지 확인할 수 있는 좋은 방법입니다. 사용자는 어떤 문제에 직면합니까? 문서나 API를 어떻게 개선할 수 있나요? 분명하다고 생각했던 것이 왜 그렇게 많은 오해를 불러일으키는 걸까요?

질문은 제품이 어떻게 사용되고 있는지 보여주는 중요한 신호입니다. 그러나 요점은 대답하고 계속 진행하는 것이 아니라 먼저 그 사람이 질문이 있는 이유를 이해하려고 노력하는 것입니다. 아마도 제품에 귀하가 알지 못하는 문제가 있거나 귀하가 무의식적으로 만든 몇 가지 가정이 있을 수 있습니까? 또한 질문은 제가 많은 버그를 발견하는 데 도움이 되었고 계속 작업할 수 있도록 영감을 주었습니다.

개발자를 위한 제품을 유지 관리하는 경우 Stack Overflow를 쓰레기장(또는 더 나쁘게는 질문 묘지)으로 생각하지 마십시오. 어떤 질문과 답변이 나타났는지 정기적으로 확인하세요. 이는 모든 질문에 직접 답해야 한다는 의미는 아니지만 스택 오버플로의 신호는 무시하기에는 너무 중요합니다.

질문, 버그 보고서, 기능 요청 사이의 경계가 흐릿해졌습니다.

스택 오버플로의 VS Code에 대한 상당수의 질문은 실제로 버그 보고서였습니다. 그리고 다른 많은 사람들은 실제로 새로운 기능에 대한 요청입니다.

예를 들어 "내가 할 때 VS Code가 충돌하는 이유는 무엇입니까?"라는 제목의 질문입니다. - 버그 리포트입니다. VS Code는 다양한 상황에서 충돌하지 않아야 합니다. 버그 보고서에 대한 질문에 대답하는 것은 작성자가 해결 방법에 만족하고 실제 버그 보고서를 제출하지 않을 수 있기 때문에 비생산적입니다. 이런 상황에서는 일반적으로 사용자에게 Github에 버그 보고서를 제출하도록 요청합니다.

다른 경우에는 차이점이 덜 명확할 수 있습니다. 예를 들어 "JavaScript IntelliSense가 VS Code에서 작동하지 않는 이유는 무엇입니까?"라는 질문이 있습니다. JavaScript IntelliSense가 작동하지 않는 방식에 따라 문제는 다음 세 가지 범주 중 하나로 분류될 수 있습니다.

• 사용자 구성 문제라면 실제로 스택 오버플로에 대한 질문입니다.
• 설명된 사례에서 IntelliSense가 작동해야 하지만 작동하지 않는 경우 이는 버그 보고서입니다.
• 설명된 경우 IntelliSense가 작동하지 않으면 이는 새로운 기능에 대한 요청입니다.

결국 대부분의 사용자는 이러한 미묘한 차이에 신경 쓰지 않고 단지 JavaScript IntelliSense가 작동하기를 원합니다.

그리고 이러한 차이점은 프로젝트 책임자인 나에게는 중요하지만 일반적으로 나에게는 중요하지 않습니다. 질문, 버그 보고서, 기능 요청은 모두 하나의 아이디어를 표현하는 방법이기 때문입니다. 사용자는 내 코드에서 무언가를 기대하지만 이해하지 못합니다. 제품이 완벽하다면 사용자는 제품에 대해 절대 질문하지 않을 것입니다. 왜냐하면 모든 것이 명확하고 원하는 것을 정확히 수행할 것이기 때문입니다(또는 적어도 그렇게 할 수 없는 이유를 명확하게 알려주기 때문입니다).

개발자도 사람이다

사람들은 감정적입니다. 사람들은 비합리적입니다. 사람들은 바보입니다. 물론 항상 그런 것은 아니지만 가끔은요! 믿거나 말거나, 개발자도 사람입니다.

우리 개발자들이 스스로에게 다음과 같이 말하고 싶어하는 환상이 있습니다. “우리는 컴퓨터를 사용하여 작업하므로 합리적이어야 합니다. 우리는 비밀스러운 상징을 이해하므로 현명해야 합니다. 소프트웨어가 전 세계를 장악했으므로 우리는 냉철해야 합니다! 시원한! 앞으로!!!"

이것은 잘못된 것입니다. 만약 그렇다면, 하나님은 나머지 사람들을 도우실 것입니다. 객관적인 지식 기반으로 설계된 전문가를 위한 도구인 Stack Overflow에서도, VS Code의 매우 구체적인 코너에서도 논리적 오류, 모욕, 집단 사고방식 등 모든 종류의 분노에 계속 직면합니다.

농담하지 마세요. 당신은 아마도 당신이 생각하는 것만큼 완벽하지 않을 것입니다. 그러나 이것이 우리의 결점을 없애려고 노력해서는 안 된다는 뜻은 아닙니다.

얘야, 내가 이걸 만든 거야

나도 인간이고 때때로 Stack Overflow에서 일어나는 일이 나를 짜증나게 합니다. 예를 들어 사용자가 자신있게 말도 안 되는 글을 쓰거나, 내가 만들고 잘 아는 제품인 VS Code와 관련된 질문에 단순히 잘못된 답변을 하는 경우 등이 있습니다. 이상하게도 대답이 잘못된 것일수록 누군가는 이를 명백한 사실이라고 부를 확률이 높아지는 것 같습니다.

이런 일이 생기면 저는 그림과 같이 행동해서 정답을 씁니다.

그리고 여러 번 이로 인해 긴 스레드가 발생했습니다. 내가 만든 것에 대한 그들의 지식에 감히 질문을 던지는 것은 나에게 화가 있습니다! 항상 옳으려고 노력하지 마세요, 빌어먹을 똑똑한 놈들아! 내 말이 맞으니까!!!

이런 절망감 속에서 냉소적이 되기 쉽습니다

끝없이 쏟아지는 질 낮은 질문에 직면하면 냉소적이 되기 쉽습니다. 그는 Google에 대해 들어본 적이 없나요? 그는 일관된 문장을 구성하는 방법을 알고 있습니까? 당신은 개입니까?

때로는 하루에도 수십 개의 새로운 질문을 봅니다. 품질이 낮은 질문을 계속 관찰하다 보면 경멸이나 냉소주의에 빠질 위험이 있습니다. 지나치게 열성적인 중재자를 만나거나 질문을 조사하고 작성하는 데 몇 시간을 소비한 사람이라면 누구나 증명할 수 있듯이 이러한 냉소주의는 사이트에 퍼질 수 있으며, 그 대가로 부정적인 응답을 받고 아무런 설명도 없이 망각 속으로 사라집니다.

물론, 전혀 노력하지 않고 나쁜 질문을 게시하는 사용자가 있습니다. 하지만 저는 품질이 낮은 질문의 대부분이 (비록 어리석기는 하지만) 좋은 의도를 가진 사람들로부터 나온다고 믿습니다. 나는 항상 초보자가 된다는 것이 무엇을 의미하는지 기억하려고 노력한다. 방금 시작하면 여기에서 모든 것이 실제로 어떻게 작동하는지 이해하지 못합니다. 어떤 경우에는 어떤 단어로 문제를 정확하게 표현해야 할지조차 모를 때도 있습니다. 저를 믿으십시오. 이 위치에 있는 것은 어렵습니다. 그리고 단지 질문을 했다는 이유로 엉뚱한 말을 하는 것은 불쾌합니다.

Stack Overflow가 초보자를 돕기 위해 많은 노력을 기울였음에도 불구하고 아직 해야 할 일이 많이 남아 있습니다. 나는 사이트 표준을 준수하는 것과 경험이 없는 사용자에게 관대해지는 것 사이에서 균형을 찾으려고 노력했습니다. 여기에는 내가 질문을 종료하기로 결정한 이유를 설명하거나 사용자에게 더 많은 정보를 제공하도록 독려하는 댓글을 게시하는 것이 포함될 수 있습니다. 아직 성장할 여지가 있어요.

반면에 "JavaScript 개발을 위한 최고의 VS Code 레이아웃은 무엇입니까?"와 같은 질문을 게시하거나 텍스트 대신 코드 스크린샷을 업로드하는 평판이 50인 사용자를 반대하는 데 주저하지 않습니다.

가끔은 고맙다는 말을 전하고 싶어

스택 오버플로에는 감사 문화가 약합니다. 옛날 옛적에 사이트가 질문에서 "안녕하세요"와 "감사합니다"라는 단어를 자동으로 잘라낸 것을 기억합니다. 아마도 이 작업이 아직 완료되었을 것입니다. 확인하지 않았습니다.

오늘날 고객 지원 분야에서 일해 본 사람이라면 누구나 너무 지나친 공손함이 방해가 될 수 있고 심지어 강요된 것처럼 보일 수 있다는 것을 잘 알고 있습니다. 하지만 때때로 이 사이트의 누군가가 귀하에게 매우 중요한 일을 할 경우, 그들에게 감사를 표하는 유일한 방법은 그들에게 플러스를 주는 것입니다. 짜증나.

효율성 때문에 우리가 영혼 없는 로봇이 될 필요는 없습니다. 물론 사용자가 원할 경우 사이드 채널을 통해 사람들 간의 더욱 확실한 커뮤니케이션을 제공할 수 있습니다.

가끔 답변을 받은 후 무슨 일이 있었는지 알고 싶을 때가 있어요.

스택 오버플로는 트랜잭션 원칙에 따라 작동합니다. 어떤 사람은 질문하고 다른 사람은 대답합니다. 응답을 받은 후에는 어떻게 되나요? 누가 알아? 가끔 나는 이것이 궁금하다. 제 답변이 도움이 되었나요? 그는 어떤 작은 프로젝트를 도왔습니까? 질문자는 무엇을 배웠나요?

물론 이 호기심을 만족시키는 것은 불가능하다. 사용자에게 자신이 받은 정보를 어떻게 사용할 것인지 설명하도록 요구하는 것은 비록 그렇게 할 수 있다고 해도 매우 문제가 될 것입니다. 그러나 그것에 대해 생각하는 것은 흥미 롭습니다.

게이미피케이션이 효과적이다…

...프로세스를 게임으로 전환할 때.

상태 표시줄에 작은 +10 또는 +25 아이콘이 표시되면 여전히 약간 걱정됩니다. 아마도 이러한 작은 게임화 작업이 제가 10년 동안 이 사이트를 다시 방문하고 있는 이유일 것입니다. 하지만 몇 년이 지나면서 스택 오버플로(Stack Overflow)가 어떤 종류의 게임인지, 그리고 여기서 승리하는 것이 무엇을 의미하는지 궁금해지기 시작했습니다.

저는 이 시스템이 유용한 질문과 답변에 대해 사람들에게 보상하려는 최선의 의도로 만들어졌다고 확신합니다. 하지만 높은 점수를 추가하자마자 적용됩니다. 굿하트의 법칙, 일부 사용자는 최대 가치를 달성하는 것이 아니라 최대 등급을 얻기 위해 행동을 조정하기 시작합니다. 그리고 이게 중요한 이유는...

평판은 당신이 생각하는 것을 의미하지 않습니다.

평판은 기술적 역량, 의사소통 능력, 스택 오버플로의 작동 방식 또는 작동 방식에 대한 이해와 동일하지 않습니다.

나는 평판이 쓸모없다고 말하는 것이 아니다. 이는 Stack Overflow 관리자가 의미하는 바나 "평판"이라는 단어가 의미하는 바를 의미하지 않습니다. 나는 평판이 영향력의 척도라는 것을 깨달았습니다. 사이트에 게시된 두 가지 가상 답변을 고려해보세요.

• 일반적인 git 작업에 대한 것입니다. 구글을 이용해 XNUMX분 만에 세 줄짜리 답변을 썼습니다.
• 다른 하나는 얽힌 그래프 이론에 관한 것입니다. 아마도 전 세계에서 단 XNUMX명만이 대답할 수 있을 것입니다. 나는 문제와 해결 방법을 설명하는 몇 개의 단락과 샘플 코드를 작성했습니다.

5년 만에 첫 번째 답변은 2000만 번 조회되었고 300개의 추천을 받았습니다. 두 번째 답변은 XNUMX번 검토되었으며 두 번의 찬성표를 받았습니다.

어느 정도 이것은 매우 부정직합니다. 적시에 적절한 장소에 있었던 것에 왜 보상을 합니까? (모든 것이 운에 의해 결정되는 것은 아닙니다. 게임의 규칙을 이해하는 것도 큰 역할을 합니다.) 반면에 첫 번째 질문은 실제로 두 번째 질문보다 훨씬 더 많은 사람들에게 도움이 되었습니다. 어떤 의미에서 인정은 '명성'의 축적으로 이어진다는 점을 인식할 가치가 있지 않을까?

그래서 저는 스택오버플로의 '평판'을 일종의 영향력 척도라고 생각합니다. 진정한 평판은 단순한 점수로 평가할 수 없으며 커뮤니티에서 나옵니다. 나는 누구의 조언을 듣고, 누가 다른 사람을 돕고, 누구를 신뢰합니까? 아마도 내가 PHP로 글을 쓰는지 iOS용으로 글을 쓰는지에 따라 이들은 모두 다른 사람들이 될 것입니다.

그렇다면 스택 오버플로가 이와 관련하여 무엇을 해야 하는지 모르겠습니다. 사용자가 "평판" 대신 "교활한 포인트"를 획득하면 동기가 부여됩니까? 포인트 시스템이 전혀 없다면 사용자는 계속해서 참여하게 될까요? 나는 그럴 것 같지 않다고 생각한다. 그리고 Stack Overflow의 "평판"이 실제 평판과 동일하다는 신화는 사이트 자체뿐만 아니라 가장 활동적인 사용자에게도 도움이 됩니다. 글쎄요, 평판이 높아지는 것을 좋아하지 않는 사람이 누가 있을까요?

아니요, 인생에서 가장 자주 발생하는 것처럼 무슨 일이 일어나고 있는지 실제 아이디어를 얻으려면 숫자뿐만 아니라 분석해야합니다. Stack Overflow에 게시물의 포인트가 10개라면 이 사람이 어떻게 소통하는지, 어떤 질문과 답변을 게시하는지 살펴보세요. 그리고 예외적인 경우를 제외하고 스택 오버플로 점수만으로는 개인의 사이트 사용 능력 이외의 다른 것을 나타낼 가능성이 없다는 점을 명심하십시오. 그리고 내 경험상 그들은 종종 이것에 대해 이야기조차 하지 않습니다.

스택 오버플로가 없었다면 생산성을 발휘할 수 없었을 것입니다.

Git에서 복잡한 작업을 해야 할 때마다 Stack Overflow로 이동합니다. Bash에서 간단한 것이 필요할 때마다 Stack Overflow로 이동합니다. 이상한 컴파일 오류가 발생할 때마다 스택 오버플로로 이동합니다.

검색 엔진인 IntelliSense와 Stack Overflow가 없으면 생산성이 없습니다. 일부 책에 따르면 이것은 나를 매우 나쁜 프로그래머로 만듭니다. 나는 아마도 많은 테스트에 실패하고 보드의 많은 문제를 해결하지 못할 것입니다. 그러면 그렇게 해. 진지하게, JavaScript에서 .sort를 사용할 때마다 언제 -1, 0, 1을 얻을지에 대한 정보를 찾아야 하고, 매일 JS를 작성하여 해당 언어에 가장 인기 있는 편집기를 개발합니다.

아니요, Stack Overflow는 놀라운 도구입니다. 오직 바보만이 자신이 사용할 수 있는 모든 도구를 사용하지 않을 것입니다. 그렇다면 나처럼 내면의 바보가 되어 보는 것은 어떨까요? Seinfeld 시리즈의 모든 줄거리를 암기하거나 정교한 말장난을 생각해내는 것과 같은 중요한 지식을 위해 두뇌 자원을 절약하십시오(이 기사에서는 누락되었지만 완전히 다른 성격의 다른 많은 것들이 있을 것입니다).

스택 오버플로는 기적이다

Stack Overflow를 사용하면 경험이나 지식에 관계없이 누구나 프로그래밍 질문을 게시할 수 있습니다. 이러한 질문에 대한 답변은 완전히 낯선 사람들이 합니다. 이들 중 대부분은 무료로 다른 사람들을 돕는 데 자신의 삶과 직업의 시간을 보냅니다.

기적은 스택 오버플로의 존재와 결과에 대한 사실입니다. 모든 것이 제작자의 의도대로 되지는 않을 것이라고 확신하지만 그들은 노력합니다. 모든 단점에도 불구하고 이 사이트는 저를 포함해 수년 동안 수많은 사람들에게 도움을 주고 있습니다.

스택 오버플로는 영원히 지속되지 않습니다. 언젠가는 더 좋은 일이 생길 것입니다. 이것이 스택 오버플로의 실수로부터 배우고 최선을 다할 수 있는 내용이기를 바랍니다. 그때까지는 우리가 이 사이트를 당연하게 여기지 않기를 바랍니다. 이것은 랜드마크이자 살아있는 커뮤니티이며, 끊임없이 새로운 사람들이 보충됩니다. 이것이 걱정된다면, 이 모든 것이 매우 취약하며 심지어 선의는 있지만 아직 무지한 신규 이민자를 돕는 것과 같은 작은 행동조차도 긍정적인 영향을 미칠 수 있다는 것을 기억하십시오. 내가 이 사이트를 비판한다면 그것은 단지 내가 관심을 갖고 이 사이트를 더 좋게 만드는 방법을 알고 있기 때문입니다.

PS

Stack Overflow에 왔을 때 저는 아직 남학생이었습니다. 저는 Eclipse에서 JavaScript(ES5!)를 작성하기 시작했는데, 질문의 90%가 "JQuery를 사용하면..."으로 시작되는 것 같았습니다. 그리고 내가 무엇을 하고 있는지도 몰랐음에도 낯선 사람들이 나를 도와주느라 시간을 보냈습니다. 당시에는 별로 감사하지 않았던 것 같지만 잊지는 않았습니다.

사람들은 항상 Stack Overflow가 뭔가 다른 것, 즉 질문과 답변 사이트가 되기를 원할 것입니다. 가정 문제를 해결하기 위한 도구; 프로그래밍의 생활 수준. 그리고 나에게 이 사이트는 성장과 단점에도 불구하고 낯선 사람들이 서로 배우고 발전하도록 돕는 개방형 커뮤니티의 핵심입니다. 정말 훌륭해요. 지난 10년 동안 Stack Overflow의 일원이 되어 기쁘고 앞으로도 계속 그렇게 되기를 바랍니다. 나는 지난 XNUMX년 동안 그랬던 것처럼 다음 XNUMX년에도 새로운 것을 많이 배우고 싶습니다.

출처 : habr.com