Is is still worth it to learn to code?

简介 这是我看TJ的一个视频,不能说有感而发吧,但确实引起了我的一些共鸣,时间有限在这里做些简单的记录和总结,后续有时间再更系统地写自己的感想吧。转载请注明出处。 观点提取 其实大家想问的是:我是否仍然能够通过学习编码时所学到的技能获得报酬 软件不仅仅是编码 编程本身不仅仅是编码 人工智能将能够完成初级工程师目前面临的编码任务,人工智能将能够比那些初级工程师更快、更便宜地执行这些任务 人们不会为代码付费,他们肯定不会付费只是为了观看你的代码,除非你是一个 twitch 流媒体:) 他们支付的是要解决的问题,当你编码时,你不会因为该代码而获得报酬,你会得到报酬来解决别人的实际问题或感知到的问题 你获得报酬的原因是因为你为某人解决的问题(这里后续展开说说,技术/业务间的关系),而这个关系足够有价值,让他们足以放弃他们"心爱的现金",这可以归结为软件 能够提供比以前更快、更便宜或更可靠的东西。 软件是那些直接在计算机中输入的编码任务的超级集合,因为你需要的不仅仅是好的算法或好的类型系统 你需要理解客户需求需求并在情况发生变化时更新它们,你甚至可能会要出来与客户或利益相关者交谈,所以你要练习沟通技巧。 沟通也包括很多非技术方面,有时你需要向非技术人员传达技术概念 需要能够对您专业领域内的人员说不 项目无法正确完成所有事情 对想做但是成本过高的事情说不 它的价值是什么 软件和制作软件有社交方面的因素,比如倾听反馈和提供建设性反馈,有指导和被指导,有耐心、善意和尊重,所有这些都创建了通常看起来像团队的团队,更有效地创建软件,询问和理解诸如我们如何在这家公司赚钱之类的问题 我曾经工作过的最好的软件开发人员在所有这些方面都很出色,包括编码。他们肯定很擅长编写代码,但他们理解 这些技能中的每一项都帮助我学会更好地完成另一项,只要我们有工作,所有这些技能仍然有用 编程本身不仅仅是编码。两类程序员,一类是解决方案复制者,一类是问题解决者 解决方案复制者不仅仅是使用复制粘贴解决方案,而是使用复制粘贴解决方案来解决复制粘贴问题,而无需检查和确认(这里他举了个非程序员的例子来进一步澄清这两种类型的区别) 解决方案复制者对事情如何运作不感兴趣,他们只是一个一个接需求。他们不知道不同的库、语言和工具可以解决他们的问题的方式,或者可能无法解决他们的问题,他们只是复制粘贴StackOverflow上问题中的第一个解决方案,或者现在可能是他们最喜欢的 llm,直到CI变绿为止,而不考虑他们当前所处环境 这不仅仅限于我们一直在谈论的技术问题,可能是他们对如何赚钱或者他们的客户想要什么,也许他们从未考虑过「我们自己组织的结构是否可以帮助我们实现我们打算做的目标和愿望」 相比之下,我们有问题解决者,这些都是好奇的人 他们试图通过理解来解决问题,我认为即使我们不再编写一行代码,这些技能仍然有用 我认为人们低估了他们可以通过软件开发再次学习的技能。 我的观点是,即使你已经编写代码很长时间了,也有可能不学习这些,也不练习这些。例如 例如,我认为逻辑思维是我们在做软件时可以练习的东西 开发中,我们可以练习将大问题分解为更小的问题 我们可以致力于识别迭代并为客户解决问题,他们实际上愿意为您付费,以便可以更好地进行领域分析,正确理解问题集可能的解决方案,然后如何实施一些业务逻辑或流程来解决问题 可以致力于预测这些流程的边缘情况或故障模式 学习如何管理/解决工程中的权衡点 模式识别 这对我们都很有用。在我看来,这些技能中的每一项至少都像你可以训练并变得更好的肌肉,你可以使用软件开发作为进行训练的工具,只要我们有能力,所有这些技能都将再次有用 这些在工作中的软技能,其实与我在软件部分提到的软技能一样(然后举了两个Neovim相关的例子) 您可以用任何您想要的技术替换 neovim, react、rust、htmx、Excel等等,模式和想法是相同的,我的最终观点是您可以 选择你将如何解决问题以及你从实际解决问题中获得的收获,从单纯的复制粘贴转向"Problem Solver" 在实际的例子中,你可以尝试为自己构建一些东西来做到这一点解决你遇到的实际问题。如果其他人已经构建了它也没关系,重点是你要为自己构建它,看看你是否可以解决这个问题 为自己构建一些东西的时候,你就是自己有效反馈,让你知道你是否解决了问题。如果你没有解决,那没关系,你可以重复。失败是可以的,这是我们学习的一部分,重要的是我们利用我们的粗糙和坚韧再次尝试 但要明确的是,我并不是说解决方案复印机是坏人,或者我不喜欢他们,相反,我试图传达这样的信息:如果我开发的所有技能都围绕着重复现有解决方案(拾人牙慧),我会更担心。对我来说,现有的解决方案似乎是一个更有可能通过人工智能以某种方式实现自动化的领域 对我来说有这样的建议,比如保持好奇心,注意努力工作,不要害怕失败。那些从来没有真正让我误入歧途。在我看来以这种方式思考是正确的,无论人工智能如何快速和彻底地扩展到其他软件领域 我不知道未来会是什么样子我 我只是一个普通凡人。但我确实认为,即使不考虑我在整个视频中提出的所有论点,如果你当前的假设是数十亿行新代码将会产生,那么重要的是真正理解有关代码的一些事情,不是所有的事情,不是每种语言,不是每种框架,不是每种类型系统,而是关于软件本身的一些事情 在我看来,与您可能拥有的任何其他可能的技能相比,这似乎是一项更有益的技能 我希望这可以鼓励你在你的软件中努力学习和努力工作,并且也有一些信心,即使我们在编写代码这件事情本身上完全被淘汰,我们正在学习的很多内容都非常有用,并可以转移到其他领域 附录Appendices 原视频

