我要不要写技术文章?

1,050 阅读12分钟

我很喜欢一句话,这也是我为什么一直喜欢写文章的原因之一。

输出倒逼输入

写技术文章真的能赚钱?

我们生在一个浮躁的时代,繁重的工作和学习任务一直压在我们身上,加上人类本身的惰性在,这些东西加起来让我们很难有时间停下来思考。

思考一些东西本质上的意义。

我最近在从 0 做系统架构设计,真正经历的时候才发现写代码事实上是很小的一个环节,而思考整个架构能给我们带来什么,架构本身的合理性,拓展性,稳定性,以及产品形态(产品应该设计成什么样子才能解决真正的问题,而不是为了技术做技术)。

写文章也是,我写了 git 的系列文章,被说是浪费时间。对于我来说明明只需要两天就可以看完的 go 整个系列的教程,也写了个把月,但是说实话我没有写出自己满意的文章。

特别是做公众号,我尝试过日更,因为工作本身就很忙,我不仅要保证文章没有错误,每个都验证过,结构要顺畅,还要花时间去想这些文字是不是写的足够通俗,因为看的用户大多数是小白,搞的自己很累,但是很难很难达到想要的效果:赚钱。

微信的特点就是私有,公众号的文章只在微信用户中流传,搜索引擎搜不到,换句话说,在上面写文章就是给微信打工,再大的号,只要微信想封,即使你辛辛苦苦耕耘是数年,也说没就没了。

更新的频率越快,历史文章被遗忘的也越快,特别是技术文章,你也很难靠积累换取影响力,而且移动端阅读代码更是不现实。想想你什么时候会刷公众号,多数不是学习的时候,比如在路上,比如在上厕所。这种时候就适合看一些不需要高强度思考的东西。

那么公众号上写东西能赚钱吗?

能,但是写技术文赚不到大钱,想赚钱只有考广告,靠在上面卖货,所有技术相关的头部大号都不是纯更新技术文的,要么就是疯狂转载,写思考文章,经历,传记,甚至有团队在运作。

靠广告和疯狂转载会很严重的影响个人的形象,这样撑起来的粉丝也不长久。拿着那几千的收入,对自己未来也没有任何好处,不如好好沉下心来磨砺自己的技术能力和思维。

真正赚钱的都是那些追热点,追娱乐的公号,搞黄色的公号,涉及股票财经或者教人赚钱的公号,就是这三大派系,理智派,污派,和钱派。

我和写书的朋友聊了下,他写的书很有名,但是到手的版权费寥寥无几,而且还要和几个作者分。

那么该不该写技术文呢?

我从刚刚开始学技术就开始写了,一开始就是纯铺代码,到现在稍微好一点,以前的一些文章不时还有人感谢和点赞,持续写,常常写,还是帮助到了很多人,只要对读者有帮助就是有用的。

虽然公众号有原创保护,但是其他平台还不是想抄就抄了,脱离了公众号,更有积累的感觉,可以在现成的平台上写,也可以有一个自己的博客,想转载就转载吧,包容一点,开放一点,被转载也是因为自己写的好,还能帮助更多的人,何乐而不为呢,只求转载的时候能带上出处。等影响力大了,即使别人不带出处也能被发现是自己的文章,多好。

写就写吧,不要带着那么多功利性,没有目的的写,记录记录自己工作中遇到的坑,解决问题的过程,工作中的思考琐事,一些小创新,小优化,小突破,甚至一个小 bug 的解决思路都可以写。

到这里可能有人会问,写这些会不会很“low”?有人会看吗。其实你多虑了,过分的担心大可不必,有太多的作者都是靠写写日常的工作琐碎,阅读量非常大,有的甚至成为了技术圈的大咖,这样的例子太多了。

所以我想说,当你带着目的性去创作的时候,往往难以成功,而不断的通过自己的坚持,总结和分享,就会成为这个行业的专家大牛。

写作对我来说,最大的意义,就是强迫自己克服惰性,深入思考研究,总结提炼,提升段位。

较长时间里,工作主要在解决具体问题。做新功能是在解决问题,改 bug 是在解决问题,帮助用户是在解决问题,自己解决了很多问题,也帮忙别人解决了很多问题。在此期间了解了新的业务,拓展了技术体系边界,但感觉自己的段位并没有显著提高。为什么?

因为对工作内容的总结提炼不够,无法站在更高层面“悟”,段位提升不明显。

虽然我开发了很多具体的功能,解决了很多具体问题,但大多数问题是碎片化的,单纯碎片化救火并不能有效提升自己的段位。只有持续有深度的总结提炼,将碎片化问题抽象提炼,更高层面考虑问题域的方法论和通用解决方法,高屋建瓴,才能有效提升段位。

而要强迫自己深入思考研究,并不容易。因为深入思考不像解决具体问题那样有即刻的收获感、工作紧迫性必要性。要主动,要克服自己天然的惰性。而写作是一个非常好的强迫自己深入思考研究、提升段位方法。

不同于给自己看的工作记录,随便写写,即使像密电文也能理解。给别人分享,必须要让不了解你的人感同身受,了解到所分享内容背景是什么,是否找到问题的本质,如何解决,有什么方法论做理论支持,做了哪方面取舍,还有哪些可以提高的地方。写作过程就像自己对自己的面试,深挖下去,发现之前没去想,没觉得是问题的问题,甚至会发现即使想到了问题也想不清楚答案的问题。

