세상에서 가장 최악의 직업: 하브라 작가 구해요

개발에 관해 Habr에 글을 쓰는 것보다 더 나은 직업이 있을까요? 누군가가 저녁 시간에 큰 하브라포스트를 준비하고 시작하는 동안, 여기에서는 근무 시간 중에 바로 커뮤니티와 흥미로운 것들을 공유하고 그로부터 혜택을 받습니다.

Habr 개발에 대해 글을 쓰는 것보다 더 나쁜 직업이 있을까요? 누군가가 하루 종일 코드를 작성하는 동안 당신은 이 사람들을 바라보며 입술을 핥고 저녁에는 마음에 드는 프로젝트를 시작하고 시작합니다.

우리 (JUG.ru 그룹) 매년 우리는 개발자를 위한 다양한 컨퍼런스를 점점 더 많이 개최하고 있어 이제 다른 직원을 찾고 있습니다. 올렉치르) 우리 habrablog의 텍스트입니다. 우리에게 필요한 사람과 이 사람을 기다리는 것이 무엇인지 명확하게 하기 위해 Habré의 기업 블로그에서 개발자를 위한 텍스트를 작성하는 작업이 일반적으로 어떤 것인지 설명했습니다.

무엇이 멋진가요?

내가 이 일을 좋아하는 이유는 무엇입니까? 모든 기업 블로그의 목표는 회사를 돕는 것이지만 여기서는 "그것이 얼마나 놀라운지에 대한 빛나는 판매 카피를 작성한다"는 의미는 아닙니다. 이것은 Habré에서는 작동하지 않습니다. 여기에서는 또 다른 일이 가능합니다. 귀하의 활동에 대한 언급이 적절해 보이는 커뮤니티에 흥미롭고 유용한 게시물을 작성하는 것입니다.

논쟁없이 "우리 컨퍼런스는 훌륭하고 놀랍습니다"라고 적어도 XNUMX 번 쓸 수 있으며 아무도 그것을 읽지 않을 것입니다. 또는 과거 컨퍼런스 보고서의 텍스트 사본을 게시할 수 있습니다. 그러면 사람들은 자신에게 유용한 정보를 얻으려고 노력할 것입니다. 동시에 실제 예를 사용하여 이벤트에서 무엇을 볼 수 있는지, 그들은 다음번에 이곳에 가고 싶어해요.

계속해서 헛소리로 구성된 글을 써야 한다면 나는 금방 목을 매고 싶을 것입니다. 다행스럽게도 저는 컨퍼런스 주제에 대한 텍스트를 작성합니다. 마지막에는 "모바일 개발에 대한 이 텍스트에 매료되었으므로 주목하세요. 여기에 이에 대한 컨퍼런스가 있습니다."라는 작은 메모가 있습니다.

이 직업의 또 다른 장점은 좋은 사람들을 많이 만날 수 있다는 점입니다. 귀하의 업무 중 유능한 사람을 인터뷰하는 것이 있을 때 조나 스키테, 당신은 숨을 죽이며 그의 대답을 듣고 마지막에 그는 "질문 주셔서 감사합니다. 흥미로 웠습니다"라고 말하고 "잠깐만, 이건 내가 지불 할게"라고 생각하게됩니다. 그들도 돈을 낸다? "

음, 배를 좋아하는 사람들을 위한 보너스: habrapost를 작성하는 것이 직업이고 자주 게시하면 habra 사용자 순위에서 XNUMX위를 차지할 수 있습니다. 그러면 당신은 이상한 개인 메시지를 받기 시작할 것입니다!

어려움은 무엇입니까?

하지만 이 모든 장점이 모든 것이 완벽하다는 의미는 아닙니다. 주요 과제는 이것이다.

한편으로는 개발에 대해 더 많이 알수록 그러한 작업에 더 좋다는 것이 분명하며 특정 주제에 매우 몰입되어 있다면 그와 관련하여 멋진 글을 쓸 수 있습니다.

그러나 동시에 우리는 다양한 영역(Java에서 테스트까지)에서 여러 컨퍼런스를 개최하므로 각 작성자마다 다루어야 할 여러 이벤트가 있으며 언제든지 새로운 이벤트가 추가될 수 있습니다. 즉, 좋아하는 주제에만 국한할 수 없으며 완전히 다른, 훨씬 덜 친숙한 주제를 탐구해야 한다는 의미입니다. 동시에 우리 컨퍼런스는 매우 하드코어하고 방문자는 업계에 새로운 것이 아니므로 콘텐츠는 숙련된 개발자에게 흥미로울 것입니다.