April 4, 2024 · 1 min · ChaosNyaruko

Should I learn vim in 2023?

Introduction Vim is one of the most well-known editors(the other one is Emacs), maybe “infamous” for its steep learning curve. . Nowadays there are lots of good editors/IDEs(VS/VSCode/Atom/SublimeText/Jetbrains-series/…) for programmers, so one might ask, should I learn the ancient editor in 2023? TL;DR It depends on your workflow and habits. In general, if you “have to” or “like to” use command-line tools in your workflow, then “yes, you should learn at least basic vi usage”. If not, learning vim may not be that helpful, but personally I still recommend you to do that. ...

March 5, 2023 · 3 min · ChaosNyaruko

Rob Pike's 5 Rules of Programming

Rob Pike’s 5 Rules of Programming Rule 1. You can’t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you’ve proven that’s where the bottleneck is. Rule 2. Measure. Don’t tune for speed until you’ve measured, and even then don’t unless one part of the code overwhelms the rest. Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don’t get fancy. (Even if n does get big, use Rule 2 first.) Rule 4. Fancy algorithms are buggier than simple ones, and they’re much harder to implement. Use simple algorithms as well as simple data structures. Rule 5. Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. Pike’s rules 1 and 2 restate Tony Hoare’s famous maxim “Premature optimization is the root of all evil.” Ken Thompson rephrased Pike’s rules 3 and 4 as “When in doubt, use brute force.”. Rules 3 and 4 are instances of the design philosophy KISS. Rule 5 was previously stated by Fred Brooks in The Mythical Man-Month. Rule 5 is often shortened to “write stupid code that uses smart objects”.

January 20, 2023 · 2 min · ChaosNyaruko