今天跟我的一个朋友聊天，他还是像3年前一样，一直在说他那个开源项目。虽然项目基本无收益，可是他却保持100%的时间和精力的投入，坚持了3年。 他也是普通的上班族，除了上班工作，每天上下班和周末时间基本上全部投入到这个项目中，3年的时间已经累积了几十万行代码。我看着项目的一点点成长，真的是看着他离成功越来越近，我也始终相信他一定可以成功。 今天想聊的就是：他为啥可以坚持这么久？ 靠什么坚持下去 我前面写过一篇文章有讲到责任感和目标感，他呢就是一个目标感特别强的人。他相信自己一定可以成功，他相信这件事一定可以成功，就是他的这种相信的信念，让他有足够的力量一直坚持到现在。 他的这种信念，是一般人无法
最近在做团队半年度的绩效沟通，在和其中一位同学沟通的时候，我说到“除了工作时间，下班时间、周六日时间还是得学习学习技术，提升一下技术能力”，他回答说“下班时间，还是更喜欢放松一点，生活是生活，工作是工作”。 他呢，是一个很认真的同学，投入度高，交付质量也高，而且工作时间也不短。我一直以为他跟我一样——有点工作狂属性，对工作和个人成长愿意投入更多的时间和精力。但聊完之后，才发现他跟我对生活和工作的态度完全不同。 所以，今天要聊的就是“关于生活和工作如何平衡”。 关于我自己 我对生活和工作的规划分两个阶段。 现在这个阶段 我是农村出来了，除了家里的几亩田地，没有任何家底，一切开销都得依赖工资的收入
今天参加公司半年度复盘会，在会上听了财务、市场投放、供应链、门店等各部门的复盘，学到了从不同的维度看公司的业务，也学到了很多新的业务名词。 我听得很认真，但是在QA环节我却问不出来任何问题，我在想，是我的业务能力太弱吗？这就是技术人一直被吐槽不懂业务的表现吗？ 今天要聊的话题就是：我们说的技术人要懂业务，到底是在说什么？ 技术人应该如何懂业务 以会上供应链复盘内容为例，供应链业务负责人根据公司当前的商户组成结构和行业商户的心智，以及结合我们公司当前最紧急的货源需求，制定了一套商户运营策略。我听了之后，佩服他的知识之丰富、逻辑之严谨，对自己的能力也有了一点点怀疑，感觉自己做了这么久这个行业，为啥
前几天写了一篇“在这个时代，人人都应该是全栈工程师的文章，有几个朋友留言说“哪有时间学这么多技术啊”。 这个情况跟我看到的团队里的很多同学很像。我会根据每位同学的情况制定不同的学习目标，会让他们去学对应的技术。但是每当我问“学的怎么样了？”的时候，经常都会收到这样的回答“我不是在做需求吗？哪有时间学啊”、“也没有给我排期学啊，要不我插入两天排期学一下？”，每次听到这样的回答我都很无语。 今天想聊的就是“我们真的忙到没时间吗？” 我们真的忙到没有时间吗 我其实非常理解大家的工作确实很忙，尤其是研发工作本身还有很大的特殊性。 一是每次排期一排就是一两周，而且我们的工作一环套一环，如果自己延期了可能
最近几年，偶尔会有人跟我说“宝哥，你知道大家背后都在说你压榨大家吗？”“你知道有人在背后骂你吗？”，我每次都会这样回答“我又不是圣人，我感觉我做的已经很好了，其他的就随它吧”。 今天想聊的就是技术人转管理，怎么跨过最开始的那道坎，这个坎就是我上面说的这些担心，叫做评价焦虑。 什么是评价焦虑？ 担心权威合法性被挑战 刚升职的同学最担心的就是被质疑“为什么是你升职？”。你不是最资深的那个，也不是最会来事的那个，为什么是你来管我？刚升职的同学，在最开始的一段时间一定会受到这样的挑战，然后就会小心翼翼的沟通和安排工作，生怕被人说“摆架子”、“拿着鸡毛当令箭”。 担心关系破裂 刚升职的同学都会面临“怎么
今天忙了一整天，处理了很多问题，成就感爆棚。碰巧有一个测试用例评审，我想着去放松一下吧，没想到在会上我们吵起来了… 测试同学坚持分模块组织用例，这样有利于复用；而产品和开发更关心业务流程，觉得测试用例需要把流程描述清楚，而不是东一块西一块的讲。大家吵的不可开交，谁都说服不了谁，连我都气的数不出来话了😂。 其实问题的本质很简单，就是大家视角不一样，对用例的预期不一致而已。 矛盾分析 产品/开发的流程视角 产品/开发同学希望测试用例要像需求评审一样，能够把整个业务流程讲清楚，并把产品各个细节逻辑补充清楚。这样产品可以确保自己的需求自洽没有遗漏，技术可以对照者看自己开发的内容是否有缺失。 测试的功能
最近要招聘一个后端组长，我们后端是从PHP（20%）转的Golang（80%），又因为融合的原因，后续需要再转JAVA。所以今天跟BP聊对新人要求的时候，我随口说了句“最少要会2到3门语言”，BP跟我说“那要求也太高了吧！”。 可在我看来“2到3门语言”，已经是基础的要求了，我最想找的是一个即会后端也会前端的人。因为在我看来，如果你不是在研究语言底层原理或数据库等底层系统而只是在做业务开发的话，那么人人都应该是全栈工程师。 为什么人人都应该是全栈 时代潮流的要求 用“天下大势，合久必分，分久必合”这句话来形容技术的发展最合适不过了。刚开始的时候，一切都是新鲜的、简单的，不分什么前后端，所有工作
前段时间跟一位团队成员绩效沟通的时候，他跟我说“宝哥，跟数据部门沟通好难啊，他们总是推来推去的，不解决问题”。 其实不只是他，日常工作中这种类似的反馈和摩擦很多，每次我都要耐心地开导一下大家。其实事实并不完全是其他部门不配合，一定程度上是部落意识在做怪。 什么是部落意识 部落意识，是指一个人在集体环境中，对自己所属的“组织单位”（如部门、团队、公司）产生高度认同感，并以此为界线去划分“我们”和“他们”，进而影响沟通、协作和决策的方式。 部落意识属于心理学，是人类基因里带来的。 以研发团队为例，同一个研发团队内的成员一定觉得其他研发团队的人协作困难；当涉及研发和产品之间问题的时候，研发团队会
我们公司去年被收购了，到现在刚好一年。虽然我们公司跟集团比规模很小，差不多是集团的1/20吧，但是我们公司也是有自己一套完整的业务系统的。在收购初期做了一些融合的业务需求，两边产研经过很长时间探讨做了一套方案，从结果上看还是不错的。 经过近一年的融合，业务和技术都比较稳定了。因为考虑到这块业务整体的迭代效率，公司决定把集团里融合的这部分业务也统一交给我来负责。 我这才有机会看到融合方案的全貌。 真正理解“组织架构决定技术架构” 很多年前第一次看到“组织架构决定技术架构”这句话的时候，很不能理解。我当时的认识是：技术架构就应该是清晰、抽象、结构合理的，绝不能因为组织架构原因就做出不合理的设计。
上次逼自己日更公众号的时候，连续写了十几天。开始是激情，后面就变成了应付。再次开始写公众号也有一段时间了，每次不知道写啥的时候，还是会问自己：我应该写什么，写别人愿意读的？还是我想写的？ 这次内心的回答很坚定 —— 写我想写的 Why 写别人愿意读的，真的挺难的。 写别人愿意读的公众号，就像做产品一样，你找到了一个特定人群的特定痛点，去分析、拆解、满足用户的需求。但是这种公众号，写刚开始的一二十篇还比较轻松，因为方向是明确的，可选主题也比较多。如果连续写几个月、甚至几年，那每天怎么选题呢？想想都头疼。 写我想写的，就比较轻松了。 这个公众号的初衷很简单：记录自己日常的想法、心理历程，以及记录