怎样才能相对公平的判断程序员的贡献大小 - 未名空间MITBBS历史存档

怎样才能相对公平的判断程序员的贡献大小# Programming - 葵花宝典

d*t2014-08-16 07:08

1 楼

Max Burton 6015 Portable Induction Cooktop Stove and Interface Disk
Combination Set
amazon上是150，见这个链接http://www.amazon.com/dp/B00213L3PU/ref=asc_df_B00213L3PU980481?smid=ATVPDKIKX0DER&tag=googlecom09c9-20&linkCode=asn&creative=380341&creativeASIN=B00213L3PU
带着个disk的哦，就不用额外买锅了
只花了59大元！！！咔咔咔咔
爽死！

u*d2014-08-16 07:08

2 楼

有木有啊？！

B*z2014-08-16 07:08

3 楼

有的人写代码很多，但是bug也很多。
有的人写的少，没什么bug。不过这样的话很可能上面认为这部分简单。
公司里面也不可能同一个项目让两组人做两遍。
在项目不同的情况下，怎样才能相对公平的判断出谁的贡献大，code质量好？
如果能有些量化的方法更好。

d*t2014-08-16 07:08

4 楼

快乐的转两圈，真是划算

t*z2014-08-16 07:08

5 楼

大多数人都这样的把

c*e2014-08-16 07:08

6 楼

太认真计较了就不好了。编程本来就是很自由的事情，同一个project,有人这么做，有
人用另外的方法做，不好比较的。
同时，有的project简单，有的复杂，也不好比较。
所以，如果是新人码工，就给他擅长的活做，比如会javascript,jquery的，就让做前
台;如果是老人，会做web services的，给他做web services,会做什么就给他什么。
程序员都很敏感脆弱的，千万别公开比较2个程序员。

【在 B**z 的大作中提到】

: 有的人写代码很多，但是bug也很多。
: 有的人写的少，没什么bug。不过这样的话很可能上面认为这部分简单。
: 公司里面也不可能同一个项目让两组人做两遍。
: 在项目不同的情况下，怎样才能相对公平的判断出谁的贡献大，code质量好？
: 如果能有些量化的方法更好。

Y*I2014-08-16 07:08

7 楼

一般都差不多100一个，59真的很便宜了

【在 d*****t 的大作中提到】

: Max Burton 6015 Portable Induction Cooktop Stove and Interface Disk
: Combination Set
: amazon上是150，见这个链接http://www.amazon.com/dp/B00213L3PU/ref=asc_df_B00213L3PU980481?smid=ATVPDKIKX0DER&tag=googlecom09c9-20&linkCode=asn&creative=380341&creativeASIN=B00213L3PU
: 带着个disk的哦，就不用额外买锅了
: 只花了59大元！！！咔咔咔咔
: 爽死！

j*l2014-08-16 07:08

8 楼

应该问有没有不是这样的。不这样怎么申请绿卡？

i*i2014-08-16 07:08

9 楼

根据design的页数。
完全可以洋洋洒洒好几页，结论是一行代码。

i*u2014-08-16 07:08

10 楼

Amazon上是150刀哎。怎么59刀买的？

W*o2014-08-16 07:08

11 楼

不写code，0 bug. 这最牛

【在 B**z 的大作中提到】

: 有的人写代码很多，但是bug也很多。
: 有的人写的少，没什么bug。不过这样的话很可能上面认为这部分简单。
: 公司里面也不可能同一个项目让两组人做两遍。
: 在项目不同的情况下，怎样才能相对公平的判断出谁的贡献大，code质量好？
: 如果能有些量化的方法更好。

d*t2014-08-16 07:08

12 楼

tuesday morning今天是本月的打折日，正好老公在他家买的两件衬衣尺寸不对，趁着
妞妞芭蕾的时候去换，一眼就看见那两大盒子躺在地上，新新的，旁边的老美没人看一
眼，我就抱在怀里去给钱，最后老太太说59，是税后哦，乐得我直跳

c*92014-08-16 07:08

13 楼

很多时候，还真是写了不如不写。常常接盘比重写困难多了。

【在 W***o 的大作中提到】

: 不写code，0 bug. 这最牛

r*a2014-08-16 07:08

14 楼

哈哈，有包子发么

【在 d*****t 的大作中提到】

