Algolia의 Sarah Dayan은 선임 엔지니어를 차별화하는 요소에 대해 설명합니다.

좋은 코딩 기술은 항상 높이 평가되지만 직원과 엔지니어가 되기 위해서는 기술 능력 이상의 것이 필요합니다. 거기에 도달하려면 무엇이 필요하며, 더 중요한 것은 조직에 가장 큰 영향을 미칠 수 있는 곳은 어디입니까?

엔지니어링 트랙에서 시니어 레벨에 도달하면 하드 스킬 세트에서 최적의 상태가 될 것으로 기대됩니다. 당신은 자율적이며 코드가 깨끗하며 소프트웨어 구축 및 배송에 대해 깊이 이해하고 있습니다. 그러나 스태프에 역할을 더하는 것은 완전히 또 다른 짐승입니다. 프로젝트 관리, 멘토링 및 교육, 의사 결정, 관계 구축이 있으며 회사에 제공하는 가치는 더 이상 코드 라인의 품질이 아니라 엔지니어링 조직을 발전시키는 것으로 측정됩니다.

오늘의 손님은 바로 그런 일을 겪었습니다. Sarah Dayan은 개발자가 API를 통해 자체 플랫폼에 색인 및 검색 기능을 구축하는 데 도움이 되는 "서비스로서의 검색" 플랫폼인 Algolia의 직원 엔지니어이자 두 가지 기술 팟캐스트인 Developer Experience 및 Entre Devs의 호스트입니다. 그녀는 사용자 경험, 디자인 및 구축에 대한 평생의 열정을 감안할 때 그녀에게 완벽하게 맞는 역할인 프론트 엔드 라이브러리를 만듭니다. 사실 Sarah는 부모님이 지하실에 광대역 인터넷을 설치한 이후로 웹사이트 제작에 집착해 왔습니다. 첫 클릭에 반했습니다. 그녀는 15세에 첫 phpBB 포럼을 구성했고, 얼마 지나지 않아 첫 HTML 페이지를 작성했으며, 그 이후로 계속해서 무언가를 만들고 있습니다.

엔지니어링에 대한 정규 교육을 받지 않았음에도 불구하고 Sarah는 프랑스 컨설턴트 Grand Manitou에서 개발자로 취직했습니다. 그리고 4년 전인 2018년, 그녀는 Algolia에서 소프트웨어 엔지니어로 취직했습니다. 그녀는 부지런히 승진하여 마침내 스태프 엔지니어의 개인 기여자 역할로 성장했습니다. 그리고 갑자기 지난 몇 년 동안 그녀가 관심을 가졌던 모든 것 – 더 나은 엔지니어가 되고, 더 나은 코드를 작성하는 것 – 은 새로운 도전을 위한 길을 열어주었습니다. 그녀는 회사에 올바른 기술 방향을 어떻게 제공할까요? 병목 현상을 차단 해제하시겠습니까? 다른 엔지니어들이 그녀를 위해 했던 것처럼 멘토링을 하고 다른 엔지니어들을 도우시겠습니까?

이 에피소드에서 우리는 Sarah와 함께 직원과 엔지니어 역할에 대한 다양한 뉘앙스, 숙련도 및 기대치에 대해 이야기했습니다.

다음은 대화에서 우리가 가장 좋아하는 내용입니다.

• 뒤처지고 싶지 않다면 계속 배우십시오. 다양한 관점과 배경을 가진 다른 엔지니어로부터 아이디어를 논의하고 피드백을 받으십시오.
• 직원 엔지니어로서 많은 에너지가 비전과 전략을 위한 팀 간 협업에 사용됩니다. 5년 후 회사는 어디로 갈까? 어떻게 거기에 갈거야?
• 직원 엔지니어를 멘토로 두는 것은 더 많은 후배들이 그 역할에 도달하기 위해 취해야 할 단계를 명확하게 하고 엔지니어링 리더를 만드는 프로세스를 빠르게 추적할 수 있도록 합니다.
• 일반적인 믿음과는 달리, 직원 엔지니어는 구조적 문제에 대한 빠른 수정이 아닙니다. 새로운 직업을 수락하기 전에 오해를 피하기 위해 당신에게 무엇을 기대하는지 물어보십시오.
• 직원 엔지니어는 회사의 목표를 달성하는 데 도움이 될 수 있도록 회사의 요구 사항을 이해해야 합니다. 온보딩하는 동안 최대한 많은 문서를 읽고 가능한 한 많은 사람들과 이야기하십시오.

