分工和学习的关系怎么平衡?

清醒疯子 发布于 2014年03月12日 | 更新于 2014年03月13日
无人欣赏。

首先,一个人包打天下是不现实的,效率太低。所以,我们需要分工合作。

然后,既然是分工合作,前提自然是别人已经干好的事情,我们不重复去做,而是在别人的基础上锦上添花,让事情变得更好。

但是,要不要更彻底地分工呢?别人已经干好的事情,不但自己不干,甚至不去做《使用指南》以外的任何深入学习呢?

比如,当我们拿到一个第三方类库的时候,是只做好输入、看好输出,黑盒使用呢?还是也花时间去阅读对方开源出来的代码,好好了解类库代码(至少是自己用的那部分)?

比如,我们是直接拿搅拌机打肉,坏了就换一个?还是学习一下搅拌机的知识,坏了就自己临时修一下?

还是说一切看自己需求的深度?如果输出能满足我,就直接使用别人的输出;如果输出不能满足我,就找下一个;如果没找到能满足我的,才往深了解,自己改,为自己定制输出?

如果重复创造旧轮子是错的,那么对于非轮子生产者,重复学习怎么创造旧轮子是不是也错呢?只有我们被细分得不能再细的从来没有人实现满足过的工作才值得深入学习吗?

如果我们不断远离基础,又怎么解决“如果基础错误,在错误之上的任何深入学习都是错的“这个问题?

问题问到这里,自己倒是有个想法:有欲望,找现成的满足方法,如果一个方法不够好就换找另一个。如果在一定的时间内都没找到能满足的,就从找到的挑一个出来,修改定制来满足自己欲望。 也就是说,先排时间,在一定时间内不断地找能满足欲望的方法,超过给定时间,挑其中一个进行定制。

共15条回复
tinyfool 回复于 2014年03月12日

写的不少,仍旧有条理方面的问题,仍旧看的出来有思而不学的痕迹,希望你根据问题给自己找本书看看

huang9012 回复于 2014年03月12日

熟练使用的前提下,对功能结构进行扩展,从而阅读源代码。时间久了,就有能力自己造一套自己的齿轮了。至于工作中分工,感觉界限不是太清晰,每个节点自己至少都要了解,这样对于出现问题之后的有效沟通有帮助,还有就是题主的问题,我看了半天仍然觉得不知道在说什么。

BarryWey 回复于 2014年03月12日

项目开发过程中,对于第三方的类库来说,只要能够正常使用并完成项目功能就好。

但接下来的业余时间,你若感兴趣就可以去研究下第三方类库到底是怎么实现的。

但是大部分的人,用过了,就过了。

holly 回复于 2014年03月12日

有个名词叫做 全栈...

清醒疯子 回复于 2014年03月12日

1楼 @tinyfool

2楼 @huang9012

3楼 @BarryWey

4楼 @holly

谢谢大家:)

问题已经明白了。

事情可以用“先广后深“的顺序来完成。

首先安排好“广“和“深“的时间分配。比如,工作时间五天,把一天时间用来“寻找方案和学习方案的使用“,四天时间用来对方案进行“深入优化定制“。

如果一天不停地“寻找、使用“,还是解决不了问题。从第二天开始就可以比较“寻找“到的方案,挑一个最接近目标的方案。对这个方案“深入分解、学习、定制“,直到问题解决。

在这个“深入“的过程中,把自己深入的心得放出来,看看有没有业内人反馈“更好方案“。

这样就可以了:)

BarryWey 回复于 2014年03月12日

5楼 @清醒疯子 nice …… 「先广后深」的说法非常nice……

清醒疯子 回复于 2014年03月12日

6楼 @BarryWey

嗯,方向尽可能不错的前提下好好深入:)当然,也不能一直在调方向,这样只会什么方向都是错误,因为做不深入就没有优势。

广,只是最前期的基础。后面大量的工作,还是要靠深入来完成。

方向不错的话,后面就是功力问题了:)

清醒疯子 回复于 2014年03月12日

或者,像我听的一个Podcast说的,没有一直不变的正确方向,只能不停地微调深入,再微调再深入:)

董一凡 回复于 2014年03月12日

你误读了一个问题,这也算是程序员界误读最多的问题之一了。从来没有人反对重复造轮子,一直以来都是反对重复发明轮子。事实上造轮子是非常好的一种学习的方式。

比如正则表达式,很多人都是学了就忘,用到再学,相反你去写一个正则表达式引擎去,99%的概率,正则表达式从此深入骨髓,想忘都忘不了。

