我希望的前端攻城狮

前言

我个人,并没有工作很长时间,但是确实也见过不少前端攻城狮。

兴趣很深的,纯粹工作谋生的;



刨根问底的,浅尝则止的;



偏重管理的,执着于技术成长的;



极具天赋的,需要前辈指点的;



... ...

自己经历过两家大公司,碰见过不少前端攻城狮。在换工作之时,也面试过不少或大或小的公司,他们面试我的同时,也是我面试他们。从中,也大致能感知,对方面试的着重点是什么。也就对这篇文章有了比较重要的参考依据。

 

各种分类,你能想到哪些?

或者你还可以分一下,从积累成果来讲——坚持写博客的(但是,你需要问问你自己,你的博客中的文章,够精华吗?),没有过多思考总结的;或者,有成品展示的(如github上的源码),只能口语表达实力的。

我个人还想这么区分,从理论与实践的区分——善于理论分析并思考于实践的,或者通过实践去反推(重新思考)理论研究的。

当然还有,动手能力来讲——碰见问题,及时分析并快速动手解决的,或者稳扎稳打,全局思考,一丝不苟的。

毕竟在大公司呆过,或者你的分类标准来自BAT这种大公司的等级制度,如百度的T几T几的,这些东西或多或少能证明点儿实力,但是,切不可拿它涵盖全部,否则,你会埋没了他的真实才能。

你工作中深入接触的每一个同事,你都可以为他产生一种分类,那是因为你发现了他的可贵(更有可能是他的平庸)之处。

 

以我的视角,我希望你可以如此(当然,千万别在意我的语气有点儿大了)——

 

重理论

绝大部分的前端都是实践驱动的,这样并没有错,实践能够让大家更加深入的理解理论。我想强调的是,别忘了实践之中,或者实践之后,多看看相关技术点的理论部分,深入研究之,再反转过来,联系实践,不断的理论与实践去结合,更多的不是为了应用实践去验证理论,而是两者结合不断的思考,引入更深层次的解决问题或者创新。

相信绝大部分的理论来自阅读“枯燥的”书籍。没有错,很多书籍能够帮助我们全局看问题、深入看问题。

这么长时间的工作经历,碰见能够“智慧”看书的,真的不多。很多人,书籍读的是快,但是,只懂了皮毛,只知道好像是那么回事儿。如果你没有深入思考,读之何意。

谈到重理论,不单单读书,毕竟很多书籍也是通过实践总结汇总出来的,也同时多看看网上优秀的理论性质的文章。说白了,重在把你想要弄清楚的理论点(举个例子,如js闭包、函数式编程等等),结合你的实践,深入理解透彻。

 

善创新

我所谈到的创新,不是指很大的方面,如管理体制、工作流程等等(当然,如果不排斥这类的创新idea),更多的是指诸多小的方面,如小工具的使用、一些实时出现的创新技术、编程模式、架构模式等等,说大也大,说小也小。

在这里,我列举可能创新的来源——

实时跟进一些新技术网站,领略新技术带来的冲击。当然,如果你从这些新技术的学习中,你对它有些更优秀的改良,那再好不过。不过要记住,结合自己的项目来做创新,你的改良能够解决你项目中的问题。



同事讨论。问题讨论的过程中,思维暴风雨式的撞击。希望你可以陶醉于技术的讨论之中。



发觉问题。这里的问题,指的是项目中发现到的种种,如底层框架、项目架构、编码风格、团队协作等等等等,这里需要你敏感的嗅觉,与经验、知识量多少有些关系,如果你是新手,不要在意你的思维过窄,或许你的idea,其他老油条并没有思考过。

但要注意,所谓的创新,不仅需要你敏锐的思考,更重要的是实践之。不管你的创新贡献于个人,还是团队。、

 

乐分享

这一点,我多说点儿——

在时间上,你可能没有多少时间去筹备PPT文稿,也没有时间,把你要分享的专题去进行深入调研或者扩展。工作忙完一段时间之后,你的分享idea也就渐渐淡了,因为你总有更重要的事儿等着你。

在团队里,你做了很多不错的分享,但得到团队认同的分享却少之又少,很难用于项目之中。



在团队里,你也很难碰见与你同样享乐于分享的同事,你的分享换不来其他人的分享,你似乎总是孤独的一个。
在面子上,你也可能会担心你分享的内容太过肤浅,会带来同事瞧不起的眼光。 更有可能,你觉得你做的东西或者你调研的东西太easy,自认为没什么可分享的,没啥技术含量,不屑于分享。 ... ...

我曾致力于团队的学习氛围的建设,但多人的反馈之中,似乎有太多的愿与不愿、成与不成。