동시에 여러 방향에서 선배가 되는 것은 일반적으로 비현실적입니다. 이제 여기에 개발자로도 일하지 않는다는 점을 추가하십시오. 작업 시간의 일부는 주제 영역에서 벗어나지 않도록 코드에 전념할 수 있지만 이것이 주요 활동은 아닙니다. 그리고 여기에 게시물의 규칙성을 추가하십시오. 영혼의 부름에 따라 Habr에 글을 쓰는 사람들이 텍스트를 작성하기 전에 하나의 주제를 작성하는 데 몇 달을 보낼 수 있다면 여기서는 작동하지 않습니다.

그러한 상황에서 숙련된 개발자의 관심을 끌 만한 내용을 작성하는 것이 어떻게 가능합니까?

모든 것이 완전히 우울해 보일 수도 있지만 상당히 실행 가능한 옵션이 있습니다.

어떻게 살 것인가?

첫째, 광범위한 개인적인 업무 경험 없이는 많은 주제에 대해 글을 쓸 수 없지만 이것이 필요하지 않은 경우도 많습니다.

새로운 버전의 Java가 등장했는데 개발자들은 "거기에 무엇이 바뀌었나요?"라고 궁금해하고 있습니다. 이에 대한 일반적인 게시물의 경우 Java로 작성할 수 있어야 하지만 특별히 새 버전에 대한 "수개월의 경험"이 필요하지 않습니다. 영어 소스를 신중하게 이해하면 충분합니다(시험해 보는 것도 유용합니다) 혁신은 직접 이루어지지만 신속하게 완료할 수 있습니다.) 이 새 버전의 Java에는 JShell 도구가 포함되어 있습니까? 새롭기 때문에 숙련된 개발자라도 이 튜토리얼이 유용하다는 것을 알게 될 것이며, 튜토리얼을 작성하기 전에 JShell을 한두 시간 정도 사용해 보는 것으로 충분합니다(REPL의 "개월"은 전혀 투자할 가치가 없습니다). GitHub가 개인 저장소를 무료로 만들었나요? 물론 그러한 소식을 허브 브라우저에 즉시 알리고 싶고 연구에 시간이 좀 걸릴 것입니다 (그래서 게시물이 한 줄이 아니도록).

둘째, 특정 주제에 열정을 갖고 깊이 이해한다면 이것도 훌륭합니다. 예, 매일 그것에 대해 글을 쓸 수는 없을 것이고, 더 자주 다른 일을 다루어야 할 것입니다. 그러나 무엇보다도 당신이 가장 좋아하는 주제가 나오면 그 지식이 도움이 될 것입니다. 여기에서 Oleg는 Graal 프로젝트가 유행하기 전부터 고민하고 있었기 때문에 Graal과 함께 일하는 Chris Thalinger에게 매개 변수 인라인과 같은 것에 대해 기꺼이 물었습니다. 음, 훌륭했습니다. 결국 Oleg와 이 주제에 관심이 있는 다른 사람들은 모두 관심 있는.

셋째, 다른 사람의 능력을 연결하여 자신의 능력에만 국한되어서는 안 됩니다. 예를 들어, 인터뷰 형식에서는 세상의 모든 답을 알 필요는 없지만 질문은 할 수 있습니다. 전 세계에서 가장 흥미로운 사람들이 .NET 전설에서 우리 컨퍼런스에 참석하여 연설합니다. 제프리 리히터 Kotlin의 선두에 앤드류 아브레슬라프 브레슬라프, 그런 질문을하지 않는 것은 죄입니다. 이는 완전한 승리/승으로 판명되었습니다. 면접관과 Habr 독자 모두 관심이 있습니다(우리 기록은 다음과 같습니다). интервью 같은 존 스키트, 조회수 60 회 이상), 발표자들은 일반적으로 컨퍼런스 전날 인터뷰를 기꺼이 진행하며 이는 컨퍼런스에 분명한 이점입니다.

물론 그러한 사람들에게 질문하려면 특정 지식도 필요하지만 요구 사항의 규모는 완전히 다릅니다.

다른 사람의 역량을 공유하는 또 다른 방법은 이미 언급된 보고서의 텍스트 사본입니다. 또한 우리 연사 중 한 명이 영어로 블로그 게시물을 게시하고 우리는 그와의 동의에 따라 해당 게시물을 러시아어로 번역합니다. 이런 경우에는 글을 이해해야 하지만 글을 쓸 수 있는 전문가가 될 필요는 없습니다.

이것이 무엇으로 연결 되는가?

내 경험에 비추어 볼 때, 이런 종류의 작업을 통해 IT를 다소 흥미로운 관점에서 바라볼 수 있다고 말하고 싶습니다.

