该不该从事更多项目？
公司有公司的项目，虽然主要分配给我的工作A比较无聊，但也偷偷接触了一些公司的核心项目B， 没有时间搞B，这时候又有github上的项目C诱惑，
好好搞B的话，也许能提高收入，但C上能学到东西。
又希望早日结束A，而公司目前缺人，不让俺全职搞B。 有点想把C砍掉的意思。。C回报慢周期长
“andrew ng语重心长的说，每次专心做一件事情就好了，因为你做的最大的事情远远大于次大的，例如乔布斯的苹果和皮克斯。”
做一件事 one at a time，据说这句话最近很流行，纠结。
我的看法
A.
无聊项目变有趣的方法可以是流程自动化 文档化 或者重构。这些同时还为你能抽身创造客观条件
B.
你不可能没有时间搞B，没有时间100%只是借口，在我看来可能的原因有 你懒／老板不让你搞／或者是你本职的A没搞好等等，A没搞好的话参见上一条，创造你能抽身的条件；懒的话自己想办法解决；老板不让你搞的话，在解决了其他问题以后，找老板谈，告诉他你已经把A项目撸圆，不需要很多精力维护，B项目你已经了解了觉得很有趣，你对B项目的看法规划等等
C.
C能学到东西，A.B学不到是假象。C如果和公司无关，那么就只能在把AB搞漂亮之外的时间来搞，这是基本职业素养，时间自己找。 千万不要觉得只有C才能学到东西就好。我的建议是公司如果压力大的话不妨先抛开C，投入精力在改善AB两个项目，优化架构，或者是和老板沟通增加AB的资源（放慢研发周期或者加人），略微卸掉压力以后再找时间来玩C
为什么国内有不少PHP程序员不喜欢THINKPHP，甚至鄙视THINKPHP？
为什么国内有不少PHP程序员不喜欢THINKPHP，甚至鄙视THINKPHP？
我的看法
自古文人相轻，程序员更甚，所谓的鄙视不是简单的链条或循环，而是密密麻麻的有向图，什么技术都有人鄙视
我的看法是技术是有适用场景的，什么样的业务，什么样的硬件，包括公司已有什么样的开发人员，什么样的开发人员市场上容易招聘等等各种因素都会影响到技术选择
就比如说“世界上最好的语言”，其古怪程度确实罄竹难书，有篇知名博文用两头都是起子的锤子来描述并不为过，但只需要“人好召，环境好配，运维简便，性能过硬” 两头都是起子的锤子也至少能在市场占有方面完爆很多竞争对手。市场是不会说谎的，用的人多的技术一定有它的优点
作为负责技术选型的lead programmer，必须综合考虑所有的因素来选择对公司最合适的技术，而非争个人喜好或是仅靠单纯的某个方面做出选择
而一旦某个项目技术选型确定，或者是你加入的是已经成熟的项目，那么吐槽已定的技术栈就没什么建设性了。这时候适应已有的思维带着镣铐跳舞才是正道，当然如果能够融合其他技术栈的思想来弥补现有技术栈的一些缺陷就更好了。
说回thinkphp的话，我最近否决thinkPHP的理由和否决Laravel的大致理由是一样的：我不需要全功能的框架
如何看待敏捷开发？
能否根据你用敏捷开发的经验简要的说下敏捷开发。
谈谈你自己的理解即可。几句话，几段话，都可。
我知道这不是编程语言，我只是想了解大家在项目中用到敏捷开发时候，对其的理解。
我的看法
有人说这是某种思想，有人说这是某名字和古董OS一样的实践，又有人说这是另一些实践
我讨厌这种暧昧不清的词
我只认为并相信
a)高效的团队开发有必要遵循某种方法/流程
b)方法/流程是随时都可以优化而且应该不断优化的
这是我在 SegmentFault 上的问题回答选编，遵循CC BY-SA 3.0 CN 分享
题图：万智【鄙视】
