技术人生的职场众生相 – 十多年的经验与心得 – 之二 – 技术与质量

系列目录

 

技术与质量

学习

只为一家公司卖命一辈子的,少数。即便只为一家公司干活,始终会有产品改进甚至更新换代的一刻,不管是用户量上去了,还是用户需求变更了,那总要学习新技术。一些公司,系统多年不改进,员工就无欲无求了。等离开公司的一刻,才发现自己与社会脱节了,这种如温水煮蛙,所以早就了很多养老心态的老油条 。

公司C,一个资深码农,离职之前,考高级程序员证,恶补,拿到证之后,离职了。

我不是喜鹊码农(The Magpie Developer),不贪新厌旧,确实太多东西需要学,数据量太大了,每天太多东西可以学,时间不够。举个例子,基本的日常使用的工具,如开发工具,譬如Visual Studio,即便你每天用,很多有用的东西我就是没留意,举个栗子:你知道怎么快速复制、剪切、删除整行代码吗?删除一个词呢?再举个粒子,SSMS(SQL Server Management Studio)里面,怎么快速查看一个对象的相关信息,如一个表,显示所有字段、主键、索引、约束等等?

最近看越来越多的网络资源,一些要收费,如一个网站提供了专业面试国际大公司的一对一指导服务,全程真题,还有全球20多个著名Web2.0公司的系统设计详解,也就几十刀,值得买。

看过很多技术文章,一些网站追求一些非常入门的内容,譬如怎么做个多级菜单,动画效果,等等,放在首页,而一些干货文章却被忽视了,悲哀。

大部分码农都只擅长一种技术,所以选择的时候应该选择一种不容易被淘汰的技术(中期还是主流的),譬如.net,现在各大平台都能用而且生命力很强,在上升阶段。前端,脏乱差,但学好JavaScript不愁吃穿,围绕js的各种框架可以学一下主流的。

技术是相通的,不同的技术栈,技术思想是相仿甚至一样的,所谓一理通百理明,所以,有全栈的开发人员,从Web前端一直到后台、数据存储,还有所有之间的技术如安全、日志、队列等等。

即便不睡觉,也不够时间学习可以学的东西。所以,只能挑食,笼统地学一下大部分新技术,最关键核心的,可以深入学一下。

技术选择

前端、后台、数据存储,都有乱象。

前端尤其乱,对日新月异的那些前端技术无力吐槽,简单来说,就是脏乱差,可惜,技术负责人,没有把好关,选择了错误的技术。

技术选型,决定因素很多,譬如技术带头人,譬如技术储备,公司现有情况,等等。著名云程序日志记录提供商raygun,几个月之前扔掉node.js改用.net core,性能提升20倍。但就是有些公司的技术人为了反对而反对,选择一些不切实际的解决方案[摊手] 。

举个栗子,譬如SOA家的微服务的设计与使用。网上诸多最佳实践,在多数公司里面都没有、也不会实现 ,不管是决策者、财力资源、还是人力资源等限制 。大家审视一下现在公司的系统, 你连现有系统的的基本的模块化做到了吗?如果没有,凭啥你就觉连模块化就做不到就能把微服务做好? 甭想微服务了。微服务不大适合初创或小公司,Martin Fowler说过,上微服务需要现有的流程、监控、快速发布基础, 而且发布的成本和复杂度比单系统服务高,服务间的网络数据交换成本额外高,本地开发测试复杂度和成本也高。 遇到异常,还是看业务,一些transactional的该怎么样就怎么样,一般流程化操作,如用sagas,容易导致死流程,这种怎么监控和解决具体问题具体分析。一般做法是有机制重试n次后还不行就escalate到IT,还有日志这块也是很多坑的。

继续这个栗子,微服务的基础,用公有云的话,论灵活性,那就azure function;论scalability,还是azure batch吊;论可控性,还是service fabric强;论简单易用陪流程,还是azure logicapps好;论业界认受度,还是Amazon家的AWS λ 吊。

