联合创始人英文名片_如何成为自己的技术联合创始人-为什么值得花时间

联合创始人英文名片

Note: this blog is inspired by my recent podcast interview with freeCodeCamp’s Quincy Larson, where we talk about this in the last 15 minutes or so.

注意 ：此博客的灵感来自于我最近对 freeCodeCamp的Quincy Larson进行的播客采访 ，我们在过去15分钟左右的时间内对此进行了讨论。

Looking for a technical co-founder? I was too. For many years. It was a difficult journey, because the prevailing “wisdom” is you need to go out and find a technical co-founder because all the successful startups had them (not true, by the way). But what happens when you're at the end of your runway, and your choice is to learn to code, or quit?

寻找技术联合创始人？ 我也是。 很多年了。 这是一段艰难的旅程，因为普遍的“智慧”是您需要外出并找到技术联合创始人，因为所有成功的初创公司都拥有他们(顺便说一句，不是真的)。 但是，当您走到跑道的尽头，而您的选择是学习编码或退出时，会发生什么呢？

Technical co-founders are supposed to give you the stability, the complement of essential skills, and the accountability that are not possible being a solo founder. Of course, no one is tracking the countless examples where having a rubbish co-founder made your journey immeasurably harder, or thwarted your ability to progress altogether. But of course, what “they” mean is that you don’t need just a technical co-founder, you need the right technical co-founder, duh!

技术联合创始人应该为您提供稳定性，基本技能的补充和责任感，这是单独创始人无法做到的。 当然，没有人能追踪到无数的例子，在这些例子中，一个垃圾联合创始人使您的旅程变得无比艰辛，或者阻碍了您的整体进步能力。 但是，当然，“它们”的意思是您不仅需要技术联合创始人，还需要合适的技术联合创始人，du！

Well, of course.

嗯，当然。

None of this is particularly helpful advice. It’s like saying you need to be awake to have good ideas (seems obvious and intuitive, but not always true).

这些都不是特别有用的建议。 这就像说您需要醒来才能拥有好主意(似乎很明显和直观，但并不总是如此)。

我作为非技术(独奏)创始人的经验 (My experience as a non-technical (solo) founder)

Here is what I’ve personally experienced in the many years I spent looking for technical co-founders:

这是我多年来寻找技术联合创始人的亲身经历：

1. I spent a ton of time browsing forums, LinkedIn, and contact lists looking for people who met the minimum criteria
   我花了很多时间浏览论坛，LinkedIn和联系人列表，寻找符合最低标准的人
2. I spent a great deal of time not being able to validate much, test much, progress much because I didn’t have anything to validate, test or progress other than a well-honed pitch
   我花了很多时间无法进行大量验证，测试和进步，因为除了良好的音调之外，我没有其他任何东西可以验证，测试或进步
3. I met a lot of people, and most were not interested in entrepreneurship, or didn’t have the necessary work ethic (aka masochistic streak)
   我遇到了很多人，并且大多数人对企业家精神不感兴趣，或者没有必要的职业道德(又称受虐狂)
4. I met a lot of people who were interested but for all the wrong motivations (get rich quick, glory, fame…)
   我遇到了很多感兴趣的人，但动机都是错误的(快速致富，荣耀，成名……)
5. I met a few people who had the right motivations and (as far as I could tell) the right skills, but who did not have the mentality to withstand the brutality of starting up
   我遇到了几个动机合适，(据我所知)正确技能的人，但是他们没有承受起步残酷的心态

6. I met a very few people who had experienced starting up and had the skills, but none of them were enthused by my concepts (statistical inevitability)

   我遇到了很少的有创业经验和技能的人，但是他们都不对我的概念感兴趣(统计的必然性)

I knew diddly squat about software, though I wanted to start a technology company. So, here are my mistakes from back then:

尽管我想创办一家技术公司，但我对软件深信不疑。 所以，这是我从前的错误：

1. I had no clue about the fundamental, most basic aspects of software and its design
   我对软件及其设计的基本，最基本方面一无所知

2. I grossly underestimated the complexity involved (didn’t know how much I didn’t know)

   我完全低估了所涉及的复杂性(不知道我不知道多少 )

