×

Loading...

@Vancouver

Topic

This topic has been archived. It cannot be replied.
  • 工作学习 / 事业工作 / 好像这里有人说IT“码工”老了就没啥用了?~ 其实不然,那个结论只能是对普通“码工”,高级的越久越离不开。 +3
    不少“高级”不仅懂技术,最最关键的是知道code里Business Rules。现在做BA的不少是在职场上“跳来跳去”,有些升去做经理或PM。知道那些Business Rules不是一天两天就能做到的,许多是不碰到状况就永远学不到,新来的一接到项目往往只能是去给高级的“拜帖”,问问User Story怎么写。
    • 以前是老吃香,现在这种机会不多了, +1
      • 怎么我看到好多这样的?现在不少BA不好好写Story或Use Case,动不动就换地方。弄得最后只有写code的不得不到处问Business rules,到最后变成了只有写code的知道everything。
    • 你说的情形是在同一单位,同一套系统混到老的情形,你换个单位,换套系统试试? +5
      • 那你还真没见过能人,到了一个新地方,有心的不是只去注意那些技术上的,而是耐心地去读去学那些Business上的,很多多都在code里,多交朋友。三年五年下来你就是“大拿”。
        • 你都说是“能人”了,那就不是普通“码工”了,我们讨论普通“码工”。 +2
          • 这里想说的是要去学做不“普通”的,不难。IT技术上的很容易学,而学Business上的要有耐心。还有一点,不管做什么,要有好的Attitude。很重要很重要!
            • “要有好的Attitude。很重要很重要!” 非常赞同!对码工来说编程逻辑大同小异,但是要去接受新的技术,新的开发环境和工具,老的没法和小的比。
              • 新技术新环境新工具,不懂Business还是什么都做不出来。十几万几十万的老code,现在的年轻人不少根本就没兴趣去读,那最后谁做?
                • Business rules 应该是BA的事,所以老“码工”应该争取转做BA或PM。
                  • 问BA?现在许多都是年轻人,你让BA去问谁?会返回来问你的。见过太多了。
                    • 所以老“码工”应该争取转做BA,对一套business rules了解之深的BA,薪水不会比码工低,而且不易被替代。
                    • 确实是这样的,大部分年轻的BA,都是反过来问你。😄
              • 有啥新技术? 再新的技术,也脱离不开数据结构+算法, 呵呵 至于开发环境跟工具 , 这些东西基本上1周就差不多了。都是换汤不换药的东西。😄 +1
        • 说的非常再理!👍
    • 好文 给加个一 作为用户甲方 我觉得越老越香的情况正在火速消亡 用户对系统质量的容忍度大大提高 很烂的程序照样卖得动 这个社会大趋势有关
    • 确实business更重要。技术层面要看上面的态度了,系统更换或者迁移就可能大换血
    • 其实一般公司很需要能把业务逻辑变成软件需求的人 --- 擅长这个的人其实并不多。但 BA/PO 挣得并不多,所以很多公司的 BA 都挺烂的。但 jr coder 对此绝对没兴趣 -- 随便学个 react / python / aws 哪个都比这个挣得多... +1
      • 这没办法,项目一大了,闷头搬砖的就只能看见自己面前那2平米的墙,根本就不知道这是起楼呢还是造桥呢…… +1
      • 我倒是很喜欢做这些,经常自己志愿写一些小程序,帮助公司内部的BA,QA完成工作;我写的app直接帮助QA缩短一半的工作量;不过这些并不能让我加薪,甚至连奖金都没有,只是在员工之间口碑非常好而已😊 +2
    • business rule 其实也不难,难的是不大容易有机会involved。 如果不参与,只是纸上谈兵,很难深入下去。 +1
    • 你这个正是说明了文档的重要性…… 不过嘛,所有对文档有雄心壮志的最后都被埋葬在了文档堆里…… 所以现状就是,直接读code比较快,比较准……
      • 印度IT劣质外包一统天下,就是靠这个完备的文档。
        • 这是没错,包装的好嘛…… 真正能干活的一看这文档,转身就找code去了…… 真正会干活的嘛,再写他几十份新的。
        • 印度程序员的文档比程序更烂,一般也不会和程序同步更新。要想搞明白到底在干什么,就得读code。虽然读起来痛苦,至少还能运行。 +1
    • 我们单位老的都干掉,一律交给印度人,管理层拿绩效,只看报表上的外包省钱,不计业务,名声损失。 +3
      • 正解,大趋势使然,势不可当👍
    • 这个也没那么绝对,我曾经接手过老VB, +2
      fox。数据库SSIS写的一些烂程序,改造成.net,WPF,里面的代码一眼没看,就是根据输入,输出结果来推测业务逻辑;保证老程序的输入输出和新程序的输入输出完全一致就好;这样试运行几个月,没毛病,就直接上新程序了;性能提高从50倍到100倍不止
      • 那是不是“普通”老码工写的?
        • 应该是,好多老马工不愿意学习新出现的技术,甚至对面向对象都一知半解,但是会写很多内部乱成一锅粥的面向过程的代码;改写这种程序,千万不能试图去读他们的代码,只能从输出结果推测业务逻辑,只要样本足够就好 +2
      • 得看这老系统做的是一个怎样的东西,不太复杂的当然可以这么做。
    • 是呀,可惜很多人只会写代码,但不明白写的是什么。我一直觉得好的代码需要灵魂,码工要懂得如何设计解决方案。需要很好的想象力和抽象思维的能力,可惜很多码工只是做机械劳动。
    • 或许这是北美IT分工过细的副作用?以前在国内早期纯码工并不多,很多人从系统分析、设计、开发、维护/升级...都走过完整的周期过程,在系统分析/设计阶段就对business(业务流程)了解和反复确认之后才往下走的,现在的码工除了编程其它都是别人的活...
      • 正好相反 --- 现在很多公司跳过正经 SDLC 瀑布流程,自我感觉敏捷,BA 乱提需求,dev 没有验证就瞎 code --- 项目失败就怪 agile。加上 jr dev 刷 leetcode 进大厂工资是一般公司的2-3倍,没有人再愿意积累经验(尤其是“业务逻辑”)--- 因为越来越难套现。
        • 现在当个码工一年半载不跳个槽都不好意思见人,还积累……
      • 以前在国内做过码工,看这里码工干活实在可笑
    • 码工真正牛人都是很有经验的,而且都是洋人。 +3
      • 对这个世界上没有自知之明,觉得自己很牛的人挺多的,计算机哪里发明的,编程语言哪里发明的,加拿大这种人口小国都出了很多计算机大牛,看不起这里的码农的主要是没有机会接触到有水平的人,这类人基本上是洋人。 +3
        • 除了专业技术知识外,华人尤其是第一代的移民,在北美文化背景和很多Business的知识方面,相对洋人本来就是普遍的短板,而这种大环境经验的积累对“业务逻辑”的理解/感悟很重要,会影响技术的发挥,当然技术若不过硬就更别说了...
          • 👍,知道自己的不足,才会去提高,去进步。
      • LZ此帖主要讨论的不是编程技术本身的牛不牛,而是技术在项目的应用是否到位,能否很好的满足了business的应用需求...就像一个数学演算很牛的人,未必是从复杂现实问题中提炼出正确的数学模型,并用合适的数学方法去解决问题的高手...