在成为独立开发者若干年之后，我越来越感受到技术与产品在一定程度上是互斥的，哪怕它们不得不相互依存。
做技术还是做产品
很多年前我在知乎上看过这样一个问题：如何成为年薪百万的技术大牛？最让我印象深刻的回答说的是年薪百万、技术和大牛三者之间并无瓜葛：想要年薪百万并不需要成为大牛，成为技术大牛也并不意味着就年薪百万。这和我这么多年的工作体验是一致的，说到底技术和它能够带来的收益不是线性关系，好的技术不代表能打造出好的产品，好的产品甚至都不需要一门技术来支撑它。
《Make: Bootstrappers Handbook》是我最喜欢的一本关于独立开发者如何建立创立初创公司的小册子，它是product hunt网站（producthunt.com是一个每天聚合、分享和讨论最新产品、应用、网站和科技创意的平台）2018年产品类书籍的第一名。本书作者最为成功的产品之一是Nomad List，它是一个为远程工作者以及游客寻找一个城市的游玩之处以及进行交友的平台。作者起初对编程一窍不通，Nomad List的第一个版本不过是一个作者个人整理的并对完分享的excel表格而已。
书中当然也涉及到了少许的的技术讲解，但也不过仅限于使用拖拽的方式利用Google Form或者WordPress来构建一个网站，与专业编程相距甚远。本书发布于2018年，在七年之后的今天相信我们都已经看到在AI让技术变的更加不重要。在上一篇《反对vibe coding不过是程序员的自我感动而已》文章中我同样提到过提到过另一位名为leo的编程门外汉，通过vibe coding已经赚取了属于自己的第一桶金。甚至在一些独立开发者的论坛中（比如下面提到的Indie Hackers），还出现了为非编码人士准备的独立vibe coding板块。
我想表达的观点是，如果你想做一个好的产品，那技术不重要，任何一个你想到的创意，在product hunt上都被实现过无数次了。在product hunt上以“todo”为关键词进行搜索，你会得到超过一百页的搜索结果，是什么让这1000个todo应用中的某一个脱颖而出？是因为它代码写的足够整洁吗？因为它测试覆盖率达到了100%吗？
甚至做技术与做产品两者在行事风格上也是相悖的。上面我提到的《Make》也好，鼎鼎大名的《精益创业》也罢，他们都不约而同的提及到同一件事：产品应该尽早的发布，迭代应该快速进行。而程序员则希望自己是匠人，希望能够有充分的时间来打磨自己的代码。程序员需要时间，而时间是一个产品最大的敌人。
那么如何理解各种最佳实践的存在？例如不同类型的测试或者CI/CD都需要占用大量运行时间。在我看来它们是一类投资，在已经证明你产品的价值所在的情况下，用于确保你的长远利益不会受损。而对于一个生死未卜且大概率下个月就可能夭折的项目来说，还是先设法活下去比较重要。
你以为我们聊的是只有独立开发者才会面临的选择，但其实我们聊的是每个开发者在工作场合都会遇到的困境。不同之处在于独立开发者需要独自一人来掌控这种平衡，而在大厂工作的程序员需要通过对外斗智斗勇来争取利益。在程序员口中类似的问题总是被包装成“不懂技术”，“外行领导内行”之类的话题被抛出来，看上去这是技术追求的问题，其实是屁股（决定脑袋）的问题：程序员为代码负责，而你的lead在为产品交付负责。这里我要着重说明：我不认为让代码更好有什么错，也不认为让快速迭代产品有什么问题，但世事就是这样，矛盾的产生不是由简单对或者错决定的，而是利益冲突带来。
在早些年还在从事前端开发的时候我一直有3个心愿：1)引入GraphQL；2)把项目中的状态管理类库从Redux换成Mbox；3)把项目拆分为微前端。这三个愿望我从来没有实现过，因为我看到的是一个面向未来的理想的技术栈。而团队的Tech Lead或者项目经理关心的是它需要多少人天来完成以及可以带来多少收益，更重要的是没有这些技术改进太阳每天照常升起。这件事的另一个缩影是，我依然记得在HTML5推出N多年后国内各大视频网站依然坚定不移的使用flash作为pc站点的视频播放技术。你们知道它们何时才开始决定将视频播放由flash更新为HTML5的吗？当浏览器宣布不再支持flash的那一天。
但产品思维对研发人员依然有可借鉴之处。我可以兴奋的为一个想法投入十几个晚上的空闲时间把它完成，但这是不可持续的，一旦开始思考如何长线的维护它，你也一定会落入计算性价比的“怪圈”。想象你的某个开源项目突然大受欢迎，哪怕每天你只会收到一个feature request，一个pull request以及一个bug，它们也会占据你每天不少时间。我们终将需要在投入分配上做出取舍，甚至终止某些项目的维护。在我们看似在讨论“死”的问题，殊不知这也与“生”息息相关：在项目启动之初给自己的设定一些退出机制或者迭代计划，会让自己更游刃有余。
习惯失败
如果你已经接受了技术和产品是独立的两个领域，那你必然要接受另一个不受欢迎的真相是，相比于编码带给你的正反馈，做产品的体感在绝大部分时候是负面的。编码是非常有成就感的事，你迈出的每一步都是对的方向，不管是修复了一个bug还是完成了一个功能，哪怕一段无法运转的代码都意味着为你排除的一个错误可能性。然而如果你做的是一个产品，可能迈出的第一步就是错的。更有意思的是，代码的出错完全有迹可循；至于产品成功方法论，十个人的嘴里可能会说出来十个相左的产品方法论。
失败是producthunt网站上独立开发者的常态，比如我通过随机一个todo应用找到的Younghourta，他在加入producthunt的5年时间里发布了9款应用，它们中的所有都已经无法访问。
从结果上来说产品和代码具有相似之处，成功或者失败是非常直观的：编译通过或者编译失败，广受欢迎又或者无人问津。当一个产品无法找到它自己的价值，关掉它理所应当。你可能会问我难道不会为过去此付出的时间和精力感到可惜吗？但我认为在看不到收益的前提下，投入无限的精力去维护它更是一种浪费。
我最近刚好读完的小马宋老师的《卖货真相》，我想用书中的两个观点来总结以上部分的内容，：1)今天99%的创业者做的产品都没有特别的壁垒；2)卖不出去，设计和生产就变得毫无意义。从这个角度上说，“生产制造”是最不重要的一个环节。
其实单纯做技术或者做产品都没有问题，问题在于你给予了它一个成功的期待。我把它称之为除时间成本和金钱成本之外的感情成本。无论是面向普通用户还是面向技术人员的个人项目，人人都希望它们受到关注，希望它们受到欢迎——程序员与其他人类并无不同，我在《开源社区的暗面》中提到过一篇名为 《社会地位即服务》（Status as a Service）的文章，它揭示这么一个真相：对于地位的渴望是源自于人类内心的本能
people are status-seeking monkeys, always trying to seek more of it in the most efficient way possible
说白了编写开源项目的程序员和抖音上的舞者并没有区别，我们都希望脱颖而出。同时这些期待又带来了另外一些连锁反应：也许我只有把项目做的足够好才能获得足够的关注，也许我应该把安全做到万无一失才行——无论如何我总应该能做点什么吧。这里的谬误之处在于程序员将他们习以为常的优绩主义套用在了万事万物身上，它把产品的好坏与代码的好坏强行绑定在了一起，然而两者并不互为因果。这又回到了我一开始所说的，产品与技术相互独立。
在我看来还有一部分“依依不舍”源于生长在互联网神话下的程序员们接受了太多的成功教育，却还没有来得及接受死亡教育。我依然还记得我读完《重构》(Rework)之后的心潮澎湃，他们反主流、反大公司以及说干就干极客精神太具有吸引力了——无数人都在鼓励你向前，但没有会告诉你当你的付出得不到任何的反馈甚至得到的负面反馈时，接下来应该怎么办。至少在这个行业里失败者通常会对羞耻于复盘或者坦白自己的失败，而人们也倾向于自己是那个不会重蹈覆辙的幸运儿。
这类成功学的意志最好的体现在我看来便是Indie Hackers网站，一个所谓的独立开发者论坛，他们的网站首页永远只有一类内容：“我是如何在XXX时间内挣到XXX”：
我有幸很多年前收藏过其中的一篇帖子《I’m DONE with all these “Success Stories” Online》，文章里面的一段话说出了关于这里的真相：
You don’t hear about people like me who have started various businesses, from reselling and Instagram theme pages to packing groceries for people (yes, I did this), creating a clothing brand, a dating app, selling water bottles, podcasting, newsletters, eBay flipping, curb painting, and offering SAT prep services.
These failed ventures don’t catch headlines, and I assure you, I have so many ideas and cool stories to share, but they’ll never see the light of day.
很有意思的是，尽管文章的作者Enos Codes的创业经历并不算成功，却也没有丝毫停止折腾的意思，你可以说这源于人类本身的乐观，但这也恰恰是也是这些“个体户”们独特的可爱之处，折腾只有一次和无数次。
我和年轻程序员聊天的时候发现很有意思的共通一点，他们永远在寻找一个“世外桃源”：理想中的下一个公司必须有着最卓越的技术追求，用着最时髦的技术栈。每次聊到这里我都不禁在想，如果五年甚至十年之后依然难以寻觅到属于自己的“世外桃源”的，他们会发生什么样的变化？失望？妥协？愤怒？这些都不让人意外，意外的是依然乐观和充满希望。
去年为了帮助自己发现更多感兴趣的播客节目，我开发了一个名为“播客广场”的工具，它能够帮助纵向地去收集某个话题下的最新播客节目。目前它已正式关闭，如果想要了解开发这个产品的初衷和形态，可以前往少数派网站。
最近我想用几篇文章的时间把这个工具的实现细节做一系列拆解。因为AI的普及代码不会是这一系列文章的重点，我会把篇幅留给架构设计和解决问题的思路，它们比代码更值得分享的。而本篇则是这一系列文章的第一篇，在下一篇里你会看到本文中所谈到的思维模式是如何主导我的架构设计和技术选型的。