3. I grossly underestimated time involved
   我大大低估了所花费的时间
4. I grossly overestimated the people I approached to be technical co-founders
   我严重高估了我成为技术联合创始人的人
5. I significantly (but not knowingly) overstated my role in the initial period — “hustling” and “business development” were my skills, and I did not appreciate that some of the most successful startup companies spent a third of their time on those things, and most of their time building the product and responding to customer needs
   我在最初阶段显着(但不是有意地)夸大了我的角色-“忙碌”和“业务发展”是我的技能，并且我不欣赏一些最成功的创业公司在这些事情上花费了三分之一的时间，他们大部分时间都在构建产品并响应客户需求

For close to 4 years I told myself “I do not need to learn to code. My talents are better used elsewhere”. Sound familiar?  

近四年来，我对自己说：“ 我不需要学习编码。 我的才能在其他地方得到更好的利用 ”。 听起来有点熟？

It’s only partly true. As someone with very limited resources, my talents needed to be used on whatever gave me the best chance at succeeding. I had some spare cash I could spend on developers. I had some time I could spend managing them, and that time was mainly created by cutting down on social activity, sleep and disallowing myself weekends. I had valuable experience I could use in putting together a business plan. I had strong social skills and communication skills I could use to pitch to prospects, and also to potential co-founders.

这只是部分正确。 作为一个资源非常有限的人，我的才华需要用于使我获得最大成功机会的一切上 。 我有一些闲钱可以花在开发人员身上。 我有一些时间可以花在管理这些事情上，而这段时间主要是通过减少社交活动，睡眠和不允许自己周末来创造的。 我有宝贵的经验可用于制定业务计划。 我具有很强的社交能力和沟通能力，可以用来吸引潜在客户以及潜在的联合创始人。

I did all these things, and inched closer to my goals. But it took far too much time. Of course progress is always slow, certainly slower than we would like. But we only slow ourselves down further by not looking at the situation objectively. Even when I did have co-founders (who eventually quit because it was too hard or their life circumstances changed) I found that managing their work ethic, expectations and moods took a great deal of my time and energy. That’s ok — but no one budgets for that.

我做了所有这些事情，并且更加接近目标。 但是花了太多时间。 当然，进展总是缓慢的，当然比我们期望的要慢。 但是，我们只能通过不客观地看待局势来进一步放慢自己的步伐。 即使我确实有联合创始人(他们后来又因为太辛苦或生活条件改变而最终辞职)也发现，管理他们的工作道德，期望和情绪会占用我大量的时间和精力。 没关系-但没有人为此预算。

You see, as aspiring founders, our greatest enemy is anything that causes us to lose time. With every week that passes without results you’re more likely to quit. And we never truly know what our time-cost is when we choose a course of action. And we never know when we are victims of the sunk-cost fallacy.

您会看到，作为有抱负的创始人，我们最大的敌人是任何导致我们浪费时间的事情。 每经过一周却没有结果，您更有可能退出。 当我们选择一个行动方案时，我们永远不会真正知道我们的时间成本。 我们永远不知道什么时候成为沉没成本谬论的受害者。

Looking back, it cost me 4 years and quite a lot of money. And at the end of that, the only way to start again was to repeat that expenditure of time, effort and money, doing the same thing — putting together a plan, and then desperately looking for a technical co-founder.

回想起来，这花了我4年时间和很多钱。 最后，重新开始的唯一方法是重复花费时间，精力和金钱，做同样的事情-制定计划，然后拼命寻找技术联合创始人。

Here we go again…

再来一次…

一个简单的时间 (A simple time-math)

In 2014 I read a blog by Sam Altman, the president of YCombinator. In it, Sam says some of the most profound truths I’ve ever disregarded. Here is the tweet that I dug up for fun.

在2014年，我读了YCombinator总裁Sam Altman的博客 。 在其中，Sam讲了一些我无视的最深刻的真理。 这是我挖出来的有趣的推文。

The first 2 or three times I read his piece I made really sensible sounding arguments as to why it did not apply to me. I was wrong and it cost me money, but worse, it cost me a lot of time (I made back the money).

