Skip to content

四火的唠叨

一个纯正程序员的啰嗦

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

工作压力的问题

Posted on 06/25/201210/01/2024 by 四火

1程序员的工作是紧点好还是松点好?

对个人的影响

有人说紧点好,理由是可以从中学到东西,这是一种压力驱动式的学习方式;也有人说松点好,可以有大把的时间去闲逛、打酱油。前一种人至少是上进的、积极的,只是兴许是由于教育体制和软件大环境的原因,已经失去了许多主动性,非得要环境逼迫的压力下才能去学习、去分析和解决问题。

其实,大部分刚毕业的程序员都属于前一种,他们至少是努力着去提升自己,设法去写出好的代码,有一种追求卓越的愿望。但是,我们从来的教育都是这样,喂食—— 吃食,喂食—— 吃食…… 到了大学,喂食的情况少了,于是颓废、堕落的人就多了,素质教育和体验教育没有跟上节拍,真正要实施的时候发现,学生基础、自我管理和约束能力与领导的理念太不兼容,于是实施只能停留在概念上。

后一种人则要令人伤心得多。打酱油的人大有人在,他们已经没有了锐气,没有了动力,很想混到一个舒服的岗位上,或者做一份安逸的工作。其实这也是一种生活方式,本身无可厚非,只是从大多数人所理解的“ 优秀的程序员” 的角度上来说,无疑是不甚合格的。

不容忽视的一件事是,对于一个足够优秀的程序员,即便你给予很少的工作量、不尽细致的工作目标,他依然能够自发地工作、学习,这是一种高度自我管理的工作方式。这样的程序员并不多,但是这样的人,无疑是有足够热情、足够意志力的,他们的未来并不会因当前不适合的环境受到太大影响,换言之,是金子总是会发光的。

我的一位亲戚在这次高考中“ 没发挥好,比正常水平少了四十分”(绝大多数家长都觉得自己的孩子没发挥好 :))一样,问我,还要复读不?我说,如果你想混个文凭,那么,尽管去读吧,我相信你明年可以考得很不错;但是如果你想有所作为,何必在乎那四十分呢?你的复读,浪费的是你一年的时光,给你带来了额外的、长达一年的枯燥的痛苦,也许你损失的将远远大于你得到的。

从软件的本质来说,创造性的工作,始终应该给予最宽松的氛围。只有在宽松的氛围下,思维的潜能才能得到最大的释放。国内的软件环境被两种人搞坏了:一种是无良的企业主,他们依仗毕业生的诚惶诚恐的心态、廉价的劳动力,拼命压榨员工,甚至把维护公司利益宣扬得如何地伟大和光荣,但是对于程序员的人文关怀则忽视不见;第二种人正是广大自怨自艾的“ 码农”,工作量大了抱怨没前途,工作枯燥了抱怨没技术含量,工作领域自己不熟悉了抱怨被公司忽悠了…… 只是生活并不总随人愿,不蛰伏、不适应、不改进(毕竟没有事物是完美的,事实上,在一定程度下的“ 忍” 是很好的办法,去获取那些积极的因素,比如可以学到很多东西,增加丰富的阅历),而是无休止的抱怨,甚至连离职的勇气都没有!“ 哀其不幸、怒其不争”,这是程序员中最令人心痛的群体。

在《浪潮之巅》中数次提到,美国的 IT 领域为何能够如此蓬勃发展,反垄断法起到了不可替代的作用。反垄断法使得 IBM、Inter 等各领域内的巨头,不得不养着自己的竞争对手,这些竞争对手尚不足以威胁到自己的生存,但是限于垄断的红线,又不能轻易地收购、打压它们,事实上,最终它们帮助这些 IT 巨头一道培养出这个领域市场来,并且持续逼迫着它们始终坚持技术进步。同理,倘若中国没有那么多人,劳动力没有那么廉价,是不是会有助于软件行业的进步?起码,更多的东西需要机器、程序去完成,而不是人力的介入,这就是一个促进科技发展的正面因素。

—————————————————————————————————————-

对团队建设的影响

团队的工作,无疑是团队文化的重要影响因素之一(当然我坚持的一个观点是,无论是哪种文化,核心永远是“ 人”,而不是工作、流程、历史)。举例来说,很难想象,在一个成天压榨之上、工作昏天黑地的团队中,能有宽松的氛围。

我经历过一个压榨员工极其凶猛的公司,平均每天的工作可能已经超过了十小时,周末单休、经常通宵。我属于脸皮比较厚的员工,“ 下班了完成工作就回家” 这样看起来理所当然的事情对于很多人来说竟然成为了奢望:

  • “ 别人都在工作,你好意思走啊你?”
  • “ 你那么早回家,工作不饱满!”
  • “ 你还是留下来,陪大家一起,我们要像一个团队嘛,年轻人吃点苦有好处。”

刚开始我听到这样的话还火冒三丈(有类似经历的请举手!),后来我逐渐明白,这是一种病态的团队氛围,这并非特定是谁的过错,但是当工作压力大到一定程度时,比绩效变成了比时间、比态度、比可怜,团队成员的理性的思维极大地受到影响,团队的氛围彻底被这样的多数人同化了。

最终许多人(包括我在内)离开了这支团队,我很喜欢里面的每一个人,大部分人对我都很好,但是也许是过于繁重的工作压力(也许不是,我只是推测,也有可能是无良领导的因素,或者是公司的文化使然),让团队成员感受到的人文关怀少得可怜。

在团队文化的建设上,团队经理不应当成为一个约束者,而应当成为一个引导者,自己少去下结论、做判断,而是让大家去完成这样的事情。团队的文化应当有一定的包容性,这样的环境是有助于培育不同风格的“ 人” 的。

—————————————————————————————————————-

对项目的影响

看了许多敏捷实践、管理措施,我越发觉得,倘若项目交付压力过大,这样交付的问题,是任何方法论是都无法解决的。这是很简单的原理,但是很多公司领导并不清楚这一点,以为只要采取了什么牛逼的实践,只要保证了流程的质量,开动员会、喝壮士酒、写军令状,就可以在变态的项目中拼搏出一个好的结果来。

我参与过一个疯狂的项目,交付压力大到无能为力的情形下,采取不要文档、不要过程、甚至不要正规的测试—— 全裸奔的开发过程。这看起来荒唐无比的事情,确是当时做出的一个正确决定,实乃无奈之举。

反过来,如果项目过于稀疏,对于培养程序员的成就感,亦不是一件好事。这些年,越来越多地听到一个词——“ 节奏”,古人文武之道就已讲究一张一弛,我等工程商人,更不能违背规律行事。

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

×Scan to share with WeChat

你可能也喜欢看:

  1. 自由地生活和工作
  2. “残酷” 的事实
  3. 时间投入上的权衡
  4. 我裸辞了
  5. Good Surrounding For Programmers

1 thought on “工作压力的问题”

  1. 常高伟 says:
    06/25/2012 at 11:57 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 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)
  • Machine Learning and Artificial Intelligence (6)
  • 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 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • Ticket: TRANSACTION 1.922915 BTC. Go to withdrawal >> https://yandex.com/poll/enter/BXidu5Ewa8hnAFoFznqSi9?hs=20bd550f65c6e03103876b28cabc4da6& on 倔强的程序员
  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme