Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

关于时间管理的一点新的感悟

Posted on 08/26/202310/01/2024 by 四火

从读书,到工作,都离不开时间管理,我相信只要不是属于无比随性的少数人,应该都有自己的体会。因为这件事情太重要了,它贯穿于每日的生活和工作之中。好久以前就写过一点关于时间管理的体会,后来又补充了一些,现在重新开一篇短小的文字,记录一点新的感悟。

变化

随着年岁的增长,我却越来越感到时间管理这件事情在不断地变得更加重要,因为整体的事务数量和复杂度都提升了。

关于其中的原因,我仔细思考过。大致上,在年纪轻一点的时候,兴许每天需要筹划实施五件事,但是现在呢,每天需要筹划实施十件事。相应地,年轻的时候,兴许可能这五件事里面,最终能完成三件;而现在,这十件事里面,也最多能完成五件,看似完成的更多了,却留下了更多的待办事项。

那接着的问题就变成了,为什么现在的事情更多?

一方面是因为年纪增长,本身就需要承担更多的责任,比如需要处理孩子的事情,家人的事情等等,而这样的事情简直太多了。读书的时候,虽然忙,但是事情的类型相对单纯,而现在的忙,则是掺杂了生活、家庭、工作、学习等等各种各样类型的事情。我记得有一句话说,“成年人的世界里没有童话”,繁忙就是常态。

至于另一方面,则是因为科学技术的发展,尤其是信息技术的发展,让一切都变得更可触及和可获得,因此我们的选择更多了,有精力去同时参与更多的事情。比方说,各种社交软件,就会不断打断你的进程,侵蚀你的时间。也许在十五年前,我只需要处理回复短信就可以了,现在我需要处理邮件、短信、微博、微信、Twitter……当然,作为一个社会人,这些也都是有各自的必要性的,我享受于置身其中,并不想成为那种抛弃世俗联络的人。

除去上述原因外,我觉得还有一个有趣的因素,我越来越留意到,人的大脑总是更愿意和更擅长完成单纯的、排他性的活动。因此如果缺乏时间管理,很可能没有头绪,当即可以做的事情有一堆,自然而然产生畏难情绪,即便勉强做起来,也很可能瞻前顾后,很难专注。

时间管理的一大目标就是把当前要做的事情清晰化,可能有十件事情要做,但是根据规划,当前只要做其中的两件就好了,这就让大脑觉得舒服得多,压力也更少。因此时间管理就是变得越来越重要。

策略

于是,有些时间管理的方式方法就有了更重要的地位。

比如说,安排优先级就是其中之一,记得很早以前看过一张四象限的图:重要+紧急,重要+不紧急,不重要+紧急,以及不重要+不紧急。有些事情就需要有更高的优先级,去立马完成;有些事情在当前可以拖一拖,但是随着时间的流逝,它会变得越来越重要。而有些事情则始终没有那么重要。

再比如说,碎片化的时间,碎片化是时间管理的大敌,无论怎么安排,碎片化的时间就是很难做到高效利用,这是事实。因为当时间变得碎片,每一个碎片都需要使用大脑上下文切换的时间,这就降低了整体的实际时间利用率;更不要说在时间碎片中,我们往往具备软硬条件的各种限制,很难实施一些需要大块时间才能够做的事情。

举个例子,在开车的时候,大脑往往具备一定空闲的份额,而这个份额可以用来接受适度的信息,我觉得听播客、听访谈就是一个不错的方式,我算是个喜马拉雅长期的用户。但是这种时间并不适合需要大量思考的行为,毕竟心不在焉着驾驶还是非常危险的。

接着我想说的,是明确自己的能力范围,抓住主线事务。

我以前犯过的错误之一,就是 “野心太大”。这既包括想做很多方面的事情,最终可能很多都浅尝辄止;也包括在想把一件事情做到的程度上,过于激进,导致花了大量的时间,进度却很不令人满意。无论是哪一种,都和没有对于自己的能力准确识别有关。

关于主线事务聚焦,其中一条重要的原则就是不要有太多并行的进程。具体说,每天都不要做太多的不同主要的事情,尤其是这些事情属于同一类型的时候,哪怕这些事情看起来可以在一天内完成。一般来说,需要耗费时间精力的事情,一天做个三、四件就已经是极限了。太多的事情会让完成的效率降低,或者会导致一些低级错误。

举例来说,有时候和同事进行线上的 1 on 1 对话,可能讨论技术话题,可能讨论业务话题,可能讨论职业方面的内容……无论哪种,我的经验是,这样的活动,在每天不宜安排过多。就算它们中每一个都只可能占据半个小时的时间,但是一天的对话超过 3 个,哪怕加起来它们的总时长也哪怕只有两个小时,我发现大脑也会只保留其中的两三个,而自动模糊剩余的部分(换言之,只有最多两三个对话会留下足够深刻的印象)。类似的情况在做很多其它事情的时候出现,比如面试,比如参加类似的技术讨论会。

究其原因,我觉得有两点。一点是很多活动看似只有一个特定的时间长度,但是却有一定的长尾效应。比如一个技术问题可能只讨论了半个小时,但是在这之后,大脑依然会时不时地想到它,并进行进一步的思考。这种有趣的现象其实很有用,有很多问题都是以这种方式想出来的。第二点是人脑具备一种特殊的排他性,这种排他性让自己在类似的情况短期内(尤其是一天)出现几次的时候,只有印象最深的两三个能被比较好地记住。

最后,任务切分也是一个重要步骤。

前面已经提到,时间管理的一大目标就是把当前要做的事情清晰化。因此对于一个模糊而复杂的事务,其中一个重要的步骤就是把它切分,切分成若干个可以完成的部分,这样去处理每一个部分都显得清晰而游刃有余。这有点像软件世界里面的项目管理,任务切分,我想,本质上是相通的。

举个例子,前一阵子需要给孩子申请某一证件,这就需要若干材料,这些材料需要跑不同的地方(譬如要开证明,要在网上递交申请,要写邮件去获取文字材料等等),走不同的流程完成,而这些流程之间还往往存在依赖关系。这就可以把整个过程列出步骤 1、2、3、4 在笔记上,每次只从可以进行的步骤中选择当前能做的,之后等待流程完成以触发下一个流程,同时还需要订立提醒,以避免某个流程因为某些原因超时了,需要特殊的干预过程。这整个过程看起来,其实和一个工作流系统的设计非常相似,每次只关心一个工作环节,这一点也是非常有意思的。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 哎,写代码的时间真的越来越少了……
  2. 职业生涯下一站
  3. 闲聊投资:亲自体验和护城河
  4. 我为什么坚持写博客(续)
  5. 英文能力与独立思考

1 thought on “关于时间管理的一点新的感悟”

  1. Anonymous says:
    03/14/2024 at 2:56 AM

    博主日常用什么记录日常计划

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Python Spark 互联网 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 程序员 管理 系统设计 缓存 编码 编程范型 英语 西雅图 设计 评审 问题 面试 项目

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Big Data and Machine Learning (5)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • + 1.943624 BTC.NEXT - https://graph.org/Ticket--58146-05-02?hs=9a9c6f8dfe3cdbe0074006e3e640b19b& on 所有文章
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
  • Dylan on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme
Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接