难为你们写这些了……

 

你看到的这些都是来自我的手机里,在 iOS 13 发布前夕,大家各种抓紧更新,发布版本的描述。

我最喜欢的就是 Twitter 和 YouTube 的描述,你看不看得到不重要,我改了就行。

《编程大师访谈录》书评

同发布于:https://book.douban.com/review/10510963/

 

一个有趣的事是,我在 2019 年的今天读完了这本书,来到豆瓣,赫然发现一条 2012 年的短评写着『至少十年前采访的文章,现在看来一点作用都没用』。

如果我们不谈编程这件事本身,单就书的结构而言,这也不是一本多上乘的书。作者用一个模式从头到尾,介绍被采访人是谁,描述下采访时间地点场景,采访对象穿什么衣服,进入聊天,问题也有好多重复的模板化的,然后最后加一个采访对象后来近况。千篇一律,感觉像是就在往同一个函数里传不同的参而已……

但在我看来,这无损这本书的有趣和价值。

书里的内容确实很老,那不说是上古时代,至少也是计算机历史的远古,对个人计算机来说,那也就是创世之初。打孔卡片机还仍然在采访中不时被提起,大型机仍然方兴未艾,不像今天 x86 成为了默认标配一样,那个年代大家还在做各种各样的硬件。 BASIC 虽然时不时被人给拿出来嘲讽,更强力的语言却也并不是今天我们说的这些。那是一个没有 Java ,没有 Python,更没有 JavaScript,没有互联网,卖软件还靠软盘的年代。我们今天很多人接触到这些历史是从哪里开始?我知道有很多人是从乔布斯的各类传记里才头一次听到过……恩,家酿计算机俱乐部。

很多采访对象对未来的预判在今天看来,更是错的离谱,历史从头到尾都没有和他们一部分人的想象有任何重合。这样的内容,也难怪会被认为是『现在看来一点作用都没有』。

但显然你会看的出,我并不是这么想的。

这本书并不适合新手程序员阅读,就像上面提到的,它没什么用。它提到的技术体系过时陈旧,早被历史给遗忘,因为从头到尾都是各种访谈,何况那还是一个没有互联网的世界(几乎),它采访的对象对中国的读者来说大多陌生,里面提到的软件程序毫不稀奇,今天的程序员很可能只需要拿封装好的库直接开始写增删改查,两天就给你搞定。但更可能的是,这些软件开发出来为了解决的问题本身,在今天都已经不复存在。但这些毫不影响这本书的价值。

我们今天有时候在复盘计算机和软件开发历史的时候会提到,除了写业务,我们看起来有了更高级的设计体系,更好的内存管理和回收——当然也有了更好的硬件,强大的网络,当年无论如何都想不到的分布式架构,同时我们有了更新更全面的数学理论体系支撑,但我们偶尔还会感叹,其实我们今天计算机世界的基础,还是几十年前就有了的那些。

循环还是那个循环,条件判断也还是那个条件判断。 TCP/IP 还是古早的技术,CPU+内存的概念也是那时候就有,操作系统往上一层一层的分层架构那个年代也早有了,它和我们今天使用的东西并没有什么不同——只是我们日常不再那么需要碰它。

以及我们不再用 GOTO 了。

今天的我们的大多数人写汇编会望而却步(专业领域需要没办法的是例外),可在有一段时间,汇编也是一个很高级的语言,用它写东西很舒服,就像今天的前端有 React 或者 Vue 全家桶一样。尤其是今天的我们有 GitHub 和 StackOverFlow 。

而且那个年代的程序员们都已经知道,写的函数要简短,每个功能模块都要尽可能的原子化。编程是一个脑力活动,要谋定而后动,设计比写代码本身重要。他们都凭本能知道,自己写出来的东西,用户体验很重要,不光是要有用,还要好用。

你看,这还不就是我们到今天仍然会反复提起的那些东西。

我们用 Electron 写的东西,跑在 PCI-E 的 SSD 上,用着机器的 8G 内存,其实也没见比 64k 内存下一些精巧构思的程序快到哪里去。

但我不是要比较这个,这样的比较没有意义。我们今天有更好的硬件,更好的技术体系,也确实有着远超前人的思维与视野,掌握着那个年代不敢想象的工具,有着强大的开发社区支撑,我们确实将这个社会大大的往软件化的方向推进了太多。

只是偶尔回过头来,有机会看一看那些上一辈或者上上一辈的开拓者,在没有我们今天这样的条件的情况下,他们是怎么创造东西的,可能对于今天的我们,都是会有不少启发的。

毕竟知道来的路是怎么走过来的,才能更好的把握未来去向何处。

文字发现『玉米』

今天中午煮玉米,突然发现一个事。

玉米玉米,其实就是指——看起来像玉一样的米。

从小喊到大,今天才突然意识到『玉米』原来是这么个意思哈哈哈哈哈。

30岁,白领,男性……

这样的消费者画像,没用。

“这个男性住在什么样的几线的城市?他的收入是多少?他每个月花在服装上是多少钱?孝敬父母是多少钱?存起来是多少钱?他交的朋友是什么样的朋友?他听什么样的音乐?他买什么样子的衣服?他多久会做一次采购?什么样的物品?耐久品是什么?消耗品是什么东西?等等,越详细才越好。”

