26 Lessons From Being a Developer at a Startup
「 湾区日报评语 」：总结得很不错：要舍得花钱买好的开发工具（软件、硬件），时间比钱贵；CEO休假是件好事，说明公司已能自动驾驶了；必须得腾出专门的时间来学习新技能；讨论时要避免外向的人说个不停、内向的人插不上话。这个也有道理：团队里的新手与老战士混搭，若都是老战士，各个都想证明自己是最牛逼的，吵个不停，永远做不了决定；若都是新手，两三天就换一次编程框架，哪受得了？
「 原文链接：我在创业公司学到的 26 个经验 」
在创业公司做工程师学到的 26 个经验
在过去的三年，我在柏林为一家小的 B2B 创业公司工作。我作为第一个加入公司的后端开发工程师，经历了公司的快速成长，从服务 200 个客户到服务 720 个客户，从 20 万美金的年度审查到 320 万美金的年度审查，从 5 名雇员到 25 名雇员。
下面的经验是我在那段时间学到的非常简单的个人总结，没有什么比这更简短的了，希望对你有用。
1.回顾至关重要。我们经常作为一个团队，坐在一起来回顾最后一次的产品迭代。回顾和评估的重要性不能被夸大。每个参与者都必须先考虑好，哪些事情进展顺利，哪些事情可以提升。团队只有在每个参与者都表述完自己的想法后开始讨论。通过这种方式，每个人都能够提出重要的问题，比哪些最能说的人主导会议要好得多。
2.定期花时间。在繁忙的创业环境中，可能一周中很难抽出一个小时和你的主管谈论。但是这正是我们所做的事，而且效果良好。你可以深入、及时地讨论问题，并且作为一名员工更感到有价值。对此，没有什么可以代替这样做。
3.为编程工具付费。对于计算机来说，每 GB 或者 MHz 都有助于加快工作速度。对于软件，每一个有用的工具都能让你的产出更有效率。给开发者一个快速、现代化的工具集，也体现了公司的对于他们的重视。
4.去见你的客户。我们定期的去拜访当地的客户，每年公司都有一次去用户热点地区出差 ( 例如纽约和旧金山 )。这让一切变的有所不同，与客户交换电子邮件是一回事，但与他们见面并听取他们的痛苦和成功则是完全不同的经历。当你回顾开发过程，这些用户的看法会有很大且持续的影响力。
5.不要缓慢的工作。你知道，当缓慢的工作变成办公室里的插科打诨时，再行动起来就晚了。几乎没有什么比一个慢的反馈周期更让人沮丧了。我们在后端使用 Java ，在前端使用 Webpack。一周后，我们都开始变得越来越慢。最后，缓慢的让我想撞墙。从长远来看，购买更快的机器也不能解决构建程序缓慢的问题。你需要思考应用程序的结构来处理这个问题，比如模块化。没什么其他快速修复的办法。
6.跨职能团队 FTW。在我们组建跨职能团队之前，我们只能有效的解决小项目。一旦我们有一个由设计师、前端和后端开发人员组成的团队，做事的效率就大大提升了。它使我们可以做更大、更有影响力的功能。它带来了一些挑战，但总的来说，这是创业发展的关键一步。
7.Trello 不能作为很好的 Bug 或者项目管理工具。我们用 Trello 来管理我们的 Bug。我很喜欢 Trello，但是我总感到这不符合标准。它很难搜索，只能放大到某一点。项目管理也是如此。在一定程度上，使用的简单性和易用性会逐渐消失，会变得太过庞杂和无效。我更喜欢专门的工具，真正地促进你想要实现的东西。
8.承担责任或者消亡。为了在任何公司取得成功，你都要承担责任，并且越大越好。与企业环境不同之处在于，这样做很容易：角色不是一成不变的，很容易就可以抓住别人不会承担的责任。你必须成为这样的人才能拉高你的地位。你需要积极主动塑造自己的形象，否则别人会为你做。如果你把奖励积分作为公司的目标，你可以成为一名优秀的工程师，但是当公司只重视功能开发的时候，你就是在瞎折腾了。
9.适应或者离开或者与之挑战。你或许在某些事上与你的管理者意见不合。在这种情况下，你要确定这些问题对你来说有多重要。如果非常重要，那就为你认为对的方案站出来。但往往这将是一场艰苦的战斗。如果你身边的人很少支持你，或者甚至不赞同你的观点，那么你就要问问自己是否值得。你可以忽略这一点，或者另外寻找工作。
10.寻找实际上重要的好处。很多创业公司都有很多好处，有人为他们的乒乓球桌而骄傲，有些想则是令人印象深刻的周五酒吧夜，还有一些炫耀他们的糖果福利。这是一个陷阱！寻找有意义的好处，比如午餐和学习，教育预算或健康福利。
11.CEO 应该可以休假。当一家公司发展壮大时，CEO 必须放弃越来越多的责任，不能光靠一个人扩大公司的规模。基本上，CEO 必须逐步取代自己。如果他/她正在制定度假计划，可能是一个很好的指标。
12.你需要一个实时消息策略。我们使用 Slack 沟通，虽然它很有趣，但也在扼杀生产力。我们对如何使用工具没有共同的观念模式。定义清楚聊天的结果是什么很重要，并且是发送 Email 或者面对面交谈再或者是使用 wiki， 哪个更好？
13.首先你可以影响人们怎么看待你。无论你说什么或者做什么，都会塑造别人对你的看法。如果你周末都在工作，你可能是“工作狂”；如果你推出新功能，你可能被称为“奇思妙想的人”。而且这些看法还会被坚持。通常情况，早期的印象往往是最重要的，之后改变周围的人对你的看法则越来越难。
14.平衡好高级工程师和初级工程师。在后端，我们几乎只有拥有多少年经验的高级开发人员。但是令我惊讶的是，这导致了即便在很多的讨论下也很少取得好的讨论结果。这些讨论很激烈，有时候我想是否每个人都能完整表达自己的观点。另一方面，前端人人都是初级工程师。他们表现出很强的激情和创造力，这很不错，但是往往错过更大的局面，也缺乏高水平的最佳实践。关键是要去平衡好高级工程师和初级工程师，让他们一起工作。
15.在开始编码之前，始终要有个视觉模拟呈现。一个新功能有很多利益相关者。例如：项目经理、设计师、产品所有者、CEO、开发人员和客户。他们都有自己的期望和关注的重点，所以传达新功能愿景的最佳方式似乎是尽可能的接近最终的视觉表示。这样做一次又一次的帮助我们防止误解，促进大家意见一致。
16.每个团队一个办公室。多次反复的验证表明，一个开放式的办公室是个坏主意。我认为一家公司通常希望在办公室租金上省钱，并将其包装成合作和充满创造力的地方。从我的经验上来看，你需要一个安静的地方来完成工作，但是仍然需要能够与你的团队成员轻松地沟通。我发现，如果你保持一个小的团队，每个团队一间办公室能很好的平衡上述需求。
17.如果没有缓和的话，外向者会主宰每一场讨论。像我这样的内向的人，在职场上可能会有挑战性。外向的人通常喜欢说很多话或者写很多东西。内向的人通常不能与之相比。因为外向的人可以更快、更自信、更精确地做出反应，所以我们会处于劣势。任何不处理这个问题的公司，都会因为“沉默的少数”而失去伟大的想法和贡献。
18.开发者需要去谈论他们的共同心态。一旦你从独立开发转到一个开发团队，就会有冲突。当然，每个人都不一样。比如代码风格、代码结构、开发情况、处理 Bug 的流程和代码审核等等，这就是为什么谈论共同心态如此重要。简单地在 wiki 里写下规范是不起作用的。它需要被活用、被理解，甚至在需要的环境下被改变。所以定期的的讨论是不可避免的。
19.定期的状态更新是激励。第二天我在整个团队面前，他们听我讲述我如何通过工作激励我自己，每周的状态更新都是如此。当我们的创业公司很小的时候，每个人都用几句话来分享上周的成功和失败。当公司发展壮大，只有团队的共同努力时，才有了动力。
20.及时衡量学习预算，而不是金钱。尽管我们已经有了学习预算，但是除了出席会议之外，它几乎没有用过。研讨会可能会没有什么收获，甚至连最新的技术都没有。但是和我的很多同事一样，可以从博客、书籍和视频中学到新的东西。所以，我建议开发者每年投入几天的时间来自己学习。无论如何，这是我们必须做的，通常公司也可以直接支持周末学习。
21.结对编程被低估。在团队成员甚至跨团队之间分享知识的好办法就是结对编程。就我而言，我觉得这样的做法比评审更有效。编码过程中的讨论非常宝贵，它的效果通常取决于两个开发者之间的相处程度，从经验上来看，把不同的人放在一起实际上可以产生最好的结果。
22.功能卡在了发布的过程。这个可能看起来很明显，但很容易被忽略。我亲眼目睹了一些功能陷入僵局好几个月，因为没人知道在一个分支里如何对一个完成的功能有所进展。清楚的了解谁有哪些责任非常重要，或者有一个人来处理这个问题就更好了。
23.有自主权的时候会发生伟大的事情。让开发人员有机会在事情上可以成为创新的强大源泉。当一家公司支持优秀开发者的自然驱动时，就会发生伟大的事情。否则，最有贡献的开发者无论如何都会有自己的机会 ( 例如加班或者周末 )，从长远来看，这可能会导致不快乐甚至倦怠。
24.当你想要坚持一个观点，那就一遍又一遍的说。你有一个重要的信息，你希望每个人都能理解、支持并记住。你不能只说一遍，或者用粗体字把它放在幻灯片里。你要一遍一遍的重复它，它需要被人们认识清楚。你不应该对你所说的有所猜疑，想要了解更进一步的建议，请看这本优秀的书 Make it Stick 。
25.黑客是创业文化中很重要的部分。一家创业公司总是有更多的事情要做，而不是资源。优先级是必要的，这通常意味着迅速拼凑出一个几乎不起作用的解决方案。有时候出于好的原因，比如制作一个功能原型，看它是可行。但这如果这样，你很少有时间回去做的更好。然而，我一直觉得恼火的是一个黑客能否庆祝。它总让我觉得在作弊，但我已经接受了。在任何初创公司，黑客都是一个必要的小罪恶，但请不要做过头。
26.Deadline 简直愚蠢。在当今这个不断变化的世界里，Deadline 是一个过去的人为因素。Deadline 只能让经理感觉良好，但是抹杀了所有关于软件开发的好的东西。Deadline 成为了越来越可笑和危险的方式，更糟糕的是还有伴随 Deadline 的一系列要求。这使我们回到了软件开发古老的开始，在以后也没有 Deadline 的那么个地方。
作者：Stephan Behnke
编译：by Erlich Liu
此计划面向所有科技进步青年，让您提前对即将改变我们生活的科技有所了解，对有可能成为未来商业主流的公司和产品有所察觉，对您个人的成长有所感悟。文章多来源于「 湾区日报 」的推荐，但不限于「 湾区日报 」。此计划目前由 Bianka Chu & Erlich Liu 推动，也希望有志于此的您加入和关注。