我希望你可以多思考分享带来的好处——

其一、自己可以对分享专题的把握达到一定深度,并可以努力将分享的专题成为你立足于团队的优势。



其二、塑造自己在团队乃至整个公司的个人影响力。



其他、语言表达力的提升,个人气场的锻炼等等。

我曾听到一个同学这样描述,当他发现某一个技术创新点的时候,他总想向别人分享出去,一起讨论讨论,一起用用,提高点儿开发效率...

简单的描绘,却印象颇深。希望你也可以如此。

分享,它在技术大家庭来讲,本就很简单,我们只是单纯的讨论技术,讨论它怎么让我们提高开发效率、解决项目问题等等。如果考虑其他乱七八糟的事儿,那么你离技术就远了。

 

成果导向

这一点,并不是针对那些“光说不练”的同学。更多的是那些思路开阔却不善实践的同学。毕竟实践出来的东西才能给自己的团队或者公司带来收益。

一位前辈的话——先成事,是成有利。

先把事儿做出来,也就是所谓的成果导向,这样团队的同学才能认可你,你也就有了坚实的合作基础。

那么,所谓的成果导向,是指什么——

如果你调研某一项新技术,你先用之,不要求你直接应用于项目之中,哪怕你跑出个不错的DEMO,再把它展现出去,再提出你理解的优缺点,不要拿着官网的介绍说说而已。



如果你的项目中不得不用到某一项新技术,用完之后,希望你把技术的关键点结合你的项目实践一起展现。



如果你思考很多,却无暇分享,也希望你可以将之形成博客之类的文档,将之分享出去。这里的博客,也将成为你思考的小成果。



如果你在阅读某个书籍,你发现某一个点子,非常值得实践,不要犹豫,实践出来(无论你贡献于线上产品还是线下产品),再与大家详细说说。



... ...

成果导向,为的更多的,是自己深入把握形成成果过程中用到的技术,带来团队及公司的收益的同时,驱动自己成长。

 

完美主义

谈到完美主义,相信每一个程序员都有,只是或多、或少的区分而已。

我要声明,我所说的完美主义,是优点,而非缺点。

如果你坚持自认为还算不错的编程风格,那么,我想你仅仅有轻微的完美主义。



如果你一个空格、一个分号你都不放过,那么,我想你有过重的完美主义。我表示,很赞(哈哈)。

因为一个空格,一个分号,在你看来,他们的不和谐,将导致你整个代码体系质量的下跌。这将导致,你对这款产品的失望(当然,我说的有点儿夸张了)。

你可以有重度完美主义,但我希望,你针对的是个人,这也就代表你对自己有着极高的要求,也就很有可能,你将在你所在的领域达到一定高度,这全然来自你的完美主义精神,你不会放过任何一个阻碍你不完美的地方,这种自驱力会让你把每一个问题都解决的非常透彻深入。

但要注意,几个方面——

其一、要把握住做事儿的时间,不要把重要的事儿,因为你的完美主义而被耽误。



其二、不要局限在封闭的个人主义里,你需要接纳他人的观点,相信他人的思维更能开阔你的完美主义。



其三、毕竟产品是多人协作完成的,你要虚心接纳他人看起来不是很好的代码,要相信他们的上升空间。要宽以待他人的不完美之处。



其四、要善于学习他人的过人之处,不要钻牛角尖。虚心求教进步。

完美主义的工程师,要好好享受你的卓越之路。如果你是,欢迎你与我多加沟通。我个人极其欣赏重度完美主义的工程师。

 

OK,确实啰嗦了很多。

什么大众选择的标准,如天资聪慧、动手能力强等等,在这里就不说了。但我要强调,你需要自信、更需要努力。

以上偏向于管理方向,但我个人不喜欢走管理方向,只是在工作过程中,略有思考。

以上是几个大的方面,或许你或多或少都有些,也希望我的观点能够给你带来些许指引。

希望可以在日后的工作中,可以碰见拥有以上特征(其中的几点、全都有那就更好)的同学。一起玩儿技术、讨论技术、分享技术。

我不奢求你多么高尚的热爱编程,只是希望也可以或多或少——喜欢思考、善于总结。

今年开始的第一篇博客(这次是纯非技术类),同时鼓励自己日后一个月一篇精华技术类博客,捡起来写博客的习惯。实在是非常清楚写博客的好处,希望看到这篇文章的你,也可以写写博客。

如果你正好有点儿上述我讲到的特征,正好也是前端攻城狮,欢迎与我沟通,当然更希望你加盟。



你可能感兴趣的:(前端)