토론이 재미있다면 팟캐스트의 더 많은 에피소드를 확인하세요. iTunes, Spotify, YouTube에서 팔로우하거나 선택한 플레이어에서 RSS 피드를 가져올 수 있습니다. 다음은 에피소드의 가볍게 편집된 대본입니다.

배움을 멈추지 마세요

Brian Scanlan: Sarah, 오늘 쇼에 함께 해주셔서 감사합니다. 당신과 이야기할 기회를 갖게 되어 기쁩니다. Algolia에서의 귀하의 역할과 업무에 대해 이야기하기 전에 지금까지의 여정에 대해 듣고 싶습니다. 오늘 당신이 있는 곳으로의 여행은 어떻게 시작되었나요?

Sarah Dayan: 글쎄요, 저를 만나주셔서 감사합니다. 글쎄요, 그것은 사실 재미있는 이야기입니다. 저는 현재 32살이고 15살 때 집에서 광대역 인터넷과 무제한 인터넷을 사용했습니다. 저는 항상 물건을 만드는 일에 관심이 많았고 웹사이트를 처음 봤을 때 "이렇게 하는 방법을 알아야 합니다."라고 생각했습니다. 한 일이 다른 일로 이어졌고 저는 phpBB로 첫 번째 포럼을 만들었습니다. PHP는 정말, 정말 컸고, 지금도 큽니다. 하지만 당시에는 실제로 웹용 언어였습니다.

“나는 이것이 내 일이 아니라 내가 좋아하는 일을 해야 한다고 결정했습니다. 그래서 저는 제가 좋아하는 웹사이트 구축으로 돌아갔습니다.”

그 당시에는 기술 분야, 특히 소프트웨어 엔지니어로 경력을 쌓는 것이 오늘날처럼 멋지고 뜨겁지 않았습니다. 부모님은 제가 학교에서 언어와 문학을 잘했기 때문에 기자가 되어야 한다고 생각하셨습니다. 그리고 그것이 내가 가장 먼저 한 일이었습니다. 저는 저널리즘 분야에서 첫 해를 보냈지만 완전히 실패했습니다. 그리고 나서 이것은 제 일이 아니라 제가 좋아하는 일을 해야 한다고 결정했습니다. 그래서 저는 제가 좋아하는 웹사이트 구축으로 돌아갔습니다. 나는 에이전시에서 첫 직장을 구했고 그곳에서 6년을 보냈다. 그것은 저에게 직업, 고객과 일하는 것, 자신이 무엇을 원하는지 아는 사람들, 원하는 것이 무엇인지 모르는 사람들과 일하는 것에 대해 많은 것을 가르쳐주었습니다. 그러다 스타트업의 세계로 넘어갔다. 저는 15년 넘게 코딩을 해왔지만, 전문적으로는 12년 동안 코딩을 해왔습니다. 이것이 제가 Algolia에서 현재 직책을 맡게 된 이유입니다. 나는 4년 동안 거기에 있었고 계산하고 있습니다.

브라이언: 슈퍼. 초기에 배운 흥미로운 교훈이 당신에게 붙어 있습니까?

Sarah: 저는 기술 분야에 대한 고전적인 길을 가지고 있지 않습니다. 저는 공과대학을 다니지 않았고, 그렇게 하지 않으면 기술 분야에서 훌륭한 경력을 쌓을 수 있습니다. 당신은 확실히 독학할 수 있고, 다른 사람들로부터 배울 수 있으며, 학위가 없어도 됩니다. 그러나 학위가 없다고 해서 배우지 못한 것에 대한 변명은 아닙니다. CSS-Tricks에 대한 Google의 엔지니어링 관리자인 Sarah Drasner의 훌륭한 블로그 게시물이 있습니다. 학위 없이 기술 분야에서 경력을 쌓을 수 있지만 지식을 배우고 추구하는 데 면제되지는 않습니다.

“나는 피드백을 받지 못했고, 다른 사람들, 즉 다른 엔지니어, 다른 관점, 다른 배경을 가진 사람들과 대화를 나누지 않았습니다. 그래서 뒤처졌다”

그리고 학교에서 실제로 배우는 한 가지는 배우는 것을 배우는 것인데, 그것은 정말 중요한 기술입니다. 제가 경력 초기에 말씀드린 회사에서 오랫동안 저 혼자만의 직원이었습니다. 나는 혼자였다. 그리고 제 상사도 코딩을 하고 있었지만 제가 하고 있는 일에서 약간 소외된 사람이었습니다. 그리고 혼자 작업하는 것이 자유로울 수 있지만 – 당신은 많은 신뢰와 많은 자유를 가지고 있습니다 – 당신은 피드백이나 자신의 관점 외에 다른 관점이 없기 때문에 빨리 배우지 못합니다. 그리고 적극적으로 배우지 않으면 뒤쳐지게 됩니다.