再比如基于引用计数的智能指针,其实ARC本质就是这玩意,如果在strong还是weak的问题上纠结,那就自己去写一个看看,你想再纠结都困难了。

清醒疯子 回复于 2014年03月12日

9楼 @董一凡

咦?这个点超有意思:)

Silence 回复于 2014年03月12日

我觉得这类问题太虚了,属于方法论的讨论范畴了。讨论具体问题可能比较实在一些。

imgamer 回复于 2014年03月12日

想太多了,人又不是上帝。只需要用可以接受的方案解决当前的问题即可,只要你不笨又有点追求,有空的时候重构就行了,多动手你会一次比一次聪明,在你没成为大师前你就别幻想能一下子写出完美代码。如果说那个方案不能解决问题,无论是因为效率还是别的什么原因,这样的需求会驱动你改进。简单点说是,需求驱动,不断重构。

清醒疯子 回复于 2014年03月13日

嗯,其实,我在想的时候有一个错误的前提假设:就是可以做方向错误的深入学习。

事实上,只要我们去深入学习,永远绝对不会在错误的方向上努力太久,是不是?:)或者说,所有深入学习,都必然包含方向的选择和调整,是不是?:)

清醒疯子 回复于 2014年03月13日

祝大家只需努力深入学习研究,永远不存在方向错误的问题:)

清醒疯子 回复于 2014年03月13日

刚才在地铁上又想了一下这个问题。当然,应该像Tiny兄说的,我应该先去好好学习一下,比如说把《精益创业》这本书买来看了,而不是仅仅听一个Podcast,只得到一点点片断就开始思考。这个,今晚会去购书中心买,但可能也没有时间看,最近都在赶代码。

Podcast主要分享了一个点:在方向正确之前,不要做过多的深入。通过几个例子来说明,比如先把软件功能展示视频放出来,如果受欢迎,再组队开发(这有点像现在的“众筹“)。先把现成的类似产品放出来,如果接受度高,再定制自己的产品。先用人工方式提供服务,如果量大,再改成自动化24小时服务。

总之,就是以最低的成本验证方向,调整方向,然后才是深入开发。

业界,很多一开始就码足资源投入,最后颗粒无收的尝试,数不胜数。如果资源雄厚,也许可以多犯几次错,靠一次胜利赚回来,个人呢?有几个十年?

如果仅从这个角度看问题,“最低成本验证方向,再投入资源深入开发“,应该很难是错的。

我想把从这个角度看来不错的观点,换一个角度看看它的弊端在哪里。

从创业,回到个人。是不是“最低成本验证手上的资料是否足够好(或最好),再投入精力时间进行深入学习“?

可能有人会觉得,只要深入学习总是好的,现在这里用不上,以后那里说不定就用上了。那创业也能按这种逻辑干吗?只要努力做产品就好了,现在这里没人买,以后那里说不定就有人买?甚至再退一步,这次创业不成功,说不定下次创业就成功?

所以,我们不难发现,方向错误的努力和深入是没有意义的。

回到问题,我们来看看“最低成本验证手上的资料是否足够好(或最好),再投入精力时间进行深入学习“(以下,我们把它简称为“先定向,再发力“),弊端在哪里。

其实,通过简称,我们不难发现,如果一直定不了向呢?什么时候才发大力?比如我们听到身边很多人天天叫迷茫、困惑,这明显就是一直定不了向啊,然后就一直不发力啊,然后就很容易废柴啊。

再看看身边很早就找到工作,很早就混上一级的同学、同事、朋友,很多人根本就没有考虑太多方向的问题。老师给什么方向,就好好干;公司给什么方向,就好好干;团队做什么方向,就好好干。没有太多纠结、怀疑,不管给的是什么方向,就好好干,往深挖,工作能力就上来了啊,工次就上来了啊,级别就上来了啊。

相反,那些自以为自己很聪明,一直在怀疑别人方向,天天验证新方向,立志要先找到自己方向再好好发力的人。就一直在找方向,从来没见他发过力啊。

再退一万步讲,一个问题能不能解决,除了手上工具强不强大以外,也看使用者的功力如何。同样的工具,同样的类库,有人能解决问题实现功能,有人不行。

同理,同样的行业,同样的方向,有人能做成,有人做不成。

本帖有15个回复,因为您没有注册或者登录本站,所以,只能看到本帖的10条回复。如果想看到全部回复,请注册或者登录本站。

登录 或者 注册
[顶 楼]
|
|
[底 楼]
|
|
[首 页]