这样的,有用。

『提升了性能,修复了问题』

『提升了性能,优化了一些体验。』

『修复了部分 app 崩溃的问题。』

我不是说这样不好,我知道非常多的一些公司在写类似这样的 what's new 的时候也头大,实在不知道写什么。

产品已经上线并且井然有序的运行,开发部门配合着测试、客服、销售、运营各个团队稳步推进着自己的计划,改善性能,让产品运行起来更快,更稳定,修复一个又一个的错误。但都是在计划之内的东西,要编出一些文案来实在是难为人。

写一堆『修复了XXXX 错误,解决了内存 XX 问题,不晓得有没有引入什么新的毛病』——肯定也不能这么写。

我也不知道这种 what's new 怎么写好,但我始终觉得这样,不太好。不优雅。

《凤凰项目》

  对一个做运维出身,现在做IT和项目管理的人来说,这本书某种意义上有一种明灯一样的感觉。

豆瓣上我标记了我是2017年6月18日看完的,现在是2019年7月16日,过了两年我又看了一次。感觉比上次看的时候又有不一样的感触。

不是什么特别高级的书,这本书整个讲的故事一看就是把工作过程中几乎每个IT经理都会遇到的事做了一定程度的归纳抽象,然后像一个小说一样重新讲述了一遍。我现在在当前公司已经工作3年有余,也不再需要这样一本书重新给我指导一次方法论了。但重看的时候还是觉得心有戚戚,那种明灯一样的感觉还在。

在中国的近几年的关于互联网公司或者有互联网业务相关的公司中,大致会分这么几个角色。产品经理,项目经理,研发经理,还有其他的一些title和职能,但基本上就是这几个职能的不同交叠。在传统印象中,产品经理,是属于那个根据上层意愿,设计出产品的人。研发经理,是属于拆解并带领开发团队进行技术开发的人。项目经理,是根据项目进度,工期需求,处理和协调项目开发过程中各种周边事项的人。

但实际上这样的划分很不合适,大多数公司好像也并没有这么按部就班的来处理。基本上,一个人接了一个项目,他就是项目负责人,需要了解上层领导的意志,理解商业上的整体目标,对产品的形态做出基本规划,甚至可能要亲自上场开发,并对过程中出现的各种意外情况做处理,包括设计团队,测试团队的协调,还要应付开发过程中人力和其他资源被其他公司内各种力量牵扯和分流的情况。

最后还得背锅。

我就是一个挂名产品技术总监的实际做着项目经理职责的上班族。

《凤凰项目》这本书中的主人公本身也是运维部门出身,和我的背景也一样。所以看的时候,我总是很难控制自己直接代入进去。那种中你避免不了的公司内部政治斗争(这些年有越来越多的公司喜欢标榜自己扁平化,没有办公室政治,挺好笑的。有人的地方就有江湖,你人在公司,怎么可能躲得开。)。我也很喜欢书中的一个title,IT经理。对,只要是和IT相关的,不管往下再怎么划分部门和职能,需要有人能协调和总管这一切的人,我也愿意称之为IT经理。

虽然我现在新的工作规划是去转型成一个更偏前置且贴近商业和用户的产品经理去了……

这本书好看,每个在有IT业务的公司,每天在各个项目中疲于奔命的人是可以看看。里面的方法论不是银弹,但思路很多时候是一致。虽然有太多理想化的结局,现实生活比这惨痛一百倍,但那个把 IT 比作生产车间的比喻我还挺喜欢的。其实换做计算机内部工作原理也可以理解。争夺CPU资源,输入输出,进程的意外崩溃,不对内存做垃圾回收造成的隐患,本质上 IT 相关的管理干的事其实和这个差不多。在有限的资源下,用你的能力,来做尽可能贴近目标的产出,这就是 IT 和其他大多数项目管理的精髓。

我对机械键盘毫无研究, 唯一要求是声音要大。

“我对机械键盘毫无研究,唯一要求是声音要大。”

出自一篇公众号文章

我喜欢这样直爽的人,哈哈哈哈。

我自己现在有个 Filco,有个 Cherry 标准的104,还有个 IKBC 扔在公司用。

Cherry 的这个大青轴确实响,但是敲着是真的爽。我知道网络上有一种不自觉的政治正确叫不能影响他人,特别是青轴这种很容易声音巨大的键盘。放在公司里,担心会吵到别人(也确实在 V2EX 见过若干次抱怨别人键盘声音大的),放在家里,担心吵到家人休息娱乐的。

道理都正确,我也懂,但我还是坚持,我现在喜欢这块青轴的 Cherry 远胜那款红轴的 Filco,虽然那个更贵(补个题外话,他们的手感我都认为远胜 HHKB ,HHKB 根本没有让我退烧,我觉得并不足够好。)。除去所谓手感,我可能最喜欢的就是使用 Cherry 的时候发出的确实巨大的声响。

声音不响我干嘛用机械键盘,它又何德何能被成为机械键盘。机械键盘就是要有驾驭工业时代机器一样的感觉才是机械键盘啊!