基于反驳网友的话 => 急于

@kekeabab ok 向你道歉，我收回我关于 unsafe 的话。之前没看你的 repo ，看另一个人的评价，以为你代码里 unsafe 到处飞。刚才看了一下，你 20 多个 repo 里有 5 个是 Rust 的，只有 msrs 里有些要包装系统 API 的广泛用了 unsafe ，其它 repo 倒没有。

然后就是另一个问题了，从这些 toy project 确实也看不出你的真实水平如何。就像你前面说的，都是自己写着玩或者自己特定场合下使用随手写写的。没人为这些 project 付你钱，你还要迫于生计奔波，没动力按产品水准来实现比如命令行参数之类的特性。但另一方面，既然是把 repo 贴过来让人看到了，那至少在你心里这些 repo 应该不会是减分项，应该能成为你在学历偏低、技术发展也遇到瓶颈从而影响个人职业生涯的情况下，还能得到技术圈认可你热爱技术的依据。从这个角度出发，其实是有一个死循环：自己写着玩不需要产品级的实现 -> 只有 toy project -> 没机会实践产品级开发 -> 没有能引起用人单位注意和认同的 project -> 找不到能体现自己价值的工作 -> 只能自己写着玩不需要产品级的实现……

而且还有另一个问题，你自我评价是比较 geek ，然后玩 Lisp 、go 、rust 这些比较小众的语言（ go 相对来说还不算很小众），不想碰 Java……那么你到底是太功利呢还是太不功利呢。说功利吧，快要活不下去了还玩小众技术；说不功利吧，别人建议你 Github 上的 repo 里要多考虑，要脱离 toy project ，你却因为没有直接的实际好处而不愿意做。要我说，你要么认清现实，你现在没底气玩小众技术，为了养活自己还是要先走大众路线，Java 该用就用，PHP 也不要嫌弃，这些都是容易找工作的语言，先活命再说……要么就是找份其它的工作（非 IT 类的），技术上可以继续玩小众，继续 geek ，但是在有其它工作养活自己的情况下，花点精力做好你的开源项目，但不要满足于 toy project ，同时也要补基础课。在开源项目里体现出你的技术水平，体现出你的“价值”。

再就是，建议不要应激反应太强烈，基于反驳网友的话，尤其是没必要对别人的回复里抓住一两句话的不当之处跳起来。因为说服网友没用，你要说服的是用人单位，要给用人单位证明你的价值，证明你哪怕学历不高但你有足够的技术水平，让他们认为你值得他们不去看学历。

不用部署，就一个本机数据文件。

凡是能用 web 套壳重写的，一定会用 web 套壳重写……

求职不是求知。沙雕的公司 /面试官 /HR 很多，没必要非要咽不下一口气要个说法。尤其是这种涉及惯例达不成默契的人为因素，自己有数知道自己没问题就行了。

计算机技术是博大精深的，需要打好好几个方向的基础，再在好几个专业方向深耕。不是凭直觉看了几门编程语言的语法入门，再凭小聪明就能学好的。
有很多人在成体系长期学习计算机技术之前容易误以为自己对计算机技术很感兴趣或者有才能。实际如何还是需要事实来检验。
还是建议 OP 先解决了养活自己的问题的前提下，抽出时间来慢慢学习，补好基础。以前逃避学习，欠下的人生债，终究是要还的。
其实 OP 不必焦急。大概是互联网时代容易看到被刻意渲染出来的“成功 IT 人应该 35 岁退休”的鸡汤案例和更多 35 岁没成功退休只能被裁员的极端真实毒案例，有的人会觉得在这风风火火的速度下已经不能再静下心来花几年时间学习，学几年就错过了同龄人的成功之路。其实就算你现在补回以前逃避了的学习，几年之后再入场，人生也还是上半场的前场呢。

另外虽然你看到有些批评你的表述可能正好触动了你心里最脆弱的地方，但希望还是能尽量让自己静下来，不要急着反驳，更不要明明是抬杠了还一遍遍强调不是抬杠。比如关于 unsafe rust 的认知，只能说你根本没理解 rust 的 safety 背后的理念和 unsafe 的使用场景。基本功和见识不够，还是尽量谦虚一点吧。

打字太多，拆键盘太少

认真的工作环境，应该拒绝使用家用路由器这种为特定场景优化从而导致对其它场景劣化的设备作为路由器角色。

好好写你的能“带来直接收益的项目”的代码，别胡思乱想。等你写多了，遇到的问题多了，现有的库、框架不能称心如意了，或多或少也会去动手搞点基础设施。人家厂子大，那搞的基础设施就更大、更多、更通用、更牛叉、更出名。

看到这名字我第一反应是支持 CAS 协议…

健身环大冒险，舞力全开

椭圆机

小型运动器械

@pusheax 甲方表示有苦说不出，做业务系统开发的那些地方性、行业性的供应商，除了被甲方锤着勉强把业务功能凑合实现之外，其它真的是什么都不懂……还一个个拽得。

不熟悉 MySQL……

对 Oracle 和 MS SQL Server ，N 和非 N 的区别在于如何算长度，非 N 的版本是按字节算的，N 版本是按字符算的，所以一个 NVARCHAR(6)是不论哪国文字都 6 个字符，而 VARCHAR(6)跟具体的库所用的编码和文字内容有关。

而 PostgreSQL 统一按字符数算，不需要 N 版本。也就是说 PostgreSQL 里的 VARCHAR 等于 Oracle 和 MS SQL Server 里的 NVARCHAR 。

运维和安全也是专业性很强的工种，有自己的知识体系和技能要求。会做开发、做职能管理的人并不是自然而然凭直觉就会做运维和安全的。

不怕出错，就怕前面出过的错后面还继续出同类型的。还是要有总结和改进才行。

硬撑。运维类的工作就是靠知识积累和经验积累。多撑撑，踩坑踩足够了，经验丰富了，就害了。
当然，持续学习是必须的。

@Macolor21 所以呢广大地行小的尴尬之处在于，“基础扎实（ cs 四大课）”的、“学习能力够好”的 crudboys 都去一互大了，地行小哪怕是开出更高一些的工资都招不到靠谱的人，更何况地行小不太可能有实力给基层的 crudboys 们全员开出一互大的工资……另外还有个尴尬就是，一互大们的一些相对资深员工被输送到社会，进入各行各业的业务信息化领域当 CTO 、架构师之后，会把一互大的方法论带出来，但是这些方法论有的是要一互大的规模才有条件实行，有的是要一互大的人才层次才能实行……

@Macolor21 因为数量广大的地方性、行业性、小体量的行业信息化系统开发商可能不太撑得起独立的 infra 组这样的组织架构。而 crudboy 在这种团队里也不仅是因为分工不同而做专注业务的代码，而是新人进来只能先从 crud 开始。这样的公司，架构性或者基础性技术的人员基本上只能从做 crud 的新人里慢慢分化出来。在实际工作中，地行小的 crudboys 也不可能只管业务逻辑，肯定要去写一些具体的“技术性”的代码，比如跟操作系统 API 交互，比如处理一些安全相关的操作等。而他们中的大多数人，基本上都是基础知识很差，一到要写这些代码就麻爪。作为一个甲方的信息化综合管理人员，我甚至手把手教过一个乙方程序员如何写 Java 代码来调用我们在 Kong 网关下用 HMAC-SHA 认证保护的 API……

其实最主要的问题是，地行小没有一互大的光环，即使用同样的工资也是招不来同样的人的。l

去公证处做公证翻译。