ASPIRE

[collect]一个平庸程序员的自白

原文链接：一个平庸程序员的自白

Jacob Kaplan-Moss 是著名 Python 框架 Django 的 Co-Creater 和核心开发者，在 Heroku 担任安全部门的 Director, 他常年参加 Python 社区的年度聚会 PyCon ，并经常上台演讲。在这次 PyCon 2015 上，他声称自己顶多只是一个平庸的程序员，幻灯片上也写着：

“Hi, I’m Jacob, and I’m a mediocre programmer.”

这次演讲非常精彩，视频可以在 Youtube 上看到（如果不想看视频，这里也有一篇文字总结：https://lwn.net/Articles/641779/）。Jacob 以马拉松为例，试图说明大部分人在大部分领域都是平庸的（Most people are average at most things.），特别好的和特别坏的都是极少数，但在程序员领域，我们听到的大都是某某程序员 rocks 或者 sucks ，基本没有中间状态，这是一件非常奇怪的事情。他还提到“真正的程序员”（real programmer）这个概念，也就是所谓的 “10x programmer” ，你只有精通某些原理或者长得像 Mark Zarkerberg 才算是一个 real programmer ，而一个使用各种云服务以及 API 快速搭建自己应用的人就不算，这非常可笑。顺带一提，Jacob 的 Twitter 个人简介就是 “not a real programmer. ”

Jacob 认为这种关于“编程天才”的神话非常有害，一方面它把行业门槛设置得特别高，令很多人望而却步，另一方面它也在折磨行业内的人，因为你如果不能 rocks ，就会变成 sucks ，所以不得不用一切时间来努力学习和工作，导致影响生活。他认为我们应该改变这种态度，编程只是一些技能，并不需要太多天分，它是可以学习的，而且做一个平庸的程序员不丢人，”it’s cool to be okay at these skills”。跑步的人有很多种——短跑运动员，纯粹为了锻炼身体的人，参加马拉松的人，等等。为什么编程就一定要做 real programmer ，而且做不到就觉得自己不配编程呢？

这个演讲在大会现场赢得很多掌声，在提问环节也可以听到一些怯生生的声音说：“我也是一个平庸的程序员。” 不过在其它地方也引起一些争议，有人认为拿跑步和编程对比并不恰当，有人说程序员能力的差距确实大得惊人，有兴趣的人可以去看 Hacker News 上的讨论。

对于我个人来说，Jacob 的演讲触动了我多年来的心结，让我非常感动。我一直认为自己顶多只是一个平庸的程序员，而且无论多么努力学习，总觉得自己不是一个 real programmer ，而且好像越走越偏。Jacob 的演讲让我明白，有此苦恼的大概不只我一人，所以这里写一下自己的心路历程，希望对别人有一些启发。

公开承认自己平庸是一件危险的事情，如果不能说明你智商低或者没有天分，至少说明你态度有问题：“平庸就应该去努力练习，而不是写文章为平庸辩解”。而当你说 Jacob 这样的人也承认自己平庸时，就会出现一堆带有“资格论”的反驳：“Jacob 至少写了那么多代码，你怎么能和别人比” “人家那样说是谦虚，你这样就是无耻了”，顿时你就会觉得自己和那些只会从伟大人物身上挑毛病的小人没什么两样。幸运的是，今后我很可能不会以编程为业了，所以这些事情都无所谓了，可以诚恳地说一下自己的经历。

我对 real programmer 的印象始于大学，尽管对于其它专业的人来说我们和修电脑的没什么两样，但专业内部已经隐约有对某种高级事物的崇拜，记得大一时一个同学对我说：“我们现在还学 C，外面早就开始用 Java 了”。那个时候专业内也已经流传了不少程序员的传说，比如某个学长多么厉害，或者微软某个程序员一个人做完了一个项目组的工作。相信很多人都听说过那个故事，大意是一个人电脑坏了，于是找一个电脑高手来修，电脑高手拿来电话，连上电脑，花了整整一夜的时间用 0 和 1 写了一个操作系统，故事的结局是“这个电脑高手去了美国，杳无音信”。当时我听到这个故事的时候半信半疑，居然宁愿相信它是真的！因为如果万一它是真的而我不相信，只能说明我的技术水平或者智商无法理解那个层次的东西，那就太糟糕了。那个时候真的很想变得厉害。