MYOB是澳洲著名的老牌会计系统,直到几年前他们的解决方案还是Windows桌面程序,客户需要用citrix远程进去跑的。。。anyway,原来这公司的名字是Mind Your Own Business的缩写。

公司C,当年O/RM流行没多久,entity framework还没有出现,我们用的一个商业的,性能很烂,批量生成数据的时候整个界面无法响应(当年我们都不懂异步处理)。

公司C,微软推出了和macromedia(还没有被Adobe收购)的flash对抗的Silverlight,设计思路是好的,性能都比flash好,漏洞远没flash多,技术负责人说,我们下一版本要用Silverlight实现,当时他说:“我们要做银光版!”

爆栈

最近的争论,懂一个Web前端框架,然后试图搞定后台和数据存储,还有之间存在的各种数据交换、流程处理、安全、扩展性、潜在性能问题(各级cache、sharding)等等,很难。因为每个都有太多太多的坑,不把这些坑踩过就说可以搞定全端,有点难度啊。

我之前反复强调我不仅仅是全栈,我还是#爆栈#。技术体系,需要时间去构建,融会贯通。听过、会写Hello Kitty、懂用、掌握和精通是不同的,需要多读多动手,把坑踩了,跌得越痛,认识越深入。

上大学的时候,导师用跟我们说过赫胥黎的名言:“learn something of everything, learn everything of something” (尽可能广泛地涉猎各门学问,并且尽可能深入地择一钻研)。我们可以全栈,但起码有一样是研究的特别通透的。

质量

在编程的时候,我们一定要想象一下,以后维护我们自己的代码的那个人会成为一个暴力的精神病人,并且,他还知道我们住在哪里。

MVP,对体育运动来说,是most valuable player(最有价值运动员/球员);对开发人员来说,是most valuable professional (最有价值专家);对产品开发来说,是minimum viable product (最简可行产品)。一些公司开发系统,一开始就勾画宏大的愿景,几个月甚至几年之后,产品还是没有见踪影。相反,一些公司追求最小化的可行产品,每个版本只发布一个新功能。

产品质量、功能和时间这三者里是互斥的。要质量和功能,那么时间就得延长;追求质量和时间,那么功能就要砍;赶时间和功能,那么质量必然下降。

看了很多公司的系统,就像在吃苍蝇。

大家看过少林足球,吴孟达样子和口吻:“代码,不是这样写的!”

怎么给垃圾系统擦屁股:你被扔了一坨热气腾腾的烂代码,幸运的话只有几百万行,没有注释,仅可能有的就是早已过时的文档,写这些代码的烂码农早已去逍遥快活。

公司X,第一天,下班了,累瘫,腰酸背痛。首两周都是各个部门的不同人来介绍公司、各种业务、各个系统,找了几个机会跟开发团队聊了一下,顺手看了一下他们的开发,具体就不谈了。

公司业务成功,和开发不是正相关 。很特别是那些行业系统,只要销售人员足够强,不管多烂的系统都可以大卖,所以,很多公司的销售人员收入很高。

公司E,硬度公司,公司绝大部分是硬度菊苣,部门都是硬度码农,除了我。主系统登录页,老板要放一个配合公司LOGO的动画,硬度菊苣就设计了个gif动画,彩虹波浪线不断翻滚,但页面加载很慢,整个窗口响应也很差,鼠标挪动都有问题,我一查,原来那个gif大小是全屏幕的,超过5兆。。。

公司B,客户端用OLEDB从Visual FoxPro读到DataTable,序列化到JSON,压缩,存到Azure BLOB,然后写相关记录到Azure Service Bus Queue,服务器端Service Bus接收到信息,取相关BLOB,解压,反序列化,再Bulk Copy到Azure SQL Server的临时表,再转换格式化各字段读关联表,最终到达目标表。。。蛋疼的感觉?

