程序员转行故事阅读笔记001

原文

• 作者跳过了CS101课程，多年以后还是补上了。看来作为初学者，还是有必要自学两门101课程。
• 大多数程序员都有及其曲折的转行经历。从小就接触计算机一路成为程序员的人占比并不多。转行者也不用有此负担。
• 数学给作者并没有带来很多直接的用处。是否说明数学只有一部分对编程有用？
• 深入学习计算机科学的子领域，例如网络/数据库等等。
  • 同时减少看概论类的书的比例（例如oreilly），因为它面向一个广泛的群体，内容受限，没法深入。应采用T形学习策略。
  • 也不用学很多语言。学习新语言时，你是在学习新的syntax，和学外语类似，常常并不能提高你解决问题和编出好程序的能力。机会成本高。
• 你永远不知道自己目前的方法有多低效，直到你认识到别人更好的做法。例如作者所在的一家公司同时使用三种语言开发。他们还自觉没问题。直到有一天作者换了家公司，才发现以前的做法有多糟糕。标准化，统一语言、建立规则的好处被当事人严重低估，只有你实际感受才能体会其重要和强大。
  • “people don't really see it until they've seen the alternative.“
  • 所以永远假设自己是低效、有限乃至错误的。
  • 多接触、学习别人的方法，不试试光凭感觉，没法得到一点正确认识。
• 坑：作者大量阅读，报告论文和书，涉及相关和无关专业的内容。其中有很多工程知识后来也没用了。软件开发“big idea”的书他发现和实际编程也不太相关。同时他学了大量的不同语言，结果也没有影响他些许。倒是《设计心理学》改变了他对设计的态度。
• 作者大多数EE的工作经验最后并没有迁移到编程工作中。除了一些元技能：
  • debug
    • 大多数人以为自己懂debug，比别人更有耐心。他们错的离谱。和硬件debug相比，软件debug中的痛苦不值一提。
    • “The people I worked with most closely kept a mental model of what bugs were open“
  • trace bug的意识和能力。
    • 什么是trace bug？（压力测试？#Todo）
    • “people are often uncomfortable with the idea of taking a major problem and putting it into a bug instead of fixing it immediately because they're so used to bugs getting forgotten that they don't trust bugs. But that's what bug tracking is for! “
  • 如何解决（大）困难的能力和态度
    • 大神解决的问题，你可能连如何构思方案都做不到。
    • 但大部分时候你觉得完不成的问题，最后你八成也独立解决了。
    • “I know that I eventually started thinking of myself as someone who could solve any open problem that we had.“
• 在设计阶段的迭代远远好于开发阶段的迭代。
  • 所以设计阶段多思考，推敲，花时间。
  • 所以MVP并不是代表马上一头扎进代码里。
• 大多数人认为写设计文档是浪费时间。他们又错了。在大多项目中，好的设计文档比一个中级程序员对项目的贡献更大。
  • design doc 是啥？#Todo
• 作者找了些super productive的人结对编程，每次都有收获
• 除了努力，你还需要不断想办法创造机会
• 最后，作者强调自己的原技能和经验并不一定对读者有用。大果并不一定有大因。读者还需要根据自己的情况自己探索。。。“In conclusion, life is messy and I don't have any advice.“
• PS：下次阅读时，重点看下文章给的其他链接。