그것은 나에게 일어난 일 중 하나입니다. 나는 피드백을 받지 못했고, 다른 사람들과 대화를 나누지 않았습니다. 다른 엔지니어, 다른 관점, 다른 배경을 가진 사람들과 말이죠. 그래서 나는 뒤처졌다. 나는 내가 가진 지식에 의존하고 있었고, 그것이 효과가 있었기 때문에 다르게 일을 할 이유가 없었습니다. 그것은 내 경력 초기에 얻은 가장 큰 교훈 중 하나가 될 것입니다. 특히 기술에 대한 고전적인 여정이 없는 경우, 피드백과 그들의 관점을 제공하는 다른 사람들과 함께하는 것이 매우 중요하며, 이는 귀하의 경력에 ​​큰 힘이 될 것입니다.

Brian: 전문적인 역할을 하는 모든 사람에게 훌륭한 조언이라고 생각합니다. 하지만 당신에게는 정말 효과가 있었던 것 같습니다. 요즘 PHP로 작업하지 않는 것에 대해 그리워하는 것이 있습니까?

Sarah: PHP는 훌륭한 언어라고 생각합니다. 현대 JavaScript에서 PHP에서 많은 영감을 찾을 수 있습니다. JavaScript가 PHP를 사용하려는 모든 곳에서 사용할 수 있는 수준으로 발전했기 때문에 더 이상 사용하지 않습니다. 그리고 특히 프론트 엔드 엔지니어로서 공동 공유와 같이 프론트 엔드와 백 엔드에서 동일한 언어를 사용하면 많은 이점이 있습니다. 하지만 PHP는 훌륭한 언어라고 생각합니다. 그것은 많은 나쁜 농담과 "오, PHP는 죽었습니다."하지만 Laravel과 같은 것의 성공을 볼 때 PHP가 죽지 않은 것처럼 느낍니다.

제가 PHP에 입문했을 때 진지한 사람들이 사용하는 프레임워크를 Zen 프레임워크라고 했습니다. 사실 저는 Zen이 PHP를 지원하는 회사이거나 적어도 PHP를 되찾은 회사라고 믿습니다. 적어도 새로운 프로젝트에서는 더 이상 Zen 프레임워크를 사용하는 사람이 없지만 PHP가 현재 어디에 있는지 확인하는 것은 좋습니다. 여전히 번창하고 있고, 사람들이 PHP로 코딩하는 것을 즐기고 있고, 그것이 훌륭하다고 생각합니다. 모든 사람을 위한 것은 아니지만 당신도 마찬가지입니다. 누구나 자신이 좋아하는 언어로 테이블에 앉을 수 있습니다.

엔지니어링 사다리 오르기

Brian: 당신은 현재 Algolia의 직원 엔지니어입니다. 그 역할과 어떤 일을 하시는지 말씀해 주시면 스태프 엔지니어가 무엇인지 설명드리겠습니다.

사라: 물론이죠. 저는 직원 엔지니어이며 프런트 엔드에서 일합니다. 저는 프론트엔드 경험, 줄여서 FX라는 팀에 소속되어 있으며 Algolia용 프론트엔드 라이브러리를 작업하고 있습니다. Algolia는 검색 엔진이므로 종단 간입니다. 검색할 데이터를 보낼 수 있는 여러 언어로 된 엔진과 일부 API 클라이언트가 있지만 액세스 가능한 작업 검색 상자, 조회 목록, 구체화 목록 또는 계층 메뉴?

이 모든 것들은 제대로 구현하기 어렵습니다. 그래서 우리는 고객을 위해 그 일을 하고 있고, 그것이 바로 제가 일하고 있는 팀입니다. 저는 개인 기여자(IC)이며 리더십 트랙에 있지 않습니다. 그러나 문제는 IC로서 더 높은 역할로 성장함에 따라 현실이 리더십 역할과 약간 혼합된다는 것입니다. 나는 보고서가 없고 아무도 관리하지 않지만 사물의 비전 측면에 더 많은 주제에 대해 관리자와 많은 시간을 보냅니다. 하지만 나는 여전히 매일 코딩을 하고, 다른 사람들처럼 리뷰를 하고 리뷰를 받습니다. 그래서 여전히 IC 역할입니다. Algolia에서는 꽤 고급 수준으로 성장할 수 있으며 매일 코드를 작성하는 개별 기여자로 남을 수 있습니다.