我阅读他的作品的前两到三遍，对于为什么不适用于我，我提出了非常明智的观点。 我错了，花了我很多钱，但更糟的是，这花了我很多时间(我把钱还了)。

He basically posits that it’s faster (much faster) to learn to program enough to build your prototype than it is to find a reliable, dependable co-founder who is a good fit, and will go the distance. Not just faster, but the odds of progress are vastly higher.

他基本上认为，学习足够的程序来构建原型要快( 要快得多 )，而不是找到一个合适的，可靠的，可靠的联合创始人，并且会走得更远。 不仅速度更快，而且进步的几率更高。

It’s obvious. Finding a good co-founder, technical or otherwise, is a long shot — like finding the right partner for life — and requires some degree of luck. Learning to code a bit is faster, needs no luck and therefore has a higher success rate.

很明显。 寻找一个优秀的联合创始人，无论是技术上还是其他方面，都是一个漫长的尝试-就像找到一生的正确伴侣一样-并且需要一定的运气。 学一点编码更快，不需要运气，因此成功率更高。

In fact you can stop reading this blog right here if you like. Read his. It’s better. The only reason I’m writing mine is to share direct, personal experiences that confirm what he said. It’s telling that to date his blog has only had ~8,500 views — of which a dozen are mine. That is much less than the number of aspiring non-technical founders out there.

实际上，如果愿意，您可以在这里停止阅读此博客。 读他的。 好多了 我写我的文章的唯一原因是分享直接的个人经验，这些经验证实了他的话。 据说到目前为止，他的博客仅获得了约8,500次浏览-其中有12次是我的。 这远远少于有抱负的非技术创始人的数量。

约会类比 (A dating analogy)

In high school, I remember being told that if you’re desperate for the affections of someone, you will act in ways that compromise yourself — your standards, your values and your best interests. You will settle for people, behaviours and situations that aren’t right for you.

在高中时，我记得有人告诉过您，如果您渴望某人的爱慕，那么您的举止会损害您自己的水平，包括标准，价值观和最大利益。 您将适应不适合您的人，行为和情况。

It’s exactly the same with looking for co-founders. As time went on and my fear and desperation increased, I found myself compromising — reducing my standards. Negotiating against myself. Making excuses for others. Settling.

寻找共同创始人完全一样。 随着时间的流逝，我的恐惧和绝望加剧，我发现自己在妥协–降低了自己的标准。 反对我自己。 为别人找借口。 解决。

Over time I made bad decisions and bad compromises. Fortunately, none of those bad decisions resulted in actual co-founding relationships.

随着时间的流逝，我做出了错误的决定和妥协。 幸运的是，所有这些错误的决定都没有导致实际的联合创始人关系。

My point is that I was prepared to make bad compromises, just to make progress. That is a bad start to something that you may have to spend the next 10–20 years of your life on.

我的观点是，我准备做出坏的妥协，只是为了取得进步。 这是一个糟糕的开始，您可能必须在生命的下一个10到20年中度过。

技术方面的事情不会在发布时就结束 (The technical stuff doesn’t end at launch)

It’s tempting to be tactical and say I just need to get to launch. That is not a sustainable plan. There is a difference between planning to “make it up when I get to that bridge” and having to do that because life left you no choice.

战术性很强，说我只需要发布就可以了。 那不是一个可持续的计划。 计划 “当我到达那座桥时弥补”与必须这样做之间是有区别的，因为生活让您别无选择。

I learned the hard way that my need for technical help grew after launch. I thought the hard yards were getting to launch. Boy, was I wrong. Things break. Bugs emerge. Features don’t work as expected. Users have strong views on things. Iteration is the way to achieve product-market fit. And it has to be rapid, well coordinated and systematic. Data helps, and lot of valuable data comes post-launch!

我深知这一点，我需要技术帮助上市后成长起来。 我以为硬地要发动了。 男孩，我错了。 事情破裂了。 出现错误。 功能无法正常工作。 用户对事物有强烈的看法。 迭代是实现产品与市场的契合的方法。 它必须Swift，协调良好且系统化。 数据有帮助，许多有价值的数据会在发布后发布！