随着对专业的了解，很快我们就开始嘲笑那种“Java 比 C 新，所以比 C 好”的看法，转而去相信“越底层越牛”的论调，写 C 的比写 Web 的厉害，写汇编的又比写 C 的厉害，为什么呢？因为他们“基础更扎实，更了解原理。” 这种论调发展到一个极致就是：学数学或者物理这种“硬科学”的人如果转行写程序，肯定比我们厉害。他们算法一定比我们好，而且就是这帮家发明的计算机啊我靠。有一段时间隐约觉的别的专业的转行写程序都会比我厉害，哪怕是一个钢琴家——因为他手指灵活打字更快。

大学里另外一个让我印象极其深刻的传说就是：高手写程序不用 IDE ，都是直接记事本。高手摘花飞叶皆可伤人，谈武器和工具，那就是落了下乘，只有不入流的才整天研究哪个工具更有效率。所以在很长一段时间内我都因为自己没用记事本写程序而怀疑自己的能力，直到后来工作之后我接触到了 Vim ，发现它长得和记事本还真的挺像的。

除此之外，还有对经典书籍的顶礼膜拜，MIT 的 Introduction to Algorithms 和 SICP ，Knuth 的 The Art of Computer Programming ，TCP/IP 详解，以及一些其它的经典操作系统、数据库等方面的书。不啃完这些就说明你天分不够，或者没有热情，还是趁早转行比较好。在我一直很喜欢（现在依然喜欢并推荐）的一篇文章 Teach Yourself Programming in Ten Years 中，作者在结尾推荐了 SICP ，他说：”The book is challenging and will weed out some people who perhaps could be successful with another approach.” 所以尽管我一直没有读完这本书，而且应该也不会去读了，但对它总有一种情结，以至于两年前出国的时候还把它带在身边。

毕业之后开始做职业程序员，每天都是和程序员打交道，关注的也都是科技新闻，那时候硅谷文化也越来越流行，所以更加向往和崇拜 real programmer 。Joel Spolsky 写过一篇《飙高音》，其中的两段可以算作是对 real programmer 的最佳诠释：

用许多平庸的程序员取代少数优秀的程序员，这种做法的真正问题在于，不管平庸的程序员工作多长时间，他们做出来的东西，都无法像优秀程序员做得那样好。
……
一流的歌唱演员不管在什么时候，都可以很轻松地唱出高音，而平庸的歌唱演员就是永远做不到这一点。莫扎特的歌剧《魔笛》中有一段著名的咏叹调”Queen of the Night”，音高必须达到F6（女高音的最高音高）才能唱好这首歌，世界上能达到这个标准的女高音都快要绝迹了，而飙不到著名的F6，你就是不能表演”Queen of the Night”。

简单地说，如果你缺乏天赋，那么你再努力，也做不到 real programmer 可以做到的事情，而一个平庸的程序员就是一个烂程序员。这种断言式的文章一直比较能鼓舞人心，那些认为自己比较聪明的人也很喜欢这种说法，但对于我这种一直怀疑自己智商和能力的人来说，它就像一个阴影：万一我真的没办法飙高音怎么办？

因为这种对 real programmer 的仰视，从工作以来，不对，是从大学以来，有一个想法一直挥之不去，那就是：I don’t deserve it.

大学里我也有作品拿过奖，但总觉得自己的代码是一坨屎，不配拿那个奖，如果当时有另外一个 real programmer ，肯定轮不到我。

大四找工作的时候，尽管我是通过正规的笔试和面试拿到的 offer ，而且被录用的只有我一个本科生，我还是觉得自己不配得到那份工作，因为没写过 10 万行代码，也不是一个 real programmer.

刚工作的时候我每天从早晨 9 点到晚上 9 点都在公司，有时候周末也去，手头工作做完了就看技术文档，无聊了就用打字软件练习正确的指法，以便编程可以快些。即便这样，我还是怀疑自己对编程的热情，觉得自己离一个 real programmer 越来越远，不适合做程序员。

后来去雅虎北研面试，从早晨 8 点面试到 12 点，第二天又跑去美国的同事视频面试。测试其实已经很严格了，而且我平时没有针对性地刷题或做其它应试准备，但很奇怪，我还是觉得自己能力不行，只是侥幸拿到了 offer.

