在写程序的时候,最常遇到的就是 bug,有时候程序产生的错误很明显,但总是找不到代码错在哪里,甚至有时候排查了一整个下午的时间,最后发现那个错误竟然是如此的简单、傻x…,在那一刻的你无论是出于生理还是心理,一定会发出 “卧槽” 之类的声音,比你平常说话的声音高出好几个分贝,如果此时旁边有妹纸的话,还会被你吓得一个机灵,随着你 “卧槽” 声音的落下,妹纸心里破口大骂:“傻逼玩意”。

而你,还处于不爽的情绪里面:我特么花了这么多的时间精力,就因为这?

可是过不久,你又会遇到相同的情况,又是一声 “卧槽”,妹纸又是一句 “傻逼玩意”…依然单身,依然热泪盈眶,实在是妙啊!

虽然上面是个小玩笑,但写过程序的朋友应该或多或少遇到过类似的情况,每当发现程序测试运行有错误的时候,我们会去定位代码错误的地方,然后找出原因,接着纠正错误,然后重新运行,这个过程,我们叫做 “调试”。

在大部分编辑器里面,都内置了 debug 工具,我们可以通过它对代码进行逐行分析,每执行一步我们都可以清楚的看到,它做了些什么,以及执行的结果。(这一点其实除了在调试自己的代码之外,有时候阅读一些开源的项目也是一个有效学习的手段,反正我经常这么干。)

在软件程序的世界里面,我们相对容易发现程序存在的错误,因为我们只要运行,大部分情况下会有错误的 log 产生,我们可以比较快速的去定位相关的错误,而在我们的人生中,想发现自己存在的错误,却不是一件容易的事情,因为,这是一件需要我们主动的事情,我们好似没有一个显而易见的日志系统,一运行,就告诉你哪个地方错误了,特别是我们的思维,我们的想法,我们的选择…

很多人连寻找自身的错误都是不情愿的,就更别说去 debug 自己的人生了。毕竟,想要 debug 自己,首先是要寻找出自己错误的地方,不是吗?

在维基百科里面,对调试程序的的步骤是这么说的:

1
2
3
4
5
发现程序错误的存在。
以隔离、消除的方式对错误进行定位。
确定错误产生的原因。
提出纠正错误的解决办法。
对程序错误予以改正或重构,重新测试。

那么对应到自己来, 我想 debug 自己就应该是这样的:

1
2
3
4
5
6
寻找自身存在的问题
分析问题,想想是在哪里出自哪里
确定导致问题出现的原因
找出纠正错误的解决方法
试着改变,与以往做出不同的选择
重新“运行”自己

我想把这个过程称之为 “debugging my life”。

举一个我在 debugging my life 的例子,之前我在做个人计划的时候,我总感到心有余力不足,我把工作和自己想做的事情在日程表里排的满满当当,一开始总有一种把计划写了就等于把事情做完了的错觉,但实际实施的时候,并没有我想的那般美好。

这是我多次执行计划后发现的问题所在,于是我开始 debug 自己,想想到底哪里出现了问题,我重新拿出自己之前所做的计划,差点把自己逗笑了,我他娘的快把自己当做天才了,比如有些任务明明需要至少半天才能完成,这还不包括不确定因素,我愣是计划在一个小时内完成,而在当时我却浑然不知,我把自己的做事效率想的过于牛逼,高估了自己,这就是导致我总是心有余力不足的原因。

那么怎么去解决呢?

我去看了一些关于做计划的相关书籍,后来发现确实有很多人存在和我一样类似的问题,并且从中找到了解决方法,知道如何更好的预估自己需要完成任务的时间,以及做计划的一个非常重要的点——把任务拆分成最小单位,然后再去执行。

那天,我还专门写了《开始认真地做一个计划》

找到了纠正错误的解决方法之后,我开始改变制作个人计划的时间长度,不再高估自己,并且把计划排好优先级,拆分成最小的执行单位,并在每个最小单位的计划之间安排短暂的休息。

于是,我重新运行自己的计划,心有余力不足的感受不再那么强烈,反而偶尔还有一些成就感伴随在完成计划的瞬间。

现在想来,有时候我们太想冲,太想快点达到我们的目标,但常常忽略了那些错误的出现,它们在提醒我们:“兄弟,能不能停下来看看我啊?”,倘若我们对它们不予理睬,甚至还走错了道,并总是感觉脚像灌了铅一样不要命的往前跑,那危险,可想而知。

如果此刻的你,总是感觉努力了没有收获,总是感觉每天都在忙但很迷茫,总是感觉自己很累但不知道自己究竟在累什么…停下吧,停下来,好好 debug 一下自己,debugging your life,说不定能改变点什么呢。