"상급 이상이라면 전략에 많은 에너지를 쏟아붓기 시작합니다. 비전은 무엇이며, 5년 후 제품은 어디로 갈 것이며, 우리는 그 일에서 어떻게 성공할 것입니까?"

Brian: 나머지 작업에 비해 배송에 얼마나 많은 시간을 할애한다고 생각하십니까? 컨텍스트 공유, 전략 작업, 그런 종류의 작업.

Sarah: 측정하기 어렵습니다. 나는 50/50이라고 말하고 싶다. 제가 코딩을 많이 할 때가 있는데, 여러분이 사용하는 것과 같은 에너지이기 때문에 코딩에 리뷰를 포함합니다. 그러나 또한 PM, 연구원, 디자이너와 함께 작업하는 것과 같이 전략을 세우는 데 많은 시간, 많은 회의, 많은 비전 문서, 많은 생각, 피드백을 수집하기 위한 많은 대화가 있습니다. 이 모든 것이 업무의 일부입니다. . Algolia에는 고위 직원, 교장 등이 있습니다. 고위직 이상이라면 전략에 많은 에너지를 쏟아붓기 시작합니다. 비전은 무엇이며, 5년 후 제품은 어디에 있으며, 우리는 이러한 일에서 어떻게 성공할 것입니까? 성공하지 못한 경우 백업 계획이 있는지 어떻게 확인할 수 있습니까? 시니어 엔지니어일 때 코딩과 같은 프로젝트에 적용할 수 있는 모든 것을 제품 전략에 적용합니다. 당신은 제품에 대해 많은 일을 하고, 그것은 내가 기술 스타트업에서 일할 때 가장 좋아하는 것 중 하나입니다.

내가 기획사에 있을 때, 당신은 어떤 전략도 하지 않았고, 당신이 생각한 것을 말하지 않았고, 당신은 당신이 반드시 조언을 줄 것이라고 기대하지 않았습니다. 당신은 당신이 말한대로했습니다. 하지만 스타트업의 엔지니어, 특히 그런 수준의 엔지니어라면 목소리와 비전이 매우 중요합니다. 엔지니어를 위한 제품을 만들고 있습니다. 그리고 우리가 스스로 무언가를 만들지 않도록 매우 조심해야 하지만 – 우리는 지식의 저주를 가지고 있고, 제품을 알고, 사용하는 방법을 알고, 모든 주의 사항을 알고 있습니다 – 우리는 여전히 엔지니어가 관심을 갖는 것에 민감합니다. 무엇을 원하는지, 무엇이 그들의 삶을 쉽거나 힘들게 만들지. 따라서 제품, 아이디어를 테이블로 가져오는 것, 도전적인 아이디어, 오래 지속되는 최고의 제품을 만드는 데 매우 중점을 둡니다.

“더 나은 엔지니어가 되는 방법에 대해 몇 년을 고민한 후에 다른 것에 대해 생각하기 시작하려면 사고 방식의 전환이 필요합니다. 다른 사람들을 어떻게 도울 수 있습니까? 상황 차단을 해제하려면 어떻게 해야 합니까?”

Brian: 조직이나 팀 이외의 다른 직원 및 수석 엔지니어와 작업하는 데 얼마나 많은 시간을 할애합니까? 회사에서 활동하는 커뮤니티입니까? 그와 함께 작업을 많이 하게 됩니까? 당신은 주로 그룹에서 독립적으로 일합니까? 아니면 함께 일하고 있는 다른 고위 직원 엔지니어의 하위 집합이 있습니까?

사라: 내가 원하는 만큼은 아닙니다. 어느 조직에서나 높은 수준으로 올라갈수록 더 적은 수의 사람들이 있습니다. 따라서 IC 5, IC 6, 직원 및 교장이 많은 것은 아닙니다. 지금은 선배를 많이 채용하고 있어서 6개월 후에는 제 답변이 달라질 수 있습니다. 다른 스태프나 수석 엔지니어들과 이야기하는 데 보통의 시간을 보냈지만, 우리가 그렇게 많지 않다고 해서 커뮤니티나 공식적인 것이 없는 것은 아닙니다. 지금은 제 역할의 일부이기 때문에 선배 이상의 사람들과 토론하는 데 많은 시간을 할애했습니다.

