爆栈思想 – 开发人员如何面对各种不公和不满

某司,同一天,有2个开发人员通知大家他们离职,其中一个还是做技术这块算是二号人物的元老。另外一个,和我谈过一些对他不公平的事情,对管理如何的不满。

工作中,我们会遇到各种不公平的事情。我的职业生涯中,超过10间公司,每间都有这样那样的不公平/我不满意的事情,譬如:

  • 一些老油条把他们的任务强塞给你
  • 你完成的任务,他们抢过去邀功
  • 出现了问题,就说是你造成的
  • 管理混乱,团队负责人纯技术出身,完全没有学过人员管理,老板为了挽留那些老油条而给他们升职,把他们放到不恰当的管理岗位
  • 一些时候,老板给新来的人高薪,而一些确实贡献很大而且经验丰富的人,他们的待遇比新人还低
  • 一些老油条,平时你请教他们,他们要么无视你,要么有意无意地只给你片言只字,让你无从下手。他们的思维,大抵是:
    • 老子多年前就是这么过来的,你们总得辛苦一下
    • 我总不能让你快速上手,否则让我这种不勤快的人很难堪
  • 一些老油条,察觉到你对他们有威胁,诸多阻挠给小鞋穿
    • 我大学毕业第一份工作,因为我大学的时候就有工作经验,毕业后快速成长,部门经理隔三差五把我写的代码删除掉
    • 另外一家公司,我做出来的东西,在生产服务器跑,一个人先后多次把生成的数据删除掉,等我发现之后,就说:“你重新跑一下不就行了吗?”

如果你遇到这样的问题,你会怎么办?

 

大家一般的做法是:

  • 尝试反馈,如果对方不改变,就找人力资源或更高的管理层
  • 如果还没改善,走人

其实,人的性格无法改变的,即便他们表面上和你客气了,实际中还是会耍各种阴招。

英文说:If you can’t change others, change yourself。其实就是说,走人是上策。

不过,既然选择要走人,那没什么好害怕的了,把所有证据收集起来,走之前群发。

 

爆栈之旅

是否想技术水平快速提升?是否希望快速成为公司的技术骨干?

核心价值
  • 把我这10多年来所学到的知识、总结的经验、吸取的教训分享出来
  • 针对不同的学生量身定制规划学习成长路线、1对1个人指导、代码审阅等
  • 解答各种技术问题
  • 为公司提供技术解决方案

请查看本站右边的信息联系我。

版权所有

所有文章内容版权所有,任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

开发思想 – 做软件开发和转行

George Bernard Shaw(萧伯纳)在《Man and Superman》(人与超人)中的Maxims for Revolutionists《致革命者的箴言》写道:“He who can does; he who cannot, teaches.” (有能者则为,无能者则教)。

大家不要误解作者的愿意,这个名言表面上看起来是说有能力的人才能做事情,没有能力的人就只能转行去做老师了,看着是在讽刺教师这个职业。但实际上,没有明确的考证这就是作者想表达的意思。

我引用这个名言,只是想引出今天要讲的话题:作为开发人员,如果对这个职业失去了兴趣,接下来会做什么?

我之前写过长篇博文,关于《大龄码农何去何从》,我还说过,一些大学刚毕业的开发人员,去到第一个公司,被严重打击了,失去了信心。又有一些工作几年的开发人员,在一家公司呆久了,有了”开发不过如此,真实糟糕“的幻觉,也失去了动力。

我在多年打靶的过程中,见过上百个猎头/中介,碰到过几个从开发一线退下来的码农,现在转行做了”有技术背景的猎头“,这种猎头起码比剩下的95%以上的猎头靠谱,毕竟他们懂开发,知道怎么考察应聘者的技术水平。

今天,一个码农朋友跟我说,他最近在面试,昨天碰上一个懂技术的猎头,搜索了一下领英LinkedIn,之前是做高级前端开发人员。我这朋友现在主要做.NET桌面开发,最近恶补前端尤其React,用它做了个个人网站,然后希望找份前端的工作。

我跟他说:“你这样是抛弃了过去几年积累的.NET/后台经验优势,你起码应该找份全栈的,保留后台优势的前提下,可以学习实战前端”。他说:“这个猎头告诉我纯前端收入更高。”

