The Joy and Power of Understanding

2026-06-22

Deeper understanding of the code and software systems we work on, is not only pragmatic and practical but highly enjoyable as well. The usefulness is quite obvious: understanding gives us control and ownership of the systems and code we are responsible for. What we do not understand, we can neither fix nor change. 对我们所从事的代码和软件系统进行更深层次的理解，不仅具有务实和实用的价值，而且本身就非常令人愉悦。其有用性显而易见：理解赋予了我们对自己所负责的系统和代码的控制权与所有权。如果我们不理解，就既无法修复也无法更改。

Interestingly, that deeper understanding not only allows us to be masters of our tools and not their slaves, but also is simply fun and brings lots of joy. There most likely are solid evolutionary reasons behind it - why is comprehension so psychologically satisfying? It actually makes a ton of sense - behaviors and traits that increase our control over the environment should be accompanied by feeling positive emotions strongly. 有趣的是，这种更深层次的理解不仅让我们成为工具的主人而非奴隶，而且本身就很有趣，能带来许多快乐。这背后很可能有着坚实的进化论原因——为什么理解在心理上如此令人满足？这其实非常有道理——那些能增加我们对环境控制力的行为和特质，理应伴随着强烈的积极情绪。

But, if it is both joyful and powerful, why are we so often prone to skip the struggle to understand and take shortcuts, accepting copy-pasted/generated solutions and generic answers, not analyzed? 但是，如果理解既令人愉悦又充满力量，为什么我们却经常倾向于跳过理解过程中的挣扎，转而走捷径，接受那些未经分析的复制粘贴或生成的解决方案以及通用答案呢？

Human Nature

人性

At our core, we are lazy beings, driven to minimize our energy expenditure and maximize returns on its investment. This laziness can be a great motivator to automate tedious and expensive processes and tasks, but at the same time, it is our inherent flaw when it comes to learning, expanding our knowledge, skills and by extension - control, influence and power (in healthy hierarchies based on competence). 从本质上讲，我们是懒惰的生物，倾向于最小化能量消耗并最大化投资回报。这种懒惰可以成为自动化繁琐且昂贵的流程和任务的强大动力，但同时，在学习、扩展知识、技能以及由此延伸的控制力、影响力和权力（在基于能力的健康层级中）方面，它也是我们固有的缺陷。

In the context of a need to understand, given how many answers & solutions to similar problems are available out there on the Internet - recently even more than ever before and in the exact form we need, thanks to Large Language Models (LLMs) - it is no wonder why people skip on understanding so often by taking those shortcuts. 在需要理解的背景下，考虑到互联网上有如此多针对类似问题的答案和解决方案——得益于大语言模型（LLMs），最近这些答案甚至比以往任何时候都更精准地以我们需要的方式呈现——难怪人们经常通过走捷径来跳过理解过程。

Unfortunately, there are many pitfalls in accepting something that seems to work but we cannot explain how and why. After all, why bother with learning the syntax and inner mechanisms of SQL (or any other query language), when we might just tell the LLM what tables are there and the data we want to retrieve. It is way easier to write a messy English prompt and copy-paste the result than to learn how to do it properly ourselves. 不幸的是，接受一个看似有效但我们无法解释其原理的东西，存在许多陷阱。毕竟，既然我们可以直接告诉 LLM 有哪些表以及我们想要检索的数据，何必还要费心去学习 SQL（或任何其他查询语言）的语法和内部机制呢？写一个混乱的英文提示词并复制粘贴结果，远比我们自己学习如何正确地完成它要容易得多。

And I hear you, some people would say something along the lines: Why should I trouble myself with constructing SQL by hand if I know it? LLMs can do it much faster for me and I do not lose anything, since I am already perfectly able to write and read this language. Well, it really depends; you might be capable of reading and understanding it today, since you have done it repeatedly by hand in the past, but this ability will diminish over time. Eventually, we do lose what we do not use - and passive reading is not enough to keep these skills sharp. 我明白你们的想法，有些人可能会说：如果我已经掌握了 SQL，为什么还要费力去手动编写它呢？LLM 可以帮我更快地完成，而且我并没有损失什么，因为我本来就完全有能力读写这种语言。嗯，这真的取决于具体情况；你今天可能具备阅读和理解它的能力，因为你过去曾反复手动操作过，但这种能力会随着时间的推移而减弱。最终，我们确实会失去那些不使用的技能——仅仅被动阅读不足以保持这些技能的敏锐度。