내 역할의 일부는 고위직에 있는 사람들이 성장하고 직원 수준으로 승진하도록 돕는 것입니다. 많은 회사, 특히 Algolia의 규모의 선임 엔지니어로서 여러분은 거기에 도달하기 위해 무엇을 해야 하는지 알고 있습니다. 체크리스트에 가깝습니다. 그 다음부터는 해석에 맡길 수 있는 일들이 많고, 성격에 따라 다른 사람과 아주 다르게 할 수 있는 일들이 많기 때문에 더 복잡해집니다. 그러나 아이디어는 당신이 상급자 수준에 도달했을 때 우리는 당신이 당신의 어려운 기술 세트에서 최적의 상태가 되기를 기대한다는 것입니다. 우리는 당신이 훌륭하고 특정 기술 수준에 있다는 것을 알고 있으며 그 이상으로 성장할 것으로 기대하지 않지만 다른 종류의 기술을 개발하라는 요청을 받게 될 것입니다.

“당신이 잘하는 일, 하고 싶은 일, 당신을 빛나게 해줄 일이 무엇인지 찾아내야 합니다. 많은 멘토링이 필요하다”

더 나은 엔지니어가 되는 방법, 더 나은 코드를 작성하는 방법, 더 나은 리뷰를 작성하는 방법 또는 리뷰를 받았을 때 댓글을 줄이는 방법에 대해 몇 년을 보낸 후 다른 것에 대해 생각하기 시작하려면 사고 방식의 전환이 필요합니다. 다른 사람들을 어떻게 도울 수 있습니까? 상황 차단을 해제하려면 어떻게 해야 합니까? 나만의 워크로드를 만들려면 어떻게 해야 합니까? 이러한 수준에 도달하기 전에 반드시 생각해야 하는 것은 아닙니다. 나는 사람들이 그것에 접근하고, 그 의미를 이해하고, 거기에 도달하기 위해 사용할 수 있는 성격의 일부를 이해하도록 돕습니다.

예를 들어, 어떤 사람들은 무대에 서서 이야기하는 것을 좋아합니다. 그리고 이것이 그들이 좋아하는 것이라면, 나는 그들이 더 나은 회의 계약을 체결하고 더 나은 문서 요청서를 작성하도록 도와야 합니다. 그러나 이것이 당신의 것이 아니라면 우리가 그것에 투자해야 할 이유가 없습니다. 자신이 잘하는 것, 하고 싶은 것, 빛나게 해줄 수 있는 일을 찾아 육성해야 합니다. 많은 멘토링이 있습니다. 이것은 이 상급자 수준에서 내가 가장 좋아하는 부분 중 하나입니다.

회사의 경우 한 명의 직원이나 한 명의 수석 엔지니어가 있는 것은 그다지 흥미롭지 않습니다. 여러분은 3, 5, 8, 16명을 원합니다. 그리고 그렇게 할 수 있는 유일한 방법은 이미 한 단계 낮은 사람들을 도와줍니다. 엔지니어링 관리자가 전체 팀과 함께 혼자서 모든 작업을 수행할 것으로 기대할 수는 없습니다. 다른 엔지니어가 1년 또는 2년 전에 했던 작업을 도와주는 엔지니어가 있으면 이러한 승수 효과가 나타납니다. 그리고 저는 이것이 사람들에게 정말 짜릿한 일이라고 생각합니다. 왜냐하면 그들은 같은 조직에서 실제로 그 과정을 겪은 사람들로부터 배울 수 있기 때문입니다. 그들이 그 단계를 따르고 경청한다면 효과가 있을 것이라는 확신이 있습니다. 나는 거기에 도달하기 위해 내가 무엇을 해야 하는지 이해하는 데 도움을 줄 수 있는 수석 엔지니어들로부터 배우고 싶습니다.

그들이 실제로 한 일을 해부할 수 있기 때문에 가르치는 사람에게 특히 흥미롭습니다. 나중에는 흐릿해져서 "예, 저는 이것만 조금 했습니다. 저것도 조금 했습니다."라고 말합니다. 아뇨. 무슨 짓을 한 겁니까? 구체적으로 어떤 조치를 취했습니까? 당신이 예라고 말한 것들은 무엇입니까? 당신이 하지 말라고 한 것들은 무엇입니까? 아이디어를 명확하게 하고 프로세스를 명확하게 하고 다음 아이디어를 위해 더 효율적으로 만드는 데 도움이 된다고 생각합니다.

온보딩 직원 및 엔지니어