That is why paying for developers isn’t sustainable unless you got lots of funding. And you’re not likely to get lots of funding before you even have a product. It’s possible, but not for most founders.

这就是为什么除非您有很多资金，否则为开发者付款是不可持续的。 而且，即使您没有产品，也不太可能获得大量资金。 这是可能的，但对于大多数创始人而言并非如此。

So what are you going to do when 4 weeks after launch things are breaking, users are reporting unexpected bugs, and the server crashed, or the app store has changed some policy? You spend more money. And beg the developers to hurry up. Meanwhile you’re doing your darnedest to find users, pitch, sell, etc.

那么，在启动后4周内发生故障，用户报告意外错误，服务器崩溃或应用商店已更改某些政策时，您该怎么办？ 你花更多的钱。 并恳请开发商赶紧。 同时，您正在尽最大努力寻找用户，推销，出售等。

You’re spending your time on things, for sure, and they’re important. But given a choice between fixing a bug / adding a features your users are clamoring for, and pitching your business plan to a potential seed funder, the best use of your time is product, not the pitch. And you cannot do it because you don’t know how. So you exert yourself on things of second-order consequence because you cannot exert yourself on things of paramount importance.

您肯定会花时间在事情上，而且它们很重要。 但是，要在修复错误/添加用户所追求的功能以及将业务计划推销给潜在的种子出资者之间做出选择，您最好的时间是产品而不是推销。 而且您无法做到，因为您不知道如何做。 因此，您不能专心于次要后果， 因为您不能专心于最重要的事情 。

发展技术同理心 (Developing technical empathy)

As I mentioned on the podcast, I was (mortifyingly) one of those people who insisted that “it is a simple, quick prototype”. I totally, utterly, woefully, lacked any concept of what the development process is like.

正如我在播客中提到的那样，(坚决地)我是坚持“这是一个简单，快速的原型”的人之一。 我完全，十分痛苦地缺乏关于开发过程的概念。

Quincy, the founder of freeCodeCamp and the one who runs the podcast, summed it up very well:

freeCodeCamp的创始人和运行播客的Quincy总结得很好：

It gives you empathy for the developer experience, and helps you make meaningful time-estimates, not only in terms of what is possible, but also what is straightforward, and what is complex. [paraphrased]

它使您对开发人员的体验充满同情心，并帮助您做出有意义的时间估算，不仅在可能的方面，而且在简单的方面和复杂的方面。 [释义]

Imagine if someone who has no clue about your work comes to you and insists that something that takes a week should take 2 days — wouldn’t you want to knock them on the head, and just turn away in disgust?

想象一下，如果某个对您的工作一无所知的人来找您，坚持要花一周的时间就需要2天-您是否不想敲他们，只是厌恶地转身离​​开？

I’m seriously embarrassed by all the times I did this (insist that it’s a simple app, not knock someone on the head).

我这样做的所有时间让我感到非常尴尬(坚持这是一个简单的应用程序，而不是敲打某个人的头)。

Worse still, why would they take me seriously? Had I really showed them respect and commitment by at least trying to learn a little bit of their craft? From their point of view, I was hiding behind my skills and the reasonable excuse that coding is “not the best use of my time”.

更糟糕的是，为什么他们会认真对待我？ 我是否真的通过至少尝试学习一些技巧来表达对他们的尊重和承诺？ 从他们的角度来看，我躲藏了自己的技能和合理的借口，即编码“ 不是我时间的最佳利用 ”。

Here is another sinister side effect of not being knowledgeable enough on the technical stuff. I could never evaluate the relative skills of the people I spoke to. I had to go on faith, trust or recommendations. I had no way to assess their fitness for the very purpose I needed them to fulfill.

这是对技术知识不够了解的另一个不良后果。 我无法评估与我交谈的人的相对技能。 我必须坚持信念，信任或建议。 我无法评估他们是否适合我需要他们实现的目标。

Looking back, I could have saved myself a ton of money and months of effort, while building a skill that extends my runway almost indefinitely — had I learned to code earlier.

回顾过去，如果我能早日学会编写代码，那么在建立一项几乎无限期地扩展我的跑道的技能的同时，我本可以节省大量的金钱和精力。

