Geoff Ralston: I would like to introduce Jared Frieda, my partner, and his esteemed panel, who he will introduce, to talk about technology. Thank you.
Geoff Ralston: 我想介绍我的合伙人杰瑞德·弗里达和他将要介绍的尊敬的小组成员，来谈谈技术。谢谢。
Jared Friedman: Thank you, Jeff. Okay well, I am super lucky to have a very esteemed group of guests with me here today. Everyone on this panel is a technical founder of a really successful company. Everyone here has built a really cool company and a really amazing technology organization. We've changed the name of the event for today.
杰瑞德·弗里德曼：谢谢你，杰夫。好吧，今天有一群很受尊敬的客人和我在一起，我真是太幸运了。这个小组中的每个人都是一家非常成功的公司的技术创始人。这里的每个人都建立了一个非常酷的公司和一个非常棒的技术组织。我们把今天的活动改名了。
It was originally called "CTO Advice" and, on the advice of Lillian, thank you so much, we have changed it to "Technical Founder Advice", which I think is a better description.
它最初被称为“CTO建议”，根据Lillian的建议，非常感谢您，我们已经将其更改为“技术创建者建议”，我认为这是一个更好的描述。
And I would also like to thank everyone on the startup school form who wrote in with questions for the panel. We posted a few weeks ago and solicited questions, we got over 150 responses so, thank you everyone who wrote in with those questions. We're gonna do our best to cover as many of them as we can and then, at the end, we'll open it up to the in-person audience for some questions as well. Okay so, let's get started. Could we start by having everyone introduce themselves and tell us about your company and about your technology like what's your technology stack, what's some of the interesting technology that you've built, how's your technology organization look like today. Ralph you want to start.
我还要感谢创业学校表格上的每一个人，他们为小组写了一些问题。几个星期前，我们发布了一些问题，我们收到了150多个答复，所以，感谢每一个写了这些问题的人。我们会尽我们最大的努力尽可能多地报道，最后，我们也会向现场观众公开一些问题。好的，让我们开始吧。我们能不能先让每个人自我介绍一下，告诉我们你的公司和你的技术，比如你的技术栈，你建立的一些有趣的技术，你的技术组织现在看起来怎么样？拉尔夫你想开始。
Ralph Gootee: Hello everyone I'm Ralph Gootee.
大家好，我是拉尔夫·古蒂。
I'm CTO and co-founder of PlainGrid. PlainGrid we're 350 people based out of Mission, San Francisco. We write beautiful, easy to use software for the 17 trillion dollar construction industry. So what that looks like to you, the analogy off the top of the news is we're like GitHub for construction. Construction has blueprints, blueprints change rapidly, version control is extremely important.
我是CTO和PlainGrid的联合创始人。PlainGrid我们是来自旧金山的350人。我们为17万亿美元的建筑业编写了漂亮、易用的软件。所以在你看来，新闻顶部的类比是，我们就像建筑的GitHub。建设有蓝图，蓝图变化迅速，版本控制是极其重要的。
If you have changes that means there're issues that are happening, issues need to be tracked and then we build collaboration tools on top of that too.
如果您有更改，这意味着有问题正在发生，问题需要跟踪，然后我们也在此基础上构建协作工具。
As well, as a lot of other tools for the construction industry that go into some deep jargon. Our stack, based on AWS we used to be based on a variety of other things, we had to move everything to AWS overtime. On our back end, mostly Python on the backend and then we've got some go in other things.
同样，对于建筑行业来说，也有很多其他的工具，这些工具都有一些深奥的行话。我们的堆栈，基于AWS，我们以前是基于各种其他的东西，我们不得不把所有的东西都转移到AWS加班。在我们的后端，大部分是后端的Python，然后我们在其他方面做了一些工作。
And one of our challenges is that we actually write native for every platform so, we've got IOS, Swift, Subjectivcy, Android, All Javlin, Kotlin, Web React and then Windows. We have a full windows app as well which is .net.
我们面临的挑战之一是，我们实际上为每个平台编写了本机，因此，我们有iOS、SWIFT、Subjectivcy、Android、所有javlin、Kotlin、Web Reaction，然后是Windows。我们也有一个完整的Windows应用程序，即.NET。
Jared Friedman: Cool.
杰瑞德·弗里德曼：酷。
Calvin...h-Owen: Hi everyone, I'm Calvin French-Owen and I'm CTO and co-founder of Segment. Segment is a single API to collect, organize and adapt all of your customer data into hundreds of down streaming tools you might be using. Whether that's a analytics tool like Google Analytics or Mixpanel, maybe a customer success tool like Gainsight, maybe an e-mail tool like Customer.io. Segment helps you collect data from where it lives and get it where it needs to be.
卡尔文.欧文：大家好，我是卡尔文·法尔文-欧文，我是首席技术官，也是分部的联合创始人。段是一个用于收集、组织和调整所有客户数据的API，用于将您可能正在使用的数百个向下流工具中进行调整。无论是谷歌分析工具还是MixPanel分析工具，可能是像Gainsight这样的客户成功工具，也可能是像Customer.io这样的电子邮件工具。段可以帮助您从它居住的地方收集数据，并将其放在需要的位置。
In terms of the company overall we're a little over 300 people right now. We have our headquarters in San Francisco but, we also have offices in Vancouver, New York and Dublin.
就公司整体而言，我们现在有300多人。我们的总部设在旧金山，但我们也在温哥华、纽约和都柏林设有办事处。
In the engineering product and design team which is kind of how we build product here at Segment, is a little over 80 or 90 right now.
在工程产品和设计团队中，我们是如何在Segment这里建立产品的，现在是80或90多一点。
In terms of our technology stack we're also built entirely on top of AWS. In terms of how we run our infrastructure we run on top of ECS, Amazon's Container Service and pretty much all of our different services are containerized. Today we're running about 300 different microservices which are kind of piping together very escophic topics and reading and writing, transforming this data, getting it where it needs to go.
就我们的技术栈而言，我们也完全建立在AWS之上。就我们运行基础设施的方式而言，我们运行在ECS、Amazon的容器服务和几乎所有不同的服务都是集装箱化的基础之上。今天，我们运行了大约300个不同的微服务，它们将非常复杂的主题、读写、转换这些数据，把它们带到需要的地方。
And our back end is primarily written in GO.
我们的后端主要是用Go写的。
Diana Hu: Good morning everyone, so my name is Diana Hu.
大家早上好，所以我的名字是戴安娜胡。
I was the founder and CTO for Escher Reality and we're building the back end for augmented reality.
我是埃舍尔现实的创始人和首席技术官，我们正在为增强现实建立后端。
And I say I was because my company just got acquired by Niantic, the makers of Pokemon Go. So, what we were building at Escher and now, we actually continue doing it in Niantic, is building this backend technology for augmented reality to enable developers to build AR experiences as easy as possible. So we handle all the complexity with the computer vision algorithms, with all the interaction with the backend, all the hard parts of getting things to render so that developers could build easy AR apps in minutes, so that's what we do. We provide a lot of advanced AR features like multi-player, persistence and cross platform so that it is easy for developers to just develop let's say unity and it just works.
我说我是因为我的公司刚刚被Pokemon Go的制造商Niantic收购了。所以，我们在埃舍尔建造的，现在我们在Niantic继续做的，是为增强现实构建这种后端技术，让开发者能够尽可能容易地构建AR体验。所以我们用计算机视觉算法来处理所有的复杂性，所有与后端的交互，所有要渲染的东西的所有困难部分，这样开发者就可以在几分钟内构建简单的AR应用程序，所以这就是我们所做的。我们提供了许多先进的AR功能，如多玩家、持久化和跨平台，这样开发人员就很容易开发-比如说，统一-而且它只是起作用了。
In terms of technology stack it has been a bit of adventure, back at Escher we had a service that we hosted in AWS but, that didn't matter too much because we had everything in Docker containers. Now, Niantic is heavy user of Google Clouds so move everything through Google Cloud. But, we have a lot of the bulk of the code for us native means more C++ literally, because it's a lot more efficient for us to write the code and all of the algorithms once and then cross compile it across all the architectures for Android or IOS and event he back end. So that we run some of the [inaudible] we can prototype it in the phone and then we can easily move them into the server because our server is actually also written in C++.
在技术栈方面，这是一种冒险，在埃舍尔，我们在AWS中托管了一项服务，但这并不太重要，因为我们在Docker容器中拥有一切。现在，Niantic是GoogleClouds的大量用户，所以通过GoogleCloud移动一切。但是，我们有大量的本机代码意味着更多的C+字面意思，因为它对我们来说效率要高得多，我们只编写一次代码和所有算法，然后在Android或IOS的所有体系结构中交叉编译它，然后将它交叉编译到所有用于Android或iOS的体系结构和Event He后端。因此，我们可以在电话中运行一些[听不见的]原型，然后我们可以轻松地将它们移动到服务器中，因为我们的服务器实际上也是用C+编写的。
Lilian Chou: Hi everyone, I'm Lilian I am COO not CTO of Second Measure. Second Measure we're about 50 people we got started back in 2015 and we're based in San Mateo. What we do is we analyze credit card data. So, basically we take billions of credit card transactions and try to build a daily view into public and private company performance. We analyze these billions of transactions automatically everyday and Justin will clean them, enrich, normalize them and then service that in a front end application for our clients which include VC firms, hedge funds and big brands like Blue Apron or Spotify to check trends, any sort of competitive intelligence or customer intelligence. So we actually don't have a CTO that's a fun fact about us. That's why I'm here on the panel today. Myself and my co-founder actually are both technical's that's been pretty fortunate. We don't have to deal with as many of the challenges around starting with non-technical founders.
周丽莲：大家好，我是莉莲，我是首席运营官，不是第二任首席运营官。第二，我们大约有50人，我们是在2015年开始的，我们的总部设在圣马特奥，我们所做的就是分析信用卡数据。因此，基本上，我们需要数以十亿计的信用卡交易，并试图建立一个公众和私人公司的日常表现。我们每天都会自动分析这些数十亿笔交易，贾斯汀会清理它们，丰富它们，规范它们，然后在前端应用程序中为我们的客户提供服务-包括风投公司、对冲基金和蓝色阿普隆(Blue Apron)或Spotify这样的大品牌-来检查趋势、任何类型的竞争情报或客户情报。所以我们实际上没有CTO，这是一个有趣的事实。这就是我今天来这里的原因。我本人和我的联合创始人都是技术人员，这是相当幸运的。从非技术创始人开始，我们不需要应对太多的挑战。
I mentioned our team is 50 people, primarily technical so, are technical organization is about 30 people and that's actually split evenly between data scientists and engineers.
我刚才提到我们的团队是50人，主要是技术人员，所以，技术组织大约是30人，而这实际上是数据科学家和工程师之间的平均分配。
And that's probably something that makes us unique is that, our core product is actually the data itself. So our data scientist and engineers have to collaborate super closely on a day to day basis. And probably one of the thing that has technically been interesting is a lot of our users want to explore and dive deep into our data and building a front end that allows that flexibility of exploration while still creating a good user experience basically requires us to figure out how to rapidly query data and run really complex queries on our back end. You asked about technology stack, we're also primarily on AWS so for our pipeline we leverage services like Lambda and Spark.
这可能让我们与众不同的是，我们的核心产品实际上是数据本身。因此，我们的数据科学家和工程师必须在一天的基础上进行超级紧密的合作。技术上有趣的事情之一可能是，我们的许多用户想要探索和深入研究我们的数据，并建立一个前端，使探索的灵活性，同时仍然创造一个良好的用户体验基本上需要我们找出如何在后端快速查询数据并运行非常复杂的查询。您问到了技术栈，我们也主要使用AWS，因此对于我们的管道，我们利用Lambda和SPark之类的服务。
And then for our front end we are React based and leverage columnar data storage on the back end to service queries, so think Redshift.
然后，对于我们的前端，我们将基于响应并利用后端的列式数据存储来进行服务查询，所以请考虑一下RedShift。
Jared Friedman: Awesome guys, that was super cool.
杰瑞德·弗里德曼：太棒了，太酷了。
It's so cool the diversity of different kinds of technology organizations and products that are here today. Okay so, most of the companies in start up school are really early. So I want to take everyone here back to their V1. The very first version before you had actually shipped anything. Tell us the story of how you built your V1, who built it, how did you build it, how long did it take you to build it and what things went wrong in the process.
今天这里有各种各样的技术组织和产品，真是太酷了。好吧，大多数开办学校的公司都很早。所以我想带大家回到他们的V1。在你发运任何东西之前的第一个版本。告诉我们你是如何构建你的V1的，是谁构建的，你是如何构建的，你花了多长时间来构建它，以及在这个过程中出了什么问题。
Ralph Gootee: Okay so I'll start. This is a great story.
拉尔夫·古提：好的，我先开始。这是一个伟大的故事。
I've actually got my CEO and CO-founder over there watching me right now. So that's kind of-
实际上，我的首席执行官和首席执行官都在那里看着我。所以这有点-
Jared Friedman: Say Hi Tracey.
杰瑞德·弗里德曼：喂，特雷西。
Ralph Gootee: Yeah, Hey Tracey, how's it going? So, that's where we started Tracey told me about her idea of putting blueprints on an iPad. This was in 2011, right at the launch of the iPad so it was very early for the technology.
拉尔夫·古提：嘿，特蕾西，怎么样了？所以，那就是我们开始的地方，特蕾西告诉我她把蓝图放在iPad上的想法。这是在2011年，正好是在iPad发布的时候，所以对于这项技术来说，这还为时尚早。
And I said "Yeah no problem.
我说“没问题。
I can put blueprints on iPad it's like a PDF, that's no problem at all." So I was attempting to impress her really quickly by putting blueprints on an iPad, it turns out there was actually some hardcore challenges with putting these giant images on a really low computer availability on the iPad, there was no graphics chip at the time so basically these were 20,000 pixel images and they would just crash or overrun the video memory.
我可以把蓝图放在iPad上-就像PDF一样，这一点也不成问题。“所以我试图通过在iPad上放置蓝图来给她留下深刻的印象。事实上，在iPad上把这些巨大的图像放到一个非常低的计算机上是有一些困难的，当时没有图形芯片，所以基本上这些是2万像素的图像，它们会崩溃或者超出视频内存。
And they were in PDF which is a kind of painful format to deal with so, the first proto type sucked it was really slow, and that actually told me that there's something real meaty here, there's something that's actually a challenge.
他们是用PDF格式的，这是一种痛苦的格式，所以，第一次输入它的速度很慢，这实际上告诉我，这里有一种真正的肉质，有些东西实际上是一种挑战。
And it took me about a month to write the second proto type based off some... My background actually I used to work at Pixar so I had some graphics experience there. Didn't use any proprietary stuff but, used some off the shelf computer graphics knowledge to write the first blueprint viewer that ever ran on mobile. So that was our first prototype back then and I think the best thing I remember back on it is the only thing we really focused on the first prototype was what technically impossible. There's no way you could load blueprints onto an iPad at the time and that was our prototype which, meant that all the data got there by side loading which meant there was no web interface and the little crappy web interface we had, had a delete button right next to a publish button that was not a pixel part and there was no confirmation on the delete button. So, we actually as a team we manage everything on the backend, we kind of like behind the curtains, loaded all the documents for our first 30 or 40 customers. But, all the saw was the prototype that was fast, and did what they thought it would. They never saw the man behind the curtain so to speak. So, that's a little story of our first prototype.
我花了大约一个月的时间根据一些.我的背景，实际上，我以前在皮克斯工作，所以我有一些图形经验。我没有使用任何专有的东西，但是，用一些现成的计算机图形学知识编写了第一个运行在手机上的蓝图查看器。所以那是我们当时的第一个原型，我认为我记得的最好的东西是我们真正关注的第一个原型-技术上不可能的东西。当时你不可能将蓝图加载到iPad上，这就是我们的原型，这意味着所有的数据都是通过侧加载得到的，这意味着没有网络接口，我们拥有一个糟糕的网络界面，在发布按钮旁边有一个删除按钮，而发布按钮不是像素部分，删除按钮上也没有确认。因此，我们实际上是一个团队，我们管理后端的一切，我们有点像在窗帘后面，为我们的前30或40位客户加载所有文档。但是，所有的锯子都是快速的原型，他们做了他们想做的事情。他们从来没有见过窗帘后面的那个人，可以这么说。这是我们第一个原型的一个小故事。
Jared Friedman: Awesome.
杰瑞德·弗里德曼：太棒了。
Calvin...h-Owen: Cool and I'll share a little bit of a story of our V1 and then maybe our V1 next...
卡尔文.欧文：酷，我会和大家分享一下我们的V1的故事，然后也许是我们的V1.
I think for those of you who have seen the startup school talk, my co-founder Peter talks about finding product market fit. He goes into the story in way more detail than I could today but, I can share a little bit of our journey. So, when we first started we were in the YC 2011 class, which sounds like a dinosaur now in terms of YC years. But, at the time we were actually building something completely different from Segment today. We were building this classroom lecture tool, which would help professors get feedback about what their students were thinking in the middle of class. We were students at the time, and we figured "Hey, this seems like a great idea. Professors will sometimes go on for five minutes, and they'll lose the entire class, the class gets confused, and you just waste everyone's time. Let's solve that problem." We built it out over the course of the summer and we deployed it back in Boston in the fall.
我想对于那些看过创业学校演讲的人来说，我的联合创始人彼得谈到了如何找到适合自己的产品市场。他比我今天更详细地讲述了这个故事，但是，我可以分享一些我们的旅程。所以，当我们第一次进入YC 2011课程的时候，这听起来就像是YC年里的恐龙。但是，在那个时候，我们实际上是在建造与今天的片段完全不同的东西。我们正在构建这个课堂讲课工具，它将帮助教授们获得关于他们的学生在课堂中间的想法的反馈。当时我们还是学生，我们想：“嘿，这似乎是个好主意。教授们有时会持续五分钟，全班同学都会输掉，全班同学都会感到困惑，而你却浪费了大家的时间。让我们来解决这个问题吧。“我们在夏天建造了它，并在秋天把它重新部署到波士顿。
And the whole thing just kind of crashed and burned like students would go to Facebook, YouTube, Wikipedia.
整个过程就像学生们会去Facebook，YouTube，维基百科一样地崩溃和燃烧。
In retrospect all the things you would assume college students would do if they have a laptop in front of them in a lecture but, we didn't quite see it that way. So, we started looking around for a new idea because we just raised a seed round. And we say "Okay what are the problems that we have with this college lecture tool." And one of them was that we couldn't answer questions about how people were using our tool. We couldn't tell you hoe college students at Harvard were using the tool differently than students at MIT or we couldn't tell you how anthropology classes use it differently than biology classes.
回想起来，所有你认为大学生会做的事情，如果他们面前有一台笔记本电脑在他们的演讲，但，我们没有完全这样认为。所以，我们开始四处寻找一个新的想法，因为我们刚刚开始了一个新的想法。我们说：“好吧，我们的大学演讲工具有什么问题。”其中之一是我们无法回答人们如何使用我们的工具的问题。我们不能告诉你，哈佛大学的学生使用这个工具的方式和麻省理工学院的学生不同，或者我们不能告诉你人类学课是如何使用它的，而不是生物课。
And so we switched again to something which, also we don't do today but, effectively it was a competitor to Mixpanel or Amplitude.
因此，我们再次转向一些，我们今天不做的事情，但实际上，它是混合面板或振幅的竞争对手。
It was this tool that would allow you too cluster your users by different rules and break them up into segments, which is where the name came from, and from there you could then reach out to them or figure out what your most engaged users were doing.
正是这个工具让你把你的用户按不同的规则聚在一起，把他们分成几个部分，这就是名字的来源，然后你就可以联系他们，或者找出你最投入的用户在做什么。
And so we built out that system for about 15 months. The whole time we we're doing Revs on the backend infrastructure, we were building it out and we were trying to get users and no one wanted our tool.
所以我们建立了大约15个月的系统。在我们对后端基础设施进行REVS的整个过程中，我们都在构建它，我们试图让用户使用我们的工具，没有人想要我们的工具。
And so we arrived 15 months later, we actually moved back to the bay area after living in Boston for a year and we go and talk to PG and we tell them about our whole saga that's been running for the past year and a half.
15个月后，我们搬回海湾地区，在波士顿住了一年后，我们去和PG谈了谈，我们告诉他们我们在过去一年半里的整个传奇故事。
And he listens to our story and he listens to everything that we've done and when we were finished, he just sort of pauses, I think it was maybe 400 ft out there walking around the round about, and he says "Wow so you just burned half a million dollars and you're still at square one." We were just like "Yes." He said "Well on the plus side you still have some runway left so try again, like launch something new." At the time we had this internal tool that we had been using as kind of a growth hack to get ourselves more users.
他听着我们的故事，听着我们做的每一件事，当我们完成的时候，他就停了下来，我想大概是400英尺，在四周围走动，他说：“哇，所以你刚刚烧了50万美元，你还在原地踏步。”我们就像“是的”他说：“好吧，在好的一面，你还有一些跑道，所以再试一次，比如发射一些新的东西。”当时，我们有一个内部工具，我们一直使用它作为一种增长黑客，以获得更多的用户。
And the whole idea was that you would use the same API to send us data as you would send to Mixpanel, Kissmetrics, Google Analytics, all these other tools.
整个想法是使用相同的API向我们发送数据，就像发送给MixPanel、Kissics、GoogleAnalytics等所有这些工具一样。
And people actually like that single API and they were contributing to this opensource library on GitHub and starting and using it and so my co-founder Ian said, "Hey why don't we turn this into a product. Why don't we launch this and see what happens." And my co-founder Peter said "Oh, that's the worst idea I've ever heard, it will ever work." He's CEO now but, he's seen the light.
事实上，人们喜欢这个单一的API，他们在GitHub上为这个开源资源库做出贡献，并开始使用它，所以我的联合创始人Ian说，“嘿，我们为什么不把它变成一个产品呢？”为什么我们不启动这个，看看会发生什么。“我的共同创始人彼得说：“哦，这是我听过的最糟糕的主意，它会成功的。”他现在是首席执行官，但是，他看到了光明。
And so he said "okay, I've got to figure out a way that we can test this idea incredibly quickly." So we cleaned up the library and we launched it on Hackernews and to our surprise it actually got about a thousand stars that first day on GitHub.
于是他说：“好吧，我得想出一种方法，让我们能以惊人的速度测试这个想法。”所以我们清理了图书馆，在黑客新闻上发布了它，令我们惊讶的是，它在GitHub的第一天得到了大约一千颗星星。
And so, our real V1 was that first week taking that library and basically just had a landing page up which said, "Hey if you're interested in a hosted version of this leave your e-mail." And about 500 people left their e-mail.
所以，我们真正的V1是在第一周使用这个库，基本上只有一个登陆页面，上面写着：“嘿，如果你对这个托管版本感兴趣，请留下你的电子邮件。”大约有500人留下了他们的电子邮件。
And we built out that V1 in about a week, we're just everyone was in mad hackathon mode and building out the product which we launched a week later.
我们在大约一周内建立了V1，我们只是每个人都处于疯狂的黑客马拉松模式，并在一周后开发出了我们推出的产品。
And so, today I think there is actually no parts of that product which still live on today. But, it was enough to get us the seed of product market fit and then start getting us a user base.
所以，今天，我认为这个产品的任何部分都没有活到今天。但是，这足以让我们的种子产品市场适合，然后开始为我们提供一个用户基础。
Jared Friedman: So one week is the short, one week, one week, everybody hear that one week. Okay.
杰瑞德·弗里德曼：所以一个星期是短暂的，一个星期，每个人都会听到一个星期。好的。
Diana Hu: That's kind of amazing one week. So our story is definitely more than one week. so me and my co-founder had been thinking of building different things and one of the technology trends that we really saw... He comes from a robotics background with a lot of experience with Slam. Slam is this algorithm called spontaneous localization of mapping, and it's one of the core algorithms that runs today in AR, which helps tell where your camera position is while you also build this map of the world. So what happened is there's this category of algorithms that have been used mostly for robotics now, AR had then kind of tried and many times but never really been picked up, there's AR with markers and that never really took off.
胡黛安娜：这一周真是太棒了。所以我们的故事肯定不止一个星期。所以我和我的联合创始人一直在考虑建造不同的东西，以及我们真正看到的科技潮流…他来自机器人的背景，有丰富的经验与大满贯。SLAM是一种称为自发定位的映射算法，它是今天在AR中运行的核心算法之一，它可以帮助判断相机的位置，同时也可以绘制这张世界地图。所以发生的事情是，这类算法现在主要被用于机器人技术，AR曾经尝试过很多次，但从未被真正拾起，还有带有标记的AR，但从未真正起飞。
And then we thought about why do we bring these algorithms and run them on the phones and we got to the point were we thought we could do it because the computation at that point with phones for example iPhone seven has the same computation actually as a MacBook Pro from 2013, if you think about that that's kind of amazing in terms of all the trends with [inaudible] and some of the one's with power efficiency... So we decided to go do it.
然后我们思考了为什么我们要把这些算法带到手机上运行，我们认为我们可以这样做，因为在这一点上-例如iPhone 7-的计算实际上与2013年的MacBookPro相同，如果你考虑到这一点的话，那就太神奇了。所有的趋势与[听不见的]和其中的一些与能源效率.所以我们决定去做。
At that time I was actually still working and leading a data science team back then, and I said "Okay I'll do that." Because I was thinking of doing some transition.
当时我还在工作，当时我领导着一个数据科学团队，我说：“好吧，我会这么做的。”因为我在考虑做些转变。
I was working part-time with another engineer on this, one of the engineers that we kind of got excited to work with us. So, we struggled a lot to try to get a version working. The first one was very duct tape, and it wasn't very encouraging.
我和另一位工程师做兼职，其中一位工程师，我们很高兴能和我们一起工作。所以，为了让一个版本正常工作，我们费了很大的劲。第一条是很好的胶带，并不是很鼓舞人心。
It was only working five frames per second, which is terrible because if you want a good AR experience the whole thing is that you need it to render nicely, and be at least 30 frames per second. So that was very discouraging in a sense because it was all kind of put together fast. Then we started kind of really removing all the research code out and then it started working and seeing a lot of promise, and it was running then at least 30 frames per second.
它只工作五帧每秒，这是可怕的，因为如果你想要一个良好的AR经验，整个事情是，你需要它渲染很好，并至少30帧每秒。所以，从某种意义上说，这是非常令人沮丧的，因为这一切都是快速组合在一起的。然后我们开始真正地删除所有的研究代码，然后它开始工作，并看到了很多希望，它运行了至少30帧每秒。
And note that when we were working on this it was at least about a year and a half before AR could have launched.
请注意，当我们在这方面的工作，它至少是一年半，才能推出AR。
And then we were excited about this so were both very more from the technology side, so we didn't know the product market fit, or where to go with this. So, we had to find a market. [inaudible] side of that is we went in and interviewed a bunch of people that we thought would use it and we found a really good fit with gaming. So we decided to focus on that and that was our YC application.
然后我们对此感到兴奋，所以从技术方面来说，我们都非常兴奋，所以我们不知道产品市场是否合适，也不知道该如何应对。因此，我们必须找到一个市场。(听不见)的一面是，我们进去采访了一群我们认为会使用它的人，我们发现他们非常适合玩游戏。所以我们决定专注于此，这就是我们的YC应用程序。
And the thing that really took off and this is actually a good story, is the first day of YC, Apple announced ARkit which is basically what we had built and that was sort of a moment of truth for us, a sort of go flight or fight. So we decided why not let's just take on Apple. So we decided to just double down, and we had this idea that this wasn't just on the device, which we had all our demos and technology was just working on the phone, we didn't have anything on the backend yet so, backend YC we got it working with a backend and also with Android and basically accelerating the roadmap that we thought was bat a year, shrink it and got it done in three months.
真正起飞的，这是一个很好的故事，是YC的第一天，苹果宣布了ARkit，这基本上是我们所建立的，这对我们来说是一个真实的时刻，一种去飞行或战斗。所以我们决定为什么不直接和苹果公司竞争。所以我们决定双倍下降，我们有这样的想法，这不仅仅是在设备上，我们所有的演示和技术都只是在手机上工作，我们的后端还没有任何东西，所以，后端YC我们让它与后端和Android一起工作，并且基本上加速了我们认为是好的路线图。一年，缩小它，在三个月内完成它。
And that was the thing that once we put it out there and let people sign up if they were interested, a thousand developers signed up in about a week. So "Okay, I think we've found something." And then after that we got a little interest and among those Niantic was one, and the story is we got acquired later, that's our little summary.
这就是一旦我们把它放在那里，让人们注册，如果他们有兴趣，一千名开发人员注册了大约一周。所以“好吧，我想我们找到了什么。”在那之后，我们得到了一点兴趣，其中一个是尼安蒂奇，故事是我们后来获得的，这是我们的小总结。
Jared Friedman: So how long was it from the time that you started working on like the original Slam algorithms until you had like a working product in users hands?
杰瑞德·弗里德曼：那么，从你开始像最初的Slam算法那样工作到你在用户手中拥有一个有用的产品之前，有多长时间了？
Diana Hu: So we were not really working full time, it was probably about a yr of part-time.
胡黛安娜：所以我们不是真正的全职工作，大概是大约一年的兼职时间。
And part-time I wasn't really working so I went full-time and took another six months of me and another engineer to do it.
而兼职，我并没有真正的工作，所以我去全职，并花了六个月的我和另一个工程师来做这件事。
And then during the summer, let's see we hired two more engineers and that's when we were able to really accelerate it and get it working well.
然后在夏天，让我们看看，我们又雇佣了两名工程师，那时我们才能真正加快它的速度，使它运转良好。
Lilian Chou: Cool. So for us our V1 probably took assuming full-time, two or three months to build.
周丽莲：酷。所以对我们来说，我们的V1可能需要全天候，两三个月的时间来构建。
And I actually would say that most of that time was just figuring out what our product was going to be. We knew that the problem we were working out was going to be really interesting, initially we were focused on investors basically trying to get them an information edge on sort of any investment decisions that their making whether that be hedge funds, focus on public markets or VC's focused on private markets. We ran through a few ideas, we were like "Hey do these investors want predictions, do they just want to know how this company, public companies quarterly sales are gonna hit?" And the short answer is yes but, no. That didn't really seem like a really sort of sustainable business model so then we shifted a little bit.
我想说的是，大多数时候，我只是想弄清楚我们的产品会是什么样子。我们知道我们正在解决的问题会很有趣，最初我们关注的是投资者-基本上是试图让他们在任何投资决策中获得信息优势-不管是对冲基金，还是公共市场，还是风投专注于私人市场。我们研究了一些想法，比如“嘿，这些投资者吗？”想要预测，他们是否只想知道这家上市公司的季度销售额会有多大？“简短的回答是肯定的，但是，不是。这看起来并不是一种真正可持续的商业模式，所以我们改变了一点。
It was like "Okay maybe these investors really, really want to go deep and they just want to cut data anyway, they want." So, we put something together really quickly, put that in front of some of our friends who are investors and found out very quickly through that somewhat user testing that, that was way too overwhelming. Our users wanted some guidance. So what we ultimately landed on is we needed to build our own self-service platform where we can apply our opinions around how our customers should be viewing this data and getting quick access to insights. So once we figured that part out, it was actually pretty quick. So my co-founder focused on building the analytics product piece so the front end application.
就像“好吧，也许这些投资者真的，真的很想深入，他们只是想削减数据，他们想要的。”所以，我们很快地整理了一些东西，把它放在我们的一些投资者朋友面前，很快就通过用户测试发现，这实在是太令人难以抗拒了。我们的用户需要一些指导。因此，我们最终需要建立我们自己的自助服务平台，在这个平台上，我们可以应用我们的意见，比如我们的客户应该如何查看这些数据，以及如何快速获取这些信息。所以一旦我们弄清楚了这部分，它实际上是相当快的。因此，我的联合创始人专注于构建分析产品，使其成为前端应用程序。
And together we built the data pipeline and the transformations on the data. But, I think some important choices that we made early on, is maybe something that you guys are facing right now, is what technology do you want to use like what do you want to build this is? Ultimately we decided to build our first application in Groovy using the Grails framework which is very not shiny, not that many people are doing that but, that was actually the code that we had the most experience in. So my co-founder Mike had built large production scale systems servicing hundreds of thousands of concurrent users and pretty much within a week had built the bones of the application.
我们一起构建了数据管道和数据转换。但是，我认为我们早期做出的一些重要选择，也许是你们现在面临的问题，你们想要使用什么样的技术，比如你们想要构建什么？最终，我们决定使用Grails框架在Groovy中构建我们的第一个应用程序，这并不是很多人正在做的事情，但实际上这是我们最有经验的代码。因此，我的联合创始人迈克建立了大规模的生产系统，为成千上万的并发用户服务，并且几乎在一周内建立了应用程序的核心。
And kind of like some of these other stories here like none of us are running our V1 anymore. So it's more important in the early days to be able to iterate quickly and usually that comes from using the technology that you know the best, building things in a modular way such that once you actually find that product market fit and know what your audience needs then you can focus on that area and actually select the technologies that are a best fit for that problem.
就像这里的其他故事一样，我们都不再使用V1了。所以，在早期，更重要的是能够快速迭代，这通常来自于使用你最熟悉的技术，以模块化的方式构建东西，这样一旦你真正找到了适合你的产品市场，知道了你的受众需要什么，那么你就可以专注于这个领域，并真正选择最适合这个问题的技术。
Jared Friedman: Awesome. Okay so I'm gonna go next to the very top voted question from the startup school from, which is about the trade off between engineering best practices like good test coverage and security, and scalability, and redundancy versus writing code as quickly as possible and shipping something. So, can everyone talk about how you made that trade off for your V1 and then how it's evolved since then and sort of like the time table of its evolution as your company grew and those things became presumably more important. And just to mix it up let's trying flipping the order, we'll start with Lilian this time.
杰瑞德·弗里德曼：太棒了。好的，接下来我来谈谈创业学校最热门的投票问题，这是关于工程最佳实践之间的权衡，比如良好的测试覆盖率和安全性，以及可伸缩性，以及冗余与尽快编写代码和发布一些东西之间的权衡。所以，每个人都能谈谈你是如何为你的V1做出这种权衡的吗？然后它是如何从那时开始演变的，就像你的公司成长时的进化时间表，而这些事情大概变得更重要了。为了把它混在一起，让我们试着改变顺序，这次我们将从莉莲开始。
Lilian Chou: Sure. So speed is paramount. Nobody's going to pay you for having excellent test coverage so, in the early days you definitely want sort of what you need, right? So access the risk to your business around sort of security and not having things working, and obviously you want whatever you build to run every day. You don't want to be fixing or it breaking all the time and not actually building. But, really it is a balance.
周丽莲：当然。所以速度是最重要的。没有人会因为你有出色的测试覆盖率而付钱给你，所以，在早期的日子里，你肯定想要某种你需要的东西，对吗？因此，访问您的业务的风险在某种程度上是安全的，没有工作，很明显，您希望任何您构建的运行每天。你不想一直在修理或破坏它，而不是实际建造。但是，这真的是一种平衡。
I do believe that initially it is more important to have that speed of development and constantly testing and incorporating the learnings into your product than it is to have the most robust or most scalable product, right? You're trying to find something that people will pay you money for or solves a real problem and that takes time and a lot of iteration. That has definitely evolved since we got started. You know, once you find product market fit a lot of these problems change, your system gets more complex, your team grows, and you have a lot more people contributing code, a lot more ways for your system to break, a lot more users who are relying on your product. So for us, the way that manifested itself is we started writing uni-test to verify, each engineer would be verifying their code works. Then we introduced CI and CD to make sure that that code would work with the whole system. Our director of engineering who leads our engineer organization, started developing and formalizing our best practices around like code reviews, testing etc.
我确实认为，在一开始，拥有这样的开发速度和不断地测试并将所学知识集成到产品中比拥有最健壮或最可伸缩的产品更重要，对吗？你试图找到一些人们会付钱给你的东西，或者解决一个真正的问题，这需要时间和大量的迭代。这在我们开始的时候就有了很大的发展。你知道，一旦你发现产品市场适应了很多这些问题的变化，你的系统就会变得更加复杂，你的团队也会成长，你有更多的人贡献代码，有更多的方法让你的系统崩溃，更多的用户依赖于你的产品。因此，对我们来说，表现出来的方式是我们开始编写单元测试来验证，每个工程师都将验证他们的代码工作。然后，我们引入了CI和CD，以确保代码能够与整个系统一起工作。我们的工程总监，领导我们的工程师组织，开始开发和形式化我们的最佳实践，如代码审查，测试等。
And to finding those processes and then finally building some more controls directly into our system to make it harder to break things.
并找到这些过程，然后最终将更多的控制直接放入我们的系统中，从而使我们更难打破这种局面。
Jared Friedman: And specifically what was the rough time line for those things? Like are we talking about two months after launch, two years after launch?
杰瑞德·弗里德曼：具体来说，这些事情的大致时间是什么？就像我们说的是发射后的两个月，发射后的两年吗？
Lilian Chou: So I'd say most of that stuff I was just talking about happened probably in the last year to year and a half.
周丽莲：所以我想说的是，我刚才提到的大部分事情大概发生在过去一年半的时间里。
Jared Friedman: And that's how many years after launch?
杰瑞德·弗里德曼：那就是发射后的多少年了？
Lilian Chou: About a year and a half after launch.
周丽莲：发射后大约一年半。
And the main reasons for that again were the growth, and those complexities of our systems and our technical staff tripled in the last yr so, just that along introduces a lot more need for process.
这其中的主要原因是增长，我们的系统和技术人员的复杂性在过去几年里增加了两倍，因此，这就带来了对过程的更多需求。
Diana Hu: In our case it was aways about trying to get to MBP that was reasonably working well.
胡黛安娜：在我们的例子中，一直以来都是为了设法达到MBP，这是相当有效的。
And all that was definitely duct tape code, is nothing I'd be proud of.
所有这些都是管道胶带代码，没有什么值得我骄傲的。
It's just...
只是.。
I put together and barely working as much as possible, so we were there even when we did the kind of private launch in a sense when we did the private data and got customers who signed up.
我把数据集中在一起，几乎没有尽可能多地工作，所以我们在那里，即使在某种意义上说，我们做了那种私人发布-当我们做了私人数据，并得到了签约的客户。
And we had private data that we had some number of our game developers working with us and that was also the duct tape code. The only time we started actually having all the best practices was once we joined Niantic because now, we have to integrate into the games which Pokemon GO has hundreds of millions of users. So we were burying ourselves to get a lot of the... We pretty much rewrote the whole code base, none of what we had before is there it's all re-written to prepare for that expected number of users.
我们有私人数据，我们有一些游戏开发者和我们一起工作，这也是管道胶带代码。我们唯一真正开始拥有所有最佳实践的时候就是加入Niantic，因为现在，我们必须整合到Pokemon Go拥有数亿用户的游戏中。所以我们为了得到很多.我们几乎重写了整个代码库，我们以前的所有代码都没有重新编写，以便为预期的用户数量做好准备。
Calvin...h-Owen: Cool.
加尔文.欧文：酷。
I think for us at Segment there are kind of three distinct phases of our development.
我认为，对于我们来说，在分段，有三个不同的阶段，我们的发展。
I'd say the first one was when we were in full hackathon mode, right? Were definitely didn't have any test, no CI.
我想说的是，第一次是在我们完全参加黑客马拉松的时候，对吧？绝对没有任何测试，也没有CI。
I'd say there was an 80% chance that we were just going to throw it out two weeks later because it wasn't going to stick and that we were going to move on to the next thing.
我想说的是，我们有80%的机会在两周后把它扔出去，因为它不会继续下去，我们还会继续下一件事。
I think because we had been burned so much by building out all this infrastructure and investing in a lot of these ways to provision your infrastructure, and write test and spin up different new services, over the past year and a half, it really had gotten us nowhere. We had no users.
我认为，因为在过去的一年半里，我们通过建设所有这些基础设施和投资于许多这样的方式来提供基础设施、编写测试和分拆不同的新服务而被烧得精疲力竭，这真的让我们一事无成。我们没有用户。
It just created this like pretty aligning homing instinct for us where we just said "No matter what the only thing that matters is getting users at this point in the game." So, that's where we started and I think that lasted us probably for about the first nine or 10 months where we were just focused on rapid iteration, getting more users, making sure that we didn't run out of money and then whole thing wouldn't of even mattered.
它为我们创造了一种非常和谐的归巢本能，我们只是说：“无论什么事，唯一重要的是在游戏的这个时刻吸引用户。”所以，这就是我们开始的地方，我认为这可能持续了我们最初的9到10个月，那时我们只是专注于快速迭代，吸引更多的用户，确保我们没有耗尽资金，然后整个事情就都无关紧要了。
I think from there the first phase that then shifted is when we brought on our first engineer TJ, rad for those of you who know or are involved with the note community, TJ is one of the best engineers I think I've ever worked with, I think 90% of note jobs run on some part of his code. He basically came into Segment and he looked around at well, this mess that we created, the product that we created and he said "Well, there's no way for me to work in this.
我认为，从那以后，第一阶段发生了变化，当我们引进了我们的第一工程师TJ，rad，对于那些知道或参与到注释社区中的人来说，TJ是我认为我曾与之共事过的最好的工程师之一，我认为90%的笔记工作都是在他的代码中运行的。他基本上进入了分部，他环顾四周，看看我们制造的混乱，我们创造的产品，他说：“好吧，我不可能在这个问题上工作。
I have a horrible time onboarding."I think it took him a week to get his entire laptop set up.
“我觉得他花了一周的时间才把他所有的笔记本电脑都装好了。”
And so we kind of moved from this point where the entire development team shares the same tube of toothpaste to now, starting to have more and more engineers of [inaudible] for the project.
因此，我们从这一点开始，整个开发团队共享同一管牙膏，开始有越来越多的工程师为这个项目[听不见]。
And when that happened it really stepped up our game in terms of testing and CI, and just reproducibility when it came to running the builds and running the stack, because suddenly we had to expand outside of just the four of us.
当这种情况发生的时候，我们的游戏在测试和CI方面都有了很大的提高，当涉及到运行构建和运行堆栈的时候，它只是在可再现性，因为突然间，我们不得不扩展到我们四个人之外。
And then I think that period lasted another two or three years. Probably in the past two, three, or four years from now or from this point in time, we've gone through another shift were we started thinking a lot more about end to end testings, security, kind of best practices around handling all of our customers data.
然后我认为这段时间又持续了两三年。也许在过去的两、三、四年之后，或者从现在开始，我们经历了另一个转变-我们开始考虑更多关于端到端测试、安全性、以及处理所有客户数据的最佳实践。
And the real reason for that is now we actually have a pretty significant amount of both like revenue and customers, and reputation to lose. From day one we had no users so it didn't matter if the whole thing went down for a day or hours or whatever it was, the calculus didn't make sense there. But, today we have thousands of customers who are relying on Segment to polish their data, to not lose it, to treat it and handle it securely. No so for us the investment makes way more sense.
而真正的原因是，我们现在有相当大的收入和客户，以及声誉的损失。从第一天起，我们就没有用户了，所以不管整个事情是一天还是几个小时，还是不管是什么，微积分都说不通。但是，今天，我们有成千上万的客户依靠分段来润色他们的数据，不丢失数据，对待数据并安全地处理数据。因此，对我们来说，投资更有意义。
Jared Friedman: And that last period roughly what scale did you have to reach before you started thinking seriously about those things?
杰瑞德·弗里德曼：在你开始认真思考这些事情之前，最后一段时间大概要达到什么程度？
Calvin...h-Owen: Yeah, that's a good question.
卡尔文.欧文：是的，这是个好问题。
I think when we started having enterprise customers who are paying north of six figures per year, that's when it started to shift and we started thinking "Oh, we really have to take care in how we're handling this data because these customers are really depending on this to power their business."
我想，当我们开始让企业客户每年支付超过6位数的费用时，它就开始发生变化，我们开始思考“哦，我们真的需要注意我们如何处理这些数据，因为这些客户真的依靠这个来支持他们的业务。”
Ralph Gootee: So I think my stories a little different than the other panelists. This might be interesting.
拉尔夫·古提：所以我觉得我的故事和其他小组成员有点不同。这可能很有趣。
I would say all three of those different facets.
我想说的是这三个不同的方面。
I think I heard security, I heard scalability and I heard engineering best practices. We really have to treat them independently at PlainGrid. PlainGrid's used to build all...
我想我听说过安全性、可伸缩性和工程最佳实践。我们真的必须在PlainGrid独立对待他们。PlainGrid用来构建所有.。
In California most hospitals, most jails, most heavy civil road work were used on all the tech campuses all of the different government buildings that go up. So obviously security from day one, I mean that's key to us. So we had no choice but, to always be super conscious of security and scalability for that matter because our customer's the only way we're useful is if we're used to build the project. Like we're the replacement for blueprints which means in construction if we're not working properly no one builds.
在加州，大多数的医院，大多数的监狱，大部分的土建工程都是在所有的科技校园里使用的-所有不同的政府建筑都在上面。所以很明显从第一天起就安全了，我是说这是我们的关键。因此，我们别无选择，但在这方面，我们必须始终对安全性和可伸缩性保持超级意识，因为我们的客户是唯一有用的方法，就是如果我们习惯于构建项目。就像我们是蓝图的替代品，这意味着如果我们不能正常工作，就不会有人建造。
And not building for a day in construction can seriously impact the bottom line in these businesses. For us the first two security and scalability were always key. Scalability is a challenging one because it's I don't know...
而在建设中一天不建房会严重影响这些企业的利润。对我们来说，前两个安全和可伸缩性始终是关键。可扩展性是个挑战，因为我不知道.
I'm not sure there's a way to do it without it being kind of reactionary. You either over engineer everything and then you maybe never get a product to market, or you eventually have to deal with scaling issues.
我不知道有没有办法不带反动的态度去做这件事。你要么把所有的东西都设计好了，然后你可能永远也无法将产品推向市场，要么你最终不得不处理缩放问题。
And for us we tried to architect it in such a way that we last through the foreseeable future, the foreseeable future would come, and some customer would find the first kind of flaw in the scalability. To give you an idea of the scale we've probably about... We have customers with projects that are like 500,000 blueprints with a ton of changes and maybe over five million annotations on one project.
对我们来说，我们试图用这样一种方式来设计它：我们能够在可预见的未来中坚持下去，可以预见的未来将会到来，而且一些客户会发现可伸缩性中的第一种缺陷。让你知道我们大概有多大的规模.我们的客户的项目大约有50万张蓝图，有大量的变化，一个项目的注解可能超过500万。
And we work offline as well so this is all downloaded onto a cache on the device. Our physical size on the iPad can take up like a 100 gigabytes for certain projects. So, we've had all kinds of scaling issues we've had to approach and we always try to balance it between engineering a year ahead of time but, not maybe three years ahead of time which is a trade off. So, you know find that trade off yourself.
我们也是离线工作的，所以这些文件都被下载到设备上的缓存中。我们在iPad上的实际尺寸在某些项目中可以达到100 GB。因此，我们已经遇到了各种各样的扩展问题，我们一直试图在工程之间取得平衡-提前一年，但不是提前三年-这是一种权衡。所以，你知道的，找到你自己的交易。
I remember when we were in NYC we had all these stories of companies that had built the most iron clad architecture and just never had a product to market so, that was on our mind while we were building that. For engineering best practices our V1 so of that code still exists in the product today. So, some of the code I wrote for V1 is still there, I would say it's probably our measure of technical debt as an engineering organization so that's humbling. But, at the same time I've seen some developers... We do everything cool now, CI, CD we run integration tests, we got a UI testing team. So, this is feedback I'm getting from the past. But, if you're a experienced developer it's pretty hard to write spaghetti crap code, you know, it's actually challenging most experience developers... Some people are just really good off the get go it's normally something through time and writing a lot of production products but, you just generally learned the tricks of not writing spaghetti code pretty quickly.
我记得当我们在纽约的时候，我们有很多公司的故事，他们建造了最铁板一块的建筑，只是从来没有产品上市。所以，当我们在建造它的时候，这一直在我们的脑海中。对于工程上的最佳实践，我们的V1因此代码仍然存在于今天的产品中。因此，我为V1编写的一些代码仍然存在，我想说，这可能是我们作为一个工程组织的技术债务的衡量标准，所以这是一种谦逊的做法。但同时我也看到了一些开发人员.。我们现在做的一切都很酷，CI，CD，我们运行集成测试，我们有一个UI测试团队。这是我从过去得到的反馈。但是，如果你是一个有经验的开发人员，编写意大利面垃圾代码是相当困难的，你知道，这实际上是对大多数经验丰富的开发人员的挑战.有些人真的很好-这通常是经过时间和编写大量生产产品的东西-但是，你通常只是学到了不写意大利面代码的窍门。
And some of that code runs without heavy testing. The other thing to mention to is to properly scale test our product it would take days during integration test to download and upload all the data so, we really have a lot of functional testing to help us double check. But, the thing I've noticed with UI and unit tests is, we're a big fan of unit tests, we're a big fan of tester and development but, I've definitely seen developers write the most spaghetti test frameworks and the most spaghetti tests where they're just testing their mocks and their doing this in a middle of a production environment, you know, like a production need for release.
其中一些代码运行时没有经过大量的测试。另一件要提到的是，适当地对我们的产品进行规模测试-在集成测试期间，需要几天的时间才能下载和上传所有的数据，因此，我们确实有大量的功能测试来帮助我们进行二次检查。但是，我在UI和单元测试中注意到的是，我们非常喜欢单元测试，我们非常喜欢测试人员和开发人员，但是，我肯定看到开发人员编写了最多的意大利面测试框架和最多的意大利面测试，他们只是在测试他们的模拟并在一个生产环境中这样做，你知道，就像产品需要发布一样。
And they spent so much time writing these unit tests that actually weren't testing anything rather than getting the product out the door. Engineering best practices is great, there's a trade off between writing a lot of tests and writing a good code from the get go.
他们花了那么多时间来编写这些单元测试，这些测试实际上并没有测试任何东西，而不是让产品走出家门。工程方面的最佳实践很好，在编写大量测试和从GET开始编写一段好代码之间有一种权衡。
Jared Friedman: So speaking of test driven development a lot of questions were about the various engineering methodologies.
JaredFriedman：所以说到测试驱动的开发，很多问题都是关于各种工程方法的。
Agile development, lean start up, test driven development, extreme programming. How do you guys thing about those? Do you adhere to any particular methodology in your company?
敏捷开发，精益启动，测试驱动开发，极限编程。你们觉得这些怎么样？在你的公司里，你是否坚持任何特定的方法？
Lilian Chou: I would describe us as agileish. So, we do not fully adopt any of those methodologies. Basically we find what works more for our team and aren't super dogmatic about is this agile or is this not? We run sprints, we have daily stand ups so, we have some elements incorporated in our development but, I think with anything you're going to be solving a lot of problems for your organization and you have to find what works best for you.
周丽莲：我认为我们都是老年人。因此，我们没有完全采用这些方法。基本上，我们发现什么更适合我们的团队，而不是超级教条，这是敏捷还是这不是？我们运行冲刺，我们有日常站立，所以，我们有一些元素结合在我们的发展，但是，我认为，通过任何东西，你将解决很多问题，为你的组织，你必须找到什么最适合你。
I think it makes sense to take bits and pieces that work for you and adapt it to your organization.
我认为，采取适合你的零碎做法并使之适应你的组织是有意义的。
And then I guess its just the one other thing I'd mention on this is as you grow a big challenge is just constantly evolving how you work, right? So it's very different to work on a small team of four where everyone kind of knows everything, and everything is in everyone's heads versus a team who have 30 or 50 or for some of us 100's, that is very different. So I kind of constantly need to be assessing is this style of working or this methodology right for this stage of the company?
然后我想这只是我要提到的另一件事，那就是随着你的成长，一个巨大的挑战就是不断地进化你的工作方式，对吗？所以，在一个由四人组成的小组里，每个人都知道所有的事情，而每件事都在每个人的头脑中，和一个有30或50岁的团队，或者对于我们中的一些人来说，这是非常不同的。因此，我需要不断地评估这种工作方式或方法是否适合于公司的这一阶段？
Diana Hu: Yeah, I think the point of evolving the process is something that we've been doing a lot. Last year we were only with four engineers and building the product. So back then it was very messy, we were just trying to move as fast as possible really. So, 0 documentation, everything was kind of whiteboard and everyone could handle everything in their heads and build it out.
胡黛安娜：是的，我认为进化这个过程的意义是我们一直在做的事情。去年，我们只和四名工程师一起生产这种产品。所以当时非常混乱，我们只是想尽可能快地前进。所以，0文档，所有的东西都是白板，每个人都能处理他们头脑中的每件事，并把它构建出来。
And in terms of we really didn't do sprints because I think some of the engineers didn't quite like it as much and their were just too many big tasks and we just trusted different individuals to go and tackle kind of one area and then we would integrate it. But, now things are very different. Our new team is triple ready in the past eight months, for the AR platform product. We have a bigger team we definitely need a lot more process to be able to be efficient and communicate because you don't want duplicate, and not everyone knows everything and the system grows in a lot of complexities. So went from 0 documentation to a lot more. We used to have a literacy I but, now is very much [inaudible] that builds to all the architectural flavors to Lennox, Mac OS, Android, X86, [inaudible] , IOS etc.
就我们来说，我们真的不喜欢短跑，因为我认为有些工程师不太喜欢它，他们的任务太多了，我们只是信任不同的人去解决一个领域，然后我们就把它整合起来。但是现在情况完全不同了。在过去的八个月里，我们的新团队已经为AR平台产品做好了三倍的准备。我们有一个更大的团队，我们肯定需要更多的流程来提高效率和沟通，因为你不想重复，而且并不是每个人都知道所有的事情，系统在很多复杂的情况下增长。所以从0文档到更多文档。我们曾经有读写能力，但是，现在是非常(听不见的)，它建立了所有的建筑风格的Lennox，MacOS，Android，X86，[听不到]，iOS等。
And it actually runs al the test in all of them and catches a lot of the bugs. We have coverage and all those things but, we also hae to train and get the team to be okay with having more process so, now we do not quite like a sprint but we do planning for the week.
它实际上运行了所有这些程序中的所有测试，并捕获了大量的bug。我们有报道，但是，我们也要训练，让球队接受更多的训练，所以，现在我们不太喜欢冲刺，但是我们为本周做了计划。
And then we reconvene and I think the teams are broken down into sub teams that work. People kind of flow in and out of different focusing areas. We split in three main focuses one is, sort of the backend, other work on the clients to make it cross platform, the other do API's, and the other, the big one is bringing a lot of the computer vision algorithms to correction. So, the funny thing is that everyone in the team has ended up being and trained up to be a computer visional engineer because that's sort of the core. We have CV algorithms in the server, we have CV algorithms in the client and the core algorithms that run. So, that's how it kind of shaped up to be but, we really don't have a process per se but, we do... Right now, Niantic does OKR so now, we have OKR's as well per quarter. So now, we're starting to plan longer and longer and have ideas... Before we used to have like a rough idea of where things would go but now, it's this, this and this and this.
然后我们重新召集，我认为这些小组被分成了几个工作小组。人们进出不同的聚焦区域。我们分成三个主要的关注点，一个是后端，另一个是对客户端进行跨平台的工作，另一个是做API的，另一个是大的，一个是带来大量的计算机视觉算法来校正。所以，有趣的是，团队中的每个人最终都成为了计算机视觉工程师，因为这是核心。我们在服务器上有CV算法，在客户端有CV算法，以及运行的核心算法。所以，它是这样形成的，但是，我们真的没有一个过程本身，但是，我们确实.现在，Niantic做OKR，所以现在，我们每个季度都有OKR。所以现在，我们开始计划更长的时间，并且有了一些想法.以前我们对事情的发展有一个粗略的想法，但现在，是这个，还有这个。
Calvin...h-Owen: Yeah for us we don't have any set process that teams have to follow at Segment. We have individual engineering teams sort of like what Spotify does. Their able to self organize, their able to run how every they want.
卡尔文.欧文：是的，对我们来说，我们没有任何球队必须遵循的程序。我们有一些独立的工程团队，有点像Spotify所做的。他们能够自我组织，他们能够运行他们想要的每一个。
If they want to do sprints that's cool, if they want to use Chera they can do that, if they want to use Asana, whatever it is their allowed to run however they like to run. The one thing that we've introduced over the past two years is similarly the OKR model. For those of you that aren't familiar, this was a model that was developed at Google.
如果他们想要冲刺-这很酷，如果他们想使用切拉，他们可以这样做，如果他们想使用阿萨纳，不管他们允许怎么跑，不管他们喜欢跑什么。我们在过去两年中介绍的一件事类似于OKR模型。对于那些不熟悉的人来说，这是谷歌开发的模型。
It's the idea of O's are objectives and then key results so, you have your one objective where you're trying to go and then key results that are suppose to be objective measure of how you get there. Such if you do every KR then it adds up to the full objective. So, those are something that we do on a company wide basis, every single team in the company gets together and puts together their OKR's basically, one week before each quarter and then for that three month period there just executing on that plan.
它的思想是O是目标，然后是关键的结果，所以，你有一个目标，你想去的地方，然后关键的结果，应该是你如何达到目标的客观衡量标准。例如，如果你做了每一个KR，那么它就达到了完整的目标。所以，这是我们在公司范围内所做的事情，公司里的每个团队都聚集在一起，把他们的OKR基本放在每个季度的前一周，然后在三个月的时间里，在那里执行这个计划。
And some teams grade those on a weekly basis and check in and say "How am I doing against these goals?" Some teams grade them on a monthly basis, it kinda doesn't matter. But, at the end of the quarter every team is saying "Hey, here is how well I did against my stated goals." Separately for the teams that I work with in particular we wend up running a weekly meeting where at the beginning of the week we end up planning out what we want to get done, then we have a daily stand up.
有些团队每周都会给这些目标打分，然后检查一下，然后说：“我对这些目标做得如何？”有些团队每月给他们打分，这并不重要。但是，在本节结束时，每个球队都在说：“嘿，这是我对既定目标的表现。”另外，对于我工作过的团队，我们每周召开一次会议，在一周开始的时候，我们最终会计划好我们想要做的事情，然后我们每天都会站起来。
I honestly don't care too much about the content for those meetings so as long as we're always discussing the most important problems. We're pretty big believers that the tools and process should be there to serve us not, the other way around.
老实说，我不太关心那些会议的内容，只要我们总是在讨论最重要的问题。我们非常相信，工具和过程应该在那里为我们服务，而不是反过来。
Ralph Gootee: My experience at PlainGrid echoes all the other panelists, its agileish, self organizing. Every team can choose the tools that they want. Maybe some things that would be helpful to you, from the beginning some things that we've always found that's been very useful in every engineering team are the daily stand ups. You've got to communicate on a daily basis.
拉尔夫·古提：我在PlainGrid的经历呼应了所有其他小组成员的想法，他们年龄偏大，自组织能力强。每个团队都可以选择他们想要的工具。也许有些东西会对你有帮助，从一开始，我们就发现一些在每个工程团队中都非常有用的东西是每天站起来的。你必须每天进行沟通。
As engineers sometimes it can be a little difficult to want to communicate every day and not just program when you wake up but, that fifteen minutes, and you can do it remotely as well over slack or something, has always been really helpful in just kind of unblocking people. Time boxing, I think that a lot of these management practice's all rolled up into some abstract philosophies.
作为工程师，有时候想要每天进行交流有点困难，而不仅仅是在你醒来的时候进行编程，而是15分钟，你可以远程地通过松弛或其他的方式进行交流，一直以来，这对解除人们的障碍是很有帮助的。时间拳击，我认为很多这些管理实践都被总结成一些抽象的哲学。
And sprints are time boxed methods where you just not going to work on something infinitely, that's very helpful to kind of keep people's realities in check because often estimates can be off, and you know sometimes what we thought was going to take us a week can take us a month, myself included. So, time boxing is a good way to keep categories of that. I'd also say some other lightweight management techniques, you can probably employ right now, and your team is probably, one to one's, weekly one to one's. Such make sure if you're talking to people in a group and you're having stand ups, make sure you have some time to actually connect with people individually and get to learn more about their wants, their needs, and their emotions, and their careers.
冲刺是一种时间限制的方法，在这种方法中，你不能做无限的事情，这对控制人们的现实是很有帮助的，因为通常情况下，估计值可能是不存在的，有时你知道，我们认为一周的时间可能会花费我们一个月的时间，包括我自己。所以，时间拳击是一个很好的方法来保持这方面的分类。我还想说一些其他的轻量级管理技术，你现在可能可以使用，你的团队可能是一对一，每周一比一个人。所以，如果你和一个团体中的人交谈，并且你有站起来的感觉，那么你一定要有时间和人们单独交流，更多地了解他们的需求，他们的情感，以及他们的事业。
Jared Friedman: That's great guys. Okay, so now I want to change topics to the right way to work with non technical co-founders.
杰瑞德·弗里德曼：那是很棒的人。好的，现在我想把话题转换成与非技术联合创始人合作的正确方式。
And I think the topic that came up most commonly, in the start up school farm was the one that Ralph alluded to, which is how to deal with deadlines and time frames, particularly with non-technical co-founders? And I think particularly in the early days, so does anyone have thoughts on that? Any order is good.
我认为，最常见的话题是，在初创学校农场里，拉尔夫提到的一个话题，那就是如何处理最后期限和时限，特别是与非技术的联合创始人？我认为，尤其是在早期，是否有人对此有想法？任何命令都是好的。
Ralph Gootee: I'll volunteer for this since my non-technical co-founders is staring at me over there.
拉尔夫·古提：我会自愿参加这个项目，因为我的非技术联合创始人正盯着我看。
A few ideas here, if you got someone that's really non-technical, and I'm not saying my co-founder's really non-technical, I'm sure she can use a computer... But, if it's really non-technical this is an amazing testing opportunity for you.
这里有一些想法，如果你有一个真正非技术的人，而我不是说我的联合创始人是真正的非技术者，我相信她可以用电脑.但是，如果它真的是非技术的，这对你来说是一个惊人的测试机会。
I mean, I remember I would write this software, and I'd be so happy about it and I'd hand it to her and as soon as she touched it would break.
我的意思是，我记得我会写这个软件，我会很高兴，我会把它交给她，一旦她碰了它，它就会坏掉。
I mean I don't know she shook the iPad, she rotated it three times but, she had a way to break the stuff I wrote and that was amazing for testing in the beginning. So, that's one way to engage your non-technical co-founder. You eventually have to learn how to start pounding your deadlines, that's really hard to do.
我的意思是，我不知道她摇动了iPad，她旋转了三次，但是，她有办法打破我写的东西，这在一开始的测试中是很棒的。所以，这是吸引你的非技术联合创始人的一种方式。你最终必须学会如何开始重击你的最后期限，这真的很难做到。
I never got really good at this, I'm always optimistic. Even to this day I'm like "Oh, yeah it's gonna take me a week." So, I never really got good at this I'm just aware that I'm optimistic about it and that I'm always kind of off by a week and she's aware of that as well. So, eventually I talked to other engineering leaders that keep two books, the keep like a separate set of books they talk to other non-technical co-founders about. Say "okay the deadlines here" and then you have another set of books that's actually when you think you're going to get the job done.
我从来没有真正擅长这个，我总是乐观的。即使到今天我也会说“哦，是的，这要花我一周的时间。”所以，我从来没有真正擅长这个-我只是意识到我对此很乐观，而且我总是在一周前休息，而她也意识到了这一点。所以，我最终和其他保存两本书的工程部领导谈了起来，这套书就像他们和其他非技术联合创始人谈论的一套书一样。说“好吧，最后期限在这里”，然后你有另一套书，实际上是当你认为你将完成工作。
I think one thing that can be really helpful is having a process, a very lightweight process of like "Here's were we're like testing and here's release." Because often some people might not realize that IOS has a release cycle that's not controlled by the developers, it's controlled by Apple. So, you've got to pod that into your plan, you have to plan a little bit. So I found that a little bit of project management goes a long way when you're dealing with a non-technical co-founder and even better if their good at project management that's a great place to employ them as well.
我认为有一件事是非常有用的，那就是有一个过程，一个非常轻量级的过程，比如“这里我们就像测试和发布一样。”因为很多时候，有些人可能没有意识到iOS的发布周期不是由开发者控制的，而是由苹果公司控制的。所以，你得把它融入你的计划，你得计划一点。所以我发现，当你与非技术的联合创始人打交道时，项目管理有很大的帮助，如果他们擅长项目管理，那也是雇用他们的好地方。
Calvin...h-Owen: Yeah so all of my co-founders are technical, so we didn't really run into this problem in the early days, every one was kind of like "Oh, yeah I know what's happening here" if it slips we know exactly why it wasn't as big of an issue.
卡尔文.欧文：是的，所以我的联合创始人都是技术性的，所以我们在早期并没有遇到这个问题，每个人都有点像“哦，是的，我知道这里发生了什么”-如果我们知道它为什么没那么大的问题的话。
I found more recently with deadlines the trick that I've started using is one on one's, actually.
最近我发现，随着截止日期的推移，我开始使用的窍门实际上是一对一的。
Asking each person what they think will happen over the next three or four weeks.
问每个人他们认为未来三四个星期会发生什么。
And what I find asking one to one is that, one people don't anchor against each others answers so, you get a very unbiased view and it forces each person to think about the near term future what's going to happen. And second, each person is much more weary of the parts that they didn't work on and so, you get kind of a sense of where there might be trouble spots and typically, the end results is sort of like the wisdom of the crowds where it's kind of the average of all three or four answers.
我发现，一个人对一个人的回答是不靠谱的，所以你得到了一个非常公正的观点，它迫使每个人考虑近期的未来会发生什么。第二，每个人都对他们没有努力的部分感到厌倦，所以，你会有一种感觉。在那些可能会出现麻烦的地方，通常情况下，最终的结果有点像人群的智慧，在那里，这是三、四个答案的平均水平。
And so, I've started using that as a way to get a better sense of deadlines where each person has their prediction or mental model of what's going to happen.
所以，我开始用它来获得更好的最后期限的感觉，让每个人都对将要发生的事情有自己的预测或心理模型。
And then you kind of average them all out, to where it should be.
然后你让他们平均下来，到该去的地方。
Diana Hu: Well I guess in my case my co-founder didn't work in engineering or build products or ship products, it's mostly just in research. So in doing mostly a PhD so in that sense is kind of little bit non-technical in a sense of not having the experience of building and shipping products it's mostly kind of the algorithm side. So there was a bit of that work to kind of understand why certain things take long and why they need to be build a certain way but at some point, it was more he's letting me panel all of that.
胡黛安娜：嗯，我想就我的情况而言，我的联合创始人并不是在工程、制造产品或船舶产品上工作，主要是从事研究。所以，在做博士的时候，在这个意义上，有点非技术，没有建造和运输产品的经验，这主要是算法方面的。所以我们做了一些工作来理解为什么某些事情需要花费很长时间，为什么它们需要以某种方式构建，但在某种程度上，更多的是他让我讨论所有这些。
And he got engaged mostly on the external communications business, trying to find partners and all that. So, that's what happened sometimes that could be displayed whereas a technical founder you end up owning the product and the development.
他主要从事对外通信业务，试图寻找合作伙伴和诸如此类的事情。所以，这就是有时会发生的事情，可以显示出来，而技术创建者最终会拥有产品和开发。
And having clear communications and at least trying to set expectations that last, that's the hard part. There's always the trade off between engineering and product and business, right? The trade off on when to get things and be able to communicate that clearly.
有明确的沟通，至少尝试设定持久的期望值，这是最困难的部分。在工程、产品和商业之间总是有权衡的，对吗？在什么时候得到东西并且能够清楚地表达出来。
Lilian Chou: So my co-founders technical so I don't have much to offer here. Not much to add either on the deadlines and time estimates to do your best guess, do some padding.
周丽莲：所以我的联合创始人是技术上的，所以我在这里没有什么可提供的。在截止日期和时间估计上都没有什么可加的，来做你最好的猜测，做一些填充。
I'd say that's a one thing kind of the non-technical front though, that I do think it's worth mentioning is so today, a lot of you are probably building your products and writing code especially if you're one of the technical co-founders, at least in my experience that changes. So, I pretty much stop contributing to our code base about a year into the company, and it's for us leaders while I can't speak for all of us but at least for me, there's a pretty big shift that happens once you start gaining traction. Where it's less about building a product for a market and finding that fit, and it shifts more into building an organization and company, and a system of humans who are going to build something long lasting and great without a lot of your involvement. So, I guess what I'm trying to say is you know, that at some point you may end up doing a lot more non-technical things so, get ready for that.
我想说的是，这是非技术方面的一件事，我认为值得一提的是，今天，你们中的许多人可能正在构建自己的产品和编写代码-尤其是如果你们是技术联合创始人之一，至少在我的经验中是这样的。因此，我几乎不再为我们的代码基础贡献大约一年的时间了，这是为了我们的领导者，虽然我不能代表我们所有人，但至少对我来说，一旦你开始获得关注，就会发生一个相当大的转变。在这里，我们不需要为一个市场建立一个产品并找到合适的产品，而更多的是建立一个组织和公司，以及一个由人组成的系统，他们将在没有你的参与下建立一个持久的、伟大的东西。所以，我想说的是，你知道，在某个时候，你可能会做更多的非技术的事情，所以，做好准备。
Jared Friedman: That's great. Okay so, a lot of the companies and start ups school are at the phase where they are trying to figure out the right way to structure their early engineering team.
杰瑞德·弗里德曼：太棒了。好吧，很多公司和创业学校都处在这样的阶段，他们正试图找出正确的方法来组建他们早期的工程团队。
If they want to hire people locally, if they want to hire people remotely, if they want to hire only employees who work full time or if they want to hand off pieces of their product to contractors or to third party development firms. Can you guys talk about how you would think about that if you were starting a company now? Advice that you'd give them.
如果他们想在当地雇用人员，如果他们想远程雇用人员，如果他们只想雇用全职工作的雇员，或者他们想把他们的产品片段交给承包商或第三方开发公司。你们能谈谈如果你们现在创业的话会怎么想吗？你会给他们的建议。
And I think this is gonna be the last question and then we're gonna open it up to the audience.
我认为这将是最后一个问题，然后我们将向观众开放。
Lilian Chou: I can start. So we did not start with contractors, we started by building like hiring full time employees.
周丽莲：我可以开始。所以我们不是从承包商开始，而是从建筑开始，比如雇佣全职员工。
I think the main guidance I would give here is, you are building a product and a company, and your developing these core competencies it's a for the most part like if you end up contracting that out, you're actually not just contracting out through that technology expertise but, you're learning a lot and these early days of what's going to work for your clients, what the product actually is.
我认为我在这里给出的主要指导是，你正在建立一种产品和一家公司，而你正在开发这些核心竞争力-大部分情况下，如果你最终将这些核心竞争力外包出去，你实际上不仅仅是通过那些技术专家来外包，你还学到了很多，现在你已经学到了很多对你的客户有用的东西，产品到底是什么。
And so, sort of having that external to your company I think is, really big loss in the early days just in term of all that knowledge.
所以，在你的公司之外，我认为，在最初的日子里，从所有的知识来看，都是很大的损失。
I could see an argument if your just getting off the ground and your doing contracting kind of as a way to evaluate potential new hires.
我可以看到一个论点，如果你只是刚起步，你做承包，作为一种方式来评估潜在的新员工。
I could see that definitely being a path. But again, that's sort of with the intention of building your team. On the outsourcing front I think it's a similar thing of you really need to look at what is your go competency, that's where your investing in what's your IP. You don't want to outsource that at some point if you do, your pretty much just a marketing company.
我可以肯定的看到这是一条道路，但同样，这也是为了建设你的团队。在外包方面，我认为这是一个类似的事情，你真的需要看看什么是你的围棋能力，这是你的投资在什么是你的知识产权。你不想在某个时候把它外包出去-如果你这样做的话，你的公司只不过是一家营销公司。
And so, I'd say if you are...
所以我会说如果你是.。
And different business models might have different requirements so, for some of you it may make sense to outsource a large part of what your building. But, for us we have experimented a little bit with outsourcing. I'd say our approach has really been to make sure those projects are very well defined and not on the critical path. So, that we can experiment, it is a different type project to manage sort of outsource talent and that way you can sort of learn and see if that works for your business.
而且不同的商业模式可能有不同的要求，所以对你们中的一些人来说，外包你的建筑的很大一部分可能是有意义的。但是，对我们来说，我们已经尝试了一些外包。我想说，我们的方法是确保那些项目的定义非常明确，而不是在关键的道路上。因此，我们可以尝试，这是一个不同类型的项目来管理某种外包人才，这样你就可以学习，看看这是否适用于你的业务。
And if it does great, and if it doesn't it's fine. Was there also a question about remote?
如果它做的很好，如果它没有，它是好的。还有关于遥控器的问题吗？
Ralph Gootee: Yeah, local versus remote employees.
拉尔夫·古蒂：是啊，本地员工和偏远员工。
Lilian Chou: Yeah I think that depends on what type of culture you want to build. So for us it was really important for us to have our team together so, we hired up a local team.
周丽莲：是的，我认为这取决于你想要建立什么样的文化。所以对我们来说，让我们的团队在一起是非常重要的，所以我们雇佣了一支当地的球队。
And then in sort of the last year or so, we have actually started tapping into remote engineers. There's definitely a little bit of a culture shift with that. We're still predominantly local but there are a lot of advantages including, being able to tap into other talent pools.
在过去一年左右的时间里，我们实际上已经开始接触远程工程师了。这无疑会带来一点文化上的转变。我们仍然主要是本地人，但有很多优势，包括，能够利用其他人才池。
And it has actually turned out to be a really good forcing function for documentation without explaining your code, explaining your decisions which is good for a number of reasons including, just like as you grow communication as one of the harder problems you have to solve. So, yeah.
事实上，它实际上是一个很好的文档强制功能，无需解释您的代码，解释您的决定是有很多原因的，包括，就像您将通信作为您必须解决的更难解决的问题之一样。所以，是的。
Diana Hu: So I think for us because so much of the core of the technology is what our company is. We didn't quite outsource any of that. We did contract people as more of an interview process. So we would work with and contract someone for a month before we gave them an offer. So that's what we did. But, we did outsource more things that we really thought they were not essential to our company. For example, building 3D models, some of the design, some of the writing technological documentation, websites. Things that we could do it if we had the time or wanted to, we knew we could do it for stuff like I could build a website but, our time was better spent then the cortex. So those were things we did outsource. And in terms of remote versus local because everything was so complex with what we build we choose as a culture to be more all on site.
胡黛安娜：所以我想是因为我们公司是技术的核心。我们并没有把这一切都外包出去。我们和人签了合同，更像是面试的过程。因此，在我们给某人一个月的合同之前，我们会与他们合作并与他们签订合同。所以我们就是这么做的。但是，我们确实外包了很多我们认为对我们的公司来说不重要的东西，比如建立3D模型，一些设计，一些写作技术文档，网站。如果我们有时间或者想做的事情，我们知道我们可以做一些事情，比如我可以建一个网站，但是，我们的时间比大脑皮层更好。因此，这些都是我们外包的事情。在偏远地区和地方，因为我们建造的东西太复杂了，我们选择把它作为一种文化，让它更多的出现在现场。
And to this day we are still building a team locally. But, I think you could handle... There's a lot of stories of companies that do remote but, you kind of have to start remote first.
直到今天，我们仍在当地建立一个团队。但是我觉得你能应付.。有很多公司做远程的故事，但是，你必须先开始遥控器。
Calvin...h-Owen: Yeah, I can share a little bit from our story. So in the very early days we basically, only hired full time folks. We didn't experiment with contractors. Kind of the only case where we would outsource is when AWS could take some piece of infrastructure that we're building or like some new product feature and we could build on top of that.
卡尔文.欧文：是的，我可以分享一下我们的故事。所以在早期，我们基本上只雇佣全职员工。我们没有和承包商做实验。我们要外包的唯一案例是AWS可以采用我们正在构建的一些基础设施，或者喜欢一些新的产品特性，而我们可以在此基础上构建。
I think that was still probably the right move, especially in the early days it feels like a start up, is really fragile and you want a bunch of people who all pointed in the same direction and really kind of in it for the long haul. On the local versus remote piece we actually started hiring only remote people. We were really involved with a lot of different open source communities on GitHub, particularly there were some in Node in the very early days, some Java Script ones, Component etc.
我认为这可能仍然是正确的举措，尤其是在最初的日子里，它感觉像是一个开始，是非常脆弱的，你想要一群人，他们都指向同一个方向，而且从长远来看也是一样的。在本地和远程的部分中，我们实际上只雇佣了远程人员。我们在GitHub上确实参与了许多不同的开源社区，特别是在早期的Node中，有一些Java脚本社区、组件等等。
And so, these were people who we had been working with and collaborating with for years at this point who then, when we were ready to start hiring we just said "Hey, would you like to work more closely together?" I think it came with it's own set of trade offs. On the plus side we had access to these people who were insanely talented, not in the San Francisco Bay area but, who were used to working with us already.
所以，这些人就是我们多年来一直和他们合作的人，当我们准备开始招聘的时候，我们只是说：“嘿，你们愿意更紧密地合作吗？”我认为这是与它自己的一套权衡。好的一面是，我们可以接触到这些人，他们是疯狂的天才，不是在旧金山湾区，而是，他们已经习惯了与我们合作。
And who we very clearly built an insane amount of value for Segment.
我们非常清楚地为分部创造了一笔疯狂的价值。
I think the trickier part for us to get right was around the communication piece and all kind of being pointed in the same direction from a product perspective. So, while we grew remote from about the first 10 or 15 hires we then only grew locally through about the next 70. And then only recently started opening remote back up.
我认为，对于我们来说，更棘手的部分是围绕着沟通部分，从产品的角度来看，这一切都指向了同一个方向。所以，虽然我们从最初的10到15名员工增长到了很远，但在接下来的70段时间里，我们只在本地成长，直到最近才开始开放远程备份(Remote Backup)。
I think now, it's because we actually have enough bandwidth to create a really good remote culture where we put an emphasis on that documentation, that communication piece and we were actually able to really hire folks who have been remotely for years as well.
我现在认为，这是因为我们实际上有足够的带宽来创建一种非常好的远程文化，我们把重点放在文档和通信部分上，我们实际上能够雇佣那些已经远程工作多年的人。
Ralph Gootee: Some really good advice given on this panel so far.
拉尔夫·古提：到目前为止，在这个小组上给出了一些很好的建议。
I think the trade offs are the thing for you to keep in mind the most.
我认为权衡是你最需要记住的事情。
I was thinking back towards contractors and I'll tell you a quick story of a contractor. Our first two hires actually, as I was thinking about it contractors. One of them helped us organize our bills and our kind of like office stuff and the other one helped us develop some technology. Someone I worked with when I used to work at John Hopkins and even though he was a contractor at first, he actually... You know we didn't have money to pay him because he was my friend so, we paid him in equity.
我在回想承包商，我会给你讲一个承包商的故事。实际上，我们的前两名雇员，正如我所想的那样，承包商。其中一个帮助我们组织我们的账单和类似的办公用品，另一个帮助我们开发一些技术。我以前在约翰·霍普金斯工作时和他一起工作的人，虽然他起初是个承包商，但实际上.你知道我们没有钱付他因为他是我的朋友所以我们给他平分。
And he joined us as out first engineer eventually and helped us build some really core technology for our company and really was a great addition to PlainGrid. So, I think that even though I wouldn't suggest hiring a contractor immediately, we just did what was right for us at our company size and what we needed right then was like "Hell yeah, I need this guy to write some stuff for me and he'll take equity as payment. Wonderful because I don't got anything else to pay him in." So, I think just be open hearted with what you think is needed for your business right then. Know there's a lot of trade offs with contractors. The other thing to note is, this was my friend. We've had contractors I've hired as well. There's this ignorant feeling...
他最终以第一工程师的身份加入了我们的行列，帮助我们为我们的公司建立了一些真正的核心技术，这对PlainGrid来说确实是一个很好的补充。所以，我认为，即使我不建议立即雇用一个承包商，我们只是做了对我们来说对我们合适的公司规模，我们当时需要的是“地狱，是的，我需要这家伙写一些东西给我，他会把股权作为报酬。”太好了，因为我没有别的东西要付钱给他了。“因此，我认为，只要开诚布公，你认为什么是你的业务所需的权利。你知道和承包商有很多的取舍。另外要注意的是，这是我的朋友。我们也有我雇的承包商。有一种无知的感觉.
I can't even now I feel it, when you hire a contractor that's like "Oh, great I don't have to manage this person," and that is so not true. Management of contractors is significant time for you as founder. That is not a free hire.
我现在甚至感觉不到，当你雇用一个承包商时，你会说“哦，太好了，我不需要管理这个人”，这是不对的。管理承包商是您作为创始人的重要时间。这不是免费雇用。
It's sometimes is worse actually, it is more management time for a contractor than a full time employee. So keep that in mind as well, as the remote things also an interesting topic. When we started our company we tried to aim to have people in San Francisco but, yeah I realized actually as co-founders we split off for months at a time. We'd be like "Oh, yeah I'm gonna go back to Chicago for a month." And then one of my co-founders who work out of Chicago for a month or two and that was totally cool as well. We've gone back and forth on this over our years over, and over again between allowing remote, not allowing remote.
它有时更糟，实际上，它是更多的管理时间，一个承包商，而不是一个全职员工。所以请记住这一点，因为远程的事情也是一个有趣的话题。当我们开始我们的公司时，我们试图让人在旧金山，但是，是的，我意识到，实际上，作为联合创始人，我们分开了几个月一次。我们会说“哦，是的，我要回芝加哥一个月。”然后我的一位联合创始人在芝加哥工作了一两个月，这也很酷。在过去的几年里，我们一直在反复讨论这个问题，一次又一次地允许远程，而不是远程。
Allowing remote when it's a friend or a really good best in class IC that can really develop a lot of things. Now, we're completely open as a company it doesn't matter. We hire managers remote, we hire local, designers, products, everyone, it doesn't really matter we're just looking for the best talent we can get. So, I think the best advice you've gotten already is just do what's right for you at the size of your company and know that there's trade offs with all these decisions but, there's no easy answer for any of these questions.
允许远程时，当它是一个朋友或真的很好，在班级IC，真的可以发展很多事情。现在，我们是一个完全开放的公司-这不重要。我们在遥远的地方雇佣经理，我们雇佣当地的设计师，产品，每个人，我们只是在寻找我们能得到的最好的人才。所以，我认为你已经得到的最好的建议就是在你的公司规模上做对你合适的事情，并且知道所有这些决定都是有取舍的，但是，对于所有这些问题都没有简单的答案。
Jared Friedman: Great okay, I think we've got time for one or two questions from the audience. Questions? Questions? One over there. You, you yeah.
杰瑞德·弗里德曼：好吧，我想我们还有时间回答观众的一两个问题。问题？问题？那边有一个。你，是的。
Speaker 7: So if you were to start another company again, how would you accelerate development process? What would you do different?
演讲者7：那么，如果你要重新开始另一家公司，你将如何加快开发过程？你会做什么不同的事？
Jared Friedman: Okay, I'm just going to repeat the question so everyone can hear it.
杰瑞德·弗里德曼：好的，我要重复这个问题，这样每个人都能听到。
If you were going to start another company now, what would you do to accelerate the development process? Any takers?
如果你现在要开另一家公司，你会做些什么来加速开发过程？有人接电话吗？
Diana Hu: Yeah, sure.
胡黛安娜：是的，当然。
I mean, I think we spent too much time building technology on my side. So try to really get that product market fit as soon as possible. That is a challenge in terms of the areas that you pick because if you're in a kind of frontier technology space where like AR, VR or [inaudible] those lead times could be really long. Or think about what kind of company you want to build.
我是说，我觉得我们花了太多时间为我建立技术。所以试着尽快使那个产品市场适应。对于你选择的领域来说，这是一个挑战，因为如果你处在一种前沿技术领域，比如AR、VR或(听不见的)，这些准备时间可能真的很长。或者想想你想建立什么样的公司。
Lilian Chou: I'd say get in front of users all the time. Find your user base, it's actually a lot harder to build a product in this vacuum where you're just like in your head and you're ideating with your co-founder and you're like "What if we do this, what if we do this. These all sound great. No, this idea sounds bad." But, it's like way easier to just put it in front of somebody and have them say "This is great or this sucks." That feedback loop is invaluable.
周丽莲：我想一直在用户面前。找到你的用户群，在这个真空环境下建立一个产品要困难得多，你就像你的头脑中一样，你在和你的联合创始人一起思考，你会说“如果我们这么做，如果我们这样做，怎么办？”这些听起来都很棒。不，这个主意听起来很糟糕。“但是，就像把它放在某人面前，让他们说“这很棒或者很糟糕”就更容易了。反馈回路是无价的。
Calvin...h-Owen: Yeah, I'd echo the sentiment on users 100%. Get out in front of them, start showing things to them. Make sure you're digging deep to make sure that you're really solving their problem.
卡尔文.欧文：是的，我完全赞同用户的看法。站在他们面前，开始向他们展示东西。确保你在深入挖掘，以确保你真的解决了他们的问题。
I think if I were to start again today, actually I'd build two or three versions which, I just intended to throw away. Maybe this is biased on prior experience but, I think that fact that you can get reps in a very safe manner where then, when you're really ready to start you can, just kind of go nuts building out the V1, I think is really powerful.
我想如果我今天要重新开始的话，实际上我会构建两到三个版本，我只是打算扔掉这些版本。也许这是对先前经验的偏见，但是，我认为你可以一种非常安全的方式得到代表，当你真的准备好开始的时候，你可以，只是有点疯狂的建立V1，我认为是非常强大的。
Ralph Gootee: I love mobile development, I love Swift, I love Kotlin but, I don't think I would choose to have write four different platforms.
拉尔夫·古蒂：我喜欢手机开发，我喜欢斯威夫特，我爱科特林，但是，我不认为我会选择写四个不同的平台。
If I was gonna write again I'd probably would've picked one of the cross platform development libraries.
如果我要再写一次，我可能会选择一个跨平台的开发库。
I don't know which is best, you'd have to tell me.
我不知道哪一个最好，你得告诉我。
If anyone has like...
如果有人喜欢.。
After this give me your strong opinions of which one of those is best. They all seem to have trade offs. Probably the best advice I could give though is, I'd stop coding a little bit earlier and I would start hiring a little bit earlier because I think there's a lot of me that wanted to passionately write those futures and if I had instead been passionately hiring other developers we would've built faster I feel.
在此之后，请给我你的强烈意见，其中哪一个是最好的。他们似乎都有取舍。也许我能给出的最好的建议是，我应该更早一点停止编写代码，我会更早地开始招聘，因为我认为有很多人想要热情地写那些未来，如果我能热情地雇佣其他的开发人员，我会感觉更快。
Jared Friedman: Interesting. Okay, one more question. Over there.
杰瑞德·弗里德曼：有意思。好吧，还有一个问题。在那边
Speaker 8: As a non-technical founder what do you suggest to communicate with the CTO's regarding the implementation of new features where the CTO refers to the technical founders insist on stability, and scalability and your driving features given by the users, what would be the communication style or?
演讲者8：作为非技术创建者，您建议如何与CTO公司沟通，以实现CTO所指的新功能-CTO指的是技术创建者所坚持的稳定性、可伸缩性和用户提供的驱动功能，通信风格是什么？
Ralph Gootee: Get them in front of the users, bringing them into the meetings, get them over the phone. While then, give the questions you know, kind of set it up a little bit where you're trying to bait the users into giving the feedback that you're looking for or you won't get the feedback that you're looking for in maybe there's some adjustment there too. So, get them in front of users as much as you can that's the most powerful tool you have in my opinion.
拉尔夫·古提：把他们带到用户面前，带他们参加会议，打电话给他们。然后，给出你知道的问题，在你试图诱使用户给出你想要的反馈的地方设置一些问题，否则你就得不到你想要的反馈-也许那里也有一些调整。所以，让他们在用户面前尽可能多，这是你最强大的工具，在我看来。
Jared Friedman: Okay, thank you all so much. This was great.
杰瑞德·弗里德曼：好的，非常感谢你们。太棒了。