 |
1
CEBBCAT Oct 13, 2022 via iPhone  2
两年还算是新人，让新人独立研发这些不应该，应该弄个主程带着做。很多时候职场人觉得痛苦，不是自己太菜，而是公司管理不行
|
 |
2
Hilong Oct 13, 2022
痛苦其实没关系的,也是你成长的一个过程,建议不要裸辞,现在这里苟住,提升能力可以在公司一边学一边应用市最快的.
|
 |
3
shanghai1943 Oct 13, 2022
裸辞是不建议的。家里学习还不如在工作上成长。目前境况的解决办法是找领导沟通看看，让领导给意见，要是领导只管最终结果而不给个方向或者建议的话，就边工作边找下家。
|
 |
4
codewld Oct 13, 2022 via Android
找个开源的改？
|
 |
5
XSWJ Oct 13, 2022 via Android
我一个应届生现在也被拉去一个人做可视化编辑那种拖拉拽了，感觉以他们之前的代码成品，离主管的期望愿景差得很远，或者说很难实现，如果真要实现了，可能和实现个浏览器渲染引擎差不多了😂
|
 |
6
Hurriance Oct 13, 2022 via iPhone
正常要有人带吧。学习是个要建立在自己的基础之上有梯度的学习过程
|
 |
7
MuscleOf2016 Oct 13, 2022
看公司什么性质了，要是国企这种自己做着玩，忽悠大领导的，随便做做，当自己学习项目就行了。
另外这不是你的问题，才 2 年，就算 5 年了，做不出来也不是你的问题。是组长、架构师、技术经理这些角色的问题。 |
 |
8
FallenMax Oct 13, 2022 2
Cons:
- 学习过程痛苦 - 亏 Pros: - 能学到很多 - 简历++ - 公司的信任和 reputation 含泪做一下吧，多思考多请教 |
 |
9
YSMAN Oct 13, 2022
我工作好几年 也有这种困惑
|
 |
10
Gaays OP @CEBBCAT 项目组就我一个前端
@shanghai1943 大领导只管结果，前端技术这里不太懂 @codewld 产品需求可以说缝合了各家之所长 我现在做起来非常痛苦的一点：产品描述需求，我设计一套解决方案，适用于这一次的需求，下一次需求，可能就新增新的特性，我的解决方案设计不能满足这种新增需求，导致一直在重构代码。 |
 |
11
Southside Oct 13, 2022
看项目排期吧。如果给了足够的时间不急着催东西出来，倒是可以找个开源的项目在上面改。
|
 |
12
ChefIsAwesome Oct 13, 2022
没啥，典型的市场上那么多产品，肯定不难，我们也能做的公司思想。你也别想太多，别小看了低代码这类编辑器的难度了。
|
 |
13
weiwoxinyou Oct 13, 2022
@Gaays 不能满足需求就打补丁，重构的成本都由你承担明显不合理，能用就行
|
 |
14
renhou Oct 13, 2022
骑驴找驴吧，现在太卷了
我看牛客网上那些应届面试的，大厂就不说了，中小的面试题一时半会都想不出来 这还不算算法那些 |
 |
15
zhang77555 Oct 13, 2022
两年算是个分水岭,痛苦是正常的,不痛苦说明在温水煮青蛙或者天生适合这一行
任务完不成不要有太大心理负担,平台级的产品你从 xxx 管理系统转过来做一开始不要想着能做的多好,做烂了才是正常的,做烂了也能积累经验 不要幻想裸辞后自己的学习效率就能突飞猛进,建议骑驴找马 |
 |
16
otakustay Oct 13, 2022
10 年经验的都不一定做得出规则引擎来
|
 |
17
freeminder Oct 13, 2022 6
1. 看下来你核心的问题是感觉自己设计能力不足，事实确实是如果你经验不足，不该由你负责。
2. 确定了 1 之后，继续做，那么你需要放下包袱，不要拿这个挫折惩罚自己，无愧于心就好，大部分人不是领域精英。公司雇你，你干活，公司觉得不行他想办法。如果大领导过分批评你，那是他的问题，不是你的，不要惩罚自己。 3. 确定 1 ，从“做的不好可能会低绩效 /开除”的角度，想要避险，可以换。 4. 确定 1 ，但是公司可能也不会有什么资源换你，从“如果在其他环境有带路人进步更快”的角度，可以换。 5. 对 4 你要总结一个很重要的点：“尽管做不出来理想结果，自己有没有提升”。如果完全没有提升，建议换工作，坚持就是白费时间，就没摸着门道。如果有提升，建议坚持，不要在意结果上的失败，职业越到后面越重要的是你独立完成了什么样的进步，这种独立摸索进步的经历是可遇不可求的（无论级别和环境）。其他机会可能会给你一个好的师傅，继续提升的能力可能会让你独立解决大问题时更加从容，但是这种场景是必然需要经历的。 补充：这种设计上的困难，需要看一些对应的材料，比如设计模式，领域驱动设计。看看网上一些业务引擎创新的总结文章（相对纯技术创新），从中看到对业务的思考和对应的总结创新。还有就是绝对不要裸辞，绝对不要裸辞，绝对不要裸辞，你想裸辞的理由可能有很多，那都不是大事。 |
 |
18
gloye Oct 13, 2022
楼上大佬说得对
|
|
19
Gaays OP @freeminder 非常认同第 5 点，低代码编辑器我自己摸索出来一个勉强可用的，中间也学习到挺多知识。我时常感到痛苦的一点是感觉产品的需求最开始没搞明白，所以后面的迭代一直在为前面没想清楚的事情买单，导致我也一直在重构，所以感觉自己做的事情没有意义
|
 |
20
RealJacob Oct 13, 2022
同感觉很多时候比较痛苦，一年半
一个人主 r ，oncall 全套 对服务器知识很多时候一知半解，各种工程化配置什么的很耗时间 |
|
21
freeminder Oct 13, 2022 2
@Gaays 感觉产品需求不清楚，后续迭代有浪费：是团队合作的常态问题，不同环境程度不同，本质是计划、沟通、工作方式、相关角色能力的问题。
这种就是提升你的影响力，不论是你带头，还是你能影响带头的人，至少是做到有效暴露问题（不是直接跟人家对喷）。这个是另外一些问题上的历练：能不能我们把问题聊清楚、能不能通过什么手段规范化版本迭代、等等。 在自己的实现手段方面，如果这个事情暂时不清楚，我建议在你的控制范围内，做最小化的补丁。这个时候的实现思路不能是“我要注意扩展性、健壮、抽象、优雅 xxxx”，而是“在不特别恶心的情况下把事情办了”。对恶心的 patch 代码做意图注释“因为这里和什么冲突了，所以只能 xxx”。间隔一段时间再总结重构，这时候你积累了很多理解，起码一次解决一大批问题。另外通过完成需求，积累自己的权威性；你的权威到位了，技术债小暴雷是你申请重构资源的机会，不要害怕技术债。总之一句话：不要过早优化。 另外我这个人提建议总是向正向提的，正向很辛苦，任何时候你都有 walk away 的权利。我写的内容是“如果你想要坚持，可能有什么方向”，而不是“这些是你应该坚持的理由”。 |
|
22
Gaays OP @freeminder 感谢，原来是我对软件开发、团队协作认知不足导致的问题，看到这我有种豁然开朗的感觉！
|
Select Language