: tuesday morning今天是本月的打折日，正好老公在他家买的两件衬衣尺寸不对，趁着
: 妞妞芭蕾的时候去换，一眼就看见那两大盒子躺在地上，新新的，旁边的老美没人看一
: 眼，我就抱在怀里去给钱，最后老太太说59，是税后哦，乐得我直跳

c*32014-08-16 07:08

15 楼

很简单，不用看代码。找个棘手的问题，看谁能解决，需要多少时间，高下立判。
程序员的区别，主要是在解决问题的能力上，代码只是很小一面

【在 B**z 的大作中提到】

: 有的人写代码很多，但是bug也很多。
: 有的人写的少，没什么bug。不过这样的话很可能上面认为这部分简单。
: 公司里面也不可能同一个项目让两组人做两遍。
: 在项目不同的情况下，怎样才能相对公平的判断出谁的贡献大，code质量好？
: 如果能有些量化的方法更好。

d*t2014-08-16 07:08

16 楼

楼上的，我是穷鬼啊，没啥伪币，抱歉了

d*t2014-08-16 07:08

17 楼

你这也看不出来。工作中棘手问题难得出现一次，有人虽然对付棘手问题没办法，但处
理一般问题很稳妥，而有人刚好相反。

【在 c****3 的大作中提到】

: 很简单，不用看代码。找个棘手的问题，看谁能解决，需要多少时间，高下立判。
: 程序员的区别，主要是在解决问题的能力上，代码只是很小一面

n*r2014-08-16 07:08

18 楼

在那个店里买的阿？

b*n2014-08-16 07:08

19 楼

能解决问题且不制造问题的就是好程序员。

【在 B**z 的大作中提到】

: 有的人写代码很多，但是bug也很多。
: 有的人写的少，没什么bug。不过这样的话很可能上面认为这部分简单。
: 公司里面也不可能同一个项目让两组人做两遍。
: 在项目不同的情况下，怎样才能相对公平的判断出谁的贡献大，code质量好？
: 如果能有些量化的方法更好。

r*a2014-08-16 07:08

20 楼

哈哈，开玩笑的～

【在 d*****t 的大作中提到】

: 楼上的，我是穷鬼啊，没啥伪币，抱歉了

d*t2014-08-16 07:08

21 楼

挖坑再埋的升得快哈哈哈

【在 b*******n 的大作中提到】

: 能解决问题且不制造问题的就是好程序员。

n*r2014-08-16 07:08

22 楼

在那个店里买的阿？

c*d2014-08-16 07:08

23 楼

对于中级以上的工程师来说，很少有真正棘手做不出来的问题。总能集中精力把一般
问题处理的稳妥才是工作中真正需要的。

【在 d********t 的大作中提到】

: 你这也看不出来。工作中棘手问题难得出现一次，有人虽然对付棘手问题没办法，但处
: 理一般问题很稳妥，而有人刚好相反。

d*t2014-08-16 07:08

24 楼

tuesday morning

c*d2014-08-16 07:08

25 楼

每个项目都不同，每个队伍也都不一样，没有万能的量化方法。这个需要一线的经
理对业务和技术都有深入的了解，才能正确的衡量每个程序员的产出。

【在 B**z 的大作中提到】

: 有的人写代码很多，但是bug也很多。
: 有的人写的少，没什么bug。不过这样的话很可能上面认为这部分简单。
: 公司里面也不可能同一个项目让两组人做两遍。
: 在项目不同的情况下，怎样才能相对公平的判断出谁的贡献大，code质量好？
: 如果能有些量化的方法更好。

d*t2014-08-16 07:08

26 楼

呵呵呵

【在 r*****a 的大作中提到】

: 哈哈，开玩笑的～

k*n2014-08-16 07:08

27 楼

呵呵，有人bug大堆， code杂乱，所以需要经常加班加点解决问题，结果曝光率高
，客户救星，获得升迁与各种奖。。。。

rr

【在 d********t 的大作中提到】

: 挖坑再埋的升得快哈哈哈

s*d2014-08-16 07:08

28 楼

用disk不就跟普通电炉一样了吗。

c*32014-08-16 07:08

29 楼