公司B,巴西码农,为了格式化法国人名常见的组合名(就是名字中间有-、·、空格等符号后面第一个字母要大写),他洋洋洒洒写了80多行代码,逐个字母替换,而且为了应付空格,又重复了一遍。。。。

公司B, 又优化另一报表,初步加了索引重构逻辑后,从原来超时到现在1分26秒,再分析,发现另外一个瓶颈是引用了这函数,报表先调用一个主的人名格式化函数,这函数再多次调用上述那函数,重构后,只需要6秒。

公司B,挺无语的,部门一码农,一个流量值(字节)要格式化显示成兆,他直接/(1024*1024),根本不明白那些小数就不能显示了,然后呢,还Round两位小数,问和尚借梳子啊。

公司B,数据库那块,简单地说,就是数据库规范里面的第1/2/3范式都完美地忽略了 。。。前端界面对一些字段没有做校验,所以系统跑的时候各种爆,譬如期望是数值但里面有各种诡异字符,期望是邮箱地址但是文字。。。日志那块,每个方法执行都做一下开始/结束日志,随便点几下界面,几百K的日志内容[摊手]

我发现,懒/烂码农,很喜欢复制粘贴。

公司S,部门一开发人员,擅长复制粘贴代码,原本几百行的代码,硬生生搞成1万多行。他说:“我写代码,疯起来,我自己都害怕!”某天,这个码农在看自己的代码的时候,迷茫了,看不懂了,代码逻辑流程太乱。所以,他只能打开Visio,逐步把逻辑画出来了。。。[摊手]

公司S,系统是asp.net webform + vb.net + 大量第三方重量级UI控件,前端、后台和数据库性能都很烂,根本不是SaaS,也不支持多服务器,各种各样的错误。我踌躇满志地来到公司,第一天就跟大家说:“做开发这么多年,烂代码我看惯了,所以大家放心,不管多烂的代码我都可以重构改造的”,3个月后,我歇斯底里地指着屏幕上的烂代码,狂叫道:“你们这样写代码是不人道的!!!”

公司S,系统各种问题,性能表现差强人意。其中一个表现是,越越来越慢,譬如同一个功能,所以参数一样,今天跑5秒,后天6秒,大后天7秒这样。。。最后发现还是跟我之前优化的日志有关,虽然改成异步批处理,但是日志基于文件,每个最大2M,不断翻滚,日志文件名逻辑是扫描所有文件来取下一个文件名。

公司S,一天,分析了一下数据库,一个客户7天做了150万次数据库读操作,约读取了200G数据,加上前端那些Web Form冗余HTML,实际从服务器上走出的数据是很夸张的(按我司的规模),数据库请求延迟更厉害,一个客户每次请求都要等0.2秒。

公司S,存在多个业务逻辑错误问题。客户反映数据有问题,部门的同事分析数据和代码,最后发现关键逻辑是读的配置文件,而这个配置是应该按具体客户的设置来的,但变量写成了static。

公司S,系统运行时大量日志生成,同步写入日志文件,我改成了异步。还有,每个页面加载完成,都记录一下用户的IP、加载开始时间、加载结束时间等信息,也是同步的,加上其它业务逻辑写得不行,所以很忙,我也改成了异步,定时批量写入日志。

一些公司的码农,不把警告当警告,完全无视之。

公司S,主系统,编译的时候,显示254个警告,不能再显示更多了。

公司S,下班前,每周五全员工公司例会中,一个IT部的同事问我:“Wilson,你们部门是否会把机器学习应用起来”,我心想:“你们连数据仓库都没做,所谓商业智能这只是做了些基本报表,数据量也不是很大,我以前随便处理都是几十亿起跳的,还想机器学习???” 然而,我还是老实说:“大家知道Google alphago吗?就是最近打败了最牛的围棋手的人工智能系统?”。没人回答。我继续“我们写程序,是直接解决问题。机器学习,是我们写一个逻辑,让机器其去利用现有的数据进行分析找出最优方案,这是非直接解决问题,”

