本文发表在 rolia.net 枫下论坛看你的schedule有多长. 如果在IBM上班, 临时学什么都不迟. 但是, 很多公司不会有这么长的时间. 我的希腊经理的口头禅是, "对程序员来说, 两天是无限长的时间, 所有的工作都应该分解成两天以下的子任务:" 前任经理更过分, 经常只给1-2小时的schedule.
记得你提到agile. 我想, 我的公司的方式就是典型的agile了. 这个词还进入了公司的宣传短片.
我到了加拿大后有了个很好的习惯, 把所有的tip, (也许是一个命令用法, 也许是一些设置, 也许是一件事的具体流程, 还有许多非常有用的sample program), 许多是向别人请教出来的, 都记在自己的笔记本上, 几年下来, 记了3大本. 非常有用. 记下来了, 就不用第二次向人请教了, 而实际上, 随着我积累的增多, 往往变成了别人向我请教. 当问题发生时, 当别人去"临时根据基本理论去现学时", 我在几分钟之内就能找到解决方案, 假如我有笔记的话.
我碰到的挑战环境使得我养成了这个习惯. 我发现这里高手太多了, 无论多么难的问题, 都能找到人很快做出来. 很多时候, 头儿问你能不能做这件事? 多久能完成? 如果你没把握, 或者给的时间太长(因为你估了学习时间), 他就找别人去做了. 而我发现, 每次那个敢接这个活的人, 真能在我认为不可能的短时间内做出来.
长此以往, 你在team中留下的印象就很糟糕了. 慢慢地就没人找你做事了. 离lay-off也不远了. 唯一的办法就是慢慢积累. 问一次, 不怕. 就怕同一个问题下次还问. 现学? 门都没有. 现问还马马虎虎. 关键是, 如果没有实际经验, 有时问都不知怎么问. 搞技术, 不detail行吗?
除非这件事所有的人都不会, 才能估算一些学习时间. 有时候, 想从自己搞的领域挤到别人正在搞的领域, 别人都是干了多年的熟手. 都得靠自己用业余时间拼出来.
UML是个很好的东西. 可是我们几乎不用它. 因为, 用它搞出规范的东西时间太长了. 往往设计时, 需求就在不断变化. 一次设计和实现, 往往只有1周不到. 然后, 修改完善. 以前在国内帮IBM干, 最看不上这种小公司的"非规范"开发. 可是几年下来, 承认这种做法有其合理性. 效率真是高, 而且转向特别快.
不过我仍然认为学会用UML及其常用工具是很有必要的. 我准备用业余时间搞通它. 不是"理论上一通百通"那种程度. 要达到"来之能战, 战之能胜"的程度.
某位还提到吃透OO的design pattern, 干活效率提高之类. 这在大的release, 或re-construcuture时是有用的. 我们也常这样. 但更多的时候, 在细节绝不能追求完美. "Ugly but works"是我学会的另一点. 前提是快而且能解决问题. 产品到了不同的用户那里, 几乎都要做许多customization. 而这些customization, 用户在真正用了之前他们自己也说不出, 也不愿说. 而一旦要了, 又要得很急.
产品内部的一些long-tern的enhancement或release, 也就是用得上规范开发, UML, OO design pattern的东东, 不幸地, 因为和客户远, 放在中国和印度做也可以. 正是outsourcing的理想对象. 谁还敢往那个方向靠.
我们曾经把相当一部分东西移到了中国去做. 某些东西曾经就是我管的. 如果, 我当时满足于在那点东西上是专家, 早就完了. 当时就要求我把接手的人教会. 我虽然打点埋伏, 架不住接手的中国人也是聪明加能干再加肯干, 前面问了几个很在点子上的问题后, 后来就不再需要问了.
我深深体会到, 只有和客户近的东西, 才不容易被outsource出去. 这是我后面几年的努力方向.
不过outsource由于一个偶然的事件而中止了. 因为客户中有美国政府, 他们调查发现, 一伙在中国的人竟然可以改我们的source code(做新版本总得commit code吧), 这对他们来说是security hole. 于是就把开发任务全部从中国撤回了. 不过, 移了更多的QA活过去.更多精彩文章及讨论,请光临枫下论坛 rolia.net
记得你提到agile. 我想, 我的公司的方式就是典型的agile了. 这个词还进入了公司的宣传短片.
我到了加拿大后有了个很好的习惯, 把所有的tip, (也许是一个命令用法, 也许是一些设置, 也许是一件事的具体流程, 还有许多非常有用的sample program), 许多是向别人请教出来的, 都记在自己的笔记本上, 几年下来, 记了3大本. 非常有用. 记下来了, 就不用第二次向人请教了, 而实际上, 随着我积累的增多, 往往变成了别人向我请教. 当问题发生时, 当别人去"临时根据基本理论去现学时", 我在几分钟之内就能找到解决方案, 假如我有笔记的话.
我碰到的挑战环境使得我养成了这个习惯. 我发现这里高手太多了, 无论多么难的问题, 都能找到人很快做出来. 很多时候, 头儿问你能不能做这件事? 多久能完成? 如果你没把握, 或者给的时间太长(因为你估了学习时间), 他就找别人去做了. 而我发现, 每次那个敢接这个活的人, 真能在我认为不可能的短时间内做出来.
长此以往, 你在team中留下的印象就很糟糕了. 慢慢地就没人找你做事了. 离lay-off也不远了. 唯一的办法就是慢慢积累. 问一次, 不怕. 就怕同一个问题下次还问. 现学? 门都没有. 现问还马马虎虎. 关键是, 如果没有实际经验, 有时问都不知怎么问. 搞技术, 不detail行吗?
除非这件事所有的人都不会, 才能估算一些学习时间. 有时候, 想从自己搞的领域挤到别人正在搞的领域, 别人都是干了多年的熟手. 都得靠自己用业余时间拼出来.
UML是个很好的东西. 可是我们几乎不用它. 因为, 用它搞出规范的东西时间太长了. 往往设计时, 需求就在不断变化. 一次设计和实现, 往往只有1周不到. 然后, 修改完善. 以前在国内帮IBM干, 最看不上这种小公司的"非规范"开发. 可是几年下来, 承认这种做法有其合理性. 效率真是高, 而且转向特别快.
不过我仍然认为学会用UML及其常用工具是很有必要的. 我准备用业余时间搞通它. 不是"理论上一通百通"那种程度. 要达到"来之能战, 战之能胜"的程度.
某位还提到吃透OO的design pattern, 干活效率提高之类. 这在大的release, 或re-construcuture时是有用的. 我们也常这样. 但更多的时候, 在细节绝不能追求完美. "Ugly but works"是我学会的另一点. 前提是快而且能解决问题. 产品到了不同的用户那里, 几乎都要做许多customization. 而这些customization, 用户在真正用了之前他们自己也说不出, 也不愿说. 而一旦要了, 又要得很急.
产品内部的一些long-tern的enhancement或release, 也就是用得上规范开发, UML, OO design pattern的东东, 不幸地, 因为和客户远, 放在中国和印度做也可以. 正是outsourcing的理想对象. 谁还敢往那个方向靠.
我们曾经把相当一部分东西移到了中国去做. 某些东西曾经就是我管的. 如果, 我当时满足于在那点东西上是专家, 早就完了. 当时就要求我把接手的人教会. 我虽然打点埋伏, 架不住接手的中国人也是聪明加能干再加肯干, 前面问了几个很在点子上的问题后, 后来就不再需要问了.
我深深体会到, 只有和客户近的东西, 才不容易被outsource出去. 这是我后面几年的努力方向.
不过outsource由于一个偶然的事件而中止了. 因为客户中有美国政府, 他们调查发现, 一伙在中国的人竟然可以改我们的source code(做新版本总得commit code吧), 这对他们来说是security hole. 于是就把开发任务全部从中国撤回了. 不过, 移了更多的QA活过去.更多精彩文章及讨论,请光临枫下论坛 rolia.net