从郎咸平批评认知看职场祛魅

郎咸平在回复一个提问“月入五千和月入五万”在认知上有什么差别时,本以为他会从认知维度高谈阔论来论证,结果却是对提问者好不委婉的训斥,他说:

“你们和送外卖的在认知上没什么区别,在我看来没有区别,你们一样啥也不懂,唯一的区别是你过了哪条线,才有了参与的机会。恰好你还干得不错,可能是这个因素,也可能是那个因素,就是综合原因,才走到了现在”。

这句话乍一听有点刺耳,甚至带着点精英主义的傲慢,但仔细琢磨,却戳中了职场和社会竞争里最隐秘的真相——很多时候,你需要先拿到上桌门票,才有机会参与游戏。

在职场中,要进行祛魅职场,那些“上桌的人”,未必比你强,只是比你早一步摸到了入口。

我花了很长时间才想明白一件事:那些坐在高位的人,那些在会议上侃侃而谈的“专家”,那些手握资源、头衔光鲜的“成功者”,其实并没有想象中那么不可企及。他们未必比我聪明,未必比我更懂业务,甚至未必比我更努力——他们只是比我早一步摸到了某个入口,或者恰好踩中了某个契机。

这个认知让我彻底放下了对“权威”的盲目敬畏。我开始明白,职场和社会竞争的本质,不是能力的绝对比拼,而是一场关于“规则、时机和入场券”的游戏。

那条隐形的“线”,才是真正的分水岭。我们从小被教育“努力就能成功”,但现实是,努力只是最基础的条件。真正的分水岭,是那条隐形的“线”——学历、资历、人脉、平台,甚至是运气。

我见过太多人,能力并不出众,但因为早几年进入某个行业,赶上了红利期,如今已是“行业大佬”;也见过更多人,明明实力强悍,却因为学历或背景的硬伤,连展示的机会都没有。

这让我意识到:“上桌”的人,未必是更强的玩家,只是更早拿到了入场券。

高位≠高能,别被“光环效应”骗了。我曾经对高管、专家充满敬畏,直到某次会议上,一位VP(副总裁)提出一个明显脱离实际的方案。我小心翼翼地问:“这个方案在技术上可能会遇到XX问题……”他愣了一下,然后含糊其辞地绕开了。那一刻我突然明白:他根本不懂细节,他只是习惯了别人不质疑他。

后来我观察到更多类似的现象:

  • 许多高管的决策,依赖的是下属提炼的简报,而非一手信息;
  • 某些“行业专家”的见解,不过是重复几年前的陈词滥调;
  • 那些看起来自信满满的权威人士,私下也会焦虑、会犯错。

头衔会给人镀金,但不会让人突然变聪明。

祛魅的关键:看清“游戏规则”,当我意识到这一点后,我开始用另一种眼光看待职场:

  • 不要盲目崇拜“高位者”——他们的成功,可能是时代红利、平台加持,甚至是运气;
  • 不要低估自己的专业价值——你在业务细节上的积累,是那些远离一线的人无法比拟的;
  • 不要被“规则”困住——如果现有的游戏规则对你不利,那就想办法绕开它,或者自己制定新规则。

专业自信:你才是细节的王者,我在自己的领域花了足够多的时间:

  • 我知道每个环节的坑在哪里;
  • 我试过所有可能的解决方案;
  • 我清楚数据和事实,而非依赖模糊的“经验”。

这让我在面对那些“高高在上”的决策者时,有了十足的底气。当他们提出不切实际的想法时,我会直接说:“这个方案在测试阶段会遇到XX问题,我们试过A/B两种解法,数据表明B更优。”

细节,是破除权威幻觉的最佳武器。

真正的自由:选择自己的游戏,最后我明白了一件事:人生不是只有一张桌子。

  • 有人挤破头想进大厂,而有人在小公司做得风生水起;
  • 有人追求高管title,而有人选择自由职业,活得更加自在;
  • 有人沉迷于社会定义的“成功”,而有人早已跳出了这套评价体系。

真正的祛魅,是看清所有规则后,依然能冷静选择自己的路。

所以,别再仰望那些“上桌的人”。他们只是玩家,不是神明。而你——

  • 可以尊重他们的位置,但不必神话他们的能力;
  • 可以学习他们的经验,但不必盲从他们的观点;
  • 可以玩他们的游戏,但更可以开辟自己的战场。

因为最终,能定义你的,不是别人制定的规则,而是你如何看待自己。

Read more

痛风带来的思考