另外一些紧急凑付事的临时解决方法,也不好意思拿去分享。只能思考,再思考,去想所有问题的答案。联想自己做过的其他事情,读过的资料,继续去搜索,去尝试,给出至少让自己信服的答案。如此写完,虽然感觉很疲惫,但有感悟,自己得到了提高,很有收获。

写作可以消化所读的技术文章,将被动记忆的知识,通过写作,变成自己真正掌握的知识。

为了提升段位,自己看了一些书,很多技术文章。不能在工作中立即用到的技术知识,也坚持做了不少积累。像系统架构,源码分析,算法实践,有意思的分析都看了不少、努力理解这些文章讲了什么,收藏了很多有用的链接。年度总结,似乎学了很多,可依然没感到段位有显著提高。这是为什么?

这是因为之前的学习,实际是在用应试方式去理解,记录要点。虽然一段时间内能像复习考试般清楚自己学过什么,但没有结合自己经历深入的“悟”,没有变成真正掌握的知识,日常工作用不上,慢慢就淡忘了。

解决方法依然还是靠写作,来强迫自己深入思考。写阅读的收获,自然不能把原文抄一遍,要有自己的理解感悟,要结合自己做过的事情写点新东西出来,需要把知识体系打散了重新提炼。一旦有了深入思考,写出自己认可的阅读分享,自然就真正掌握了所学的内容。

写作可以提高拆解问题,分层细化的能力。

以前迷信敏捷快速迭代,认为不能过度设计。去解决一个问题时,才会思考这个问题的解。遇到新问题,case by case 解决新问题。规划不够清晰,缺少对需求,业务流程,业务建模,数据建模,架构建模,接口建模的有效拆解,没有从上到下,一层层将问题域拆分的足够清楚。规模不大的问题可以轻松解决,一旦要处理涉及面广,流程复杂的多业务域问题,就会因为考虑不足经常要修改原来的设计和实现。

而写作要让别人容易读,就不能像头脑风暴那般想到哪写到哪。要提前确定好分享的主题,按照主题整理写作提纲,层层细化,分解章节目录,各级要点,控制写作范围,避免写的文不对题。这就很好锻炼了拆解问题,分层细化的能力。

写作可以获得反馈,走出思维盲区。

再多的自我思考,实践验证,依然可能存在思维盲区,有常识性错误而不自知。分享可以让更多人了解,更多获得反馈修改错误的机会,帮助自己进一步提高。

写作可以提高自我认知,认识更真实的自己。

技术人员往往会高估自己。我的错觉之一是总觉得存在某条提升能力的捷径,研究各种方式方法而忽视了脚踏实地的前行。错觉之二是做了一堆计划就很有满足感,好像已经成功了大半。最后计划往往没完成,安慰自己是太忙的原因而不是能力问题。

实际上,时间管理是技术人员最需要的能力之一。做了计划完不成,首先是对自己认知不足,过于高估自己能力。写自己认可的文章,会认识到自己知识的不足,思考的不足,写作能力的不足,直面更真实的自己。认识到到写一篇自己认可的文章,原来需要这么多时间精力。认识到要想提升段位,必须投入更多时间精力,一步步前行,没有捷径可走。

如何写技术文章

上面说了为什么写,下面说下怎么写。

其实技术稿件没有大家想的那么难,不一定非得整得很高大上,这里给你的建议是聚焦一个关键点或者关键技术,把背景,实现过程,架构设计,系列系统调优的过程写清楚就可以,切记不要写成产品介绍。

我们要写的是技术稿,不是产品文档,所以需要和读者完整介绍一下自己项目的技术实现,以及背后的思考。这里有人可能会问,这个项目背后的技术点很多怎么办,那么提炼出 2-3 个关键点,或者你认为比较有价值的点重点说即可以。千万不要什么都写,最后成了好像什么都有,什么都没写清楚的状态。

其次,文章的选题比较关键,如果未决定开始写的情况下,可以稍微调研下,这个主题领域大家比较关注哪方面话题,什么样的话题大家感兴趣,这样写出的内容能够最大程度引起关注,虽然刚才说写作就是自己的日常分享,但是写作是一个高成本的事情,在动笔之前,多一个考虑总不会太坏。

最后,写作的内容和逻辑线一定要清晰,我看过很多万字长文,虽然一眼看上去很厉害,但是真正仔细对齐,很多都是不需要的“废话”,考虑自己的感受,也考虑读者的阅读体验最重要,技术稿一般 4-5 千字最好,太少的话,很多技术细节说不清楚,太长读者也看不进入。

技术文章的逻辑线一定要清晰,包括写这篇稿子的背景、目前这项技术面临的挑战、我们是如何实现的、目前取得的效果、未来的计划等等,一般这样的逻辑下来,读者看起来会舒服很多。

这里还要提醒一句,专业的文章尽量通俗化一些,不用太专业,因为毕竟面对的读者百分之 80 都是小白用户,写的太专业,那是专利论文,毕竟我们的目的是让更多人看懂。

参考:

  • 为什么要写专栏-晓哥 https://zhuanlan.zhihu.com/p/35635056
  • 腾讯开发者公众号-感觉写技术文章的时候老是找不到突破口,有没有什么写技术文章的方法论?链接匿
  • 酷壳网-为什么我不在微信公众号上写文章-陈皓 https://coolshell.cn/articles/17391.html

本文使用 mdnice 排版