• An answer to "What makes a good engineering culture?" by Edmond Lau, Quora Engineer

  • "무엇이 좋은 엔지니어링 문화를 만드는가?"에 대한 Quora 엔지니어 Edmond Lau의 답변

  • One of my favorite interview questions for engineering candidates is to tell me about one thing they liked and one thing they disliked about the engineering culture at their previous company. Over the course of a few hundred interviews, this interview question has given me a sense of what good engineers look for and what they're trying to avoid. I also reflected back on my own experiences from the past six years working across Google, Ooyala, and Quora and distilled some things that a team can do to build a good engineering culture:
  • 나는 엔지니어들을 면접할 때 지원자들에게 이전 직장의 엔지니어링 문화 중 어떤 것이 좋았고 어떤 것이 싫었는지 즐겨 물어본다. 수백 명을 면접하면서 나는 이 질문을 통해 좋은 엔지니어들이 무엇을 원하고 어떤 것을 기피하는지에 대한 감각을 얻었다. 또한 나는 지난 6년간 구글, Ooyala 그리고 Quora에서 일한 경험을 통해 좋은 엔지니어링 문화를 만들기 위해 팀이 할 수 있는 것들을 정리해 봤다.
  • note icon
    engineering culture를 '개발 문화'라고 번역하신 분도 보았는데, 개발은 프로그래밍에 국한되는 반면 엔지니어링은 개발 뿐 아니라 네트워크, 운영 등 더 넓은 범위를 포함한다고 생각되어 그냥 '엔지니어링 문화'라고 했습니다.
  • 1. Optimize for iteration speed.
  • 1. 반복 속도를 최적화하라
  • note icon
    소프트웨어 개발에서의 이터레이션(Iteration, 반복)이란, 짧은 개발주기(코딩-테스팅-디버깅-배포)를 반복하며 개발하는 방법을 말합니다.
  • Quick iteration speed increases work motivation and excitement. Infrastructural and bureaucratic barriers to deploying code and launching features are some of the most common and frustrating reasons that engineers cite during interviews for why they're leaving their current companies.
  • 반복 속도가 빠르면 일에 동기부여가 되고 재밌어진다. 코드를 배포하고 기능을 추가하는데 있어 구조적이고 관료적인 장벽들이 바로 엔지니어들이 지금 다니는 회사를 떠나려는 이유 중 가장 흔하고 좌절감에 빠지게 하는 이유였다.
  • Organizationally, quick iteration speed means giving engineers and designers flexibility and autonomy to make day-to-day decisions without asking for permission. While I was at Google, any user-visible change to search results, even for low-traffic experiments, required Marissa Mayer's approval at a weekly UI review. Needless to say, while this allowed Google to protect its search brand, it significantly hampered innovation. Optimizing for iteration speed also means that there are well-defined processes for launching products, so that cancellations don't happen unexpectedly after significant time investment.
  • 조직적인 관점에서, 빠른 반복 속도는 엔지니어와 디자이너에게 일상적인 결정들에 대해 일일이 허락을 구하지 않을 수 있는 유연성과 자율성을 부여한다. 내가 구글에 있을 때는 검색결과에 사용자가 볼 수 있는 어떠한 변화라도, 심지어 방문자가 적은 실험에 대해서도, 주간 UI 리뷰에서 Marissa Mayer의 승인을 받아야 했다. 말할 것도 없이 이것은 구글이 검색 브랜드를 보호하기 위한 것이었지만, 분명히 혁신을 방해했다. 반복속도를 위한 최적화는 또한 제품을 출시하기 위해 잘 정의된 프로세스가 있고, 많은 시간을 쏟아부은 후에 예상치 못하게 취소되는 경우가 생기지 않는다는 것을 뜻한다.
  • Infrastructurally, optimizing for iteration speed means building out continuous deployment with a fast deployment process, high test coverage to reduce build and site breakages, fast unit tests so that people run them, and fast and incremental compiles and reloads to reduce development time. Continuous deployment, where commits go immediately to production, deserves a special mention. Prior to using it at Quora, it would've been hard for me to internalize that the benefits it provides toward iteration speed outweigh the risks of site breakages, at least for small engineering teams. People are more excited about features and incentivized to fix bugs because changes see live traffic quickly. It's also significantly easier to reason about and pinpoint the source of errors for a narrow window of committed code rather a week or more's worth of batched changes.
  • 구조적인 관점에서, 반복속도를 위한 최적화는 빠른 배포 프로세스, 빌드 실패와 웹사이트 오류를 줄여주는 높은 테스트 커버리지, 빠른 유닛 테스트에 기반한 지속적인 배포(continuous deployment)를 통해 TODO
  • Team-wise, fast iteration speed means having a set of strong leaders to help coordinate and drive team efforts. Key stakeholders in a decision need to decide effectively and commit to their choices. To borrow a phrase from Bill Walsh, a leader who coached the 49ers to 3 Super Bowls, strong leaders need to "commit, explode, recover," which means committing to a plan of attack, executing it, and then reacting to the results.  A team crippled with indecisiveness will just cause individual efforts to flounder. [1]
  • 팀의 관점에서, 빠른 반복 속도는 팀의 노력을 잘 조정하고 이끌어가는 강한 리더들을 뜻한다. 주요한 의사결정권자들은 효율적으로 판단을 내리고 그 결정에 충실해야 한다. 3번의 수퍼볼에서 49ers를 지도했던 Bill Walsh의 말을 빌리자면, 강인한 지도자는 "수행하고, 폭발하고, 회복한다,"고 한다. 다시 말하면 공격을 계획하고 이를 실행하며 결과에 반응한다. TODO
  • note icon
    49ers는 샌프란시스코를 기반으로 하는 미식축구팀입니다.
  • 2. Push relentlessly toward automation.
  • 2. 자동화를 위해 끊임없이 노력해라
  • In his tech talk "Scaling Instagram", Instagram co-founder Mike Krieger cited "optimize for minimal operational burden" as a key lesson his 13-person team learned in scaling the product to tens of millions of users. [2] As a product grows, so does the operational burden per engineer, as measured by the ratio of users to engineers or of features to engineers.  Facebook, for example, is well-known for touting scaling metrics like supporting over 1 million users per engineer. [3]
  • 인스타그램의 공동창업자 Mike Krieger는 "인스타그램 확장하기(Scaling Instagram)"이라는 발표에서 "운영 부담을 최소화"한 것을 단 13명의 팀으로 수백만의 사용자에 맞도록 제품을 확장한 비결로 들었다. 제품이 성장할 수록 엔지니어당 운영 부담도 늘고, 엔지니어당 사용자수 혹은 기능당 엔지니어수도 늘어난다. 페이스북은 한 명의 엔지니어가 1백만이 넘는 사용자를 지원하는 것으로 잘 알려져 있다.
  • Automating solutions and scripting repetitive tasks are important because they free up the engineering team to work on the actual product. Ensuring that services restart automatically if possible when they fail and that services are easily and quickly replicated at peak traffic is the only sane way to manage complexity at scale. In the short-term, there's always the tempting tradeoff of applying a quick band-aid manually rather than automating and testing a long-term fix.
  • 해법을 자동화하고 반복적인 작업을 스크립트로 만들면 엔지니어링 팀이 실제적인 일을 할 수 있도록 자유로워진다. 가능하다면 서비스에 문제가 있을때 자동으로 재시작하고 트래픽이 급증하면 빠르게 복제하도록 만드는 것이 확장되는 서비스의 복잡성을 관리할 수 있는 유일한 방법이다. 단기적으로는 자동화하고 테스팅하는 근본적인 해결책보다는, 빠르게 적용할 수 있는 임시방편에 대한 유혹이 항상 있게 마련이다.
  • note icon
    복제(replicate)란, 같은 일을 하는 새로운 서버를 만드는 작업.
  • Etsy's motto of "measure anything, measure everything" [4] and its support of open-source monitoring and charting tools like graphite [5] and statsd [6] highlight an important aspect of automation -- that automation must be driven by data and monitoring. Without monitoring and logs to know what, how, or why something is going wrong, automation is difficult. A good follow-up motto would be to "measure anything, measure everything, and automate as much as possible."
  • Etsy의 "무엇이든 측정하고, 모든 것을 측정한다"는 모토 그리고 Graphite나 statsd 같은 오픈소스 모니터링, 차트 도구는 자동화의 중요한 점을 강조한다. 바로 자동화는 데이터 그리고 모니터링에 의해 수행되어야 한다는 점이다. 모니터링과 무엇이 어떻게 왜 잘못됐는지에 대한 로그기록 없이는 자동화가 어렵다. 모토에 하나 덧붙이자면 "무엇이든 측정하고, 모든 것을 측정하라. 그리고 가능한한 자동화하라."가 어떨까?
  • 3. Build the right software abstractions.
  • 3. 소프트웨어에 대한 올바른 추상적 개념을 만들어라
  • MIT Professor Daniel Jackson captures the importance of software abstractions well [7]:
  • MIT의 교수 Daniel Jackson은 소프트웨어 추상화의 중요성에 대해 다음과 같이 말했다.
  • "Pick the right ones, and programming will flow naturally from design; modules will have small and simple interfaces; and new functionality will more likely fit in without extensive reorganization. Pick the wrong ones, and programming will be a series of nasty surprises: interfaces will become baroque and clumsy as they are forced to accommodate unanticipated interactions, and even the simplest of changes will be hard to make."
  • "제대로된 것을 고른다면 프로그래밍은 디자인으로부터 자연스럽게 흘러갈 것이다. 모듈은 작고 단순한 인터페이스를 가지고, 새로운 기능은 별다른 재편성 없이도 맞아들어갈 것이다. 잘못된 것을 고르면, 프로그래밍은 형편없는 놀래킴의 연속이 될 것이다. 인터페이스는 복잡하고 어설퍼서 기대하지 않은 반응을 할 것이다. 게다가 단순한 변경조차 하기 어려울 것이다."
  • Part of what allowed thousands of engineers to build scalable systems at Google is that really smart engineers like Jeff Dean and Sanjay Ghemawat built simple but versatile abstractions like MapReduce [8], SSTable [9], protocol buffers [10], and the like. Part of what allowed Facebook engineering to scale up is the focus on similarly core abstractions like Thrift [11], Scribe [12], and Hive [13].  And part of what allows designers to build products effectively at Quora is that Webnode and Livenode [14] are fairly easy to understand and build on top of.
  • 구글에서 수천명의 엔지니어들이 규모가변적인 시스템을 구축할 수 있도록 한 것 중 일부는 Jeff Dean이나 Sanjay Ghemawat 같은 똑똑한 엔지니어들이 MapReduce, SSTable, protocol buffers와 같은 단순하면서 여러 곳에 쓰일 수 있는 추상화된 개념을 만들었기 때문이다. 페이스북을 확장하게 한 것 중 일부 역시 Thrift, Scribe, Hive와 같은 주요 추상화 개념들에 대한 집중이다. 마찬가지로 쿠오라의 디자이너들이 효율적으로 제품을 만들도록 한 것 역시 Webnode나 Livenode와 같이 쉽게 이해하고 그 위에 무언가를 구축할 수 있는 것들이다.
  • Keeping core abstractions simple and general reduces the need for custom solutions and increases the team's familiarity and expertise with the common abstractions. The growing popularity and reliability of systems like Memcached, Redis, MongoDB, etc. have reduced the need to build custom storage and caching systems. Funneling the team's focus onto a small number of core abstractions rather than fragmenting it over many ad-hoc solutions means that common libraries get more robust, monitoring gets more intelligent, performance characteristics get better understood, and tests get more comprehensive. All of this helps contribute to a simpler system with reduced operational burden.
  • 핵심적인 추상개념을 단순하고 일반적으로 유지하면 커스텀 솔루션의 필요성을 줄여주는데다, common 개념에 대한 팀의 친화도 그리고 전문성을 증가시킨다. 점점 인기와 신뢰성를 얻고 있는 Memcached, Redis, MongoDB같은 것들은 별도의 저장/캐시 시스템을 구축할 필요성을 줄여준다.
  • 4. Develop a focus on high code quality with code reviews.
  • 4. 코드 리뷰를 통해 높은 코드 품질에 집중하라.
  • Maintaining a high-quality code base increases the productivity of the entire engineering team. Cleaner code is easier to reason about, quicker to develop on, more amenable to changes, and less susceptible to bugs. A healthy code review process makes this possible.
  • 높은 품질의 코드베이스를 유지하면 전체 엔지니어링 팀의 생산성을 높일 수 있다. 깔끔한 코드는 이해하기 쉽고 빠르게 개발할 수 있으며 변경하기 용이하고 버그(오류)에 덜 취약하다. 건강한 코드리뷰 과정을 통해 이것을 가능하게 할 수 있다.
  • Establishing a process for timely code reviews, whether pre-commit or post-commit, improves code quality in a few ways.  First, the peer pressure of knowing that someone will be reviewing your code and that committing poorly written code will likely let down your teammates is a strong deterrent against hacky, unmaintainable, or untested code. Second, code reviews provide opportunities for the code reviewer and author to learn from each other to write better code.
  • 커밋하기 전이던 후던 시의적절한 코드 리뷰 프로세스를 정립하면 여러모로 코드 품질을 향상시킬 수 있다. 우선 누군가 자신의 코드를 볼거라는 사실이 꼼수같고, 유지보수 불가능하고, 테스트를 거치지 않은 코드를 작성하고 커밋하지 않도록 강하게 억제할 것이다. 둘째로 코드 리뷰를 통해 리뷰어나 코드 작성자 모두 서로에게 더 좋은 코드를 쓰는 방법을 배울 기회를 갖게 된다.
  • If the code reviews are easily accessible to other members of the engineering team, then the reviews also bring along the benefits of a) increasing accountability for reviewing code in a timely manner, b) allowing team members -- particularly, newer ones -- to model off of others' good code reviews, and c) speeding up the dissemination of best coding practices.
  • 만약 엔지니어링 팀 모두가 코드 리뷰에 쉽게 참여할 수 있다면 다음과 같은 장점들을 가져온다. a) 시의적절하게 코드를 리뷰하는 책임감을 키울 수 있다, b) 팀원들 - 특히 신입들 - 이 다른 이의 좋은 코드리뷰를 배울 수 있다, c) 모범사례를 빠르게 전파할 수 있다.
  • Counter-arguments that nimble teams don't have time to spend on code reviews ignore the technical debt that can easily accumulate from poorly written code. Ooyala, in its very early startup days, used to optimize for cranking out as many features as possible, with an absence of code reviews; the result was that while the initial product may have gone to market more quickly, the resultant code became painful to modify, and we spent over a year just rewriting brittle code to eliminate technical debt.
  • 행동이 빠른 팀은 코드 리뷰 할 시간이 없다는 반박은 기술적 부채가 허접한 코드로부터 쌓여진다는 점을 간과한다. Ooyala 초기에 코드리뷰 없이 최대한 많은 기능을 내보내려고 노력했고, 그 결과 초반에는 시장에 제품을 더 빨리 내놓을 수 있었다. 하지만 결과적으로 고치기 어려운 코드 때문에 일 년 이상을 불안정한 코드를 수정함으로서 기술적 부채를 갚는데 써야했다.
  • Google, at its size, does pre-commit code reviews for all code, but smaller teams don't need to be as comprehensive or strict, and not all code needs to be reviewed with the same rigor. Ooyala later adopted post-commit reviews over email for core or risky changes while I was there. At Quora, we currently conduct all code reviews in Phabricator [15], mostly post-commit, and apply different standards for model or controller code and view code; for sensitive code or for code from newer engineers, we'll either do pre-commit reviews or try to review them within a few hours of the code being submitted.
  • 구글은 그 규모에도 불구하고 모든 코드에 대해 사전 커밋 코드 리뷰를 한다. 하지만 작은 팀들은 그렇게까지 포괄적이고 엄격할 필요는 없다. 그리고 모든 코드가 같은 똑같이 엄격하게 리뷰되어야 하는 것도 아니다. Ooyala는 나중에 주요 부분에 대한 혹은 위험한 변경들에 대해 이메일을 통한 사후 커밋 리뷰를 채택했다. Quora에서는 모든 코드 리뷰를 Phabricator를 통해 하고있다. 대부분은 커밋 이후에 리뷰를 하고 있으며 모델, 컨트롤러 그리고 뷰 코드에 대해 각각 다른 기준을 적용한다. 민감한 코드이거나 신입 엔지니어가 작성한 코드에 대해서는 사전 커밋 리뷰를 하거나 코드가 제출(커밋)된 후 수 시간 안에 리뷰하는 방법을 쓴다.
  • 5. Maintain a respectful work environment.
  • 5. 존중받는 근무 환경을 유지하라.
  • Respect among peers forms the foundation for any type of open communication. A place where people feel comfortable challenging each other's ideas is one where sound ideas get forged through debate. A place where people easily get offended is one where crucial feedback gets withheld.
  • 동료들로부터의 존경은 모든 열린 의사소통의 기본이 된다. 다른 사람의 아이디어를 쉽게 평가하고 시험할 수 있는 분위기라야 좋은 아이디어가 토론을 통해 발전할 수 있다. 쉽게 기분이 상해버리는 분위기에서는 결정적 조언을 하지 않을 것이다.
  • In 1948, Alex Osborn outlined the familiar brainstorming approach that's been popular in work environments for the past few decades, where participants come together, set aside criticism and negative feedback, and collectively pool together creative ideas without fear of being judged. [16] Respectful deferment of judgment is key to this type of brainstorming session. Recent psychology research has started to overturn Osborn's approach, suggesting that encouraging debate in brainstorming sessions actually helps to avoid groupthink and generates more effective ideas. In light of this research, a respectful environment becomes even more critical so that attacks are directed toward ideas rather than being ad-hominem. [17]
  • 1948년 Alex Osborn은 우리에게 지난 수십년간 유명세를 떨친 브레인스토밍이라는 개념을 제창했다. 이는 참가자들이 함께 모여 비판이나 부정적인 피드백을 배제함으로서 평가받는다는 두려움 없이 창의적인 아이디어를 모으는 것을 뜻한다. 평가를 유예하는 것이 이런 종류의 브레인스토밍에 핵심이다. 최근의 심리학 연구가 이 Osborn의 접근방법을 뒤집기 시작했다. 연구에 따르면 브레인스토밍을 할 때 토론을 장려하는 것이 어정쩡한 집단사고를 예방하고 더 효과적인 아이디어를 내도록 돕는다고 한다. 이 연구결과에 비추어 보자면 비판이 사람을 향한 것이 아니라 아이디어에 대한 것으로 받으들여지기 위해서는 존중하는 환경이 더욱 중요하다.
  • Engineering often spans a wide range of areas (systems, machine learning, product, etc.) and not everyone has the same expertise in each area. A strong team in fact probably ought to have individuals who are uniquely strong in certain areas even if they end up being deficient in others. This sometimes makes it tricky for say, a systems engineer to evaluate the proficiency of a product engineer, but it's important in a healthy engineering culture to respect those differences and to not judge solely based on your own strengths.
  • 엔지니어링은 상당히 넓은 분야를 아우르는데 반해 각 분야의 모든 사람이 같은 정도의 전문성을 가지고 있는 것은 아니다. 강한 팀은 다른 분야에 대해서는 잘 모르더라도 특정한 분야에 뛰어난 개개인으로 이루어져 있다. (TODO 시스템 엔지니어가 제품 개발자의 숙련도를 평가한다던가 하는 것) 건강한 엔지니어링 문화에서는 차이점을 존중하되 자신의 전문분야를 바탕으로 다른 사람을 평가하지 않는 것이 중요하다.
  • 6. Build shared ownership of code.
  • 6. 코드를 공동 소유하도록 하라.
  • note icon
    자기가 작성한 코드를 남이 손대는 것을 싫어하거나, 반대로 남이 작성한 코드를 고치기를 기피하는 경우가 있습니다. 전자는 자존심 때문에, 후자는 읽고 이해하는 것이 쉽지 않기 때문인데 '코드 공동 소유'는 모든 코드를 누구나 고칠 수 있는 문화를 말합니다.
  • While it's natural for individuals to become proficient in various parts of the code base or infrastructure, no one person should feel that they own or are the sole maintainer of any one piece. While having individuals become experts that own certain areas for a year or more might increase effectiveness in the short run, this approach ends up hurting in the long run.
  • 개개인이 코드베이스나 기반구조의 여러 부분에 능숙해지는 것은 자연스러운 일이지만, 코드의 일부분을 자기것이라고 생각하거나 혼자서 관리한다고 생각해서는 안된다. 한 사람이 특정한 분야를 일년 이상 맡아 전문가가 되는 것은 단기적으로 효율적일지 모르지만 이런 접근방법은 장기적으로 문제를 일으킬 것이다.
  • Organizationally, shared code ownership provides three benefits. First, keeping the bus factor [18] greater than one relieves stress from the maintainer and reduces risk for the team in case the maintainer leaves. It also makes it difficult for that one person to take worry-free time off. I sure don't miss the days when I was the sole maintainer of Ooyala's logs processor and got texted by pager alerts while hiking on volcanoes in Hawaii.
  • 조직에 있어 코드의 소유권을 공유하는 것은 세 가지 장점이 있다. 우선 '승차 인원'을 1명 이상으로 유지하면 담당자의 스트레스를 줄일 수 있고, 담당자가 팀을 떠났을 때의 위험을 줄일 수 있다. 또한 근심없이 휴가를 떠나도록 하기 어렵게 한다. 나 혼자서 Ooyala의 로그 프로세서를 맡고있던 시절에 하와이의 화산에서 하이킹을 하고 있다가 (시스템 오류에 대한) 문자메세지를 받았던 날을 잊을 수 없다.
  • note icon
    코드를 한 사람이 장악하고 있으면 그 사람이 없을 때 팀이 위험해질 뿐 아니라, 코드를 관리하는 당사자도 걱정을 내려놓을 수 없다는 취지로 이해됩니다.
  • Second, shared ownership empowers engineers who aren't knee-deep in the particular area to contribute fresh insights. It frees engineers from the sense that they're stuck on certain projects and encourages them to work on a diversity of projects, which helps to keep work interesting and boosts employee learning and motivation. In the long run, it reduces organizational risk that some engineer feels stagnated and decides to leave. [19]
  • 또한 코드를 공동 소유하면 해당 분야에 전문적이지 않은 엔지니어가 새로운 통찰력을 제공할 기회를 준다. 엔지니어들은 특정 프로젝트에 메어있다는 느낌으로부터 자유로울 수 있고 다양한 프로젝트에 참여하도록 북돋는다. 이를 통해 직원들은 일에 재미를 느끼는 한편 배우고 자극받을 것이다. 길게 본다면 엔지니어들이 정체됐다는 느낌 때문에 회사를 그만두게 되는 위험을 줄여줄 것이다.
  • Third, shared ownership also sets the foundation for having multiple team members swarm (a technique from agile development) together on a high-priority problem when necessary to finish a strategic goal more quickly. With siloed ownership, the burden typically falls on one or two people.
  • 셋째로, 코드 공동 소유는 전략적인 목표를 더 빨리 성취할 필요가 있을 때 여러 팀원들이 급한 일에 함께 달려들 수 있는 토대가 된다. (코드의) 소유권이 격리되어 있다면 이런 경우의 부담은 한두 명에게 집중된다.
  • note icon
    Swarm은 애자일 방법론(Agile method)의 하나인데, 곤충들이 특정한 리더 없이 한꺼번에 떼지어 움직이는 현상에서 차용한 개념이라고 합니다. 참조 : http://agiletools.wordpress.com/2007/12/03/what-is-swarming/
  • One mistake that many engineering organizations make too early on is dividing the entire team into subteams with tech leads when the team's still small. Subteams build walls of ownership that reduce incentive to cross those walls, since individuals will likely be assessed by their subteam's objectives. Ooyala had subteams while I was there, and one thing I missed out on was the opportunity to work with some folks on other teams; they've since adopted an agile development process with a much larger focus on shared code ownership that I've heard has made large strides in work happiness and productivity. One aspect of Quora that I've loved is that we've emphasized projects over teams, and I've had an opportunity to work on projects ranging from user growth, machine learning, moderation tools, recommendations, analytics, site speed, and spam detection.
  • 많은 엔지니어링 팀이 초창기에 겪는 실수 중 하나는 바로 팀이 아직 작은데도 불구하고 여러 팀으로 나누고 각 팀에 팀장을 두는 경우다. 작은 팀의 팀원들은 개별 팀의 목표에 따라 평가되기 대문에 팀간의 벽을 넘을만한 동기가 없다. 내가 Ooyala에서 일할 때에도 팀이 나뉘어 있었는데, 그 때문에 다른 팀에 있는 사람들과 일할 기회를 놓쳤다. 다른 팀에서는 코드 공동 소유권에 초점을 둔 애자일 개발 프로세스를 도입했고 생산성과 일의 행복감이 크게 향상됐다. Quora에서 내가 사랑하는 점 중 하나는 팀보다는 프로젝트를 강조한다는 것이다. 그리고 나는 회원 증가, 머신 러닝, 관리툴, 추천, 분석, 사이트 속도, 스팸 감지 등 다양한 프로젝트에서 일할 기회를 가질 수 있었다.
  • 7. Invest in automated testing.
  • 7. 자동화된 테스팅에 투자하라.
  • Unit test coverage and some degree of integration test coverage is the only scalable way of managing a large codebase with a large group of people without constantly breaking the build or the product. Automated testing provides confidence in and meaningful protection against large-scale refactorings that are required to improve code quality. In the absence of rigorous automated testing, the time required for manual testing either by the engineering team or by an outsourced testing team easily becomes prohibitive, and it's easy to fall into a culture of fear for improving a piece of code just because it might break.
  • 유닛 테스트 커버리지와 어느 정도의 통합 테스트 커버리지만이 많은 수의 사람이 빌드를 깨먹지 않고 커다란 코드베이스를 유지할 수 있는, 유일하게 확장성 있는 방법이다. 자동화된 테스팅은 코드 품질을 향상시키기 위해 꼭 필요한 큰 규모의 리팩토링을 자신감있게 해내도록 한다. 신중하게 자동화된 테스팅 없이 엔지니어링 팀 혹은 테스팅 팀이 일일이 직접 테스트하는 데에 드는 시간은 감당하기 힘들 정도이며, 뭔가를 망가뜨리는 것이 두려워 코드를 개선하기를 두려워하는 분위기가 만들어지기 쉽다.
  • In practice, automated testing is a requirement for making continuous deployment work as the team grows. Codebase size grows over time as the product grows, but average familiarity with the codebase by team members decreases as new people join. Testing and validation are most easily done by the original code authors when the code is fresh in their minds than by those who try to modify the code months or years later. Encouraging a strong unit testing culture shifts the validation responsibility toward the authors.
  • 실제로, 팀이 계속 커지더라도 지속적인 배포를 유지려면 자동화된 테스팅이 필요하다. 코드베이스의 크기는 제품이 성장하면서 커지게 마련이고, 새로운 사람이 팀에 들어오면서 코드에 대한 익숙함은 덜하게 된다. 테스팅과 검증은 몇 달 혹은 몇 년 후에 고치려는 사람 보다는 막 작성된 시점에 이것을 작성한 사람이 가장 쉽게 할 수 있는 일이다. 견고한 유닛 테스팅을 장려하는 문화는 검증에 대한 책임을 코드 작성자에게 넘긴다.
  • 8. Allot 20% time.
  • 8. 20%의 시간을 할당하라.
  • Gmail found its roots in Paul Buchheit's 20% project, and he hacked together the first version in a single day. [20] Google News, Google Transit, and Google Suggest also started and launched as 20% projects. I used 20% time while at Google to write a python framework that made it significantly easier to build search page demos.  While Google's 20% time may be less productive now than during the early days of the company [21], the notion of letting engineers spend 20% of their time working on something not on their product map remains a cradle of innovation for smaller engineering organizations.
  • Gmail은 폴 부크하이트의 20% 프로젝트로 부터 시작되었으며, 그는 첫 번째 버전을 단 하루 만에 만들었다. 구글 뉴스, 구글 트렌짓, 그리고 구글 서제스트도 모두 20% 프로젝트로 시작해서 런치까지 되었다. 나는 구글에 있을 때 20%시간을 검색페이지 데모를 굉장히 쉽게 만들어준 Python프레임웍을 만드는데 사용했다. 비록 옛날에 비하면 구글의 20%시간이 지금은 덜 생산적일지 몰라도, 엔지니어가 자기 시간의 20%를 자신이 일하는 제품 개발계획과 상관없는 일에 사용한다는 아이디어는 작은 엔지니어 조직에 혁신의 산실이 되고 있다.
  • Ooyala didn't officially have 20% time while I was there, but I took some anyway and wrote a command-line build tool for Flex and Actionscript that sped up the team's build times, just as Adobe's Flex Builder tool chain started to degrade, and the tool's still in use today even though the engineering team has nearly tripled in size. Atlassian adopted 20% time after experimenting it for year. [22] A variation of 20% time that Facebook's fond of and that Ooyala added later is periodic hackathons -- all-night events where the rule is that you can work on anything except your normal project. [23]
  • 내가 있는 동안 Ooyala는 공식적으로 20%시간을 가지고 있지는 않았지만, 나는 스스로 시간을 빼서 Adobe의 flex builder 툴이 후져지기 시작했을때, Flex와 Actionscript의 커멘드 라인 빌드 툴을 만들어 팀의 개발 시간을 향상시켰다. 이 툴은 팀의 크기가 3배가된 지금도 사용되고 있다. 20%시간의 비슷한 예로는 페이스북이 좋아하는 그리고 Ooyala도 나중에 추가한 주기적인 헤커톤이 있다. -규칙은 밤새 원래하던 프로젝트만 아니면 무엇이든 일할 수 있다.
  • Top-down approaches to product planning, while necessary for focusing the overall direction of the company, can't account to for the multitude of ideas that might arise from engineers closer to the ground. As long as engineers are accountable for their 20% time and focus on what can be high-impact changes, these projects can lead to large steps forward in progress. Without official 20% time, it's still possible but much more difficult for engineers and designers to try out crazy ideas -- the dedicated ones basically have to find weekends or vacation days to do it.
  • 상의하달식 제품계획은 회사의 전체적인 방향을 집중하는 데는 필요할지 모르지만, 현장에 가까이 있는 엔지니어들이 만들어내는 다양한 아이디어에 응답하기는 어렵다. 엔지니어들이 자신의 시간에 20%를 책임지고 무엇이 큰 변화를 일으킬 수 있는지에 집중한다면, 이 프로젝트는 발전을 향한 큰 발걸음을 내디딜 수 있다. 공식적인 20%시간이 없어도 할 수는 있겠지만, 속한 프로젝트가 있는 엔지니어나 디자이너가 주말이나 휴가 때 시간을 내 특이한 아이디어를 시도해보는 것은 훨씬 어렵다.
  • 9. Build a culture of learning and continuous improvement.
  • 9. 배우고 끊임없이 개선하는 문화를 만들어라.
  • Learning and being sufficiently challenged are requirements for what psychology professor Mihaly Csikszentmihalyi calls a state of "flow", where someone is so completely focused and motivated by what they're doing that they even lose track of time. [24] The direct and immediate feedback loop provided by faster iteration cycles is another requirement.
  • 배우고 또 충분히 시험당하는 것은 바로 Mihaly Csikszentmihalyi 교수가 '플로(flow)'라고 부르는 - 시간을 재는 것조차 잊을 정도로 지금 하고 있는 일에 완전히 집중하고 동기부여된 - 상태를 위해 필수적이다. 빠른 반복주기를 통해 직접적이고 즉각적인 피드백을 받는 것 또한 필요하다.
  • Weekly tech talks provide forums for engineers to share their designs or what they've built, creating an opportunity for engineers to take pride in their work and for the the team to learn more outside their immediate scope of work.  Documenting processes internally like how a email service works or how to make ranking changes to a search service also empowers engineers to learn and explore new things on their own, nicely complementing 20% time.  At Quora, we do this by running an internal instance of Quora where we ask product- and development-related questions.
  • 엔지니어들이 주간 기술 발표를 통해 설계와 작업들을 공유하도록 할 수 있다. 또 그들에게 자신의 일을 자랑스럽게 느낄 수 있는 기회를, 팀에게는 업무영역 바깥의 것들을 배울 기회를 제공한다. 이메일 서비스가 동작하는 방식이나 랭킹 변화가 검색 서비스에 미치는 영향과 같은 내부 프로세스를 문서화함으로서 엔지이너들이 "20% 시간"동안 새로운 것을 스스로 익히고 탐구하도록 할 수도 있다. Quora에서는 사내 전용의 Quora를 따로 운영함으로서 제품이나 개발에 관련된 질문, 답변이 이루어지도록 하고있다.
  • A corollary of building a culture of learning is focusing on mentoring and training to make sure that everyone has the basic algorithms, systems, and product skills necessary for success.  The more an engineering organization grows and the more effort gets spent on recruiting (particularly college recruiting), the more effort needs to be invested into mentoring and training. It might seem burdensome for a single mentor to spend an hour per day for a new hire's first 4 weeks on the job, but that investment represents less than 1% of the total time that hire will spend in a year and has significantly high leverage in determining whether the person is set up for success.
  • 10. Hire the best.
  • 10. 최고를 고용하라.
  • Hiring the best is the foundation for many of the other philosophies listed. It's hard to respect someone if you think they're a B-level engineer. It's hard to give someone autonomy in product development if you don't trust their product instincts. It's hard to recognize the right abstraction to build without enough engineering experience. It's easy to fall into a trap of building something complex without other smart people to challenge your ideas and drive you toward simplicity.
  • 최고의 인재를 고용하는 것은 이 글에 언급한 다른 사상의 기본이 된다. B급이라고 생각되는 상대를 존중하기는 어렵다. 마찬가지로 그 사람이 가진 제품에 대한 직감을 믿을수 없다면 제품 개발에 대한 자율권을 주기 어려울 것이다. 엔지니어링 경험이 충분하지 않다면 추상화를 제대로 하기가 어렵다. 유능한 사람들이 당신의 아이디어를 시험하고 단순화하도록 하지 않으면 복잡한 해법에 대한 유혹에 빠지기 쉽다.
  • There's a saying around Silicon Valley, coined by Steve Jobs, that "A players hire A players. B players hire C players." [25,26]  Focusing on recruiting and hiring the right people is hard but critical to effectively growing an engineering organization.  Yishan Wong, who previously was an engineering manager and director at Facebook, argued that hiring has to be the number one priority for everyone in the engineering organization, not just for managers, but for engineers as well. [27]  He also quite rightly points out the difference between "hiring the best" and "hiring the best candidate that you've interviewed."
  • 스티브 잡스가 이런 말을 했다. 'A급은 A를 뽑고, B급은 C급을 뽑는다." 적절한 인물을 채용하는 것은 어렵지만 엔지니어링 조직의 효율적인 성장에 있어서 매우 중요하다. 페이스북의 엔지니어링 관리자이자 director였던 Yishan Wong은 엔지니어링 조직에 있어서 채용이란 비단 관리자 뿐 아니라 엔지니어들에게도 최우선적인 문제라고 말한 바 있다. 그는 또한 '최고를 뽑는 것'과 '인터뷰한 지원자 중 최고를 뽑는 것'의 차이점에 대해서도 적절하게 지적했다.
  • In the early days of Ooyala, we were so overwhelmed with the queue of inbound customer work that we nearly caved in to lowering our hiring bar so that we could hire enough people to get all our work done.  I'm glad that we didn't, as the technical debt from lower quality code and weaker engineers on the team would've ended up hurting the team and the product.
  • Ooyala 초기에 쌓여있는 고객지원 업무를 해결하기 위한 사람을 더 뽑으려고 채용 기준을 낮춘 적이 있다. (Quora에서는) 그렇게 하지 않은 것이 다행이다. 낮은 품질의 코드와 실력없는 엔지니어로 인한 기술적인 부채는 결국 팀과 제품을 망치게 될 것이므로.
  • note icon
    기술적인 부채(technical debt)란 문제 근본적으로 해결하지 않고 임시방편(quick-and-dirty)으로 해결하다 보면 문제점이 누적는 상황을 말합니다.
  • Building a good engineering culture is certainly a lot of work, but the resulting work environment is well worth it.
  • 좋은 엔지니어링 문화를 만들기 위해서는 해야 할 일이 많다. 하지만 그 결과로 얻은 업무 환경은 그럴만한 가치가 있다.
  • ----------
  • ----------
  • [2] Scaling Instagram.
  • (원문참조)
6 Comments
paul81

paul81 • Jun 24th, 2012

새롭게 스타트업을 시작하는 입장에서 많은 공감이 가는 글이었습니다.
  • baxang • Aug 30th, 2012

    시작하신 일 잘되길 바랍니다^^

umteeh

umteeh • Jun 9th, 2012

읽다가 재미있어서 저도 몇줄 얹었어요. 초벌이라 생각하시고, 어색한 부분있으면 수정해 주세요~
  • baxang • Jun 12th, 2012

    고맙습니다^^ 이번주엔 손을 못 댔는데 저도 진도 좀 빼야겠네요!

euniya

euniya • May 24th, 2012

아? 안녕하세요? 정말 오랜만이에요. 번역 워낙에 잘하셔서 이거 끼어도 되는 기사인지 모르겠어요. :) 페북 루아에도 소개할께요~
  • baxang • Jun 5th, 2012

    댓글을 이제야 봤네요^^ 이거 번역하기가 꽤 까다로운데 좀 도와주셔요~