为什么写代码是一件很爽的事情?

2021-10-19  本文已影响0人  ThoughtWorks

为什么写代码是一件很爽的事情?

我的看法是:

因为这些感觉/感受,写代码成为了一件很爽,甚至会上瘾的事情。其实会上瘾的事情,通常也有这些特质。

软件交付的上下游

写代码是整个软件交付过程的一环,当然软件交付是整个产品的一环,产品又可能是公司战略的一环。我们就只把上下文限界在软件交付的过程中。稍作抽象,软件交付是在解决问题,用某些技术(代码)来解决某些人的某些问题。

从定义问题,到找出解决方案,再到实现,那大约会就出现了”上下游“的概念。

image

顺流而下

从问题,到解决方案,再到实现,如果我们从以下几个维度来观察:

就会发现趋势:

image

不确定性 - 从高到底:

不确定性是因为变化导致的,而且是不规律的变化(如果变化是规律的,那就是可预测的,不确定性也就大大降低了。)

我们经常说市场在变化,需求在变化,甚至是人在变化,这些变化导致了大量的不确定性。从找到/定义问题,到制定解决方案,再到实现,不确定性的趋势,是由高到低的。

反馈周期 - 从长到短:

在问题阶段,客户/用户提出一个问题/请求,到这个问题得到合理验证性的回答,这个中间是需要一段时间的;而且,很多这个阶段的问题,都只能给出假设性的回答,或者没有回答,只能等到产品上线之后才能知道其中一些。

等到了最后的实现阶段,不断拆解Release -> Feature -> Story -> AC -> Task -> TDD, TDD的反馈环就不言而喻了吧。

从无形到趋近于有形:

在物理世界里,当然软件也是无形的;不过在数字化的世界里,可以工作和运行的软件就是有形的了。

某个问题,某些想法和感受,通过文字或者图片表达出来,以此来找到解决方案,再通过计算机程序语言来实现变成可工作的软件,这个过程是无形到有形的转化。

从人的问题转为了程序的问题:

Ta有什么期望?现在的体验是什么样的?有什么其他的没有说出来的诉求?会不会受到什么影响而改变决策?这些都是典型的人的问题,不一定有确切的答案,有时候甚至是Ta自己也不知道。

程序的问题则不一样,这个地方出错了,一定是有原因的,某个地方的逻辑一定出了问题,我会找到原因的。
所以,从问题到实现,我们一开始偏重人的问题,到最后逐渐转化为解决程序的问题。

上游的蝴蝶

上游对下游的影响是显著,而又数量级递增的,就像“蝴蝶效应”一样。上游的蝴蝶扇动了翅膀,可能会对下游产生剧烈影响。不过,倒也不用太担心,因为软件交付的下游影响比蝴蝶效应要可控一些,预测性比较强。

image

上游的Problem:

中游的Solution:

下游的Implementation:

上游的"蝴蝶",很重要

通过上面的分析,可以看到,上游的”蝴蝶"很重要,扇动翅膀的威力很大。

我们自然是希望更有经验的人来做上游的”蝴蝶”:

项目里谁适合呢?有经验的PM, BA, TL被选中了!

如果客户方有技术/架构师参与到项目交付中的时候,TL就跑不脱了。

为什么不写代码是件”不爽”的事
非彼无我,非我无所取。

那不写代码很会失去哪些写代码的能获得的快乐呢:

及时反馈 && 确定性强,这两个肯定是没有(或者大幅降低)了。
那成就感,和被需要感呢?
既然加了一个“感”字,那就说明这个东西,就是“主观的”,我说有就有~
如果感受不到成就感和被需要感,那就去寻找,创造,记得向外看(可以参看之前的博客: 拼命的工作有人教 快乐的工作没人教

那我不写代码,得到的啥?

是会议、PPT与扯皮吗?就这?

上一篇 下一篇

猜你喜欢

热点阅读