!!!!! 散分贴 !!!!! 聊聊编程你会不会‘倔强’

Question

遇到了问题 但觉得这个问题自己是完全可以解决的 却又偏偏卡住了 大家会倔强吗， （我就不信弄不好？又或者放一放？ 再或者others?)大家说说看
我比较倔强的 散分了~~ 

Answer 1

  如果你是在学校，你这样自己努力解决问题，这样做是件好事，  如果是在公司上班，这样做或许太浪费时间了吧.  马上上MSDN/baidu/google 先把问题解决，下班后回去再想。

Answer 2

我比较同意这种做法的，我也是这么做的，上班是有任务的，因为是新手，有是确实是会碰到lz这种情况，
我还是先google把问题解决了，回来再想原因的！

Answer 3

我好像一不会就先问baidu了！！！

Answer 4

其实等你研究的久了，你就知道，哪些困难是要自己研究，哪些是没必要研究，直接GOOGLE即可

Answer 5

如果你是在学校，你这样自己努力解决问题，这样做是件好事，   如果是在公司上班，这样做或许太浪费时间了吧.   马上上MSDN/baidu/google 先把问题解决，下班后回去再想。

Answer 6

我自认为叫掘..........
上个星期刚结束的一个项目，sql文我写了5个星期.............
最后PM让一个前辈来看............
最后证明单是SQL文行不通...............

Answer 7

这事得看情况，如果急活，当然是baidu下速战速决，如果时间允许还是自己多琢磨下好

Answer 8

从项目管理的角度上看，例如pm计划一个任务需要半天完成，而如果过了1天还没有完成，并且pm认为是人为原因，pm还应该跟这个程序员讨论“倔强”问题吗？我们可以google一下“为什么学不像丰田模式”。企业管理中的问题跟软件项目管理也很像。如果pm仅仅会简单地把工作分解和压到程序员身上，那么他也一定会被程序员所反过来“要挟”。这就好像是许多企业学丰田，但是不论搞了多少形式主义都没有能学像。对于项目管理来说，真正的敏捷开发可以保证很高的质量、很准时的进度，而且真正从技术和绩效上体现以人为本，而不是那种靠称兄道弟嘻嘻哈哈而体现出来的以人为本（实际上生产率低下）。

Answer 9

我这里随便想象地“附会”几条丰田经验到软件开发上：1. 程序员编写的代码只应该有项目成功所需要的一半，另一半应该是检测、管理等。你不能仅仅靠买来所谓先进的项目管理、质量保证和开发工具，应该（一旦工具不合手就）自己开发和改造关键的工具，从而了解如何善用工具。而不是一旦遇到工具不合手的问题就去寻找新的工具，那样永远只是一个理论家而不是实践者。2. 只做必要的重构工作，不盲目地为了分层、模式编程而重构你的系统。3. 物尽其用。每个人离开电脑，电脑就暂时停机了？为什么不用来做十分钟自动化测试。4. 对待bug要做到全员管理，而不是只有测试人员才能报告bug。对待bug要如临大敌一样敏捷地响应，而不是无动于衷。5. 只给开发人员采用可靠的经过充分测试的技术。6. 按照软件的机制自己去精细和准确地解决问题，而不仅仅是到google上去找实现方法。7. 不仅仅是产品，设计、管理等等要纳入同一个bug管理系统。不论最终是否被评估为bug，任何人都可以对于感觉是bug的东西进行投诉。8. bug管理系统全过程对所有人都是透明的，可以从一个系统上读到全过程的处理情况。9. 管理者是真正懂行并且懂得具体生产产品的（而不仅仅是指挥）。
在一个好的组织中，个人性格不会与组织目标发生什么冲突。

Answer 10

大多感受了,不会就查资料,查不到就CSDN..