一、X-Y问题
X-Y 问题的本质是沟通问题。需求方或提问者没有清晰地阐述自己真正想要解决的问题 X，而是将自己假设的解决方案 Y 当作问题本身提出来，使得解决问题的方向出现偏差，浪费了大量的时间和精力。
举个例子：学习的时候大部分人写项目或者刷算法遇到代码不能运行了，不会给别人说自己正在解决什么问题，而是会说：“诶，XXX你看看我这个代码怎么报错了”，被提问者还要自己看代码理解代码的意思，这样可能会导致陷入到提问者的思维里面，我们会花费大量的精力去试图找到代码问题所在，但如果提问者的思路本就不能解决问题，除了跳出思维，其实想不到解决办法。
对此，当作为需求方或提问者，要尽量清晰、全面地阐述自己面临的问题 X，包括问题的背景、产生的现象、期望达到的结果等，而不是直接给出自己假设的解决方案 Y。
作为被提问者，要学会深入追问，多问几个 “为什么”，通过不断追问来挖掘出真正的问题 X，避免被 Y 问题所误导。
二、T 型学习模型
T型能力模型是软件工程师职业发展的经典框架，强调“深度+广度”的复合能力结构。它帮助工程师避免成为“窄专才”或“浅通才”，而是成为既能解决复杂技术问题，又能协同跨领域团队的高效人才。
相对于前后端，我们现在正处于后端的“深度”学习，但是相对于后端的各个部分，我们又像是在 “广度” 学习，关于这点没必要纠结，我们必须要先具备可以完成一些工作的能力，再去提高完成工作的效率不是嘛。
❌ 盲目追求广度：学一堆“入门级”技能（如同时学Python/Go/Java但都不精）。
✅ 用项目驱动学习：通过搭建个人博客（涉及前端/后端/部署）自然扩展广度。
❌ 忽视软技能：技术再强，无法清晰表达（如写不好设计文档）也会限制发展。
三、 好的代码是读出来的
很喜欢一句话：代码是写给人看的，只是恰好能被机器执行。
作为小白，我们不要认为自己的代码就是好代码，有空一定要去看看别人的代码，养成读代码的习惯，比如你身边学的好的人，或者网上开源的，到了工作的时候，可以看看公司大牛的代码，他们的代码一定有可取之处，甚至有很大的差距。将别人的代码优点努力糅合到自己代码里面。
❌ 只读不写：读代码后必须动手实践。
❌ 贪多求快：精读一个小模块比泛读整个项目更有价值。