数据从用户在界面输入开始生命周期,经过传输到达网站,经过处理(譬如ETL),再存到数据库,后续还可能有数据仓库二次处理等,最后数据失效被删除。这中间很多事情需要做,但,最重要的第一步,是确保用户输入是校验过的合法数据,否则进入系统后造成连锁反应,修复成本太高。

我服务过的很多公司,界面输入缺乏基本的校验,譬如长度,用户输入长一点就爆了。邮件格式也不判断,系统发送邮件的时候各种爆。

公司S,系统设计有问题,实现有问题,运作有问题。拿各种通知客户的定期报表邮件,地址完全不校验,同一个客户出现几十种的邮箱域名,譬如正确的是foo.com.au,实际出现:foo
coma.u, foo.com,foa.com.au, foo.com…..,一些明显是不合法的格式,一些是不存在的域名,等等,发送的时候也不校验[摊手]

公司X,系统各种安全漏洞,SQL注入轻而易举。

遇到过各种奇葩软件/系统设计,譬如LinkedIn Android版,经常告诉你无法发送内容,不告诉你为什么,之前打的长长内容都丢了,根本草稿等临存功能。一些银行的app,允许你增加、减少每日转账额度,但根本不告诉你要增加到多少或者减少到多少[摊手]。

公司S,现有的系统10多年前开始写的,技术陈腐,其中一个功能是根据不同客户不同产品从可自定义模板那里动态生成表单,这个功能是用的第三方的,本来不复杂,但随着业务发展,现在单纯渲染界面的代码行超过10,000。我在用angular改造,目前代码行200,可以显示了,接下来就是做一些交互[摊手] 。

公司S,Web系统性能差,有几个原因,其中一个,是HTTP压缩都没有启用,页面/资源加载都要用较长时间,我发现之后,顺手启用了[摊手]

公司K,系统的数据库设计很多奇葩的事情,就命名这块就看不下,用户标识(UserId)这个,同一个数据库里有以下各种形式:UserId、UserID、user_id、userid、iduser、USERID、id_user等,而且大部分是同一个人搞的 。

公司E,隔三差五发现公司印度菊苣们写的代码好多坑,譬如前端js肯定就不判断对象是否null,直接取属性,然后后续的代码都无法跑了。后端的代码更奇葩,直接try/catch抑制错误(catch无任何逻辑),今天发现一功能无法跑,分析后发现,数据库表字段类型是nvarchar,代码里定义是int,菊苣不解决抑制错误就完了

这么多年来,各种平台,看见过各种软件的奇葩实现。

公司Z,现在的业务系统,一个复杂的申请流程,所有数据都暂时保存到cookies,今天终于爆了,客户的一个下单JSON后超过4k,boooom!

写烂代码的人多用旧版本的语言,这样他们就能名正言顺地不用新版本的语法糖来精简代码。譬如c♯的自动属性,expression body、LINQ等,他们都不会用。更恶心的是重新发明更烂的轮子,数值TryParse、DayOfWeek等重搞,最恶心的是压制错误:一个对象几十个属性,不判断null,几十个try/catch逐个属性轮 。

公司A,数据库这块,因为某GIS产品Web服务的特点,把数据库分割为:每个客户3个数据库,然后呢。。。然后服务器就几十个数据库。。。。其实做到一个数据库是没有什么难度的。。。。可以预见以后各种血泪 。

公司A, 开发这块。。。之前弄过Windows Mobile,后来用Sharepoint(怨念!) + Silverlight(怨念!!)。。。。。加上某GIS产品+.NET插件(啊啊啊),现在在上马#WPF#(怨念!!!),然后准备招聘iOS开发人员和Android开发人员(啊啊啊啊。。。

公司A, 做的产品主要是基于GIS的产品,给服务人员提供地理任务标注/指示,然后开展工作。然后呢。。。。#没有自己写的服务器端#,#不直接存取数据库#,完全用某GIS产品提供的Web服务。。。。然后性能各种爆。。。。。。。