As Sam Altman says:

正如萨姆·奥特曼(Sam Altman)所说 ：

“When people like this say “I’ll do whatever it takes to make this business successful” (which they almost always say), I say something like “Why not learn to hack?”

“当这样的人说“我会尽一切努力使这项业务成功”(他们几乎总是说)时，我会说“为什么不学会黑客？”

Why not indeed. Do whatever it takes. Especially if it helps your startup “not die”.

为什么不呢？ 尽一切努力。 特别是如果它可以帮助您的创业公司“不死” 。

工程不是万能的 (Engineering is not the be-all-end-all)

Not for one moment do I think coding is the answer to everything. If you are among those who have an interested and totally reliable technical co-founder, classmate, colleague, sibling etc, then yes it’s not the best use of your time — why? Because you’ve got a great resource in that other person. Then learning to code is duplicating skillsets.

我认为编码不是万能的答案。 如果您是那些有兴趣且完全可靠的技术联合创始人，同学，同事，兄弟姐妹等人士，那么是的，这不是您时间的最佳利用-为什么？ 因为您在另一个人中拥有丰富的资源。 然后学习编码就是复制技能。

But when you don’t have that skillset, learning a little of it is the best use of your time, if it saves you a lot of time in the long run. Here is the math I apply:

但是，如果您没有那种技能，那么从长远来看，如果能为您节省大量时间，则最好学习一点时间。 这是我应用的数学：

priority = probability of outcome in a given unit of time

优先级=给定时间单位内结果的概率

So:

所以：

Find a co-founder in 6 months and start build in 7th month : 50% probability

在6个月内找到一位联合创始人，并在7个月内开始构建：50％的概率

Learn enough code in 6 months and start build in 7th month : 90%

在6个月内学习足够的代码，并在7个月内开始构建：90％

This entire article would be totally obvious if it said that coders need to learn marketing and communication skills to pitch. Coders need to get out of the building and talk to their customers and not just code. This is now considered “obvious” advice.

如果说编码人员需要学习营销和沟通技巧以推销产品，那么整篇文章将是显而易见的。 编码人员需要走出大楼与客户交流，而不仅仅是编码。 现在，这被认为是“显而易见的”建议。

So why isn’t the reverse just as obvious?

那么，为什么逆转不那么明显呢？

给自己信誉 (Give yourself credibility)

Engineers are like the really good looking girl at the bar. They get “hit on” all the time. They get approached all the time. I don’t know directly, but I’m guessing that gets tired fast, and cynicism is just another “you’re going to love my startup idea” away.

工程师就像酒吧里的漂亮女孩。 他们总是“被击中”。 他们一直与他们接触。 我不直接知道，但我想这很快就会累了，玩世不恭只是另一种“你会爱上我的创业想法”。

You know what’s refreshing to someone you’re chatting up at a bar? Interest and awareness about them. The same goes for coders. If you’re aware enough of their world, and interested enough in the detail of their skills, they will respond and, at the very least, help.

您知道在酒吧聊天的人有什么新鲜感吗？ 对它们的兴趣和认识。 编码人员也是如此。 如果您对他们的世界了解得足够多，并对他们的技能的细节也足够感兴趣，他们将做出回应，至少会提供帮助。

This bit I do know from personal experience. Ever since I’ve learned to code I have many more engineers happy to give me advice, guide me, correct me, and even dive into my ideas with me. It’s not easier to find the right co-founder, but that has nothing to do with expertise, and more to do with their interests, priorities and life-circumstances.

我从个人经验中知道这一点。 自从我学会编码之后，我就有更多的工程师乐于为我提供建议，指导，纠正我，甚至与我一起探讨我的想法。 找到合适的联合创始人并不容易，但这与专业知识无关，而与他们的兴趣，优先事项和生活环境有关。

现在呢？ (And now what?)

And now, for the first time in my life, I’m in a position where I can experiment with my ideas. Earlier it cost me time and money. Now it costs me a little time, and even then less time than finding developers, negotiating scope, supervising work, reviewing work, testing work. And that time is an investment as I keep improving the skill even if the idea pans out as commercially unviable.