일반적으로 이것은 공격적일 수 있습니다. 모든 곳에서 일종의 움직임이 일어나고 있고 사람들은 흥미로운 일을 하고 있으며 이 모든 것을 "외부에서" 보고 질문하고 결국에는 각각에 대해 뭔가를 이해합니다. 표면적으로는 이러한 것들이 있지만 구현의 세부 사항에서는 이미 이해하지 못하고 있습니다. 이를 파악하려면 지속적으로 작업해야 합니다. 심해에도 흥미로운 것들이 많이 있을 것입니다. 이 모든 것을 한 눈에 보는 것만으로도 당신을 유혹할 것입니다!

그러나 동시에 깊이가 상실되는 동안 적용 범위가 넓어지며 이는 또한 가치가 있습니다. 특정 프로젝트에서 특정 역할로 작업하는 경우 이 프리즘을 통해 모든 것을 볼 수 있습니다. 시야에 전혀 포함되지 않는 것, 측면에서 보는 것(“테스터는 내 아름다운 코드를 깨뜨리는 나쁜 사람들입니다. "). 그리고 다른 것에 대해 글을 쓸 때 "측면에서"가 아니라 조감도에서 매우 다른 것을 보게 됩니다. 세부 사항을 볼 수는 없지만 머리 속에 전체적인 그림을 얻을 수 있습니다. 저는 인터뷰와 컨퍼런스에서 컴파일러부터 테스터까지, Google 직원부터 스타트업까지, Kotlin으로 작성하는 사람부터 Kotlin 자체를 작성하는 사람까지 완전히 다른 많은 사람들과 이야기를 나눴습니다.

JS 개발자는 C++ 세계의 habrapost("거기에는 무엇이 있나요?")를 읽고 싶어할 수도 있지만, 주요 분야의 자료에 압도되어 이러한 비핵심 자료를 다루지 못할 것입니다. 저에게는 거의 모든 영역이 전문화되어 있으므로 개발 및 테스트에 관해 읽은 모든 텍스트가 업무에 유용할 수 있습니다.

나는 어떤 의미에서 매우 운이 좋다고 생각합니다. 대부분의 사람들과 달리 근무 시간 동안 나는 일반적인 발전이 어떻게 생활하고 발전하는지 관심을 가지고 지켜볼 수 있습니다.

우리에게 필요한 사람은 누구입니까?

이 모든 것에서 그러한 작업에는 다소 독특한 사람이 필요하다는 결론이 나옵니다.

그(또는 그녀)는 개발에 대해 잘 이해하고 있어야 하지만 동시에 개발 자체가 아닌 다른 일도 기꺼이 수행할 의지가 있어야 합니다.

개발을 이해하려면 코드 관점뿐만 아니라 커뮤니티 관점에서도 필요합니다. 개발자와 동일한 언어로 대화하고 그들이 걱정하는 것이 무엇인지 알아야 합니다.

주도성과 근면함의 조합이 필요합니다. 한편으로는 완료해야 하는 표준 작업이 있습니다(예: 전통적인 "지난 회의의 상위 10개 보고서" 게시물이 있습니다). 반면에, 우리는 단지 지시를 기다리지 않고 흥미로운 텍스트에 대한 아이디어를 직접 제공하기를 원합니다.

물론 글을 쓸 수 있어야 합니다. 읽고 쓰는 능력의 관점과 "흥미롭게 만드는 것"의 관점에서요. 우리는 딱딱한 기술 튜토리얼처럼 보일 뿐만 아니라 정말 마음을 사로잡는 텍스트를 중요하게 생각합니다. 예를 들어, 자료의 주제와 어느 정도 교차하는 개인적인 이야기가 있다면 훌륭한 소개가 될 수 있습니다.

유연성도 필요합니다. 현재 우리는 주로 .NET 텍스트 및 테스트에 관심이 있으므로 관련 역량을 가진 사람에게 특히 관심이 있지만 우선순위는 바뀔 수 있습니다. Habr 외에도 우리는 때때로 다른 사이트에 게시하며 이에 적응할 수도 있어야 합니다(본질은 "개발자를 위한 텍스트"로 유지되지만 형식은 다를 수 있음).

그리고 아무도 근무 시간 외에 일하도록 요구하지 않지만 여가 시간에 재미로 애완 동물 프로젝트에 참여하거나 IT에 대해 읽는 IT 괴짜들은 여기에서 자신의 위치에 있다고 느낄 것입니다. 이것이 업무 문제를 직접적으로 해결하지는 않지만 궁극적으로 더 효과적인 문제를 해결하는 데 도움이 됩니다.

위에 쓰여진 모든 내용이 당신을 겁주지는 않았지만 관심이 있었고 더 자세한 내용을 알고 싶거나 응답하고 싶다면 두 가지 모두 다음에서 수행할 수 있습니다. 공석 페이지.

출처 : habr.com