公司A,是典型的传统使用微软产品的企业,IT/基础设施这块都是AD/exchange server/SCCM等,最近弄了个JSP写的helpdesk系统,所有东西都往那里扔,连新产品/新项目/改进都放那里,还包括bug管理。。。

公司B, 系统是Web应用,引用了大量的第三方Web前端代码,超过2500个JavaScript、CSS文件。。。。每次发布要等好久好久。。。其实绝大部分都不需要用到,就是硬度码农买1送10地狂塞进去,而且grunt build那套也不用,打开首页的时间都够我去找菲律宾妹子了

公司B, 相比上一家公司,这公司的产品状况要好很多(尽管很多问题)。上一家公司的产品我接手之前只是基于第三方产品做扩展,完全不是自主知识产权,午饭商业化,我从头写,大半年完成,比第三方产品还好很多功能多很多。好歹现在的直接自主产权,技术较新,但坑多。

公司B, 这公司是和这行业的领先者之一合股搞的SaaS解决方案,软件+硬件结合,市场很大,不过,合股公司总部就是仓库,大家绕着会议桌开发,旁边的沙发坐了一堆五湖四海的合股公司员工吃各种风味的午饭。。。新公司的工作场所还在装修,隔壁,其实还是仓库改造。。。

公司B, 需要使用的第三方系统,其市场占有率超过50%,但用的Visual FoxPro开发。。。。。。。。因为官方没提供API,我们的玩法是直接逆向工程数据结构然后自行山寨业务逻辑玩弄数据。。。。。、、

公司B, 8个硬度码农(已经炒掉5个)做出来的web系统,后台ASP.NET MVC+nhibernate。。。每个controller都automapper create一次map。。。还直接数据CRUD。。。前端angularjs,每个controller直接http req。。。各种null ref问题。。。

公司A, 我发现了,代码的质量很差,主要原因是:大量复制粘贴、反复操作(譬如反复的获取同一个值做而不是读一次做变量)、冗余的循环、没有使用较新的语法糖(譬如lambda)而自行弄10多行代码实现一行LINQ搞定的、很多情况都没考虑大小写敏感,强行catch异常而不是判断

公司A, 入职一个半月,发现前任挖了很多很大的坑,一些短期内无法填,一些长期也无法填,怎么办?逐步填,一天填一个呗。

公司A, 开发,是典型的四无:无设计、无文档、无规范、无流程,无法无天(噢,五无了)。数据库设计乱七八糟,性能极渣,处理几百万数据的ETL也要跑几个小时,还会内存耗尽(32G)。。。。代码那个更无法吐槽。

公司A, 产品用的C#开发,Visual Studio做IDE,代码管理用的SVN,陈腐得很。产品开发还是waterfall,新版本发布用windows登录触发复制更新,无力吐槽。。。给CIO建议,改用Visual Studio Online,搭配scrum,项目管理/代码控制关联起来,这只是第一步,还有很多需要做。

公司A, 虽然不同州不同客户不同的业务需求,但绝大部分业务/逻辑是一样的,完全可以把基础部分标准化,但是呢,现在的做法是每个客户单独有3个数据库。。。每次基础功能/逻辑更新,就要更新几十个数据库。。。

公司A, 数据库的更新允许通过sharepoint修改任意记录,然后呢,没有后台逻辑封装,然后呢,一些表大量触发器,一些触发器几百行代码。。。

公司A,产品的日常数据查看/修改,除了专门的管理工具/客户端,还可以通过sharepoint来,有一个自定义的数据列表WebPart来绑定一个数据源,还有一个数据编辑WebPart,根据PK来更新数据,竟然允许直接修改任意记录。。。。。没有后台逻辑,没有存储过程。。。我靠

公司A, 系统的部分数据导出和通知是用的python脚本,质量放一边(容错、复制/粘贴等),产品环境根本就没成功跑动过,一个月多月了,没有人去排错。。。今天开会,我一下子就找到问题了,print组合输出某数据库值null。。