平时帮别人写代码，或者和别的部门合作，第一个念头就是自己的能力不行。尽管最后项目顺利完成，对方也对我评价不错，但我还是觉得自己不配得到那些夸奖，甚至想：如果他们见到 real programmer ，就不会称赞我的工作了。

这种心理还有另外一个负面作用，那就是时时刻刻焦虑，害怕掉队。Jacob 在演讲中也说到：

If the only options are to be amazing or terrible, it leads people to believe they must be passionate about their career, that they must think about programming every waking moment of their life. If they take their eye off the ball even for a minute, they will slide right from amazing to terrible again. That leads people to be working crazy hours at work, to be constantly studying programming topics on their own time, and so on.

这段话准确地说出了我以前的某种状态。我对除了编程之外的很多事情都有兴趣，从生活的角度来看，这其实是一件好事，但我却常常因此有负罪感，因为它们耽误了我编程、看文档和学习新技术的时间。那些事情本来是可以带给我快乐的，但每次做好像都有一种偷偷摸摸的感觉，被别人问到也羞于提起。现在回头看，之前有段时间我的工作和生活其实平衡得很好，但当时我只有不断告诉自己“你本来就平庸”，甚至把自己想象成一个自甘堕落的人才能安心享受，实在太扭曲了。

以前我有时还喜欢写点东西，认为自己是在分享，但后来总觉的自己又不是 real programmer ，分享的东西有什么价值呢？而且写文章会耽误编程的时间，程序员文化又特别推崇“务实”，反对“务虚”——写作就是“务虚”，“只会打嘴炮”在程序员群体里面是一个非常严重的侮辱，记得之前看到过一条招聘信息，明确地说“不欢迎经常写博客的人”。事实上写作不止是表达，它反过来还可以帮助思考，很多想法在下笔之前是不存在的，我从中获益良多。而且，“不愿意表达”和“不会表达”有着本质的区别。以前如果一个猥琐不堪、一句话都说不清楚的人过来朝我扔一句”Talk is cheap. Show me the code.”，我立刻就会惭愧不已，甚至认为他或许就是一个 real programmer.

以上种种不安和困扰，让我常常觉得自己从性格到业余爱好都不适合做程序员。程序员文化告诉我的是：如果你不是一个 real programmer 或者不在成长为一个 real programmer 的路上，那么你连一个 programmer 都不是。Hacker News 上针对 Jacob 演讲的讨论中，panjaro 说了他自己的经历：

I’m an example how this myth can destroy you. I was programming for 6 years in normal projects and I thought I was not talented. I left job, came to research degree. Now I realized I’m terrible at maths and advanced algorithm techniques. I think about going back but since it has been 3 months I haven’t worked in a company, I feel I am a very bad programmer and no one will hire me. I’m depressed and paralyzed. All I do all day is look into HN and read articles, think how all these people are talented and I’m so dumb.

他的描述让我感同身受，当初我也痛恨自己对数学不感兴趣，整天在自习室苦苦复习离散数学和算法，工作之后也常常想要重新回头学习这些“基础知识”。有时候即使你发现在某些工作中算法并不像传说中那么重要，也不能说出来，否则你就是忽视基础，或者你从事的就是程序员当中的低级工作，以至于体会不到算法的重要性。

程序员文化当中“能力决定一切”的态度很多时候都值得商榷，因为除了极少数的计算机科学家，大部分程序员从事的是产品开发工作，而在产品开发中是没办法用一个简单的标准衡量一个程序员的能力的。一个人可能编程能力很强，但他可能执意要实现自己的想法，以至于拖累整个项目。另外，编程能力强的人不一定能从事某些“低级的”、不需要太多智力的工作，那样的工作可能需要大量的耐心，而耐心和传说中的天赋一样，也不是一种人尽可夫的品质。以前看到过一个招聘信息很有意思，里面说希望应聘者“已经结婚，或者至少有过一段长期的恋爱关系”，他们觉得这样的人懂得与别人相处，不太容易是一个鄙视别人工作的 jerk.

