时间和项目管理
本周最大的 project 是一个软件工程大项目，要求独立 deliver。这个项目让我感觉到最头疼的地方在于：1. 技术栈的熟练程度导致 troubleshooting 比较耗时 2. 没怎么写过业务前后端，所以在限时 deliver 的时候几乎没有正反馈和心流。
在规划中，这个项目大概 15-20 个小时，实际上这个时间被低估了（助教其实不止一次提醒我们 start early，但还是低估了）。体感上本周完全耗在了这上面（>30 个小时）。但实际上，周一周二因为别的事情只 track 了 2 个小时，剩下两天的时间疯狂输出，实际上每天肝了 10 个小时的样子。周二是万恶的本源，为了晚上喝了咖啡，干扰了睡眠，接下来两天的工作专注度显然下降了很多。
总结：
- 看起来最快的方法永远是快糙猛，但是这并不是最有效的做法，即使是看起来并不复杂的全栈项目。相反，test-driven 和提前规划好 milestone 可能会让这个项目。
- 写业务代码是很 trivial 的活儿，但及时如此，GPT 和 Copilot 仍然不一定是对的。supervise 和 test 的工夫一点也省不了。有点理解了
- 睡眠是一个长期无解的事情。我总感觉自己生物钟是按照 26 小时算的，但是没办法，还是要多睡觉。睡眠不行了，服用各种刺激前额叶的物质效果也会大打折扣...
- 另一个长期无解的事情是有时间的时候不一定有精力，有精力的时候不一定有热情 / 专注。我在最 energetic 的时候也许能学新东西，但是不一定能写 code；而感到疲乏的时候，code 的质量也不会很高。而这个中间节点就变得很 tricky 了。
Linux
本周学习了一些 Linux 相关的一些零碎的知识，主要围绕 eBPF，CUDA 和 Linux 的底层工具。目前在看的学习资料有 BPF Performance Tools: Linux System and Application Observability 以及 ebpf.io 的学习路线图。
第一次接触 eBPF 是在 PingCAP，当时大家都在兴致勃勃的讨论如何用 eBPF 实现底层的各种 tracing，给我印象很深。但是真正玩起 BPF 并了解它的业务场景却是很后期的事情了，也局限于一些小打小闹。本科应该是最能正经玩 tech 的时间了，不过还是因为疫情太遗憾了。有机会讲一讲本科科技社团的一些故事。
Misc
- 如何快速得到一个行业的认可？也许是是 1. 在某一特定方向上有独特的积累 2. 在标准化的考试中脱颖而出 3. 对领域文化的 fit 以及认同 4. 运气
- 最近比较忙，再加上前一阵子遇到了国内的一些事儿，搁置了和一些朋友的聊天 (apologize for not being cool). 直到周末休息好了点，我发现这里面还有一个原因：自从来到美国以后，我对前程的顾虑一直是发散的 —— 这里固然给我开启了一些新机会，但也有很多必要的牺牲。
- 最忙的日子也不要忘了运动健身保持精力（