@Junzhou 这个也不错，我觉得中间件领域 Java 应该会日益萎缩，也就是大数据还能撑一下。

@gwy15 hhh··我觉得 DP 是最套路的类型题目（不过思路不对就会卡死）。有时候反而是一些单纯的比较麻烦的题目要处理细节有点烦。

因为没办法衡量，也没必要衡量。

----

参考下 https://www.v2ex.com/t/670175，只能和同行业比较，CTO Vs CTO 可是不同的 CTO 的行业又不一样对伐？最后只要你没做上 CTO 就是你很菜，没跑了。

@Junzhou 现在转 Java 不怎么划算，略看好 Rust……

第一次做差不多 1H，做变种就会快很多。一般面试如果不是 OJ 那种判题，只是人工看，那主题对就 OK，甚至于可以减枝的部分可以留一个注释。

挺正常的，人总是要经历一段时间的“虚无主义”的。
慢慢的总能找到一些平衡点。let it be....

这要看地理位置，在我们老家我觉得不可能啊，我爸妈根本不会普通话，我妈选择用手写输入法慢慢写。

这事情我觉得还分 2 部分：

1. 新手可能会堆代码，生搬硬套。
2. 老手要防止过早优化（或者说预留扩展）

我赞成楼主，工作第五年的我同样的困扰，我也在 V2 提问过什么是 技术，不过我最近找到了答案。 我从这本书里面找到了 https://book.douban.com/subject/25846075/ 对于来来说，技术本身就是一个非常看经验的活，当我们的经验能够被复用的时候就变成了组件，事情就开始变的很无聊了。因为就像从一堆积木里面找到适合的东西堆一个东西出来，你不能总能总是喜欢玩堆积木的游戏。

另外其实可以把自己的重心放在技术目标之外，编程的目的是解决问题，单纯的编程不好玩，帮助别人解决问题，可能仅仅是油猴的一个脚本就很有意思，尽量从单纯的技术驱动中释放出来。

最后，千万不要想到的是解决什么高并发的场景这种问题，因为这玩意对于个人来言很意淫，等以后有工作需求的时候再好好的玩。

自从我上了 32g 内存之后，虚拟机常驻。

凑个热闹： http://blog.yanick.site/

不学，Servlet 直接看看 J2EE 的标准里面就说清楚了，其他的要么不属于 Servlet 要么就是具体实现的部分。

@aoscici 可以的，但是还有很多其他辅助手段，比如手机 ID，全家桶里面总有没翻墙的，很容易就分析出来了。想做到影分身就得搞 2 个手机……

IP 地址也可以定位咧，精度不高罢了。

2010 年款的 Thinkpad e430 （ i7-3XX ）换了固态，加了 8g 内存，还能在战 2 年。

---

准备搞个 3900x 的台式机，笔记本的性能太弱了（在轻薄的情况下）

看你职业规划啦，如果希望 WFH 的话学点英语想办法接点外面的单子还是不错的，如果走国内大厂那条路还是要学一个更通用的语言的，倒不是语言重要，因为生态比较重要，小种语言普遍生态较差，从我的观察看 Java 的轮子就明显比 Go 的轮子多也圆一点。

不明白很正常……
讲道理按照逻辑说，的确是应该将 地址直接从内核态作为返回值直接给用户态就可以了。但是在实际上因为安全 /硬件 还有一些历史原因导致，最基础的传递是通过 Copy 来的，之后才出现的 Zero Copy 的技术。

OS 因为要配合硬件，所以不是一个很纯粹的软件设计思想，这个只能按照他的思路来。

给你讲其实大家都差不多是这样的，主要有两层原因：

1. 团队磨合不到位
2. 经验不足：产品经理不知道要交付到什么程度的原型图，后端不能保证 mock 的数据和最终数据一致

其实也没啥纠结的，新团队都会这样的，磨合个一年多就好了，如果在人员流动低的团队，替换的员工可能就会觉得好点。如果一直没磨合好，就要考虑是不是能力问题了。