• 如何成为一位失败的程序员
  • 发布于 2个月前
  • 104 热度
    0 评论
  • 崔天临
  • 0 粉丝 5 篇博客
  •   
每个人都有自己成长的节奏,对于成功的定义也是因人而异,在我们迈向所谓「成功」之前,我们应该瞭解何谓「失败」。

在穷查理的普通知识一书提到,查理・蒙格最喜爱的一个美国老谚语:「我只想知道我将来会死在什麽地方,这样我就可以永远不去那裡」,听起来很粗浅,但其实指的是你应该歼灭那些本就不该做的事,而只做该做的事情,也就是所谓的「不用试图成为聪明人,而是持续试图别变成蠢货」。

那麽身为软体工程师,在职业生涯的发展中,怎麽样算是失败呢?

也许是,你以为资历十年的工程师,其实是一年的经验重複了十次。

所以,这篇文章会说明要如何掌握诀窍的一步一步成为「失败」工程师。

会动就好
coding 只要有一台电脑,搭配对程式语言瞭解的判断式就可以开始撰写了,这就和写文章一样,一支笔一张纸就可以写出能够表达的内容,然而文章的内容有的人可以写出优雅的句子,也有人会写出只有自己能懂得句子,写程式也是一样,并不是每个人都学习过如何「表达的优雅」。

所以有一类的工程师以 Get things done 为基准,只要能完成任务、完成老闆的商业逻辑,程式码长怎样不是很重要,反正其他的协作者只要花时间一定能看懂我的 code,看不懂是他能力不好。

总是 Work around 的诀窍
不要学习任何 Best Practice
不要学习任何 Design Pattern
逻辑採瀑布式撰写,不需要抽象
不遵循任何 Convention
通常养成 Work around 的习惯之后,进阶发展的技能就是 Hack around,一开始可能只是把东西写死,但后来可能用各种奇淫技巧将程式尽可能搞到没人看的懂得 Magic

自我风格命名
Naming is hard.

我们都知道面对各种的业务需求,在程式开发中的命名总是令人难以决定。

自我风格的命名不需要在乎其他协作者的感受,以自己键盘少敲为主,也不在乎什麽编辑器有自动补全。

让命名失败的诀窍
使用自己发明的简写
用自己懂的搞笑梗当作命名
绝对简写的命名

@ano = Announcement.last

# 但愿所有开发者都能一眼看懂 @ano 是什麽
wd = Withdrawl.recent
# wd 是什麽?除鏽剂?
第一眼绝对看不懂的模组命名

module Kimoji
...
end

# 嗯,你 kimoji 了我并没有
无法瞭解的使用者权限命名

User.last.rule
# Super saiyan <== 可以解释一下超级赛亚人是什麽权限吗 Orz?
用力替自己造轮子
在做选用套件时,往往会有技术评估,评估这个套件我们是不是要加进来做为使用,是否有社群维护来支持日后的升级?是否符合我们商业逻辑所需?

我们应该自己写还是用别人写好的?

成为造轮子高手的诀窍
无论如何,自己写
相信自己写的东西很棒,不需要写 Unit test
如果开源的专案有漏洞,我们不会被影响
这样一来,製造了更多的工作,成为了不可取代的造轮子工程师

喜欢手动胜于自动
懒惰且有能力的工程师会将日常重複的工作尝试往自动化或是更有效率的方向发展,而有毅力的失败工程师更乐于将经常性的工作视为日常任务。

成为手动王的诀窍
能手动 key 指令就不写 script
能手动翻 Log 就不用 Error Tracking Service
就算团队框架已经使用 ORM,仍坚持一字一字敲出纯 SQL
能一个字一个字打就不用自动补全
有十台机器要装环境,能手动装机,就绝不用 devops 工具
总是给意见不给建议
在讨论或是 Code review 时,总是给「意见」而不是「建议」

成为意见小霸王的诀窍
使用主词都是「你」怎样怎样,或是「我」怎样怎样,不许用「我建议」当作开头
提供自己未经求证的幻想理由要求他人需要按照我的意思
宁愿百处写不愿一处收
当我们在专案内已经四处看到重複的程式码或逻辑,当我们要再次写出一样或类似的东西时,我们不需要抽象或整理。

只要继续 Copy paste 就可以了,绝对不要 refactor,到时候有 Bug 坏了的话算在我头上怎麽办。

到处写的诀窍
不需要遵循 Don’t repeat yourself,重複十次也很好,正所谓数大就是美。
一试成主顾 Try Error Coder
写不出来就一个一个尝试,反正语法兜一兜结果出来是对的就可以了。

不需要瞭解自己的 code 是怎麽写出来的,只要知道可以动就好。

成为 Try Error Coder 的诀窍
不读 API 用法
写 code 前不先思考逻辑,而是直接拼凑
上网直接 copy 范例,改看看能不能符合需求
OK 绷万事都 OK
当发现有 Bug 时,直接在该处掩盖问题,像是把 OK 绷贴起来一样。

来一个问题修一次,来十个问题修十次,不需思考原因或改善架构的问题,只要能把程式弄到能够正常运行就可以了,有没有 Side Effect 也不是很重要。

成为 OK 绷王的诀窍
不需瞭解 Bug root cause
使用隐讳写法,例如直接随便包一个 Error exception 处理掉
有 Bug 直接进 DB 改资料,反正 application 不会再喷错就好
技术才是一切
在公司实现业务逻辑时在乎技术细节高过于一切的想法,从不认为使用者角度重要,而以技术实现难度取决于是否实作。

成为技术王的诀窍
不需瞭解使用者或产品
反正干的出来或是能用很潮的技术解决就行
没有业务视角,只要有技术视角就行
没时间写测试
时间就是金钱,反正我没有很多金钱所以不写测试,因为写测试无法直接带来好处。

如果有手动没测到的 Bug,修就好了大惊小怪什麽,爆一个修一个这是负责任的行为。

成为炸弹魔的诀窍
绝对的认为测试是 QA 的责任
Code 手动测过几遍就可以了,不需要自动化测试
霸王硬上弓
Git 推 Code 默认加 -f,不开分支直推 Master,如果衝突了就是删掉你的部分,或是留给你解。

任何和团队有关的操作只要我自己知道就可以了,其他人自己看 Log 或是通灵应该会知道的。

成为小霸王的诀窍
Commit 直推 Master 不要浪费时间去开 PR
调整了机器上的某个设定调完自己知道就好,绝对不可以告诉其他同事
平行时空旅人
绝不参加社群,不和社群上的人有来往,不需要和其他人讨论有关开发、设计的大小事,这样就不会遇到比自己还强的人,只要自己认为对就是对。

成为时空旅人的诀窍
禁止参加技术会议
禁止参加 Meetup

禁止和自己不认识的人讨论程式开发相关问题


小结
不怕一时的失败,只怕日积月累到已和失败习惯共存,想得到失败的诀窍就是从不检讨自己,不从自己或他人的失败经验中学习,经验是宝贵的,我们都希望自己能够持续胜利和避免恶果。

我们都想成为更好的工程师(应该吧?还是其实你觉得还好 XD?),在此之前我们也应该要懂得如何成为他人或自己眼中的失败工程师,毕竟知己知彼百战百胜,想知道怎麽走到成功就要先知道怎麽达到失败。

就我认知而言,我认为 coding 是一个没有极限的职业,本文的例子是在漫漫开发道路上听过遇过见过甚至是回想起以前的自己所蒐集的案例,希望在未来的日子我们都能警惕自己避免掉坑,并且不断的精进自己。
用户评论