中级以上，都是复杂问题，区别才明显。
复杂问题里，肯定有超级复杂和棘手的，往往只有少数人才能做得出，而且可能很快。
其他人都做不出，或者要很久才能想出来。
能很快做出超级复杂和棘手问题的人最有价值。这种人缺了，项目运气不好，可能会在
关键时候，遇到棘手问题而卡壳。其他人缺了，都无所谓，或者无关大局。
如果项目没有超级复杂和棘手的问题，那这种项目难度低，对谁都一样，也就无所谓区
分程序员好坏了。
按照解决问题的能力，很容易把程序员的水准区别开。这方面人和人之间的差距是很大
的，反而看代码，不见得有很大差距。

【在 c***d 的大作中提到】

: 对于中级以上的工程师来说，很少有真正棘手做不出来的问题。总能集中精力把一般
: 问题处理的稳妥才是工作中真正需要的。

d*t2014-08-16 07:08

30 楼

是啊，但是就可以暂时不用去买锅了

o*g2014-08-16 07:08

31 楼

提一个
最大贡献在于，你说啥时候做好，就啥时候交活，不带大bug的，不带偷工减料的。
拖着做不完，对其他相关部门伤害是很大的。太难直说做不了，拒绝接活也是有贡献的。
以上限于业界，学术界不算
版上有谁举手说，十年从来没拖过？

g*g2014-08-16 07:08

32 楼

能meet deadline的就是好程序员，能擦屁股帮团队meet deadline的是牛逼程序员。

g*g2014-08-16 07:08

33 楼

我老从来没拖过。来不及估计的时候就说。

的。

【在 o***g 的大作中提到】

: 提一个
: 最大贡献在于，你说啥时候做好，就啥时候交活，不带大bug的，不带偷工减料的。
: 拖着做不完，对其他相关部门伤害是很大的。太难直说做不了，拒绝接活也是有贡献的。
: 以上限于业界，学术界不算
: 版上有谁举手说，十年从来没拖过？

h*k2014-08-16 07:08

34 楼

好的程序员对问题的解决一般了然于胸，写程序只是个code/debug的过程。
牛逼的程序员平时不会使出100%的能量的，所以日常工作也看不太出来。到了关键时刻
可以力挽狂澜，发挥小宇宙
完成整个项目。要知道，好程序员和一般程序员都发挥100%能量的时候产出可能是几倍
或者几十倍的差别。但平时
真的没那么明显。

【在 B**z 的大作中提到】

: 有的人写代码很多，但是bug也很多。
: 有的人写的少，没什么bug。不过这样的话很可能上面认为这部分简单。
: 公司里面也不可能同一个项目让两组人做两遍。
: 在项目不同的情况下，怎样才能相对公平的判断出谁的贡献大，code质量好？
: 如果能有些量化的方法更好。

z*e2014-08-16 07:08

35 楼

猴屁股不是有个总结么？
制造bugs比解决的多
还是反过来

z*e2014-08-16 07:08

36 楼

难
尤其是接盘的项目
想要很快上手，真不那么容易
有些屎坑一个类6000多行，看都看晕过去
然后这种就是招一个，半年后不是被赶走就是自己跑走
然后那个位置就不停地换人

的。

【在 o***g 的大作中提到】

: 提一个
: 最大贡献在于，你说啥时候做好，就啥时候交活，不带大bug的，不带偷工减料的。
: 拖着做不完，对其他相关部门伤害是很大的。太难直说做不了，拒绝接活也是有贡献的。
: 以上限于业界，学术界不算
: 版上有谁举手说，十年从来没拖过？

a*l2014-08-16 07:08

37 楼

怪不得买卖提男的都痛恨接盘.

【在 z****e 的大作中提到】

: 难
: 尤其是接盘的项目
: 想要很快上手，真不那么容易
: 有些屎坑一个类6000多行，看都看晕过去
: 然后这种就是招一个，半年后不是被赶走就是自己跑走
: 然后那个位置就不停地换人
:
: 的。

W*o2014-08-16 07:08

38 楼

但是有时又不得不接盘

【在 a****l 的大作中提到】

: 怪不得买卖提男的都痛恨接盘.

a*f2014-08-16 07:08

39 楼

看有效代码的数量是多少，可以用人月的工作量来估计。拷贝代码改动改动算不上大的
工作量。
如果系统稳定可靠可用，基本就是有效系统
如果要重做，大概估计一下如果重做是否需要几个人月的工作量