目 录CONTENT

文章目录

程序员是如何思考?

不争
2024-01-02 / 0 评论 / 0 点赞 / 14 阅读 / 2153 字

10X 程序员是如何思考?(摘要)

四个思考原则

  1. 为什么要做这个特性,它会给用户带来怎样的价值?
  2. 什么样的用户会用到这个特性,他们在什么场景下使用,他们会怎样使用它?
  3. 达成这个目的是否有其他手段?是不是一定要开发一个系统?
  4. 这个特性上线之后,怎么衡量它的有效性?

给出思考框架是为了让你明白为什么要提出问题,而具体问题要怎么问,就可以遵循下面这四项原则:

  1. 以终为始;
  2. 任务分解;
  3. 沟通反馈;
  4. 自动化。

以终为始:就是在工作的一开始就确定好自己的目标。我们需要看到的是真正的目标,而不是把别人交代给我们的工作当作目标。你可以看出这个原则是在帮助我们回答思考框架中,Where are we going?(我们如何到达那里?)的问题。

任务分解:是将大目标拆分成一个一个可行的执行任务,工作分解得越细致,我们便越能更好地掌控工作,他是帮助我们回答思维框架中,How can we get there?(我们如何到达那里?)的问题。

如果说前两个原则是要在动手之前做的分析,那后面两个原则就是通往目标的道路上,为我们保驾护航,因为在实际工作中,我们少不了与人和机器打交道。

沟通反馈:是为了疏通与其他人交互的渠道。一方面,我们保证信息能传达出去,减少因为理解偏差造成的工作疏漏;另一方面,也要保证我们能够准确接收外部信息,一面因为自我感觉良好,阻碍了进步。

自动化:就是将繁琐的工作通过自动化的方法交给机械执行,这是我们程序员本职工作的一部分,我们擅长的是为其他人打造自动化的服务,但我自己的工作却应用得不够,这也是我们工作中最值得优化的部分。

怎么把这四个原则用在工作中呢?我们回过头看一下前面的场景,产品经理把要做的功能特性摆在我面前。站在以终为始的角度,我需要了解真正的目标是什么,所以,我会关心为什么要做这个特性。为了保证目标是有效的,我会关心它给用户带来的价值

有了任务分解的视角,我需要将一个大的目标进行拆解,如果我要达成这个目标,整体解决方案是远远不够的,我需要把任务分解成一个一个小的部分。所以,我会关心一个一个具体的使用场景

一方面,我会了解到更多的细节,另一方面,当时间紧迫的时候,我会和产品经理来谈谈究
竟优先实现哪个场景。

为什么要学会沟通反馈?因为我需要明确,自己是否真正理解了产品经理提交的需求。所以,我要不断地问问题,确保自己的理解和产品经理交代的内容一致。

另外,我也需要保证我的产品做出来确实能够达到目标。所以,我会关心它上线后的衡量手段。因为我知道,这个行业里有太多代码上线后,从来没有运行过。

自动化的角度很有意思,**我们做的方案通常是一个自动化方案,但我们需要了解这个方案没有自动化之前是怎么做的。**如果不自动化,用户会怎么用。所以,我会关心是不是还有其它替换方案,比如,买一个现成的服务。因为很多需求的提出,只是因为我们有了一个开发团队而已。

好,现在你已经对这四个原则在工作中的应用有了一个直观的认识。但你也会发现,我问的这些问题似乎已经“超纲”了,超过了一个普通程序员应该关注的范围。但这就是真实世界,它不像考试一样,有一个标准答案。

我们不是一个人孤独地在工作,而是与其他人在协作,想要做到高效工作,我们就要“抬起头”来,跳出写代码这件事本身。所以,我在开篇词里说,程序员解决的问题,大多不是程序问题

总结时刻

大多数人工作低效是由于工作中偶然复杂度太多造成的,只要能够更多地将注意力放到本质复杂度上,减少偶然复杂度造成的消耗,我们“真实”的工作效率自然会得到大幅度提升。

而想要减少偶然复杂度的消耗,就要了解一些高效的工作方法和最佳实践,而这一切是可以用统一的框架进行思考的。

如果今天的内容你只能记住一件事,那请记住:面对问题时,用思考框架问问自己,现状、目标和路径。

如果今天的内容你只能记住一件事,那请记住:遇到事情,倒着想。

0

评论区