1. 为什么技术人必须认真对待影响力这件事
做了十几年技术,带过不少团队,也看过很多技术能力很强但始终困在基层的工程师,我越来越确认一个有点扎心的事实:在职场里,你的价值不仅取决于你做了什么,还取决于多少人知道你做了什么。
技术人普遍有个思维惯性,觉得"酒香不怕巷子深",认为只要代码写得好、系统架构设计得漂亮、线上问题处理得干净利落,升职加薪是水到渠成的事。但我见过太多反例:一个工程师默默重构了核心模块,性能提升了三倍,结果代码评审过了、合并上线了、然后……就没有然后了。另一个工程师做了个相对简单的功能,但在团队周会上把业务价值讲得清清楚楚,又在内部分享会上做了一次完整的复盘,结果晋升答辩时拿出来的材料非常丰满。这里说的"丰满"不是他做了多少事,而是他的工作被多少人看见、被多少人认可。
这背后的逻辑其实很简单:**影响力和你的技术能力是两条独立增长的曲线,它们互相放大,但不会自动互相转化。**技术能力解决的是"你能不能搞定问题",影响力解决的是"别人认不认为你能搞定问题"。在跨部门协作、资源争取、晋升评审、职业机会这些关键场景里,后者往往起到决定性作用。
这篇文章我想系统讲讲技术人到底该怎么打造职场个人影响力,包含具体的路径、可落地的技巧,以及我自己踩过的一些坑。我不打算讲那种虚的"建立个人品牌""成为行业KOL"之类的空话,而是聚焦在一个技术人真实可行的操作层面:从写技术博客开始,到参与开源、做内部分享、经营职场社交关系,再到建立自己的方法论体系。全程用我自己的经历和观察来举例,希望能给同样在技术道路上想往上走的人一些参考。
这篇文章适合谁?如果你是三年以上经验的工程师、技术 Leader,或者正在为晋升做准备、想在团队里获得更多话语权和资源的开发者,这篇内容应该能给你一些具体的启发。如果你刚入行一两年,同样建议提前看,影响力这件事越早布局越好,等需要用到的时候临时抱佛脚,效果会差很多。
2. 影响力这件事,先要搞清楚它在职场里到底起什么作用
2.1 影响力不是虚名,而是职场资源的杠杆
很多技术人对"影响力"这个词有抵触情绪,觉得那是搞政治、混脸熟的人才会琢磨的事。但从本质上说,影响力就是你的专业信用在你社交网络里的扩散程度,它直接决定了几件非常现实的事情:
**第一,晋升。**绝大多数公司的晋升评审,都要考察候选人在团队内外的技术影响力。不是说你有影响力一定能晋升,但你没有,大概率会被卡住。评审委员会看到的材料是有限的,如果你平时的工作产出没有被记录下来、没有被团队其他人认知到,那你在答辩时讲的东西很难让评委信服。反过来,如果你平时做内部分享、写技术文档、在代码评审里给出高质量建议,这些都会成为评委嘴里"这个人我听过""这个人我有印象"的佐证。
**第二,资源。**在跨团队协作的项目里,影响力能帮你更快获得兄弟团队的配合。做过跨部门项目的都懂,很多冲突的根源不是技术问题,而是"对方团队不信任你的判断"。如果你平时在技术社区或公司内部有一些口碑,别人更倾向于相信你的方案是经过深思熟虑的,这能极大降低沟通成本。
**第三,选择权。**影响力建立起来之后,机会是主动来找你的。不管是猎头挖人,还是公司内部新项目负责人点名要你参与,都建立在一个前提上:你的价值被足够多的人看到。我见过一些能力很不错的工程师,就因为太"低调",在组织调整时被放到了边缘位置,这其实是双输的局面。
2.2 技术人的影响力构成:不是单一维度,而是一个组合
很多人以为影响力就是"写博客+涨粉丝",这其实是把它理解窄了。我自己的拆解是,技术人的职场影响力由四个维度构成:
- 专业深度:你在某个技术方向上的积累是否让人信服。这是地基,没有真正的技术能力,影响力就是空中楼阁。
- 可见度:你的工作成果、技术观点、解决问题的能力是否被团队/公司/社区看见。
- 连接度:你认识谁,谁认识你,你和关键的人和团队是否建立了有效的协作关系。
- 信誉度:别人提到你时,第一反应是"这个人靠谱"还是"这个人水平一般"。
这四个维度是互相支撑的,但有明显的先后关系。专业深度是入场券,可见度是放大器,连接度是传输通道,信誉度是最终沉淀下来的资产。如果你只做第一个维度,那你是一个优秀的执行者;做到第二、三个维度,你是团队里的技术骨干和意见领袖;第四个维度也建立起来之后,你的影响力就开始具有跨团队甚至跨公司的溢出效应了。
2.3 树立一个正确的目标:做"高可信度的技术连接点"
在开始具体的实操之前,我建议你先在心里给自己定一个方向。不是所有技术人都要成为"大V",也不是所有人都适合走"网红工程师"路线。我个人的建议是,技术人打造影响力的合理定位是:成为你所处技术圈层里一个"高可信度的连接点"——也就是当你所在的组织或社区里有人遇到相关问题,他们第一时间会想到来请教你或寻求你的建议。
这个定位的好处在于:
- 它不强求你有很大的粉丝量,只需要在关键的人群里有口碑。
- 它和你的技术能力天然契合,不需要刻意表演。
- 它产生的复利效应非常明显,因为每一次成功的解答或建议都在强化你的可信度。
想清楚这一点,你再去看接下来要讲的技巧和路径,就有一个统一的坐标系来安排优先级了。
3. 实操路径一:技术写作,这是性价比最高的启动方式
3.1 为什么技术人首先应该从写作开始
如果要我排序,技术人打造影响力的第一步,我一定会选技术写作。原因非常简单:**写作是唯一一种一次投入、无限次展示的曝光方式,而且它不依赖实时互动。**你做一个内部分享,影响的可能只是当时在会议室里的那二三十人;但你写了一篇高质量的技术博客,挂了两年之后依然会有人因为搜索到它而认识你。
我自己从大概工作第三年开始在有道云笔记(当时还叫有道笔记)上写技术备忘,后来转到语雀,再后来在公众号和掘金上同步维护一个技术专栏。前前后后写了有差不多四五年,累计输出的文章不算多,大概六七十篇,但就是这么一点持续的输出,给我带来的回报远超我的预期。
我在上一家公司的晋升答辩时,评委里有一个人看过我发在公司内网上的两篇技术方案复盘,答辩的时候他问我问题的方式就不太一样——不是那种例行公事的考核语气,而是带着一种"我大概知道你在做什么所以来跟你深入聊一聊"的态度。那种感觉就像考试前老师已经对你有了不错的先验证一样,整个答辩的节奏会舒服很多。
3.2 技术写作的三个核心技巧:选题、深挖、表达
写作这件事,很多人一提就头疼,总觉得"没什么好写的"。但你真要动笔,会发现最大的问题不是没内容,而是选题没想清楚。我总结了三个核心技巧:
**选题是关键,先解决"写什么"。**我的经验是,在选题上有三个切入点最值得优先考虑:
- 解决过的一个复杂问题:你最近调试了一个很难的Bug、设计了一个有张力的系统、优化了一个棘手的性能瓶颈,这些都是好素材。因为它们是"有故事"的,有前因后果,有坑有曲折,写出来天然就吸引人。
- 踩过的一个坑:技术人最不缺的就是踩坑经历。为什么这个配置这么写会报错?为什么这个方案上线后出了性能问题?把这些教训写下来,比写十篇教程更能建立信任感,因为你对问题的理解深度是读者能直接感受到的。
- 对某个技术方案的多视角比较:比如"我用A方案和B方案都实现了一遍,对比下来发现……"。这种文章很实用,因为很多读者正面临同样的选择困惑。
**深挖,做领域里的"信息差"狙击手。**现在网上的技术资料非常多,随便写一篇"我学会了某某框架"没人看。但你如果能写出别人搜不到、查不到的细节,就在这个话题里建立了知识上的"信息差"。比如别人写的都是"怎么做",你写的是"什么情况下不能这么做";别人写的是"版本A怎么用",你写的是"版本A和版本B在这个场景下的行为差异"。这种深度沉淀才是你的壁垒。
表达要降维,把"我很专业"变成"你也能懂"。这里有一个很常见的误区:写博客拼命用生僻术语、画复杂的架构图、贴一堆代码,以为这样显得很厉害。实际上,好的技术文章是把复杂的道理讲简单。我自己的标准是:如果一个非该领域的技术同事能大致看懂我文章的核心思路,那说明我写得足够清楚。每写完一篇文章,我会自己先读一遍,凡是读到"这里我可能看不懂"的地方,要么补上下文,要么加示例。
3.3 写作渠道和运营策略:从内到外,一步一步来
关于发布渠道,我的建议是先内部后外部:
- 第一步,团队内网或知识库。先在公司内部写起来。这个门槛最低、反馈最快,同事的反馈能帮你快速修正表达方式和内容深度。
- 第二步,公司技术博客或内刊。大多数中大型互联网公司都有自己的技术博客,投稿被录用本身就是一种背书,而且面向的读者群体会更广。
- 第三步,外部技术社区。等你在内部积累了一定信心和量,再在掘金、CSDN、思否、InfoQ等渠道开设专栏,同步你筛选过的文章。这样做的原因是:内部写作有"工作场景"的保护,你想怎么写都有背景来支撑,不容易跑偏;直接对外写,一旦没有反馈,很容易坚持不下去。
还有一个小技巧我特别想分享:**文章发布之后的一周内,要持续关注评论和私信反馈。**这不仅是维护关系,更是迭代自己写作方向的免费调研机会。读者提问集中的点,往往就是你下一篇该写的内容。
3.4 我的写作频率和坚持心得
关于写作频率,我见过很多人给自己立"每周一篇"的Flag,然后三周之后断更。我要说实话,这不现实,因为技术写作质量比数量更重要。我给自己的要求是每两周至少一篇、每月最多四篇,但每篇都要达到"即使过了一年回头看也不觉得过时"的质量标准。
再分享一个坚持的秘诀:**不要追求每篇都是经典。**你要允许自己写一些"看似普通但不写就记不住"的内容。技术写作就像健身,偶尔一两次划水没关系,关键是持续在练。哪怕你觉得自己写的内容平平无奇,只要保持更新节奏,半年后再看,你一定会发现自己对问题的梳理能力和表达水平都有了肉眼可见的进步。
4. 实操路径二:开源与社区,把影响力从公司内延伸到行业
4.1 参与开源的本质:你是为未来的自己在积累信用
技术写作帮助你建立"这个人会写、有深度"的印象,而参与开源则更直接地展示了"这个人能动手、能交付"。尤其是在技术圈,开源贡献记录是一个非常客观的能力证明,因为它不看你说的天花乱坠,而是看你提交的代码、文档、Issue 和 PR 质量。
很多工程师对开源有畏难心理,觉得自己技术还不够格,或者觉得那些知名的开源项目根本不会接纳自己的代码。我的建议是:先把预期放低,从"参与"开始。
我自己的经验是,第一次给一个中大型开源项目提PR,只是修了一个文档里的拼写错误和残缺的注释。很简单对吧?但那次经历给我最大的收获不是那个PR被合并了,而是我学会了这个项目的贡献流程——怎么下载源码、怎么跑测试、怎么提PR、怎么和维护者沟通。这个流程跑通之后,后面再提代码修改就有底气多了。
4.2 从零参与开源的阶梯式路线图
我整理一条自己去年的实操路径,供你参考:
- 先用起来,成为活跃用户。找两三个你日常开发中高频使用的开源项目,认真读文档、熟练使用,在社区里积极参与讨论,回答别人的问题。这是门槛最低的一步,但能帮你积累对项目的熟悉度。
- 从"小修小补"开始。低门槛的Issue:文档错误、类型定义不完整、测试覆盖缺失、Bug复现步骤不清晰。这些看似工作量不大,但积累多了,你就自然熟悉了代码结构和贡献流程。
- 主动认领或创建Issue。在项目维护者"欢迎新人"的Issue列表里找机会,或者你发现了新Bug,自己写清楚复现步骤和定位,再提一个修复PR。带问题来提交PR,被合并的概率远大于"我觉得这里应该重写一下"。
- 坚持维护1-2个自己的小项目。不一定要做那种试图颠覆行业的大项目,做一个解决某个具体痛点的命令行工具或SDK封装就很好。把它维护好,写好文档,定期更新,这就是你个人技术品牌的"根据地"。
这条路径的耗时因人而异,但核心逻辑是确定的:你用实实在在的贡献换取社区里别人对你的认知和信任,这个过程没办法跳步。
4.3 技术社区经营:线下 Meetup 和线上社交的正确姿势
线下方面,我的建议是不要做"签到狂魔",要做"内容贡献者"。刚参加技术社区活动的时候,你很可能只是坐在台下听。但随着你积累的内容越来越多,要主动找到主办方,申请做一次20分钟的闪电分享。哪怕你的主题很小、很具体,但一次成功的现场分享给你建立的影响力,比参加十次活动都大。
线上方面,我特别推荐一个策略:**高质量回复比发很多贴更重要。**在掘金、V2EX、Stack Overflow 这类平台上,与其每周水一些无关痛痒的评论,不如每周认真回答一个你有把握且有深度的问题。一个高质量的回复,能吸引到正想找这个答案的人,他会因此关注你,甚至去看你的其他文章。
我至今记得一个很小的例子,有一次我在某个技术社群里认真回答了关于"分布式事务最终一致性方案选型"的问题,逻辑推演、场景对比、代码示例都写了,差不多花了一个半小时。这个回答后来被群主置顶了两个月,前后有十来个网友私聊我咨询细节,其中两个还因此加了微信。这之后有一年多,我在这方面的"技术人设"就非常稳,因为一个深入的答案能顶几十次泛泛的曝光。
5. 实操路径三:在职场内部把影响力落地
5.1 内部分享:把"我做了"变成"大家学到"
如果说对外的写作和开源是长线投资,那么对内的分享就是在职场上最快速的"变现"手段。我在各家公司都坚持做内部分享,做过的主题涵盖架构设计、故障复盘、性能优化方法论、代码评审规范、编程语言特性踩坑等。
做内部分享有一个核心认知:**它不是汇报工作,而是帮助团队成长。**所以内容设计上,重心要放在"大家听完能带走什么"上,而不是"我做了什么项目、我这个季度有多辛苦"上。
分享的频率不用太高,一个季度有一次高质量分享就足够让团队感知到你的存在感和专业度了。我见过有人每个月都抢着做分享,但内容非常凑数,久而久之反而降低了大家对他的预期。宁可少做,做一次就做精品,让听过的人有"值了"的感觉。
5.2 代码评审与文档文化:日常工作中润物细无声的影响力
除了正式的分享,日常的协作细节也是建立影响力的重要渠道:
- **代码评审(Code Review)**是技术人日常影响力最重要的触点。不要只回一个"LGTM"就算完,认真看逻辑、想边界条件、提有建设性的问题。高质量评审意见的作者,会在团队里自然形成"他看问题很全面"的标签。但要注意分寸,只对事不对人,别把评审意见写成指责。
- 技术方案文档是另一个重要的影响力载体。不管公司有没有强制要求,做设计之前花半天时间写一份2000字左右的设计文档,把背景、方案对比、选型理由和风险点写清楚。它既是保护你自己的"稻草人"(评审阶段就暴露问题,避免上线后出大事故),也是展现你思维完整性的窗口。
- **沉淀故障复盘(Postmortem)**也非常重要。线上出了故障不可怕,可怕的是复盘会变成甩锅会。主动组织复盘、把根因分析得透彻、改进措施制定得可执行的团队,技术口碑通常会很强,因为大家在你身上看到了"工程素养"。
5.3 跨团队影响力:从"被依赖"到"被信赖"
在职场里,如果你的影响力只停留在自己的组内,那还远远不够。等你需要带跨团队项目、晋升答辩、争取预算的时候,你会发现跨团队的口碑比什么都重要。
培养跨团队影响力的方法不多,但都很有效:
- 主动输出公共组件或工具。如果你负责的模块具有通用性,主动标准化并文档化,方便其他团队接入。一个让多个团队依赖的稳定公共模块,是你和很多负责人建立良好关系的纽带。
- 在跨团队会议上主动做技术补充。你可能不在C位,但如果你能在别人讨论设计时,针对一个细节给出精准的技术判断,对方团队会默默给你记上一笔。
- 别对跨团队的求助说"这不归我管"。哪怕确实不属于你的职责范围,你也可以给出大概的方向或推荐合适的人,这个极低成本的动作能显著提升别人对你的好感。
5.4 向上管理中的影响力展示:让关键的人看到你
技术人经常有一个误解,觉得"老板应该自己看到我的工作"。现实是,在信息过载的环境里,老板的关注度是非常稀缺的资源。你不主动展示,被看见的概率就微乎其微。
但"向上管理"并不是拍马屁,在我看来,它其实就是定期同步关键信息。我坚持比较久的习惯是,在做重要项目或有阶段性进展时,用"一页纸"(简单概括:目标、进展、风险、需要决策的点)同步给我的Leader和相关方。这个动作的核心不是邀功,而是让关键决策者始终掌握你的工作动态,在讨论到相关方向时能第一时间想到你。
6. 个人品牌与长期资产:把自己当产品来运营
6.1 打造你的"个人知识资产地图"
随着写作、分享、做项目的数量积累,你会发现,只有把它们系统化地沉淀下来,才能形成真正的长期资产。否则今天写了Redis的调优经验、明天分享了团队管理心得、后天写了一个Go的代码生成工具,它们各自主题分散、互不相关,别人翻你主页时抓不住你的主线。
我建议每个人根据自己的技术方向,花一两个小时画一张"个人知识资产地图",列出你想建立权威标签的三个领域,然后审视你已有的内容资产,把散落的素材分类整理,规划出接下来要补全哪一块。比如我的地图上有"分布式系统实践""Go工程化""技术团队管理笔记"三个核心板块,之后我的输出就尽量围绕这三块来做。
这样做的价值在于:当别人想到"这个人擅长什么"时,能快速形成一个清晰的认知。而清晰的认知,恰恰是影响力传播的前提。
6.2 非技术能力对影响力的加成:沟通、演讲与结构化思维
前面讲的路径,绝大部分场景都涉及一个核心能力——表达。包括书面表达和口头表达。
很多技术人表达不清晰,不是因为他们不懂那个技术,而是因为思维是"点状"的:想到哪说到哪,没有层次,没有抽象层级。要改善这个问题,可以刻意练习结构化表达:先说结论,再说理由,再说证据,最后说建议。这个框架在技术讨论、方案评审、故障复盘、晋升答辩里都适用。
另一个很实操的提升方法是录制自己的分享视频回看。虽然画面里的自己一定会让你尴尬,但真的会瞬间发现自己口头禅、语速、语气词多不多、节奏好不好。我头两回看自己的演讲录像,简直想捂眼睛,但第三回开始就能有针对性地改进了。很多技术人没留意到,口头表达在影响力建设中的权重,其实远远超过书面表达,因为它是实时、与情绪相连的。
6.3 经营一个"可信赖"的人设:比"大牛"人设更实用的定位
现在很多人做个人品牌都往"大神"方向发力,但我越来越觉得,对大部分普通技术人来说,"可信赖的同行者"比"行业大神"更实用、也更可持续。
因为"大神"人设需要你持续产出远超常人的内容,而且一旦某一次露怯,反噬会很严重。但"可信赖的同行者"不需要你掌握所有前沿方向,只需要你在自己覆盖的范围里准确、严谨、乐于分享、愿意帮助别人。你不需要成为万事通,但你可以成为大家愿意问问题的"那个人"。
我认识一位后端工程师,他的博客访问量不算高,但他长期在一个Go技术社群里解答问题,五六年下来,群里大部分人都知道"遇到Go的并发问题找他就对了"。后来他出去面试的时候,好几家公司的技术负责人都表示"我好像在XX群见过你"。这种口碑不需要粉丝量,却转化成了实实在在的职业机会。
6.4 时间的复利与定期复盘
个人影响力是典型的复利型资产,前期增长很慢,甚至会让你怀疑投入产出比。我自己的体感是:前半年几乎看不到什么迹象,到一年左右开始有陌生人因为某篇文章或某个回答找到我,到两年半之后,才开始明显感受到"影响力红利"。
所以最重要的策略就是长期主义+定期复盘。我的习惯是每半年花一两个小时问自己几个问题:
- 过去半年,我输出了哪些内容?主题是否围绕我的核心标签?
- 哪些内容的反馈最好?好在哪里?能否复制?
- 哪些内容反响一般?问题出在选题、深度还是表达?
- 我和哪些新的人建立了连接?和哪些关键的人保持了连接?
- 我的目标(比如晋升、换方向、转型管理)是否需要调整影响力策略?
每次复盘下来,都会发现自己在时间分配上有很多可以优化的地方。没有复盘,很容易陷入"很努力但方向不聚焦"的陷阱。
7. 常见问题与避坑指南:这些坑我都替你踩过了
7.1 为什么我写了半年技术博客,阅读量还是两位数?
这是新人最容易受挫的时刻。我的回答是:先别急着怀疑内容质量,看看你的选题是不是追逐了错误的热点。
“什么是错误的选题?就是你自己不关心、只是为了流量去写的东西。”你硬着头皮写一篇什么“XX框架最新特性详解”,但你实际上没有用它在项目里解决过问题,写出来大概率是官方文档的翻译稿,读者不傻,一眼就能看出来。而我自己的经验是,如果10分钟之内你脑子里没有浮现一个真实的例子或故事,那这个选题基本不适合你现在写。
还有一个因素是社交媒体分发的不确定性。技术社区的文章更像是"回收站",你发布的时间是即时的,但很多人经过搜索在几个月后就搜到了它。所以,长期来看,文章质量比发布时间重要得多。别因为前几篇数据差就放弃,至少要写完20篇、覆盖5-8个不同主题再谈效果。
7.2 工作和写作/分享冲突时,我该选择什么?
**终极答案是:工作永远是第一优先级。**影响力是"锦上添花",不是"雪中送炭"。如果你为了写博客而耽误了主线项目的交付,那不仅影响绩效,也违背了影响力建设的初衷——工作成果本身就是影响力最硬的支撑。
但现实是,很多人把工作做完了,剩下的时间又被短视频和焦虑消耗掉了。其实你不需要每天挤出大块时间,用碎片时间来做信息收集、框架梳理,周末留一个完整时段来写,是可以做到的。别总想着"等我有时间了再开始",你永远不会比现在更闲。
7.3 表达观点和低调做人有矛盾吗?
这个担心我特别理解,因为技术圈确实有一些文化倾向"少说话多做事"。这里要做一个区分:**"表达观点"不等于"爱出风头"。**前者是你在专业领域内基于事实的分享和讨论,后者是你在所有领域内都要站在聚光灯下。前者为公司和个人都创造价值,后者则容易让人反感。
我给自己定的表达原则很简单:
- 只在自己的专业范围内发表观点;
- 不评判别人的方案,只讨论方案本身;
- 有不同意见时,用数据和实践说话;
- 能公开说的,就不私下说。
守住这几条,基本不会给人留下"这个人爱表现"的印象。恰好相反,你越是在专业范围内持续清晰地表达,大家越会觉得你是在帮忙,而不是在展示。
7.4 我不是社牛,不擅长社交怎么办?
这里有一个认知误区:认为"打造影响力"必须外向、必须善于社交。其实按照我前面的拆解,影响力的核心是你能为别人提供什么价值,而不是你的性格是否讨喜。写作可以不社交,开源贡献也可以不社交,内部分享同样可以不社交——你只需要站在讲台上讲好内容,不需要在饭局上八面玲珑。
性格内向的人反而有一个优势:你更容易被人认为"踏实、靠谱、不浮躁"。你只需要找到适合自己的输出方式,把"深度"这个长板发挥到极致,影响力一样可以做得很好。
7.5 避坑清单:写在最后的原则性提醒
这些原则如果你能贯穿全部操作,你会少走很多弯路:
- 不要在技术社区里"对线"或参与网络骂战,赢了对影响力没有加持,输了掉价。
- 不要过度承诺自己做不到的事,比如"下周我一定更新"但连续鸽三个月。
- 不要编造数据或复盘,技术社区的信任是稀缺资产,一次失信需要十次修复。
- 不要在分享中贬低其他技术栈或同事,给人留下"刻薄"印象会抵消所有专业加分。
- 不要追热点追得面目全非,你发布的每一个内容,都在更新别人对你的心智模型。
8. 从今天开始,可以启动的最小行动清单
根据我的经验,很多朋友看完这类文章时热血沸腾,过两天就忘了。所以这里我给你一份最小启动清单,你不需要全做,选两三件从今天开始推进就好:
- 梳理一个"我想建立影响力的三个标签",写在你的备忘录里。
- 选一个最近解决过的技术问题,用一篇1500字的文章把它写出来。不用完美,发布到团队知识库或技术社区。
- 查看你常用的两三个开源项目,去GitHub找到它们仓库里的
CONTRIBUTING.md文档,认真读一遍。 - 在团队下一次周会上,主动提出"我可以做一个XX主题的内部分享",给自己定一个日期。
- 清理一下你的社交媒体资料,把GitHub、技术社区、公众号等账号的头像和介绍统一起来,保持专业一致。
这五件事,第一件是定方向,第二件是练手,第三件是布局,第四件是逼迫自己输出,第五件是整理门面。都不难,但配上时间杠杆就能产生效果。
最后再讲一点:技术人的影响力不是一蹴而就的速成工程,它更像一棵树,前期的浇灌、换盆、剪枝都是默默无闻的,你觉得它好像没变,但要不了两三年,它突然就长成了让人认不出来的样子。我见过太多人刚开始兴致勃勃,写了几篇文章没人看就放弃了,结果一年后看到当初那些数据也一般的同行已经因为持续输出获得了新工作机会,才后悔当初没坚持下去。这是整个人影响力游戏里最不值钱的后悔——明明你也有过入场券,只是你没耐心打完这场持久战。
所以,别想太多,从今天能做的那个最小动作开始。等你积累了第一个能被外人看到的小成果,你会回来感谢此刻决定开始的自己。