现在，我有生以来第一次能够尝试自己的想法。 早些时候花了我时间和金钱。 现在，它花了我一些时间，甚至比寻找开发人员，谈判范围，监督工作，审查工作，测试工作花费的时间更少。 这段时间是一笔投资，因为即使这个想法在商业上不可行，我也会不断提高技能。

I’m not a great coder. I don’t think I need to be (maybe in 5 years I will revise this view). But I know enough to build my own prototypes, and understand what is involved in building a viable product. And I know enough to take a call on which bits to outsource, how to describe what I want, not get taken for a ride, assess the output, and team up with other hackers to get results. I may never be a professional developer, and that’s fine. That is not what this is about.

我不是一个优秀的程序员。 我认为我不需要这样做(也许我会在5年后修改这种观点)。 但是我足够了解构建自己的原型，并了解构建可行产品所涉及的内容。 而且我足够了解要外包哪些位，如何描述我想要的东西，不坐车，评估输出以及与其他黑客合作以获得结果。 我可能永远不会成为专业开发人员，这很好。 那不是这个。

But I have become my own technical co-founder. There may come a day when the best use of my time really is the non-technical stuff. But that day will come once I’ve built something that’s growing. I believe I’ve increased my chances of finding that something simply because I can run many more cheap, low-stress, experiments that do not involve me spending money or begging others for help.

但是我已经成为我自己的技术联合创始人。 也许有一天，我最好地利用时间是非技术性的工作。 但是，一旦我构建了不断增长的东西，那一天就会到来。 我相信我发现这些东西的机会有所增加，这仅仅是因为我可以进行更多便宜，低压力的实验，而无需花钱或求助别人。

All this in less than 12 months. Think about it. Maybe it really is the best use of your time if you want to be a founder.

所有这些都在不到12个月的时间内完成。 想一想。 如果您想成为创始人，也许这确实是您最好的时间利用方式。

Postscript对于免费的CodeCamp学生 (Postscript For freeCodeCamp students)

I really, truly believe your most precious resources are your time, effort and money. Of these, the single most important resource is time, because the other two can be renewed and recovered. So if you’re going to spend time on something make sure it gets you closer to this goal.

我真的，真的相信您最宝贵的资源是您的时间，精力和金钱。 其中，最重要的资源是时间，因为其他两个资源可以更新和恢复。 因此，如果您要花时间在某些事情上，请确保它使您更接近此目标。

With that in mind, if you want to invest 3 hours with me to find your shortest path to learning to code (especially if you’re looking to start up), then head to my course site and use the form there sign up (not the popup!). If you add the words “FREE MY TIME” to the message, I will know you’re a freeCodeCamp reader, and I will send you a promo code, because just like you, freeCodeCamp gave me a solid start.

考虑到这一点，如果您想与我一起花费3个小时来找到学习编码的最短路径(特别是如果您想开始学习)，那么请前往我的课程站点并使用那里的表格进行注册(而不是弹出窗口！)。 如果您在消息中添加“ FREE MY TIME”(免费)，我会知道您是freeCodeCamp的读者，并且会向您发送促销代码，因为与您一样， freeCodeCamp也为我提供了一个良好的开端。

Check out the relaunched freeCodeCamp podcast, where Quincy and Abbey use their incredible experience as educators to pull together content that will help you on your journey. I was recently on episode 53 and some of the things in this post are covered in greater detail there. You can also access the podcast on iTunes, Stitcher, and Spotify or directly from this page.

请查看重新启动的freeCodeCamp播客 ，Quincy和Abbey在这里以他们令人难以置信的经验作为教育工作者，汇集了对您有帮助的内容。 我最近在第53集上 ，这篇文章中的某些内容在此有更详细的介绍。 您也可以在iTunes ， Stitcher和Spotify上访问播客，或直接从此页面访问 。

I can be contacted on Twitter: @ZubinPratap

可以通过Twitter与我联系：@ZubinPratap

翻译自: https://www.freecodecamp.org/news/non-technical-and-looking-for-a-technical-co-founder-2c212c01d6da/

联合创始人英文名片