我并不是否认大牛的存在，Linus 和 John Carmack 就不用说了，刚毕业在中国雅虎的时候就遇见过一位大牛同事，清华毕业，基督徒，已婚，业余时间喜欢编程和做饭，经常一个人做完整个团队的工作，打字奇快，每次技术分享都有很多人去听，甚至 HR 都因为好奇过去。听众提问的时候，他能清楚讲解某个不常用命令的某个参数的作用，简直就是活的 user manual 。他非常乐于助人，经常看到他在 mail list 里面回答别人问题，从问题的成因分析到解决方案都一一给出，表达非常清晰。让我比较惊讶的是他对很多琐碎的事情也极有耐心，记得公司想要一些人申请专利，周末就看到他在那里专心写申请。另外一个和我比较要好的同事本来觉得自己还算有天分，比我厉害得多，在大学里真的写过 10 万行代码，但见过大牛之后立刻发现自己其实没天分。那个时候他女朋友在外地，他业余时间也就是看看电影写写代码，不想写的时候就打开大牛的 Github 看看，一般都会发现他又有新的 commit ，然后就有动力继续写了。

问题在于并不是所有人都是大牛，整个行业需要的也不止是大牛。举个例子，很多写 PHP 的大概看不起那种 “Wordpress 工程师”，就是只懂 WordPress 而对 PHP 了解不够深入的人。但很多公司确实就需要做一个小网站，只需要你能开发 WordPress Theme 就够了，不需要研究更多东西。帮别人开发 WordPress Theme 完全可以谋生，甚至挣得不少，但他们大概自己也觉得自己不是 real programmer ，所以很少发声。前一段时间有个应用很火，但他们团队的文章开头就说“我们团队中没有大牛”，好像那是很丢人的事情，一定要大牛组成的团队才配开发出好东西？如果抛开其它不谈，“一个人凭借自己的能力养活自己，他就应该得到尊重”，这话听起来没有任何问题，只是一旦牵扯到代码，好像只研究 WordPress 的工程师就不能见人。

很多公司也迷信只有大神程序员才能做事，所以在招聘的时候会说他们只招聘 Top 1% 的程序员，这其实根本不可能，Joel Spolsky 早就写文章谈过。你不可能招聘到 Top 1% ，只可能招聘到应聘者中的 Top 1%. 我们可以想象一下，最厉害的人可能直接去了 Facebook, Google 或者硅谷的创业公司，差一点的可能选择百度腾讯等国内巨头，或者非常有前景的创业公司，剩下的人才是市场中的人，这里面的 Top 1% 已经不是全部人中的 Top 1% 了。所以看到这种招聘可以评估一下这个公司，如果不是特别牛，完全可以大胆去应聘，因为你在那些愿意应聘这个公司的人当中，可能已经是 Top 1% 了。

其实我非常喜欢这个行业的某些理想主义色彩，过去这几年也认识了不少朋友，发现了不少 thinker ，对我启发很大。可惜我常常感到不舒服，也觉得和这种程序员文化或者 Geek 文化格格不入，虽然很努力去尝试过，但发现还是不行。当然，也可能并不是文化问题，而是因为像我和 panjaro 这样的人胆小浮躁，太在乎别人看法，容易焦虑和抑郁，这样的人大概在任何行业都是 loser 。希望其他人可以活得理直气壮一点。

过去常常希望找到人生目标，而当怀疑自己不是 real programmer 的时候又庆幸生活是一团乱麻，而人生可能并没有意义，不然的话，可能每时每刻都要生活在一条“鄙视链”当中了。

==

今天上午看到的这篇文章，有点感触，自己还是太在乎别人的看法，容易焦虑，但其实个人还是很努力的(虽然水平一般)，希望可以活得轻松一点，因为最近越来越感觉到——其实我必须很努力，才能过上普通人的生活。不过我还年轻，慢慢来，一切都来得及！

admin

, ,