公司S,审查代码,发现多个地方都出现一个诡异的逻辑,文件输出的时候,定义编码是GB2312,我跟写代码的码农说:“可是,咱们不在中国啊[摊手],而且,那可是10多年前的做法啊[捂脸] 。

版权所有

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

技术人生的职场众生相 – 十多年的经验与心得 – 之一 – 协作与交流

系列目录

前言

我是个码农,在职场干了多年,在超过10个公司服务过,遇到过各种怪现状,拍案惊奇葩,不吐不快,太想写篇文章吐槽一下。

这篇文章汇集了我10多年来的工作中遇到的各种经历,总结的心得,分别讨论了团队与协作(同事/领导/客户的交流)、技术与质量(学习、技术选择、质量)、职业与事业(现实、追求、老油条、职业道德、典故、事业/经验)、找工作(猎头/中介、应聘、简历、面试别人)、辞职(原因/理由、信任)等,干货满满的,里面还夹带了我的很多秘密和典故,如果你认真看,会回来找我赞的!!!

如果你非要叫我跑龙套码农,请不要在前面加个死字,谢谢。

我在中国读的大学,工作了7年之后,移民到了澳洲,文中的经历,一部分是中国的,剩下的都是在澳洲遇到的。

下面的文章夹杂了不少英文,那是因为这些文字都是我在澳洲写的,习惯而已,不是你们想象中的所谓装逼,谢谢。

本文是我的个人经历和意见,请取滤网三钱,温水煎,和着服用,谢谢。

协作与交流

入职

不管你在以前多厉害,有多丰富的经验,去到新公司,都要重新学习,撇开业务逻辑,我们还需要学新的编码规范(不管你是否认同)、开发流程与守则、工具等等,更耗时的,是理解他们的开发框架,每个公司都有自己的一套(很多可能重复发明了了轮子)。

心态很重要,没有端正心态,很容易造成失衡。一些人一夜暴富(如中奖),然后大肆挥霍,最后比暴富前更穷困潦倒。入职新公司,可以放低身段,毕竟你掌握的技术是一回事,学习公司各种文化、流程、规范、业务逻辑等等都要花一段时间,不能一蹴而就,否则落差太大,事与愿违,如牛入泥潭,强烈的无力感。

一张厕纸,都有它的作用。每个技术公司都有过人之处,我们要关注的,不是那些不行的地方(有待后续解决),而是寻找那些有营养的干货,学习之,提高自己。20/80法则,20%的公司牛,那就算差的公司里,也有20%的人尤为突出的,要向他们学习,看他们写的高质量代码。

从一个公司角度来看,评估员工的表现,不是看他以前多厉害,经验多丰富,而是看现在为公司的贡献。所以,一些时候出现的情况是:“我自认水平很好,为什么公司给我的回报没有我想象中那么多?”

去到一个新公司,心态要摆好,低头做人,努力学习。或许,有一些同事,觉得你空降过来,不会持有热烈欢迎的态度,所以,做好本分的事情,不需要奉承别人,也更加不要得罪别人,平常心看待。

每去到一家公司,我会尝试笑着面对每个遇到的人,甚至说一声Hi,如果对方没兴趣,那没关系,我不会因此脸黑或者不爽。笑着面对各种问题,自己写的烂代码,含着泪也得把它重构好。

同事/领导/职场

林子大了,什么鸟都有,公司大了,什么人都有。有人的地方就有江湖,有利益的地方,就有冲突。

澳洲,跟美国一样,是移民国家,一般每家公司都有各色人种。文化的差异,语言的沟通,总会造成各种矛盾。

根据这些年来的观察,冲突一般有:1、邀功,当你辛苦干完活,别人把功劳拿走了;2、推卸责任,不是你造成的问题,别人强加于你身上;3、小圈子排挤外人。