Brian: 새로운 직원과 수석 엔지니어를 조직에 온보딩하는 것이 상당히 까다로울 수 있다고 언급하셨습니다. 당신이 경험한 것이 있습니까?

Sarah: 솔직히 말해서 이것은 우리가 많이 한 것이 아닙니다. 우리 팀에는 3~4명의 수석 엔지니어가 있으며 모두 내 팀에 속해 있지 않습니다. 내가 가진 경험은 주로 선임 엔지니어를 데려온 것입니다. 이제 모든 사람에게 공통적인 것이 있고 수석 엔지니어에게 흥미로울 수 있는 것이 있으며 나는 여전히 그것을 시도하고 찔러볼 수 있습니다.

“아주 아주 고위직이 많은 일을 도와줄 수 있지만 회사나 팀의 구조적 문제를 해결하지는 않을 것입니다.”

명료성은 매우 중요하며, 물론 직원이나 수석 엔지니어를 고용할 때 동일한 손을 잡는 것을 기대하지는 않습니다. 당신은 그들이 스스로 시작하기를 원합니다. 명확성은 당신에게 무엇을 기대하는지, 모든 작업 등에 대한 것이 아니라 사명에 대한 감각을 제공하는 것입니다. 여기서 당신의 목적은 무엇입니까? 여기서 뭐해? 그리고 이것은 인터뷰 수준에서 시작한다고 말하고 싶습니다. 직원이나 회사에 입사하는 수석 엔지니어에게 추천하는 것은 때때로 사람들이 자신의 문제를 해결하기 위해 매우 고위직을 고용하려고 하기 때문에 이에 대해 물어보는 것입니다. 그들은 "오, 우리가 모르는 것을 알고 있기 때문에 아주 아주 나이 많은 사람을 고용합시다." 그리고 그것은 사실이 아닙니다. 아주 아주 선임이 많은 일을 도와줄 수 있지만 회사나 팀의 구조적 문제를 해결하지는 않습니다.

그리고 다른 한편으로 엔지니어링 관리자는 왜 그 사람이 필요하다고 생각하는지 궁금해해야 합니다. 대부분의 경우 뛰어난 코딩 능력을 위해 이 수준의 사람을 고용하지 않습니다. 팀에 선임 엔지니어가 있다면 Algolia의 IC 4가 될 것입니다. 그들은 이미 코딩 면에서 완벽하거나 최소한 그래야 합니다. 직원이나 수석 엔지니어는 여러분이 하고 싶은 일에 대한 경험을 갖고 있으며, 예를 들어 팀의 누구도 이전에 도달하지 못한 규모에 도달해야 한다는 것을 알고 있을 때 필요할 수 있습니다. 어쩌면 당신은 그것을 알아낼 수 있지만 가속기를 원하고 이것은 매우 고위급 사람이 팀에서 할 일입니다.

사전에 이러한 질문을 하는 것은 예상되는 내용에 불일치가 없는지 확인하는 좋은 방법입니다. 당신이 아주 고위직이고 정렬이 잘못되었다는 이유로 코딩을 하거나 고위직에서 일하도록 요청받는다면 실망하고 떠날 가능성이 큽니다. 비용이 많이 들기 때문에 이 수준의 사람을 고용하는 데 많은 시간을 소비하고 싶지는 않습니다.

그 다음에는 이 직급에 있는 사람이 책을 많이 읽고 대화를 많이 하기를 기대합니다. 이것은 당신이 주니어 엔지니어일 때 일반적으로 하지 않는 일입니다. 조직에 와서 첫 번째 작업이 주어지고 그냥 흐릅니다. 작업을 시작하고 코딩을 시작하고 이것이 다음 단계로 이동할 것이기 때문에 해야 하는 일입니다.

“당신의 역할은 전달된 제품이 적합하고 확장될 수 있도록 하는 것입니다. 그리고 회사에서 다른 사람들과 논의하지 않으면 그렇게 할 수 없습니다.”

그러나 당신이 그 고위급에 있을 때, 당신이 어디에 있는지, 무슨 일이 일어나고 있는지, 누가 무엇을 하는지 이해하는 것이 중요합니다. 다른 엔지니어 및 고위 직원뿐 아니라 후배, 제품 관리자, 디자이너 및 연구원과도 관계를 구축해야 합니다. 회사가 작동하는 방식과 거기에 어떻게 부합할 수 있는지, 무엇을 개선할 수 있는지 이해해야 합니다. 내부 문서로 작성된 문서가 있으면 읽고, 다 작성했으면 다시 읽으십시오.