不过他后来又告诉我:”其实我最近研究React等前端,过度透支了我的兴趣,我现在看着前端就想吐了。我想我是做后台好些,不过我还是想学/做些不一样的东西。”

在某公司,一个码农离职,说:“这公司只能学到C#,世界那么大,我应该去学学别的语言。” 其实这公司使用很多的其它技术,Windows/Linux,桌面/Web/嵌入式,软件/硬件,.NET/Java,不一而足。其实很多时候,要么你没有去追求,要么你因为局限于某个项目/小组的所需要的技术。

想知道为什么我这么多年来能掌握那么多种技术,不仅仅是广度,还有深度,达到我所说的“爆栈”吗?

 

爆栈之旅

是否想技术水平快速提升?是否希望快速成为公司的技术骨干?

核心价值
  • 把我这10多年来所学到的知识、总结的经验、吸取的教训分享出来
  • 针对不同的学生量身定制规划学习成长路线、1对1个人指导、代码审阅等
  • 解答各种技术问题
  • 为公司提供技术解决方案

请查看本站右边的信息联系我。

版权所有

所有文章内容版权所有,任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

开发思想 – 代码质量的追求

之前我们在 开发思想 – 代码的4重:重质、重构、重视和重用 说过代码质量的重要性。

代码质量,不仅仅是性能,还有可读性、可维护性等等各种-ibility“性”。

一个开发人员今天说他们公司质量追求情况悲喜交织,譬如有些强人追求代内联优化(inlining),包括C#和SQL(没想到吧?),然而有些码农舍本逐末,譬如推崇jQuery而反对native方法,代码审查不给native过,这开发人员就说不服跑个分,性能一比较差jQuery差5倍,然后那个做审查的就不吭声了。

还有网友问,代码的可读性和性能,哪个重要?我觉得:没有定律,但有些时候可以两全其美。如果不能鱼与熊掌兼得,那可以根据实际需要而追求之,如果没有特别要求,那可以两者平衡取舍。

举个例子,我们为了追求代码可读性,不考虑性能,那就是舍本逐末,比较产品的使用者是用户,用户不满意性能(体验差),那造成损失是不可避免的。

同理,如果我们写的是天书一样的代码,犹如自带混淆器,那如果这个逻辑有问题,相信别人也无法修改。

爆栈之旅

是否想技术水平快速提升?是否希望快速成为公司的技术骨干?

核心价值
  • 把我这10多年来所学到的知识、总结的经验、吸取的教训分享出来
  • 针对不同的学生量身定制规划学习成长路线、1对1个人指导、代码审阅等
  • 解答各种技术问题
  • 为公司提供技术解决方案

请查看本站右边的信息联系我。

版权所有

所有文章内容版权所有,任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

开发思想 – 阿姆达尔定律、高德纳定律、Dane North定律

阿姆达尔定律 Amdahl’s law / Amdahl’s argument

计算机系统运行的最大瓶颈,是那些不能并行计算的部分。

一般为了提高性能,我们会先采用多线程,这样可以实现并行计算。如果这个不满足需求,我们可能会支持多个进程。不管哪个,我们都要解决一个无法避免的问题:数据同步。而多进程的实现,还需要指出进程间通信(IPC),一般可以用命名管道(named pipe)、消息(windows message)、socket (没错,本机也可以用套接字)、内存映射文件(memory mapped file – MMF)等等。

如果多进程还不能解决问题,我们可以考虑分布式计算,这个时候数据同步/通信可以用scoket、队列(如Kafka等)、HTTP服务等。

不管哪种实现,性能瓶颈应该是整个业务流程中不支持并行处理的模块/功能。

高德纳定律 Knuth’s law (Donald Knuth)

Premature optimization is the root of all evils,过早的优化是万恶之源。

我之前说过不应该过度设计(开发思想 – KISS/DRY、奥卡姆剃刀、重复发明轮子、过度工程/设计/YANGNI),因为你现在不需要、短期也不需要。

但是,有些开发人员就利用这个做借口,懒于设计,最后做出一个刚上线就已经无法应付需求的产品,这是因为这些开发人员没有理解高德纳的原意。他老人家想说表达大家不要“过早”优化。那什么是“过早”呢?

举个例子,某个创业公司,技术负责人要高大上,所使用的技术都是业界最先进最强大的,技术团队折腾了2年,产品还没有出来,公司资金链断了,倒闭了。这是过度设计,他们臆想客户在短期内有这个需求。