说到底,工作就只是一份养家糊口的事情,其它都是不重要的,把这个想通了,一切都好办了。把心态摆正,把事情做好了,就行了,很多事情无法控制,当然,我们要懂得不要给别人留有藉口揪你小辫子。

每个公司都有各种问题,进新公司之前,大家习惯设想新公司怎么怎么好,自己的计划如何顺利开展,现实,往往不是如你所愿。所以,要做好最好的准备,最坏的打算。

办公室不是找朋友的地方,必须时刻提防各种办公室政治,披着羊皮的狼,是最危险的,越天真越容易中招,不大有人会踢一只死狗,枪打出头鸟,你越出色,越容易招惹是非,要混得开,低头做人很重要。

对美女来说,“天生丽质难自弃”,想突出自己把自己的优势最大化。职场,大部分人都想出人头地,努力往上爬,加薪升职。然而,事与愿违,总有“老子干得很不爽,去你大爷的!”的时候,如果你真有心有力,确实是可以去创业,不需要受各种非人的委屈。

一言蔽之,要干得爽,还是需要自己创业。

公司S,心累,现在公司部门和部门之间有严重的斗争,各自为政,根本就不是想干活的,恶心的事情很多,譬如部门老大不干活,让小弟干,小弟工作繁忙压力大就爆脾气,说话不像人样,然后部门老大就各种推卸责任,还美化之,去它大爷的 。

公司B,三个印度码农在印度,一个大胡子孟加拉国的,一个刚来澳洲两天的伊朗人,一个来了澳洲很多年但口音极重的越南人,一个还在马来西亚下个月才来报道的码农,加上来自黎巴嫩的上司,还有我,真的是联合国。

公司K,精神分裂的部门女同事,菲律宾大妈,在公司呆了18年,在CTO背后联合她的两个马来西亚小弟直接跟CTO的上司说CTO各种坏话,在CTO面前老装很友好地狂笑,对待客户是一样的做法。

公司T,当年很纯真,但已经目睹了各种利益纠纷。公司和别的公司协作做的GSP系统,一个医药销售系统,产品做得差不多了,各种纠纷,后来产品就烂尾了。

公司T,我离职,老板请大家吃酱板鸭,味道特别棒,至今难忘,离职后还和老板保持了多年的联系,每年春节还发祝贺短信,很精短,都是手写的。

工欲善其事,必先利其器。开发工具,是开发中重要的资源,公司不应该在这块上有任何吝啬。

公司S,我入职后发现开发部的机器,最老的7年了,新的也有3年老了,没改一行代码,重新编译,需要5分钟以上。跟我一起入职的有4个新同事,公司给我买的电脑是给其它同事买的3倍价钱,IT部经理一脸正经地跟我说:你丫的应该觉得庆幸拿到这么贵的电脑。但我一脸无奈地跟他说:“虽然你买的是我要求的ThinkPad,我我希望是t4xx,你却买了exxx,我才不想要呢!”。新来的项目经理对公司安排给他的新手提电脑很不满意,一大早打开的时候就已经用力噼噼啪啪了,还吐槽连HDMI接口都没有什么的,下班快走的时候还吐槽这i3 CPU配置都8年老的了。首先,讲道理,每次i3换代都有新版本,不能刻舟求剑,但是,省这几百块不值得。

客户

客户是不讲理的上帝。

你的代码写得那么烂,你的客户知道么?

公司S,做IT的同事告诉我几个真实的故事,忒搞笑了,其中一个是:客户说电脑不正常,同事远程协助,很客户说:“close all the windows”,然后客户说“done”,同事说我这里看见还没有关闭啊,客户坚持已经关闭。争论半天,最后发现客户关闭了的不是“窗口”,是“窗户”。

公司S,有一个潜在客户发来合同,要求我们的系统一年365日,100%在线,如果服务down了,按分钟赔钱[允悲]。

客户的需求,没有明确目标的居多,需要逐步引导,按优先度和难度分期实现,否则很容易烂尾。

版权所有

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