그런 다음, 만나야 할 사람들이 누구인지 엔지니어링 관리자에게 문의하십시오. 새로운 사람과 이야기할 때마다 당신이 이야기하고 싶은 사람이 누구인지 물어보십시오. 이것은 당신이 관계를 만들고 무슨 일이 일어나고 있는지 이해할 것이기 때문에 당신에게 날개를 줄 것입니다. 제품은 무엇입니까? 현재 투쟁은 무엇입니까? 어디에서 도울 수 있습니까? 그리고 당신의 팀과 당신이 만들고 있는 제품이 그 계획에 어떻게 들어맞습니까? 이러한 수준에서 제품에 초점을 맞추면 더 이상 코드 품질에 관한 것이 아닙니다. 팀 선배들이 이미 그런 부분을 잘 챙겨주고 있고 잘하고 있다. 귀하의 역할은 전달된 제품이 적합하고 확장될 것인지 확인하는 것입니다. 그리고 회사의 다른 사람들과 논의하지 않으면 그렇게 할 수 없습니다.

새로운 도전

Brian: 모르는 청취자를 위해 Algolia는 강력한 호스팅 검색 API입니다. 겉으로 보기에는 꽤 성공한 회사처럼 보이지만 마음속에는 많은 도전과 과제가 있을 것입니다. 당신이 생각하고 있거나 작업하고 있는 큰 문제에 대한 아이디어를 알려주시겠습니까?

"아이디어는 해당 데이터를 검색하고 가져오고 페이지에 도달하기 위해 어떤 경로를 택하든지 올바른 데이터가 표시된다는 것입니다."

Sarah: 말씀하신 대로 Algolia는 호스팅 검색 API입니다. 이것이 우리가 가진 가장 큰 API이며 현재로서는 가장 성공적이지만 약간 확장하기도 했습니다. 현재 검색에 사용하는 것과 동일한 데이터 세트를 사용하지만 주어진 제품을 기반으로 추천하는 Algolia Recommend라는 제품이 있습니다.

Algolia의 요점은 검색뿐만 아니라 콘텐츠를 표면화하는 것입니다. 많은 콘텐츠가 있지만 모든 콘텐츠가 같은 사람들에게 동시에 관련이 있는 것은 아닙니다. 아이디어는 해당 데이터를 검색하고 가져오고 페이지에 도달하기 위해 어떤 경로를 선택하든 올바른 데이터가 표시된다는 것입니다. 이것이 Algolia의 포인트입니다. 그에 따른 과제가 있습니다. 우리는 검색 전문가이지만 추천 및 머신러닝 측면은 훨씬 새로운 기술이기 때문에 최신 정보로 학습하고 있습니다. 검색에 비해 배울 것이 많습니다. 이것이 가장 큰 도전은 아니지만 검색으로 얻은 것과 동일한 성공을 반복할 수 있는지 확인하는 것은 여전히 ​​도전입니다.

이제 Algolia가 잘하지 못하는 것이 있습니다. 데이터베이스가 아니라 검색 엔진입니다. 속도가 빨라지고 결국에는 일관성이 있게 되지만 모든 데이터를 보유할 것이라는 보장, 데이터가 항상 일관성이 있다는 보장, 또는 모든 데이터가 거기에 있을 것이라는 보장은 없습니다. 그것은 검색 엔진을 중심으로 한 디자인 선택으로 데이터베이스와 매우 다릅니다. 즉, Algolia에 데이터를 보내기가 매우 쉽고 거기에 있고 빠르기 때문에 많은 사람들이 Algolia를 데이터베이스로 사용하는 것을 좋아합니다. 아마도 주변에서 배울 것이 있을 것입니다. 아마도 데이터베이스가 될 수도 있고, 그렇게 될 것이라고 말하지는 않지만 아마도 그럴 수 있습니다. 어쩌면 우리가 이해하고 연구해야 할 다른 것이 있을지도 모릅니다.

