lijingyu68

中美在比赛憋气，找工作也是在比谁更能憋～

28 岁已经失业的路过。。

我最近也在往这个方面转，但现在存在两个问题比较突出，一个是工资太低，二个是学习成本较高。

我个人的想法是先自己玩玩 rust 嵌入式，等市场成熟了跳，本人的话，现在在从事前端。

我觉得很多 V 友没太理解楼主的意思。。。

我理解到的是这样的：
观点 1. 努力会带来更多的选择，更好的生活，更幸福快乐，但现实是没有。这个结论我是赞同的。
观点 2. 努力没有用。这个观点我不认同。

先来说一下努力和选择的关系。显然，它们并没有直接关系。太努力，选择反而会更少。因为社会是金字塔型的，越往上，选择越少。但如果你懂得放弃的话，那选择就更多了。

好的生活分为精神生活和物质生活，不管哪个都与努力都不沾边。努力可能有助于物质生活，但如果在不喜欢的方向上努力的话就会影响精神生活。物质生活好不好，取决于太多因素，比如选择、家庭、人脉、既有资源等等，努力到底能占多大成分，很难说。

幸福快乐和努力也不沾边。因为研究表明，人活的幸福不幸福，更多地在于与家人和朋友的关系，如果你有良好的社会关系，会有更高的安全感，也会更幸福。

综上，在你想要解决的问题上，努力的确没有什么用～

可以出去走走，比如去寺院呀之类的。建议少刷社交媒体，现在网上的牛人多了去了，没必要在意，也没必要攀比。该放弃就放弃，等想明白了，找到方向了，再来也不迟。

想用点数或分数来量化绩效基本都是自找苦吃。

原因有：
1. 分数多的成员干的活的确会多，但干活多会有助于业务成功吗？写代码又不是搬砖。
2. 软件质量的成功很大因素在于团队协作，量化绩效会间接破坏团队协作，损害技术领导的领导自由度，进而阻碍创新。
3. 有的事情无法用点数衡量，但却很重要。比如，对业务的重视程度，技术选择的方向，团队成员能力的建设，促成团队成员的协作，对非技术流程的梳理及知识传递，等等。

那么最好的方式是什么，那就是拆团队，打通团队之间的流动性，考核整个小团队的产出，营造优胜劣汰的环境，并将产出和义务挂钩。

送自己一本《心经》

感觉并没有解决什么实质的问题。看了下，这个东西有点类似 GraphQL，但没有 resolver 的机制，总之，看完后不知道业务逻辑应该放什么地方～。如果后端不放业务逻辑的话，还不如用 firebase，直接查询数据库。

不知道你说的架构是脚手架还是软件架构。。。从你的语言看，感觉更像是脚手架，脚手架的话，跟着各种工具的官方文档做就可以了。软件架构了话，看 领域驱动设计。