- 浏览: 2579979 次
- 性别:
- 来自: 小胖儿的大城
文章分类
最新评论
-
ni4wangba0:
ni4wangba0 写道亲测,算法有问题。对不起,其实是我自 ...
谈谈"求线段交点"的几种算法(js实现,完整版) -
ni4wangba0:
亲测,算法有问题。
谈谈"求线段交点"的几种算法(js实现,完整版) -
kers007:
苹果不让Webapp 在appstore 里发布,我不知道对 ...
苹果真的要在 AppStore 里封杀 WebApp 吗? -
striveandlive:
fins = js大牛
[原创]GT-Template, 一个超轻量级的js模板工具. -
AlwaysYang:
基础扎实的才能行走天下。
关于body的"大小"在ie和ff下的一些基础知识
以下内容出自我给领导写的项目总结中的一部分
贴出来的目的希望里面的一些东西可以对大家有所帮助.
也许也有很多人的公司和我们有着同样的弊端与不足.
大家可以讨论一下该如何克服他们.
===========================================
项目开始时大家都说,我们这个项目必须成功,不许失败,也有人说,我们这个项目必然成功,不可能失败.
项目这东西对于公司来说 也许只有失败和成功两种情况.
但是我觉得还有第三种情况:没有失败,但绝对算不上成功.
在成功的完成了一个项目的开发之后,员工的个人技能、团队的战斗力、公司的凝聚力都应当得到提升.
而我们这个YWZC项目是否让我们得到了应得的提升呢?
项目完成后,我们当中,是因为自己的成长而感到兴奋的人多一些,
还是因为项目的艰辛感到疲惫的人多一些,还是那些感慨"总算完事了"的人多一些?
我想这三者的比例 最能直接反应出我们这个项目是否真的取得了成功.
从成功的项目再延伸一下,我们的团队是成功的吗 是出色的吗?
这个的衡量标准有很多,但最基本的一个就是,成员对团队的认同感如何.
如果团队成员自己都对这个团队不满意,那么这个团队不管做出了多么伟大的业绩,它都不是一个出色的团队.
当然,没有哪个团队能让成员100%的满意,但是有60%的成员表示满意应该是一个最基本的及格线.
我觉得我们的团队应该是达不到60%的.
提高员工认同感和归属感的一个重要手段是对员工进行正确的激励,这个工作通常应该由TEAM LEADER来做.
但是说实话,TL表扬开发人员10句 不如大领导的一句,
这到不是说TL的激励不重要,而是因为TL与开发人员太近了,成天被生活在一起的人激励,力度明显不够.
就好像陌生人对我们的认可往往比父母对我们的认可更让我们高兴一样.
所以,希望上层领导能多表扬表扬底层的程序员吧 呵呵.
再来说说我最关注的技术吧
坦诚的说,我们部门的技术已经落后于业内的其他出色的公司了.
原因我觉得大概有以下几点:
1 原先的技术骨干,逐渐走向管理层,在专研技术上所能分配的时间越来越少
而新的技术骨干没有成长起来,并且略显浮躁(例如我,呵呵.没办法,现在就是一个浮躁的年代.踏踏实实做学问的人越来越少了)
2 对于我们的系统,我们过分的追求了"稳定".很多代码还是很多年前留下来的,今天依然能用,那么我们就继续使用.
我们对代码的修改只是修改BUG,添加功能,很少进行技术上的重构.
3 对新技术的关注不够.
新技术常常被认为是"不可靠的,未经过足够考验的"不成熟的东西.
这样的观点有一定的道理,但是我们可以不使用,可以不去学习,但是不应该不去关注.任何技术都是从不成熟走向成熟的.
现在行业的竞争激烈,等到某技术成熟时,我们再去关注就太迟了.
而且很多东西,我们不去主动深入的了解他就很难做出正确的评估,仅仅是临阵磨枪,靠google来的一些介绍性文章是远远不够的.
4 开发人员良莠不齐
开发人员素质差异这个问题不可能避免,团队规模越大越是如此(总是有一些擅长面试和笔试的人可以顺利的混进公司).
5 开发人员之间的技术交流太少了.
我始终觉得,开发人员之间的技术交流要比公司组织的技术培训对他们的帮助大.而我们部门这样的氛围不浓烈.
很多员工似乎都只满足于"我的技能能完成领导交给的工作就可以,不管完成的快慢好坏",不愿意花业余时间来进一步学习.
我始终信奉一句话:人和人之间的差距是在8小时之外拉开的.
我想我们部门的每一位员工都应该牢记这句话.
6 我们部门以后也许要逐步摆脱低层技术,加强员工的设计能力和业务水平,编码的工作交给外包做.
这样的思路是有道理的,是可行的,但是宏观与微观的度应该把握好,太过注重宏观的上层的东西,忽视技术细节,后果就是我们会被外包人员牵着鼻子走.
举个极端夸张的例子吧,如果大家都专研设计 都搞宏观的,代码复查的时候,连外包写的代码我们都看不明白,那就糟糕了.
关于技术方面的想法我还有很多很多,有机会我再单独撰文吧,在这封信里就不多说了.
公司的口号是"超越技术" 但是在超越前,请让我们先"关注技术"吧
深有同感,不能进行重构的原因太多了,新功能工期紧,系统要求稳定等等。
重构需要时间,时间就是金钱。这是一个长远利益与眼前利益平衡的问题。
恐惧能够扼杀一切创造力。生的伟大,活的憋屈。这是你自己的选择。
深有同感,不能进行重构的原因太多了,新功能工期紧,系统要求稳定等等。
重构需要时间,时间就是金钱。这是一个长远利益与眼前利益平衡的问题。
这句话好像就是在说我。我现在就是通过8小时之外,制造差距的。
人在江湖,身不由己。
顶~~~~,我是做外包的,客户的公司开发人员没有下40岁的,有一牛人65岁了还是做coding,思维逻辑非常细腻,当我跟他聊天的时候,他说他已经coding了28年了,以前是一个医生,按理说美国的医生职业是非常好的,但他说他喜欢coding.公司把他当宝贝一样,谁说35岁以后不能coding我会强烈鄙视他,如果你喜欢coding,就坚持下去吧,但如果你想去做管理也可以,请务必打好深厚的技术背景。我坚信国内的软件氛围会慢慢的变的规范和务实!
长见识了,这种人很少,从来没有亲眼目睹过呀,不过写代码也是我的爱好,步管怎么样,我也要坚持下去,提供国内的软件氛围就要从自己做起
顶~~~~,我是做外包的,客户的公司开发人员没有下40岁的,有一牛人65岁了还是做coding,思维逻辑非常细腻,当我跟他聊天的时候,他说他已经coding了28年了,以前是一个医生,按理说美国的医生职业是非常好的,但他说他喜欢coding.公司把他当宝贝一样,谁说35岁以后不能coding我会强烈鄙视他,如果你喜欢coding,就坚持下去吧,但如果你想去做管理也可以,请务必打好深厚的技术背景。我坚信国内的软件氛围会慢慢的变的规范和务实!我的第一个师父大约50岁以上。。。
他是外国回来的。。。
在公司干了6年,一直带新手,手中还有公司股份。
写程序,用软件,写PPT,用VBA写工具,
反正是哪样东西他都能很快的上手,之后再教我
我惊为天人。。。
顶~~~~,我是做外包的,客户的公司开发人员没有下40岁的,有一牛人65岁了还是做coding,思维逻辑非常细腻,当我跟他聊天的时候,他说他已经coding了28年了,以前是一个医生,按理说美国的医生职业是非常好的,但他说他喜欢coding.公司把他当宝贝一样,谁说35岁以后不能coding我会强烈鄙视他,如果你喜欢coding,就坚持下去吧,但如果你想去做管理也可以,请务必打好深厚的技术背景。我坚信国内的软件氛围会慢慢的变的规范和务实!
前两种在干活时没什么太多的麻烦
而你在干活时太用心了。。。
我觉得这样也未免绝对了吧, 谁都有给自己考虑的时候,自是他曝漏了自己降低复杂度?会不会延长开发周期?。。。
会?那么被否定
往上爬?会不会更加努力?
会?那么肯定
出去开公司?会不会跑路?
会?趁他没走多用用他。。。
PS:如果一次次被否定你还会研究么?如果一次次被打击你还会努力工作么?
前两种在干活时没什么太多的麻烦
而你在干活时太用心了。。。
我觉得这样也未免绝对了吧, 谁都有给自己考虑的时候,自是他曝漏了自己
为什么领导不知道呢? 难道领导不是从我们这样一步一步做出来的?为节约点钱让闲着的java程序员去写flash...
这样的老板,实在。。。。难怪你要抛出异常了。
前两种在干活时没什么太多的麻烦
而你在干活时太用心了。。。
为什么领导不知道呢? 难道领导不是从我们这样一步一步做出来的?为节约点钱让闲着的java程序员去写flash...
这个确实有点抠门了..我都搞了快6年flash了,还好我们领导没有叫我去写flash
楼上说的一语中的
为什么领导不知道呢? 难道领导不是从我们这样一步一步做出来的?
领导有两种,
一种是外行领导内行的,他知道分多种才怪呢;
一种是象你说的一步一步作出来的。不过绝大多数领导无法摆脱“屁股决定脑袋”的规律。既然做到领导这个位置,就不用考虑那么多了。
古人讲“千军易得,一将难求”,古人还讲“主将无能,累死三军”。
为什么领导不知道呢? 难道领导不是从我们这样一步一步做出来的?为节约点钱让闲着的java程序员去写flash...
为什么领导不知道呢? 难道领导不是从我们这样一步一步做出来的?
我始终觉得,开发人员之间的技术交流要比公司组织的技术培训对他们的帮助大.而我们部门这样的氛围不浓烈.
我见到的软件公司普遍存在这个问题,有培训,没交流。
我们公司有交流, 培训少, 每天都要开会交流.
个人觉得在大环境下,搞开发的大部分略显浮躁, 因为都想着怎么出来自己发展.
导致吧经历用在了其他地方
贴出来的目的希望里面的一些东西可以对大家有所帮助.
也许也有很多人的公司和我们有着同样的弊端与不足.
大家可以讨论一下该如何克服他们.
===========================================
项目开始时大家都说,我们这个项目必须成功,不许失败,也有人说,我们这个项目必然成功,不可能失败.
项目这东西对于公司来说 也许只有失败和成功两种情况.
但是我觉得还有第三种情况:没有失败,但绝对算不上成功.
在成功的完成了一个项目的开发之后,员工的个人技能、团队的战斗力、公司的凝聚力都应当得到提升.
而我们这个YWZC项目是否让我们得到了应得的提升呢?
项目完成后,我们当中,是因为自己的成长而感到兴奋的人多一些,
还是因为项目的艰辛感到疲惫的人多一些,还是那些感慨"总算完事了"的人多一些?
我想这三者的比例 最能直接反应出我们这个项目是否真的取得了成功.
从成功的项目再延伸一下,我们的团队是成功的吗 是出色的吗?
这个的衡量标准有很多,但最基本的一个就是,成员对团队的认同感如何.
如果团队成员自己都对这个团队不满意,那么这个团队不管做出了多么伟大的业绩,它都不是一个出色的团队.
当然,没有哪个团队能让成员100%的满意,但是有60%的成员表示满意应该是一个最基本的及格线.
我觉得我们的团队应该是达不到60%的.
提高员工认同感和归属感的一个重要手段是对员工进行正确的激励,这个工作通常应该由TEAM LEADER来做.
但是说实话,TL表扬开发人员10句 不如大领导的一句,
这到不是说TL的激励不重要,而是因为TL与开发人员太近了,成天被生活在一起的人激励,力度明显不够.
就好像陌生人对我们的认可往往比父母对我们的认可更让我们高兴一样.
所以,希望上层领导能多表扬表扬底层的程序员吧 呵呵.
再来说说我最关注的技术吧
坦诚的说,我们部门的技术已经落后于业内的其他出色的公司了.
原因我觉得大概有以下几点:
1 原先的技术骨干,逐渐走向管理层,在专研技术上所能分配的时间越来越少
而新的技术骨干没有成长起来,并且略显浮躁(例如我,呵呵.没办法,现在就是一个浮躁的年代.踏踏实实做学问的人越来越少了)
2 对于我们的系统,我们过分的追求了"稳定".很多代码还是很多年前留下来的,今天依然能用,那么我们就继续使用.
我们对代码的修改只是修改BUG,添加功能,很少进行技术上的重构.
3 对新技术的关注不够.
新技术常常被认为是"不可靠的,未经过足够考验的"不成熟的东西.
这样的观点有一定的道理,但是我们可以不使用,可以不去学习,但是不应该不去关注.任何技术都是从不成熟走向成熟的.
现在行业的竞争激烈,等到某技术成熟时,我们再去关注就太迟了.
而且很多东西,我们不去主动深入的了解他就很难做出正确的评估,仅仅是临阵磨枪,靠google来的一些介绍性文章是远远不够的.
4 开发人员良莠不齐
开发人员素质差异这个问题不可能避免,团队规模越大越是如此(总是有一些擅长面试和笔试的人可以顺利的混进公司).
5 开发人员之间的技术交流太少了.
我始终觉得,开发人员之间的技术交流要比公司组织的技术培训对他们的帮助大.而我们部门这样的氛围不浓烈.
很多员工似乎都只满足于"我的技能能完成领导交给的工作就可以,不管完成的快慢好坏",不愿意花业余时间来进一步学习.
我始终信奉一句话:人和人之间的差距是在8小时之外拉开的.
我想我们部门的每一位员工都应该牢记这句话.
6 我们部门以后也许要逐步摆脱低层技术,加强员工的设计能力和业务水平,编码的工作交给外包做.
这样的思路是有道理的,是可行的,但是宏观与微观的度应该把握好,太过注重宏观的上层的东西,忽视技术细节,后果就是我们会被外包人员牵着鼻子走.
举个极端夸张的例子吧,如果大家都专研设计 都搞宏观的,代码复查的时候,连外包写的代码我们都看不明白,那就糟糕了.
关于技术方面的想法我还有很多很多,有机会我再单独撰文吧,在这封信里就不多说了.
公司的口号是"超越技术" 但是在超越前,请让我们先"关注技术"吧
评论
24 楼
dongbin
2007-06-09
centgo 写道
引用
对于我们的系统,我们过分的追求了"稳定".很多代码还是很多年前留下来的,今天依然能用,那么我们就继续使用.
我们对代码的修改只是修改BUG,添加功能,很少进行技术上的重构.
我们对代码的修改只是修改BUG,添加功能,很少进行技术上的重构.
深有同感,不能进行重构的原因太多了,新功能工期紧,系统要求稳定等等。
重构需要时间,时间就是金钱。这是一个长远利益与眼前利益平衡的问题。
恐惧能够扼杀一切创造力。生的伟大,活的憋屈。这是你自己的选择。
23 楼
centgo
2007-06-09
引用
对于我们的系统,我们过分的追求了"稳定".很多代码还是很多年前留下来的,今天依然能用,那么我们就继续使用.
我们对代码的修改只是修改BUG,添加功能,很少进行技术上的重构.
我们对代码的修改只是修改BUG,添加功能,很少进行技术上的重构.
深有同感,不能进行重构的原因太多了,新功能工期紧,系统要求稳定等等。
重构需要时间,时间就是金钱。这是一个长远利益与眼前利益平衡的问题。
22 楼
JJYAO
2007-05-27
LZ写的很好,非常真实.
有很多复杂的因素会导致一个上点规模的公司出现这种问题.一般大家私下会讨论很多,老板也不是不知道,但大多时候也不能随便乱动,大家就慢慢熬吧.
首先你自己要认为你是对的,保持一颗清晰的大脑,并在必要的时候站出来,向大家(你的领导,上上级领导,资深开发人员都可以)清晰的表达你的观点,我相信大多数领导和设计人员都能比较客观的看待问题
有很多复杂的因素会导致一个上点规模的公司出现这种问题.一般大家私下会讨论很多,老板也不是不知道,但大多时候也不能随便乱动,大家就慢慢熬吧.
引用
降低复杂度?会不会延长开发周期?。。。
会?那么被否定
往上爬?会不会更加努力?
会?那么肯定
出去开公司?会不会跑路?
会?趁他没走多用用他。。。
PS:如果一次次被否定你还会研究么?如果一次次被打击你还会努力工作么?
会?那么被否定
往上爬?会不会更加努力?
会?那么肯定
出去开公司?会不会跑路?
会?趁他没走多用用他。。。
PS:如果一次次被否定你还会研究么?如果一次次被打击你还会努力工作么?
首先你自己要认为你是对的,保持一颗清晰的大脑,并在必要的时候站出来,向大家(你的领导,上上级领导,资深开发人员都可以)清晰的表达你的观点,我相信大多数领导和设计人员都能比较客观的看待问题
21 楼
keete
2007-05-27
fins 写道
人和人之间的差距是在8小时之外拉开的.
这句话好像就是在说我。我现在就是通过8小时之外,制造差距的。
人在江湖,身不由己。
20 楼
sun113
2007-05-22
沟通很重要--日本人称水平沟通!
19 楼
umbrella
2007-05-19
做管理未必要技术很全面吧,甚至连技术都可以不懂.
18 楼
ahuaxuan
2007-04-26
CosmicWind 写道
Allen 写道
人们正在直上天堂,人们正在直下地狱……
只要“35岁还在写代码就是人生的悲哀”这种思想还在盛行一天,我们就一天不得不痛苦的徘徊。
只要“35岁还在写代码就是人生的悲哀”这种思想还在盛行一天,我们就一天不得不痛苦的徘徊。
顶~~~~,我是做外包的,客户的公司开发人员没有下40岁的,有一牛人65岁了还是做coding,思维逻辑非常细腻,当我跟他聊天的时候,他说他已经coding了28年了,以前是一个医生,按理说美国的医生职业是非常好的,但他说他喜欢coding.公司把他当宝贝一样,谁说35岁以后不能coding我会强烈鄙视他,如果你喜欢coding,就坚持下去吧,但如果你想去做管理也可以,请务必打好深厚的技术背景。我坚信国内的软件氛围会慢慢的变的规范和务实!
长见识了,这种人很少,从来没有亲眼目睹过呀,不过写代码也是我的爱好,步管怎么样,我也要坚持下去,提供国内的软件氛围就要从自己做起
17 楼
抛出异常的爱
2007-04-26
CosmicWind 写道
Allen 写道
人们正在直上天堂,人们正在直下地狱……
只要“35岁还在写代码就是人生的悲哀”这种思想还在盛行一天,我们就一天不得不痛苦的徘徊。
只要“35岁还在写代码就是人生的悲哀”这种思想还在盛行一天,我们就一天不得不痛苦的徘徊。
顶~~~~,我是做外包的,客户的公司开发人员没有下40岁的,有一牛人65岁了还是做coding,思维逻辑非常细腻,当我跟他聊天的时候,他说他已经coding了28年了,以前是一个医生,按理说美国的医生职业是非常好的,但他说他喜欢coding.公司把他当宝贝一样,谁说35岁以后不能coding我会强烈鄙视他,如果你喜欢coding,就坚持下去吧,但如果你想去做管理也可以,请务必打好深厚的技术背景。我坚信国内的软件氛围会慢慢的变的规范和务实!
他是外国回来的。。。
在公司干了6年,一直带新手,手中还有公司股份。
写程序,用软件,写PPT,用VBA写工具,
反正是哪样东西他都能很快的上手,之后再教我
我惊为天人。。。
16 楼
CosmicWind
2007-04-26
Allen 写道
人们正在直上天堂,人们正在直下地狱……
只要“35岁还在写代码就是人生的悲哀”这种思想还在盛行一天,我们就一天不得不痛苦的徘徊。
只要“35岁还在写代码就是人生的悲哀”这种思想还在盛行一天,我们就一天不得不痛苦的徘徊。
顶~~~~,我是做外包的,客户的公司开发人员没有下40岁的,有一牛人65岁了还是做coding,思维逻辑非常细腻,当我跟他聊天的时候,他说他已经coding了28年了,以前是一个医生,按理说美国的医生职业是非常好的,但他说他喜欢coding.公司把他当宝贝一样,谁说35岁以后不能coding我会强烈鄙视他,如果你喜欢coding,就坚持下去吧,但如果你想去做管理也可以,请务必打好深厚的技术背景。我坚信国内的软件氛围会慢慢的变的规范和务实!
15 楼
thinking
2007-04-23
项目发布了,但是如果开发人员感觉很累,不快乐,没进步,这个项目还是失败的。
14 楼
抛出异常的爱
2007-04-19
cozone_柯中 写道
抛出异常的爱 写道
KKND 写道
我身边的一些同事,不想着怎么把方法的复杂度降到O(N),而是每天想着怎么往上爬、或者怎么出去开自己的公司……
当然了,在领导的眼中,我们这些人没有什么区别,都只不过是随时可以牺牲掉的小卒……
如果可以的话我认为会先牺牲掉你。。。。
当然了,在领导的眼中,我们这些人没有什么区别,都只不过是随时可以牺牲掉的小卒……
前两种在干活时没什么太多的麻烦
而你在干活时太用心了。。。
我觉得这样也未免绝对了吧, 谁都有给自己考虑的时候,自是他曝漏了自己
会?那么被否定
往上爬?会不会更加努力?
会?那么肯定
出去开公司?会不会跑路?
会?趁他没走多用用他。。。
PS:如果一次次被否定你还会研究么?如果一次次被打击你还会努力工作么?
13 楼
cozone_柯中
2007-04-18
抛出异常的爱 写道
KKND 写道
我身边的一些同事,不想着怎么把方法的复杂度降到O(N),而是每天想着怎么往上爬、或者怎么出去开自己的公司……
当然了,在领导的眼中,我们这些人没有什么区别,都只不过是随时可以牺牲掉的小卒……
如果可以的话我认为会先牺牲掉你。。。。
当然了,在领导的眼中,我们这些人没有什么区别,都只不过是随时可以牺牲掉的小卒……
前两种在干活时没什么太多的麻烦
而你在干活时太用心了。。。
我觉得这样也未免绝对了吧, 谁都有给自己考虑的时候,自是他曝漏了自己
12 楼
lintomny
2007-04-18
抛出异常的爱 写道
cozone_柯中 写道
抛出异常的爱 写道
领导不 知道程序员分很多种
我正在写flash的AS时就已经知道了
我正在写flash的AS时就已经知道了
为什么领导不知道呢? 难道领导不是从我们这样一步一步做出来的?
这样的老板,实在。。。。难怪你要抛出异常了。
11 楼
抛出异常的爱
2007-04-18
KKND 写道
我身边的一些同事,不想着怎么把方法的复杂度降到O(N),而是每天想着怎么往上爬、或者怎么出去开自己的公司……
当然了,在领导的眼中,我们这些人没有什么区别,都只不过是随时可以牺牲掉的小卒……
如果可以的话我认为会先牺牲掉你。。。。
当然了,在领导的眼中,我们这些人没有什么区别,都只不过是随时可以牺牲掉的小卒……
前两种在干活时没什么太多的麻烦
而你在干活时太用心了。。。
10 楼
KKND
2007-04-18
我身边的一些同事,不想着怎么把方法的复杂度降到O(N),而是每天想着怎么往上爬、或者怎么出去开自己的公司……
当然了,在领导的眼中,我们这些人没有什么区别,都只不过是随时可以牺牲掉的小卒……
当然了,在领导的眼中,我们这些人没有什么区别,都只不过是随时可以牺牲掉的小卒……
9 楼
cozone_柯中
2007-04-18
抛出异常的爱 写道
cozone_柯中 写道
抛出异常的爱 写道
领导不 知道程序员分很多种
我正在写flash的AS时就已经知道了
我正在写flash的AS时就已经知道了
为什么领导不知道呢? 难道领导不是从我们这样一步一步做出来的?
这个确实有点抠门了..我都搞了快6年flash了,还好我们领导没有叫我去写flash
楼上说的一语中的
8 楼
adamzhao
2007-04-18
cozone_柯中 写道
抛出异常的爱 写道
领导不 知道程序员分很多种
我正在写flash的AS时就已经知道了
我正在写flash的AS时就已经知道了
为什么领导不知道呢? 难道领导不是从我们这样一步一步做出来的?
领导有两种,
一种是外行领导内行的,他知道分多种才怪呢;
一种是象你说的一步一步作出来的。不过绝大多数领导无法摆脱“屁股决定脑袋”的规律。既然做到领导这个位置,就不用考虑那么多了。
古人讲“千军易得,一将难求”,古人还讲“主将无能,累死三军”。
7 楼
抛出异常的爱
2007-04-18
cozone_柯中 写道
抛出异常的爱 写道
领导不 知道程序员分很多种
我正在写flash的AS时就已经知道了
我正在写flash的AS时就已经知道了
为什么领导不知道呢? 难道领导不是从我们这样一步一步做出来的?
6 楼
cozone_柯中
2007-04-18
抛出异常的爱 写道
领导不 知道程序员分很多种
我正在写flash的AS时就已经知道了
我正在写flash的AS时就已经知道了
为什么领导不知道呢? 难道领导不是从我们这样一步一步做出来的?
5 楼
cozone_柯中
2007-04-18
引用
我始终觉得,开发人员之间的技术交流要比公司组织的技术培训对他们的帮助大.而我们部门这样的氛围不浓烈.
引用
我见到的软件公司普遍存在这个问题,有培训,没交流。
我们公司有交流, 培训少, 每天都要开会交流.
个人觉得在大环境下,搞开发的大部分略显浮躁, 因为都想着怎么出来自己发展.
导致吧经历用在了其他地方
发表评论
-
有些事现在不做,一辈子都不会做了
2012-03-27 20:49 4819和当初那篇《Done ... -
小胖的" MacOS常用免费软件 "清单(有小更新).
2011-09-13 18:16 10644转眼用MacOS也有一年多 ... -
上海HP招Web前端工程师一名, 有意者简历 发到 fins[圈a]163.com
2011-05-26 17:04 608上海HP招Web前端工程师一名, 有意者简历 发到 fins[ ... -
如今锻炼身体越来越难,暂时把微博转到国内的新浪微博了,欢迎关注.
2011-03-14 10:12 1631如今锻炼身体越来越难,暂时把微博转到国内的新浪微博了,欢迎关注 ... -
简单说说1月8号的中国首届cocoa移动开发者大会吧.
2011-01-09 02:28 2540这次大会是我的治愈系小天使@tinyfool (他就是那个重量 ... -
离职离了一个月了,还没离,而且被派到广州来了...
2010-12-05 23:55 1993离职离了一个月了,还没离,而且被派到广州来了... 出差加班中 ... -
离职中...
2010-11-16 13:03 2126到上海三年多 ,感谢普元给了我一个很好的成长环境, 让我学到了 ... -
推特碎语摘记,关于HTML5 Webworker(临时)
2010-04-19 09:27 2315把推特里自己说过的关 ... -
向那些伟大的 无懈可击的观点致敬
2010-04-13 15:51 2056世界上有一些观点是无懈可击的 是伟大而完美的. 是值得我们膜拜 ... -
google离开后 我开始重新玩 twitter 了 : @finscn
2010-04-06 18:37 1791google离开后 我开始恢复上twitter了 欢迎大家f ... -
转两篇关于"前端工程师面试"的文章,其实不仅仅适于前端工程师
2010-04-01 10:48 2406原作者是 Nicholas C. Zakas 下面给出的链接 ... -
<你嘴上所说的人生就是你的人生>
2010-03-31 15:43 1581朋友给我发来了一段话,出自这本书: <你嘴上所说的人生就 ... -
推荐大家一款小巧的国产思维导图(脑图软件):Thinking Express
2010-03-26 18:22 4755很久以前 善用佳软上就 ... -
有人玩<名将三国Q>吗? ( 不是<名将三国> )
2010-01-16 14:46 2264有人玩<名将三国Q>吗? ( 不是<名将三国 ... -
有了解相机的朋友吗?帮忙看看这款是徕卡的什么型号 谢谢了
2010-01-15 22:50 1394有了解相机的朋友吗?帮忙看看这款是徕卡的什么型号(上世纪40年 ... -
[求开导]明天又是星期二... 颤抖...
2010-01-11 18:41 2173我一直自认还算是一个 ... -
只说几句
2009-05-20 18:21 1634最近琐事太多 依然无暇去做所谓的正经事, 但是还是想上来说几句 ... -
我最近正在看的一本英语教材,我的英语水平由此可见一斑哦...
2009-04-12 22:08 4597最近打算在上下班的地铁里学学英语 可是我英语水平实在太低下了 ... -
我爱上了一个女孩... (此文标题党)
2009-04-11 12:00 2385她叫 冈田技兰 , 是胖虎/技安(过去叫 大熊)的妹妹. ... -
永远不要低估胖子---哦 不对, 是皮克斯的心
2009-04-07 15:38 1649刚刚在 影像日报 看到了这篇文章: 1.75亿打造,皮克斯《 ...
相关推荐
121-加入ERP项目组后的感想.zip
IT 项目管理资源感悟
有效的沟通对于管理认知、管理期望、管理项目团队、减少冲突以及克服项目管理在其他方面的不足之处很重要。
l 消息。JMS API规定了五种消息:Message、MapMessage、...PTP的消息应用中一个消息只有一个消费者,消费后该消息即不再有效。而PUB/SUB应用中一个消息可以有多个订阅者,而且每个订阅者不一定非要处理该消息。
《项目管理成功案例精选》收集、整理了近年来我国的一些典型项目案例和在国际上获奖的部分项目案例。这些项目的管理科学、有效,有的还遵循了目前权威的国际卓越项月管理模型,取得了项目管理和项目成果的双重成功,...
视锐达公司有幸作为神州数码项目管理软件系统的提供商,并深入参与了神州数码企业级项目管理体系的建设,在此将过程的经验教训逐一总结出来,形成一个《神州数码项目管理最佳实践系列文章》,为推动IT服务行业项目...
1.5 项目经理感悟 1.5.1 大中小型项目管理的区别 1.5.2 系统架构 1.5.3 风险管理 1.5.4 沟通管理 1.5.5 时间、成本、范围和质量的平衡艺术 1.5.6 项目经理自身学习的加强 1.5.7 政治问题 1.6 民营企业IT项目管理之路...
IT项目经理的大项目售前、售中和售后感悟.doc
本书基本内容为“理论理解+管理实务+工作流程+工作模板+工具表单”,同时具有工作指导书或项目管理实务手册的特点,旨在为项目管理一线不同管理层次的专业管理人员提供对项目管理核心内容的理解与感悟,对项目管理...
创业项目推介会感想.doc
使用nginx部署前端项目是一篇非常详细的教程,旨在帮助初学者使用Nginx来部署前端项目。本文首先介绍了Nginx的基本概念和作用,解释了为什么Nginx是一个强大的Web服务器和反向代理。然后,文章详细讲解了如何在Linux...
1、项目管理之美 2、WPS分解 3、项目管理中的六个力 4、项目管理成功管理八要点
[经管20条的感想感悟]生活经管20条感想感悟.rar
信息化项目管理个人感悟.pdf
黄浦区教育局幼儿园网络改造项目参与感想与感悟 裘景秋小学网络改造工程感想 福诺中国移动移动短信平台扩容点之厦门 福州海通证券设备备份造项目参与感想 厦门移动无线城市核心业务平台系统割接 广发华福证券...
写作原理某咨询项目实践感悟.pptx
《金银岛》读后感感悟感想.docx
脱网一年再上线之感悟:虚拟真实相互共存.docx
心得,体会,感想,实习,实训,项目。项目实训实习心得体会感想范文(适用于Java和数据库实训其他实训也可参考用语)
该JavaScript项目实训,基本上包含了所有的JavaScript课程知识点,里面有用户注册登录,信息管理,留言管理,相册管理,还可以浏览图片,编辑图片,模块管理,像图形文字编辑都有,总之功能很强大,希望能给你们带来...