Algolia가 사용할 수 없는 많은 사용 사례가 있습니다. 그 중 하나가 예약 사용 사례입니다. 에어비앤비를 예약하려는 경우 검색할 때 결과에 ​​표시되며, 이는 에어비앤비를 사용할 수 있음을 의미합니다. 그러나 페이지에 도달하자마자 데이터베이스에서 Algolia로 데이터를 복제하기 때문에 더 이상 사용할 수 없습니다. 데이터베이스에 무언가를 저장할 때 변경 사항을 약간 다른 형식으로 Algolia에 보낼 것입니다. 그리고 실시간이 아닌 지연이 있기 때문에 예약 사용 사례와 같은 것이 작동하지 않습니다. 에어비앤비를 다룰 때 지금 사용 가능한 것이 30초 안에 사용 가능하지 않을 수 있지만 저장했을 때 전파되는 데 10초 정도가 필요하기 때문에 검색 엔진에 계속 나타날 수 있습니다. Algolia, 그리고 아마도 실패했고 다시 해야 합니다. 그것들은 우리가 생각하고 있는 검색 엔진 수준의 것들입니다. 우리가 지원할 수 있는 일입니까? 말도 안되는 소리인가요? 그 뒤에 숨겨진 비즈니스 사례는 무엇입니까? 많은 일을 하기 때문입니다.

“눈에 보이지 않아야 합니다. 그것은 원활해야합니다. 그것들이 별도의 API라는 사실은 당신의 문제가 아닙니다. 그것이 우리가 해결해야 할 문제”

이제 프론트엔드 팀에 대해 Algolia Recommend에 대해 언급했습니다. 당신이 고객일 때, 당신은 다른 제품이 있다는 사실에 별로 신경 쓰지 않습니다. 이러한 기능이 포함된 Algolia Search와 해당 하위 기능이 포함된 Algolia Recommend가 있는지 여부는 중요하지 않습니다. Algolia를 구독하고 함께 잘 작동하는 기능 세트에 대해 월별 또는 연간 요금을 지불합니다. 이 API와 데이터 API 사이에 내부적으로 생성한 인위적인 경계를 이해하고 싶지도 않고 이해할 필요도 없습니다.

"조직도를 보내지 마세요"라는 말이 있는데 이것이 우리의 다음 큰 주제 중 하나라고 생각합니다. Algolia 프론트엔드 라이브러리를 사용할 때 프론트 엔드에서 이것이 필요한지 저것이 ​​필요한지 궁금해하지 않아도 되도록 하려면 어떻게 해야 할까요? 당신은 그 경계를 느끼지 않습니까? 보이지 않아야 합니다. 그것은 원활해야합니다. 그것들이 별도의 API라는 사실은 당신의 문제가 아닙니다. 그것이 우리가 해결해야 할 문제입니다.

우리는 검색 API와 정말 강력하게 결합된 라이브러리를 만들었으며 이제 함께 작동할 수 있는 최신 API로 확장해야 하며 때로는 하나를 호출한 다음 최종 응답을 얻기 위해 다른 API를 호출해야 합니다. 현재 이러한 모든 것들이 우리가 원하는 만큼 매끄럽지 않습니다. 이러한 API를 함께 연결하려는 경우 여전히 가장자리가 약간 거칠습니다. 가능하지만 튜토리얼을 읽고, 따라하고, 여기저기서 약간의 변경을 수행하고, 일부 상용구 코드를 작성해야 합니다. 이것은 유쾌하지도 않고, 재미도 없고, 너무 많은 작업입니다. "해당 라이브러리를 사용하십시오"라고 말하면 사용자가 원하지 않는 작업을 수행해야 합니다. 하위 수준의 기본 요소가 사용하기 쉽다면 라이브러리를 사용할 이유가 없겠죠?

현재 가장 큰 과제 중 하나는 라이브러리의 가치를 높이는 것입니다. 그들은 이미 대부분의 사람들이 하고 싶지 않은 많은 일을 하고 있지만 특정 고객의 경우 특정 시점에서 검색만 했을 때만큼 매끄럽고 유쾌하지 않습니다. 그리고 이것이 우리가 추구하는 느낌입니다. "와, 생각했던 것보다 훨씬 간단하다"는 느낌.

브라이언: 마지막으로 청취자들이 당신의 소식을 따라갈 수 있는 곳은 어디인가요?

Sarah: 트위터에서 저를 찾을 수 있습니다. 저는 frontstuff_io입니다. 나는 이것이 트위터에서 최악의 핸들이라는 것을 고통스럽게 알고 있습니다. 원하는 경우 sarahdayan.com에서 나를 찾고 GitHub에서 팔로우할 수도 있습니다. 나는 때때로 일을 저지릅니다. 하지만 네, 채팅을 하고 싶다면 제 DM이 열려 있다고 생각하니 무엇이든 보내주세요.

브라이언: 슈퍼. Sarah, 오늘 저와 함께해주셔서 정말 감사합니다.

사라: 데려가줘서 고마워. 재미있었어요.