昨晚一罐冰啤酒下去,睡觉时就感觉脚踝隐隐发作,果然早上起床直接下不来地。跟崴脚的感觉十分相似,无法行走,只能坐在一起上滑动,公司上班也去不了了,呆呆得躺在家里,下午疼痛感加剧,整个心思都在左脚的疼痛上,没有其他任何多余的精力去关注其他事情,而此刻的阳台,乃最美人间四月天,春日的微风吹拂着阳台的花儿,温暖的阳光抛洒下来,一切都如此惬意,而我却无心欣赏。 人在健康时,生活中有好多问题,但人在不健康时,生活中只剩一个问题。 我对这句话的理解更深刻了。人是健忘的,在疫情期间、在手术期间,这种感悟其实已经很深刻了,但是病情好转之后,人还是会被日常的琐碎、工作的烦扰搅乱心绪,没有专注的去享受生活本身的美好。 幸福的秘密在于,去享受我们所拥有的,而不是顽固的去追求所没有拥有的。阳光、草木、微风,都是幸福的玩意儿,应尽情的享受。 再等两天,脚完全恢复好了,身体健健康康后,我要以更轻盈的姿态去生活,不纠结他人的看法,不执着别人的认可,关注自己的能力,享受拥有的生后。 还有一个反省,针对咖啡、酒、烟,

By 李浩

设计模式之命令模式

命令模式将“请求”封装成对象,以便使用不同的请求、队列或者日志来参数化其他对象,命令模式也支持可撤销的操作。 来解析这个定义: 1. “将一个请求封装为一个对象”,请求原本是一个方法,现在要封装成一个对象,说明要新增类来完成。 2. “可以用不同的请求对客户进行参数化”,说明是将命令对象作为参数进行传递。 3. “队列”说明需要维护命令多个命令的列表队列。 4. “撤销”说明有命令对象有undo撤销方法。 命令模式在设计模式中,算是一个比较不好理解的模式,很重要的原因是不清楚设计意图,不清楚不用这个模式前有何问题,这个模式带了哪些好处,能解决什么问题。 上一篇状态模式中,看到了状态模式抽离的是状态(属性),向上提成状态对象。有了这个基础,再来理解命令模式就相对简单了。命令模式抽离的是行为(方法),向上提成命令对象。 两者都通过“对象化”来解耦和扩展系统,但解决的问题不同: * 状态模式:处理对象内部状态驱动的行为变化。 * 命令模式:处理行为请求的封装与调度。 💡智能家居遥控器,假设我们有一个智能家居遥控器,可以控制 灯(Light) 和

By 李浩

设计模式之状态模式

状态模式允许对象在内部状态改变时改变它的行为,对象看起来好像修改了它的类。 来解析这个定义: 1. “内部状态”表明对象内部有一个属性来表示状态。 2. “内部状态改变时改变它的行为,对象看起来好像修改了它的类”说明状态改变后对象的行为发生了非常大的变化,不像是同一类的行为。 从目前的分析中似乎无法推导出状态模式的类图结构。 从实际的例子出来,来看看状态模式是如何演进而来。 💡我们有一个文档审批系统,文档有以下状态和转换: 1. 草稿(Draft) → 提交 → 待审批(PendingReview) 2. 待审批 → 批准 → 已发布(Published) 3. 待审批 → 拒绝 → 草稿 4. 已发布 → 撤回 → 草稿 从直觉出发,会使用条件语句实现需求逻辑。 public class Document { private String state = "DRAFT"; // 初始状态为草稿 public void submit(

By 李浩

设计模式之代理模式

代理模式为另一个对象提供一个替身或占位符以控制对这个对象的访问。 解析这个定义: 1. “替身”表明在客户端看来,代理类与被代理类是同一类别,对客户端来说看上去没什么区别,依然能够满足诉求。如此可以看出代理类与被代理类来自同一个超类。 2. “控制对这个对象的访问”,能够控制访问,说明前提是能够访问,才能在访问之前做这个限制,即代理持有对真实对象的引用(或能创建它)。 当然可能会质疑,用继承的方式不是也能完成目标吗,用代理类去继承被代理类,然后重写方法,加入控制逻辑。但这违背了"组合优于继承"原则,代理类与被代理类强耦合。 💡我们要开发一个图片查看器,需求如下: 1. 图片加载开销大(从磁盘或网络加载耗时),希望首次显示时才加载(延迟加载)。 2. 某些图片需要权限校验,只有授权用户才能查看。 3. 客户端代码应统一接口,无需关心是直接加载图片还是通过代理。 // 1. 抽象接口(Subject) interface Image { void display(); } // 2. 真实对象(RealSubject)

By 李浩