再举个例子,某个系统的一个模块,设计人员考虑到可能用户量会很大,所以做成分布式的,用上了非常复杂的架构,上线之后,用户量远没有想象中的多,单机就能轻松应付所有请求。

实际上应该怎么样做?多次迭代,看菜吃饭。技术架构应该是不断变化的。

Dane North’s law

每一个决定都是有代价的。

大家应该知道计算机优化的2大常用办法:

  • 用空间换时间:譬如缓存
  • 用时间换空间:譬如压缩

每个功能都有其侧重点,譬如追求性能,或者追求内存/存储空间最小化,很多时候,我们只能在这两者之间做取舍、平衡。

爆栈之旅

是否想技术水平快速提升?是否希望快速成为公司的技术骨干?

核心价值
  • 把我这10多年来所学到的知识、总结的经验、吸取的教训分享出来
  • 针对不同的学生量身定制规划学习成长路线、1对1个人指导、代码审阅等
  • 解答各种技术问题
  • 为公司提供技术解决方案

请查看本站右边的信息联系我。

版权所有

所有文章内容版权所有,任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

爆栈之旅-.NET- C# – 中级语法

目录

这是爆栈之旅的1对1私人定制授课的第十三讲,视频+讲义+问答+测试+代码审查等等。

 

是否想技术水平快速提升?是否希望快速成为公司的技术骨干?

核心价值
  • 把我这10多年来所学到的知识、总结的经验、吸取的教训分享出来
  • 针对不同的学生量身定制规划学习成长路线、1对1个人指导、代码审阅等
  • 解答各种技术问题
  • 为公司提供技术解决方案

请查看本站右边的信息联系我。

版权所有

所有文章内容版权所有,任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

开发思想 – 墨菲定律、琐碎定律、散弹枪法

霰弹枪法

在开发过程中,有多少次,你遇到很难缠的问题,百思不得其解,因为没有正确的思路,所以,使用霰弹枪法,到处放一枪,这里修改一下,不行,再在那里修改一下,还是不行,继续换个地方打一枪。

有一句英文谚语:“当你是是一个锤子,看见啥都是钉子(nail)”,但是你迟早会砸到自己的拇指(thumb-“nail”)。同理,当你没有一个明确的目标,到处放枪,迟早要射到自己脚(shoot yourself in the foot)。

所以你们会发现有一些开发人员经常性处于一种思考状态:

  • 咦,为什么这个不工作?
  • 咦,为什么这个又工作了?

 

Work, Programmer Humor, and Why: It doesn't work.... why? why?

那究竟应该怎么做?首先,捋清思路,明确业务逻辑/流程,从到到尾走一边,看看问题在哪个端/层出现,再逐步缩小范围,直到定位具体的代码行。具体的例子我再写文章。

墨菲定律

该发生的事情,不管几率多低,迟早会发生。

开发过程中,我们会遇到一些难题,解决不了,譬如某种异常,我们中有些开发人员会尝试把这个异常吞掉,以为这样就天下太平了,但事实上问题在不断产生,造成或大或小的损失。

尽管我们目前无法把这个问题的根本原因找到,解决不了,那最起码的,需要把错误自动记录下来,尝试对堆栈和运行时状态、业务值等中找到规律,从而帮助我们找到问题根源。

帕金森琐碎定理

核发电厂的设计中,包括核反应堆和停车场,其中对停车场的设计,大家都很热衷地讨论给建议,但对核反应堆的设计,大家都不发声了。

这个定律,是说开发过程中,一些重要的架构,懂的人不多,所以也不会多少人敢参与讨论,相反,一些界面的元素摆放、大小、颜色等,大家会议论纷纷。

在代码审查(code review)过程中,假如改动只有10行代码,我们可能会挑出10个问题来,但是如果改动有5000行,我们看着看着就累了,所以直接就让过了,挑不出问题。

爆栈之旅

是否想技术水平快速提升?是否希望快速成为公司的技术骨干?

核心价值
  • 把我这10多年来所学到的知识、总结的经验、吸取的教训分享出来
  • 针对不同的学生量身定制规划学习成长路线、1对1个人指导、代码审阅等
  • 解答各种技术问题
  • 为公司提供技术解决方案

请查看本站右边的信息联系我。

版权所有

所有文章内容版权所有,任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。