Sure, you may argue that since there are LLMs (and other reusable solutions), we will never have to write these types of things again and that the skills of searching, prompting, reading and verifying LLMs’ output is all we need - it is the future. Well, given how LLMs work under the hood (probability), I would say that it is a highly optimistic and unfounded claim (ignoring LLMs long-term sustainability for now). Regardless, at their best, LLMs and other search engines are force multipliers - but we must have the force first and keep it strong. 当然，你可能会争辩说，既然有了 LLM（以及其他可复用的解决方案），我们再也不需要编写这些东西了，我们所需要的只是搜索、提示、阅读和验证 LLM 输出的技能——这就是未来。然而，考虑到 LLM 的底层工作原理（概率），我认为这是一个过于乐观且毫无根据的说法（暂且忽略 LLM 的长期可持续性）。无论如何，在最好的情况下，LLM 和其他搜索引擎只是力量倍增器——但我们必须首先拥有这种力量，并保持其强大。

What is this force exactly? It definitely is not the ability to prompt and read the output. I do not see how we can develop and keep it sharp, if we are generating and copy-pasting solutions (maybe with a bit of refinement) all the time. Fortunately or not, struggle is a necessary component of deeper learning and mastery. 这种力量究竟是什么？它绝对不是提示和阅读输出的能力。如果我们要一直生成并复制粘贴解决方案（或许稍加润色），我看不出我们如何能发展并保持这种力量。无论好坏，挣扎都是深度学习和掌握技能的必要组成部分。

Of course, context is king here. For some skills, areas that we rarely use and do not care about that is totally fine, but our core skills and knowledge regularly used must be kept as strong as possible - otherwise, what is that defines us as software developers and problem solvers? Isn’t it exactly our knowledge, experience, judgement and skills? It is impossible to develop and even keep it by just reading the code and solutions of other people and machines - we have to be actively engaged in the building and creation process ourselves. 当然，语境在这里至关重要。对于某些我们很少使用且不在意的技能领域，这样做完全没问题，但我们经常使用的核心技能和知识必须尽可能保持强大——否则，是什么定义了我们作为软件开发者和问题解决者的身份呢？不正是我们的知识、经验、判断力和技能吗？仅仅通过阅读他人或机器的代码和解决方案，是不可能发展甚至保持这些能力的——我们必须亲自积极参与到构建和创造的过程中。

That is why, in the context of understanding, we must fight against our lazy nature on a regular basis - spending much more energy than is required in order to keep expanding our knowledge, skills and by extension - control, influence and power. We ought to read the docs and sources. Grasp the reasons behind solutions under consideration. Know our tools and understand the tradeoffs they introduce. Engage creatively and design solutions & algorithms ourselves - do not just search/prompt and passively verify, hoping to get some working solution; somehow, someday, maybe. 这就是为什么在理解的背景下，我们必须经常与懒惰的天性作斗争——投入比所需更多的精力，以不断扩展我们的知识、技能，进而扩展我们的控制力、影响力和权力。我们应该阅读文档和源码，掌握所考虑方案背后的原因，了解我们的工具并理解它们带来的权衡。要创造性地参与并亲自设计解决方案和算法——不要只是搜索/提示并被动验证，寄希望于某种方式、某一天、或许能得到一个可行的方案。

Short- vs Long-term productivity tradeoff

短期与长期生产力的权衡

Practically speaking, does it always make sense to grasp the code and solutions we work on fully? Of course not - it depends and it is a spectrum. Throwaway script that automates an operation of low importance and risk? Completely fine to copy-paste/generate. Internal UI/page used by two or three people? Same here; nothing wrong with copy-pasting/generating that one as well. 从实际角度来看，完全掌握我们所使用的代码和解决方案总是合理的吗？当然不是——这取决于具体情况，它是一个光谱。如果是用于自动化低重要性和低风险操作的一次性脚本？完全可以复制粘贴/生成。如果是两三个人使用的内部 UI/页面？同样如此；复制粘贴/生成这些内容也没什么问题。

Code and solutions that we will own, maintain and evolve over months and years? They should be created in a language and technology we know deeply and can understand every line, word, character and/or config option (or at least are on a path for it to be the case). Here, we want to optimize for long-term understanding, maintainability and productivity, not the fastest & largest output at this very moment. 如果是我们需要在数月甚至数年内拥有、维护和演进的代码和解决方案？它们应该使用我们深入了解的语言和技术来创建，并且我们能够理解其中的每一行、每一个词、每一个字符和/或配置选项（或者至少正朝着这个方向努力）。在这里，我们想要优化的是长期的理解力、可维护性和生产力，而不是此时此刻最快、最多的产出。

Are there in-between cases? Situations where we might reuse/generate something grasped only partially, requiring us to take more time to understand, fix and modify when such need arises? If we work on a Minimum Viable Product (MVP), not being sure whether it makes sense/is going to work, or an experimental feature within the existing product - it is reasonable to lower the quality and comprehension standards a bit. After all, we cannot yet tell. 是否存在中间情况？即我们可能重用/生成一些仅部分理解的内容，当需要时再花更多时间去理解、修复和修改？如果我们正在开发一个最小可行性产品（MVP），不确定它是否有意义/是否可行，或者是在现有产品中开发一个实验性功能——适当降低质量和理解标准是合理的。毕竟，我们目前还无法断定。