把业务全流程搞懂，别说你只负责一小部分，不管其余，要尽可能多的掌握全局。近水楼台，身在业内，就是最好的资源，把这个行业尽可能多的吃透。从自己手头的一块，以效率翻倍为目标小范围内尝试革新，累积经验的同时，还能连带了解业务和项目组织的实践细节。有本事把搬砖的重复劳动“自动化”再说。LeetCode 仅仅奔着多少时间能做出多少题去的话，路子就走歪了。不是以搞算法研究为目的的话，只需要作为一个拓展解决逻辑问题的经验去慢慢积累即可。最后，没人逼你拧螺丝，也没人拦着你去学习更多的技能，坚持学习，坚持思考就对了。

@jasamboro 就在 V2EX 建一个节点？用的人多了，说不定 V 站能考虑单独开一个像样的功能出来。

@tctc4869 好吧，从你的描述看，很多人都被引导到 PTT 去了，你不觉得自己的文字表述有些模糊么？
另外，你所指出的“不支持”的功能，仔细看看都是些“可实时互动”的动态效果。
回到常规意义的文档本身来说，为什么需要那么多的互动？这些互动能被打印到纸上么？能转成 pdf ？在静态展示为主的传统文档里，平铺展开就足够了，快速跳转交给目录和索引去完成。动画展示的内容一律通过截图来说明。除了动画和声音外，文字和图片已经足够表达了。不需要额外软体和设备的支持。
当然，“文档”可以包括视频资料和多媒体的互动资料。要实现这些，建议采用 html 或者 markdown 来完成。但这样的展示需要特定的软体支持，使用者才能看到效果，这是有成本的。可能做成网站形式，对用户来说使用负担最小，也较易被接受。markdown 还是太不成熟了。

同意 9 楼的，你把两种不同需求混一起了。
你需要一份 PTT，仅做演示和宣讲。而产品文档就应该是静态的，不要花里胡哨，向字典看齐，事无巨细，方便查找。

这能叫算法？只是一种实操不怎么高明的策略而已。看人下菜碟，可惜端菜的那位也不怎么会看人，只知道一个劲儿地上最近客人点单比较多的菜，简单粗暴，让人觉得这小二真的二。

为啥不行，只要自己的性格和处事能力跟得上，就转呗。同意楼上的，写代码没人拦着你。业余时间还能坚持钻研技术的领导，最受欢迎啦。

这题的解有很多，凭直觉就能做出来。主要考察小朋友的试错能力，同时也能对“科学方法论”进行实践体验。但为什么要升级到图论或者奇偶数点这种纯粹的数学技巧里面去？完全违背了学习数学的初衷。回想下自己的小学阶段，没人告诉“高深的数学解题技巧”之前，你们不都是凭直觉去尝试的么？至于何时才需要去研究更高层次的东西，那不是小学，甚至都不是初、高中生去做的事情。当作课余了解下倒是可以，提前窥探下数学的博大和奥妙，激发兴趣。不要被应试牵着鼻子走，不要唯解题论英雄。陪着娃一起去解决问题的过程，就很好，这就够了。

公司素质可以的话，肯定技术高的，能提高整体团队水平。你不用担心自己技术上不如他 /她，你是技术方面的管理者的话，做好后勤和团队融合即可；技术上的事，实在是高深的，只要大方向不错，用人不疑就行。如果公司规模尚小，则要看目前团队正真缺什么能力的人，保证公司资源用在刀刃上。杀鸡用牛刀，就算公司用得起，大牛还不一定来呢。

锻炼咯，5km 或者举铁，不信你还能睡不好。

宜家的库克斯小闹钟，翻转就能计时，到点响铃。不要什么花里胡哨的 app，大清早把一天要做的事列在张纸上，保证周围干扰最小，每 40 分钟翻一次闹钟，到点起来走动、喝水、远眺、伸展胳臂，核销任务，然后循环。晚上清点下任务单，哪些没完成的，哪些超时的，哪些超前的。习惯后，效率自然能上去，附带的你的人月预估也会越来越准。

这赖不到公立和私立，只能说给你碰上了，运气不好。只要没有发生原则上的失误，这种结果你就得接受，别太把这 6K 放在心上就好了。
医疗很大程度上还是“手艺活”，人为因素限制很大，还不算每个病例的个体差异，没人敢拍胸脯说一定给你治好。这可比修车复杂多了，我也没见哪个高资历的修车师傅每次都能一锤子搞定各种妖怪的问题，总有能力受限甚至失手的时候。更何况这是肉长的人，不是尺寸统一的铁疙瘩。
打听哪里水平高，哪里弄得好，也只多是个“道听途说的”参考。仔细想想，这些病人哪有条件去货比三家，能亲自实验出看哪家医院的疗效最好呢？你只知道某人某次在某医院的疗效还不错，没法横向比较。
就现状而言，多数优质医疗资源集中在公立医院这一条，还是适用的。但这仅说明，在公立医院“大概率”能得到更好的治疗，仅是概率高一点，还是没人能 100%保你疗效。
你的决策是对的，专科大医院、高资历医生，已经是大概率导向好结果的选择。
虽然疗效不是很理想，但只要不是医疗事故或者明显人为事故，那就要接受这个结果。
没必要为了疗效而去自责，有问题就再想办法解决，在能力范围内去努力就够了。

好好沟通，从这贴开始！发出来的贴，自己从第三方角度去读读看，就知道你的成本在哪里了。以后说话前，也这么快速过一遍脑；时不时回味下自己说过的话，多多少少就能发现不少自身原因而造成的成本问题了。解决了自身问题，已经能成功一大半了。

@Mithril 是的，未经许可，哪怕是复制片段，也是侵权。所以我说，想都别想复制黏贴的事。自己留着没造成损失，还能推脱说非主观故意，没删干净。要是造成公司实际损失，那还要另算赔偿。而竞业协议是想说，楼主是否有同行从业的权利，具体怎么限制，要看签了点什么。

API 没有专利的话，可以参考。如果是对外开放的 API，完全可用兼容名义去照搬。
原则上，你不应该保留前雇主的源码，那不属于你。所以复制黏贴的事，想都别想，即使你有代码在手里。
但你可以按大致逻辑进行重写，前提是这套逻辑不在专利保护之内。
另外，是否 3 年后你就可以为所欲为，涉及你跟上家是否有同业竞争协议。
试着站在雇主的角度去考虑问题，如果你的员工也来这么一出，你怎么来保护属于公司的知识产权？

这种不叫剥削叫啥？趁早走人，外面大的很。凭本事吃饭，有多大锅下多少米，老板头上就长角的？
996 这种搞法，没有出路的，说白了还是在堆初级人工、吃人口老本。

管住嘴，迈开腿，上述各种即可远离。

还行吧，搞过几年嵌入式的，都能上手。重点还是放在软件和生态部分吧，这才是大头。奈何国内上游 IC 在这方面没啥大起色，嵌入式行业的路子越来越窄，搞不大。