对于写代码和编写程序来说，放到今天稍微学习一下 Python 和 JavaScript 这类编程语言就可以实现满足自己需求的应用程序，因为已经有很多很好封装好的框架共我们开发者使用，乃至一个中学生都不需要懂一些数学知识，调用相关的 Math 包就可以进行高等数学相关计算。现在有许多高级的编程语言和优秀的框架，使得开发变得更加容易和高效，Python 和 JavaScript 等语言拥有丰富的生态系统和强大的社区支持，为开发者提供了各种各样的工具和框架，使得构建复杂的应用程序变得更加容易。
上文提到从需求变成编程再到程序，需求是代码编写者对于软件系统所需功能和特性的描述，例如实现一个四则运算计算器程序，可以是在程序直接编写 console.log("20 + 4 = ",20 + 4) 这种形式来完成需求，也可以是实现一个漂亮的界面完成对应的需求。从 IDEA 到 Coding 到 Product 这个过程中 coding 环节是属于技术实现环节，实现某个功能可以有很多种技术方案，但是方案这么多作为程序员如何选？
主流开发的软件都属于应用软件，目前跑在电脑上和跑在手机上的应用软件并没有一些本质区别，都是程序员将自己的大脑逻辑抽象通过代码的形式告诉计算机，当执行这段代码运行之后该程序就会按照你编写的逻辑去交给 CPU 执行，只不过 CPU 要比我们脑子里面计算快得多。这个过程就是 Coding 阶段不能确保程序员大脑里的逻辑一定是正确的，当不合规的逻辑被编写到程序代码中，就可能会产生很严重的后果，例如程序崩溃导致的事件。在电脑和手机只要你开发的不是一些基础的软件，应用软件遇到问题最多就是卡死重启一下，现在的服务器端软件更是搞出来主从或者高可用架构来解决程序员在编码阶段留下的 bug 的问题。
在工业时代崇尚机器自动化，现在计算机程序已经渗透到各行各业中了，天上飞的地上跑的水下游的，飞机汽车潜艇这些设备上都靠着计算机程序在辅助人类完成一些操作。机械工程师在设计一些机械结构时犯下的错可能会导致飞机会坠毁，即使是设计合理的机械结构现在控制这些机械装置的已经不是人类了，是跑在计算机中的程序在控制这些机械结构。所以一架飞机或者自动化驾驶的汽车出了事故，责任不完全在机械工程师身上，更有可能的是编写软件的工程师导致的。
即现在从一名普通人转行为一名程序员太容易了，普通人通过特定的 IT 培训经过几个月的训练就可以写代码，此种工程师可能不具备专业的 CS 知识就可以动手写程序了，带了问题就上面所说的不可靠软件，如果需要开发专业型的软件还是需要专业型的知识作为铺垫的，例如让一个学土木工程或者做建筑设计的去做软件工程师，那就对应上了中文的俗语 “隔行如隔山” 。一些知名计算机科学界的先驱们就提出了点观点 Dijkstra 曾说过：
简单的工具容易被使用，但是会让使用者不去思考背后的原理，导致缺乏逻辑思维和不去思考事物的本质。这在日常生活中使用的智能手机可以拍照可以打电话可以玩游戏，但是发明和制造一台手机所需要的知识远远不是一个人就能做到的，是一个跨学科和跨领域合作的产品。现在用电脑写一篇文章的时候打错字可以回退修改，但是如果在纸上你写错了一个字可能就报废一张纸，解决办法则你可以使用铅笔进行写字配合着橡皮擦使用，古代人使用毛笔更需要思维和手法练习才发展出来了书法行业。
现在已经很少有人去使用了 COBOL 语言进行程序设计了，虽然我本人也是没有写过，但是在研究一些 PL 过程中了解到 COBOL 这门 PL 语言属于结构化加命令式结合产物。但是新的流行语言例如脚本语言和弱语言 JavaScript 和 Python 这些只有在运行的时候才能确定某个变量的类型，还有 C/C++ 这类有空指针设计的 PL ，也会带来底层软件的 Bug ：
使用这里语言开发的程序如果程序在开发期没有有效找出 bug 或者程序员的逻辑错误导致 bug 产生，当程序发布之后这些带有 bug 程序会被发布到线上环境，可能在未来的某一时刻会因为这些 bug 导致程序出现故障从而影响到整个系统。一些隐秘的 bug 不一定尽快被修复，例如一个计算闰年和数据类型存储精度丢失的 bug ，要导致触发这个 bug 条件是当前是时间是处于闰年或者闰秒才会发生错误。这类隐秘的 bug 是开发阶段程序员逻辑错误导致的没有处理好，在修复的这些 bug 过程中需要花大量的时间解决，如果在开发这些涉及相关领域知识软件系统时应该提前去查看一些相关领域的资料文件，使用一些业绩主流的解决方案，例如被使用最广工业级时间库，来减少不必要的找 bug 和修复 bug 的时间浪费。
现在内存安全的编程语言研究有很多了，但是能作为系统层开发的编程语言屈指可数，除了 C/C++ 这两门语言以外近些年也出现了能替代他们的编程语言例如 Zig 、Rust 这些编程语言，当时目前具备这样的能力程序员还很少，还另外一种解决方案使用静态程序分析产品来提高代码和软件的质量。
应用层的内存安全编程语言更不用说，目前主流的 Python 、Java 、C# 、Ruby 这些都属于应用层的编程语言，但是应用层编程语言大部分都是脚本和解释性语言，能作为工业级程序设计的也就只有 Java 语言为主流了。很多人在开始一个新项目之前都会尝试使用新比较时髦技术去开始试错，尝试比较新的编程语言去写新的项目，风险比较大，而且很多解决方案也没有一个主流统一的企业开发标准，例如 Java 是有企业开发标准的。最典型的例子就是 Go 语言，Go 语言在很早之前连一个包管理工具也没有，统一包管理工具也没有了，这就导致每个团队都各自搞各种的开发依赖包解决方案；包括现在依赖包管理工具也不是那么成熟，很多开源的第三方库，从 v1 版本升级到 v2 版本时，是直接弃用掉 v1 方式的 API 设计，导致再次使用新版本时会重新去学习新的 API 使用方式和在源代码里面更改 v1 包路径映射到 v2 版本上，这也是浪费大大时间的。
在程序员技术圈里经常流行一些鼓吹某些编程语言和技术方案的案例，实质为其争吵起来。一些编程语言脑残粉那种会鼓吹某个编程语言，当然一些也是抱着相关技术布道的目的地。很多某个语言脑残粉就会盲目的推崇某个语言，在大公司里有足够的人力和财力，开源让一些人去试错，但是试错是有代价的。选择 PL 还是要根据场景来的，例如开发高性能的网络 IM 聊天服务器应用，只要能实现网络通信的 PL 都可以去实现。那如何去选择对应的 PL 呢？但是如果从事迹开发角度来说你考虑内存占用吗？考虑实时性要求吗？考虑性能要求吗？还是考虑团队综合技术水平和开发效率时间快慢问题？
不要试图去说服和你观点不一致的人，因为很多人它的认知和所需要的领域知识不及你全面，而且讨论问题的你还要帮助他去科普某些知识细节，交流起来很费劲。某些脑残粉给予给你扣上一个帽子，某些情况下一部分人就是故意在讨论中参入一些不相关的话题扯开话题或者故意添加干扰原本话题源的质量；参入讨论的前提跟你是一个层级的人或者说是有具备相关领域知识的人，如果观点不一致的双方可以互相尊重交流和倾听求同存异的面对观点进行交流沟通。
能够正常沟通前提是双方获取的信息来源都是相同一致的，很多系统在设计阶段采用的方案因为信息不对称信息获取问题，导致此用一些不是主流解决方案和技术栈，这会导致自己在某些新技术栈下走其他成熟技术栈道老路，出现了问题和 bug 也找不到官方的文档和相关的问题解决方案。那如何选择技术栈呢？我一直坚持一个观点就是从源头获取信息，例如通过 Google 搜索统计和当下流行技术栈，还有招聘网站上 JD 大多数公司所使用的技术栈来判断。例如使用 spring 框架可以去 spring 官方技术博客和文档上获取，而不是在互联网上看一些其他人已经生产的二手文章和二手信息。通过数据来说话，主流的技术用什么，解决了什么样的问题，以前有没有这样的方案，二者对比弊端呢，再配合自己应用场景做选择。
在中国大陆因为一些特殊原因不能正常访问国际互联网，这也是程序员获取信息源的阻碍，可以尝试着在 GitHub 和 Twitter 找到相关领域专家进行交流，一般这些技术框架或者开源软件都会提供相关负责人的邮箱地址，通过此种方式就能和一线的技术专家交流了。
很多国内程序员喜欢通过技术图书来学习国外新的技术，其实很多一部分技术都提供了官方网站和官方文档，通过官方资料去获取信息是最为正确的方式，但是弊端是官方的文档只是介绍如何使用这个技术和为什么要这个技术，还有一些使用此技术优势。但是对应真正开始尝试使用这些技术时，又不知道如何和现有系统做整合。此时可能就会在互联网上查别人的资料和购买技术图书，我不推荐国内的技术图书，很多都是将官方文档抄袭就出版了。我个人比较推荐使用所使用技术栈方案对官方出版的图书进行学习，因为这是官方团队成员所写的，没有谁能比这项技术的作者更为了解这项技术本身，所以推荐找到学习源头获取技术知识。
