《火星救援》与工程师
最早是从别人口中听到这个电影的介绍,但是从听说这部电影开始,就一直很想看,因为总想着去年看过的《星际穿越》,对太空和科幻题材的电影,有一种特殊的向往.于是一上映就琢磨着去看.终于在周五的时候,抽空去村里看了,两个小时看完,惊讶的我只能说两个字:好看!这是一部从故事到演员到音乐到内涵,都能吸引人的好电影.
但是今天我要说的是,作为一个代码工作者,从电影中看出了工程师的情怀.在看的过程中,就跟同去的人说笑,说NASA的这帮人,就像我们平常工作一样,有人负责干活,有人负责背锅,而Jeff Daniels饰演的Teddy就像每一个老板一样,负责告诉开发部门:'你们只有67天来做完这个项目'.然后开发部门表示,时间这么紧张,测试就不测了,先上线再说.当然结果大家都知道了...Boom!!!最惨的是开发部门还要花1/3的时间再做一个一样的...
回来之后本着好奇的精神Google了一下,发现这个原著的作者Andy Weir其实是一位专业的码农,曾在AOL,Palm,以及暴雪工作,还参与过魔兽争霸2的开发!怪不得把一个科幻故事讲的这么Geek范.电影中的Mark Watney和NASA简直堪称是一个工程师和一个项目组的真实写照.
而且电影作为一个连反派都没有的积极向上正能量大片,无处不透露着一个优秀工程师身上所体现出的特质和优点.下面我就以一个码农的角度来阐述一下我所理解的本片中的一些观点.
Mark Watney是优秀的工程师吗?
先说结论,当然是.至少以Mark Watney的观点来讲,他起码也是火星上最优秀的工程师和植物学家.毕竟火星除了他也没有第二个人.其实关于工程师这个话题,我也跟许多人讨论过许多次,到底什么样的工程师才可以称得上优秀?以及如何成为一个优秀的工程师?这些问题都值得深入的思考.
如果说Mark Watney是一个优秀的工程师,那么他的身上又有哪些值得我们思考的地方呢?按照他在结尾的自述,他在火星做的事情只有寥寥几项.
- 保持乐观
- 解决当前的问题
- 解决下一个问题
- 再解决一个问题
- ...
- 回家
是的,他从头到尾只是在解决问题,在我看来这正是一个工程师的价值所在,你能解决问题.而你能解决多复杂的问题,能不能解决别人解决不了的问题,以及你解决问题的方法,开销和效率,决定了你是不是一个优秀的工程师.
至于你在解决问题的过程中,所需要的专业技术,工具和其他能力,以及细节的内容,我们都能从他身上看出一些影子.
清晰和相对固定的目标
首先他很乐观,也很理智,这是很重要的.当他发现自己被一个人困在火星上时,他的想法很简单,要回家,剩下的一切工作都是为了回家这个目标而努力.当然你需要把一个大的目标,拆解成一个一个的小而简单的任务,然后用你的知识和技能去逐个解决他们.而我要说的是一个明确的目标,会让你的每一小步都走的更正确,因为你知道你不光要做好当前的任务,还要让整个项目向目标前进.这往往更加重要.
掌握自己的资源和能力
Mark很快进入了状态,想回家怎么办,第一方案就是活着等到战神四号并且在那时到达数千公里外的Schiaparelli环形山.而看起来能帮助他的只有剩下的几十天的食物和一辆火星车,似乎不可能完成.但是他愣是靠着自己在火星上种出了土豆.从找到最开始那一袋土豆开始,他就充分发挥了自己的专业精神和想象力,不得不说联氨制水的那一段实在是太有想象力了,虽然可能实际上会有点困难?不过这都充分证明了,他很确实是一个专业的植物学家,并且善于利用已有的环境和资源.在有限的条件下,更好的解决问题.
多沟通和寻求帮助
解决食物的同时,Mark也没忘记尝试和地球取得联系,能多得到一点帮助是一点,这时候伟大的探路者号就出现了,这个1997年的老代码,在Mark机智的update下,重新焕发了容光,浑身上下只有摄像头能动的探路者号,硬是被改造成了一个能传输16进制编码的通信协议...然后紧接着又和NASA联合改造了现有的系统,通过手敲机器码,实现了一个IM工具.最后更是坐着敞篷飞行器离开了火星.毕竟Mark的设定只是一个植物学家,但是他通过和NASA的沟通,得到了其他许多专业人士的帮助和指导.因为工程师往往是专精在自己的领域,比如我是一个前端开发工程师,遇到Java或者Nginx的问题,我在了解大概之后,更倾向于向这一领域内的专业人士寻求帮助,因为他们的经验和技能决定了,这些问题上,他们会解决的更好.所以,向别人求助就和使用开源代码一样,有助于你更专注的解决你精通的问题,而不是为了解决问题从头去学另外一个技能.当然如果这个解决方案不够好,那你大可以自己造一套轮子.这是值得的.
NASA是怎样一个项目组
NASA相对于Mark来说,缺少一些个人的色彩,更多的是一个项目组的感觉.里面有大老板Teddy,小老板肖恩·宾(我实在是不记得那个角色叫什么了...),项目经理Vincent,以及研发部门的研发经理Bruce Ng和一干码农.所以在故事上,充分反应了一个现实中的项目组都会发生些什么...
时间很紧迫 需求还总在变
为了营救Mark,先紧急给他送补给上去,让他能坚持到战神4号抵达火星.NASA为了这个方案拼上了大量的人力物力,确因为最后没有测试而功亏一篑,只好再临时换方案,再压缩时间.要不是有中国的共产主义火箭和码农小哥Rich Purnell神奇的方案,恐怕结局就不是这么美好了.就像墨菲定律,你如果把所有希望都寄托在一个解决方案不出问题上面,那他一定会出问题.所以我们在面对时间和需求的不确定时,千万不要寄希望于需求不改了和时间还很充裕这种鬼话.假设这些一定会变,你能不能迅速的调整和改进你的代码,适应变化?能不能在设计的时候,考虑一些可能的因素,能不能把可重用的东西尽量重用起来?这样至少你再下一次造同样一个太空器的时候,能省下2/3的时间.
总要有人背锅
当Teddy宣布Mark还活着的时候,记者问得最多的问题就是:'你是否会辞职?',而当我们的项目或者代码出了问题的时候,我们也往往做同样的事情,这个锅到底要是谁的,如果是我的,我能不能把它甩出去,如果不是我的,我该甩给谁?他甩的这么厉害,一定是每天晚上回家都在练习甩锅.但是很显然,这不是一个正常的项目组该做的,责任应该是每一个人的,至少你要负责你所做的工作,保证你的代码或者测试或者设计,但是领导者应该承担更高层次的风险和错误,当然很巧妙的是,这一条一般不适用于大老板,所以肖恩·宾虽然没有发挥他的特长成为这部电影里唯一的死人,还是承担了辞职这个任务...当然我还是希望大家能主动的承担自己工作中的责任和失误,错误不可怕,可怕的是你下次还犯同样的错误.
我还学到了什么
- 多做记录和日志还有文档,同时有计划的做事
- 健康的身体很重要,吃半年土豆还能接着写代码大概能达到标准
- 一定要测试你的代码!越重要的代码越需要严格的测试,以及不要在生产环境做测试
- 多掌握一点技能没有坏处,有时候能救你一命(没错,我说的就是种菜)
最后
好久没有动笔写过东西了,这次难得有这么多脑洞,所以索性动笔写了一些,也算是对于电影的思考和对于工程师这个话题的一些想法吧.毕竟代码写的多了,也需要一些思考.希望以后能强迫自己定期写一点东西.
送上电影的片尾曲 I Will Survive -- Gloria Gaynor
《火星救援》与工程师
最早是从别人口中听到这个电影的介绍,但是从听说这部电影开始,就一直很想看,因为总想着去年看过的《星际穿越》,对太空和科幻题材的电影,有一种特殊的向往.于是一上映就琢磨着去看.终于在周五的时候,抽空去村里看了,两个小时看完,惊讶的我只能说两个字:好看!这是一部从故事到演员到音乐到内涵,都能吸引人的好电影.
但是今天我要说的是,作为一个代码工作者,从电影中看出了工程师的情怀.在看的过程中,就跟同去的人说笑,说NASA的这帮人,就像我们平常工作一样,有人负责干活,有人负责背锅,而Jeff Daniels饰演的Teddy就像每一个老板一样,负责告诉开发部门:'你们只有67天来做完这个项目'.然后开发部门表示,时间这么紧张,测试就不测了,先上线再说.当然结果大家都知道了...Boom!!!最惨的是开发部门还要花1/3的时间再做一个一样的...
回来之后本着好奇的精神Google了一下,发现这个原著的作者Andy Weir其实是一位专业的码农,曾在AOL,Palm,以及暴雪工作,还参与过魔兽争霸2的开发!怪不得把一个科幻故事讲的这么Geek范.电影中的Mark Watney和NASA简直堪称是一个工程师和一个项目组的真实写照.
而且电影作为一个连反派都没有的积极向上正能量大片,无处不透露着一个优秀工程师身上所体现出的特质和优点.下面我就以一个码农的角度来阐述一下我所理解的本片中的一些观点.
Mark Watney是优秀的工程师吗?
先说结论,当然是.至少以Mark Watney的观点来讲,他起码也是火星上最优秀的工程师和植物学家.毕竟火星除了他也没有第二个人.其实关于工程师这个话题,我也跟许多人讨论过许多次,到底什么样的工程师才可以称得上优秀?以及如何成为一个优秀的工程师?这些问题都值得深入的思考.
如果说Mark Watney是一个优秀的工程师,那么他的身上又有哪些值得我们思考的地方呢?按照他在结尾的自述,他在火星做的事情只有寥寥几项.
是的,他从头到尾只是在解决问题,在我看来这正是一个工程师的价值所在,你能解决问题.而你能解决多复杂的问题,能不能解决别人解决不了的问题,以及你解决问题的方法,开销和效率,决定了你是不是一个优秀的工程师.
至于你在解决问题的过程中,所需要的专业技术,工具和其他能力,以及细节的内容,我们都能从他身上看出一些影子.
清晰和相对固定的目标
首先他很乐观,也很理智,这是很重要的.当他发现自己被一个人困在火星上时,他的想法很简单,要回家,剩下的一切工作都是为了回家这个目标而努力.当然你需要把一个大的目标,拆解成一个一个的小而简单的任务,然后用你的知识和技能去逐个解决他们.而我要说的是一个明确的目标,会让你的每一小步都走的更正确,因为你知道你不光要做好当前的任务,还要让整个项目向目标前进.这往往更加重要.
掌握自己的资源和能力
Mark很快进入了状态,想回家怎么办,第一方案就是活着等到战神四号并且在那时到达数千公里外的Schiaparelli环形山.而看起来能帮助他的只有剩下的几十天的食物和一辆火星车,似乎不可能完成.但是他愣是靠着自己在火星上种出了土豆.从找到最开始那一袋土豆开始,他就充分发挥了自己的专业精神和想象力,不得不说联氨制水的那一段实在是太有想象力了,虽然可能实际上会有点困难?不过这都充分证明了,他很确实是一个专业的植物学家,并且善于利用已有的环境和资源.在有限的条件下,更好的解决问题.
多沟通和寻求帮助
解决食物的同时,Mark也没忘记尝试和地球取得联系,能多得到一点帮助是一点,这时候伟大的探路者号就出现了,这个1997年的老代码,在Mark机智的update下,重新焕发了容光,浑身上下只有摄像头能动的探路者号,硬是被改造成了一个能传输16进制编码的通信协议...然后紧接着又和NASA联合改造了现有的系统,通过手敲机器码,实现了一个IM工具.最后更是坐着敞篷飞行器离开了火星.毕竟Mark的设定只是一个植物学家,但是他通过和NASA的沟通,得到了其他许多专业人士的帮助和指导.因为工程师往往是专精在自己的领域,比如我是一个前端开发工程师,遇到Java或者Nginx的问题,我在了解大概之后,更倾向于向这一领域内的专业人士寻求帮助,因为他们的经验和技能决定了,这些问题上,他们会解决的更好.所以,向别人求助就和使用开源代码一样,有助于你更专注的解决你精通的问题,而不是为了解决问题从头去学另外一个技能.当然如果这个解决方案不够好,那你大可以自己造一套轮子.这是值得的.
NASA是怎样一个项目组
NASA相对于Mark来说,缺少一些个人的色彩,更多的是一个项目组的感觉.里面有大老板Teddy,小老板肖恩·宾(我实在是不记得那个角色叫什么了...),项目经理Vincent,以及研发部门的研发经理Bruce Ng和一干码农.所以在故事上,充分反应了一个现实中的项目组都会发生些什么...
时间很紧迫 需求还总在变
为了营救Mark,先紧急给他送补给上去,让他能坚持到战神4号抵达火星.NASA为了这个方案拼上了大量的人力物力,确因为最后没有测试而功亏一篑,只好再临时换方案,再压缩时间.要不是有中国的共产主义火箭和码农小哥Rich Purnell神奇的方案,恐怕结局就不是这么美好了.就像墨菲定律,你如果把所有希望都寄托在一个解决方案不出问题上面,那他一定会出问题.所以我们在面对时间和需求的不确定时,千万不要寄希望于需求不改了和时间还很充裕这种鬼话.假设这些一定会变,你能不能迅速的调整和改进你的代码,适应变化?能不能在设计的时候,考虑一些可能的因素,能不能把可重用的东西尽量重用起来?这样至少你再下一次造同样一个太空器的时候,能省下2/3的时间.
总要有人背锅
当Teddy宣布Mark还活着的时候,记者问得最多的问题就是:'你是否会辞职?',而当我们的项目或者代码出了问题的时候,我们也往往做同样的事情,这个锅到底要是谁的,如果是我的,我能不能把它甩出去,如果不是我的,我该甩给谁?他甩的这么厉害,一定是每天晚上回家都在练习甩锅.但是很显然,这不是一个正常的项目组该做的,责任应该是每一个人的,至少你要负责你所做的工作,保证你的代码或者测试或者设计,但是领导者应该承担更高层次的风险和错误,当然很巧妙的是,这一条一般不适用于大老板,所以肖恩·宾虽然没有发挥他的特长成为这部电影里唯一的死人,还是承担了辞职这个任务...当然我还是希望大家能主动的承担自己工作中的责任和失误,错误不可怕,可怕的是你下次还犯同样的错误.
我还学到了什么
最后
好久没有动笔写过东西了,这次难得有这么多脑洞,所以索性动笔写了一些,也算是对于电影的思考和对于工程师这个话题的一些想法吧.毕竟代码写的多了,也需要一些思考.希望以后能强迫自己定期写一点东西.
送上电影的片尾曲 I Will Survive -- Gloria Gaynor