《 “[collect]一个平庸程序员的自白” 》 有 25 条评论

  1. 技术高手如何炼成
    https://zhuanlan.zhihu.com/p/20270317
    有些事儿，工程师可能今生仅此一次
    http://www.cnblogs.com/zhengyun_ustc/p/topicStudy.html
    `
    公开分享你的所思所得，不仅要做，还要写下来，还要说出来。你一定要输出你在这个问题上构建的知识结构，帮助自己，帮助大家，共同进步。

    如是重复再重复，训练再训练，不妨试试看遵循 70-20-10 的学习法则：70%的学习时间放在针对现实生活和工作中遇到的任务、问题解决，20%的学习时间放在人与人之间正式的、非正式的反馈、辅导，10%的时间学习知识和信息（可能是碎片化的学习，也可能是读书）。
    `

    回复

  7. 做到这一点，你也可以成为优秀的程序员
    https://mp.weixin.qq.com/s/8Bl105G8ZsE_jy5mbrIy_g
    `
    作为一个程序员，我经常会问自己一个问题：
    优秀的程序员都具备哪些特质？

    我总结过很多特质，例如：
    有解决问题的能力
    有独立思考的能力
    有好奇心、有探索精神
    逻辑清晰，能够用通俗的语言把技术问题讲清楚
    有良好的英文阅读能力
    数学好，算法好

    经过一段时间的观察，我发现这上面的所有特质，都可以由一种行为习惯衍生出来，也就是如果你有以下习惯，那么你可能拥有且不限于以上所有的特质：
    「观察大多数程序员的行为，朝相反的方向走」
    `

    回复

  8. 软件工程师成长之路
    http://yiding.9.cn/wp/2803174
    https://mp.weixin.qq.com/s?__biz=MzA3NDM0ODQwMw==&mid=2649827772&idx=1&sn=10407d51a4779fc11a3b46bd5edad3c4&scene=0
    `
    如何选择一个能够让自己成长的工作？
    这个问题在『黑客与画家』里Paul已经给出了答案：选择那些具备「可测量性」和「可放大性」的工作。
    选择的顺序「行业→公司→团队→老板→队友」

    如何在工作中成长？
    自信自律
    自我学习
    建立自己的方法论
    重新认识听说读写
    学会选择
    学会问问题
    `
    http://www.infoq.com/cn/news/2017/08/Learn-grow-at-work

    回复

  9. 如何在技术路上走得更高更远
    https://mp.weixin.qq.com/s/5p1LdST-WHtMFBrElWtwSg
    `
    好奇心，追本溯源，追求技术本质的好奇心。
    心静如水，耐得住寂寞，远离浮躁，跨过这个苦逼行业的种种挑战；
    不断学习新技术，培养自己对技术的敏感度和前瞻性；
    不喜欢技术，对技术没有好奇心，岂不是每天都很痛苦？

    思考，才是进步的本质

    和谁工作很重要，倒逼成长

    时间×方法×E=技术大牛 （E=环境限制系数）
    `

    回复

  11. 那些会阻碍程序员成长的细节[1]
    https://mp.weixin.qq.com/s/URvpwQE2sK_UDrfHtvWC8A
    `
    拿到开发任务后，直接上手写代码。缺少必要的沟通与设计，返工的机率极大。
    在逻辑混乱的地方加入新东西，而不是去重构。
    不愿意与别人分享技术成长。教是学习最快的一条路，将自己所学传播分享给他人，并使他人能消化吸收，是对自己知识掌握一个最好的检验。同时在分享的过程中温故而知新，更加深对知识技能的掌握。如果你有教会徒弟饿死师傅的想法，会显得很落伍。互联网时代下，还有什么知识技能，是你独有而别人从来没有的？不如拿出来分享，大家共同成长。一个人走的快，一群人才走的远。
    遇到BUG首先否定是自己的问题。
    缺乏验证条件时，开发的功能不经测试直接交付给测试人员。
    修复某BUG时，夹带其它问题。
    `

    回复

  13. 36氪领读 | 腾讯工作法：当你认为领导比你更愚蠢时，应该怎么办？
    https://36kr.com/p/5128620.html
    `
    开会的本质
    我们之所以碰头，是因为要想完成某一项具体工作，单凭一个人的知识和经验不够，需要结合几个人的学识和经验。开会是为各方在大方向上的沟通提供尽可能多的机会，但其实开会的目的并不是沟通本身，而是为了让大家达成共识。

    PPT悖论：重点是point有power
    在制作PPT 时，要特别重视内容的支撑。

    “不允许说什么事情在技术上做不到”
    一件事情在技术上能否做到，与执行人自身的职业技能和其变通思考的能力息息相关。完成一件看似不可能的事情，首先要敢于尝试，只有踏出那一步，你才有资格评判整件事情。其次，对实现问题的边界判断也不能只基于自己的个人能力，要放大到整个组织的能力中去看，要学会利用身边的资源，团队的力量往往超乎想象。

    当你认为领导比你更愚蠢……
    职场中无绝对的对与错，人们观点的不同只是源于每个人思考问题的角度不一样。作为员工，大多问题都是从执行的层面考虑的。作为管理者，获取的信息更丰富，思维空间更广阔，所以思考问题会更多地从战略上出发。除了任务的执行之外，任务的最佳时机、所需的成本、涉及的影响因素等多个方面也是管理者比较关注的。
    当你的脑海里开始产生“领导比你更愚蠢”的想法时，请务必提醒自己：职场中视角不同常常导致不同职位的人看到的东西不一样，很多时候领导能够看到的东西，员工可能看不到。在遇到问题时，保持积极的沟通才是明智之举。
    `

    回复

  16. 如何成为一位「不那么差」的程序员
    https://crossoverjie.top/2018/08/12/personal/how-to-be-developer/
    `
    1. 前言
    2. 技能树
    　　2.1. 计算机基础
    　　2.2. 数据结构与算法
    　　2.3. Java 基础
    　　2.4. 多线程应用
    　　2.5. JVM 虚拟机
    　　2.6. 数据库
    　　2.7. 分布式技术
    　　2.8. 懂点架构
    3. 如何学习
    　　3.1. 视频
    　　3.2. 看书
    　　3.3. 知识付费
    4. 打造个人品牌
    　　4.1. 博客
    　　4.2. GitHub
    5. English 挺重要
    6. 保持竞争力
    7. 思维导图
    8. 总结
    `

    回复

  19. 我所理解的高级工程师
    https://mp.weixin.qq.com/s/Y4jjuy3a6lugWBM_3mylpA
    https://dev.to/mokkapps/my-definition-of-a-senior-developer-3k8l
    `
    下面先总结一下我理解的高级软件开发工程师的特点：

    对正在做的事情充满激情
    做一个解决问题的人
    了解编程语言和框架的基本原理
    成为一个导师的同时也给自己找一个导师
    让自己跟上业界的发展
    离开你的舒适区
    争取自己的观点
    要社交
    同时专注于软技能的学习和提升
    `

    回复

  21. 一个技术人，如何做到比别人更突出
    https://mp.weixin.qq.com/s/F7hmjN5rlHcEifT8NzlYqA
    `
    01. 做出承诺，超出预期
    1.了解期望
    2.做出合理承诺
    3.超出期望

    02. 重要不紧急的事
    在处理工作任务的时候，大部分人都是在处理“紧急”的事情，不管它是否重要，但是优秀的人会懂得安排出时间把重要但不紧迫的事先做了，所以每每在做结果汇报的时候，总能给到大家“意外的惊喜”。

    一件事情是否重要，这个就要回归到大家的具体工作本身，根据我的经验，可以通过以下三步来确定：
    1.问领导
    2.看收益
    3.寻路径

    总结一下，职场上要做一个突出的、优秀的人，除了“出活”，还要学会“用心”，做出承诺，超出预期，让别人收货意外的惊喜，他就会牢牢记住你，同时，要学会花时间处理“重要不紧急”的任务，这样你完成的东西总会让人眼前一亮，想不突出都难！
    `

    回复

  22. 程序员如何在工作中自我增值
    https://mp.weixin.qq.com/s/nEmc5yqVOB2osZnoqUo_HA
    `
    技术、市价和身价的关系
    技术，尤其是通用技术，和marketing value是直接绑定的。而paper value，很多情况下并不和marketing value成正比。
    对于一个特定职位而言，paper value有相当大比例的业务相关性，同时，paper value也不乏和资历挂钩的情况。

    对于已经是全职员工的人来说，保持对前沿技术的敏感性是很重要的。但是如果一心学习前沿技术，一则各种技术更迭不断，另一方面也会占用深入研究和学习业务的时间。
    而且，学到的技术不应用，终归流于粗浅。既不能达到很好提高marketing value的目的，还会影响paper value。

    而如何只专注业务，则无异于将自己绑定在现有单位的现有产品经营上，不要说企业本身倒闭之类，就是业务调整，也会使得这个员工在忽然之间丧失全部value。一旦他/她做的业务被裁撤，这个员工也就可以走人了。

    核心价值何在？
    其实，说白了，技术也好，业务也罢，都是表面现象，真正的价值在于解决实际问题的能力。
    实际当中的问题是千差万别的，如果处理每个问题都仅仅“就事论事”，只会用这项技术解决那个业务问题，那么也只能是把自己绑定在某些技术细节和领域知识上。
    所以，在工作中提高自身价值的最佳途径是结合现有工作，深入学习相关技术，进而在抽象层面形成对于现实问题的提取、解决、体系架构的设计。

    只有经过提炼到抽象层次的问题解决能力，才可能迅速在不同领域之间切换，达到触类旁通、融会贯通。要达到这样的水平，切入点很关键，技术人员至少需要在一个领域达到深入的程度，否则根本连面对真正问题的机会都没有。

    此处的一个关键点就是：学习和实践相结合，以问题为驱动，不断向下挖掘研究。

    获取“输入”
    提供“输出”

    如果你经常感到被无视，无法体现存在感，那么试试下面这些方法吧：

    1. 做能够直接产生商业影响力的项目。
    明确项目对公司的商业影响，争取成为项目中重要的角色，让你的工作对公司的目标直接产生影响。
    当然，获得这样的机会往往需要承担风险，走出舒适区。争取有压力的机会，你的潜力才能够被发掘。

    2. 主动展现你的技术能力。
    具体方式是争取展示能力的任务或活动机会，比如技术分享，宣讲等。要自己开口去说，否则别人怎么知道你会做什么。
    当然，要能够做到持续的技术分享，需要紧跟技术潮流。让你的主管知道你想要学习掌握的技术，并制订相应的目标。同时也可以看看公司是否愿意支持你去发展相应职业机会。

    3. 寻找具有影响力的导师。
    导师可以针对的你的职业发展和公司文化给予建议和指导，而赞助人则能够帮你提高存在感，让受惠于你的工作的组织内成员得悉你的存在。

    4. 构建一个强有力的关系网络。
    可以通过参加跨职能，跨组织的项目，以此来扩展自己的知识和技能。
    在有了一定的技术和项目积累后，可以考虑自己也承担内部导师的角色，去辅导别人。回报是让你本人变得更加职业也更具领导力。另外，辅导他人的经历也可以写到年终评定的总结里，让别人看到你的贡献。
    `

    回复

  24. 有没有自我反思这 5 个问题，为什么觉得自己能力不行？
    https://mp.weixin.qq.com/s/sJPE58XStpEIkrGduWZb3A
    `
    一、不害怕探索陌生程序语言

    接触新专案或是转换工作跑道时，都有可能需要学习全然陌生的程序语言，许多人对此感到害怕，甚至未尝试就先放弃。其中，跳脱舒适圈的恐惧往往多于学习程序，会担心是否无法重现过去工作的好表现，甚至因此怀疑自身能力。

    不论是多厉害的工程师，一定都有起点，就像打造 Microsoft Windows 基础的微软资深工程师 Dave Cutler 为文组出身，没受过正式电脑科学教育，比起同辈花更多时间在错误中学习。在这之中，最重要的两个关键为具备「成长心态」（growth-mindset）而非「固守心态」（fixed-mindset），以及「乐于学习」（optimize for learning）的态度。

    学习陌生程序语言这项关键能力会越练越上手，并让你在学习过程中成为更好的程序设计师。

    二、精通 Debug

    为什麽程序跑出来和我预期的不一样？是许多工程师会遇到的问题。Debug 能力往往是影响工程师是否能顺利完成专案的关键因素，却被大部分人低估。Debug 的系统性思考如下：

    先假设造成 bug 的可能原因。
    若假设为真，界定此假设可能导致的结果。
    试著检视是否有和这些结果衝突的现象。
    若有衝突表示假设错误，要重複上述思考过程。
    由此可知，想加快 Debug 速度，要提升「提出假设」和「检视假设」的能力。假设能力可随著 Debug 经验的累积而提升，检视能力则需加强善用检测工具的技能。在此过程，必须先假设所有东西都是可检视的，并找出可用来检测或加快检测速度的工具或机制，千万不要只用自己熟悉的工具。

    三、开发节省时间的工具

    减少时间做那些电脑就可做的工作，例如开发节省时间的工具和使工作流程自动化。

    曾负责 Facebook 软件基础建设团队的软件工程师 Bobby Johnson，带领该团队从 6 人成长至超过 1 百人。他观察到，团队中表现出色的人多数写了许多工具，这些看似和绩效无直接相关的工具开发时间可能佔三分之一的工作时间，却因此大大提升工作效率，其中包含用来部署程序、监测系统，以及其他可节省时间的工具。

    四、优化重複性工作的速度

    软件工程师每天可能要搜寻、浏览函数定义很多次，善用键盘快捷键可省下可观的时间。例如，每次搜寻需花 12 秒，类似的步骤每天要重複 20 次，若用快捷键可将搜寻时间缩短到 2 秒，一年下来即省了 40 个小时。其他状况如每次 Debug 都需要在不同装置测试，除了要分别打开 app，还要设定测试情境，这时候就可以思考如何加快这类重複性工作的速度。

    五、发展系统性思考模式

    写完程序码、让程序可运作仅是冰山一角，要产出真正有价值的程序，必须从程序本身提升到整个系统来思考。

    你的程序和其他程序库以及其他人写的功能是否相容？
    程序是否测试完成，并确保其他成员可执行你写的这些功能？
    部署你的程序需要改变哪些生产环境？
    新程序对其他正在运作的系统是否有负面影响？
    客户和使用者的新程序使用情况是否如预期？
    新程序是否达到公司期待的效果？
    从宏观的角度思考问题，可让你更懂得如何调配时间和精力以让程序达到最佳效果。
    `

    回复

  25. 工程师的成长
    https://github.com/lzyy/telescope/discussions/1
    `
    我们都需要成长，工程师也不例外。以下是我感觉对工程师的成长比较有帮助的点，供参考。

    要点
    * 积累信用货币（先把手头的事情做好，再聊你想做什么）
    * 提升影响力（注重输出；做能够影响更多部门/使用方的事，并把它做好）
    * 把工作当成内部创业（多研究手头/部门的事情，寻找问题/机会，把其他部门当作潜在合作伙伴）
    * 清楚自己的强项（将自己的强项和正确的事情结合起来，才能发挥最大的作用）

    环境
    * 与优秀的人共事（学习他们的技能和做事方式，不要成为最聪明的那个）
    * 做符合大趋势的事（ Focus 在某个领域可能是把双刃剑，多结合一些通用技能）
    * 做事情有足够的空间（可以发挥自己的创造力，而不是偏流程化、对着操作手册就能做的事）
    * 一个好的 Mentor（用旁观者视角给你反馈，指出问题和改进方案，帮助成长）

    作为个体的基本素质
    * 自驱力（想在前头，不需要别人来 Push）
    * 好奇心（不局限于自己的 Scope，多了解同事、Lead、行业的事情）
    * 高标准（仅仅做完是不够的，一个问题往往有很多可以挖掘的点）
    * 时间管理（不会疲于应付各种需求和问题，有优先级和 Plan）

    作为工程师的基本素质
    * 良好的编码能力（1 个月后的自己依然可以维护，出问题可以快速定位）
    * 享受解决问题的乐趣，具备化繁为简的能力（抽象，分解，分层，分模块）
    * 抗压能力（压力下，不变形）
    * 数据意识（好了，坏了，用数据说话）
    * 注重效率（不吝啬在工具上的投入）

    看问题的角度
    * 如果现状让我不舒服，我可以做什么来改变，而不是逃避和埋冤
    * 如果觉得当前没什么问题，一定是了解得还不够深入
    * 如果是Ta（某个你欣赏的人）来做你手头的事，Ta 会怎么做

    做事情的方法
    * 设计方案时要考虑周到：竞品调研、上线策略、降级方案、回滚方案、出问题时如何排查等
    * 事情推不动就上升，但要提供充足的上下文以便 Lead 做决策，Context not Control
    * 汇报时要切换视角，有条理，把要点说清楚，同时提供了解细节的入口
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注