三十才经济独立太晚了吧, 本科毕业就应该开始养家了, 所以肯定不是.
立不是"独立", 不需要参照物, 有自己的价值观和原则, 不轻易改变.

绝对支持 LZ, 我愿意自愿加班, 但强制加班就是 SB.

第一种代码不难懂. 唯一不好的地方是这一行:
pre, slow.next, slow = slow, pre, slow.next
因为这一行做了几件事情, 一行下来对读者心智负担比较重.

@jiankaikey 在这里, 效率并不是需要考虑的主要问题.

很多老程序员急是因为见得多了那些菜鸟程序员过早优化封装, 结果就是还不如不封装; 写代码跟做其他事情一样讲究的是解决主要矛盾, 在我看来这段代码逻辑简单, 也不是什么核心代码, 楼主纠结于此并说很离谱(这段代码确实写的是不怎么样, 我可能也会顺手改了, 但不会太苛责), 那么在面对复杂的核心问题超过楼主的能力时, 这种凡是要抽象封装的理念只会带来错误和难以维护的设计, 危害会比更少设计来得大.
说到 Code Review, 讲一个笑话: 一个人去 update 一个开源代码, update 几行的时候几个核心程序员讨论了半天才 Approve; 当 update 超过几百行的时候十分钟(run 完 unit test)就接受了.

再看了一下楼主的补充, 自己也说了有"新"的需求, 新需求带来代码或者结构的变化是正常现象. 以我多年编程经验来看, 过早的优化比不优化其实危害更大, 不优化大不了重写一部分逻辑, 过早优化改的时候还得把所有优化过的逻辑拆开重装.

封装意味着多一层抽象, 会多一层心智负担, 所以需要有代码清晰度的提高或者减少重复来作为补偿(比较明显的结果就是封装后代码行数明显变短). 楼主同事的代码没什么大问题, 更谈不上"离谱", 经过优化后代码并没有明显的代码量的降低.

架构经验是慢慢积累的, 作为新人, 我觉得关注点还是多琢磨怎么写好代码上面. 先把自己用的程序设计语言相关的书看上至少两本, 一本包含所有知识点(不是为了用到所有的犄角旮旯都用到,为了看懂别人的代码), 一本包含进阶, 类似 effective java 之类的书;
了解项目用到的框架, 如果是 java 的话, 比如 pro spring, pro spring boot, High-Performance Java Persistence
然后就是怎么整体写好代码的书, 比如 clean code, clean coder, code complete (还有很多)
架构上主要还是多思考, 多看看别人的架构. 书的话也有很多, clean architecture, patterns of enterprise application, design data intensive applications, building microservices
读完书多实践, 为自己每一行代码, 每个架构决策都能找到这样写和这样决策的理由.

很多工具不错, 有没有办法跟 Alfred 一起工作呢? 比如程序支持参数化输入什么的.

持续学习, 保持为一个人才.

一个月是基本操作, 下家明显不尊重候选人.

怎么变成知乎: 分享现编的故事了...

LZ 跑一下我的 SQL 就知道了 , 为什么还在问呢?

假设表结构为 student (id, name, grade).
完整不考虑效率的 sql

select f.id as id, f.name as name, f.grade as grade from student as f where f.grade >=
(select max(e.grade) as cutgrade from
(select sum(d.acount) as count, d.bgrade as grade from
(select a.cnt as acount, a.grade as agrade, b.grade as bgrade from
(select count(id) as cnt, grade from student group by grade order by grade desc) as a join
(select c.grade as grade from (select distinct grade as grade from student order by grade desc) as c) as b
where a.grade >= b.grade
order by bgrade desc) as d group by grade order by grade desc) as e where e.count >= 10)

不专门刷题的能在半个小时做出来的程序员素质不低了, 取名字那一步会出现并列第一名的情况, 规则没说按照什么逻辑来选择.

1. 女朋友也有给 LZ 买东西;
2. LZ 也是稀里糊涂的;
3. 女方家人没毛病: 成年人要对自己负责, 知道影响学业也帮了, 既然是两个人去的, 他们也不清楚谁花了多少钱, 男的承担没毛病.

node.js 的强项是前后端可以用同一技术栈. 弱项是后端生态不完善, 第三方库质量参差不齐. CPU 密集型不合适我理解主要是指一些极端场景效率不高(但是我极度怀疑这些极端场景会用 node.js 来实现). 实时返回不代表要同步处理或者要在 node.js 层面处理, node.js 很多逻辑天生都是异步的, 放到 worker 中处理即可.